I just flipped the switch for the 3.28 Release Video. I’m really excited for all the new awesome features the community has landed, but I am a bit sad that I don’t have time to put more effort into the video this time around. A busy time schedule collided with technical difficulties in recording some of the apps. When I was staring at my weekly schedule Monday there didn’t seem much chance for a release video to be published at all..
However, in the midst of all that I decided to take this up as a challenge and see what I could come up with given the 2-3 days time. In the end, I identified some time/energy demanding issues I need to find solutions to:
- Building GNOME Apps before release and recording them is painful and prone to error and frustration. I hit errors when upgrading Fedora Rawhide, and even after updating many apps were not on the latest version. Flatpak applications are fortunately super easy to deal with for me, but not all applications are available as flatpaks. And ideally I will need to setup a completely clean environment since many apps draw on content in the home folder. Also, currently I need to post-process all the raw material to get the transparent window films.
- I run out of (8GB) memory several times and it’s almost faster to hold power button down and boot again, than to wait for Linux memory handling to deal with it.. Will definitely need to find a solution to this – it builds up a lot of frustration for me.
I am already working on a strategy for the first problem. A few awesome developers have helped me record some of the apps in the past and this has been really helpful to deal with this. I’m trying to make a list of contacts I need to get in touch with to get these recordings done, and I need to send out emails in time with the freezes in the release cycle. It makes my work and the musician’s work much easier if we know exactly what will go in the video and for how long. I also had a chat with Felipe about maybe making a gnome shell extension tool which could take care of setting wallpaper, recording in the right resolution and uploading to a repository somewhere. As for the second problem, I think I’m going to need a new laptop or upgrade my current one. I definitely have motivation to look into that based on this experience now, hehe..
“Do you have time for the next release video?” You might ask and that is a valid question. I don’t see the problem to be time, but more a problem of spending my contribution energy effectively. I really like making these videos – but mainly the animation and video editing parts of it. Building apps, working around errors and bugs, post-processing and all that just to get the recording assets I need, that’s the part that I currently feel takes up the most of my contribution energy. If I can minimize that, I think I will have much more creative energy to spend on the video itself. Honestly, all the awesome contributions in our GNOME Apps and components really deserve that much extra polish.
Thanks everyone for helping with the video this time around!
One of the Gnome repos (probably GNOME:Next, I’m not into pre-release repos) in openSUSE Build Service.
You are not the only one to regularly hit the limits of Linux’s memory management and yeah it’s super frustrating when it hangs. Ironically I originally switched to Linux because of Windows 98’s tendency to do the exact same thing.
At a guess I’d hope we could use cgroups to make sure the Shell stays responsible in the face of memory, IO and CPU contention. I don’t know how big a job it is though …
gnome-shell is JavaScript cancer. It needs to be rewritten in a real language.
+1 on it being easier to hit the power button than to wait for memory management to sort it out.
Admittedly I am using firefox and pycharm, so they can use a lot of RAM, but I wish these apps could react to low memory situations (like maybe, they could put a lot of their buffers somewhere that linux can easily dispose of them).
I think Linux would need some new infrastructure for this to work well.
With OOM … well, everything just completely comes to a halt.
Using VMs and restoring them without properly powering them off over a few days is a great way to do this too.
Disable swap right now. These days it’s probably near useless anyway.
Many years ago I reported thrashing in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/27441
because at the time I had a hope that a consumer-oriented distribution would find the default behaviour (just thrash and thrash and thrash) unacceptable, but it never went anywhere.
It’s a seldom occurring, hard to fix problem – it really requires being bold, you need to come up with heuristics for when things are going awry and then go ahead and prioritize a kill that may cause data loss.
Still super enjoyable to watch. Thanks for making these :)
Can you do the videos without the mouse cursor being visible? Is it even possible to do that, screen capturing and leaving out the cursor?
So that a potential user would understand that both mouse and keyboard could be used (now or more fully in the future) to fully work/create/play with Gnome.
Sleek video!
If you enable the magic SysRq key, you can use this to immediately invoke the OOM killer instead of waiting for half an hour:
Alt + SysRq + F
https://fedoraproject.org/wiki/QA/Sysrq
Warning: this affects the security a bit as the OOM killer might decide to kill your screen lock (never happened to me though; if there is enough memory the OOM killer doesn’t do anything apparently).
(A maybe better option is to tweak the VM overcommit settings so memory allocations fail earlier and faster, but can’t remember the details as it happened to break some part of my workflow that relied on the default overcommit.)
Years ago I set ulimit in my shell to force runaway browser processes to die rather than trigger OOM. Surely cgroups has better and stronger support for saying “If anything goes out of control relative to my machine’s resources then a) renice it, b) let me know, c) just kill the damn thing.”