From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened software in favour of whatever is in systemd by default.
Logging is a bit different, but you can tell journald to use syslog.
No. One can tell syslogd to read from the journal. There is no mode of operation for journald that does not have the journal, on disc or in a memory filesystem. And journald itself is not optional. The only optional part is choosing to have an extra old-style syslog daemon that is using the journal as input.
They really aren't. It took us a full week of work to get dnsmasq to work in place of systemd-resolved. The problem is that they are tied in to the dhcp client and it only seems to know how to update systemd-resolved's configuration. So getting our custom search path out of dhcp was a huge pain.
I like almost every other part of systemd, but trying to excise systemd-resolved from Ubuntu 18.04 was massively frustrating to the point where I started thinking, "maybe the systemd haters are right…"
The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd.
And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts together won't do it.
This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools.
The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
Alternative doesn't mean 100% substitute both ways. The pre-systemd didn't go in their abstraction in the way, that systemd does - it is basically system-level, event handling machine. The events could be not only boot, but also hotplug, timer, socket connection or others, and their handling is configured by the system or admin in unified way, including unified way of adjusting system-supplied units. Other inits just ran scripts at some order the boot and that's it, ignoring, that something doesn't have to happen at boot, but at some other time.
That's one of the things, that systemd handles way better, than any suggested alternative. By ignoring where systemd is strong, you won't make the alternatives any better.
> The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
No. I don't see why we should have the Sisyphos task of maintaing sysv/cron/etc idiosyncrasies forever. Sometimes, it is better to get rid of the collected warts, and not limit the system to existing semantics.
On the contrary, that's exactly what systemd's predecessor, Upstart, did. systemd, in contrast, did not. Basing the system around the concept of events triggering things turned out to cause problems, as discussed by Lennart Poettering and by Debian Technical Committee members during the Debian Hoo-Hah as their reason for not choosing Upstart.
See http://0pointer.de/blog/projects/systemd.html, section "On Upstart". It names two big issues with HOW.
I meant, that systemd solves some category of problems, that other tools didn't solve, didn't intend to solve and didn't even care for what the problems are. For distribution maintainers, systemd was something to welcome, that did address their problems.
So yes, there is no replacement (the requirement for it being drop-in only places the bar higher), because there's nothing else that scratches the same itch.
This is an interesting claim, mind throwing some pointers?
and some other directives documented on the same page.
The timing of these systems releasing does not equate to causation here. Google themselves (creators of cgroups) do not even use systemd on their own hypervisors which leverage cgroups heavily.
> For example, using Docker when the basic isolation features of systemd would do
Then you should not be wanting to see applications including a hard dependency to systemD.
The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our stuff so now you do too" approach. It's _very_ hard for me to build a system without systemd; I can use a niche Linux distro, I can use a BSD, or I can hack another init system (etc.) in myself. None of those are satisfying, I think for obvious reasons.
systemd is not well written, and it is not well designed. Its style and architecture are inconsistent. Parsing is mixed with validation and business logic. The types of CVEs its generated show that there was no coherent thought put into input validation, fuzzing, taint analysis, and so on. The effects of those flaws (your whole system crashes, etc.) show that failure strategies were never considered. And if all that sounds like overkill to you, maybe it is! But I can tell you that these techniques and design strategies are employed by experts to build software that must be robust, like software that controls medical equipment or transportation control systems. We know how to build software that works and that mitigates failures. Looking at systemd's code, it's clear they used none of that knowledge. And that, combined with its sprawling control over my system, makes me not want it on my machines.
I'm not qualified to judge the quality of the code in systemd directly; I've browsed it a little but I am a middling C++ programmer and while it hasn't stood out to me as smelly I would defer to more knowledgeable heads. I get the drive for very rugged underpinnings, and I'm on board with that; in things that aren't C++ I frequently am the one with the scalpels making criticisms similar to yours, so that totally resonates with me. I am not, however, convinced that any of the alternatives that currently exist are materially better, so I kinda shrug a bit? Further, it seems to me that the generally modular nature of systemd (regardless of how coupled one believes those separate modules to be) suggests that a determined programmer could probably build a drop-in replacement--Rust? Where's my Rust Evangelization Strike Force?--that plays nicely with it and grows to replace poor and soft design.
The social aspect you bring up is, to me, the most compelling argument against systemd (because monocultures aren't great in general, etc.--I think most people agree on that). Thing is, though, I think that that bottom-up consensus model was doomed from the start. I don't think it was ever going to be tenable as soon as there's any money in it. Red Hat wants consistency, their stuff is going to have consistency, you can use it or go off-roading.
I don't think there's a great solution aside from "build your own ecosystem and don't let it get capitalism.txt'd to death." Which is a deeply unsatisfying and impractical answer. And to be clear, people who feel strongly about it should do that. I'm not being snarky when I say that. I'm a pragmatist--if it's better, I'll use it, too, and submit patches if needed and when I'm capable. ;)
I do, it's "if you run a big mainstream distro like Fedora or Debian, let your users swap out init systems". I know there have been debates on this, and I know the general consensus is "it's not worth the trouble / it's not as simple as just swapping out something like systemd". My counter arguments are: there are distros that are doing it, so it doesn't seem like it's that bad after all, and when dealing with something as important as PID 1 (or your libc, or your filesystem) we should be conservative and let users swap things back when making a huge change.
The other thing that jumps out at me is just that this hypothetical is mostly kicking the can down the road. If Fedora suddenly decided to support multiple init systems I think it's hard to envision a future where the happy path wouldn't remain systemd; it's what the core folks think is best, otherwise they wouldn't use it now, and even with additional support the lion's share of attention would go to that happy path. To that end I think that any sort of init choice in those distros just becomes "so we'll support it for now, but the set of third party stuff that supports it is going to continue to shrink, so I hope you have an off-ramp in the future."
Between these two issues it seems like separate distros that have a firm commitment to not-systemd end up being necessary anyway and an ecosystem of not-systemd stuff will need to compete for value on those merits. What am I missing?
I never said it is.
What I said is that if someone values diversity of software, then they should object to applications including a hard dependency on systemD. That's just logical, as including hard dependencies on systemD reduces software diversity by requiring that the system it runs on uses systemD rather than allowing them the choice.
Basically systemd has nothing like a dockerfile, that's not what it's for.
I think there's a good argument though that Docker should be retargetting its encapsulation work to a lower level OS primitive where possible (which would be systemd on linux) instead of rolling its own.
I quite like systemd-nspawn too, though.
I’m not arguing that this is worth the overhead, or even a useful feature in practice (most companies and products tend to pick one environment and stick to it), but one that comes to mind that systemd would likely never have.
The naming in Windows and Mac, along with the limitations of the Desktop implementation are also frustrating. Don't get me wrong, I really like Docker as an orchestration base, I just don't think the cross-platform support is a value add in practice and in fact detracts as a whole imho.
Based on my experience and all the anti-systemd posts online, I expected to dislike it.
But on it's merits I really like the consistency it brings to the "system layer" of the OS.
I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system.
On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.