Slashdot Mirror
Choose Your Side On the Linux Divide
snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."
the general concept behind systemd makes sense, its mainly some additional features on top of the current model, such as the ability to have processes started on certain system events. The fact is, if you want your bootup process to be controlled by bash scripts, all you need to do is configure systemd to start your bash script and youve got a more traditional init system. So, systemd does not take away any functionality, only adds it. Systemd supports the system v init process features so you still have all the old model functionality available to you. So, it does not make much sense that people complain about this when they can easily configure things however they want, including having a BSD style init, by having systemd hand off control to your own scripts, including to work the way things always have. People act like systemd has taken away something when it has not, i think many people just hears some soundbite about systemd introducing a new model and assume that they can no longer use things the way they do currently, which is not the case. it seems like people who don't like systemd don't want people to have the additional functionality that it provides, because it does not take away anything. Its open source software, and its something that you can control and configure to your hearts content. Its much ado about nothing. systemd, while being configurable, also will make things easier to use for many users. I think the ado about systemd is more about Linux people who think that Linux should be hard to use except for a small elite and do not want the OS to be useful to less technically adept users. This is even though making it more useable for less adept users does not in any way harm or take away flexibility from experts, who can still configure everything if they want they want to.
Yes, the old SysV init of hordes of scripts running in series was broken - especially for large-scale systems that have to do a lot of things during startup.
But systemd is just plain FUCKED UP. Read the dependencies.
Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.
What system V and systemd do is initialise the OS, let me kinda explain, you turn on your pc, it loads the bootloader which in turn loads the init system, the init's systems job is to hand off certain jobs to certain programs, getty so you have cli, X so you have a nice GUI, and starts or stops services. This is a very simplistic explanation. Now it's my belief that Init should be made with separate components, for instance system V will read the scripts from /etc/rc.d and depending on those scripts depends what's loaded at boot time. Now the problem with systemd is (from what I believe) is that it's a one-stop for all, encompassing all the scripts needed, and gaining bloat (mostly not needed) at the same time. It's starting to be the "registry" of the linux world. and NO-ONE with a hint of intelligence wanted the Windows registry, let alone a clone of one.
http://chimpbox.us
Much like pulseaudio, it will probably become quite good when Lennart stops working on it and hands it over to someone else to maintain.
Who really needs systemd?
I've been working with Linux since 1995, where I started with Slackware, moved over to Redhat until it went all "enterprise-y", at which time I moved to Fedora.. Stayed there till a friend turned me on to Ubuntu in 2007, where I stayed pretty much till the recent Unity shitfest over there, where I then moved to Debian.. I cut my teeth on /etc/init.d and a stock standard init() process.. I could do pretty anything I needed to do in troubleshooting/starting/stopping daemons from memory.. Can't remember the last time I consulted a man page regarding anything having to with init() or logging.. Now with this $#@$%%$#@ systemd, I have manpages up ALL the time just to do simple shit that I could do with init() and standard logging in my sleep before systemd. It also seems like this crap is spreading like sewage over pretty much of the standard distros.. Debian/Fedora/CentOS.. The only one I'm somewhat familiar with (haven't used it recently) is Slackware and from what I've heard Patrick and the devs over there feel the same way I do about systemd.... Maybe its time to revisit an old friend.....
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
What's broken is that some people would rather change Linux into something else fundamentally, rather than wait for the rest of the world to catch up. The result is going to be the same kind of pain that's happening in the browser arena. There, you have reasonable standards bodies who move "too slowly" for a few, who wish to replace the web with a new version that's obviously even more flawed, all in the name of progress. Sometimes the old guard aren't just holding back progress, but don't tell that to inexperienced youths and bitter old men who want to make a name for themselves.
Was that so hard?
Hey, guess what? I did that, and it didn't work.
Hint: you missed at least one more place where you have to change the port number.
This is the problem with systemd, Gnome 3 and a lot of other recent stuff.
Unix was originally designed rather like a tinkertoy set. The individual parts might not be very smart, but you could glue them together however you wanted. A "RISC" architecture, if you will.
Recent "improvements" to Linux have attempted to be all-in-one solutions. By making them one-size-fits-all, you lose useful, important, sometimes critical functionality. Because no one system can be all things to all people. It's a "CISC" solution, and what you are left with is what the designed wanted you to have, not what you wanted to have.
So that's the Great Divide. Turn into another Apple, where you can have any solution you want as long as it's the one the providers want to give you or retain the original spirt of the system, and allow it to be powerful at the expense of the presumed masses who'd gladly chuck Windows if only Linux was more friendly to the casual user.
I think, for a lot of people, they don't have the challanges that systemd solves.
Conversely, systemd daily inserts problems that never existed before.
Actually they did. I dealt with binary log formats in Windows, OS/2, and IBM's mainframes. IBM has a really bad habit of creating a different binary format logfile for every app, complete with special binary utilities to be able to read them in any way you like - as long as it's a way IBM supports.
The old text logfiles might not be as tidy, but I constantly string together strange concatenations of the text utilities to garner critical information from them. Something that's nowhere near as easy when the logs are in binary form.
What systemd reminds me of is the Windows Registry. A fine concept that turned out to be a nightmare in practice.
That, I must say, is one of the arguments that turns me off to it. I really could not possibly care less how long it takes any system other than my laptop to boot. My laptop does run a distro with systemd, and I do like that it boots fast....I would not hesistate for a second to give that speed up if I needed to for something I do once a day usually and twice a day at most.
The majority of systems I deal with are servers. They mostly have plenty of CPU and memory available and typically run very few services..... they boot plenty fast without systemd.
Really the most annoying thing about it for me isn't going to be learning it, its going to be training other people to deal with it and supporting them when they find the software they are installing isn't setup for it properly and they need to troubleshoot and fix it.
If there was some real benefit, I am all for it but....boot speed? Talk about not worth it if that is the "benefit"
"I opened my eyes, and everything went dark again"
This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.
http://en.wikipedia.org/wiki/S...
It amuses me greatly that both replies to this post responded as if Bill was talking about "X" the windowing system rather than a placeholder variable.
Should've used $X. ;)
Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.
Except that's actually false. Unixen really don't share common interfaces. Mac OS uses launchd, FreeBSD uses init.d, many Linuxes use systemd.
On Linux you'll find devices named /dev/hda(n) and sda(n), while on OS X you'll find /dev/disk(n)s(m), and on solaris you'll find /dev/dsk/c(n)t(m)d(l)s(o).
All unixes differ. Trying to claim that the way it happens to have been done in Linux for a while is the "one true unix way" is frankly bullshit.
You got a bunch of "upstarts" who don't know, or don't care, about Linux's roots and want to turn it into something it just never was meant to be
When I was a junior network engineer, I sometimes had to work on (what we now consider ancient) technology such as ATM, Frame Relay and ISDN. I even had my share of IPX/SPX. Back in those days, the experienced network engineers with 20+ years of experience despised Ethernet while complaining about those junior folks who knew nothing about the established technologies. As it turned out, all of them are out of a job now.
Bottom line is, when it comes to technology progress, roots are pretty much irrelevant. I don't care if something has been done like this for 1000 years. If we can find a better way to do it, let's do it.
The question should be whether or not systemd is progress, or an unnecessary burden. History is irrelevant in this case.
I'm not a complete idiot... Some parts are missing.
Not just the Registry, but it's also rapidly becoming the equivalent of "svchost.exe". I probably wouldn't have a problem with SystemD if it were designed to be *much* more modular, but the design goals for the package seem to be to embrace, extend and extinguish a significant number of other processes essential to the Linux boot process and to bring most of it straight into PID1. That's just asking for major problems if/when anything goes wrong, and makes troubleshooting a nightmare because you have one huge black box instead of a bunch of daemons. If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.
If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?
Still, there's always BSD.
UNIX? They're not even circumcised! Savages!
One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become.
The init system is a very poor example of Unix common interfaces. As beelsebob and oursland point out, different Unix systems use different init systems. The Linux alternatives, upstart and systemd, were actually inspired by the clear advantages displayed by MacOS X's launchd.
And even in Linux, with SysVinit, there are different interfaces. When you want a script to run at boot, do you use update-rc.d, like Debian? Do you use rc-update like Gentoo's OpenRC? Or chkconfig like Red Hat? Or insserv like SuSE? And where do you find important details like the hostname and network configuration?
I don't find systemd to be a pleasing design, and I especially don't share their love of long command names with lots of consonants, but I think their work is very important.
Have a nice time.
RHEL 6.5 uses Upstart. It does not have Systemd.
There is no "fundamental change" to Linux with systemd
I'd call moving DBUS into the kernel, assimilating udev, and making the init system a large complex system that does lots of things rather than the old school ideology of doing one thing and doing it well, some pretty big, somewhat fundamental changes to GNU/Linux.