Tobias Hunger

Yeap, you now get logs from all stages of the boot process, and you notice logs going bad or getting manipulated. It’s a huge step forward for Linux, especially for people that look at logs every day. They can finally trust the logs to be correct and complete.

And it is not even a change: I have never had real unix servers with plain text logs in 30 years working with them. Proper computers have always stored logs in databases or whatever. That’s actually a legal requirement in many parts of the world for many kinds of servers.

Just use a distribution that uses the init system you want to test by default. The init system is a pretty central piece of infrastructure in todays unix, ditsributions need to invest a lot of effort to make it work well. The default init system always works better than any other options a distribution offers (if they even over options).

There are significant security/reliability improvements all over the place. E…g. logind actually works as promissed, which none of the clones do as they can not have the necessary infrastructure that is provided by other parts of systemd. Or udev using systemd-pid1 to start services: That fixes a well documented problem with udev starting services itself – which most non-systemd distributions do till today. Problems do notngo away by ignoring them.

Checkout non-systemd distros, most of them still use group based access to devices a user needs to run wayland. Of course that does not matter at all for X11, security is so poor there anyway.

These comparisons assume the systems do the same thing, resulting in a comparable system once everything is up and running.

That is just not the case. Systemd does a ton more wrt. security, hardening and reliability. E.g. it has udev integrated and not running “stand-alone” since it tends to lock itself up when it needs to start long-running services in response to HW showing up. Yes that happens rarely but there is nothing you can do about it. Logind locks down permissions to HW way more tightly than the “forks” that have the same problems that the pre-logind system had – and that led to logind getting developed in the first place. Lots of sandboxing options are built into systemd and widely used to run services (I rarely saw any sandboxing elsewhere so far out of the box), measured boot is pretty much a systemd-only thing at this time, … .

How does systemd dare to provide useful functionality? It should be just as useless as all the other inits that nobody ever felt the need to depend on, simply because they do nothing interesting.

You can just build a way more functional and secure system with all the cool features systemd provides.

Filesystem enable age verification in pretty much the same way as systemd does: You can optionally store a user’s birthday. That is such a ridiculous statement.

To be fair: None of the other inits cared for udev. None contributed or helped by providing features they wanted to improve udev. The systemd devs care for the lower level plumbing overall… and not just for the init system. So it is very natural for low level plumbing projects to land under the systemd umbrella today.

Systemds track record wrt. security flaws is actually pretty good. Not many went through the cracks,maven though some were indeed pretty ghastly. Hardly any was in the core functionality, most were in new code not widely used yet.

On the other hand, the service hardening that systemd enables has improved the overall security of a typical Linux system by quite a lot.

What you can expect when switching from a system management tool written for Linux to an init tool targetting the least common denominator of general Unix functionality?

Less functionality, less security, less information about the state the system is in, less reliable switching between states and a whole lot less of linux kernel features exposed to your use in convenient ways.

It’s not as if systemd was started to be complicated, the world got complicated. E.g. we used to just create all the device nodes in /dev statically during system installation. Then USB became a thing and supported so many different kinds of devices with thousands of potential ports to connect them to. They would not fit into the device node namespace! So we needed to make device nodes dynamic, which is also convenient.You do not have lots of device nodes that do not exist on your system and you no longer need to change system configuration when you plug your mouse into another port of your system.

Filesystems, security (often linux specific) features, everything is easy more complex (and more dynamic) today than it was when sysv init was a thing. That simple stuff was great when you had to power off your machine to change its available devices. It is less cool when you plug an USB-C cable into your laptop and want to use all the stuff that is now suddenly available.

Immutable distros are the future for everything. We just need to wait a for the people most heavily invested into the status quo to retire.

Any user can delete important OS files by turning their computer off while an upgrade is running in almost all traditional distros:-) Sure, you can disable updates, but that is not an option either.

First off, you do not need to know most of that stuff. Tooling around container-based development is really nice nowadays. It just works almost all the time – and way more often than in mutable setups.

As a beginner you can not really transfer docs from one distribution to another, so you look for docs on your distribution and ask in the official support channels. Those of bazzite are pretty responsive and will be able to help. The community is able to help way better than in a traditional system where every installation is almost but not exactly the same.

Nothing is as bad as accidentally removing some important OS files and not knowing how to restore them. That will just not happen in an immutable setup.

I have installed immutable distros on lots of computers and the users usually are happier than they were on traditional linux: Nothing breaks anymore, the setup is way more solid. Its great for me, too, as I need to support them less often.

Seriously, you should give this a try: Immutable OSes are a huge step forward. Takes a few days to get used to, but I am pretty sure you will not want to go back afterwards.

The OP has no experience with either immutable nor mutable linux. So let him go with the rubust version already installed over recommending some package-based, old-school distro, just because you are more familiar with those.

OP will need to learn things either way, let him learn the future proof stuff, not the outdated ways.

Actual developer and 30+ years Linux expert.

Don’t use anything but immutable distros for development work. Hands down.

Just develop in containers and have one container per project. Doing anything else will lead to broken projects as you can not properly control dependencies per project otherwise.

It is not harder to work in a container than on the real system.