That's funny, because the loudest voices all seem to be insisting that an unholy shitpile of init scripts a la SysV was the One True Unix Way and had been forever (which shows how young they are, but I digress).
The number of people pushing for smf/launchd equivalents (let alone working on them) is tiny by comparaison.
The arguments I've seen are mostly that it's possible to write clean, composable, independent programs with solid, well-defined APIs between them, rather than the monstrosity that is the systemd project.
Want to replace journald with something else? The API for doing that is not stable, and I suspect the build system doesn't make it easy. Want to initialise kdbus under another init system? Even though it should have absolutely no dependency on systemd whatsoever, the component which does so is tied into systemd and can't be removed from it.
On the other hand, there's systems like nosh[0] which prove that you can build UNIX-y composable programs to solve many of the problems that systemd set out to solve. If you want to replace the logger, go ahead! If you want some component of it without using the whole init system, that's doable too. With only a little work, I'm sure it'd be possible to run much of nosh as non-PID-1.
(Note that I'm not suggesting anyone use nosh - the code is a tad weird and it's hard to find things, and the build system is extremely non-standard. However, it makes a useful proof of concept that the tightly-coupled systemd is not the only way to build something better than the SysV init system.)
[0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
Event-based and dependency-based init systems are not controversial. Having an init system with inseparable and breaking changes to logging, IPC, etc. with its own DHCP client seem to be what people think is absurd.
systemd is a package of separable utilities, plus an init system. Much like the GNU core utilities.
The complaints about "doing too much" can never decide what too much means and usually start suggesting obvious, raw sore spots of SysV init are actually features.
> systemd is a package of separable utilities
It is absolutely anything but that.
If I want to use GNU coreutils with my own implementation of cat, I can write my own. I have to comply to the interface of GNU coreutils' cat, of course, but as long as I do that, I'm fine.
Good luck replacing journald with your own implementation. The API isn't stable or well-documented, so there is no interface that you'd have to comply with to speak of, and even implementing your own journal reader is officially discouraged.
I often find myself thinking that systemd (which I actually use on my desktop) would be far less hated if the development team would stop claiming things that aren't true. If I break a monolithic program into four parts that can't work without each other and can't be replaced, I'm only meeting a cargo cult definition of modularity.
What you imply is equivalent to wanting to run Gnome without libgnome.
If you want text logs, configure journald to pass things into rsyslog or whatever other logging subsystem you prefer (there are many).
>systemd is a package of separable utilities, plus an init system. Much like the GNU core utilities.
The response was:
>So, how does one completely excise journald from a box running systemd. I'm not talking about passing messages through, I'm talking about complete, utter, wiping out?
The point is that if the utilities are truly separable from the init system (as was claimed by the first point as an indication that the person they were responding to didn't "get" systemd) then that would be simple. Note the person responding is responding to the assertion that they fundamentally misunderstand systemd. Their point is to show that they do not.
Your first response adds nothing to the conversation:
>If you want text logs, configure journald to pass things into rsyslog or whatever other logging subsystem you prefer (there are many).
Good point, except that's not what the person you're responding to asked for.
My observation is that systemd isn't just "an init system with separable utilities" that was originally claimed. You seem to agree with me.
Your last point, however, would have been helpful above:
> Anyone could implement their own journaling subsystem against the api and it would work... it doesn't have to be journald.
That would have answered the actual question asked.
Instead of implementing your own reader or writer for journal files we ask you to
use the Journal's native C API to access these files.Apparently proof it's too monolithic is literally 1 dependency between two parts of it
I might give it another look once the internal API between all of the core components is well documented, isn't changing every 17 seconds, and any work to rip out or replace components doesn't require you fight tooth and nail with the build system.
The theoretical possibility of systemd not being monolithic by way of tightly-knit incestuous dependencies doesn't mean much when the reality is that the deck is stacked against you if you try to replace any of those dependencies.
I'm not even against something being monolithic or 'different' - I run a ton of illumos based servers, I love SMF, and am looking forward to the FreeBSD implementation of a more modern and featureful init system.
(I'll disclaim I don't like Lennart or Kay - I've found their behavior to be ridiculous in quite a few ways, and that certainly colors my judgement... but my dislike for them stems from behaviors in relation to technical problems, so I wouldn't say said dislike is without merit)
The fact that it took four releases to add the setuid/setgid statements kind of tells you all you need to know about how many sysadmins the developers talked to.
I don't think that's at all true. It's not been any of the arguments I've seen (e.g. it wasn't the case made by boycottsystemd.org ). If anything that sounds like a strawman from the systemd side.
2) "which shows how young they are" -- what in particular is your issue with older, more experienced people, and how is that a problem enough for you to call it out?
Which, it turns out, are wholly underwhelming for many things people now want their init system doing. Hence launchd, SMF, and Jordan Hubbard's interest in an equivalent. But I guess the BSD developers working on the former and latter don't know what they're doing either, right?
> what in particular is your issue with older, more experienced people
I'm sorry you're struggling to read, but it's quite the opposite: anyone around long enough knows SysVisms were derided widely when they were introduced.
Shitty init scripts and the path to systemd have been self-inflicted wounds caused by a tiny group of inexperienced desktop developers. Such is life when you live in a local minima caused by your own incompetence, I suppose; even terrible, tasteless directions look like improvements.
Oh, you mean like Red Hat (the largest enterprise and server open source company on the planet)?
What about SUSE, Debian, Ubuntu... the list goes on...
It's hard to take you seriously when you're not even wrong.
You're creating a false dichotomy. Just because SysV-style initscripts are a mess doesn't mean systemd is the only viable option.