Debian's Systemd Adoption Inspires Threat of Fork 555
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."
Finally ... (Score:5, Interesting)
... 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.
Re:Finally ... (Score:4, Interesting)
I am entertaining FreeBSD and Slackware as viable options. The only thing in Slackware's favor is the games I play will run on it vs FreeBSD.
Re:Finally ... (Score:5, Insightful)
then systemd came along and made me sad.
Re: (Score:2)
I'm not concerned over 2GB of space unless I'm running an embedded system, in which case I'm probably not installing X or XFCE. (I'd bet XFCE is where your space is being gobbled up).
Re: (Score:3)
Re: (Score:3, Interesting)
freedesktop.org (Score:5, Insightful)
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.
Fedora fork too (Score:4, Interesting)
http://forkfedora.org/ [forkfedora.org]
Not really, but well made.
Re: (Score:3)
http://forkfedora.org/ [forkfedora.org]
Not really, but well made.
That's a good point as to the the drawbacks of the "do one thing and do it well" principle.
The individual tools get simpler, but some of the complexity pops up when you try to make them interact. So instead of complex programs we end up with complex and esoteric configurations that end users have to descipher.
I'm not a fan of everything involving systemd, but the idea of shoving a bunch of complexity into a well designed and reliable blob doesn't strike me as an intrinsically bad idea.
Re:Fedora fork too (Score:5, Informative)
All that proves is that Fedora's init scripts suck. I'll believe that.
Here's Slackware's rc.sendmail script:
#!/bin/sh
# Start/stop/restart sendmail.
# Start sendmail: /usr/sbin/sendmail ]; then /usr/sbin/sendmail -L sm-mta -bd -q25m" /usr/sbin/sendmail -L sm-mta -bd -q25m /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m" /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
sendmail_start() {
if [ -x
echo "Starting sendmail MTA daemon:
echo "Starting sendmail MSP queue runner:
fi
}
# Stop sendmail:
sendmail_stop() {
killall sendmail
}
# Restart sendmail:
sendmail_restart() {
sendmail_stop
sleep 1
sendmail_start
}
case "$1" in ;; ;; ;;
'start')
sendmail_start
'stop')
sendmail_stop
'restart')
sendmail_restart
*)
echo "usage $0 start|stop|restart"
esac
That's all we need ... (Score:3, Interesting)
The solution to yet another init system is to support even more init systems?
If systemd needs to die, then say so. Give the reasons why, then fork it if necessary. We've got enough problems supporting different not-invented-here stuff in too many distros already.
Re:That's all we need ... (Score:5, Funny)
There are too many competing standards. Clearly what we need is a new, unified standard. ;-)
Re:That's all we need ... (Score:5, Insightful)
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.
Re: (Score:3)
However, it is undesired by a vocal minority of users and sysadmins
FTFY.
It is not a minority. It would become a overwhelming majority when the systemd would actually be installed on the majority of the systems. But it would be too late then, of course.
I probably shouldn't care at all. Systemd would never appear on the systems I work with. For the simple virtue that it is, with the dozens of other "supervision" frameworks, is simply redundant, primitive junk, which is only capable of starting and restarting the Apache server (a.k.a. "hello world" type of service, with no real
Re:That's all we need ... (Score:5, Interesting)
So you know the majority of system administrators? That's an awful lot of people.
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.
This is, by all appearances, a tempest in a teacup, mostly existing here on on slashdot, where groupthink has moved against systemd without any real argument against it other than mumblings about philosophy, or theoretical problems that haven't been shown to even exist in systemd.
If these "supervision" frameworks of which you speak were redundant, then why do they exist in the first place? Clearly system v has had some pretty big limitations. I've personally hacked many a cronjob to supervise processes started by sys v init scripts (some of the init scripts I wrote myself... yuck). Also as servers move into virtual space, and deal with hotplugging of various resources, it just wasn't enough. Took years to get consistent naming on network interfaces, for example, and even then I could never be sure which interface was which when I first brought them up (they usually followed motherboard numbering, but not always). To say nothing of adding other hotplug interfaces of different sorts. Even after the udev hacks brought some sanity, every time I'd change out a network card, or clone it to a new system with a new MAC address I'd have to either delete the udev config for it, or have it change to eth1, eth2, etc. And by the way, it's not even systemd that does all this now, it's systemd-udevd. So it's still modular and you could replace systemd with uselessd, and then run a separately-packaged udev.
It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well, or at least abandoned shell scripts as part of the init system, for a more comprehensive and capable system and framework. I'm not sure if Apple ever used system v init, but they certainly abandoned the script system in general with 10.4 and LaunchDaemon. They had good reasons to do so.
Re:That's all we need ... (Score:4, Insightful)
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.
Re:That's all we need ... (Score:5, Insightful)
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.
Compromise or the lack thereof (Score:3, Insightful)
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 peopl
Re: (Score:3)
I prefer to call it Poettering Operating System/Linux
Re:That's all we need ... (Score:5, Insightful)
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.
Re: (Score:3)
If I didn't know otherwise, I'd say you were tinkering with my Fedora system.
I decided switching to a different distribution would be easier than getting systemd to do what I want.
Re: (Score:3)
Re: (Score:2)
Good point - that makes a huge amount of sense.
Which is probably why they're doing exactly that.
What? (Score:5, Insightful)
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*)
Re:What? (Score:5, Insightful)
On a desktop, systemd and firewalld make sense, because one might have an Ethernet connection that is in a trusted zone, a Wi-Fi adapter that is on a public (untrusted) zone, and so on. Plus, the parallel startup of systemd makes booting a lot faster.
For a server, one wants reliability and security above all. One reason why IBM still obtains boku bucks is because AIX 7.1 still runs applications written for 3.2.5. It might require some compatibility programs to be installed, but if one wanted to run FrameMaker or WordPerfect under Motif, they still can, assuming a graphics card present.
Server-side, it doesn't matter if things start in series. Things need to work properly and be coded for maximum security and reliability.
systemd is the iTunes of the Linux world. It does so much in userland, that a bug in that can mean disaster, or a series of disasters similar to the tons of sendmail holes found in the early to mid 1990s. While it does improve some things, having a large, monolithic package handle so much of userland can mean big trouble [1].
My personal take: systemd is a leap forward. But, for something this crucial to infrastructure, with so many moving parts and so many different interactions between them, this really needs to run through a bug stomping session. Maybe Facebook would torture-test it like they are doing btrfs so that virtually all the major bugs get squashed sooner, rather than later. Even better might be a formal code audit on it (a la TrueCrypt) to find and squash anything that could cause the next Shellshock or RTM worm in coming years.
The one thing that has kept the epic fails out of UNIX is the fact that the OS is made out of a lot of little subsystems. Replace bash with busybox, not that many programs would notice. Replace /bin/yes with busybox's yes... who cares. However, systemd breaks this philosophy. If something breaks, I can't just rename the binary, link in the busybox equivalent, and call it done. I'm dead in the water until a patch comes out, and since this is a subsystem that completely controls the userland environment, this is worrisome when it comes to production critical items.
[1]: Ironic how this is similar to what Tanenbaum said about the Linux kernel.
Re: (Score:3)
Debian can already do parallel starts without systemd. That could be improved upon, but I see no reason systemd's approach is required for that.
Honest question, Can anyone out there name a single reason everything systemd does can't be done as well or better using a simple helper app to start the daemon (and optionally stick around to monitor/control it)?
Any clue why systemd should even have an interest in replacing the well tested nntpd?
Re: (Score:3)
Re: (Score:2)
What is it about a server that makes systemd inappropriate? NetworkManager I see; servers rarely change their network configuration when they do they want to do it in a controlled way, not an automatic way.
But I don't understand what similar distinction you're drawing for systemd. It doesn't take away the ability to carefully manage your configuration via text files, and doesn't do anything automatically unless you ask it to; what about running a server makes systemd undesirable?
Re: (Score:3)
The primary downer for systemd on servers is the lack of backward compatibility for boot scripts. We hack things often, and the last thing I want is to have a competing system which may decide that a systemd DB entry should override my #!/bin/sh legacy mode script for the same functionality. Further, we test things by interrogating boot script, and obviously with systemd those tests all need to change to new methods.
I'm not claiming it's an impossible task mind you, but would add a ton of work no matter h
Re: (Score:3)
We normally don't hack things because Init is broken, we hack things because a driver or application requires some tweaking. What if I'm on a server where the brocade takes longer than the driver expects to respond? What if I'm starting up 200-400 Apache sites on the same host and I need to make sure I have numerous DBs available, bind each site to a unique IP (and I only want the interface up if the site is up)?
There are numerous examples like this which have nothing to do with Init being broken, and Sys
Re:What? (Score:5, Insightful)
In the past, I have resorted to booting with init=/bin/bash and then running the rc scripts by hand to see the problem. Systemd won't even try to work if it isn't pid1, and it can't be if I booted init=/bin/bash.
In other cases, I have booted to shell, mounted up the filesystems and then did /etc/init/d/ssh start so I could get a second opinion. Try that with systemd.
In any number of cases, I have had to set something up that the system scripts and configs didn't (and couldn't have) anticipated. It was a simple matter of editing a few init scripts...
Imagine the 'fun' if you need to boot to a rescue disk, chroot into the server filesystem and bring up services while you fix a problem.
These 'heroic' measures come up when a server is in a lights out environment hours away. Sometimes the best approach is to get it to limp along until regular hours.
Re: (Score:3)
Your point seems to be, "new stuff requires new debugging methods on failure, avoid new stuff."
My point is new things should HAVE an effective debugging technique.
I am fine with replacing or greatly updating SysV. I simply don't see systemd as an improvement on the balance. Its wrongs outweigh its rights.
As an aside, most competent admins wouldn't be "resorting" to the kludge you describe, and will probably just stare and you and blink rapidly when told doing so is supposed to be a good thing.
I guess they think the answer is to stay down while they do a total re-install without understanding what was wrong then?
Re: (Score:3)
The PaaS vendors are all excited about systemd. So that's just simply false. It is better for server.
Re: (Score:3)
And that's the problem - adding support for systemd is like the camel's nose.
Debian's proposal is not workable over the long term, because the long-term goal of systemd is incompatible with non-systemd init systems, and it's not like we don't have enough maintenance headaches already with every distro seeming to have their own scripts, etc.
So what do you do,
drinkypoo?
When it all sucks,
just go boo-hoo?
support systemd
e'en if it's a mistake?
of course not,
but that's just my take.
Burma Shave
I
This could be really good for Debian (Score:5, Interesting)
Re:This could be really good for Debian (Score:5, Insightful)
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.
Re: (Score:3)
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.
Debian doesn't have a big pool of paid developers they channel into whatever project they wishes. The Debian technical committee is just doing the only sensible thing in choosing a working, well maintained init system for Jessie, instead of a not-quite-here/vapourware/unproven init system so close to the freezing of Jessie.
That decision doesn't prevent anybody from actually making an init systems that is better than systemd and the Debian could adopt for Jessie+1 (the decision was strictly for Jessie).
There
Re:This could be really good for Debian (Score:5, Insightful)
Re: (Score:3)
Is there any current distro focused on easy desktop use that has resisted the system wave? I'd hate to see the world divided into "server distros (know what's you're doing or don't even try)" and "easy desktop distros, system required".
Re: (Score:3)
I've found one major distro that still avoids systemd (for now anyway): PCLinuxOS.
It's listed on DistroWatch among the top 20 Linux distros, for whatever that's worth.
Otherwise, every other major Linux distro uses systemd.
Re: (Score:3, Insightful)
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
Comment removed (Score:5, Insightful)
Re:its not a claim, its a fact of life. (Score:5, Informative)
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.
Except it's not. /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-timesyncd /usr/lib/systemd/systemd-networkd
My system is too old so I don't have the consoled on it, but I imagine that will be a separate daemon as well.
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)
That would of course be nice. But someone has to do the work. It's not like it's just a matter of flipping a bit and everything just works. You actually need to go in and make sure that stuff works with all of them.
Re:its not a claim, its a fact of life. (Score:5, Informative)
One might as well complain about all the basic utilities under the GNU project umbrella.
I can use ls without having to use info, but I can't use systemd-networkd without using systemd. Conversely, there is no logging system other than systemd-journald that works with systemd.
In other words, each individual program that makes up the "systemd brand" must all be installed and running or else none of them work. This is completely different from the current init system, which doesn't care which system logger (for example) you use, and doesn't even require you to use one at all.
So, even though the "systemd brand" is many separate applications, the net result is no different from one monolithic application with many shared libraries.
good for the ecosystem? (Score:2)
UNIX Philosophy (Score:4, Interesting)
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.
However, do these programs follow the do-one-thing-and-do-it-well principle: web servers like Apache, database servers like PostgreSQL, the X Window system, the GIMP, OpenOffice? Is an init system more like one of these or more like sed and awk? That's not a rhetorical question. I'm a web programmer who loves Linux, but the kernal and start-up are still black magic to me.
Maybe an init system can be simple. 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? Can't programs be formalized to follow some init API? If the start, stop, and restart are not enough, maybe also an option, like --bg, that they'd all take, so the init system always calls $program --bg start, or $program --bg stop, or whatever; so that all we need is that simple config file. Those programs that don't yet follow the init API could keep using a shell script until they do.
Please have mercy if this question is terribly naive. I've tried googling . . . a little. I was hoping a real live human being could either explain it all. Or feel free to reply with some links that explain why SysV init needs all those shell scripts and can't be just a simple list or somewhat-simple declarative configuration.
Re:UNIX Philosophy (Score:5, Informative)
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.
Re: (Score:2)
> However, do these programs follow the do-one-thing-and-do-it-well principle: web servers like Apache, database servers like PostgreSQL,
Yes they do actually.
One serves web pages and the other enforces the relational model on data. They aren't one huge behemoth that includes both of these as well as some other application level features.
Re: (Score:2)
If you think httpd only does one thing you clearly have never even cracked the configuration file open, let alone compiled it.
Re: (Score:3)
One serves web pages.... and acts as a proxy, a cache, a load balancer, an SQL client, has its own authorisation system.... Apache is probably the single biggest and bloated web server currently available on Linux. It definitely does not do one thing, however it gets a tick for doing most things well.
Likewise PostgreSQL has a feature list so incredibly long that is not related to the core of having a simple relational database model that it's own Wikipedia entry could be accused of being bloated. But again
Re: (Score:2)
Systemd even has a shutdownd. I'm pretty sure it does one thing and does it well.
Re: (Score:3)
It may only do one thing, but it most *certainly* does not do it well. I've yet to have a system with an NFS mounted root filesystem correctly shut down under systemd.
Re: (Score:2)
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
Do you use X?
I actually find the whole change hate thing funny in general. The public galleries attack systemd for lack of Unix philosophy and then give X a free pass calling Wayland change for change's sake.
Re:UNIX Philosophy (Score:5, Interesting)
Please have mercy if this question is terribly naive. I've tried googling . . . a little. I was hoping a real live human being could either explain it all. Or feel free to reply with some links that explain why SysV init needs all those shell scripts and can't be just a simple list or somewhat-simple declarative configuration.
It's a political problem more than a programming problem. Someone has to get input from everyone involved, and come up with a solution that makes everyone reasonably happy (including BSD folks). Specifically, any solution has to have three things:
1) Be easy for distro builders to work with
2) Be easy for developers to implement
3) Accommodate people who still want to do their own thing
4) Be implemented in a diplomatic way, so people will be willing to compromise.
SystemD tried to avoid the political problem by not caring what other people think.
SystemD also made the mistake of making an implementation, NOT a standard (which is what you correctly suggested), so it is hard to replace with alternate implementations (competition is a good thing). Furthermore, it is not a stable interface, which makes replacing it even harder.
Re: (Score:3)
1) Be easy for distro builders to work with
2) Be easy for developers to implement
3) Accommodate people who still want to do their own thing
4) Be implemented in a diplomatic way, so people will be willing to compromise.
I forgot one here:
2.5) Be easy for system admins to work with.
Re:UNIX Philosophy (Score:5, Insightful)
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.
Re:UNIX Philosophy (Score:4, Insightful)
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?
Re: (Score:3)
I'm a web programmer who loves Linux,
Welcome.
but the kernal and start-up are still black magic to me.
SysV init is really quite simple. Just a few minutes playing around with it on a system and you'll get the hang of it. First off, there are several run-levels. Let's focus on just one run-level for now since most people only ever edit one (they'll use run-level 0: shutdown, and run-level 6: reboot, unknowingly). Within each runlevel directory (let's choose /etc/rc5.d/) are symlinks that point to the scripts in /etc/init.d/, and these symlinks are named with S for start or K for kill, followed b
In Soviet Russia .... (Score:5, Funny)
Come to think of it ....
Never bring a fork to a gun fight (Score:2)
A rather empty threat (Score:5, Informative)
There are +150 Debian forks (derivates) already, so yet another one hardly matters. The main reason why its is an empty "threat" is that there basically isn't any real development of needed infrastructure in the non-systemd camp, and as time goes by, more and more alternative development will be need by non-systemd distros.
The fork of systemd's "udev", "eudev", is basically just a shadow fork with patches, but soon eudev maintainers have to decide between having to support a kdbus manager, thereby become more developers instead of just patch maintainers, or their fork will deviate so much from the real udev, that they no longer just can leech new patches from it.
Of course, ConsoleKit is still dead with nobody picking up development, the only alternative is a rather limited implementation of systemd-logind, and is basically maintained by a Canonical developer who are unlikely to maintain it after Canonical have switched to systemd.
Stuff like root-less X.org can at the moment only be safely done by systemd. Some Wayland implementations will also depend on systemd simply because the upstream projects aren't getting any help at all in supporting non-systemd distros.
Even SysVinit isn't in such a hot state, it haven't made a release in five years, and the defacto upstream maintainers have been SUSE/Reed Hat for years. At some point they will drop maintaining it anymore.
I could go on, but the fact is that there is an increasing amount of work needed to be done, just in order to keep status quo somewhat, and that the non-systemd camp are severely lacking developers that could help maintaining such critical infrastructure.
It would actually be quite good for the non-systemd camp if there was a proper Debian fork that solely was about non-systemd developemnt. They have been lacking a focal point for such development for a long term stable distro for years (Slackware, despite its merits, is ultra conservative and probably too limited in certain ways for this).
The problem is that some factions in the non-systemd camp are pursuing systemd "emulation" by using shims and forks. That way you just get a second rate systemd, and it will remove any motivation from upstream projects to support anything else than system. Using Ubuntu's "logind" is a short term gain, but a strategic failure for the non-systemd camp. They need their own implementation of needed infrastructure, not just copying or emulating systemd.
Re: (Score:3)
Even SysVinit isn't in such a hot state, it haven't made a release in five years
This kind of stability is a good thing.....once you get a tool right, it shouldn't need to change much.
The fact that we are still arguing about how to do an init system 30 years into Unix is ridiculous.
A completely empty threat (Score:3)
Threatening a fork is like threatening legal action: if you think you're to that point, you need to just do it, and inform the relevant parties afterwards. Anyone can threaten to take action.
Re: (Score:3)
So it hasn't actually needed a change in years (meaning it is fully matured) but you're worried that there isn't enough manpower to churn the code (that needs no churning)?!?
I am not worried since I use systemd and will never run a SysVinit distro again in my life. My point was that those who doesn't want to run systemd need to realize that a lot of work is needed in the future, and that the non-systemd camp is entirely responsible for making and maintaining the necessary code in order to e.g. run SysVinit in the future.
Trying to making a virtue out the fact that SysVinit is understaffed (and this is going to get worse when the paid developers from SUSE/RH stops making bugfixes
An opportunity for Debian? (Score:4, Interesting)
Having used it almost exclusively since 2001, I've always regarded Debian as a distro for more tech-savvy and conservative types -- system administrators, for example. However, their recent move towards systemd seems very unlike them and, as a professional sysadmin, this worries me. Perhaps it's what we can expect, every once in a while at least, from a bunch of people who are not system administrators.
Luckily, they seems to be having second thoughts about the matter and this could be an opportunity for them. Their main competitor, which IMO is Red Hat, have already committed to systemd, which I'm not happy about either and find just as surprising. Therefore, since so many people have expressed their misgivings about it, if Debian were to reverse their earlier decision and go back to sysvinit (or at least make systemd optional), then I think we could see many sysadmins converting their RHEL systems to Debian jessie.
Mint Debian Edition (Score:2)
Isn't Mint Debian Edition effectively a defacto fork already? I would assume most Systemd haters are also Gnome3 haters.
Boot/init is a critical stage (Score:5, Interesting)
The init process is a critical stage: failure tends to leave you with no access to the system to diagnose the failure. I tend to break it into two parts, the first part being what's necessary to allow at least a single-user login on the console, and the stuff that happens after that point to bring up the full multi-user system and server processes.
I don't like systemd for the first part. It's overly complex, and the more parts and interdependencies there are the more things there are to fail. To quote an engineer, "The more they overthink the plumbing, the easier it is to stop up the works.". Shell scripts and plaintext log files may be primitive, but they have the advantage of being easy to read with minimal access and not requiring complex stuff to run (mainly they just require that basic binaries be available in the path). Until I've got at least a basic system up and running enough to log in and work, I want the init process to be as simple and straightforward as possible with as few points of failure in the init process itself (as opposed to the things it's starting) as possible. I want this stage to be as hard to break and easy to debug/fix as possible. I don't want to depend on complex tools at a point where I'm working in the most primitive environment.
I don't particularly like systemd for the second part, but it isn't quite as much of a problem here as in the first part. By this point I've got a basic system up, I can log in and work, and most of the tools are available. Obviously nothing graphical will work, but text-based tools will probably run to decipher binary logfiles and modify configurations. I still prefer not depending on such tools, because they're one more point where things can fail to work and leave me scratching my head trying to figure out what broke without access to basic diagnostic information, but at this stage I can likely fix any tool-related problems and get back on track.
The one part I think systemd works for is in the later stages of the second part. There's a lot of server processes with interdependencies that typically start after the multi-user system's up and running. I think systemd's a good thing for getting those running, it can do a better job of parallelizing that process than shell scripts can. The only change I'd make is to make systemd use syslogd like everything else, so log files end up in the expected place and are plain text so basic tools like more and tail and grep work on them as-is. Binary logfiles offer no great advantage over plaintext, and going through syslogd means not depending on two sets of tools and having to manage two configurations to get logging directed where it needs to go.
One last bit has me twitchy about systemd: history. SysV init scripts may be clunky and primitive, but they've been around a long time. People know how to manage them, and they've had the kinks worked out of them and best practices established. systemd doesn't have that. I do not want to make my servers (that have to run for anything to work right) dependent on something until I've had time to work with it and get familiar with it and, more importantly, it's been out there in use long enough for people to find and fix the problems, work out the oddities and figure out the best ways to use it without shooting yourself in the foot. I'd prefer to stick with SysV init on my production systems and only enable systemd on testbed systems at the start, and then enable systemd on a server-by-server basis so unexpected failures don't completely kill me (eg. if systemd blows up on my primary mailserver, the backup still on SysV can keep things under control until I either fix the problem or revert and restart the primary).
Re:Boot/init is a critical stage (Score:4, Insightful)
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 Trust Debain (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
You're wrong to suggest i don't have technical skill. I've done a fair bit of C programming against the Linux API. It might not be the bash scripting that you get excited about, but it's something.
Perhaps you've inadvertently stumbled on an interesting point though, could it perhaps be that what worries you most is the erosion of your exclusive club of arcane knowledge? I'd suggest to you that arcana is not a necessary component of te
This one is different (Score:5, Insightful)
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 is [gnome.org]on 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 [google.com] 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.
Re: (Score:3)
Just as an aside, have you noticed that his Google+ username is LennartPoetteringTheOneAndOnly?
This says pretty much everything that needs to be said regarding his mindset. To your point.
Re: (Score:3)
Oh come on! There are only 6 [lwn.net] hundred distributions.
Re:And this is why Linux will never win the deskto (Score:5, Funny)
Linus is NOT good for the desktop or average user.
Is Linus the Linux version of Microsoft Bob? I'd agree, then, that the average user wouldn't want him swearing at them every time they do something stupid.
Most people just want something that works out of the box, even if there are a lot of tradeoffs.
So why would they want Window 8?
Re:And this is why Linux will never win the deskto (Score:5, Funny)
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.
Re:And this is why Linux will never win the deskto (Score:5, Insightful)
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.
Re: (Score:2)
Linux works out of the box in the same way that MacOS or Windows does.
Which distro and desktop?
Re: (Score:2)
OSX is a little quirky for installs, but not that bad either... in general they are all okay..
Re: (Score:3, Informative)
Re:And this is why Linux will never win the deskto (Score:4, Interesting)
When my mom needed something for email and web I gave her a machine I had with Linux on it. It has worked just fine even though she had very little experience using a computer.
Re:And this is why Linux will never win the deskto (Score:5, Funny)
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.
Re:And this is why Linux will never win the deskto (Score:5, Interesting)
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.
Re:And this is why Linux will never win the deskto (Score:4, Insightful)
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.
Re:And this is why Linux will never win the deskto (Score:5, Interesting)
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.
Re: (Score:2)
Choose your OS, average user:
1) Windows
Which Windows, out of the dozens of confusing versions and three or four different UIs?
Re:And this is why Linux will never win the deskto (Score:5, Funny)
There's Window 8, and Window 8.1. There's 32-bit or 64-bit. There's Windows 7. There's about half a dozen different versions of Windows 7, and I've no idea how many of Window 8.
There's the XP interface. There's the Windows 7 interface. There's the Window 8 desktop interface. There's the Window 8.1 desktop interface. There's the Metro interface.
How can anyone expect someone to pick Windows for their desktop when there's so much fragmentation?
Re: (Score:2)
Wait, there's only one Windows? I could've sworn there were at least a half dozen active versions out there with features that aren't all inter-compatible ... just like Linux. They don't even look alike, and it causes fragmentation.
Why is Windows on the desktop? Applications and vendor support (bribed or otherwise) which boils down to "because it has been around longer."
The difference with Linux is you get a choice, and you get to argue, and it makes a difference. There are far more on-line posts about
Re: (Score:3)
Sure you can. You just can't do it with a sourceless binary.
Re:And this is why Linux will never win the deskto (Score:4, Interesting)
I'm still running the same timeseal binary for internet chess that I was running in the 90s. I'll bet the old *bsd builds still work, too.
It is over 15 years old.
I still sometimes run programs I wrote in 2001. I don't make any changes or upgrade anything, it all just still works.
Re: (Score:2)
Many of the distros are the exact same as the parent, but are specialized for a specific task or piece of hardware, which gives linux the legendary flexability.(like raspian), and lets it work on anything.
One of the big incompatibility between these two worlds
Re:And this is why Linux will never win the deskto (Score:5, Funny)
The average user also has about one tit, one ball and half a penis. Just wanted to mention that.
Re:And this is why Linux will never win the deskto (Score:5, Insightful)
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.
Don't forget you still have to update Windows (Score:4, Informative)
If I install a Linux distro that came out, let's say, 5 months ago I'd expect that to take about 30 mins on a slow ADSL connection.
If I install a version of Windows that's 5 months old I'd expect it to take most of the day if not some of the next day!
Having said that I'd never install a version of Windows that's 5 months old, instead I would install a version of Win7 with the latest service pack streamlined in and it would STILL TAKE A WHOLE FU**ING DAY.
Re:And this is why Linux will never win the deskto (Score:5, Insightful)
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.
Re: (Score:3)
" problem that made your desktop look like Windows 95"
I don't get the reference, are you saying windows 95 is a bad thing in your pro-windows rant?
Fortunately there are slightly more then 654685787684 different websites telling you how to remove windows infections.
Re: (Score:2)
Re: (Score:2)
Always threaten with a spoon.
Re: (Score:2, Informative)
> Systemd is deployed in real systems and these aren't crashing or suffering chronic problems.
Some people seem to be reporting this very thing. The cult of mindless progress just seems intent on ignoring everyone that isn't drinking the Kool-Aid.
Re: (Score:3, Informative)
Re: (Score:3)
Bash, ZSH, Busybox, Apache, sendmail, exim, postfix...
All of which can be replaced by other applications (in fact, many are replacements for each other, which is exactly the original point).
That's the issue with systemd. Once you make it a dependency then you have it and all it's attendent subsystems and you can't replace any of the parts with something else.