Live data from Hacker News

Why I dislike systemd

steven-mcdonald.id.au

171–180 of 254 posts

Re: Why I dislike systemd

#171
post #117

Earlier quoted context omitted.

All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935

Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.

I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".

Re: Why I dislike systemd

#172

This is the first anti-systemd article that I've read that focuses exclusively on the technical issues with it (well, mostly: the last one kind of gets touchy on the politics). And this article is a good summarization of them. Linux in the server world is rapidly turning into a thin platform hosting containers (docker, kubernetes, etc) of "fat" Linux distros. Systemd makes a lot more sense if you consider it in that…

Thanks, I think your perspective on the different use cases for Linux vs *BSD were helpful and something I hadn't seen all in one place before.

Re: Why I dislike systemd

#173

There is something epically beautiful about OpenBSD's consistency over the last 10 years. I swear that a 2004 OpenBSD sysadmin would be close to 100% efficient with a circa 2015 OpenBSD system, despite the absolutely massive number of improvements and changes that have been made with the operating system. Once systemd starts to get traction, it's cognitive overhead is going to become a real problem for sysadmins who…

I'm not a professional sysadmin, but as a developer with a bunch of virtual servers systemd has only made things far easier. Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on,…

Professional sysadmin (and developer) here :)

> Writing init scripts used to be a real pain

In the GNU/Linux world, yep, this is the case. Lots of copypasted boilerplate that becomes a nightmare to debug.

In the BSD world (at least with OpenBSD, where I'm most experienced), this isn't the case at all; OpenBSD ships with /etc/rc.d/rc.subr, which one can (and should) source into one's initscripts to make life much easier than even (in my experience) systemd's unit files. Set the $daemon variable, source in rc.subr, call rc_cmd, done. Sure, you might want/need to read a couple manpages, but this is the case with systemd, too.

Back to the GNU/Linux world, the complexity of SysVInit is not a hard dependency of using shell scripts for daemon management; there's very little stopping a GNU/Linux system from adopting a BSD-style rc system, rc.subr, etc. and making life significantly easier for sysadmins. Alternately, there's very little stopping a GNU/Linux system from implementing shell scripts in something significantly less horrendous to use, such as an interpreted scripting language (like Perl or Python or Ruby). SysVInit and BSD-style rc-based init both have a distinct lack of hard requirements on how initscripts are implemented, so long as said scripts are valid executables.

> Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on, I personally think that's something computers are a lot better at solving.

Would you not want to be able to model the startup process and run-state of the software you write in your head? Why should the underlying operating system be any different? If you have to rely upon external tools just to be able to reason about the execution flow of something - your server, your program, your recipe for lamb vindaloo, whatever - chances are it's way too complicated and needs significant refactoring.

Re: Why I dislike systemd

#174

Earlier quoted context omitted.

Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either. One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.

That's not a DSL, that's a shell script. As for what `pexp="..."` does - it's just setting the pexp variable. If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script. No DSL knowledge required, at all. Just shell knowledge, and the willingness to look at sourced shell scripts.

> If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script.

Ouch... Shell (or Bourne Shell to be exact), not bash.

Bash is a type of Shell and it's not* even available (thank goodness) on either of the BSDs in their base system (only as a port and/or package).

On OpenBSD, the actual command line interpreter is actually Korn, not the Bourne, Shell.

Re: Why I dislike systemd

#175
post #115
post #17

Earlier quoted context omitted.

> Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... This. I'm not saying systemd is the best answer, but I really think sysadmins could learn a thing or two from developers. Nearly every custom init script I've ever seen has bugs, and isn't portable between systems. Where are the unit tests? Code reuse? Focus on maintainability/readability? Shell scripting used t…

The shell has always been awful. It is underpowered and overfeatured with a deeply crappy API. It is more like Windows 3.1 than any sane development environment.

The good news is that you don't have to implement initscripts as shell scripts. I recall at least one GNU/Linux distro that used Python for all its initscripts, for example. Really, as long as the "script" is executable, a SysVInit-based or BSD-rc-based system doesn't really care (unless it's doing something strange like calling a specific interpreter on each script - i.e. calling `sh /etc/rc.d/rc.*` or somesuch).

Re: Why I dislike systemd

#176
post #20

Earlier quoted context omitted.

The naysayers are taken seriously, but they're in the decision-making minority. Linux distro maintainers wanted to move on from SysV Init, and systemd looked promising. Just because the naysayers didn't get their way (and on some distros, they did) doesn't mean that their criticisms aren't noted.

Which distros? Slackware is the only near-mainstream Linux distro I know of that is even possibly not moving immediately to systemd, and even then, the Slackware folks have said that once it becomes too difficult to maintain upstream packages, they'll switch too. They're just being pragmatic about it.

It's worth noting that "too difficult" is a very high bar for a distro that to this day has yet to implement things like PAM; if you want an authentication system more advanced than /etc/{password,shadow}, you'll need to compile PAM from source and install it manually (there might be a Slackbuild for it nowadays; I don't really remember).

Re: Why I dislike systemd

#177
post #91

Why would you punish yourself with various *BSDs when you can have OpenRC and more advanced ports on Gentoo? Do people really associate systemd, Gnome and other nuisances with Linux?

Given that it's the default and sometimes only working option for many of the most popular Linux distros: yes.

Given also that systemd is Linux-only due to its reliance on cgroups: yes.

Re: Why I dislike systemd

#178
post #110
post #20

Earlier quoted context omitted.

The naysayers are taken seriously, but they're in the decision-making minority. Linux distro maintainers wanted to move on from SysV Init, and systemd looked promising. Just because the naysayers didn't get their way (and on some distros, they did) doesn't mean that their criticisms aren't noted.

"Linux distro maintainers wanted to move on from SysV Init" LOL no. distro maintainers wanted to ship gnome, which was product tied to systemd. No systemd, no gnome, that simple.

Perhaps you could benefit from reading what some of the people making these decisions have written on the topic.

https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=1729;bug=7...

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Re: Why I dislike systemd

#179
post #117

Earlier quoted context omitted.

All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935

An excellent example of a failure to communicate. Linus said that the fact that systemd parses the "debug" parameter is not a bug: http://lwn.net/Articles/593677/ But sadly that didn't stop various Linux developers from bullying the systemd developers in that bug report instead of trying to find some common ground. The actual bugs (assertion failure creating debug output in systemd, and inadequate buffering in Linux'…

Your link supports the assertion that systemd doesn't play well with the community -- Linus goes on to say:

    It does become a problem when you have a system service developer [Kay] who
    thinks the universe revolves around him, and nobody else matters, and
    people sending him bug-reports are annoyances that should be ignored
    rather than acknowledged and fixed. At that point, it's a problem.

Re: Why I dislike systemd

#180
post #84

Earlier quoted context omitted.

> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN). That's because there is equally no uniform and simple way to connect to use those, either. The problem is that the "simplification" that NetworkManager prov…

Thanks for your detailed response. So what laptop do you use for OpenBSD? I'm running Ubuntu on my main laptop and I tend to search for hardware that's known to work with it.

I'm not the parent commenter, but I personally run OpenBSD on a pretty wide variety of hardware, most recently (among laptops, that is) a PowerBook G4 and a Dell Latitude D830. Most things work out-of-the-box, but there are a few exceptions:

* Power management is nonexistent on PowerPC hardware, so I currently have to shut down my PowerBook between uses, since I can't put it in standby. This is annoying, but workable.

* Hibernation is buggy on the Latitude. Suspend works fine, though.

* Both the PowerBook and the Latitude required the use of fw_update to install nonfree firmware (for the Broadcom-based Airport wireless NIC and the Intel PRO Wireless 3495abg-or-whatever wireless NIC, respectively). Also slightly inconvenient, but - again - still workable.

* Some things don't really work on PowerPC, most notably Firewire. A slight bummer, but hopefully this will be resolved someday.

From what I understand, IBM/Lenovo ThinkPads are - just like they are with GNU/Linux - among the best laptops to use with OpenBSD; IIRC, a lot of the OpenBSD devs dogfood pretty heavily on them, so they get a bit more attention. I'd avoid anything with Nvidia graphics, whereas AMD/ATI or Intel graphics should be decent.

Post reply on HN