A dead OS that haven't had a release in over a decade can hardly be a "polestar" for future Linux development.

I prefer "Linux philosophy" over "Unix philosophy" any day, because Linus Torvalds opinions are, that Linux is all about solving real world problems in the best manner possible, not adhering to any current fashion-of-today among OS designers. This is why he choose a monolithic kernel design, even though micro kernels where all the rage and the "right thing to do" at the time.
Plan 9 is probably a beautiful implementation of "everything is a file", is just happened to forget its users in the pursuit of that inflexible dogma, so it withered and died.
The same will happen to every OS that stand still and refuses to develop to solve contemporary problems.

These days certified Unix's are practically dead except Oracle Solaris and Mac OSX, and they both have an init system that resembles systemd. No wonder since the systemd developers studied launchd and SMF extensively before making systemd. taking what they liked, and dropping other things like XML config files.

systemd is simply an improvement overall in all areas in it deals with, compared to the old style legacy init systems with their executable config files.

I am not worried since I use systemd and will never run a SysVinit distro again in my life. My point was that those who doesn't want to run systemd need to realize that a lot of work is needed in the future, and that the non-systemd camp is entirely responsible for making and maintaining the necessary code in order to e.g. run SysVinit in the future.

Trying to making a virtue out the fact that SysVinit is understaffed (and this is going to get worse when the paid developers from SUSE/RH stops making bugfixes that other distros can leach), seems to be a common reaction among non-systemd users.

There seems to be a lot of reality denying going on among non-systemd users; denial that work is needed to even maintain status quo, that only they are responsible for making it so, and that sitting under the palms waiting for a magical appearance of a non-systemd alternative simply will disappoint.

The failure to realize these future challenges and the lack of coordination and development to face such challenges, will simply doom all general purpose non-systemd distros in the future.

In order to run X.org without root rights in a safe manner on Linux, you need something to deal with user sessions. Only systemd provides that. Here is a fosdem talk about it:
https://archive.fosdem.org/201...

Yeah, it is bad that there are outstanding bugs and they aren't being fixed. That is the case with SysVinit. These days SysVinit bugs are being fixed in distro repos, meaning that every sysvinit distro potentially got different releases, and the bug fixes aren't being mainlined with the GNU SysVinit. Not having a release in so many years is a sign of trouble, not stability.

You seem to misunderstand the sorry state of SysVinit; all the bugfixes are upstreams in SUSE/RH packages, not in any official release of GNU SysVinit. The SysVinit developers doesn't even have a proper test framework, so the only way to test a patch is by installing it and reboot, hoping the system will come up.

When SUSE/RH drops their engagement in SysVinit, it will decay even more.

Not having a official release of SysVinit for so many years, or even a "beta/developer" release, isn't a sign of maturity, but lack of developers.

Yes, they are split among those who think SysVinit should be used the next 40 years too, and those who recognize something else is needed for modern computing needs. Even the latter group is sub-divided into factions about one should make an improved systemd clone for compatibility reasons, or use OpenRC for BSD reasons, or making something new etc.

So instead of focusing on making a developer community to counter systemd with new code, they focused on a negative campaign against systemd instead. It is so much easier to rant on the net than organizing and making stuff happening. But that negative strategy is also the single most important reason why systemd-opponents have been routed whole-sale from every major distro; they attacked open source developers and projects, while failing to provide an alternative.

Agree about the Unix thing. "Unix philosophy" It has become a cartoonish mockery of all the great things the Unix developers did back in 60's and 70's. Totally without content and with no connection to reality.

Sure, the problem is "What is Unix Philosphy"? and is it meant as a dogmatic ex cathedra so that Unix can never deviate from whatever that philosophy is, no matter that computing changes every decade with new domain problems?

Unix wasn't even born with the now basic concept of "piping", it was a development over time. So I think that the so called "Unix Philosophy" is much more about sound guidelines and how the Unix developers tackled the computing problems in their day, than any dogma that can't be deviated from.

These days we have massive use of Linux OS containers and VM's, using petabyte of storage spread across continents and many other domain problems that was unheard of in the 1960's. I do think that the present development and use of Linux in so many ways, also require new ways for Linux to function. If Linux is put in a 1990's time freeze it will simply become irrelevant and wither away.

You can still use the same old flat text files logs with systemd distros by using rsyslog like you always had. Nothing is taken away, and in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.

I was really skeptical about binary log files before I tried it, but walked away convinced that binary logs like those used by systemd's journald, is the way forward.
They really solve so many hard/impossible to fix problems with flat text file logs, and I have yet to find any real world problems with their actual implementation. All the usual Linux text tools like "grep" and "tee" works with the systemd journals through the basic Unix concept of piping.

The systemd developers really did their homework well when designing the systemd log implementation, and it is worth a serious study by anybody working with Linux, instead of a upfront dismissal just because they are binary.

Using scripts (basically executable config files) to start daemons is probably a relic of the time when invented decades ago. The needs where much simpler in those days, and shell scripts was just a handy tool to have a quick and dirty solution to the problem. It haven't made sense for a decade at least to still using SysVinit and similar solutions, and all? certified Unix'es have switched long ago. In fact, launchd and Solaris SMF where major inspiration points for systemd.

It is quite doable to make a init system that uses declarative statements in text config files, both systemd and SMF does it. But it wouldn't be SysVinit anymore, so which distro will actually use such a init system? Slackware has its own style of SysVinit and is extremely conservative, an unlikely distro to change from what is has. Gentoo has OpenRC, and is also highly unlikely to change from that too.

So while possible to make, it is probably hard to find "buyers" for such a new init system, and therefore also developers to make it.

Debian doesn't have a big pool of paid developers they channel into whatever project they wishes. The Debian technical committee is just doing the only sensible thing in choosing a working, well maintained init system for Jessie, instead of a not-quite-here/vapourware/unproven init system so close to the freezing of Jessie.

That decision doesn't prevent anybody from actually making an init systems that is better than systemd and the Debian could adopt for Jessie+1 (the decision was strictly for Jessie).
There has to be real tangible code and some track record for such a project to have a realistic change of being the new Debian init system however.

There are +150 Debian forks (derivates) already, so yet another one hardly matters. The main reason why its is an empty "threat" is that there basically isn't any real development of needed infrastructure in the non-systemd camp, and as time goes by, more and more alternative development will be need by non-systemd distros.

The fork of systemd's "udev", "eudev", is basically just a shadow fork with patches, but soon eudev maintainers have to decide between having to support a kdbus manager, thereby become more developers instead of just patch maintainers, or their fork will deviate so much from the real udev, that they no longer just can leech new patches from it.

Of course, ConsoleKit is still dead with nobody picking up development, the only alternative is a rather limited implementation of systemd-logind, and is basically maintained by a Canonical developer who are unlikely to maintain it after Canonical have switched to systemd.

Stuff like root-less X.org can at the moment only be safely done by systemd. Some Wayland implementations will also depend on systemd simply because the upstream projects aren't getting any help at all in supporting non-systemd distros.

Even SysVinit isn't in such a hot state, it haven't made a release in five years, and the defacto upstream maintainers have been SUSE/Reed Hat for years. At some point they will drop maintaining it anymore.

I could go on, but the fact is that there is an increasing amount of work needed to be done, just in order to keep status quo somewhat, and that the non-systemd camp are severely lacking developers that could help maintaining such critical infrastructure.

It would actually be quite good for the non-systemd camp if there was a proper Debian fork that solely was about non-systemd developemnt. They have been lacking a focal point for such development for a long term stable distro for years (Slackware, despite its merits, is ultra conservative and probably too limited in certain ways for this).

The problem is that some factions in the non-systemd camp are pursuing systemd "emulation" by using shims and forks. That way you just get a second rate systemd, and it will remove any motivation from upstream projects to support anything else than system. Using Ubuntu's "logind" is a short term gain, but a strategic failure for the non-systemd camp. They need their own implementation of needed infrastructure, not just copying or emulating systemd.

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