The article makes some good points, and I'm glad it didn't just rail on one single part/component since linux distrobutions have so much variety. ZFS is really a killer FS, and unfortunately Linux just doesn't have a native answer just yet (although BtrFS does have some promising parts).
There's a lot of people either threatening to switch or are switching to one of the BSD's as a result of being dissatisfied with the systemd debate outcome -- apparently not realizing FreeBSD (and others) are in the early stages of working on their own systemd/launchd-like init system. Everyone seems to realize the need for a more modern init system...
I don't think there were too many people in that debate who were dissatisfied with the idea of a new init system. People were dissatisfied with systemd specifically, because of various architectural choices that it made. The fact that FreeBSD might adopt a new init doesn't in itself mean that those people will be scared off.
> I don't think there were too many people in that debate who were dissatisfied with the idea of a new init system
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.
> 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 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.)
Well, I don't believe that's true. All my understanding is that systemd does too much, not that we shouldn't have an init doing more than SysV.
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.
Literally everything you wrote here is objectively wrong about systemd though.
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.
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.
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?
journald is a dependency for systemd, but systemd is not a dependency of journald... in other words you can use journald on a system that does not have systemd.
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).
Anyone could implement their own journaling subsystem against the api and it would work... it doesn't have to be journald. not sure what your point is...
My point is that the following statement made further upthread is fundamentally incorrect as an assessment of systemd:
>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.
Well, as vertex-four pointed out that API is not stable, and as far as I've seen there's no expectation that it ever will be. Feel free to correct me - for me this is the nub of the issue and I'd be happy to hear otherwise.
The existence of hard dependencies in a suite of software for specific components does not prove the case for all components. systemd is 60+ separate components.
Apparently proof it's too monolithic is literally 1 dependency between two parts of it
> systemd is a package of separable utilities, plus an init system.
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)
I really like upstart, and am quite disappointed that Canonical caved on it. It seems to be an honest improvement on SYSV with standardized configs, while still doing One Thing, Well.
I use upstart on my Ubuntu servers but it's still pretty green: upstart still doesn't offer any reliable way to keep a process restarted after a transient failure (once it hits respawn limit it will never try again) and if its view of the world becomes wrong (i.e. a script's expect fork is wrong) all commands will hang until you manually kill the processes and use telinit to get it to restart.
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 initially leaned towards it, but (a) the even model is something I find less pleasant to work with than the dependency model, and (b) the original author disowned it as unfixable.
> 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).
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.
1) the unholy shitpile of init scripts was only a problem because the desktop guys who wrote the particular shitpile in question had no idea what they were doing. BSD is proof that you can write clean, sensible init scripts.
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?
> BSD is proof that you can write clean, sensible init scripts.
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.
An interest that one guy has is not evidence of the inability of many others to have written clean, sensible init scripts for several decades; which, as point of actual fact in this real world in which we actually really both exist, they have.
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.
And you're creating a strawman. rodgerd didn't say that the only two options were SysVinit and systemd, but that the loudest critics of systemd wanted to keep SysVinit. Whether that's true or not is another point (and not objectively decidable since "loudest" is pretty subjective), but it's obviously not the false dichotomy you're accusing him of.
FreeBSD has been in the early stages of working on a launchd port for 10 years now. It seems like progress with openlaunchd is going well, but there are certain things related to Mach IPC that need to be ported to the upstream FreeBSD kernel to get it working. I do recall some old version of launchd entitled launchd_xml was ported to pfSense, but it's one that puts the XML parser into PID1, so it's not desirable.
IMHO, I wouldn't count on any major init changes in FreeBSD any time soon. It's been protracted enough already, and Jordan Hubbard giving a pep talk doesn't mean all that much. I could very well be mistaken.
The differences in scope between launchd and systemd are pretty big, too.
> FreeBSD has been in the early stages of working on a launchd port for 10 years now.
There were several half-serious individual efforts, but I don't think the community / foundation were pursuing it seriously until quite recently. Kip Macy has been working hard to get it in as an init replacement recently.
> It seems like progress with openlaunchd is going well, but there are certain things related to Mach IPC that need to be ported to the upstream FreeBSD kernel to get it working.
The mach stuff has been ported (recently), again by Kip Macy.
> I do recall some old version of launchd entitled launchd_xml was ported to pfSense, but it's one that puts the XML parser into PID1, so it's not desirable.
Right. I think the current plan is that the parsing is done in another process and then IPC'd to launchd via Mach. Or the plist stuff could be replaced with a 'libucl' parser that is safer in init? I'm fuzzy on these particular detail, sorry.
> IMHO, I wouldn't count on any major init changes in FreeBSD any time soon. It's been protracted enough already, and Jordan Hubbard giving a pep talk doesn't mean all that much. I could very well be mistaken.
>> FreeBSD has been in the early stages of working on a launchd port for 10 years now.
> There were several half-serious individual efforts, but I don't think the community / foundation were pursuing it seriously until quite recently. Kip Macy has been working hard to get it in as an init replacement recently.
This is because iXsystems (Jordan Hubbard) hired Kip to implement it for FreeNAS (and, presumably PC-BSD), not because the FreeBSD community thinks it needs a new init system.
Jordan also has plans to bring other large pieces from Apple to FreeBSD.
> This is because iXsystems (Jordan Hubbard) hired Kip to implement it for FreeNAS (and, presumably PC-BSD),
I believe EMC Isilon has also sponsored the work.
> not because the FreeBSD community thinks it needs a new init system.
Right. Kip is working on it because someone hired him too. But practically, this is how large-scale efforts get done. Some FreeBSD-using corporation hires / builds out a larger project in a way that is acceptable to the community and it is incorporated into base.
I do think the community has come to more or less that consensus at this point, though. The camp that is fine with /etc/rc hasn't started raising loud complaints about the idea incorporating a backwards-compatible launchd to replace rc.
There's a lot of people either threatening to switch or are switching to one of the BSD's as a result of being dissatisfied with the systemd debate outcome -- apparently not realizing FreeBSD (and others) are in the early stages of working on their own systemd/launchd-like init system. Everyone seems to realize the need for a more modern init system...