I see a lot of hate about systems and I used to loathe it too.
Then I took a course on systemd specifically and it opened my eyes, and now I'm quite fond about it.
Systemd actually does ONE thing and does it well: it manages the system. It's the missing layer between kernel space and user space. It has quirks and bugs like all software, but I think it works very well, all things considered.
To those who say that it's complex and does a lot of things: it's complex because it does a complex work.
I think you are missing the point: Something like systemd has a good reason to exist. But the devil is in the creating team. We've seen pulseaudio, a good system in theory, but an untrustworthy unstable system in practice. And if it wont work, it is so complicated and non-transparent that you need a specialist. Taking a step backward from Alsa is hard, and they managed to do it.
Now that same team is messing with system critical stuff. We know from the kernel command line debug debacle they rather see the world burn down than admit they did something wrong. They are again creating a super-complicated incomprehensible half- documented mess, that puts it tentacles everywhere. But the stakes are a lot higher.
I am not saying they are incompetent. At a low level, the code works. But at a high level, something is very wrong. Bugs can be fixed, but arrogant architecture astronauts not listening to their users, messing with core infrastructure, that's where systemd keeps failing.
Hence it's pointless because it doesn't make things any simpler. All it does is making things monolithic and wrapping concepts that are perfectly fine by themselves, forcing third-party software to write to systemd's APIs.
> Systemd actually does ONE thing and does it well: it manages the system.
"Managing systems" is not what is meant by "doing one thing, and doing it well". Systemd takes over init scripting, logging, host names, IP, time, locale, and login, plus tens of more services. Making development of this software a Lennart Poettering/RH-only business rather than community-driven.
The trend to get rid of systemd and its metastasis into most of Linux is excellent news. Note that Slackware and Devuan are also systemd-free (and have been from the beginning).
> does ONE thing and does it well: it manages the system
"managing the system" is not "ONE [problem]". A big part of the problem with systemd is this presupposition that management of something as large and complex as a modern OS is a single monolithic[1] problem.
> it's complex because it does a complex work.
See, you agree that it's a complex problem! It's so complex with so many different use cases it isn't even possible to have one solution, because some of those use cases are mutually exclusive. Hench why a modular design is important, so it isn't too difficult to replace the management of different areas if needed.
> It's the missing layer between kernel space and user space.
That "missing layer" isn't well defined. There certainly wasn't any "missing layer" on my old server, or the compute boxen we used at ${research_lab}.
If you're talking about desktop system, I agree that there was a gap between traditional system management and the GUI, but that isn't really a new "layer" between kernal and user space (it might involve GUI userspace programs with perhaps some of them being SETUID or a privileged daemon).
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
I concur with your characterisation of systemd as “doing one thing, and doing it well”. Those who seem to malign it most are those who are, for historical reasons, profoundly conversant with the myriad daemons, configurations, and init systems (generally) of “old UNIX/Linux”. They have a point and a genuine axe to grind, I’ll concede, but systemd is an enormous simplifier for those who are recent to the scene: learn systemd, and you’ve learnt how to manage (most) of your system at a very low level.
The problem is that it comes bundled with a whole bunch of other tools for handling networks, cron, ntp, etc which really ought to be separate projects. By bundling them with the successful init system they're not exposed to the usual Darwinian selection processes that shake out the best free software.
It has it's place but it doesn't work for everyone.
I mean,there's something called user-acceptance testing for software dev lifecycles right? (Not a pro dev myself) systemd obviously has an issue being accepted by a lot of users even after almost a decade now(?)
Even before systemd there were other init systems used by different distros. The fact that systemd demands other things to adopt to it instead od smoothly integrating with existing systmes is one pain. A bigger pain is how it is expected to work well for everyone. I mean, dislike for "one size fits all" solutions is a major reason why most Linux users became Linux users.
As an end user I don't mind SystemD for writing / managing service unit files. I often find the restart policies and one time only jobs useful especially in cloud with automated deployments. My feelings on SystemD as end user are neutral, it does have some useful things but I understand some of peoples grievances with it.
On the other side I have some OpenBSD systems and the simplicity of OpenBSD service management just being plain bash files is really pleasing to use if anything because of the simplicity and power/functionality it provides without actually doing much itself.
It manages the system in a way that not everybody needs or even likes. To the people who hate it, it solves problems that other people have but brings new problems that they now have. It's not so much about if it's good or bad but more about whom it was made for.
No, really. I, the system administrator, manage the system(s). Does Systemd make my life easy ? No, again. It's something I have to deal for. If I could, I would follow the example of Knoppix.
No, systemd does many other things than just managing the system. It provides time, dns, dhcp and other services. None of which is required for achiving what it is suppsed to do: managing unix services.
I used to be a sysadmin. I still hate systemd, and think a lot of who like it are suffering from Stockholm syndrome (joking, maybe :)). It's not that I don't understand it, or use it, because I've been forced to for years. It's that it made everything about my job harder, and abstracts or attempts to abstract everything. As an end user, I get liking it. It's fast, and mostly works. As a person who likes to poke and prod, it's a gross nightmare of inconveniences.
I am a bit surprised that they (seemingly? not clear in the article) went back to sysv init rather than exploring other options. I assume they just wanted to go back to something with which they were very familiar (and for which they probably already had scripts). But after going to void linux, I've found runit [1] to be an excellent init system. I was able to sit down and read the documentation in under an hour and understand exactly how it works and how to add my own services (which is fairly trivial). The programs also seem very thoughtfully developed, taking into account specific circumstances and signals. I encourage others to take a look if you're interested; I believe a number of modern distros have support for using it rather than systemd (I know at least Arch does).
Knopper wrote his own init system called "knoppix-autoconfig" according to DistroWatch. [0] That information is not included in the release notes, though.
As a write once read many system, the abandonment of systemd isn't a big deal I suspect. You don't write to the system area and expect it to persist, and so making modifications to the init system basically isn't going to happen. The modularity doesn't really make as much of an impact then. So any backlash from unhappy users who can't install xyz with one click and have init work properly, not a big deal. Anyone who uses something more complex like an overlay system with it likely has more of an interest in the internals anyway, particularly given the nicheness and age of the distribution.
> If you want to start your own services at startup, you do not need to create any systemd units, but simply enter them in the text file /etc/rc.local, which contains explanatory examples.
Okay, but doesn't that remove a lot of functionality that is available with systemd units? In this whole systemd debate, I've never seen a really clear outline of how much complexity systemd covers, and whether the older alternatives were actually simpler or not. Granted, I haven't looked very hard. I use systemd with Arch and have no known issues with it.
The fact that we're still having _this_ conversation, after after a decade since being released and years after mass adoption, should say a lot. I can't think of any other software I have to use on a daily basis that gets so much heat, every time it comes up. One can make all the arguments for it they want but the continued public comtempt means something.
> One can make all the arguments for it they want but the continued public comtempt means something.
It means that Linux community is full of people that refuse to give up on their gripes even after years. Those also tend to be the people who refuse to understand that "the old way" might not be the best way to do something and also fail to produce a viable alternative.
Linux audio was not usable for end users until PulseAudio stabilised. Init based on scripts was a trash fire. And yet, although SystemD and PulseAudio aren't perfect, noone managed to produce anything comparable except pages and pages and pages of whining.
These people need to let it go. This toxicity is unhealthy and it's just damn software.
Been using systemd since whenever it became the default on Arch. I love it. It just works and I've never had any problems with it. I'd rather use it over any arcane bash-based system any day.
Has anyone here used knoppix (or any other dedicated Live CD) recently?
In the early 2000's, distros didn't have live environments bundled. All debian used to have was a TUI installer and that's it. Ubuntu 4.10+ introduced a live sessions.
From 2004-now driver support and hardware detection has gotten much better. There are live session CD's that include "nonfree" drivers that further improve hardware support. You can pop in most popular distros and easily connect to WiFi and mount drives, often just as easily as knoppix did.
This complaint about systemd isn't a user-related, but the perspective of the live cd creator. Maybe it's true systemd doesn't help that case, but would systemd get in the way of a live cd user though? They're likely not going to be adding/removing/starting/stopping services, setting up users/groups, or anything else that'd be done in a permanent environment.
I wish voidlinux gained more attention from the community and got adapted to serious production stuff. It has all the good elements on paper except the maturity and user base.
Well, systemd is great for responding to events (like devices and networks going up/down) so it seems like a good fit for embedded/IoT. If anything it'd be bad for servers since those are (usually) basically a couple of services and daemons brought up at boot and not changed during runtime, with a few interfaces that never change.
Systemd is not that heavy to run when configured correctly (which is what the distro should do).
When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup
This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
AFAIK, systemd is compatible with sysv init scripts.
> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
Why? Writing one isn't so complicated.
> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.
> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.
> A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it.
The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing.
Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.
So I take it you've never used journalctl then at all? Because seeing as how it's default behaviour is to use the system pager, which on any system with `less` installed is less, I'm somewhat at a loss as to what you can't do with it that you can with files now.
I wish systemd would just die a fiery death. Every two years I replace my environment - by design, to force growth. I've been doing this on Linux since 1993. In my most recent go-around, I hunted for a Unix distribution that could meet my needs, and played with: Void, Solus, Manjaro, Fedora, Tumbleweed, TridentBSD, and GhostBSD. Heck were there docker support on *BSD I'd be back there happily for the first time since 2001.
SystemD needs to die because it violates Unix principles, not because of it's new key combinations. Unix is built on the notion that everything is a file, and that purpose built binaries make sense. SystemD breaks the latter - meaning it's now significantly more work to do the same things when it comes to log investigation, service analysis, and related events.
Perhaps the worst part is the extension of a subsystem for service initialization to everything other than that. The folks at suckless (https://suckless.org/sucks/systemd/) did the argument significantly more justice than I ever could.
It's okay to flaunt your ignorance if you can claim that your peers are ignorant as well, I guess. Knoppix was one of the first, if not the first, popular live CD distributions.
[+] [-] znpy|6 years ago|reply
Then I took a course on systemd specifically and it opened my eyes, and now I'm quite fond about it.
Systemd actually does ONE thing and does it well: it manages the system. It's the missing layer between kernel space and user space. It has quirks and bugs like all software, but I think it works very well, all things considered.
To those who say that it's complex and does a lot of things: it's complex because it does a complex work.
[+] [-] hyperman1|6 years ago|reply
Now that same team is messing with system critical stuff. We know from the kernel command line debug debacle they rather see the world burn down than admit they did something wrong. They are again creating a super-complicated incomprehensible half- documented mess, that puts it tentacles everywhere. But the stakes are a lot higher.
I am not saying they are incompetent. At a low level, the code works. But at a high level, something is very wrong. Bugs can be fixed, but arrogant architecture astronauts not listening to their users, messing with core infrastructure, that's where systemd keeps failing.
[+] [-] tannhaeuser|6 years ago|reply
Hence it's pointless because it doesn't make things any simpler. All it does is making things monolithic and wrapping concepts that are perfectly fine by themselves, forcing third-party software to write to systemd's APIs.
> Systemd actually does ONE thing and does it well: it manages the system.
"Managing systems" is not what is meant by "doing one thing, and doing it well". Systemd takes over init scripting, logging, host names, IP, time, locale, and login, plus tens of more services. Making development of this software a Lennart Poettering/RH-only business rather than community-driven.
The trend to get rid of systemd and its metastasis into most of Linux is excellent news. Note that Slackware and Devuan are also systemd-free (and have been from the beginning).
[+] [-] pdkl95|6 years ago|reply
"managing the system" is not "ONE [problem]". A big part of the problem with systemd is this presupposition that management of something as large and complex as a modern OS is a single monolithic[1] problem.
> it's complex because it does a complex work.
See, you agree that it's a complex problem! It's so complex with so many different use cases it isn't even possible to have one solution, because some of those use cases are mutually exclusive. Hench why a modular design is important, so it isn't too difficult to replace the management of different areas if needed.
> It's the missing layer between kernel space and user space.
That "missing layer" isn't well defined. There certainly wasn't any "missing layer" on my old server, or the compute boxen we used at ${research_lab}.
If you're talking about desktop system, I agree that there was a gap between traditional system management and the GUI, but that isn't really a new "layer" between kernal and user space (it might involve GUI userspace programs with perhaps some of them being SETUID or a privileged daemon).
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
[+] [-] qubex|6 years ago|reply
[+] [-] rwmj|6 years ago|reply
The problem is that it comes bundled with a whole bunch of other tools for handling networks, cron, ntp, etc which really ought to be separate projects. By bundling them with the successful init system they're not exposed to the usual Darwinian selection processes that shake out the best free software.
[+] [-] badrabbit|6 years ago|reply
I mean,there's something called user-acceptance testing for software dev lifecycles right? (Not a pro dev myself) systemd obviously has an issue being accepted by a lot of users even after almost a decade now(?)
Even before systemd there were other init systems used by different distros. The fact that systemd demands other things to adopt to it instead od smoothly integrating with existing systmes is one pain. A bigger pain is how it is expected to work well for everyone. I mean, dislike for "one size fits all" solutions is a major reason why most Linux users became Linux users.
[+] [-] tiew9Vii|6 years ago|reply
As an end user I don't mind SystemD for writing / managing service unit files. I often find the restart policies and one time only jobs useful especially in cloud with automated deployments. My feelings on SystemD as end user are neutral, it does have some useful things but I understand some of peoples grievances with it.
On the other side I have some OpenBSD systems and the simplicity of OpenBSD service management just being plain bash files is really pleasing to use if anything because of the simplicity and power/functionality it provides without actually doing much itself.
[+] [-] einpoklum|6 years ago|reply
Yeah, except that the "one thing" it does is "everything".
[+] [-] std_throwaway|6 years ago|reply
It manages the system in a way that not everybody needs or even likes. To the people who hate it, it solves problems that other people have but brings new problems that they now have. It's not so much about if it's good or bad but more about whom it was made for.
[+] [-] gabrielblack|6 years ago|reply
No, really. I, the system administrator, manage the system(s). Does Systemd make my life easy ? No, again. It's something I have to deal for. If I could, I would follow the example of Knoppix.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] devit|6 years ago|reply
[+] [-] crb|6 years ago|reply
[+] [-] StreamBright|6 years ago|reply
[+] [-] znpy|6 years ago|reply
Knoppix is a live system, so all of the things systemd was designed for don't apply. I guess it can make sense for their knoppix's use case.
[+] [-] axaxs|6 years ago|reply
[+] [-] afranchuk|6 years ago|reply
[1]: http://smarden.org/runit/
[+] [-] sverige|6 years ago|reply
[0] https://distrowatch.com/index-mobile.php?distribution=knoppi...
[+] [-] Arbalest|6 years ago|reply
[+] [-] tejohnso|6 years ago|reply
Okay, but doesn't that remove a lot of functionality that is available with systemd units? In this whole systemd debate, I've never seen a really clear outline of how much complexity systemd covers, and whether the older alternatives were actually simpler or not. Granted, I haven't looked very hard. I use systemd with Arch and have no known issues with it.
[+] [-] tdewitt|6 years ago|reply
[+] [-] izacus|6 years ago|reply
It means that Linux community is full of people that refuse to give up on their gripes even after years. Those also tend to be the people who refuse to understand that "the old way" might not be the best way to do something and also fail to produce a viable alternative.
Linux audio was not usable for end users until PulseAudio stabilised. Init based on scripts was a trash fire. And yet, although SystemD and PulseAudio aren't perfect, noone managed to produce anything comparable except pages and pages and pages of whining.
These people need to let it go. This toxicity is unhealthy and it's just damn software.
[+] [-] iikoolpp|6 years ago|reply
[+] [-] tony|6 years ago|reply
In the early 2000's, distros didn't have live environments bundled. All debian used to have was a TUI installer and that's it. Ubuntu 4.10+ introduced a live sessions.
From 2004-now driver support and hardware detection has gotten much better. There are live session CD's that include "nonfree" drivers that further improve hardware support. You can pop in most popular distros and easily connect to WiFi and mount drives, often just as easily as knoppix did.
This complaint about systemd isn't a user-related, but the perspective of the live cd creator. Maybe it's true systemd doesn't help that case, but would systemd get in the way of a live cd user though? They're likely not going to be adding/removing/starting/stopping services, setting up users/groups, or anything else that'd be done in a permanent environment.
[+] [-] reacharavindh|6 years ago|reply
[+] [-] AndrewDavis|6 years ago|reply
[+] [-] einpoklum|6 years ago|reply
And by the way - if you're doing something Debian-based - make it Devuan-based, it's pretty straightforward. http://www.devuan.org/
[+] [-] johnr2|6 years ago|reply
It's also pretty straightforward to switch Debian systems back to sysvinit.
[+] [-] mobilio|6 years ago|reply
But i was seeing that in Embedding Linux or IoT distributions that doesn't make sense since they're run on limited resources.
[+] [-] SahAssar|6 years ago|reply
Systemd is not that heavy to run when configured correctly (which is what the distro should do).
[+] [-] SSLy|6 years ago|reply
[+] [-] einpoklum|6 years ago|reply
[+] [-] doiwin|6 years ago|reply
When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
[+] [-] eythian|6 years ago|reply
This is fine, but you do have to accept that things are going to move on without you.
[+] [-] Znafon|6 years ago|reply
This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
[+] [-] soraminazuki|6 years ago|reply
AFAIK, systemd is compatible with sysv init scripts.
> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
Why? Writing one isn't so complicated.
> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.
> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.
[+] [-] madhadron|6 years ago|reply
Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it.
The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing.
Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.
[+] [-] XorNot|6 years ago|reply
[+] [-] darpa_escapee|6 years ago|reply
Then just use cron.
[+] [-] didip|6 years ago|reply
[+] [-] tdewitt|6 years ago|reply
[+] [-] narnianal|6 years ago|reply
[deleted]
[+] [-] gridlockd|6 years ago|reply
[+] [-] cik|6 years ago|reply
SystemD needs to die because it violates Unix principles, not because of it's new key combinations. Unix is built on the notion that everything is a file, and that purpose built binaries make sense. SystemD breaks the latter - meaning it's now significantly more work to do the same things when it comes to log investigation, service analysis, and related events.
Perhaps the worst part is the extension of a subsystem for service initialization to everything other than that. The folks at suckless (https://suckless.org/sucks/systemd/) did the argument significantly more justice than I ever could.
[+] [-] Svoka|6 years ago|reply
[+] [-] mepian|6 years ago|reply
[+] [-] esotericn|6 years ago|reply