None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.
Logging isn't done by or in PID1. It is done by the "journald" daemon that have its own pid. I must say, that whoever telling you about how systemd is designed and works, doesn't have a clue what they are talking about. I strongly suggest you check out the systemd homepage for some basic information about systemd. http://www.freedesktop.org/wik...
People are hard to satisfy: some complain that systemd replaces daemons, and now you complain about it _doesn't_ replace syslog for writing text logs?
People who wants simple text-logs can still use rsyslog or whatever they have always used, and have "journald" forward all the messages to it. That way rsyslog can gain some of the systemd benefits like early boot logging, though not them all (rich meta data like monotonic stamps and whatnot). All in all you would be better off than simply using SysVinit and pure rsyslog.
Even without syslog, it is trivial to convert systemd's journal to text. You can even export it as JSON to preserve the rich meta data.
I really think the systemd developers did their homework very well with the design of the logging system. The more I use it, the more I like it. There is no going back for me to plain text logs.
cgroups is a kernel feature. It doesn't stop working because whatever process you're using for cgroup management dies. The process comes back, reads the state from/sys/fs/cgroup, and resumes doing whatever kind of management you wanted.
The point is that most user processes doesn't communicate directly with the kernel, but with a cgroup manager using a higher level API, like systemd or cgmanager. So while the kernel works fine, the "communication link" or the mediator between processes and the kernel would be severed if the cgroup manager in PID2 died. That is highly likely to lead to an unstable system.
Anyway, looking at the design of systemd, you will see that it actually runs very little code in PID1, it just communicate via PID1 to the other helper processes. This enables PID1, the init part, to have total control and supervision of all processes. Making e.g. the cgroup manager run in PID2, wouldn't gain anything, but increase complexity, since there would need to be intense communication between PID1 and PID2 in order for the init system to use cgroup to track all processes.
I think the whole PID1 debate is based, not on hard facts or good analysis, but on a hatred against systemd. People seems to rely on random hate blogs on the net for what systemd is, instead of examining the systemd project for themselves.
Systemd's PID1 is actually rather small, especially compared to what functions it provides. Moving some core bits out of PID1 and place them in PID2 will just increase complexity with little if any gain.
The reality is, that the systemd designers made some good choices when making systemd. Personally I think it is hopeless for all the simple script based init-systems to have real feature parity with systemd, unless they make some of the same design decisions.
Your claims that systemD is well engineered are a little eye-raising. We're talking about a replacement for the init system here, and you say the main feature is logind. That's not really part of what I expect Init to do......
logind isn't a feature with "systemd" (the daemon), but with systemd (the project). "logind" is a consumer of the systemd-daemon's internal API however. That means you can use cgroups and other kernel and systemd features in user sessions. This is how eg. secure root-less X.org is possible with systemd.
I think many peoples idea what init is, have been clouded by the fact that traditional Linux init systems were so primitive. Certified Unix'en like Solaris and Mac OSX have abandoned crude Linux like init systems years ago.
Booting and initialization of a system is quite complex on modern OS's, so doing it by modules that aren't coordinated and aren't developed with the other modules in mind, really limits what the OS can do. Having modules like systemd's, that are designed to talk to each other, all other processes and the kernel, and is developed in a coherent manner, really can remove some old limits on how Linux works. Basic things like conferring "namespaces" and "capabilities" from the kernel to a service, just by adding a simple keyword in the service config file, shows the potential. But multi-seat computing, stateless booting and "zero config" boots are either realized already or being worked upon. With kdbus in the kernel, secure OS containers from basically unmodified Linux distros, will become a reality.
I also think it is good, that systemd now will reduce Linux fragmentation at some level at least, and freeing distro maintainers and developers from a lot of non-fun work like maintaining and debugging init-scripts, while making cross distro collaboration on e.g. extra hardened "Unit" files (service configs) possible.
Here is a youtube video where Lennart Poettering talks about why systemd goes beyond a simple init system: https://www.youtube.com/watch?...
In any case, in a few months, I'll have time to read the systemD source code, and I will have a better idea if it's well designed or not.
I've been a sysadmin for 20 years, and I've seen systems break in lots of interesting ways. What I want is a log mechanism which is as simple as possible so that it as least has a chance of giving me the info I need even if the rest of the system is in the process of going to hell.
What I don't want is an unnecessarily (you aren't even able to explain the advantages, actually some of your "advantages" are disadvantages like the corruption detection) complex system which will take ages to debug, IF it will ever be - most software is already too complex and too fast moving to be ever debugged sufficiently. It violates the KISS principle. And the advantage of Linux over Windows used to be the KISS principle...
systemd's logging facilities are superior to old syslog in several ways. Fx. systemd and journald lives in initramfs while the system is booting, so it can collect logging info from before the root fs is even mounted. Since systemd actually have knowledge about mount points and files systems, it can also delay to the very last moment the things needed for journald to write to the log.
There is also kernel guarantee that the daemons/pid's/programs that appear in the log are the real ones since systemd have total control and supervision of all processes. So if "lp0: printer on fire" appears in the log, you will know whether it is a prank or a real message.
The structure and index makes it possible to store lots of interesting meta-data, like monotonic time-stamps, GUI, PID, command line, marks from where every boot started and ended ("journalctl -b -p err" shows all loglevel "error" messages generated last boot only). Using monotonic timestamps to compare two boot sequences on perhaps two similar machines, is quite interesting and very easy to do.
It also allows for multi-language log support, supplementary help files that can explain what the error message means, suggest how to solve the problem, etc.
Here is a list of fields in the journal. Because of the index, the journal have real time knowledge about what is written in the fields, so there is tab completion and extremely powerful sorting available: http://www.freedesktop.org/sof...
If you care about logging with systemd, take a look a the original design document behind journal https://docs.google.com/docume... Notice how simplicity is design goal number 1.
If you intend to remain (a paid) Linux sysadmin in the future now where all major distro are starting to convert to systemd, you should really study systemd's journal. It is much easier to "get" the power of a indexed and structured log file by trying it, than describing it. Fedora 20/CentOS 7 are reasonable choices to learn it on.
check out systemd's "nspawn" too: OS containers really are the future.
And that is part of the problem, that it is presented as a init vs init issue.
It has long since grown past that. Systemd, as a package, now holds udev, journald, its own cron replacement, a network manager, dhcp, ntp, inetd, etc etc etc.
There are several inaccuracies on that list; systemd has timers that may be used as a cron substitute, but really is a different design, so therefore cron can happily co-exist, and nobody forces anybody to use the systemd solution. Systemd doesn't have a replacement for a NTP server, it just has a simple sNTP client. Like the systemd dhcp client, it was made with a special user case in mind, namely OS containers, where existing solutions simply where too slow and noisy (when starting 1000 OS containers at the same time, it really matters if each dhcp client connection takes 60 seconds or 3). AFAIK, the dhcp code is mostly a library that can be ripped out of the systemd source tree. Nobody forces anybody to use them; they are alternatives, not replacements.
Again, systemd doesn't have an "inetd" server. Systemd uses socket activation as pioneered by inetd, but there are important differences. Lennart has several blog pages about it, here are a couple: http://0pointer.de/blog/projec... http://0pointer.de/blog/projec...
systemd can use "inetd" prepared services, but inetd may happily co-exist together with systemd, and inetd provides services that systemd doesn't provide such as TCPMUX and RPC services.
The journal was a part of systemd early on, because in order to have great service management, you need the best logging possible.
But the crowning achievement may well be logind, that more and more DEs are getting a dependency on.
And logind can only function with systemd as the init, full stop.
logind was part of systemd early on. It has never been a separate project. It has never been meant to work outside systemd. Systemd opponents seems to have this bizarre love-hate relationship with systemd code; they curse it and the open source developers who make it, claiming the code is bad etc. etc. But at the same time they lust for the code, claiming systemd should be split up in smaller modules so they can use it anyway.
It has been a seriously mistake for the systemd opponents that they have become so fixated on systemd's "logind". Why should they care about how systemd solves user session problems? Upstream projects like Gnome and KDE have warned about for years, that an _alternative_ to logind/ConsoleKit should be developed.
Upstream projects like Gnome and KDE becomes dependent on systemd's login, because it solves real problems, like no other maintained program does. If there was an alternative API, from a program with similar functionality, they would happily support that. But no-one seems to care enough to start developing such a program.
It has been said many, many times; the systemd opponents should start to solve their own problems that lie in front of them, instead of wasting breath on trash-talking systemd. More code, less ranting.
What will happen is other distress will add a compatibility layer so they can handle all the kludge that has added systemD as a requirement.
First, the "kludges" you are talking about, is a minimal distro agnostic compatibility layer, so that upstreams projects like XFCE can finally get basic system information without searching 20 places just to display e.g. the distro version it is running on top of.
It is one of the many examples on how systemd solves real world problems that helps other Linux developers, which is why systemd is so popular among developers. It is quite shameful that SysVinit (and similar init systems) distros haven't done anything even as basic as that.
The "systemBSD" project can't really be ported to Linux, and the crucial part, "logind" doesn't work yet and may never do. Trying to clone a version of systemd's "logind" is also a the wrong thing to do: trying to present it self as a systemd logind for upstream projects, but without supplying the necessary functions will just mean errors and crashes. A "logind" using the systemd API isn't what upstream projects like Gnome and KDE etc. have asked for the last couple of years; they want an _alternative_ API that support at least the basic features that logind or or ConsoleKit have.
To sum up: what upstream projects wants are an _alternative_ to logind/ConsoleKit, that works and are maintained. It is the most minimal request they can formulate, and is essential for providing modern DE functionality to non-systemd distros.
But even that request are ignored by the systemd opponents, they prefer to trash-talk systemd instead of solving their own problems.
The problem is systemD is bad design. The systemD guys like to say, "but look at all the features!", which is cool, but features aren't an excuse for bad design. "Those who do not understand UNIX are condemned to reinvent it, poorly" etc etc
Systemd is brilliantly designed and engineered, which is why it has become so popular. Its backwards compatibility is top notch; there was no flag day where every service either was a systemd service, or it wouldn't function.
They studied "launchd" and Solaris "SMF" and other Unix init systems to make an init system that was better in everything, in every detail, than what was available for Linux. SysVinit OTHO, is a notoriously bad design, where code and config options are mixed together in free form executable config files. Systemd separates code from daemon config options, so the latter are in structured text files that are easy to parse for both humans and machines.
The systemd developers really cares about details too, so it has the best bash-completion I have ever seen. It is a joy to work with the systemd CLI tools.
Vague criticisms about systemd's design really isn't much of an argument. Systemd actually works extremely well in the real world.
That's true, but pid 2 crashing won't halt the system, because pid 1 can restart it. If pid 1 crashes, it's power cycle time.
If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.
I do really think that the systemd designers have actually done their homework quite well when they started out. PID1 is quite small and only contain what is needed, everything else runs as helper processes.
Besides that, systemd can supervise itself (PID1) by using a watchdog, so the system can react if PID1 doesn't answer the watchdog "ping". http://0pointer.de/blog/projec...
Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.
Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.
You are seriously misinformed on how systemd works and what it can do: It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.
Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities": http://0pointer.de/public/syst...
There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from/home, even if they otherwise had permission to read in home.
All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.
It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,
This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.
Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.
I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.
General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.
If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.
Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.
The journal is primarily append based, so it designed to be very robust against corruption, the log is also rotated whenever a corruption is detected. So usually the corruption you see are a single line that was malformed when writing because e.g. the daemon died unexpectedly; this happens all the time with text based logs, but because they have no inbuilt integrity checks like systemd, it doesn't get discovered.
So in most cases you don't really loose any log info, and the rest of the log remains fully readable. I am sure that there are subtle bugs in systemd that end up causing file corruption, or enhances the risk of corruption when the systems suddenly shuts down. But I also think that the bugs can and will be fixed, so I really don't see it as a long term problem. The many advantages by having an indexed and structured logfiles far outweighs the theoretically small chance of file corruption on modern file systems.
I don't think it is practically possible separate text logs from the metadata and get the same functionality as systemd's journal. AFAIK, the journal is more or less just a textfile+index anyway. Try running "strings" on a journal, it will show a lot of the logging info.
It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.
You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons, logind is just one example (ConsoleKit is a dead project with no alternative).
But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities" to massively strengthen security, or have a total supervision chain of all processes, including PID1 etc. There is so much good stuff in systemd that the SysVinit-like init distros could clone.
That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.
Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?
All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.
I think that there are actually very good design reasons for why systemd is designed like it is. It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages, since it can act as a mediator between kernel features like cgroups and "capabilities" and the processes it controls.
The logging is a perfect example. Why do I have to learn a new program (journalctl) just to read the system logs? What if I had to learn the syntax of a new program to read the logs of every program that I used? That would suck. If openvpn and mysql and httpd and sshd all had their own little program that I had to use to read their logs, I would give up using Unix. I already have a program to read all logs, more or less. And I already have a program that searches all the logs, egrep. Yes, I had to learn egrep syntax, but now that I know it, I can do almost any search imaginable of any program's logs. Except systemd.
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.
The bottom line is that if people want FOSS to go in a particular direction, they have to fork out money or code. Talk is cheap, and fairly ineffective. That is true whether you're talking about commercial or volunteer-based projects.
Yes, freedom isn't a given thing. It may cost something to gain it or keep it.
If I had to choose between very fragmented or completely uniform, however, I'd choose fragmented.
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...
We can't predict where Linux will be used in the future, and so we may need the core-level diversity that fragmentation brings. It's about more than just where libraries are placed, but about ways of doing things. Being able to drop in an alternative system-level structure lets us try out new principles, such as systemd versus sysvinit for instance. We might all be using systemd in 10 years, but I would bet you nobody will be in 50, so if we're no longer able to experiment with alternatives because we're locked into one system, that new alternative will come from outside the Linux ecosystem. It's evolution: stop growing and settle into a niche, and eventually something nimbler will outcompete you.
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.
Patrick Volkerding seems to have made no firm decision in any direction at the moment.
Ok, my mistake.
...it seems that the future for non-systemd distros is very bleak.
The future definitely doesn't look good, and I don't disagree with the arguments you offer to paint it so bleakly. I'm not ready to give up on alternatives, however, so I'll do what I can with my meager skills and encourage anyone else also doing so. I prefer to remain optimistic, that we can get enough people together to continue offering an alternative to systemd.
Not requiring everyone to use the same setup is one of the big strengths of Linux. That's one of the main reasons I don't like systemd as an ecosystem: it seems to be trying to force everyone to use the same setup, by depreciating everything else. No one piece of software should be so central that there is no way to replace it with an alternative, because otherwise you end up with monoculture and monopoly.
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.
Maybe, but I suspect that eudev will just merge in the changes wholesale, which doesn't require a great deal of effort. I don't think there is any driver to keep kdbus support out of eudev.
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.
In some ways the sweeping systemd victory, is a replay of the PulseAudio distro victory.
Sure, but believe it or not I don't have pulseaudio installed on my system. I don't really have any objections to it - I just haven't had any need for it either and thus haven't gotten around to installing it (even though that probably would only take 15min). If some program I used needed it I'd get it working.
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 still doesn't have systemd, and Patrick Volkerding has apparently come down pretty hard against it. He still hasn't accepted Pulse Audio for similar reasons, and that's from a decade ago. Unless you think Slackware will disappear, or that it doesn't qualify as a "distribution of note", I think it'll end up proving you wrong.
Yes, probably no Gnome and similar, but there's always Enlightenment, Xmonad, and plenty of other more palatable alternatives. There's eudev to handle/dev, Slackware already hasn't shipped with Gnome for years now, and there's daemontools/runit/s6 to replace sysvinit. I'm sure we'll find a way to steer clear of systemd, even if we end up in the minority.
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.
While there was a lot of the usual flames at the time of formation of eudev, from what I've seen in practice the folks maintaining it actually do try to follow udev reasonably closely and they certainly talk to their udev/systemd counterparts within Gentoo. There are certainly some philisophical differences, but I suspect that when kdbus comes along the eudev folks may embrace it (it is, after all, going to be part of the kernel). I think there is recognition that if they try to go in a completely different direction they're going to be short on manpower to keep it useful. The main maintainers of OpenRC on Gentoo are also involved in maintaining systemd.
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.
I'm closer to Gentoo than anything else, but from the occasional debian mailing list browsing I get the sense that the winds are blowing the same for both distros. There are people who aren't happy about systemd in both places, but nobody really wants to create yet another distro from the ground up to try to avoid it. There is a tendency to cheerlead anything that looks like opposition, but the fact is that most of the people actually doing the work have a grasp on the momentum systemd has.
Gentoo is a bit of a niche distro and has always been about fostering choices, so stuff like openrc/eudev, or even using busybox to populate/dev are going to tend to be supported to some extent for a long time. Gentoo also supports BSD, so OpenRC will be mainstream there indefinitely. I suspect that it won't be too long until the majority of users have switched to systemd.
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.
There wasn't that much SysV init development before systemd either. It just works, no need to hack on it.
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.
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.
By what strange theory does Slackware support systemd? And how is the conversation being "held back"? At least on LQ, I think it's been discussed to death to the point where there's really nothing new to say about it.
I can say one thing for certain: you do not know that anything concerning systemd in Slackware is likely or not. Hell, *I* don't.
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.
The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!
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.
Slashdot Mirror
None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.
Logging isn't done by or in PID1. It is done by the "journald" daemon that have its own pid. I must say, that whoever telling you about how systemd is designed and works, doesn't have a clue what they are talking about. I strongly suggest you check out the systemd homepage for some basic information about systemd.
http://www.freedesktop.org/wik...
People are hard to satisfy: some complain that systemd replaces daemons, and now you complain about it _doesn't_ replace syslog for writing text logs?
People who wants simple text-logs can still use rsyslog or whatever they have always used, and have "journald" forward all the messages to it. That way rsyslog can gain some of the systemd benefits like early boot logging, though not them all (rich meta data like monotonic stamps and whatnot). All in all you would be better off than simply using SysVinit and pure rsyslog.
Even without syslog, it is trivial to convert systemd's journal to text. You can even export it as JSON to preserve the rich meta data.
I really think the systemd developers did their homework very well with the design of the logging system. The more I use it, the more I like it. There is no going back for me to plain text logs.
cgroups is a kernel feature. It doesn't stop working because whatever process you're using for cgroup management dies. The process comes back, reads the state from /sys/fs/cgroup, and resumes doing whatever kind of management you wanted.
The point is that most user processes doesn't communicate directly with the kernel, but with a cgroup manager using a higher level API, like systemd or cgmanager. So while the kernel works fine, the "communication link" or the mediator between processes and the kernel would be severed if the cgroup manager in PID2 died. That is highly likely to lead to an unstable system.
Anyway, looking at the design of systemd, you will see that it actually runs very little code in PID1, it just communicate via PID1 to the other helper processes. This enables PID1, the init part, to have total control and supervision of all processes. Making e.g. the cgroup manager run in PID2, wouldn't gain anything, but increase complexity, since there would need to be intense communication between PID1 and PID2 in order for the init system to use cgroup to track all processes.
I think the whole PID1 debate is based, not on hard facts or good analysis, but on a hatred against systemd. People seems to rely on random hate blogs on the net for what systemd is, instead of examining the systemd project for themselves.
Systemd's PID1 is actually rather small, especially compared to what functions it provides. Moving some core bits out of PID1 and place them in PID2 will just increase complexity with little if any gain.
The reality is, that the systemd designers made some good choices when making systemd. Personally I think it is hopeless for all the simple script based init-systems to have real feature parity with systemd, unless they make some of the same design decisions.
Your claims that systemD is well engineered are a little eye-raising. We're talking about a replacement for the init system here, and you say the main feature is logind. That's not really part of what I expect Init to do......
logind isn't a feature with "systemd" (the daemon), but with systemd (the project). "logind" is a consumer of the systemd-daemon's internal API however. That means you can use cgroups and other kernel and systemd features in user sessions. This is how eg. secure root-less X.org is possible with systemd.
I think many peoples idea what init is, have been clouded by the fact that traditional Linux init systems were so primitive. Certified Unix'en like Solaris and Mac OSX have abandoned crude Linux like init systems years ago.
Booting and initialization of a system is quite complex on modern OS's, so doing it by modules that aren't coordinated and aren't developed with the other modules in mind, really limits what the OS can do. Having modules like systemd's, that are designed to talk to each other, all other processes and the kernel, and is developed in a coherent manner, really can remove some old limits on how Linux works. Basic things like conferring "namespaces" and "capabilities" from the kernel to a service, just by adding a simple keyword in the service config file, shows the potential. But multi-seat computing, stateless booting and "zero config" boots are either realized already or being worked upon. With kdbus in the kernel, secure OS containers from basically unmodified Linux distros, will become a reality.
I also think it is good, that systemd now will reduce Linux fragmentation at some level at least, and freeing distro maintainers and developers from a lot of non-fun work like maintaining and debugging init-scripts, while making cross distro collaboration on e.g. extra hardened "Unit" files (service configs) possible.
Here is a youtube video where Lennart Poettering talks about why systemd goes beyond a simple init system:
https://www.youtube.com/watch?...
In any case, in a few months, I'll have time to read the systemD source code, and I will have a better idea if it's well designed or not.
I strongly recommend reading as many relevant sections from this site:
http://www.freedesktop.org/wik...
There are also some design documents (like this old one about the journal)
https://docs.google.com/docume...
And of course more youtube talks from Fosdem etc:
https://www.youtube.com/watch?...
I've been a sysadmin for 20 years, and I've seen systems break in lots of interesting ways. What I want is a log mechanism which is as simple as possible so that it as least has a chance of giving me the info I need even if the rest of the system is in the process of going to hell.
What I don't want is an unnecessarily (you aren't even able to explain the advantages, actually some of your "advantages" are disadvantages like the corruption detection) complex system which will take ages to debug, IF it will ever be - most software is already too complex and too fast moving to be ever debugged sufficiently. It violates the KISS principle. And the advantage of Linux over Windows used to be the KISS principle...
systemd's logging facilities are superior to old syslog in several ways. Fx. systemd and journald lives in initramfs while the system is booting, so it can collect logging info from before the root fs is even mounted. Since systemd actually have knowledge about mount points and files systems, it can also delay to the very last moment the things needed for journald to write to the log.
There is also kernel guarantee that the daemons/pid's/programs that appear in the log are the real ones since systemd have total control and supervision of all processes. So if "lp0: printer on fire" appears in the log, you will know whether it is a prank or a real message.
The structure and index makes it possible to store lots of interesting meta-data, like monotonic time-stamps, GUI, PID, command line, marks from where every boot started and ended ("journalctl -b -p err" shows all loglevel "error" messages generated last boot only). Using monotonic timestamps to compare two boot sequences on perhaps two similar machines, is quite interesting and very easy to do.
It also allows for multi-language log support, supplementary help files that can explain what the error message means, suggest how to solve the problem, etc.
Here is a list of fields in the journal. Because of the index, the journal have real time knowledge about what is written in the fields, so there is tab completion and extremely powerful sorting available:
http://www.freedesktop.org/sof...
If you care about logging with systemd, take a look a the original design document behind journal
https://docs.google.com/docume...
Notice how simplicity is design goal number 1.
If you intend to remain (a paid) Linux sysadmin in the future now where all major distro are starting to convert to systemd, you should really study systemd's journal.
It is much easier to "get" the power of a indexed and structured log file by trying it, than describing it. Fedora 20/CentOS 7 are reasonable choices to learn it on.
check out systemd's "nspawn" too: OS containers really are the future.
There are several inaccuracies on that list; systemd has timers that may be used as a cron substitute, but really is a different design, so therefore cron can happily co-exist, and nobody forces anybody to use the systemd solution. Systemd doesn't have a replacement for a NTP server, it just has a simple sNTP client. Like the systemd dhcp client, it was made with a special user case in mind, namely OS containers, where existing solutions simply where too slow and noisy (when starting 1000 OS containers at the same time, it really matters if each dhcp client connection takes 60 seconds or 3). AFAIK, the dhcp code is mostly a library that can be ripped out of the systemd source tree.
Nobody forces anybody to use them; they are alternatives, not replacements.
Again, systemd doesn't have an "inetd" server. Systemd uses socket activation as pioneered by inetd, but there are important differences. Lennart has several blog pages about it, here are a couple: http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
systemd can use "inetd" prepared services, but inetd may happily co-exist together with systemd, and inetd provides services that systemd doesn't provide such as TCPMUX and RPC services.
The journal was a part of systemd early on, because in order to have great service management, you need the best logging possible.
logind was part of systemd early on. It has never been a separate project. It has never been meant to work outside systemd. Systemd opponents seems to have this bizarre love-hate relationship with systemd code; they curse it and the open source developers who make it, claiming the code is bad etc. etc. But at the same time they lust for the code, claiming systemd should be split up in smaller modules so they can use it anyway.
It has been a seriously mistake for the systemd opponents that they have become so fixated on systemd's "logind". Why should they care about how systemd solves user session problems? Upstream projects like Gnome and KDE have warned about for years, that an _alternative_ to logind/ConsoleKit should be developed.
Upstream projects like Gnome and KDE becomes dependent on systemd's login, because it solves real problems, like no other maintained program does. If there was an alternative API, from a program with similar functionality, they would happily support that. But no-one seems to care enough to start developing such a program.
It has been said many, many times; the systemd opponents should start to solve their own problems that lie in front of them, instead of wasting breath on trash-talking systemd.
More code, less ranting.
What will happen is other distress will add a compatibility layer so they can handle all the kludge that has added systemD as a requirement.
First, the "kludges" you are talking about, is a minimal distro agnostic compatibility layer, so that upstreams projects like XFCE can finally get basic system information without searching 20 places just to display e.g. the distro version it is running on top of.
It is one of the many examples on how systemd solves real world problems that helps other Linux developers, which is why systemd is so popular among developers. It is quite shameful that SysVinit (and similar init systems) distros haven't done anything even as basic as that.
The "systemBSD" project can't really be ported to Linux, and the crucial part, "logind" doesn't work yet and may never do. Trying to clone a version of systemd's "logind" is also a the wrong thing to do: trying to present it self as a systemd logind for upstream projects, but without supplying the necessary functions will just mean errors and crashes. A "logind" using the systemd API isn't what upstream projects like Gnome and KDE etc. have asked for the last couple of years; they want an _alternative_ API that support at least the basic features that logind or or ConsoleKit have.
To sum up: what upstream projects wants are an _alternative_ to logind/ConsoleKit, that works and are maintained. It is the most minimal request they can formulate, and is essential for providing modern DE functionality to non-systemd distros.
But even that request are ignored by the systemd opponents, they prefer to trash-talk systemd instead of solving their own problems.
The problem is systemD is bad design. The systemD guys like to say, "but look at all the features!", which is cool, but features aren't an excuse for bad design. "Those who do not understand UNIX are condemned to reinvent it, poorly" etc etc
Systemd is brilliantly designed and engineered, which is why it has become so popular. Its backwards compatibility is top notch; there was no flag day where every service either was a systemd service, or it wouldn't function.
They studied "launchd" and Solaris "SMF" and other Unix init systems to make an init system that was better in everything, in every detail, than what was available for Linux. SysVinit OTHO, is a notoriously bad design, where code and config options are mixed together in free form executable config files. Systemd separates code from daemon config options, so the latter are in structured text files that are easy to parse for both humans and machines.
The systemd developers really cares about details too, so it has the best bash-completion I have ever seen. It is a joy to work with the systemd CLI tools.
Vague criticisms about systemd's design really isn't much of an argument. Systemd actually works extremely well in the real world.
That's true, but pid 2 crashing won't halt the system, because pid 1 can restart it. If pid 1 crashes, it's power cycle time.
If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.
I do really think that the systemd designers have actually done their homework quite well when they started out. PID1 is quite small and only contain what is needed, everything else runs as helper processes.
Besides that, systemd can supervise itself (PID1) by using a watchdog, so the system can react if PID1 doesn't answer the watchdog "ping".
http://0pointer.de/blog/projec...
logind is just one example
Does nothing a script can't do
Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.
Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.
You are seriously misinformed on how systemd works and what it can do:
It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.
Here is a general overview:
http://0pointer.de/blog/projec...
Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities":
http://0pointer.de/public/syst...
There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from /home, even if they otherwise had permission to read in home.
All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.
It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,
This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.
Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.
I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.
General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.
If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.
Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.
The journal is primarily append based, so it designed to be very robust against corruption, the log is also rotated whenever a corruption is detected. So usually the corruption you see are a single line that was malformed when writing because e.g. the daemon died unexpectedly; this happens all the time with text based logs, but because they have no inbuilt integrity checks like systemd, it doesn't get discovered.
So in most cases you don't really loose any log info, and the rest of the log remains fully readable.
I am sure that there are subtle bugs in systemd that end up causing file corruption, or enhances the risk of corruption when the systems suddenly shuts down. But I also think that the bugs can and will be fixed, so I really don't see it as a long term problem. The many advantages by having an indexed and structured logfiles far outweighs the theoretically small chance of file corruption on modern file systems.
I don't think it is practically possible separate text logs from the metadata and get the same functionality as systemd's journal. AFAIK, the journal is more or less just a textfile+index anyway. Try running "strings" on a journal, it will show a lot of the logging info.
It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.
You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons, logind is just one example (ConsoleKit is a dead project with no alternative).
But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities" to massively strengthen security, or have a total supervision chain of all processes, including PID1 etc. There is so much good stuff in systemd that the SysVinit-like init distros could clone.
That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.
Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?
All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.
I think that there are actually very good design reasons for why systemd is designed like it is.
It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages, since it can act as a mediator between kernel features like cgroups and "capabilities" and the processes it controls.
The logging is a perfect example. Why do I have to learn a new program (journalctl) just to read the system logs? What if I had to learn the syntax of a new program to read the logs of every program that I used? That would suck. If openvpn and mysql and httpd and sshd all had their own little program that I had to use to read their logs, I would give up using Unix.
I already have a program to read all logs, more or less. And I already have a program that searches all the logs, egrep. Yes, I had to learn egrep syntax, but now that I know it, I can do almost any search imaginable of any program's logs. Except systemd.
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. .xsessionerrors and what not; everything goes into the journal.
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
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.
Agree.
The bottom line is that if people want FOSS to go in a particular direction, they have to fork out money or code. Talk is cheap, and fairly ineffective. That is true whether you're talking about commercial or volunteer-based projects.
Yes, freedom isn't a given thing. It may cost something to gain it or keep it.
Anyway, thank you for a pleasant conversation.
[snip]
If I had to choose between very fragmented or completely uniform, however, I'd choose fragmented.
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...
We can't predict where Linux will be used in the future, and so we may need the core-level diversity that fragmentation brings. It's about more than just where libraries are placed, but about ways of doing things. Being able to drop in an alternative system-level structure lets us try out new principles, such as systemd versus sysvinit for instance. We might all be using systemd in 10 years, but I would bet you nobody will be in 50, so if we're no longer able to experiment with alternatives because we're locked into one system, that new alternative will come from outside the Linux ecosystem. It's evolution: stop growing and settle into a niche, and eventually something nimbler will outcompete you.
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.
Ok, my mistake.
The future definitely doesn't look good, and I don't disagree with the arguments you offer to paint it so bleakly. I'm not ready to give up on alternatives, however, so I'll do what I can with my meager skills and encourage anyone else also doing so. I prefer to remain optimistic, that we can get enough people together to continue offering an alternative to systemd.
Not requiring everyone to use the same setup is one of the big strengths of Linux. That's one of the main reasons I don't like systemd as an ecosystem: it seems to be trying to force everyone to use the same setup, by depreciating everything else. No one piece of software should be so central that there is no way to replace it with an alternative, because otherwise you end up with monoculture and monopoly.
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.
Maybe, but I suspect that eudev will just merge in the changes wholesale, which doesn't require a great deal of effort. I don't think there is any driver to keep kdbus support out of eudev.
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.
In some ways the sweeping systemd victory, is a replay of the PulseAudio distro victory.
Sure, but believe it or not I don't have pulseaudio installed on my system. I don't really have any objections to it - I just haven't had any need for it either and thus haven't gotten around to installing it (even though that probably would only take 15min). If some program I used needed it I'd get it working.
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 still doesn't have systemd, and Patrick Volkerding has apparently come down pretty hard against it. He still hasn't accepted Pulse Audio for similar reasons, and that's from a decade ago. Unless you think Slackware will disappear, or that it doesn't qualify as a "distribution of note", I think it'll end up proving you wrong.
Yes, probably no Gnome and similar, but there's always Enlightenment, Xmonad, and plenty of other more palatable alternatives. There's eudev to handle /dev, Slackware already hasn't shipped with Gnome for years now, and there's daemontools/runit/s6 to replace sysvinit. I'm sure we'll find a way to steer clear of systemd, even if we end up in the minority.
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.
While there was a lot of the usual flames at the time of formation of eudev, from what I've seen in practice the folks maintaining it actually do try to follow udev reasonably closely and they certainly talk to their udev/systemd counterparts within Gentoo. There are certainly some philisophical differences, but I suspect that when kdbus comes along the eudev folks may embrace it (it is, after all, going to be part of the kernel). I think there is recognition that if they try to go in a completely different direction they're going to be short on manpower to keep it useful. The main maintainers of OpenRC on Gentoo are also involved in maintaining systemd.
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.
I'm closer to Gentoo than anything else, but from the occasional debian mailing list browsing I get the sense that the winds are blowing the same for both distros. There are people who aren't happy about systemd in both places, but nobody really wants to create yet another distro from the ground up to try to avoid it. There is a tendency to cheerlead anything that looks like opposition, but the fact is that most of the people actually doing the work have a grasp on the momentum systemd has.
Gentoo is a bit of a niche distro and has always been about fostering choices, so stuff like openrc/eudev, or even using busybox to populate /dev are going to tend to be supported to some extent for a long time. Gentoo also supports BSD, so OpenRC will be mainstream there indefinitely. I suspect that it won't be too long until the majority of users have switched to systemd.
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.
There wasn't that much SysV init development before systemd either. It just works, no need to hack on it.
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.
By what strange theory does Slackware support systemd? And how is the conversation being "held back"? At least on LQ, I think it's been discussed to death to the point where there's really nothing new to say about it.
I can say one thing for certain: you do not know that anything concerning systemd in Slackware is likely or not. Hell, *I* don't.
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.
Because systemd now has a replacement for ntpd.
The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!
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.