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