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)
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.