So the proposal is an attempt to force volunteers to do something they do not care doing by themselves? That sounds like a solid plan and will surly result in well working support for non-systemd unit systems.

What could possibly go wrong with that plan?

Yeap, the indexing in the journald files does increase the file size. That does speed up searches though, so it does have its advantage.

But systemd also logs a lot more than syslog ever could. This includes a lot of meta data (e.g. systems unit that started a process, cryptographic hash) for each entry as well as more entries (e.g. stdout and stderr from all daemons).

What does systemd make worse?

I can e.g. restrict services far more effectively since I switched my machines to systemd. I really appreciate that. I also find the socket activation really convenient and am really happy to be rid of that horrible crontab syntax. Networkd works like a charm and debugging became so much easier since the log output is finally complete.

So far I have yet to find anything I miss from sysv unit.

That is indeed not posible: systems logs stuff that is not accessible to syslog (e.g. stdout and stderr of all processes run by systemd, output geerated before/after syslogd is up, etc.) and needs journald as some kind of internal interface to pass all that information on.

Why journald?

Because systemd logs stuff that is not accessible to syslog and thus needs an interface to buffer (e.g. before syslog is up) and forward that information to syslog.

That system grew up to handle most of the things syslog also does. So syslog was made optional, so that small systems have one less service that they need to run.

Send like a sensible decision to me.

The complexity of systemd is in stand-alone executables running inseverly restricted environments (no access to /home, private /tmp, read-only /, no network but through one file descriptor, etc.). That is a huge step forward.

This is especially true considering that the systems complexity is also running as separate, far less restricted services on non systemd systems (e.g. cron, xinetd, nwtpd, etc.).

That actually is a pretty good description of how systemd handles this.

Whichh sane ternatives to pulseaudio are you referring to?

How should that work? You need cgrouo support in the init system for that. Do you seriously think that is ever going to be added to sysv init?

Having some external process managing cgroups for init itself can not work, except by having init start the cgroup manager and then having that start everything else.

So the people that build the system do not care about it. *plonk*

Why should it be replaceable? It is internal. You are fine as long as you can attach everything you need as some kind of backend to that interface.

Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.

Once clang builds the kernel it will most likely also build systemd:-)

Oh, come on... *ALL* init systems do IPC. That might just be a simple pipe somewhere, but that is still IPC. How do you think telinit works?

KWin (the KDE window manager) will depend on logind at the very least for wayland. ConsoleKit is dead, so anything currently using that will need to look for an replacement soon. That includes basically every DE out there.

Some might come up with a different solution, some may function without logind, some will just require logind like gnome does now. Let's wait and see how that will work out.

You are aware that logind, journald and networkd are all stand-alone daemons that just happen to integrate well with systemd-PID1 and that live in the same source code repository? You do not want them? Just disable them.

Journald is a bit of an exception here: It basically provides the logging infrastructure for the other parts of the project. So all you can do there is to have it forward the logs to syslog.

I entirely fail to see why binary logs are such a big argument, considering that syslog is fully supported. Push your stuff there, RHEL7 apparently even does that by default. You still get more information into your logs that way than you used to. So you win, independent of whether you use journalctl or cat on the files syslog creates to read them.

No, but then FreeBSD is of course free to have several init systems if they care. Traditionally they do seem to prefer a more consistent user-space developed by one team.

I do not get what you are going at with this point.

Yeap, it is getting more and more common, even on embedded hardware. There is so much software out there that is basically untested on anything but glibc that it makes sense to use that libc if you do not write everything in-house.

I used "we" exactly once and I am pretty sure there will be very few people indeed that defend the crontab syntax.

I am in no way talking about features of any replacement init. I am talking about interfaces other applications are depending on.

This may be udev, or the hostname/data/time configuration or logind or whatever else. Fact is that gnome is depending on some of these interfaces. KDE announced that they will do the same -- at the very least for wayland. I doubt that the other DEs will be far behind, especially now that ubuntu wants to move to systemd, too. These interfaces are apparently not all bad, so developers want to use them.

So if you want to run any of these applications, then you need to provide these interfaces in one way or another. This can be by either using systemd, or systemd-shim or systembsd or whatever implementation. There are quite a few to choose from at this point:-) For a new project to remove all that code and claim it is not needed is naive at best.

The features provided by the init system itself or how those are implemented is irrelevant to my point.