I use Artix Linux with runit and am happy. Artix offers multiple init systems other than systemd. If you're familiar with using Arch Linux, basically Artix is the same without systemd.
You can install the various ISOs and see the differences for yourself, but the complaints launched against systemd that have any validity are either technical and/or philosophical in nature.
In a lot of ways, systemd has become like the JavaScript of init systems in that it handles a lot more than what it originally was needed for (init starts other processes after boot, JavaScript adds small amounts of interactivity to web pages).
As opposed to what each became (systemd now handles DNS, cron, bootloader, and is a suite of tools tightly coupled with the init system) (JavaScript has now become a scripting language with access to the C level exec library to the point where an OS can and has been written in it).
In the early days of systemd adoption, there was much controversy over its seemingly sudden mass adoption. SysV init needed a modern replacement, and indeed, alternatives like Upstart, openrc, and others were in production to eventually replace it. Lennart Poettering and Kay Sievers over at Red Hat created and heavily promoted systemd.
Lennart was already somewhat beloved/hated in the community as he had developed PulseAudio, which was a boon over the previous Alsa implementation, but was considered bloated and unnecessary by the less audio oriented Linux users of the time. He was inspired to create systemd after researching Apple's new init implementation, launchd.
Controversy spread as Lennart would dismiss adoption of systemd into the BSD family of UNIX like OSes. He also dismissed competitors like Upstart, as their implementation of certain modern features like CGroups was not as developed as systemd at the time. Additionally, Linux users at the time were heavily concerned that Red Hat was trying to take over the entirety of the Linux space, enforcing a more corporate and commercial influence on what had previously been a community more in line with the aims of the FSF.
Much of this culminated in a months long email exchange on the Debian email list, where many of these grievances, pros and cons of systemd adoption, and overall discourse around this topic took place in 2013-2014. Eventually the result was that Debian adopted systemd as the default init system, which along with Fedora, Arch, and other distros, sealed the fate of other alternative init systems as being fringe, out of date, and irrelevant.
More and more system admins would learn the ins and outs of systemd as it would become required for their jobs, and the criticism of systemd became more and more quiet as it just became part of the every day Linux experience.
Truth be told, the birth of systemd really heralded in the death of the UNIX philosophy as an old way of thinking about software development and program scope. Doing one thing only, and doing it well, while looking good on paper, and oftentimes is a good general rule of thumb, doesn't apply to modern application development, for better and worse.
I personally like runit not for its speed, but for its simplicity. I can peruse the C code in an afternoon and appreciate it for what it is, an init system. I can't say the same when I look at systemd's code.
But most could care less. As long as it works. And all the power to them...
It does surprise me somewhat, however, that Linux users will condemn bloated browsers, electron apps, and text editors, but will give a pass to systemd, which holds so much more importance over whether pid 1 even launches and starts user space.
systemd has become like the JavaScript of init systems
Likening systemd to JavaScript is incredibly inappropriate.
systemd now handles DNS, cron, bootloader, and is a suite of tools tightly coupled with the init system)
No.
Except for the cron replacement, all of those are stand-alone tools that can be run with systemd, without systemd or replaced with any alternative.
They just happen to be developed under the systemd project umbrella and are obviously tested to work well with another.
This argument is especially weird for systemd-boot; it's not even a Linux program ffs.
There are some components that are harder to replace with alternatives but mostly because no good alternatives exist.
Systemd might be partially to blame here in how easy it is those parts can be ran independently and replaced with equals and you could certainly criticize it for that but you didn't even mention one of them.
Truth be told, the birth of systemd really heralded in the death of the UNIX philosophy
There is no truth in this sentence.
Doing one thing only, and doing it well, while looking good on paper, and oftentimes is a good general rule of thumb, doesn't apply to modern application development, for better and worse.
What? Please google "Microservices".
Your whole wall of text hinges on the assumption that systemd is a simple "init system"; a root process spawning a set of other processes.
This is false.
systemd (as in: PID1) does service management, not init.
It happens to also fit into the "job description" of init because starting and cleaning up dead services also fall under the responsibility of a service manager but reducing it to just an init system is just plain wrong.
All the other things are handled by separate components/processes.
Thus, it still follows the "unix philosophy".
The "one thing" it does simply isn't what you think it does.
It's like saying cp doesn't follow the UNIX philosophy because you could copy files with cat.
cat is soo much simpler to understand, why would anyone ever use the bloated cp?
Must be the pesky commercial influence of Bell labs!
Truth be told, the birth of cp really heralded in the death of the UNIX philosophy.
I use Artix Linux with runit and am happy. Artix offers multiple init systems other than systemd. If you're familiar with using Arch Linux, basically Artix is the same without systemd.
You can install the various ISOs and see the differences for yourself, but the complaints launched against systemd that have any validity are either technical and/or philosophical in nature.
In a lot of ways, systemd has become like the JavaScript of init systems in that it handles a lot more than what it originally was needed for (init starts other processes after boot, JavaScript adds small amounts of interactivity to web pages).
As opposed to what each became (systemd now handles DNS, cron, bootloader, and is a suite of tools tightly coupled with the init system) (JavaScript has now become a scripting language with access to the C level exec library to the point where an OS can and has been written in it).
In the early days of systemd adoption, there was much controversy over its seemingly sudden mass adoption. SysV init needed a modern replacement, and indeed, alternatives like Upstart, openrc, and others were in production to eventually replace it. Lennart Poettering and Kay Sievers over at Red Hat created and heavily promoted systemd.
Lennart was already somewhat beloved/hated in the community as he had developed PulseAudio, which was a boon over the previous Alsa implementation, but was considered bloated and unnecessary by the less audio oriented Linux users of the time. He was inspired to create systemd after researching Apple's new init implementation, launchd.
Controversy spread as Lennart would dismiss adoption of systemd into the BSD family of UNIX like OSes. He also dismissed competitors like Upstart, as their implementation of certain modern features like CGroups was not as developed as systemd at the time. Additionally, Linux users at the time were heavily concerned that Red Hat was trying to take over the entirety of the Linux space, enforcing a more corporate and commercial influence on what had previously been a community more in line with the aims of the FSF.
Much of this culminated in a months long email exchange on the Debian email list, where many of these grievances, pros and cons of systemd adoption, and overall discourse around this topic took place in 2013-2014. Eventually the result was that Debian adopted systemd as the default init system, which along with Fedora, Arch, and other distros, sealed the fate of other alternative init systems as being fringe, out of date, and irrelevant.
More and more system admins would learn the ins and outs of systemd as it would become required for their jobs, and the criticism of systemd became more and more quiet as it just became part of the every day Linux experience.
Truth be told, the birth of systemd really heralded in the death of the UNIX philosophy as an old way of thinking about software development and program scope. Doing one thing only, and doing it well, while looking good on paper, and oftentimes is a good general rule of thumb, doesn't apply to modern application development, for better and worse.
I personally like runit not for its speed, but for its simplicity. I can peruse the C code in an afternoon and appreciate it for what it is, an init system. I can't say the same when I look at systemd's code.
But most could care less. As long as it works. And all the power to them...
It does surprise me somewhat, however, that Linux users will condemn bloated browsers, electron apps, and text editors, but will give a pass to systemd, which holds so much more importance over whether pid 1 even launches and starts user space.
Let the downvoting commence.
Likening systemd to JavaScript is incredibly inappropriate.
No. Except for the cron replacement, all of those are stand-alone tools that can be run with systemd, without systemd or replaced with any alternative.
They just happen to be developed under the systemd project umbrella and are obviously tested to work well with another.
This argument is especially weird for systemd-boot; it's not even a Linux program ffs.
There are some components that are harder to replace with alternatives but mostly because no good alternatives exist. Systemd might be partially to blame here in how easy it is those parts can be ran independently and replaced with equals and you could certainly criticize it for that but you didn't even mention one of them.
There is no truth in this sentence.
What? Please google "Microservices".
Your whole wall of text hinges on the assumption that systemd is a simple "init system"; a root process spawning a set of other processes. This is false.
systemd (as in: PID1) does service management, not init. It happens to also fit into the "job description" of init because starting and cleaning up dead services also fall under the responsibility of a service manager but reducing it to just an init system is just plain wrong. All the other things are handled by separate components/processes.
Thus, it still follows the "unix philosophy". The "one thing" it does simply isn't what you think it does.
It's like saying
cp
doesn't follow the UNIX philosophy because you could copy files withcat
.cat
is soo much simpler to understand, why would anyone ever use the bloatedcp
? Must be the pesky commercial influence of Bell labs!Truth be told, the birth of
cp
really heralded in the death of the UNIX philosophy.deleted by creator
Hyperbola has the best vision for a clean and libre general-OS.
Yes, they very strict about the interpretation of "libre", but that makes the vision pure and crystal clear.
Gentoo took the (imo) correct approach by providing users choice as well.