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.
Why I dislike systemd
171–180 of 254 posts
Re: Why I dislike systemd
#172This 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…
Re: Why I dislike systemd
#173There 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,…
> 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
#174Earlier 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.
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
#175Earlier 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.
Re: Why I dislike systemd
#176Earlier 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.
Re: Why I dislike systemd
#177Why 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.
Re: Why I dislike systemd
#178Earlier 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.
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
#179Earlier 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'…
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
#180Earlier 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.
* 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.