Suggesting to tag this as a rant. There’s not a lot of technical discussion here, and what little there is primarily serves to support the author’s personal views on OS design.
I’m not an expert on linux, but as a developer who dabbles with it, systemd is awesome. Things feel much more consistent and discoverable. The services part alone, with cron and process monitoring features is great. No more need for init scripts, I can just stick a shell script into a service and a timer and call it a day.
I’ve adminned Linux machines on a small scale (home/hobby, and a small web hosting company back in the days when servers were pets, not livestock) for over 20 years, and systemd has been absolutely a blessing to me in every way. Setting up new services is completely declarative now, and can include a lot of hardening that would double or triple the length of traditional init scripts. The documentation is not organized that well, but is remarkably complete and clear once you find what you’re looking for, whereas the documentation of traditional init scripts was a combination of oral history and reading the scripts to see what they did.
I’m not crazy about the tight coupling in systemd, nor its extension to places where it’s not needed (like home directories and DNS), but for service management, it’s 100% the right thing, and it puzzles me why Unix grognards hate it so much.
I can’t answer for all Unix grognards, just myself.
It’s the tight coupling. And it’s the extension to take over everything. And it’s the binary format logging. And it’s the giganticness. And it’s the nonobviousness of the declarative config, where everything has a near-homonym that does something different. And it’s the history of the progenitor, whose previous projects were also widely adopted and broke things.
What do you get if you remove all of the sources for those objections (besides the last one)?
A small PID 1 init that launches a supervisor with well-defined interfaces that allow it to run your choice of daemons, with defaults for logging, start, stop, security, dependency… that can be overridden by a well-documented concise set of options. A project that values working well with others, reducing bugs by reducing code paths, and ease of debugging configs.
Single favorite feature of mine is systemd timers which get away from the arcane * 13 1 1 * <command> format and let you specify time like a human would eg. OnCalendar=weekly or OnCalendar=Sat,Sun 20:00. I do wish timers held or could hold their commands, but whatever I can read their frequency without needing a reference at least.
I moved a scheduled job from an unsupported in-house version of cron to a systemd timer, it worked like a charm. I really loved the decoupling of the service definition (what to run) and the timer definition (when to run it).
BSD systems use from to drive periodic, which lets you run a weekly shell script by just dropping it in the weekly directory. Most of the system-provided ones include rc.conf and run their job only if a specific enable flag is set.
You do pretty much different things there. One command is showing status of service while another one is showing logs filtered to match particular unit. You can pass much more filters to journalctl and compose them, you cannot pass filters nor compose them to systemctl status.
You’re describing the implementations of the commands as they exist. I understand that, and I understand why those differences exist. It doesn’t matter, though. If a system provides a set of binaries of the form <noun><verb> i.e. {journalctl,systemctl} then the clear user expectation is that they have the same semantics. If that’s not the case, then they should not have the same verb.
If xctl only accepts a single argument (unit), but yctl acceps N units, then there exists a wide range of acceptable choices for how to specify arguments, absolutely. But allowing xctl unit and not xctl -u unit, while allowing yctl -u unit and not yctl unit? This definitely isn’t one of them.
That’s not really a fair characterisation of his position; he correctly points out that the US Military is Red Hat’s largest customer, and that if they or others wanted to backdoor systemd, it might not be discovered for some time.
(Though I happen to agree with your assessment of his writing; I don’t enjoy it, myself).
It’s a straw man because you can say the same about any company hat makes business in the US and thus is covered by the pretty NSA letters. Thus you rather shouldn’t use any software or product that is hosted in the US, hosted by a company also resident in the US (cloud act), created by a US company… Them military backdoors could be anywhere.
The post would be more convincing if it included a list of CVEs as evidence. The number of open issues shows that the project is quite large; it doesn’t necessarily indicate security holes.
The line count argument isn’t very strong either since each component usually replaces other software pieces. Pieces that were usually written in the 90ies and also lacked good coding practice.
That being said, I think the author is right that the systemd project might be tempted to take shortcuts and not define clear interfaces between all the components, creating unnecessary coupling in the process.
I took a look at Debian’s bug trackers for source packages systemd and sysvinit.
The first question is: should all issues in initscripts be attributed to sysvinit? On the one hand, that’s a reasonable interpretation: if you have a problem with your init system, it doesn’t matter all that much to you if it’s a core problem or in the standard script for that subsystem. Some bugs for systemd are basically of the same order: only appears if you are using that subsystem. But the SV initscripts bugs are usually isolated: you don’t need to fix anything in init itself to solve the problem, just fix the script. Most of the systemd equivalent bugs look (to me, in a brief survey) to be problems that arise in one or more of the systemd executables. I suppose that’s the difference between code-as-config and declarative config.
sysvinit is also older than systemd, so there has been more time to find and report and fix bugs. Still, about 80% of the bugs reported against sysvinit are initscripts bugs, not in an executable. About half of the systemd bugs look like they are in a similar category.
Looking at CVEs: perhaps 43 of the 73 CVEs attributed to systemd (and it should be 72, one of them is about an unrelated package with the same name…) are issues in the systemd executables rather than attributable to specific services managed by systemd.
I am unable to find a CVE related to sysvinit except one in Red Hat from 1999; “init” turns up 343 entries but I couldn’t find any (in a brief visual scan, and several other keyword attempts) that involved sysvinit.
This guy is an idiot, and I cringe every time I see something by him posted. I’m sorry if that’s not a high-enough quality comment for Lobsters, but it’s true. I have literally never seen anything of his posted that did not make me set the Bozo bit to 1.
I considered flagging this as unkind, but after the disclaimer and reading another one of his posts I reconsidered. If we’re going to ban Drew DeVault’s content here, this guy should be banned as well..
No offense to the author but these feel like a low-effort rant you’d hear at local LUGs instead of a well-thought-out argument against a particular piece of software. I’ve read some pretty well-researched arguments both for and against systemd but a 1-page blog post isn’t really going to persuade people either way. If anything, it will cause people in either camp to dig in deeper.
Suggesting to tag this as a rant. There’s not a lot of technical discussion here, and what little there is primarily serves to support the author’s personal views on OS design.
I’m not an expert on linux, but as a developer who dabbles with it, systemd is awesome. Things feel much more consistent and discoverable. The services part alone, with cron and process monitoring features is great. No more need for init scripts, I can just stick a shell script into a service and a timer and call it a day.
I’ve adminned Linux machines on a small scale (home/hobby, and a small web hosting company back in the days when servers were pets, not livestock) for over 20 years, and systemd has been absolutely a blessing to me in every way. Setting up new services is completely declarative now, and can include a lot of hardening that would double or triple the length of traditional init scripts. The documentation is not organized that well, but is remarkably complete and clear once you find what you’re looking for, whereas the documentation of traditional init scripts was a combination of oral history and reading the scripts to see what they did.
I’m not crazy about the tight coupling in systemd, nor its extension to places where it’s not needed (like home directories and DNS), but for service management, it’s 100% the right thing, and it puzzles me why Unix grognards hate it so much.
I can’t answer for all Unix grognards, just myself.
It’s the tight coupling. And it’s the extension to take over everything. And it’s the binary format logging. And it’s the giganticness. And it’s the nonobviousness of the declarative config, where everything has a near-homonym that does something different. And it’s the history of the progenitor, whose previous projects were also widely adopted and broke things.
What do you get if you remove all of the sources for those objections (besides the last one)?
A small PID 1 init that launches a supervisor with well-defined interfaces that allow it to run your choice of daemons, with defaults for logging, start, stop, security, dependency… that can be overridden by a well-documented concise set of options. A project that values working well with others, reducing bugs by reducing code paths, and ease of debugging configs.
Single favorite feature of mine is systemd timers which get away from the arcane
* 13 1 1 * <command>format and let you specify time like a human would eg.OnCalendar=weeklyorOnCalendar=Sat,Sun 20:00. I do wish timers held or could hold their commands, but whatever I can read their frequency without needing a reference at least.I moved a scheduled job from an unsupported in-house version of cron to a systemd timer, it worked like a charm. I really loved the decoupling of the service definition (what to run) and the timer definition (when to run it).
BSD systems use from to drive periodic, which lets you run a weekly shell script by just dropping it in the weekly directory. Most of the system-provided ones include rc.conf and run their job only if a specific enable flag is set.
???
You do pretty much different things there. One command is showing status of service while another one is showing logs filtered to match particular unit. You can pass much more filters to
journalctland compose them, you cannot pass filters nor compose them tosystemctl status.You’re describing the implementations of the commands as they exist. I understand that, and I understand why those differences exist. It doesn’t matter, though. If a system provides a set of binaries of the form
<noun><verb>i.e.{journalctl,systemctl}then the clear user expectation is that they have the same semantics. If that’s not the case, then they should not have the same verb.If
xctlonly accepts a single argument (unit), butyctlacceps N units, then there exists a wide range of acceptable choices for how to specify arguments, absolutely. But allowingxctl unitand notxctl -u unit, while allowingyctl -u unitand notyctl unit? This definitely isn’t one of them.I hate this guy. In another rant on systemd he says it’s a US military backdoor.
That’s not really a fair characterisation of his position; he correctly points out that the US Military is Red Hat’s largest customer, and that if they or others wanted to backdoor systemd, it might not be discovered for some time.
(Though I happen to agree with your assessment of his writing; I don’t enjoy it, myself).
It’s a straw man because you can say the same about any company hat makes business in the US and thus is covered by the pretty NSA letters. Thus you rather shouldn’t use any software or product that is hosted in the US, hosted by a company also resident in the US (cloud act), created by a US company… Them military backdoors could be anywhere.
Why would the US armed forces install a back door into systems it funds for (presumably) its own use?
It’s not as if stock Linux systems are cleared for handling sensitive data anyway.
The post would be more convincing if it included a list of CVEs as evidence. The number of open issues shows that the project is quite large; it doesn’t necessarily indicate security holes.
The line count argument isn’t very strong either since each component usually replaces other software pieces. Pieces that were usually written in the 90ies and also lacked good coding practice.
That being said, I think the author is right that the systemd project might be tempted to take shortcuts and not define clear interfaces between all the components, creating unnecessary coupling in the process.
I took a look at Debian’s bug trackers for source packages systemd and sysvinit.
The first question is: should all issues in initscripts be attributed to sysvinit? On the one hand, that’s a reasonable interpretation: if you have a problem with your init system, it doesn’t matter all that much to you if it’s a core problem or in the standard script for that subsystem. Some bugs for systemd are basically of the same order: only appears if you are using that subsystem. But the SV initscripts bugs are usually isolated: you don’t need to fix anything in init itself to solve the problem, just fix the script. Most of the systemd equivalent bugs look (to me, in a brief survey) to be problems that arise in one or more of the systemd executables. I suppose that’s the difference between code-as-config and declarative config.
sysvinit is also older than systemd, so there has been more time to find and report and fix bugs. Still, about 80% of the bugs reported against sysvinit are initscripts bugs, not in an executable. About half of the systemd bugs look like they are in a similar category.
Looking at CVEs: perhaps 43 of the 73 CVEs attributed to systemd (and it should be 72, one of them is about an unrelated package with the same name…) are issues in the systemd executables rather than attributable to specific services managed by systemd.
I am unable to find a CVE related to sysvinit except one in Red Hat from 1999; “init” turns up 343 entries but I couldn’t find any (in a brief visual scan, and several other keyword attempts) that involved sysvinit.
This guy is an idiot, and I cringe every time I see something by him posted. I’m sorry if that’s not a high-enough quality comment for Lobsters, but it’s true. I have literally never seen anything of his posted that did not make me set the Bozo bit to 1.
I considered flagging this as unkind, but after the disclaimer and reading another one of his posts I reconsidered. If we’re going to ban Drew DeVault’s content here, this guy should be banned as well..
https://www.unixsheikh.com/articles/my-choice-of-operating-system.html
So he actually likes systemd, just not all of systemd.
also the domain (unixsheikh.com) has mostly rant-tagged submissions here
Thjs change your mind? :-) https://openbsdrouterguide.net/ – it is one of the very few reasonably written router/firewall guides.
You could fix that by writing it yourself instead of complaining about others writing code.
Imagine complaining about open source developers merging work from their forks to upstream.
No offense to the author but these feel like a low-effort rant you’d hear at local LUGs instead of a well-thought-out argument against a particular piece of software. I’ve read some pretty well-researched arguments both for and against systemd but a 1-page blog post isn’t really going to persuade people either way. If anything, it will cause people in either camp to dig in deeper.
We even have a “systemd” tag that can be used for this entry.