Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs.
Systemd's journal also collects all logs in the same place, so no need to use "last" to read the binary "wtmp" log files, or locate .xsessionerrors and what not; everything goes into the journal.

Also, all the usual text tools like grep, tee, sed etc. all works with the journal by the standard Unix concept of piping. "journalctl" simply enhances the Unix text tools.

Give "journalctl" a serious spin someday; you may like it.

Yes, freedom isn't a given thing. It may cost something to gain it or keep it.

Anyway, thank you for a pleasant conversation.

Hm, I would prefer less extreme options, but I certainly agree that some fragmentation is to be preferred to a very uniform Linux. I mean, I like systemd and I do think the systemd group have some very good ideas, but they certainly don't include e.g. KDE in that future as anything else than token gestures. I would be very unhappy if Gnome ruled the Linux desktop without real competition. I have no animosity against Gnome, I just love KDE.
So there...

I agree with the general gist of what you say; Linux will only be healthy with at least some internal competition of ideas and how to implement them. As it is now, people can move from e.g. Linux KDE to Linux Gnome, if the KDE direction bothers them. With only one DE on Linux, they can only move to other OS's if they don't like what they get.
The same thing also applies to low level libraries, programming languages etc.

But on the other hand, to reduce the fragmentation is also very worthwhile goal, so I would hope that systemd could be compromise between the two extremes. IMHO, I do think systemd so technically superior to all other script based init systems, that it barely has any real technical competition anyway.

Regarding systemd as long term solution, and lock in. In some ways I think systemd have paved the way making future init system shifts much easier; with rather firm external API's it is much easier to gain momentum if the new solution is backwards compatible.

The new direction could either be a fork that later changed in a new direction, or a whole new system, that just provided external compatibility like systemd did. I am not suggesting that especially the latter will be easy, but it is doable, and since almost all distros at that point would be using systemd, they could easily change init system.
It would not be a one man solution, however; organizing and cross distro cooperation would be the key to success

As it is now, I think that a fork of systemd is the most realistic long term solution, if one find it necessary that Linux have competing projects on every level.

To me systemd is the best thing ever happening to my distro since package management, but I have no problems with people having other ideas for what they like with their distros.

My rather bleak predictions all rest on the current lack of development and the many challenges ahead, with more developers and more cooperation most of the problems can be solved.

Regarding the many different Linux configurations, then I agree with you in principle. But I don't think the fragmentation of Linux has been really helpful either. It is clear that there now is a major push to reduce Linux fragmentation.

I think the only way the smaller distros will have a say in the new direction Linux is taking at the moment, is to organize and counter it with their own proposals.

I think the "every distro is a separate island" doing everything their own particular way, is something that will disappear. But perhaps that isn't so bad, maybe the interesting thing about different distros, aren't that they all place their shared libs in different subdirs, but rather, what software platform they deliver above the system level. Less Linux fragmentation will definitely make it easier for distro maintainers and upstream developers in many respects, so perhaps this will release energy to do more cool things, instead of patching up differences. I mean, a pure systemd version of Gentoo will still be Gentoo, it will just share some basic OS characteristics with other Linux distros that will make it easier for upstream projects to support it.

I still think there will be many, many different Linux distros in the future, catering for either the mass market, or specialist use, I just think they will be less fragmented and different at the core system level, thanks to systemd etc.

It will make it easier for the eudev fork to keep up with udev, but then someone will have to make a userspace kdbus alternative to what systemd does as PID1, that appears to be a non trivial thing to do, involving some really low level stuff. So it will require some serious brain and developer power going that way, with possible implication for the rest of the distro, and the unavoidable back-clash from downstream eudev users, since that will force changes in their distros too.

Even if you don't use PA, you still benefit from the colossal cleanup of ALSA and the audio drivers PA made. But my point was merely, that PA has been on all major desktop distro for years, despite a vocal minority's endless negative campaigning against it. When people realize they have been using PA for a long time without problems, then it sounds hollow when PA opponents rants that PA doesn't work, or that Lennart Poettering can't code etc. No one ever developed an alternative to PA, simply because it was an insanely hard task to make a system wide sound daemon for Linux, so the PA opponents couldn't point to another sound daemon that people should use instead. The bottom line is, that negative campaigning utterly failed to keep PA from being _the_ standard Linux sound daemon, in much the same way, negative campaigning have failed to make systemd the _the_ Linux init system.

Slackware will have ever increasing problems not supporting systemd. There is just too much work to do, too few developers, and very little cooperation among the non-systemd distros. I think Patrick Volkerdings stance on systemd is much more nuanced; I don't think he has ever committed to saying that Slackware will never use systemd. I think he hopes he can avoid it, but at some point it may just be too hard to avoid.
Here is his latest comment on the matter (a rather embarrassing post from my side, I only realized who I was replying to when I pressed the submit button):
http://slashdot.org/comments.p...
Patrick Volkerding seems to have made no firm decision in any direction at the moment.

I find Slackware a noteworthy distro, though not a very large one. But my own personal opinion is that it either changes to systemd, or slowly whither away before the decade is over. Again, the problem is total lack of the necessary development to keep a non-systemd distro going.

Next there will be kdbus which again will force eudev maintainers to start some serious coding. A DE with Wayland support is probably difficult to get without systemd, secure root-less X.org also only works with systemd, upstream support will gradually disappear etc. In short, an avalanche of maintenance problems and challenges will hit non-systemd distros over the next couple of years. And since there is very little cooperation, no leadership, very few developers, and that they are very fragmented, even in what init system they use, it seems that the future for non-systemd distros is very bleak.

The point is that it have been relatively easy to fork off eudev and keep up with udev, but that will change with kdbus integration. Not only will the forked code differ quite a lot, but the way user space programs will use udev will also change. This will take some serious developer time to counter, one way or another. So small distros will spend more and more developer time, just to keep things from breaking and decaying. Having a fully functional DE already seems to be a lost cause for non-systemd Linux distros.

Yes, systemd will be increasingly domineering in Linux. Some years ago, I thought there would be a sizable minority of non-systemd distros competing with systemd, but this appears not to be happening.

I think there is important lessons to be learned from this; namely, without organizing and provide a constructive alternative it is extremely hard to counter the direction that leading distros chooses. Negative campaigning like attacking named open source developers and companies, and saying unfounded things about the project, is just a total failure. Not only because it is repugnant, but because it end up strengthen that attacked project.

In some ways the sweeping systemd victory, is a replay of the PulseAudio distro victory.

Well, actually SysVinit needs bug fixing too, RH and SuSE have been the actual upstream bugfixers for years, but that will stop too.

But maintaining SysVinit itself isn't the problem. The problem is udev, ConsoleKit, PolicyKit, and several other pieces that SysVinit/OpenRC distros now have to maintain themself in order to have a working desktop.

Later they will have to deal with their own cgroups manager, and that daemons wills start to use kdbus directly. New daemons of any complexity are unlikely to ship with SysVinit scripts anymore, so all those init-scripts will have to be developed and maintained. Upstream project developers will be increasingly unlikely to run anything else than systemd distros, so they can't deal directly with bug fixes or similar problems on SysVinit platforms.

Furthermore, upstream projects like KDE, XFCE, LXDE, needs help in supporting non-systemd platforms etc.

I must say I am surprised by the reaction at many SysVinit proponents, like you they seem to live in a fantasy world where no work is needed to keep running SysVinit. It looks like some cargo cult mentality where small downstream distros have been shielded by all the hard work the big distros have been doing in making Linux work, and therefore thinks that software will keep magically appearing and maintain itself.

You are in for a rude awakening in the near future.

There are still some Debian derivative distros that haven't changed to systemd yet, since Debian haven't released "Jessie" yet; the first Debian stable release with systemd as default init.

There is also a handful of other, rather small distros (forks of Gentoo and similar). But the basic problem with all those non-systemd distros and the systemd opponents are, that they seem unable to attract developers, and they don't cooperate either. They can barely maintain basic forks of udev, so when udev gets kdbus support, forks like "eudev" will begin to really differ from "udev".

The entire non-systemd infra structure will start to decay further when no big distros are supplying developers to maintain it. ConsoleKit have basically been bit-rotting for years now, and the systemd opponents haven't even started to _plan_ for a replacement.

At best the non-systemd distros will have crude Desktop Environment support. They will also have problem with Wayland support. Without DE support, it will become even harder to attract developers.

As things are looking now, I don't think any non-systemd distros will survive for long. IMHO, they only have themselves to blame for that, they have focused all their energy on hate attacks on named open source developers and negative campaigning against systemd, instead of focusing on making a constructive alternative.

Paul Venezia is just another sore systemd hater who can't accept that all major Linux distros are changing to systemd.

That he think systemd is mostly for desktops just show how much he has lost contact with Linux. There simply isn't any commercial interest in keeping SysVinit or even Upstart alive. The market would have reacted long ago if any companies where queuing up to pay for new Linux SysVinit releases. They are not.

Several companies have even switched to using systemd even though it wasn't officially supported on their distro yet, simply because systemd offers so many advantages over legacy script based init-systems.

There is no coordinated non-systemd development taking place in the Linux community at the moment. The few non-systemd distros left haven't even begun to cooperate. So it looks unlikely right now that any non-systemd distros of note will survive into the next decade.

There is a reason why commercial Linux vendors like Ubuntu and Red Hat are supporting desktop editions, even though they don't generate any money; without the desktop you will start to lose developers. It is that simple. That is also the main reason why BSD's are using GPL'ed DE's even though their sponsors can't resell them as close source software like the rest of the core BSD components; without a DE, the BSD variants would have even fewer developers.

So it is pretty much distro suicide to split a distro up in two different and incompatible versions, one for the desktop and one for the server.

Whoosh! /blush/

Excuse me Mr. Volkerding, didn't notice your user name. Cheers. Slackware on floppies was my first real distro, so I have a soft spot for Slackware (but not for floppies as a distro media :-).

While I may not agree with some of your decisions on how to make a Linux distro, I respect your work very much. I think you are a smart guy, so I find it unavoidable that Slackware will change to systemd at some time in the future. Not perhaps as a first choice, but as a necessity, simply because no other real alternative seems to exist. Maybe some non-systemd community will emerge to make it possible for non-systemd Linux distros to survive on the long run, but it doesn't look like it at the moment.

Some Slackers have been working on making systemd work on Slackware. It is not official supported packages, but what is on Slackware.

Patrick V. have clearly been expressing that he doesn't have a suicide pact with Slackware's init system, so he hasn't rejected shifting to systemd. Slackware is a tiny distro with few developers, it is totally unable to sustain itself when the rest of the Linux community have shifted to systemd. It is already clear, that without systemd there won't be any Wayland support, nor secure root-less X.org and more and more upstream projects are dropping e.g. ConsoleKit support.

There seem to be no coordinated non-systemd development at the moment, so at one point in the future, Patrick will have to choose between an ever decaying distro or systemd.

I am not in doubt that he will choose systemd, it is only software after all.

Please notice that systemd-timesyncd is only a sNTP v4 client, not a full NTP server like NTPd.
A main focus for systemd is OS containers, and this sNTP client, like the DHCP client, was especially made for such OS containers: When starting 5000 OS containers in parallel the usual sNTP and DHCP clients wouldn't work properly (like in fast enough).

systemd's "timesync" isn't in any way mandatory, and it is easy to compile and run systemd without it.

Both Gentoo and Slackware support systemd, and at least Slackware is likely to change to systemd in the future. Patrick Volkerding is holding the conversion back in the hope that some alternative may appear. But at the moment there is almost zero Linux development outside systemd, so at some point they will change to systemd in order to get e.g. Wayland support etc.

It isn't trivial to port to Linux, since the executables are just wrappers that translate into OpenBSD calls. The only part that matters in this GsOC project is "logind", and it doesn't work yet, and it is very unlikely that it will ever be a drop in replacement for the real "logind" (Cgroups support, kernel IPC and all that).

Anyway, if you don't want systemd, then cloning it is the worst possible strategic move to make. What upstream projects like Gnome and KDE have asked for, for years, is an alternative API and program to "logind", not a cloning attempt that pretends to be "systemd" while not supporting systemd features.

I mean, just maintaining a fork of ConsoleKit, would resolve 90% of all short term problems for upstream projects in supporting non-systemd platforms, and many long term problems too.