The problem is that nobody really develops for non-systemd distros anymore. Sure, a loud minority is constantly attacking systemd, but they don't bother with developing crucial software needed to run non-systemd distros, nor do they help upstream projects to support them either.

The reason why upstream projects depend on systemd, is because systemd provides essential low level stuff that nothing else really provides on Linux.
There will probably be no problem with running Gimp etc. on Windows (or OSX) simply because those OS's have the necessary low level stuff to keep modern software running, so the projects can just use that instead of systemd.

It is pretty common to "vet" academic papers before publishing, so that other people can give a qualified input etc. So it is hardly surprising that Lennart had "early access" to the paper. As I understand it, then "Forward security" is a pretty old crypto concept. What Marson and Poettering did was tweaking the concept to log files which represents special problems to more static texts like emails, and use the concept for sealing, not encryption. The concept seems sound and have been formally peer reviewed.

Here is the paper in case you haven't read it:
https://eprint.iacr.org/2013/3...

Sure, systemd's journal with its advanced and rich meta data works very well with database logging, much better than the old legacy style syslog text dumps. This is hardly surprising.

But database logging is also much more complex which is why it is only used on large setups with syslog, and the systemd's journal is designed with simplicity as a primary design goal, so it works with all the standard Linux text tools like grep, tee, less, etc.

Systemd's journal can be used as a drop in replacement for syslog with total backwards compatibility, including in-house made watch scripts, or it can be used as a next generation syslog with a stable API for generating watch scripts (finally!), and providing rich meta data like monotonic timestamps.

I don't know how you got the idea that grep etc. doesn't work with the journal?
"journalctl -b -p err | grep -i ata | tee sata-errorlog.txt" works brilliantly: show all log entries from this boot that have error log level "error", grep it for "ata" and tee the result into a textfile. Think of "journalctl" as the most powerful log filter tool you have ever seen. It works perfectly with the standard Linux tools.

Anyway, you can still use rsyslog or whatever together with systemd. You even gain the benefits of early boot logs (journald can log from before the root filesystem is even mounted while living in initramfs). I did too in the beginning, but removed it when I got to know systemd better. Forget about what other people say about systemd's binary logs, and try them yourself; it is really good stuff.

Yes, you are correct. Status quo can't be maintained without development. ConsoleKit worked, and if it was maintained it could still be a working solution, but it has been deprecated for years now.

That is the problem in a nutshell; the non-systemd distros have the sole responsibility for maintaining and developing the necessary code for making a non-systemd distro run.

Oh, and stop getting your "information" about systemd from the tin foil hat systemd hate-blogs, they are so filled of misinformation it is laughable. Gnome, including the lates Gnome 3.14 still supports ConsoleKit: http://blogs.gnome.org/ovitter...

They are not happy about developing against dead software that can't be bugfixed though, and they have said so for years. But the systemd-opponents don't care at all about that, they don't care about helping upstream projects support their ever dwindling numbers of distros, all they seemingly wants to do, is ranting all day long about how bad systemd is.
All rant and no code.

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.