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."
As long as xterm & the web browser are running on Wayland, nobody will complain.
X.org has became such a mess itself (compared to the old XFree86) so anything smaller, simpler, faster and 100% compatible is welcome.
OTOH systemD is not smaller, simpler and 100% compatible with the systemV init and BSD rc - so it requires everybody relearning a lot of concepts for scratch just to gain 4-5 seconds at boot time - unsually on a server that you reboot only a couple of times a year.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
> Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition.
Sure it should. At the very least, such sweeping changes should be met with some skepticism based purely on mundane ideas about change control. Why are changes with such a massive impact being considered? What is being done to mitigate risks? How is this going to impact how Linux fits in with other Unixen?
What's broken exactly?
A Pirate and a Puritan look the same on a balance sheet.
Who cares if you have to relearn stuff? Its the fact that systemd is less than stable... In many cases, you end up with corrupt binary log file after a crash, have services that don't (run a process that does heavy syslogging to the tune of 25-30K messages per second. Yes, its bad app design but come on - this thing worked for years and now its suddenly broken???) that used to work just fine before and then top it off with really braindead configuration options (go ahead and change the pgsql listen port - and see how long it takes you...)
I'm all for systemd - once its been stable for a while, but till then it would be nice to have at least a choice...
Peter.
> Who cares if you have to relearn stuff?
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.
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.
The anti-dinosaur sentiment should not be an excuse to blindly and gratuitously change things just because of "new shiny shiny".
All of your substantive complaints seem to be a direct result of ignoring the principle "don't fix what isn't broken".
A Pirate and a Puritan look the same on a balance sheet.
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..)
Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.
A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.
A complex startup system that logs to a database rather than a text log, is just poor engineering.
And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.
Just the requirement for dbus proves systemd far too complex and bloated a thing, it is against the Unix way of doing things. Failures and problems in a needlessly complicated black box may well be too difficult to even troubleshoot
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.
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...
System admins both old and new that are worth anything don't want things changing just for the sake of change.
It boils down to the old adage: "If it ain't broke, don't fix it."
Which further boils down to something admins care very much about: stability and reliability. Changing something that's been in production for 5, 10, or more years just because someone decided to roll out the new "shiny, shiny" is not an effective use of the admin's time.
Last but not least, admins are often responsible for systems from multiple vendors. Having a unique configuration model for each system goes against the whole point of things like POSIX APIs and standardized startup processing.
Sure on a desktop or developer system, the difference is probably irrelevant. But when your main job is configuring and maintaining services on servers instead of just using a box, the arguments and priorities change for damned good reasons.
I do not fail; I succeed at finding out what does not work.
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 can see this in Development vs Operations, Bay Area Startup Hipster Programmers vs System Administrators Who Have To Carry The Pager, Big Data vs Simpler Analysis, and a lot of other places in the industry right now....
There's an influx of talent that doesn't seem to understand the fundamentals of system architecture, or assumes they have all the answers and can/should hard-code them into the design, preventing "the Unix Philosophy" from being applied by the operator who's trying to deal with the crisis at 3 in the morning. "whatcouldpossiblygowrong", ergo I shall design this in C, and if you need more flexibility than I'm offering then You're Doing It Wrong.
What they don't understand is that they don't have all the answers... Nobody does. The only solution is to leave as much flexibility available as far down the stack as possible to allow the folks who have to deal with this (eg, system administrators) the ability to do their jobs. Replacing shell scripts with C code and the unix toolkit with monolithic binary blobs does not help the situation.
systemd does a few things right (cgroup management, for one), and promotes the state of the art in a few areas that probably only could be dealt with at the PID1 level... Also, as the original article admits, there's nothing inherently wrong with working to speed up boot times across the board. All of these things are irrelevant and outweighed by enforcing declarative styles on system configuration, and the sheer philosophical hazard of taking all these disparate functions and putting them into a program.
It makes absolute sense for Android, and perhaps an embedded system that just needs systemd and busybox. For a regular Linux userland, it takes us in the wrong direction.
Hire a Linux system administrator, systems engineer,
I've yet to read something I'd consider a valid argument against it.
It violates basic *nix design philosophy, which basically has two pieces: 1) Everything is a text file 2) Lots of small tools that can be chained together to do big things
Boot time is essentially irrelevant, I don't see why everyone gets so excited about it.
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)
Ubuntu is the largest distro I know of and it doesn't support it by default.
But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.
When the neck beards speak, it's often prudent to at least listen.
I'm reminded of a myth, of when the Ancients were sitting down to design Unix, someone said "Why would we ever need a special file, that never contains any data, and always throws away everything written to it?" The Ancient replied, "Trust me, you'll need it." And thus, /dev/null was born.
6th Street Radio @ddombrowsky
Nothing is broken with Linux. But by now I believe something very fundamental is broken in a highly dangerous fashion with the systemd developers. They hardly seem to qualify as UNIX folks at all with their mind-set....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
From what I read, I think the point was that if such changes *are* met with such fervent opposition, it is high time to step on the brakes and reevaluate the situation, and perhaps revert the changes.
Hell, most of my servers spend so much time in their boot process initializing RAID controllers, mem testing, etc. that the performance gain with systemd vs init is really not going to make that much of a difference. Add to that the fact that most of us have servers whose uptimes are measured in years, boot performance is pretty much the last thing I give a damn about.
"Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
You're posting a lot on the drawbacks of SystemD, but you're not including any of the drawbacks for SystemV.
Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.
A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.
I mostly hate X11 because I have to program for it... It's like eating a cactus and washing it down with a whole bottle of Carolina Reaper Chili Sauce.
Only to idiots, are orders laws.
-- Henning von Tresckow
Re 1: Developers uncooperative?
Looking at the mailing list this doesn't appear to be the case. +500 developers have contributed to systemd, that points to excellent leadership where even small contributions are welcomed.
Re 2: Emacs syndrome.
It is popular but totally wrong meme that systemd just pile on features. Its scope have been quite narrow for years. Yes, it have gained new features, but almost all new systemd features are related to the original scope of stateless booting and light weight containers.
So people who hasn't bothered following systemd gets totally surprised when a new version of systemd has new features, but that is just because they don't really know systemd.
Re 5: Total disregard for everything outside of Linux,
All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)
So daemon authors don't have to change a single line of code if they don't want to. The distribution managers can just add a service file instead of the sysvinit script. (probably remove some bugs that way too)
No other certified UNIX uses sysvinit scripts, they all have init systems more less like systemd. Does that mean they have a total disregard for anything e.g. not Solaris? (SMF).
I find the idea that all progress on Linux should be stopped if there is a danger that it progressed faster than other Unix'es (read BSD) a rather silly idea. Especially because those other Unix'es generally hate and despise Linux because it is a successful competitor.
systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.
Bottom line is, when it comes to technology progress, roots are pretty much irrelevant.
Translation: "Why should I learn from the mistakes made in the past? I'll just make them all over again. All in the name of progress."
The truth is that all men having power ought to be mistrusted. James Madison
Embedded systems are exactly the ones that don't want a bloated init system that requires dbus for communication.
Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.
The old guard is a huge fan of PID1 doing it's thing then going away: it's up to everyone else to manage the world after PID1 kicks everything off. The new world- the people who like systemd- are enthusiastic beyond belief to have a PID1 which serves as a master control point where the system can continue to be managed. Every systemd subsystem has a DBUS API we can program and talk to, we can schedule coordinate and manage processes over systemd's core DBUs endpoint- this speaks of the new dawn where we might not be able to hack our shell scripts to do whatever, but we can write higher level code to effectively manage their operation. Which is something that royally sucked egg in the old guard's world.
Sure some of this could sort of be dealt with by continuing to add more shell scripts. But the init script world is mess. Individual daemons have radically different ideas of what kind of responsibility they need to handle in their init scripts and even though for the most part the skeleton is visible across all, it's a hack job that outsiders have to wrack their brain to understand. Conversely, systemd gives us uniform control over the system: the master control program PID1 that is systemd will let us start/stop things, AND will tell us the status of things (over either shell interfaces or DBus).
I look at this more like the innovation of steering- which permitted four wheel vehicles- than I do a particular engine configuration (different muscle, same end). Sure you could get there with the old two wheel drive cart, but as it turns out you have a lot more flexibility when the platform has consistent stability that permits being added to. Where the cam goes is an argument that affirms the lie that systemd is just a really complex initscript: it's not, it's a resident system control daemon.
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.