There is nothing forced anywhere. The problem the non-systemd crowd is facing is they have no developers and no development taking place. Upstream projects like Gnome and KDE uses systemd features because they are necessary for having a modern DE, and because nothing else provide such features.

Gnome developers have said for years that people would have to either maintain ConsoleKit or make something similar so Gnome could function on non-systemd distros. But no one is listening and no one is developing an alternative, so Gnome is left to use systemd-logind that is maintained, take bug fixes and have good features, or try to support ConsoleKit (they still do in Gnome 3.14 despite what people claim on systemd hate blogs). But as said; ConsoleKit isn't maintained, so Gnome can't have urgent CK bugs fixed.
Same with Wayland. The non-systemd crowd simply aren't helping upstream projects to make them still support non-systemd distros.

This Debian proposal is exactly about this; if this GR succeed, the non-systemd Debian crowd can _force_ developers to work on features that SysVinit needs. It is simply impossible to gather the necessary developer talent for doing so without such force.

There is actually good reason for why systemd is designed like it is. If people tried to re-implement systemd, they would face the exact same dilemmas that the systemd developers did, and probably solve them the same way.
If you remove certain parts from PID1, you will get an awful lot of overhead and communication between the new module and PID1. This isn't a trivial problem.

Another thing worth considering, that most of the things systemd deals with, are really hard low level stuff. Very few developers actually have the skills needed for dealing with session management like in "systemd-logind". So there are almost no independent developed "modules" that can be used to replace systemd "modules"; The no serious full alternative to "udev" or logind on any other init system. There is multi-seat support outside systemd either. Even journald has no real alternative, since rsyslog etc. can't get early boot log info, since unlike journald, they can't log info before the root filesystem is mounted.

So the alternative doesn't really exist anyway. The non-systemd proponents simply lack developers, especially low-level OS developers.

You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)

There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done:
http://lwn.net/Articles/512895...

That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world:
Here is an introduction to FSS:
http://lwn.net/Articles/512895...

The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...

They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...

There are systemd libraries and what not, and lots of documentation.

That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

It is trivial to read systemd journal files from a boot media. They can also just be copied to a USB stick or whatever and moved to another system for analyzing.

Every log entry line has rich meta-data, including machine name, UUID etc, so you will never be in doubt on which machine the log was generated on

You can forward journald messages directly to syslog-ng just by adding a line to /etc/systemd/journal.conf

rsyslog can now natively read (and write) systemd journal files, and make the usual text logs if that is what you want (or use forwarding). http://www.rsyslog.com/doc/imj...

the journald daemon listen to /dev/log where all log messages from all programs are directed to, and the journald then forward these messages to another syslog. It will strip them of meta data first.
Since the journald can get log messages from early boot before even the root filesystem is mounted, this is actually an enhancement of just using syslog.

The journald journal is primarily an append based system, so it is quite resistant to file corruption. The journald files are basically text files with another line delimiter and an index. journald has integrated logfile-verification and can therefore discover if something is wrong (it will then log-rotate etc).

I want systemd's binary logfiles because they are so much better than old style text log files. Having rich meta data with every log entry is simply too good a thing to have. Small things like monotonic time stamps are really handy, the ability to filter messages based on field values is simply awesome.

systemd's journal is really cool stuff. Don't be prejudiced against it and try it out in earnest.

If you are new to Linux, the systemd bianry logfiles are great; they are much easier to deal with than learning and memorizing a lot of "grep" switches.". Not that you can't use all the standard Linux text tools with the systemd logfiles, but you don't _have_ to.

Since the systemd journal has a stable API to accessing log file information, it is now actually possible to make a GUI log viewer that works properly.

I was skeptical about binary log files too, until I actually tried systemd properly and read up upon how systemd's journal functions. I am totally converted now, and will never go back to simple text log-files. Systemd's log implementation is simply so much better.

You don't have to use systemd tools to read systemd journal files. There already exist alternative readers, and systemd provides both a journal library and Python/Ruby/etc bindings for accessing the logs.

There are two ways of doing it: having rsyslog reading(and writing directly to the systemd journal:
http://www.rsyslog.com/doc/imj...
I think this is the default behavior these days with modern versions. More info here:

Else check :
"/etc/systemd/journald.conf"
And set:
"ForwardToSyslog=yes"

(only for syslog-ng or rsyslog versions that can't read the journal directly)

It is trivially easy to read systemd journal logs on remote machines.
Also, there already exist several journal readers since the log format is defined and have an API. So it is easy to have many different log readers installed for the "belt and suspender" types.
Even rsyslog reads journal files these days.

That is of course wrong. If you have a POSIX compliant system, you have binary logs in /var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.

I don't agree about logging. I think the systemd journal is a great improvment over legacy style old text dumps. Stuff like "journalctl -b -p err" (show only messages from this boot at log level "error"). So useful, so simple. Or "journalctl --since -15m" that shows the last 15 minutes of logging. Or "journalctl -f -u firewalld.service" that just tails the firewall service. There is bash completion of everything, from parameters to servicenames. There is kernel guarantee the entries aren't faked (all those field starting with underscore), meaning that if cups is writing "lpt0 on fire" in the journal, you can see if its a fake or real. (on syslog anything can pretend to be cups).
systemd is also able to gain logging info from when the system is only in the "initramfs" stage (systemd lives in initramfs during boot and then jumps to rootfs), before the root system is even mounted, something rsyslog can only dream of.

The journal is primarily an append only system (basically a text file with another newline separator + index), so it is quite robust against RW corruptions.

systemd's primary design goal is simplicity; it isn't a log sink like rsyslog, and won't have db drivers. It is however easy to export its content in e.g. JSON format by the journald-gateway, or let rsyslog, who can natively read journal files, convert it into any supported format etc. So using Splunk is trivial these days.

Monit and systemd aren't completely overlapping, so you can still run Monit on top of systemd, that way systemd can restart Monit if it fails :-). But it is a major selling point for systemd, that it comes with integrated service supervision "out-of-the-box" and in easy way too. Just add some keywords to a textfile, and away you go. Because systemd uses cgroups, it can track all processes and their child processes with ease, so its supervision abilities are quite awesome.
To simplify both projects; systemd has the technological superiority when it comes to the low level supervision stuff, while Monit has all the high level monitoring stuff, like graphs etc.

OS containers predates systemd deployment. But systemd intend to make them much better: systemd intend to make OS containers that runs unmodified on top of the host OS. As it is now, there isn't much security, but that is the next round: unmodified, secure OS containers; run a standard Ubuntu and a standard Fedora on top of CentOS (and make them socket activated too). Nobody else have such high ambitions.

Regarding RH. They hardly need to make themselves "relevant" since their revenue actually keeps on growing despite the international crisis. Not many other Linux distro vendors experience that. No slant intended against Canonical, but AFAIK they still loose money every year.

Besides, while Lennart Poettering is employed by RH, systemd have long been a multi-distro collaboration, with half a dozen developers from different distros and companies that have git commit access. There has been more than 600 independent contributors too. So it is a huge open source project, not a Red Hat solo show.

I know the pain of changing systems and workflow. It is understandable that people working close to systems have an aversion against changing stuff that works for them. Few people get paid for the luxury of learning new technology.

But systemd is actually a very rare watershed moment in Linux where some old fundamentals are being changed, and IMHO, systemd is an improvement in every area it touches; it is a better init system, provides awesome logging, exposes hard to use kernel features like cgroups, "capabilities(7)" and "namespaces", and make them a breeze to use: just ad a single keyword in a text config file, restart the service and you can enable cgroups features or prevent privilege escalation etc.

Total service supervision, including systemd itself. Really advanced rate limiting and service restart features, like "don't restart the service if manually shut down", or "don't try to restart the service more than 3 times within 10 minutes".

You can drop hard to maintain code if your service needs to drop privileges after startup, and just use systemd's inbuilt features.

start a new OS container in seconds to play around with, etc.

I can only encourage you to start learning systemd properly; at the moment all the commercial and non-commercial LTS distros will switch to systemd. I think even Slackware will change to systemd down the road, since there is practically zero development going on in the non-systemd camp at the moment.

Take it a bit at the time; there is so much new to learn. Try a systemd distro like Fedora 20's KDE spin, or Debian "Jessie" (should be in beta by now), perhaps in a VM.
systemd really is the future, and it really have a lot to offer.

I can see what you mean, but it wasn't intended as such.

Well, it is the opinion of David Hermann that it exactly belongs in systemd. Since he is the author of kmscon and consoled, I doubt that anybody knows more about VT's than he does at the moment. Since the vast majority of Linux distros are going to be systemd based in the future, it makes so much sense to make systemd optimized VT's. Just the fact that systemd is the only game in town when it comes to multi-seat is justification alone.

Really, what is the problem with systemd gaining features like consoled? It takes nothing away for the tiny minority of non-systemd distros; they can still use kernel VT's if they want, or use kmscon if they care about features and bug fixing. Why are non-systemd user so obsessed and possessive about the systemd code? Use it if you want, fork it and use it they way you want, or make an alternative.

I can't really take your comment seriously about systemd features being coupled together with no good reason. I have yet to see a systemd-opponent that have any real experience with systemd or even have read all the documentation and man pages.

The systemd developers give good and detailed reasons for why they do what they do, but systemd-opponents seemingly prefer to get their systemd information from the many tin foil hat, swivel eyed, systemd-hating, loony blogs, instead of actually reading up on the subject.

Don't like systemd? Fine by me, just remember that it is all up to you to make the non-systemd distro working. So don't whine about what systemd developers does or doesn't, but concentrate on making your own alternative. Just attacking systemd gets you nowhere.