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."
... I was already investigating into FreeBSD as option. I welcome a fork of debian. The developers are irreparable split anyways. Half of them are pro systemd, the other half are not. So why waste time into talks. There won't be an acceptable solution anyways. So better head off and fork the project. I want to see how debian will survive, once half of the develoeprs have rushed away to form a new project.
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.
There is a certain contingent in Debian that is not good for the project, IMO. I would like to see which side of a fork they are on, and pick tthe other.
Bruce Perens.
There are too many competing standards. Clearly what we need is a new, unified standard. ;-)
Whoever installs your OS chooses for you. Might be your hardware vendor, maybe your nerdy cousin.
My wife read about Vista when it was coming out, and she asked me to install "Linux" for her so she could get used it to it before Vista happened.
I didn't ask her which distro; I chose one.
Anybody who can install an OS can choose one.
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.
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.
Come to think of it ....
Have gnu, will travel.
We've tried having standards in Linux before, and they were utterly ignored (Linux Standard Base). Basically, there is no reason for certain groups or developers (Red Hat (and to a lesser extent, Canonical) and developer-who-shall-not-be-named) to listen to everyone when they can do whatever they want and everyone else has to deal with it.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
My Linus just worked right out of the box. You have to get past the F--- You! if you have NVidia graphics, and the prickly user interface that periodically tells you you're a moron.
At least it's better than my Stallman. That thing ate something off the bottom of it's foot while I was giving a presentation. Yechh.
I disagree. Having Linus yelling expletives at your average PC user would go along way towards educating them or scaring them away from computers.
The end result is the same in either case.
The average user also has about one tit, one ball and half a penis. Just wanted to mention that.
Linux could work for the average user, at the end of the day there is no technical reason why not. After all Linux(in the form of android), dominates on the cell phone market, where the user base demands greater user friendlyness, has less patience, and wants even more bells and whistles, and is far less compitent with a computer. Linux has been shown to work marvelously with light meters, accellerometers, USB, touch screens(multi-touch even).
The big issue is how consumers by technology. They don't care about specs really, they don't care about merit. They care about branding and imagine. They want their Apple(tm), search with google(tm). Advertising and public relations gurus over the last few decades have build reality distortion bubbles, where people actively identify with brand names. GNU/Linux has no such brand name. They really don't care about "just works". Face it, windows does *not just work*, but people do whatever it takes, because they think windows is what they are supposed to be using. Microsoft presents the image of normalicy and conformity that most people identify with.
Apple on the other hand, presents an elitest artisan, fine craftsman, and intellectually supperior image, that marks the owner as part of an elite group.
Linux cleans up serverside, because it rode the wave of start up culture of the 1990s. If you had a great idea for a new website, but didn't have much capital, you could run a proffesional website with Linux, Apache, Mysql, and PHP out of an old desktop for a fraction of the cost of what constituted a proffesional server, of the day
As these companies grew, they continuted to use linux, and helped it transform into a proffesional class OS, that couldn't help but take notice.
Linux will eventually take over the desktop, and the reason is because microsoft has no real friends, and they have an ever growing list of enemies. Many of those pimpleface teenage nerds they stepped on back in the 1990s are now grown developers and sys admins. Their day dreams are now multi-million dollar products. Linux has a lot of corporate backers, many of which are household names, and some of the largest most powerful corporations in the world.
Whats eventually going to happen is that MS is going to piss off another giant like Google or Samsung to the point they want blood. You'll see a few large companies pour money, time, resouces, advertising into a distro with enough MS haters to accept them, and then use a Free as in beer product into the desktop market, to crush microsoft to prevent them from competing in other markets, by destroying their cash cow.
There will not be a year of the desktop. It will be a decade of pure hell, and microsoft is going to fight tooth and nail, and use every dirty trick in the book to keep the desktop market. They will eventually loose, because the nature of FOSS allows many companies to quietly pool resources behind a single banner, especially a not-for-profit, and allows more to join later without any real effort or diplomacy. Eventually it will be taken from them, and from that point its another 10 years before they go out of business.
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.