4 ms·
The actual speaker is great, but the vast majority of people who have a problem with systemd get there philosophically. In a "I never actually had to write any
by evol262 8y ago
The actual speaker is great, but the vast majority of people who have a problem with systemd get there philosophically.
In a "I never actually had to write any code which had significant interaction with existing solutions (openrc, upstart, sysv, bsd, whatever), but I know they exist, so I'll talk about them like they solve the same problems as systemd" way. Which they do not. Want socket activation, double forking, namespaced children, sane scripts/unit files that can build a good dependency tree? You have one option.
Additionally, people see other tools like systemd-network and say "but systemd is doing everything!" Which it isn't. Almost no distros package those as part of the default.
Even if they did, many of the anti-systemd crowd would rather live with a different, slower system (NetworkManager, for example) which is vastly most complicated than what they need. Ditto for systemd-resolved and local caching dnsmasq.
Systemd is not trying to replace NM or BIND or anything. It's basically saying "it's 2019. If you want to be able to work with a system without knowing the ins and outs of 30 different configuration files, and speed up boot time/auditability of your system significantly, you can use these services"
Some things are bad for the community in general. The dependence on dbus (and kdbus), systemd-logind, and other tools aren't very friendly to BSDs to anti-systemd distros. Frankly, from my POV, this isn't systemd's problem. The anti-distros are free to do what they want, knowing the limitations. The BSD guys have written compatibility layers, which you can do, because they're open standards.
Broadly, I'd say that the anti-systemd crowd holds to an idea of "UNIX" purity, as if HP-UX, Tru64, AIX, Solaris, IRIX, and others were uniform. The reality is that they were more different than they were alike, in terms of administrative tools, filesystem layout (is this /sbin/init.d, /etc/rc.d, /sbin/rc.d, etc?) and even software portability. A large reason that GNU autoconf exists is to detect all of the quirks on all of these platforms.
Additionally, anti-systemd people either never used X11R6/OSS/lilo and other old tools, or don't remember how terrible they were. Any large change in the community (X.org fork, ALSA->PulseAudio, grub) draws ire. From the same people who are trying to use syslinux and efibootmgr instead of just using grub2.
Some people would rather debate philosophy than get actual work done, and that's great for open source, even if it's frustrating. But those people never dug into the guts of upstart to make something work, or had 250 lines of sysvinit boilerplate+supervisord saved off somewhere to speed up a process that you can do in 4 lines in a systemd unit file.
- nickik 8y agoSolaris and other Unix had things like systemd already.
- evol262 8y agoSMF wasn't added until later in Solaris 10. Other unixes (Tru64, HP-UX, Ultrix, AIX, IRIX, etc) did not have anything like it. They were either BSD init or sysvinit
- JdeBP 8y agoRubbish. AIX had the SRC doing service management since 1992. And the SAF, also in Solaris, had been doing management of several classes of services since 1988. * http://jdebp.eu./FGA/inittab-getty-is-history.html http://jdebp.eu./FGA/inittab-getty-is-history.html * http://jdebp.eu./FGA/run-levels-are-history.html http://jdebp.eu./FGA/run-levels-are-history.html * http://jdebp.eu./FGA/unix-service-access-facility.html http://jdebp.eu./FGA/unix-service-access-facility.html
- evol262 8y agoThis is _exactly_ what I'm talking about. Neither SAF or srcmstr are equivalent to systemd, and you know it. Making the argument that they're even in the same ballpark is fatuous, except insofar as they have some abstract concept of service groups and replacing sysvinit with something better.
- JdeBP 8y agoWhat is you are really talking about is self-contradictory drivel, claiming that Unices were diverse and in the next breath stating that they only had "either BSD init or sysvinit". Clearly, you are presenting ahistoric rubbish. Trying to introduce strawmen, as you now are, when shown that is at best diversionary. The simple, but sadly not well known and in your case outright denied, truth is that the Unix world took stuff out of the old inittab+runlevels system that you erroneously claim was one of the the only two things going, and had service managers with many of the features that one would recognize today, from auto-restart through requirements not to "daemonize" and specialized configuration languages for setting processes up that replace shell scripts and dedicated control/administration tools to per-socket-connection instantiation with environment variables describing the endpoints, two decades ago.