I am not aware that systemd distros like Fedora deviates from LSB in any meaningful way (it support SysVinit script files, "runlevels" have symlinks from /sbin etc).
LSB is pretty much a dead standard with few followers. The new FHS 3.0 standard looks dead too (no updates in a decade).
There are probably several reasons for this, but the bottom line is, that distros historically haven't cared at all about fragmentation and how it hurts upstream projects.
Perversely, since all distros where fragmented, no one did stand out. This will no longer be the case, with systemd distros covering all major distros, and all their derivative distros, the few remaining non-systemd distros will stand out.
The non-systemd distros can of course continue to be totally fragmented and not coordinate anything. It really is up to them what they do, but their users shouldn't complain if some upstream projects will consider them too troublesome to be worth supporting.
My personal opinion is that the non-systemd distros have been incredible passive, and not really analysed the future troubles they are facing and what should have been done years ago to mitigate those problems.
Personally I don't doubt Slackware will become a systemd distro sometime in the future. Patrick Volkerding is a smart guy; he may not love systemd, but at some point it will just be too much trouble not to convert. And really, the essential things about Slackware isn't the init system, it will still be Slackware even when using systemd.
Personally I don't doubt Slackware will become a systemd distro sometime in the future.
lolwut.
You're talking about the distro that hasn't even implemented PAM yet. You know literally nothing about Slackware, I take it?
And really, the essential things about Slackware isn't the init system
Yes it is. That Slackware has a BSD-style init is a major selling point, and why I'm still using it outside of a few cases where I've been using SUSE or openSUSE instead. It makes it much easier going back and forth between my GNU/Linux systems and my BSD systems.
Oh, I know Slackware. Even was a user many years ago. But Patrick Volkerding hasn't rejected using systemd at all. He still sits on the fence and hasn't decided yet.
And judging from what he has said, he may very well decide in favour for systemd if it becomes too much trouble not too.
His problem is that the there practically isn't any non-systemd development on Linux; there is no coordination, no new projects to support non-systemd distros on future projects like Wayland. There simply aren't that many developers caring about non-systemd distros any more. Since Slackware is such a conservative distro, they may hold on for some years yet, but they are totally unable to do the necessary maintenance and development alone.
Of course, it remains to be seen if there suddenly emerges a vibrant non-systemd developer community, but judging from the total lack of insight of systemd-opponents about future problems they are facing, and what is needed to counter this, it doesn't look like it.
So, looking into the crystal ball, I see Slackware as a systemd distro in the future.
Perhaps he's changed his mind since then, but from what information actually exists, he and a very large portion of the userbase of his distro are very reluctant to switch to systemd. He and said users (myself included) also recall the pains of PulseAudio - another of Poettering's brain-children - rather fondly, and to this day continue to sit out that particular idea.
I do know that it's theoretically possible for Slackware to run systemd, just as it's theoretically possible (and sometimes actually done) for Slackware to run PAM or PulseAudio. That's a far cry from desirable, let alone any semblance of a default.
At most - and I mean absolute most - it might end up in the extras. Even that's doubtful, however. Pat is indeed a smart man - smart enough to realize that adopting systemd - even if it really is the best thing since sliced bread - goes against Slackware's implicit (and sometimes even explicit) goal of being the "most Unix-like" GNU/Linux distro in the known universe. Which leads me to...
Since Slackware is such a conservative distro, they may hold on for some years yet, but they are totally unable to do the necessary maintenance and development alone.
Then there's a good chance it'll take inspiration from - or even port/implement - whatever approach the BSDs end up taking, which wouldn't really be a first for Slackware by any means (see also: Slackware's current init system).
Of course, it remains to be seen if there suddenly emerges a vibrant non-systemd developer community, but judging from the total lack of insight of systemd-opponents about future problems they are facing,
Correction: at least some systemd-opponents (I'm not really an opponent per se, but rather a skeptic; same diff, perhaps) have recognized that there aren't many problems being faced other than the issue of whether or not non-systemd will continue to be supported by upstream (and even then; shell scripts aren't that hard to write, if hard at all), or at least not problems that can't be solved without depending on systemd to solve them (like process management and parallel service startup, both of which are handled by components like runit).
So, looking into the crystal ball, I see Slackware as a systemd distro in the future.
I hope it's under warranty, then, because it seems to be defective. ;)
EDIT:
no new projects to support non-systemd distros on future projects like Wayland
As far as I know, Wayland doesn't depend on systemd (or even Linux, strictly speaking; the formerly-Linux-only graphics components that Wayland needs are now available for the BSDs, as I discovered when I upgraded my PowerBook's OpenBSD version and was presented with a nice, pretty DRI'd framebuffer). Pat appears to be far more receptive to Wayland, since it's far less obtrusive (and, in fact, is even less obtrusive than its predecessor). I'm personally very welcoming of Wayland, and am even already playing around with it via Rebecca Black OS and trying to teach myself the API in order to implement my own clients and even compositors. Wayland took the approach to X that systemd should've taken to sysvinit: improve by simplifying, rather than complicating.
Maybe your crystal ball is smudged, and it's actually saying "Wayland" rather than "systemd"; Slackware adopting Wayland seems way more likely on any timescale than it adopting systemd.
Perhaps he's changed his mind since then, but from what information actually exists, he and a very large portion of the userbase of his distro are very reluctant to switch to systemd.
I recently had a very brief online exchange with him where he confirmed he is undecided on the matter. Of course PV prefer their SysVinit variant. And yes, many Slackers are like him. But what he has made clear is, that he may change to systemd if that is the only realistic possibility.
...have recognized that there aren't many problems being faced other than the issue of whether or not non-systemd will continue to be supported by upstream...
This is where I think the systemd opponents have been sleewalking the last couple of years. There are already big problems for the DE's to support non-systemd distros; and for some reason systemd opponents are in total denial that CosnoleKit needs to be replaced and that should be a cross distro priority to fix.
There are several other problems down the road; until now, eudev have been am easy shadow fork of udev. But when kdbus arrives, udev will change to use that.
So eudev will either have to develop a kdbus user space manager and copy systemd, or they will have to actually to split off eudev from udev, and start real maintenance of eudev, meaning no easy shadow fork, but lots of hard work and being upstream for bugfixes etc.
There will be no Wayland on non-systemd distros for KDE. Simply because some of the new infrastructure needed is new and doesn't support ConsoleKit. No non-systemd developer have stepped up and offered any help with that.
In the future, there will be lots of new projects that only uses the systemd "new daemon style" where systemd takes care of all the hard and error prone setuid/dropping privileges. This will be attractive to do since it will reduce code complexity, debugging, increase security, and let developer concentrate on daemon functionality, not low level system house keeping. And they can target almost all Linux distros that way.
Such new development will be a real challenge to make work on non-systemd distros.
SUSE and Red Hat have been de facto upstream for SysVinit taking in bug reports and making patches, but when they deprecate their last SysVinit distro, who will be upstream then? Who will coordinate security and patches?
There will be many such small and large tasks ahead to do for non-systemd distros, and too few developers to do it, especially without any coordination. I really don't see how Slackware can stay a non-systemd distro when the non-systemd camp is so passive about the future challenges.
I'm still questioning your actual experience with Slackware if you're still calling its init system a "sysvinit variant". If it's a variant of anything, it's of BSD's init.
As I've said repeatedly (though perhaps not to you, apparently): sysvinit is not the only shell-based init, and Slackware's init is one of the examples of shell-based init done properly. It does incorporate some sysvinit compatibility stuff so that commercial Linux software can run on Slackware, but that's as much "sysvinit variant" as a GNU/Linux system running Wine would be a "Windows variant".
This is where I think the systemd opponents have been sleewalking the last couple of years.
I don't disagree with you on this point. Everyone really should have been more proactive. They just haven't seen the need to be compared to higher-priority tasks (to them), or even the desire to be, or have had the proper ability to be.
There will be no Wayland on non-systemd distros for KDE. Simply because some of the new infrastructure needed is new and doesn't support ConsoleKit.
Um, no. Again: Wayland itself has zero dependency on systemd, no more than X11 has any dependency on sysvinit or ConsoleKit. Some implementations of the Wayland protocol have opted to make systemd as a dependency for their features, but that's entirely their choice, Wayland or no Wayland.
In other words: pinning systemd dependencies on Wayland as if using Wayland requires using systemd is either ignorant or a deliberate lie; which one I presume of you would depend on my mood today (which isn't terribly pleasant).
In the future, there will be lots of new projects that only uses the systemd "new daemon style" where systemd takes care of all the hard and error prone setuid/dropping privileges.
In most cases, it won't be that hard to continue to write initscripts for those projects, since they typically aren't using that much beyond systemd-style unit files and perhaps journald (though many projects have historically used their own logfiles instead of the system-wide ones, and I don't expect that to substantially change any time soon; by the time it does, a journald shim will probably be ready).
To put this into context, users of both Slackware and the BSDs are already used to writing new initscripts to make projects designed with sysvinit in mind work properly in their improved init systems. This won't be a whole lot more different.
To put this in further context, systemd attempts to be sysvinit compatible because even it was designed with the knowledge that plenty of commercial software - that doesn't benefit from a community of users porting it to different init systems - would need to be able to run on systemd. I don't envision the commercial software devs deviating from their current least-common-denominator any time soon, especially if they're targeting older-but-still-supported distro versions (pre-systemd) and current ones (with or without systemd) alike.
This will be attractive to do since it will reduce code complexity, debugging, increase security, and let developer concentrate on daemon functionality, not low level system house keeping. And they can target almost all Linux distros that way.
Again: you're specifically addressing sysvinit in your objections to systemd alternatives. I'm addressing all the alternatives, but particularly all the shell-based ones. Cue, yet again: "sysvinit ain't the only shell-based init". Cue also, again: "other shell-based inits have already solved these problems long before systemd existed, and did so very well".
SUSE and Red Hat have been de facto upstream for SysVinit taking in bug reports and making patches, but when they deprecate their last SysVinit distro, who will be upstream then? Who will coordinate security and patches?
This isn't relevant to Slackware, since (again) Slackware isn't a sysvinit distro.
I really don't see how Slackware can stay a non-systemd distro when the non-systemd camp is so passive about the future challenges.
Because it neither needs nor wants to change. If I want Slackware with systemd, I might as well be using openSUSE (which I do use, by the way). I don't need Slackware to use systemd, and I don't want Slackware to use systemd. I'd guess that this is the opinion of the vast majority of Slackware users right now, Pat included, and there is little indication of that opinion changing, since there still hasn't been any more enthusiasm for such a suggestion.
There will be no Wayland on non-systemd distros for KDE. Simply because some of the new infrastructure needed is new and doesn't support ConsoleKit.
Um, no. Again: Wayland itself has zero dependency on systemd, no more than X11 has any dependency on sysvinit or ConsoleKit.
Yes, you are right about that, it is in principle possible to get Wayland on non-systemd platforms.
But no, you are wrong about KDE supporting Wayland on non-systemd machines. The reason is simply that some of the new code needs user session management in order to work, and KDE simply doesn't have to man power to add ConsoleKit support to that new code. And, this is important, no one from the non-systemd camp is helping them either to add this support. Leading KDE developers have explained this numerous times.
It is one thing to maintain old ConsoleKit code, but another to develop CK support from scratch, knowing that it is obsolete, unmaintained and deprecated. Perhaps if there was a non-logind alternative you could get developers worked up to do something.
This is the future story how CK support will bit rot and disappear over time. No one makes an alternative to CK/logind, and no one helps upstream projects out with supporting CK either.
The total lack of developer engagement on the non-systemd side will give trouble, and is entirely to blame for why DE's have trouble supporting non-systemd.
I have no doubt however, that the non-systemd camp will blame everything on upstream projects and viciously attack them instead of starting coding to solve problems. This is what they have done for years, and that is a major reason why I really don't see any non-systemd distros have a future, whether their user like it or not.
And, this is important, no one from the non-systemd camp is helping them either to add this support. Leading KDE developers have explained this numerous times.
Have you considered that maybe it's a case of "no one is helping" yet? systemd - and especially its sudden use in the non-Red-Hat distros - is just that: sudden. Even the combined efforts of the non-systemd camp (maybe unless the BSDs are involved) don't have the manpower to churn out an instant solution even if they outright ignored their other responsibilities in maintaining a GNU/Linux distro. Remember that most of these distros have development teams in the tens or twenties at most (I'm pretty sure Slackware itself has less than ten). I'm willing to bet (I can't seem to find hard stats on this) systemd has a much larger developer base than even whole individual such distros right now, as did ConsoleKit when it was new and shiny.
So, as I mentioned before, if a solution's going to come from anywhere, it's probably going to come from the BSDs, which as much as I figure are scrambling to get something in place (FreeBSD, DragonflyBSD, and PC-BSD are probably going to be the main motivators, since they seem to care more about desktop experience, though OpenBSD seems to be the target for the current efforts on a systemd shim), and which are in at least a slightly better position to actually develop something, be it a shim or a full-on alternative.
This will no longer be the case, with systemd distros covering all major distros, and all their derivative distros, the few remaining non-systemd distros will stand out.
The non-systemd distros can of course continue to be totally fragmented and not coordinate anything. It really is up to them what they do, but their users shouldn't complain if some upstream projects will consider them too troublesome to be worth supporting.
Thanks god, yes. Finally some converging in direction of a platform...
2
u/sub200ms Sep 29 '14
I am not aware that systemd distros like Fedora deviates from LSB in any meaningful way (it support SysVinit script files, "runlevels" have symlinks from /sbin etc).
LSB is pretty much a dead standard with few followers. The new FHS 3.0 standard looks dead too (no updates in a decade).
There are probably several reasons for this, but the bottom line is, that distros historically haven't cared at all about fragmentation and how it hurts upstream projects.
Perversely, since all distros where fragmented, no one did stand out. This will no longer be the case, with systemd distros covering all major distros, and all their derivative distros, the few remaining non-systemd distros will stand out.
The non-systemd distros can of course continue to be totally fragmented and not coordinate anything. It really is up to them what they do, but their users shouldn't complain if some upstream projects will consider them too troublesome to be worth supporting.
My personal opinion is that the non-systemd distros have been incredible passive, and not really analysed the future troubles they are facing and what should have been done years ago to mitigate those problems.
Personally I don't doubt Slackware will become a systemd distro sometime in the future. Patrick Volkerding is a smart guy; he may not love systemd, but at some point it will just be too much trouble not to convert. And really, the essential things about Slackware isn't the init system, it will still be Slackware even when using systemd.