I don't like the ideal of binary log files, but I can get behind everything else.
Well, just use rsyslog/syslog-ng like you always have. That way you have the usual flat file text logs while having all the other benefits of using systemd.
Anybody having working with computers for a long time tends to be vary of binary formats. I have had a lot of bad experiences with binary formats over the decades. But using systemd's journal made me realize that what I really want is config files that are text based, and having binary data isn't such a big deal as long as it is an open standard and the tools are both standard and of high quality. systemd provides me with exactly that.
All the standard Linux text tools like "grep" and "wc" etc. works perfectly together with systemd's binary journal, by using the standard Linux concept of piping, so nothing is lost, but many new features like having monotonic timestamps are gained.
have nothing against binary log files per sé, but they should not be the primary and only option. Instead of hanging rsyslog after journald, I'd rather see it reversed, first plain-text logging to syslog and eventually piped to binary logging afterwards (or parallel to both, whatever). That way, all the info is still available in case the binary log files get corrupted for one reason or another, and people still have their easily searchable binary logfiles. Also it'd make it easier for other remote-logging tools to hook in with the already existing syslog infrastructure than hook on to journald.
It doesn't make sense to go from text to binary format as default. Remember that a key point in having a structured and indexed binary log file is that you can keep all kinds of rich meta data info in each log entry, like monotonic timestamps, high precision time markers, system UUID's, etc.. If you put all those meta data fields directly into the flat text file, every log entry line will become insanely long and complex, making it much less human readable.
The present solution with systemd making all the local log entries in binary form, and then use rsyslog for converting it to legacy flat file format, or placing it a database while preserving the rich meta-data is a really good solution with few drawbacks and many great advantages. In this way, systemd is actually enhancing rsyslog's capabilities. Using either journald-gateway or rsyslog to remote logging can now preserve the rich meta data too.
I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.
Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?
Good questions. The reasons are complicated, but I will try as best as I can. When journald was made it was constrained by several design parameters: it should have total backward compatibility for those needing this, it couldn't require that any userspace program should be rewritten in order to work with it, including syslog implementations like rsyslog. It should simply be a drop in replacement, giving people the opportunity to use its enhanced features if they wanted to, or just use the usual rsyslog setup they always had used. It should also be as simple and fast as possible. In fact, the journal more or less an append text file with other newline delimiters and an added index.
And because journald worked with syslog, people could use rsyslog for all their advanced database logging needs. In short, journald makes it flexible for those who have advanced needs, instead of tying them down to a particular solution. Unlike rsyslog, journald isn't a log sink (and hopefully never will be).
All in all, making sweeping and complex changes like using a real RDBMS as a logging back end wasn't an option. Also, such RDBMS solutions already exist in a mature state in e.g. rsyslog, so there was no need either.
There are other design constrains concerning logging on Linux. At the moment everything goes into/dev/log, and only one program can read it a time. AFAIK, you have to rework both the way the kernel does logging and user space loggers in order to have more than one program reading log info from the source. The solution seems to requires using kernel namespaces and other low level systems, and are likely to require that both kernel version and user space loggers are synced to a certain version in order to work. So AFAIK, it isn't easy to make a early-boot-log helper that hands over logging to syslog when it is done, at least not in a lossless way and certainly not if the helper logs are meant to be incorporated into the syslog flat text files (which is why eg. dmesg is a separate log file).
As for logging being "married" to init, the main argument was, that in order to have first class service and process management, you need a matching first class logging system. In order to have early and late boot log messages, the init system have to be aware of a lot of low level system stuff, and cooperate extensively with the logging system. They could have used rsyslog and changed it so it worked like the journald works, but that would have tied all systemd Linux distros to a particular syslog implementation.
Having them working together also makes it trivial to attach log messages to a service check.
Are binary log files a necessity of the systemd design? Absolute not. But then again, people who prefer flat text files for logs can just use rsyslog/syslog-ng as they always have. The binary log files are optional. But the binary, structured and indexed journal log do solve so many limitations of flat text files that I am glad it exist as an option. The systemd journal really is a joy to use.
The distributions should be wary of putting all their eggs in the freedesktop.org basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.
Dude, freedesktop.org is just a code repo like github, so they also host e.g. an OpenCL compiler. Sure, the site is also used for inter distro discussions and informal work groups, but implying that systemd is a desktop thing only since it hosted on freedesktop.org is just laughable.
When you got the time, please read up on the systemd project to see what it is all about: This is an excellent starting point: http://www.freedesktop.org/wik...
Or that there are no known bugs to fix and haven't been in ages.
That's what happens when you follow the KISS principle.
Just look at the Debian SysVinit bug tracker. Of course there are bugs. I don't claim that there are serious showstopper bugs, but they are there, and sometimes they are even fixed. Feeding such bug fixes back to the upstream project is normal Linux practice, but for the last several years, such bugfixes haven't been mainlined with upstream SysVinit, making SUSE/RH the de facto Upstream now, and both those distros are about to outphase SysVinit.
I don't say that eg. GNU/SysVinit is understaffed is a unsolvable problem. But what I do say is, that those who will continue to use SysVinit have the responsibility to make and maintain all the necessary code themselves for being able to do so, including helping out SysVinit.
The non-systemd camp can no longer rely on paid developers from commercial distros solving all their problems. There is a long list of stuff that needs to be done, right now and in the near future in order to run a SysVinit distro without it degrading slowly and falling hopelessly behind in features.
That the kernel buffers some kernel log files during boot really is independent of what init system there is. But as you can see when studying dmesg output, it only have "internal" kernel messages. It really doesn't know anything of mount points etc., so that leaves a gap between the kernel dmesg output and when syslog finally is ready. systemd plug that gap by being able to log events while in initramfs.
Please tell me why it is needed for servers. What does it replace that was broken in servers? It has nothing to do with relearning things, it has to do with a solution looking for a break, when there is not one. And you are still ignoring the blatant examples of it NOT WORKING
It has a total process and service supervision chain, including systemd as PID1. It simply does everything better that SysVinit does, including when all the hack tools are bolted on. It can also deal with OS containers, which will becomes just as important as VM's are now. It exposes powerful kernel features like cgroups, kernel capabilities and namespaces in an easy to use fashion, providing strong security and useful features out of the box. Want to limit a service to only 50% CPU resources on a certain CPU? Just add a simple keyword to structured text config file and restart the service. Since systemd have total supervision of all processes, it will track all the sub-processes that the service spawns too, and place them under the 50% limit.
I could go on, but it really seems to me that you haven't done a serious study of systemd with an open mind. Considering that all the commercial distros are switching to systemd, it is a worthwhile thing to do for anybody with professional interest in Linux.
Unix wasn't even born with the now basic concept of "piping", it was a development over time.
It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.
As I said, Unix wasn't even born with piping, it was a later development. And of course, Unix wasn't born fully fledged with all features and made according to some pre-existing Unix philosophy. They were pioneers in much what they did after all.
My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.
The systemd developers really did their homework well when designing the systemd log implementation
No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless.
Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.
Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.
Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping. It is a very Unix way of dealing with such "problems". Anyway, "grep" can learn to understand the journal file structure, so you can have a "jgrep" just like there is a "zipgrep" for dealing with zipped syslog files. I am sure that grep have been modified before to deal with new things like UTF-8 etc.
If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.
Not having the right tools in the box is simply a shameful thing for a paid SysAdmin. How do you expect to read a LVM volume or a new filesystem by using random, perhaps outdated tools? It is such a basic requisite to have a working boot media. And yes, some old rescue discs doesn't support reading journal files yet, but it was the same situation with LVM and btrfs etc. If you didn't have an up to date boot media or similar, you couldn't mount or read the content of the LVM/btrfs disc.
It is so trivial to read and analyze journal log files on other computers or through a boot media. Since the journal has both a stable API and language bindings, several non-systemd journal readers will pop up over time too.
Anybody who has a free choice in which distro to run can always choose e.g. Slackware. Nobody is stuck with systemd on their home server against their will.
I really like systemd, but I applaud any serious attempt to make a distro with alternative ways of doing things. Competition is good.
As argued, I think there is a pressing need for the non-systemd camp that they make a long term distro a focal point for the needed development of non-systemd infrastructure (cgroups, udev, ConsoleKit, etc). It will be much better for the non-systemd camp to fork Debian, than to continue with it since it will become a full systemd distro in the end.
As it is now, the non-systemd camp is entirely scattered and un-organised. It is every distro for it self. Cooperation and making a developer community is crucial if non-systemd distro are going to survive this decade.
You got to be joking, systemd is much more flexible than anything else on non-systemd distros. And it is trivial to extend for third party developers since it has lots of libraries, stable API's and language bindings, something no other alternative have.
If you really think systemd isn't needed for servers, you simply haven't done a serious study of it. I have no problem with people not wanting to use systemd, but please don't reject it out of ignorance.
Yes, a lot of SA's have to relearn a lot of things, including how do debug problems, boot sequences, how to use cgroups and use the systemd kernel security features etc. Experience helps, but is no substitute for learning. These things happens once in a while in tech.
However, this still isn't a reason to force systemd, since we have around a dozen init systems out there, most of which are directly compatible with sysvinit.
Nobody is forcing systemd on anybody. That all the major distros have chosen systemd, is because it is so technical superior in every way to any alternative out there, and because it makes life easier for distro maintainers and developers, and actually help upstream projects by providing them with needed features and some sort of cross distro compatibility layer.
As you say there are lots of other init systems out there. However, in order to be a viable alternative to systemd, the non-systemd camp have to take control and start developing _all_ the necessary infrastructure code necessary, like ConsoleKit, cgroups, kdbus, udev, etc.
Of course we think UNIX should continue to evolve. But we think it should improve. Taking ideas from OSX and Windows is not making things better. If you want a polestar to navigate by, look at Plan 9.
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.
So it hasn't actually needed a change in years (meaning it is fully matured) but you're worried that there isn't enough manpower to churn the code (that needs no churning)?!?
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.
Why in the world would Xorg need systemd? It doesn't need it now.
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...
Yes, bugs are a problem, but that's not what you said. You said it is bad because they haven't had a release in five years.
That shows a huge problem in your understanding of system design, which you should fix now or continue making poor systems. Stability in a core system component is a good thing, not a bad thing. Don't forget it and your code will be better.
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.
Even SysVinit isn't in such a hot state, it haven't made a release in five years
This kind of stability is a good thing.....once you get a tool right, it shouldn't need to change much.
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.
It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.
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.
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
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.
I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.
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.
I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.
Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed?...
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.
To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.
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.
Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?
When I use gimp, pidgin, geany etc on a Windows desktop, it's because they consistently work well with a thin Gtk+ shim over Win32. That's without installing a Linux compatibility layer like cygwin.
If in future one has to install some cygwin-systemd abomination just to run Gimp, then free software will have lost a fan.
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.
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.
> Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?
No, what we want is for systemd to not be forced on us as a way to destroy any chance of running a graphical environment in the future. Wayland compositors, GNOME and various other things are starting to require systemd. That is why everyone is upset. Linux users may also not like systemd and that is another issue.
The forced nature of systemd means that every linux distro must switch and that *BSD people may have to fork X or wayland (if it takes off) in the future in order to have a damn GUI.
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.
Break up systemd into its components and let certain functionality of it be augmented or replaced by sysvinit.
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.
Slashdot Mirror
I don't like the ideal of binary log files, but I can get behind everything else.
Well, just use rsyslog/syslog-ng like you always have. That way you have the usual flat file text logs while having all the other benefits of using systemd.
Anybody having working with computers for a long time tends to be vary of binary formats. I have had a lot of bad experiences with binary formats over the decades. But using systemd's journal made me realize that what I really want is config files that are text based, and having binary data isn't such a big deal as long as it is an open standard and the tools are both standard and of high quality. systemd provides me with exactly that.
All the standard Linux text tools like "grep" and "wc" etc. works perfectly together with systemd's binary journal, by using the standard Linux concept of piping, so nothing is lost, but many new features like having monotonic timestamps are gained.
have nothing against binary log files per sé, but they should not be the primary and only option. Instead of hanging rsyslog after journald, I'd rather see it reversed, first plain-text logging to syslog and eventually piped to binary logging afterwards (or parallel to both, whatever). That way, all the info is still available in case the binary log files get corrupted for one reason or another, and people still have their easily searchable binary logfiles.
Also it'd make it easier for other remote-logging tools to hook in with the already existing syslog infrastructure than hook on to journald.
It doesn't make sense to go from text to binary format as default. Remember that a key point in having a structured and indexed binary log file is that you can keep all kinds of rich meta data info in each log entry, like monotonic timestamps, high precision time markers, system UUID's, etc.. If you put all those meta data fields directly into the flat text file, every log entry line will become insanely long and complex, making it much less human readable.
The present solution with systemd making all the local log entries in binary form, and then use rsyslog for converting it to legacy flat file format, or placing it a database while preserving the rich meta-data is a really good solution with few drawbacks and many great advantages. In this way, systemd is actually enhancing rsyslog's capabilities. Using either journald-gateway or rsyslog to remote logging can now preserve the rich meta data too.
I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.
Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?
Good questions. The reasons are complicated, but I will try as best as I can.
When journald was made it was constrained by several design parameters: it should have total backward compatibility for those needing this, it couldn't require that any userspace program should be rewritten in order to work with it, including syslog implementations like rsyslog. It should simply be a drop in replacement, giving people the opportunity to use its enhanced features if they wanted to, or just use the usual rsyslog setup they always had used. It should also be as simple and fast as possible. In fact, the journal more or less an append text file with other newline delimiters and an added index.
And because journald worked with syslog, people could use rsyslog for all their advanced database logging needs. In short, journald makes it flexible for those who have advanced needs, instead of tying them down to a particular solution. Unlike rsyslog, journald isn't a log sink (and hopefully never will be).
All in all, making sweeping and complex changes like using a real RDBMS as a logging back end wasn't an option. Also, such RDBMS solutions already exist in a mature state in e.g. rsyslog, so there was no need either.
There are other design constrains concerning logging on Linux. At the moment everything goes into /dev/log, and only one program can read it a time. AFAIK, you have to rework both the way the kernel does logging and user space loggers in order to have more than one program reading log info from the source. The solution seems to requires using kernel namespaces and other low level systems, and are likely to require that both kernel version and user space loggers are synced to a certain version in order to work.
So AFAIK, it isn't easy to make a early-boot-log helper that hands over logging to syslog when it is done, at least not in a lossless way and certainly not if the helper logs are meant to be incorporated into the syslog flat text files (which is why eg. dmesg is a separate log file).
As for logging being "married" to init, the main argument was, that in order to have first class service and process management, you need a matching first class logging system. In order to have early and late boot log messages, the init system have to be aware of a lot of low level system stuff, and cooperate extensively with the logging system. They could have used rsyslog and changed it so it worked like the journald works, but that would have tied all systemd Linux distros to a particular syslog implementation.
Having them working together also makes it trivial to attach log messages to a service check.
Are binary log files a necessity of the systemd design? Absolute not. But then again, people who prefer flat text files for logs can just use rsyslog/syslog-ng as they always have. The binary log files are optional. But the binary, structured and indexed journal log do solve so many limitations of flat text files that I am glad it exist as an option. The systemd journal really is a joy to use.
The distributions should be wary of putting all their eggs in the freedesktop.org basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.
Dude, freedesktop.org is just a code repo like github, so they also host e.g. an OpenCL compiler. Sure, the site is also used for inter distro discussions and informal work groups, but implying that systemd is a desktop thing only since it hosted on freedesktop.org is just laughable.
When you got the time, please read up on the systemd project to see what it is all about:
This is an excellent starting point: http://www.freedesktop.org/wik...
Or that there are no known bugs to fix and haven't been in ages.
That's what happens when you follow the KISS principle.
Just look at the Debian SysVinit bug tracker. Of course there are bugs. I don't claim that there are serious showstopper bugs, but they are there, and sometimes they are even fixed. Feeding such bug fixes back to the upstream project is normal Linux practice, but for the last several years, such bugfixes haven't been mainlined with upstream SysVinit, making SUSE/RH the de facto Upstream now, and both those distros are about to outphase SysVinit.
I don't say that eg. GNU/SysVinit is understaffed is a unsolvable problem. But what I do say is, that those who will continue to use SysVinit have the responsibility to make and maintain all the necessary code themselves for being able to do so, including helping out SysVinit.
The non-systemd camp can no longer rely on paid developers from commercial distros solving all their problems. There is a long list of stuff that needs to be done, right now and in the near future in order to run a SysVinit distro without it degrading slowly and falling hopelessly behind in features.
That the kernel buffers some kernel log files during boot really is independent of what init system there is. But as you can see when studying dmesg output, it only have "internal" kernel messages. It really doesn't know anything of mount points etc., so that leaves a gap between the kernel dmesg output and when syslog finally is ready. systemd plug that gap by being able to log events while in initramfs.
Please tell me why it is needed for servers. What does it replace that was broken in servers? It has nothing to do with relearning things, it has to do with a solution looking for a break, when there is not one. And you are still ignoring the blatant examples of it NOT WORKING
It has a total process and service supervision chain, including systemd as PID1. It simply does everything better that SysVinit does, including when all the hack tools are bolted on. It can also deal with OS containers, which will becomes just as important as VM's are now. It exposes powerful kernel features like cgroups, kernel capabilities and namespaces in an easy to use fashion, providing strong security and useful features out of the box. Want to limit a service to only 50% CPU resources on a certain CPU? Just add a simple keyword to structured text config file and restart the service. Since systemd have total supervision of all processes, it will track all the sub-processes that the service spawns too, and place them under the 50% limit.
I could go on, but it really seems to me that you haven't done a serious study of systemd with an open mind. Considering that all the commercial distros are switching to systemd, it is a worthwhile thing to do for anybody with professional interest in Linux.
Unix wasn't even born with the now basic concept of "piping", it was a development over time.
It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.
As I said, Unix wasn't even born with piping, it was a later development. And of course, Unix wasn't born fully fledged with all features and made according to some pre-existing Unix philosophy. They were pioneers in much what they did after all.
My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.
The systemd developers really did their homework well when designing the systemd log implementation
No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless.
Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.
Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.
Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping. It is a very Unix way of dealing with such "problems".
Anyway, "grep" can learn to understand the journal file structure, so you can have a "jgrep" just like there is a "zipgrep" for dealing with zipped syslog files. I am sure that grep have been modified before to deal with new things like UTF-8 etc.
If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.
Not having the right tools in the box is simply a shameful thing for a paid SysAdmin. How do you expect to read a LVM volume or a new filesystem by using random, perhaps outdated tools?
It is such a basic requisite to have a working boot media. And yes, some old rescue discs doesn't support reading journal files yet, but it was the same situation with LVM and btrfs etc. If you didn't have an up to date boot media or similar, you couldn't mount or read the content of the LVM/btrfs disc.
It is so trivial to read and analyze journal log files on other computers or through a boot media. Since the journal has both a stable API and language bindings, several non-systemd journal readers will pop up over time too.
Anybody who has a free choice in which distro to run can always choose e.g. Slackware. Nobody is stuck with systemd on their home server against their will.
I really like systemd, but I applaud any serious attempt to make a distro with alternative ways of doing things. Competition is good.
As argued, I think there is a pressing need for the non-systemd camp that they make a long term distro a focal point for the needed development of non-systemd infrastructure (cgroups, udev, ConsoleKit, etc). It will be much better for the non-systemd camp to fork Debian, than to continue with it since it will become a full systemd distro in the end.
As it is now, the non-systemd camp is entirely scattered and un-organised. It is every distro for it self. Cooperation and making a developer community is crucial if non-systemd distro are going to survive this decade.
You got to be joking, systemd is much more flexible than anything else on non-systemd distros. And it is trivial to extend for third party developers since it has lots of libraries, stable API's and language bindings, something no other alternative have.
If you really think systemd isn't needed for servers, you simply haven't done a serious study of it. I have no problem with people not wanting to use systemd, but please don't reject it out of ignorance.
Yes, a lot of SA's have to relearn a lot of things, including how do debug problems, boot sequences, how to use cgroups and use the systemd kernel security features etc. Experience helps, but is no substitute for learning. These things happens once in a while in tech.
So much for GNU/Linux.
However, this still isn't a reason to force systemd, since we have around a dozen init systems out there, most of which are directly compatible with sysvinit.
Nobody is forcing systemd on anybody. That all the major distros have chosen systemd, is because it is so technical superior in every way to any alternative out there, and because it makes life easier for distro maintainers and developers, and actually help upstream projects by providing them with needed features and some sort of cross distro compatibility layer.
As you say there are lots of other init systems out there. However, in order to be a viable alternative to systemd, the non-systemd camp have to take control and start developing _all_ the necessary infrastructure code necessary, like ConsoleKit, cgroups, kdbus, udev, etc.
Of course we think UNIX should continue to evolve. But we think it should improve. Taking ideas from OSX and Windows is not making things better. If you want a polestar to navigate by, look at Plan 9.
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.
So it hasn't actually needed a change in years (meaning it is fully matured) but you're worried that there isn't enough manpower to churn the code (that needs no churning)?!?
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.
Why in the world would Xorg need systemd? It doesn't need it now.
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...
Yes, bugs are a problem, but that's not what you said. You said it is bad because they haven't had a release in five years.
That shows a huge problem in your understanding of system design, which you should fix now or continue making poor systems. Stability in a core system component is a good thing, not a bad thing. Don't forget it and your code will be better.
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.
Even SysVinit isn't in such a hot state, it haven't made a release in five years
This kind of stability is a good thing.....once you get a tool right, it shouldn't need to change much.
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.
It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.
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.
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
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.
I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.
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.
I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.
Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed?...
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.
To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.
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.
When I use gimp, pidgin, geany etc on a Windows desktop, it's because they consistently work well with a thin Gtk+ shim over Win32. That's without installing a Linux compatibility layer like cygwin.
If in future one has to install some cygwin-systemd abomination just to run Gimp, then free software will have lost a fan.
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.
> Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?
No, what we want is for systemd to not be forced on us as a way to destroy any chance of running a graphical environment in the future. Wayland compositors, GNOME and various other things are starting to require systemd. That is why everyone is upset. Linux users may also not like systemd and that is another issue.
The forced nature of systemd means that every linux distro must switch and that *BSD people may have to fork X or wayland (if it takes off) in the future in order to have a damn GUI.
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.
Break up systemd into its components and let certain functionality of it be augmented or replaced by sysvinit.
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.