

Gotta love Linux newbies talking about their first experiences and they’ve already tried 3 distros that I have barely on my radar. A few months in, I hardly knew what SystemD was and this guy’s already on a distro that explicitly removes it.


Gotta love Linux newbies talking about their first experiences and they’ve already tried 3 distros that I have barely on my radar. A few months in, I hardly knew what SystemD was and this guy’s already on a distro that explicitly removes it.


If you prepare an installation USB stick, so-called “Live-USB”, and select in the BIOS that it should boot from that, then you can test-drive Linux before you install it.
There is more details involved, like you may need to turn off Secure Boot in the BIOS, but yeah, point is, you don’t have to commit to Linux to try it.
Yeah, my current software project at work was basically half a year of feature development and since then, we’ve purely tried to get it into the real world, which meant evaluating use-cases to see where it falls flat and what needs stabilizing, as well as figuring out people’s needs and how our software can assist with that, then setting up a demo and hoping they find money somewhere…


My problem was that “Albert Heijn” is a dude’s name. It does not exactly scream “we’re talking about a real physical building”.
For all I knew, the impossible problem we’re solving could’ve been on a mathematical plane, named after mathematician Albert Heijn. “Sweeping” just as well can be used in an abstract sense.
Obviously, I did think of physically sweeping a physical floor first and foremost, but especially with the rest of the blog post being so entirely abstract, I had doubts on that for far too long, which did not make it easier to understand.


Probably could’ve mentioned at some point in that whole article that Albert Heijn is a supermarket chain: https://en.wikipedia.org/wiki/Albert_Heijn


Yeah, they’re really dropping the ball here on the important stuff…


F-Droid blog post on the topic: https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html
It was posted before Google backpedalled somewhat, if I remember correctly.


Yeah, from what I understand, countries try to regulate the use of antibiotics, so that we don’t blow the most potent ones, a.k.a. new ones, right away. But on some level, we’re reliant on regularly discovering new antibiotics, which isn’t great.


and the superbugs that might breed aren’t viable in humans.
But diseases jump from non-humans to humans all the time?
At least, Wikipedia chooses to spell out the sentence “Most human diseases originated in non-humans” and lists a who’s who of pandemics as such: https://en.wikipedia.org/wiki/Zoonosis
Or do you mean something different?
Yeah, the latter is certainly a big part of it. The way to make it compile-safe is to use macros to generate code, so that my users can write e.g. Package::my_frontend.version and that gives them the version of their frontend package.
Writing such macros, i.e. writing code to generate code, is certainly something I haven’t done a ton of yet, because you practically cannot justify doing that in an application codebase, only in a library, so it is new stuff that I learn.
But well, you did already call it a “nice abstraction”, which is another big part where my excitement comes from and where I think, the special nerdery is necessary.
Others might build projects which are visually tangible, like a sexy GUI, or which do something tangible, for example a colleague (who I will absolutely not deny his own special nerdery) is currently building a driver for a motor. If that driver works, you can see a motor moving in the real-world. Even non-nerds can at least tell that something is happening.
But with my project, my success is that you can write Package::my_frontend instead of Package::from_str("my_frontend")?. And that if you rename the package to super_duper_frontend, that the compiler will tell you to fix the code rather than it only breaking once you actually run the build code for the frontend.
No chance of explaining to non-coders why this is exciting or even just when you’re successful.
On Monday, one of our students at $DAYJOB asked me what projects I do in my freetime. After I infodumped on her for half an hour, she asked in disbelief “And you do these in your freetime, without being paid?”.
Like, mate, did you not listen how feckin’ excited I got just then? Of course, I do these in my freetime.
To be fair, though, the last project I told her about is very dry. It’s a library to help automate CI builds. And the thing I’m thrilled to build is a compile-safe API for accessing the packages in your workspaces. Like, yeah, it does take a special kind of nerd to get excited about that…
Pretty sure, people drawing for commissions would typically use a drawing tablet… ^^’
I mean, Rust does have a pretty inclusive community…


In many cases, you don’t need an equivalent to finally, because the cleanup is automatically handled via the Drop trait, which runs cleanup code when the object is freed from memory (similar to “destructors” in some other languages).
Because of Rust’s whole ownership thingamabob, it’s generally entirely deterministic when this code will run (at the closing brace for the scope in which the object is defined, unless you pass that object outside of that scope).
In other cases, you don’t need a finally, because nothing forces you to bubble up errors instantly. You can make a call which fails, store the error in a variable, run your cleanup steps and then return the error at the end of you function.
Sometimes, however, you do want to bubble up errors right away (via ? or early return), typically so you can group them together and handle them all the same.
In that case, you can run the cleanup code in the calling function. If you don’t to want to make it the responsibility of the caller, then pull out a small function within your function, so that you become the caller of that small function and can do the cleanup steps at the end of your function, while you do the bubbling within the smaller function.
There’s also ways to make that less invasive via closures (which also serve as a boundary to which you can bubble errors), but those are somewhat complex in Rust, due to the whole ownership thingamabob.
I will say, I do sometimes feel like Rust could use a better way to handle doing something before the error bubbles up. But generally speaking, I don’t feel like a finally is missing.


You can use the anyhow crate for something quite similar to exceptions: https://crates.io/crates/anyhow
In terms of how it actually fits into Rust, you want to use anyhow for application code. If you’re writing a library, then anyhow is a no-go, because users cannot match on different error classes with it. (Much like you would want custom exception classes, so that users can catch them in different catch branches and handle them differently.)
Every so often, you will also need matchable error classes within your application code, then you would have to replace anyhow with a custom error type there, too, of course.
I will also say, IMHO it is fine to use anyhow even while you’re learning Rust. It is so easy that you kind of skip learning error handling, which you will need to learn at some point, but you can still do that when you actually need it.


I’m guessing, those people are worried that it will be removed. It’s already somewhat on the line since Wayland started replacing X11, because individual desktop environments can now decide to implement it or not.
Ah, I think, I know what you mean, that the format is supposed to be written with foolish oversimplifications that are borderline incorrect, whereas “secured by TLS” just sounds like a normal statement from an expert…
I’m guessing that was supposed to be “secured by a thin layer of TLS”…
At its core, SystemD coordinates and launches all the services in your operating system. So, it is essential for the boot process, but also does scheduling, meaning you could run a backup script every night with it, for example.
That’s the simple answer. But in truth, SystemD is often criticized for doing too much, so it’s hard to describe what it really does. For example, you can also manage network interfaces via SystemD.
Kind of the goal of SystemD is to provide common plumbing which works the same across distros, so that when you configure your services or network interfaces etc. on Ubuntu, it works the same as on openSUSE or Arch or whatever.