it is definitely a question of power. had a debian based device because it was plugged into mains and needed to do a lot of tasks. i also had a yocto based system that ran on solar pannels and scavenged power from vibrations of the pipes the computer was attached to. power and resources setting limits on what i was running.

like the idea, trying it out. my wife already hates my phone.

it’s honestly not that niche. it’s just not a use case that hobbiest run into. there is a lot of devices in your house or in your life running linux and you just never think about it. none of the devs of these devices are loud about systemd because we are hand crafting distros ourselves so dealing with scripts in an init system is the least of our worries.

I have worked on gas meters for your house, refridgerators, two way radios for your car, home automation systems, TVs, gas pumps, A/C controllers. All hand crafted, tiny distros, all things you never see a penguin on but still run linux.

Systemd has stable API

yes, now it does as an afterthought. it wasn’t a public standard, seeking comment. no taking input from other developers. systemd was created to solve a problem distro were having, a system manager that is plug and play and makes everything just work. it is a good problem to solve, it’s one of the few reasons that so many distros exist.

But there are tons of design choices that had very narrow views. Polkit, logind and the rest of credential management come to mind as something that needs a lot of massaging if you are rolling your own distro. When running a non-systemd distro there are often pain points getting apps and services that need to have a wider reach or interact with other priviledged code. none of it makes the system any more secure, just more of a pain in the ass.

For me the portability issue wasn’t really solved. I still work on embedded devices where I need to squeeze out every cycle and every byte of memory i can. Running systemd is an automatic no go, but in the *nix way of doing things I do have other options, so that’s good.

But the more people depend on the systemd ecosystem rather than an open standard, the availability for me to use other projects goes down. Again there are usually options, but it’s sad to see no one really thought about that when everyone jumped on board.

I also love the BSDs and other Unix systems. I remember decades ago downloading FreeBSD on my Gentoo box and was able to load the same Gnome desktop on both systems. Two totally different operating systems running the same UI. It sucks that targeting systemd might make software not run on other *nix operating systems

you know they hacked their pants to be like the self tying shoes from Back to the furture. Pants unzip, pinch ya off, pull ya back in, zip up, unzip again and pull ya back out all from a single sh file.

The issue is two fold.

First the scope of the project is very important. When I am working on a web app the most complicated project is still 90% boilerplate stuff. You write some RESTful code on some framework using CRUD and make a UI that draws based on data. No matter what you are making, lets be honest, it’s not novel. This is why vibe coding can exist. Most of your unit tests can be derived from the types in your functions. Do a little bit of tracing through functions and AI can easily make your code less fragile.

When you are working on anything more complicated making code better requires you to actually grok the business requirements. Edge cases aren’t as simple. The reasons for doing things a specific way aren’t so superficial. Especially when you start having to write optimizations the compilers don’t do automatically.

The second issue is learning matterial. The majority of the code we write is buggy. Not just in range testing but in solution to problems. There is a reason why we don’t typically write once and never go back to our code.

Now think about when you, as a human, go back over old code. The commit log and blame usually don’t give a great picture of why the change was needed. Not unless the dev was really detailed in their documentation. And even then it requires domain knowledge and conceptualization that AI still can’t do.

When teaching humans to be be better at development we suck at it even when we can grok the language and the business needs. That is a hurdle we still need to cross with AI.