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."
Who really needs systemd?
It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
And THAT pretty much sums up what has always held Linux back (and probably always will).
SJW's don't eliminate discrimination. They just expropriate it for themselves.
This article is just a rant, full one one-liner insults and clichés. There are probably good debates on this topic, but this is not one of them.
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.
Old-school Unix admins don't WANT anything to change, or get easier. It threatens their livelihood. This is true of anyone with any kind of skill, but int computer-land, the changes come quickly.
It wouldn't be a problem if people weren't fundamentally lazy. But most people are. And admins are some of the *laziest*, because that laziness translates into an "automate everything" mindset, which is actually a good thing if you are an admin. But the idea of having to RE-automate everything sounds like work. Lots of work.
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.
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
Do you see any disadvantages of wayland?
Uh, let's see. Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.
Oh, but the desktop is dead, etc, etc and we'll all be doing software development on phones in future.
Who really needs systemd?
It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.
A better question is why does it matter. Nobody is forcing systemd on distros. They are free to use whatever init system them want. The only reason this is an issue is because debian change to it and all of the derivatives, including the *buntus are now changing because of debian's change. However, nobody is forcing anybody downstream to change.
Distros are free to use whatever init system they want. Now, if they don't want to expend the effort and use the upstream init system, well, that is a design decision on their part. But, they aren't being forced into it.
I notice that of the top 500 fastest computers in the world, 97% run Linux. http://www.top500.org/statisti... That would include the $390 million Tianhe-2. Oak Ridge National Laboratory spent $60 million to upgrade the $104 million Jaguar to become Titan, both running Linux. So yeah, if you're definition of "cheap" includes "the most expensive and powerful in the world", I guess you're right.
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
[quote]Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.[/quote]
Let me fix that for you:
Using X-forwarding *right freaking now* you are pushing megabytes of pixels every time you scroll a window because every single modern toolkit operates that way and you have obviously got problems distinguishing between a simple tutorial on the 1985 version of xterm vs. how real applications that are forwarded over sockets in the real world actually behave.
AntiFA: An abbreviation for Anti First Amendment.
You're posting a lot on the drawbacks of SystemD, but you're not including any of the drawbacks for SystemV.
I was involved in another discussion in one distro where the idea was floated to replace all of /etc XML files. A number of people even proposed replacing /etc with a mysql database that could be stored on or off the local system. Of course the idea was shot full of holes but having said that, the Next Generation (TM) thinking is that of replacing the UNIX paradigm of chaining simple tools together with larger monolithic tools. One of the arguments against was that if any of this broke the only recourse would be to re-image the box (reminds me of Windows). As a "dinosaur" myself I'm not enamoured with the idea that Linux (and Solaris and *BSD to a lesser degree) are becoming more Windows-like, Personally, I'd rather be in control and I don't like it when software "thinks" it's smarter than I am.
OpenRC is a really good replacement for SysV init. A serious enhancement that keeps with the spirit, an upgrade rather than a rip out and replace. OpenRC doen't keep daemons alive but that would be easy to add. Ultimately then there is only one hard problem what to do about hardware that changes. OpenRC doesn't architecturally have any good way for handing that while systemd does.
Certainly if the argument were OpenRC vs. systemd instead of SysV init vs. systemd I suspect the advantages of systemd wouldn't have outweighed the huge shift. I hope distributions like Slackware which don't have systemd move to OpenRC so that it gets tested in environments other than Gentoo.
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.
1) systemd cannot be ported to other unices because it depends on a feature, cgroups, that not even the Linux kernel maintainers like. No way will cgroups ever make it onto another Unix. It's a stupid design, but Linux is stuck with it because of Linus' ABI guarantee.
2) Software not written by idiots will continue to be portable. Network software which relies on systmd, kdbus, or glib is fundamentally a piece of trash. Desktop/application software doesn't typically have a direct dependency on systemd, and regular, user-space DBUS is portable and already runs everything. And while glib is trash, it's acceptable for desktop software.
3) The problem with systemd isn't that it's a new init system. If that's all it did people wouldn't care nearly as much. What's happening is that systemd is slowly becoming a replacement for all kinds of other things, such as NSS, PAM, etc. Basically, when Red Hat can't get their way with an upstream maintainer (including Linus and the kernel!), Lennart says, "hey, we can just add that feature into systemd and then we don't have to care about compatibility or working with those maintainers".
I write portable server software. All of my stuff currently compiles and runs on Linux, FreeBSD, NetBSD, OpenBSD, Solaris, and AIX (in other words, all the extent, server-grade Unix platforms). It's much more trivial than people believe, thanks to continually improving POSIX support by all vendors. Most of the portability horror stories are from the 1990s. I don't even bother with autotools, since it's trivial to build and install dynamic libraries on all those platforms.
I'm sad to see systemd evolve the way it has because it heralds the fact that a large part of the FOSS community has decided to give up on portability. Any software that directly depends on systemd's geometrically growing feature set will always be completely and utterly unportable. It'll also be largely crappy software. One reason I focus on portability is because compiling and running software on different environments tends to bring more bugs to the surface, and do so more quickly. I've found compile-time and run-time errors on OS X or Solaris that actually uncovered bugs which would have effected behavior on Linux, but which would have been much more difficult to discover on Linux because of the different types and slightly different run-time behavior.