The good people over at Infoworld have published a story outlining why they feel systemd is a disaster.
Excerpt from Infoworld:
While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux—which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system—from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.
(Score: 4, Informative) by cafebabe on Tuesday August 19 2014, @01:28PM
systemd is supposed to replace sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd. As noted in https://lists.fedoraproject.org/pipermail/devel/2012-October/172163.html [fedoraproject.org] via https://soylentnews.org/comments.pl?sid=3380&cid=81660 [soylentnews.org], systemd also includes a QRCode generator and a webserver (running a root?) so that the (easily corrupted) binary logs can be viewed.
The one thing that isn't glommed into this design is PulseAudio.
1702845791×2
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @01:43PM
Heh, it's only a matter of time; although it will undoubtedly be an incompatible fork of pulse audio.
(Score: 2) by Anonymous Coward on Tuesday August 19 2014, @02:31PM
How long until they move Gnome into systemd? After all, it already depends on it ...
But then, just wait for the next step: Moving things into the kernel. A kernel is not complete without a kernel space web server to control kernel parameters! ;-)
(Score: 3, Insightful) by Lagg on Tuesday August 19 2014, @02:41PM
and now you've instantly fell into the political bullshit that stops sincere criticisms from going anywhere and at least for me nullified whatever point you may have had. The "webserver" is systemd-journal-gatewayd, not only a separate binary but one that is disabled by default and actually a potentially useful method of sending journal records to another system. I don't know why I bother trying to initiate discussion and encourage critical thinking for a topic like this. People just fall into lemming-like parroting of false information that only became moreso as it went up the grapevine. I don't get why people think of this as some kind of bizarre government proprietary software. You can look at this shit yourself and give feedback if you can handle doing it sincerely.
and no, the fucking thing doesn't run as root. It runs as systemd-journal-gateway. Way to go guys with modding informative. Because that's what we have here. A post jam packed of informative info.
http://lagg.me [lagg.me] 🗿
(Score: 1, Insightful) by Anonymous Coward on Tuesday August 19 2014, @04:33PM
I'm sure I heard of something like this once... I think it was called syslogd. This was back before the dark times, before systemd.
(Score: 2) by Lagg on Tuesday August 19 2014, @06:15PM
Yes I've seen this smartass argument too. Problem is, log forwarding was nothing like this and all things considered was less robust due to it being both an ad-hoc protocol (okay, it was technically based on the syslog rfc but so much crap has diverged from it that it may as well be ad-hoc) and not having a really easily deserialized format like json that can be easily read by something that isn't another logger daemon. But of course when have facts like this stopped people from claiming that the journal gateway is somehow reinventing syslog's forwarder despite being nothing like it whatsoever and intended to be more than just forwarding to another daemon.
http://lagg.me [lagg.me] 🗿
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @09:56PM
Right, let's make this easy. I was debunking the quoted section and specifically your claim that the webserver is "a potentially useful method of sending journal records to another system".
As for json, yes it's much cleaner and more expressive than ini files -- consider...
... because systemd authors didn't. And it may also make sense as a serialisation format for logging, along with a new RFC for remote logging. And basic log tampering on the local machine could be prevented with checksumming just as effectively as it is prevented by a binary log format. Only the json for configuration stuff has anything to do with a pid 1 replacement though!