Planet GNOME

Writing state machines gets a bit of a bad reputation because they are often implemented in complex manners which are specific to the problem domain. I think that makes people shy away from writing them when they are truly beneficial, including myself.

Where they often go awry is when you have some sort of work that needs to be done asynchronously. This is exceedingly common in UI programming like GTK applications but just as easily found in daemons.

Because of this, I see people explicitly avoiding the state machine, or worse, implicitly avoiding its correctness by open-coding a solution across a dozen callbacks.

With DexLimiter and DexFiber I find I can write these state machines better.

You can use the limiter with a max-concurrency of 1 to get an “asynchronous Mutex” of sorts. No lock management necessary.

static void password_daemon_init (PasswordDaemon *daemon) { daemon->limiter = dex_limiter_new (1); }

Imagine, if you will, that a limiter is a mutex plus a callback/closure which fires as soon as a slot is free. That means we need a little state to send to our transition callback.

/* Define our closure state for a transition */ DEX_DEFINE_CLOSURE_TYPE (StateTransition, state_transition, DEX_DEFINE_CLOSURE_OBJECT (PasswordDaemon, daemon), DEX_DEFINE_CLOSURE_VALUE (PasswordDaemonMode, target))

That is a nice wrapper around defining a struct with a new and free function.

Now we can request a transition of the state machine. Since our DexLimiter is an asynchronous mutex (with a single runnable slot), the fiber will not be spawned until it is the highest priority.

DexFuture * password_daemon_transition (PasswordDaemon *daemon, PasswordDaemonMode mode) { StateTransition *transition; transition = state_transition_new (); transition->daemon = g_object_ref (daemon); transition->target = mode; return dex_limiter_run (daemon->limiter, NULL, 0, password_daemon_transition_fiber, transition, state_transition_free); }

That makes our transition code very clean when you combine the fiber with g_autoptr() and dex_await() to await the completion of futures. So a state machine might look like the following:

static DexFuture * password_daemon_transition_fiber (gpointer user_data) { TransitionState *state = user_data; GError *error = NULL; switch (state->target) { case PASSWORD_DAEMON_MODE_HANDOFF: if (state->daemon->mode != PASSWORD_DAEMON_MODE_INITIAL) return invalid_transition (state->daemon->mode, state->target); if (!password_daemon_enter_handoff (self, &error)) return dex_future_new_for_error (&error); break; case PASSWORD_DAEMON_MODE_LOCKED: ... case PASSWORD_DAEMON_MODE_UNLOCKED: ... } return dex_future_new_enum (state->daemon->mode); } static gboolean password_daemon_enter_handoff (PasswordDaemon *daemon, GError **error) { GSocket *control; if (!(control = dex_await_object (create_socket (), error))) return FALSE; ... }

What I find nice about this is enter/leave transition components can be customized for the state machine transition. That leaves room for transitions between states which require specialization for correctness.

This is much cleaner than ad-hoc callbacks chained together because you can await in the transition fiber for asynchronous work to complete and the state machine itself is preserved. No shoving temporary state in your class instance. No testing hell to see if you caught all the failure cases. No pain with sequencing or order of main loop processing.

Hopefully that shows you can use libdex to write more correct and cleaner state machines by keeping the majority of the implementation in one place.

Week 23

This week's icon is for whitequark's project:
ChiPass: "Store and autofill passwords"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

Week 22

This week's icon is for Krafting's project:
Hex Colordle: "Find the color"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

This month I’m mostly listening to music by Nu Genea, Danalogue and Noon Garden.

I’m going to tell you about a big change I’m proposing for folks using Freedesktop SDK to build operating systems. And I’m also going to talk a bit about the GNOME Foundation elections. Maybe I’ll do that first.

GNOME Foundation elections

The GNOME Foundation is a democratically organised not-for-profit that grew from the GNOME open source project around the year 2000. Anyone who contributes to the GNOME open source project can be a member of the Foundation, which allows (among other things) periodically voting in a Board of Directors who govern the Foundation. You probably know all of this.

Back in 2001 the Foundation was a lively active space. Check out the election results from 2001: 11 candidates were selected out of 25 candidates, some of whom made pretty wild campaign promises such as banning all mentions of proprietary software.

When I became more involved in GNOME, ten or fifteen years ago, the Foundation seemed pretty boring and sensible and not many people volunteered to be directors. Here’s a mail from 2017 of someone complaining about not enough candidates and low voter turnout.

This year’s election has nine eight candidates for five seats, and a lively debate. Two years ago a big explosion happened in the community, and we are still dealing with the fallout and, in many cases, still piecing together what actually happened. (It seems like the explosion had been building for a long time and maybe the boring and sensible days of 2017 weren’t as boring and sensible as they appeared from outside.) I am not impressed by the tone of some of the discourse, everyone involved in the campaign believes in what they are doing and deserves respect, but it does make me optimistic about the future of the GNOME Foundation. Questioning things is healthier than ignoring them.

My quiet theory is that the dynamics of open source have changed fundamentally now that LLMs are a mainstream technology. Code is less of an asset than it ever was. A lot of work in the desktop space since 1997 has been simply keeping pace with the rest of the industry: Apple introduced glassy window bars and so we had to have them in GNOME too, Apple introduced “retina” displays and now we need fractional scaling, Apple introduced the App Store and now we need Flatpak, and so on. All of these are huge engineering efforts requiring a lot of new code.

Now the industry is out of ideas. Apple this year are announcing AI integration and more glassy window bars.

So if code is not the asset, what is? The people, as it always ways. And in an increasingly hostile and untrustworthy internet, where you can’t even trust websites any more, a resilient autonomous and trusted structure like the GNOME Foundation, with a battle-tested democratic structure, and strong moderation capabilities to keep out the increasingly automated and vociferous trolls, is a very valuable thing indeed. (No wonder the trolls see it as a threat).

It’s hard to imagine a parallel universe where there’s no KDE eV and no GNOME Foundation, but I suspect we would miss both of them. Clearly all of the candidates believe in the Foundation enough to run for election. Remember that it’s an unpaid position with a lot of responsibility and minimal benefits. Being a director is a personal sacrifice. So thanks to everyone who keeps it working.

freedesktop-sdk.bst:public-stacks/runtime-gnu.bst

Onto the more technical material, I guess. The Freedesktop SDK is a widely used Flatpak app runtime that powers thousands of apps on Flathub. You probably know that, too.

Flatpak aimed from the beginning to be distro-independent, and consequently the Freedesktop SDK isn’t a repackaging of Debian or Fedora or Alpine Linux, but something more like a DIY Linux From Scratch build. As an app user you don’t notice any of this, because it’s very well executed and apps just work. Again, it’s hard now to imagine a parallel universe where the main Flatpak runtime was Fedora in a trenchcoat, but perhaps that would have impeded the success of Flatpak. (Of course Canonical still built their own app store technology, but I suspect that Canonical re-inventing things is part of every parallel universe).

So Freedesktop SDK has build instructions for common Linux tools, utilities and libraries, and they are so good that most BuildStream projects end up junctioning Freedesktop SDK to reuse them. (I covered this in more detail back in April). In theory this brings a virtuous cycle: we use FDSDK in industry and that funds maintenance and improvement of the build instructions, which in turn benefits the Flatpak runtime which doesn’t have any source of funding of its own.

I’ve been working on a slightly tricky intersection between these two worlds, which I call “Choose your own userland”. It makes a relatively small change to a stack element in Freedesktop SDK, but one which has big consequences for BuildStream projects that junction the project. (And no immediate consequences for Flatpak users, but you could see it as future-proofing).

A stack element is a group of elements. Freedesktop SDK provides various “public stacks” with useful element groupings. Most of these are related to build systems, like public-stacks/buildsystem-autotools.bst which includes everything you need to run builds with the crusty old GNU Autotools build system. Then there’s this special one: public-stacks/runtime-minimal.bst, which as of today includes the following:

• Root filesystem symlinks
• C/C++ platform libraries like GNU GLIBC,
• The GNU Bash shell (and its dependencies Readline and ncurses)
• GNU Coreutils, and all their dependencies

This stack is a recent addition, announced in the release notes of last year’s FDSDK 25.08 major release:

[BREAKING CHANGE] It’s now possible to create more minimal runtimes thanks to rework of bootstrap-import.bst. This adds a new stack public-stacks/buildsystem-make.bst which is essentially same as the original bootstrap-import.bst. There is also a new stack public-stacks/runtime-minimal.bst that is intended to provide a minimal environment that you can shell into. More info in the related issues: #1728 (closed), #1523

My selfish motivation for this change is I want to build embedded systems that don’t include GNU Bash and Coreutils at all, using BusyBox to provide the shell and utilities instead. This is hard today with FDSDK because every element unconditionally depends on Bash and Coreutils, so how can I remove them from my final system? But coincidentally, in the desktop world we are also seeing GNU Coreutils replaced with uutils/coreutils, a reimplementation in Rust which is already the default in Ubuntu since 25.10. So there’s another reason we might not want to hardcode a specific coreutils implementation in the lowest level stack.

The idea implemented in my branch came from Abderrahim and is delightfully simple: just drop Bash and Coreutils from the runtime-minimal stack, and have elements opt into them explictly.

On hearing the idea, I wasn’t sure how this would work, so of course I was effectively nerd-sniped into trying it. The result is as we’d hoped, it allows you to build systems with alternative coreutils. The FDSDK includes some example VMs, and here’s an example of one of them booting with uutils/coreutils (taken from MR!31779):

https://gitlab.com/-/project/4339844/uploads/04ea5b38ae78b5ee6ed175ea9ea54369/FDSDK_example_system_with_uutils-coreutils.webm

So the approach works. My main concern was the amount of churn we would cause if we change the meaning of runtime-minimal.bst. Of course, we often still want GNU Bash and GNU Coreutils, so my branch adds an additional public-stacks/runtime-gnu.bst element that brings in a GNU userland. I added Bash and Coreutils into all the public-stacks/buildsystem-*.bst elements too as we still want them at build time. That means that for most elements the change is actually transparent. You just need to ensure that each output explicitly includes a shell and utilities of your choice as runtime-depensd.

To test things further I tested the changes in branch of gnome-build-meta. It was pretty boring working through various build failures to get to a new dependency graph, but I came out the other side still convinced that this change is a good idea. (You can see my gnome-build-meta branch here, bearing in mind half the changes are actually dealing with differences between FDSDK 25.08 and ‘master’).

There was some lively discussion on the MR and I’m still not entirely clear if this change is going to land, much as I like it. One sticking point is a fear of landing big changes and not having enough people to deal with the fallout, and as an open source maintainer I certainly know that feeling, so I have more testing planned still.

Another complaint is that this change reneges on the promise from 25.08 about public-stacks/runtime-minimal.bst, that it “is intended to provide a minimal environment that you can shell into.“. You can’t shell into anything if there’s no shell, of course, so I can’t argue with the premise. But I am missing why this is a big deal. I’ve always had a bad time in BuildStream build shells because I just want to edit a file for testing and dammit there’s no Vim or even Vi or even Nano… in fact we don’t even seem to have less?! So I’ve always wanted a way to overlay elements with debug tools in my shell, and it turns out that “bst shell should be able to stage the specified element on top of a base element” is a feature request that’s been open since 2018.

If you use FDSDK as a junction and you like the idea then I’d appreciate comments on the MR. (If you hate the idea, I’m sure you’ve already switched tabs and are half way through posting an irate comment ;-). I am of course prepared for an outcome where this change doesn’t land, and it may indeed lead to some separation of “Linux OS & compiler bootstrap using BuildStream” and “Base Flatpak runtime” into different projects. My gut feeling is that this would be a bit like trying to carve a single grape into two pieces, i.e. there are still few enough people who actually want to maintain build instructions that it makes more sense to collaborate in the same repo.

Thanks as always for reading!

Hello GNOME, This is a progress report on the Pitivi Timeline Ruler Rust rewrite.

Progress

We are rewriting the Pitivi Ruler in Rust and gtk4 snapshot logic to improve performance and memory safety. At its current stage the ruler is being constructed as a standalone widget in a personal repo that can be found here:

Pitivi Timeline Ruler

GTK_DEBUG=interactive cargo run --example sandbox

Any feedback on the code is greatly appreciated!

Structure

I am structuring this around rendering a single interval of ticks between two major ticks once, then stamping that across the duration of the project, as seen in draw_single_interval().

With the ticks stamped across the timeline I am then rendering a cache of Pango labels for the timestamps that are stamped across the visible window. I made the decision to use a BTreeMap for the cache for ease of iterating chronologically through the stamps and for dropping out-of-bounds keys. The logic for this cache handling primarily lives in update_label_cache().

After some feedback from members of the video editing community, I made the decision that minor ticks should always be clean multiples of frames in the time period. This logic is implemented in calculate_minor_divisions().

Next Steps

The primary goal I am focusing on next is implementing the gesture handling, including click and drag actions. Once gestures are implemented I am going to begin moving a lot of the math to traits so that I can write a mock_env and a live_env to start writing some unit testing.

Excited that Bobby has been accepted as a GNOME Circle app!

Screenshot of a SQLite table opened in Bobby Who’s Bobby?

Bobby is a viewer utility. It displays tables from SQLite files. The most deployed database format in the world. That’s it.

Whilst hacking on the backend of Auroras I was missing an easy way to check my data tables. There are many database management tools, but they seemed too heavy for my use case.

GTK4 and Libadwaita

Releasing something smaller first also was a chance to refamiliarise myself with modern GNOME app development. It was my first serious project using Rust.

GTK is still the rock UI toolkit it has always been. Libadwaita makes it easy for your app to look beautiful and is a lot of fun to use.

The main challenge was hooking up the database backend to the ListModel required to be displayed by the new ColumnView. The struggle was worth it though as it enables Bobby to have lazy loading of rows, smooth scrolling, and a limited memory footprint.

After that using any other widget should be a breeze!

Future

I will keep the scope of the app small, but there are a few features I want to add in the future:

• Encrypted file support
• Updating values in place
• Search

Get Bobby on Flathub and always sanitise your database inputs!

One of the great annual trips we do with a bunch of friends is a train trip to Jakuszyce, a tiny stop in neighbouring Poland, and ride along the contour line through one of the most beautiful places in the Jizera Mountains. There's only one proper climb from Smedava to Knajpa, the rest is fast. A joyride. Catching up on our lives on the train and a joyride home is the best combo.

I tend to think of myself as a friend of repairs, of making things last. I have sadly had to retire our washing machine after a good 25 years. The dishwasher before that served us more than 15. A boiler and heater had to go this year after about 20. I had my previous car for 13 years and felt like I was bailing too soon, even though there were quite a few issues with it at the end. None of those things ever felt new to me by the end. They most certainly showed their age.

But the bike. The bike I ride every year on that trip, the one leaning against the wall in the shed right now — it still feels like my "new bike". I replaced the tires and brake pads last year and the thing screams. It is such a joy to ride. It feels current, alive, like something I just picked out. Until a friend sent me a photo his Google Photos app reminded him of. A very young version of myself is sitting on that exact bike. Fifteen years ago. Nothing has aged except me. Bikes just don't age like we do.

Almost exactly three years ago the Oceangate submarine implosion happened. The disaster came about when a billionaire called Stockton Rush created his own unclassified submarine to go sightseeing on the Titanic. Ignoring all advice from experts he created a "macgyveresque death trap" that eventually killed him and sadly also 4 innocent people. The whole thing was a massive display of stupidity and arrogance with unfortunate outcomes. We are not going to go into the actual event any deeper, but those interested can find lots of material online.

Instead we are going to look more deeply into one often overlooked points of Stockton Rush's character. Apparently he felt like he was something of a "new James T. Kirk" (link1 paywalled, link2). Liking Star Trek is not that unusual. I'm guessing that more than 99% of the readers of this blog are fellow Star Trek fans. The problem lies elsewhere, but to understand it we first have travel back in time.

A brief overview of the British navy during the Napoleonic wars (by a non-historian, so probably inaccurate)

The original concept for Star Trek was, approximately, The Adventures of Horatio Hornblower in Space! The Enterprise is basically a British warship sailing through the vast ocean of outer space. The command structure mirrors this, where you have a captain, navigator, ship's doctor and so on. The Next Generation leaned into this even further by having a first officer and so on. The original Star Trek never went into detail on how the main cast got to their current positions, just that there was an Starfleet Academy they went to.

In the Napoleonic era of Hornblower things were quite different. Anyone who wanted to become a captain pretty much had to be from the upper classes. They had to obtain a letter of recommendation so that they could join a vessel as a midshipman at the age of 13 or so. They were expected to be able seamen by this time and then spent the next six to seven years working on the ship rigging sails and doing all manner of random jobs. This went on for six to nine years depending on circumstances, after which the person could take a formal examination to become a lieutenant. The test was not trivial, many people could not pass even after trying multiple times.

A lieutenant then had to work successfully for several years before obtaining the rank of captain. Even that did not guarantee a commission. Some captains never commanded a ship simply because there were not enough of them to go around. All in all becoming a ship's captain was a long and difficult journey. In a surprisingly non-British turn of events it was not possible for aristocrats to sneak past the gates. Getting a midshipman position was obviously easier with connections, but the lieutenant's test was something they had to pass on their own.

All of this is to say that every captain of the time was an expert with decades of working experience on many different positions aboard the ship.

What does a captain actually do?

[Note: I have not fact checked this portion at all. Feel free to consider it fanfiction.]

The year is 1808 and we are aboard a British warship about to leave for a mission of great importance. The captain gives the order to set sail. Whistles are blown, bells are rung and sailors springs into action. Every single man, with one exception, is either doing manual labour or directly supervising their underlings. That exception is the captain, who seemingly stands around doing nothing (at least if you ask the crew). This is not so.

What he is doing is crucial. He is observing the state of the ship and her crew. This includes things like overall crew morale, any aberrations from normal operations that could cause problems, thinking of workflow improvements and so on. In a sense he has to sense the ship itself. This only works because of two things. First of all he has personal experience doing the exact work he is observing. If you have not personally "been there", you can't really know if a crew is working well or not. You need a "gut feeling" to be able to sense this. Secondly the captain does not have any manual labour so he can focus all of his mental energy on observing the ship's state. He is preparing for all the unexpected things that may occur in the future. This can only happen if your brain is free from menial tasks.

This is exactly what most books on business and project management advocate. It is a time tested way of improving your chances of success. A highly skilled commander can take an average team of people and lead them to victory. It is the basic plot of most military and sports movies.

Getting back to the present

Now take a typical modern day billionaire-via-inheritance and show them Star Trek at an impressionable age. Do they see the advantages of education, hard work and ethics? The foundation upon which Gene Roddenberry carefully built the show? Hell no! What they see is this (TNG screenshot used because TOS did not have a suitable maritime episode).

And then they think: "Wow! I want to be exactly like that! Parading around in a funny hat while everyone obeys my orders without question is my life's mission from now on. And I get to have sexy space sex with hot sexy space ladies of sex whenever I want. This appeals to me even more profoundly than Atlas Shrugged." Some of them might go on to watch Master and Commander and shed tears upon realizing that they cant publicly flog employees for failing to salute their superiors. Yet. Expect this to be made legal in Silicon Valley any day now.

Liking Kirk is not in any way a bad thing. Wanting to "be just like Kirk" is, because in the real world running a business like Kirk runs the Enterprise is a terrible way to do things. An example will illustrate this nicely. Let's imagine a random episode where the Enterprise has gotten into trouble. Eventually Kirk will call for Scotty and tell him: "You need to <babble> <babble> <babble>." Scotty will then reply with a varying level of scottish accent something like: "I cannae change the laws of physics, captain". Kirk will then say the same thing again, just more aggressively and in a close up shot. Scotty replies with "Well in that case I can get it done in sixty minutes." Kirk counters with: "You have five." And thus the problem is solved. Kirk gets a commendation for incredible valour under stress while Scotty, who did all of the actual work, is never mentioned.

In "Kirk style" management the Big Boss tells his underlings what to do. If they try to give any sort of feedback, the Boss ignores everything and just repeats his original orders again and again until the other party yields. The only reason underlings ever resist The Vision is that they are lazy and it is the job of the manager to put them in their place. This seems like a bit from a comedy show, but I have unfortunately worked under bosses like this. Either you try to talk at least some sense into them, fail, get labeled as a "not team player", watch the project crash and get blamed for the failure, or you try to do the impossible task given to you, fail watch the project crash and get blamed for the failure.

Another major problem with Kirk is that due to the way tv shows and movies need to be structured, he is actually an obsessive gambler. The stakes must always get higher and the ways to get out of trouble must become ever crazier. Kirk will break any and all laws and regulations he sees fit and then, once he has succeeded, no disciplinary action is taken. The ends justify the means. Idolising this sort of behaviour leads to thinking that wild one-in-a-million gambits will succeed at least 99 times out of a hundred. And even if it fails, you can get out of it by betting everything on an even bigger gamble. The real world does not work like that. Reality is not a story and you are not its hero. It does not owe you eternal, or even eventual, success. Had Stockton Rush survived his death trap, he would most likely have faced criminal charges and, if convicted, gone to jail.

The myth of the existence of the professional manager

Let's make one last detour in the 1800s and assume that the 7th Earl of Sidcup or some such really wants to get his idiot son instated as a captain. He and contacts the appropriate naval officers.

"My offspring needs to become a captain of a ship post haste!"

"Well first he has to become a midshipman and ..."

"Phah! None of that nonsense. It's way too slow and not becoming of my statute. Also my son is 35 years old so the post of a midshipman would be beneath him."

"I see. Well what sort of prior naval experience does he have?"

"None."

"Has he even ever been out to sea?"

"Not to my knowledge. But that does not matter. He is highly skilled in using the abacus excelius to compute annual budgets."

"By himself?"

"Of course not. That is what secretaries are for. He just gives them orders. That he can do. And that is all that matters. Same as in sailing."

This person is unlikely to get his wish with this line of reasoning. On the other hand in modern business life this is common. For example when startups get VC money, a common requirement is that they need to get a "proper manager" as a CEO. Typically this means the investor's friend, and more often than not an MBA.

Contrary to common belief, having an MBA does not make you incompetent at managing a technical company (though there is a strong positive correlation). It is entirely possible to be a good manager on a field you have no personal experience in. You just have to have a lot of humility, listen (actually, properly listen) to your employees and let the people with hands-on experience make the most technical, product and development decisions. In other words you have to be the enabler, not the maverick decision maker. People with these sorts of personality traits are rare and typically their career choices steer as far away from getting an MBA as possible.

The absolute worst thing happens if the CEO in question combines the (lack of) skills of an MBA with the attitude of Kirk. That leads to incompetent decisions based on willful ignorance, executed with the fury of an egomaniac who refuses to even entertain the notion that they might be wrong. Further, any person inside the organisation who dares to point out potential flaws in the plan will soon find themselves outside said organisation. Disagreement is treason. Treason shall not go unpunished.

In the 1800s the British navy could be said to be the best in the world. It seems plausible that one component of this success was the requirement that the officers running their ships had to have actual experience operating the ship. Not looking at other people operating it. Not pretending to read about operating it for a test. Actually doing it. If we look around how MBA wielding sociopath CEOs are enshittifying absolutely everything about the tech industry, bringing this requirement back into active use starts to feel awfully tempting.

Epilogue: Why doesn't everything immediately explode?

A reasonable counterpoint to everything written above would be that if managers truly are that bad, shouldn't all those companies be bankrupt by now? In an ideal world they would be, but there are opposing forces that keep them going.

The first one is that all corporations have inertia. If you took an established major company and actively started to mismanage it to death, it would still take years for things to eventually collapse. 

The second one is a dirty little secret. Many employees care more about the product they work on than "corporate visions" that seem to stem from overuse of peyote. They don't blindly obey idiotic commands but instead try to make things silently work within the system. Basically this means that corporations thrive despite their mad kings, not because of them. I know several people who have worked in these kinds of organizations and this is not as rare of an occurrence as one might imagine.

I have also experienced it personally. Years ago I was at a company, whose CEO (who, to the best of my knowledge, did not have an MBA) wanted to change the company's product so that it would do a specific thing X. Everybody thought this was a horrible idea and tried to reason with him using solid business and technical reasons (which turned out to be 100% correct). That failed. Spectacularly. This lead to an eternal series of secret meetings. The participants were main developers and all managers except the CEO. The only item on the agenda was "How can we make the CEO think that we did what he ordered while doing the exact opposite".

Eventually we did succeed, but boy was that a surreal couple of weeks.