Slashdot Mirror
Debian's Systemd Adoption Inspires Threat of Fork
New submitter Tsolias writes It appears that systemd is still a hot topic in the Debian community. As seen earlier today, there is a new movement shaping up against the adoption of systemd for the upcoming stable release [of Debian], Jessie. They claim that "systemd betrays the UNIX philosophy"; it makes things more complex, thus breaking the "do one thing and do it well" principle.
Note that the linked Debian Fork page specifically says that the anonymous developers behind it support a proposal to preserve options in init systems, rather than demanding the removal of systemd, and are not opposed to change per se. They just don't want other parts of the system to be wholly dependent on systemd. "We contemplate adopting more recent alternatives to sysvinit, but not those undermining the basic design principles of "do one thing and do it well" with a complex collection of dozens of tightly coupled binaries and opaque logs."
The distributions should be wary of putting all their eggs in the freedesktop.org basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.
They assert on one hand that they don't have time to participate in Debian, and on the other that they have time to manage a fork. Not buying it.
That list glosses over a couple of major problems.
1) You avoid the current version because it's such a usability disaster that no one wants to touch it. It's so bad that people would rather run an ancient and completely unsupported version.
2) Your current hardware is suddenly obsolete because it's last years model and it's not supported anymore.
Modular design makes "rage-forks" a lot less of a problem than some people try to make them out to be.
A Pirate and a Puritan look the same on a balance sheet.
I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.
Bruce Perens.
Systemd does not need to die. All the more power to those who wish to use it.
However, it is undesired by a significantly large portion of users and sysadmins, and it is unsuitable for those who still actually want to run Linux as a Unix-like OS.
For these reasons, in my opinion, it is not (yet) ready to become the init for a number of general-purpose distributions out there. Moreover, it is unacceptable for the udev subsystem to reside in the same source tree as systemd, and it is unacceptable for udev to integrate, except through the use of a stable and init-independent interface, into any particular init implementation or design.
They claim that "systemd betrays the UNIX philosophy"; it makes things more complex, thus breaking the "do one thing and do it well" principle.
This isnt a thought or a prediction, this is something systemd actually does when it takes NTP, console, logging, and networking and forces them into one application. the fork threat is to be taken seriously because of the leaderships inability to actually recognize this as a massive security, scalability, and overall functionality problem that was steamrolled into debian largely at the behest of KDE and Gnome devs. The best solution to avoid a fork in my opinion is to give the user something thats also been forgotten about in the linux community: choice. Systemd or RC Init, or uselessd (a fork of systemd that tries to rehabilitate systemd)
Good people go to bed earlier.
Linux works out of the box in the same way that MacOS or Windows does.
If your average Windows user had to install their own OS they would be even more lost than if they tried dealing with Linux.
A Pirate and a Puritan look the same on a balance sheet.
Systemd may be fine for a desktop, but not fine for a server. I can say the same exact thing about NetworkManager, which I quickly remove from any server I touch because some Ditro's think that servers need this crap.
I refuse to use Ubuntu for example because they can their software for desktops. I don't have anything against Linux desktops mind you, but I don't manage thousands of desktops. I manage thousands of Linux Servers.
If Debian does not want to ship systemd I'm happy. It saves me from searching for a new Distro to replace our current all Debian environment.
If someone does not like Debian for doing so, they can go Fork themselves all they want. Forking has been the primary reason for Linux growth. Yeah yeah, we have seen some orphaned and a few died on the tree, but the best continue and breed more... (*intentionally punned*)
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I am an experienced Linux user, and I have tried several times to install Windows. Each time I look on a retail site, I see aabout a dozen different versions of Windows for sale, and I find endless discussion about which version I should install and UI changes that developers should not include in the releases, and how I should download some third-party apps to make the UI not suck.
It always ends the same, with me putting my credit card away... be thankful Linux works well.
I ended up on Debian because of Slackware's holdout with libc5 when everyone else had gone to glibc2. I then discovered that I liked the ability to use install packages with dependency checking to keep my systems up to date.
then systemd came along and made me sad.
Do not look into laser with remaining eye.
Are you kidding. Linux doesn't even need to be installed. You can just run it straight from the install media.
This is handy when you have a Windows install that can't even run it's own wired network interface and it can't tell you what driver it needs because it's too dumb to do that.
Linux liveCD to the rescue!
Boot up.
Interrogate hardware.
Proceed with beating the bushes to find Windows drivers.
A Pirate and a Puritan look the same on a balance sheet.
To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.
After so many years, I have finally understood why Debian is constantly rises, hits the plateau, freezes for few years in shock and tumbles back down. They want to be just a distro. They do not lead - they follow. They do not create standards - they adopt them. They do not develop stuff - they just repackage someone else's stuff.
That again was one of the driving factor in picking the systemd over the rest. With systemd, somebody else is doing all the work, while Debian just repackages it.
Is fork a good idea? There is no fork, really. Debian is nothing but an organization, a community. One can clone the repo - but one can't clone the community.
Take out from all of this? There are no reasons to worry. Nothing really changed. Debian is simply following the rest of the distros. I'm simply hopeful that they would manage to integrate the systemd nicely. If not... It's not like it would be the first time Debian released something broken and unusable. (Oh, yes, there might no RC bugs - but the (too old/too new) versions of the software, or their configuration, simply make it useless. And trying to change it - breaks it.) That's why we have the Ubuntu, after all: it's like Debian, but not striving for some committee set goal - instead striving to be just useful.
All hope abandon ye who enter here.
I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.
The Ubuntu LTS releases, are pretty much what I always expected from the Debian.
The difference is that Ubuntu isn't afraid to put time of developers into the release.
While Debian insists on simple repackaging.
I'm sorry to say it, but Debian has already been a "whore" to lots and lots of other distros, even before Ubuntu hit it big. For the fact of having no distinctive technology of their own.
Recall the time when the APT was ruling. Back then, the Debian ruled. APT had set the bar for other package management systems. People followed the Debian. Now? Not so much. Debian is following and has been following for many many years now. They are not distro per se - they are the distro factory, other distros build up on. I gather that makes it a "whore" distro.
Blaming Ubuntu misses the point. Because Ubuntu does much more than just repackage the Debian. The bigger question is: why Debian hasn't evolved into something like Ubuntu is? Where's Debian's launchpad with the PPAs? where anybody can develop new things? where from users can easily access the new things?
All hope abandon ye who enter here.
I trust the Debian committee - as a collective - to make the best choice. The committee has a large group of people with diverse interests and the majority voted to adopt systemd. Debian isn't exactly known to be a flippant Distro.
I suspect the technical people behind Debian/Fedora/Arch/OpenSuSE and other Distributions (some of which make money on their products and services) are a lot smarter and thoughtful than a bunch of people with a website that has a purple background and orange links.
I've used systemd under Arch, and i could open up a systemd unit file and understand what every word in the file meant. I can't say the same thing about most SysV startup script.
Even in the Debian TC that voted in the first place it ended in a 4 to 4 split with the chairman breaking the tie. That's not a minority, that's half.
Yeah: Inability to debug what is wrong with the init system when you aren't doing exactly the use case that "normal" people use. I have a number of problems with it, but here's one: /var was on a local partition. I had that working under OpenSuSE and need to switch (for unrelated reasons) to Fedora. First, my filesystem didn't get mounted read/write. Easy fix, once you know what's wrong except that journald swallowed all the output (even though I turned on journal+console) and I had no log because of the read only filesystem. The only indication of what was ewrong was systemd saying journald had timed out. On a hunch (after seeing posts on the Arch Linux boards) I added "rw" to the kernel command line and finally got a login prompt. Now, I can't get the /var filesystem to mount before dbus starts because udev depends on dbus and the mount is a systemd special that depends on the device being present which it is, but it requires udev and dbus just to check to be sure. I've also got some weird issue with dependencies not being satisfied so the console getty never starts (on a serial console - the correct unit file seems to be there), but I'm ignoring that since I have network access. Oh, and the system won't shut down cleanly because it shuts down the network before unmounting the root filesystem which is mounted over NFS. But again, I don't even care about that anymore - I just hard reset it with the BMC. I'm sure you'll tell me that I'm a moron and have the thing horrible misconfigured. I *do* have it horribly misconfigured. What I'd like to know is how to *fix* it and systemd is getting in the way of that.
I've been trying for the last two weeks to end up in a place where my root filesystem was served up by NFS and
In SysV init, I would've seen stuff whining about permission denied errors on the console (instead of all the output being eaten, despite turning on debug mode and journal+console mode) and realized I probably didn't have the filesystem mounted right. For the /var stuff, I'd just put it in /etc/fstab and be done. On the off chance that that was not early enough in boot, I'd add a shell script (or hack it into the earliest script) to do the mount. With systemd, I've tried creating unit files several different ways. Telling them they have to run before the stuff that is breaking. No dice. I have no idea why. I thought "ok, I'll just test-run this in a chroot environment". Nope. Systemd won't run there, even to just tell you what it *would* do. In the end, I've wasted weeks on this, learned little about systemd (despite trying - it's the future whether I like it or not. And I don't), and if I ever get it working, systemd won't have gotten me *anything* that I didn't have before. I'd *vastly* prefer an architecture where normal /etc/init handled
I don't think that the former poster is complaining that the source trees happen to be managed the same way. He's complaining that dependencies are being created between different pieces of software that don't need it. If systemd were set up to where there was a standard /sbin/init and SysV (or similar) init scripts and in a desktop Linux, there was only one script: start systemd, I'd be happy. I suspect most other sysadmin/developer people who hate systemd would be happy. I don't care if it exists, and I don't even care if it exists by default. What I *want* is to easily get rid of it when it's not appropriate for the task I am trying to accomplish and there isn't currently a way of doing that because systemd, journald, dbus, and udev are all tied into one big knot.
Go Badgers! -- #include "std/disclaimer.h"
from the summary
That is really the crux of the issue and what distinguishes the systemd dispute from all the other FOSS food fights. The FOSS community never agrees on anything. That is why we have multiple everything: Multiple Kernels (BSD & Linux Kernels, multiple flavors of each) many distributions of each flavor, a host of programming and scripting languages, multiple package management tools (rpm, portage, dpkg) several GUI toolkits, GNOME and KDE desktop environments etc. Wayland is not enough, we must also have Mir. And the licenses. Egads! How many of those do we need?
Despite all the passion and ego involved, disagreement between adherents of particular designs and implementations has never before risen to the level of open revolt that we see over systemd. Why? Because in all these disputes each person can choose what is best for him/herself. Like Python and despise Perl? Use Python. Vice versa? Use Perl. But the usual rule of the user getting to pick what he likes best does not apply with systemd. Lennart Poettering is working to restrict choice to only systemd. His tactic is to make systemd a dependency of major software packages. Here he ison the Gnome dev list pushing a Gnome systemd dependency.
Sometimes an unpopular item is replaced on the buffet; Good software wins out and variety shrinks a bit. That can be a good thing. But the fear is that systmd is going to win not because it is a popular choice but because Poettering has gamed the outcome using dependencies. Something is wrong if you are running systemd because you hate it and you love Gnome. Perhaps the fanatical hatred of Poettering is driven by belief that systemd adoption is advanced in part by his cheating, instead of on the merits of systemd alone. The abusers are abusing not because he has written what they judge to be bad software but because he has violated an unspoken ethic of the FOSS community.
Ceci n'est pas une signature.
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
Sure, the problem is "What is Unix Philosphy"? and is it meant as a dogmatic ex cathedra so that Unix can never deviate from whatever that philosophy is, no matter that computing changes every decade with new domain problems?
Unix wasn't even born with the now basic concept of "piping", it was a development over time. So I think that the so called "Unix Philosophy" is much more about sound guidelines and how the Unix developers tackled the computing problems in their day, than any dogma that can't be deviated from.
These days we have massive use of Linux OS containers and VM's, using petabyte of storage spread across continents and many other domain problems that was unheard of in the 1960's. I do think that the present development and use of Linux in so many ways, also require new ways for Linux to function. If Linux is put in a 1990's time freeze it will simply become irrelevant and wither away.
I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.
You can still use the same old flat text files logs with systemd distros by using rsyslog like you always had. Nothing is taken away, and in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.
I was really skeptical about binary log files before I tried it, but walked away convinced that binary logs like those used by systemd's journald, is the way forward.
They really solve so many hard/impossible to fix problems with flat text file logs, and I have yet to find any real world problems with their actual implementation. All the usual Linux text tools like "grep" and "tee" works with the systemd journals through the basic Unix concept of piping.
The systemd developers really did their homework well when designing the systemd log implementation, and it is worth a serious study by anybody working with Linux, instead of a upfront dismissal just because they are binary.
I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.
Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed?...
Using scripts (basically executable config files) to start daemons is probably a relic of the time when invented decades ago. The needs where much simpler in those days, and shell scripts was just a handy tool to have a quick and dirty solution to the problem. It haven't made sense for a decade at least to still using SysVinit and similar solutions, and all? certified Unix'es have switched long ago. In fact, launchd and Solaris SMF where major inspiration points for systemd.
It is quite doable to make a init system that uses declarative statements in text config files, both systemd and SMF does it. But it wouldn't be SysVinit anymore, so which distro will actually use such a init system? Slackware has its own style of SysVinit and is extremely conservative, an unlikely distro to change from what is has. Gentoo has OpenRC, and is also highly unlikely to change from that too.
So while possible to make, it is probably hard to find "buyers" for such a new init system, and therefore also developers to make it.
It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.
Yes, they are split among those who think SysVinit should be used the next 40 years too, and those who recognize something else is needed for modern computing needs. Even the latter group is sub-divided into factions about one should make an improved systemd clone for compatibility reasons, or use OpenRC for BSD reasons, or making something new etc.
So instead of focusing on making a developer community to counter systemd with new code, they focused on a negative campaign against systemd instead. It is so much easier to rant on the net than organizing and making stuff happening. But that negative strategy is also the single most important reason why systemd-opponents have been routed whole-sale from every major distro; they attacked open source developers and projects, while failing to provide an alternative.
Agree about the Unix thing. "Unix philosophy" It has become a cartoonish mockery of all the great things the Unix developers did back in 60's and 70's. Totally without content and with no connection to reality.
A split decision that created flames of epic heat, even for Debian, even for Free Software in general. Flames that burned far hotter than even Vi vs Emacs. Flames that just won't die out. And the systemd side makes it worse with the attitude of STFU they project. The problem is a TC can't make this decision because it isn't technical, it is cultural and social.
This is a culture clash, between the UNIX folks who want UNIX developed in the open Linux model (as opposed to BSD) locked in a battle with people who want Windows that doesn't suck. And worse the systemd side has made it clear they are going to intentionally design out any possibility of co-existence or compatibility so it is a binary decision, take systemd and keeping any other set of low level plumbing viable is going to get very painful, very quickly.
Compromise is therefore not going to be possible since one camp is dead set against it and the UNIX camp will not accept systemd. So a fork is going to happen, but probably not just Debian. The whole Linux world will soon be the GNU/Linux camp vs the Freedesktop.org/GNOME/Linux camp.
The real root of the problem is Pottering and Co. hate UNIX and want to use the kernel as a device driver to build a new platform upon. They should have simply joined ReactOS but it isn't sexy enough for their egos and besides, RedHat won't pay their salary to work on that project.
Binary log files are more compact. They can be better indexed. They lend themselves to localization more easily by abstracting the problem away from the executable that writes them. They can be strongly typed.
Frankly, you listed a bunch of tools which process "text logs" as though they're not doing exactly the same thing a binary log file tool is doing. They are also not "basic tools". Regex parsing is anything but basic, it's just commonly included. Just as journalctl will be on *any* system which uses journald because it's a basic tool.
There's also a huge strain of American-centrism here. Plain text sounds great so long as you assume it's English.
I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.
Yes, for the kind of people who run Redhat, which is a turnkey "lick and stick", "Call support", "it's someone else's problem" kind of Linux. Great. I would expect redhat users to fully embrace systemd. That's not a shock.
For the kind of people who run Debian, it's a big deal. At least, half of us. Half of us are apparently there only for ease of use. They should fuck off to Ubuntu and leave the rest of us alone, since there's already a Debian-fork for them.
It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well,
Sure, Solaris has, but AIX hasn't. So what? That was a post-acquisition move, right? And Oracle has a serious NIH mentality. It's not done until it requires Oracle RDBMS. Just wait.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Unix wasn't even born with the now basic concept of "piping", it was a development over time.
It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.
The systemd developers really did their homework well when designing the systemd log implementation
No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless. Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read. If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.
I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.
Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"