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.
"Nothing on this page asks for your faith.", immediently followed by a whole list of "trust me" (to manage the keys correctly, that the person notices the keys getting stolen, that she manage the entire signing process correctly, ...). No HW is used that could make it harder to steal keys, just some offline USB storage and a password manager. Every mainstream distro does way better than this, incl. Void linux this is based on.
No systemd with all the security improvements that brings either, but I guess that will bring in a small fan base:-)
Systemd said on its first website that its a system management daemon. That is where the name came from. It was never supposed to be just an init system.
No need to buy out udevd, considering the guy doing that was on board with systemd from the start and made sure that systemd-init can make maximum use of udev and the other way around... you typically do want to start stuff in response to hardware appearing and disappearing. Now they can do that safely by just asking systemd-init to manage the services. They needed to run stuff thenselves before, which pretty often ended up blocking the udev daemon from recognizing new events... a quality of live improvement for everybody involved:-)
The rest has similar stories (only run network services when the network is up, start services only after the system clock has a sane value over starting the service and then adjusting the time at some later point (which some services handle really poorly), ... . There are some damn good reasons for the stuff systemd does. That bootloader is a pretty central piece in the image by the way.
Oh, and did I mention that anyone using or talking about non-systemd methods of doing things tends to get painted as "oh that's OLD and OUTDATED and OBSOLETE, just use the systemd way it's Modern™ and good"?
That is pretty much the only thing I can agree with:-) And that is because the systemd ways are ofentimes way more robust and able to deal with corner cases way better.
Either you build a tool that works well with one OS or you build one that works poorly with several.
And it is not as if those other OSes are waiting for new cross-OS init tools: They either seem to be happy with what they got or want something tailored to their own features.
To be fair: Free software projects were and also are dying from lack of ownership.
And the existing free software projects tend to be old and make it really hard for young people to join IMHO. They avoid the popular (and proprietary) stuff, which makes them hard to discover and their processes seem archaic.
When going so far back: Please do not leave out the FL part of FLOSS. Free/Libre software kicked this all off, the OSS is a later attempt to "sell" the development process FL software came up with to companies, stripping out all the pesky ideas about society benefiting for moving all the benefits over to the companies using OSS. Free/libre softwsre and OSS are technically the same, but the idea behind the licenses are so very different: Free/libre software wsnt to give rights to end users, OSS cares about the freedom of the developers between yourself and end users -- giving the companies the right to commercialize your work for you.
The moment you stop caring for the social and societal aspects of software, it becomes OK to host on a proprietary service. That was never the case for the free/libre parts of our community. Those projects tend to shun proprietary services like discord, github and stuff. Pretty old fashined... not very sexy for young devs:-(
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.
You do not even need to patch it out. It is basically an extra entry in the user db (think: /etc/passwd). Just don't fill it in and you are done, just like your location and a ton of other stuff you can put there if you want to.
Nobody can read it outside your system either... it's a defined place when (not if -- not anymore) something wants to store that information. Better have a properly protected defined place ready than have 10 different programs request that info separately and store it all over the place.
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.
The security theater is strong in this one.
"Nothing on this page asks for your faith.", immediently followed by a whole list of "trust me" (to manage the keys correctly, that the person notices the keys getting stolen, that she manage the entire signing process correctly, ...). No HW is used that could make it harder to steal keys, just some offline USB storage and a password manager. Every mainstream distro does way better than this, incl. Void linux this is based on.
No systemd with all the security improvements that brings either, but I guess that will bring in a small fan base:-)
I doubt they were the first to built such a system. The idea is pretty obvious after all.
They just are the first to give reporters a guided tour of the system and test accounts to play with.
You said Lennart is obnoxious and there is nothing like a big "that is not my problem" to not get your project adopted.
IMHO he does manage to get his projects widely adopted. His personality does not seem to have the effect you claim it has.
Systemd said on its first website that its a system management daemon. That is where the name came from. It was never supposed to be just an init system.
No need to buy out udevd, considering the guy doing that was on board with systemd from the start and made sure that systemd-init can make maximum use of udev and the other way around... you typically do want to start stuff in response to hardware appearing and disappearing. Now they can do that safely by just asking systemd-init to manage the services. They needed to run stuff thenselves before, which pretty often ended up blocking the udev daemon from recognizing new events... a quality of live improvement for everybody involved:-)
The rest has similar stories (only run network services when the network is up, start services only after the system clock has a sane value over starting the service and then adjusting the time at some later point (which some services handle really poorly), ... . There are some damn good reasons for the stuff systemd does. That bootloader is a pretty central piece in the image by the way.
That is pretty much the only thing I can agree with:-) And that is because the systemd ways are ofentimes way more robust and able to deal with corner cases way better.
Considering how widely Lennarts code got adopted: You must be missing something.
Either you build a tool that works well with one OS or you build one that works poorly with several.
And it is not as if those other OSes are waiting for new cross-OS init tools: They either seem to be happy with what they got or want something tailored to their own features.
Ok, thanks for the summary.
Anything that is cool/unusual/noteworthy about it?
To be fair: Free software projects were and also are dying from lack of ownership.
And the existing free software projects tend to be old and make it really hard for young people to join IMHO. They avoid the popular (and proprietary) stuff, which makes them hard to discover and their processes seem archaic.
When going so far back: Please do not leave out the FL part of FLOSS. Free/Libre software kicked this all off, the OSS is a later attempt to "sell" the development process FL software came up with to companies, stripping out all the pesky ideas about society benefiting for moving all the benefits over to the companies using OSS. Free/libre softwsre and OSS are technically the same, but the idea behind the licenses are so very different: Free/libre software wsnt to give rights to end users, OSS cares about the freedom of the developers between yourself and end users -- giving the companies the right to commercialize your work for you.
The moment you stop caring for the social and societal aspects of software, it becomes OK to host on a proprietary service. That was never the case for the free/libre parts of our community. Those projects tend to shun proprietary services like discord, github and stuff. Pretty old fashined... not very sexy for young devs:-(
We said the same about memory safety: That's something a compiler can not solve. Now it does.
It is nice to see that sometines things do improve.
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.
What did you write to the lawmakers in California?
You do not even need to patch it out. It is basically an extra entry in the user db (think: /etc/passwd). Just don't fill it in and you are done, just like your location and a ton of other stuff you can put there if you want to.
Nobody can read it outside your system either... it's a defined place when (not if -- not anymore) something wants to store that information. Better have a properly protected defined place ready than have 10 different programs request that info separately and store it all over the place.