Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server
I haven't seen an overwhelming support anywhere. Most people who run Linux on their laptops say, "meh, as long as it boots."
This article is a LOT better than the previous one by the same author. He makes his point clearly, that he doesn't like SystemD, as a sysadmin he doesn't want binary log files etc; but if someone else feels like they need systemD, maybe there should be a fork to make place for those people. It's a fairly kind, open attitude. Maybe we should have more of that around here.
"First they came for the slanderers and i said nothing."
Or we have learned that you can't argue with Red Hat. As a company we have decided against upgrading to RHEL 7 because of systemd, and likely will be migrating to FreeBSD when it is no longer supported.
I'm waiting for our research team to get bored and start finding holes in systemd
I'm starting to think GNU is the problem with "GNU/Linux" these days.
As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.
Every time I see stuff like this I simply laugh. Having worked with *nix for over 30 years I have never had init "not work well" or "not work" as people try and claim. This is 30 years, with at least 8 brands of *nix, and more servers than I can count any longer (ranging from 1CPU to 128CPU E10K/F15K, so my opinion is not based on limited experience).
Systemd is not going to be any better, than Sun's SMF. SMF added nothing over init, except for some sales guy got to tell everyone how great it was. Maybe systemd is going to be worse though... at least SMF was script hackable as long as you could parse and edit XML, and that is not really possible with systemd (last I checked). And in that net zero gain, what did all of the Sun customers get? Lots and lots of costs to develop new scripts and new monitoring tools because SMF was different (not because monitoring was broken). Meanwhile anything that was important stayed out of SMF and went to legacy mode "init" scripts anyway since we could be extremely granular and detailed in a startup
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I have similar length and breadth of experience of Unix systems and to be fair, I have seen init break but only once and it was when I broke it myself. I forgot to put an & and the end of a "sleep 20000 /dev/tty10" while trying to keep a serial line to a printer working properly. Next re-boot hung the machine but I was able to guess what the problem was.
When I first saw SMF break I had absolutely no clue why I couldnt ssh into the machine nor where to start looking. It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.
For me, scanning through /etc/inittab and being able to see exactly what is going on in the initialisation stage is the essence of Unix. Even this is sadly being slowly broken even before the utterly pointless systemd was born.