Choose Your Side On the Linux Divide 826
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."
What battle? (2010 wants its article back?) (Score:4, Informative)
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?)
systemd adds to and supports the old model (Score:5, Informative)
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.
Re:Choosing Sides (Score:5, Informative)
Re:Still on (Score:5, Informative)
Systemd still supports the system V boot process features, you can still run init scripts from systemd if you wish.
Re:My opinion on the matter. (Score:4, Informative)
Basically we *need* something like systemd, which is why it's gaining ground. It's providing a lot of sorely-needed features, efficiency, and cleanup in a ton of areas. The are a handful primary meta-downsides that cause all the teeth-gnashing can be summarized as follows (all of which are avoidable in theory...):
1) The developers are often uncooperative assholes - True of many projects in the OSS world, sadly. Generally not a deal-breaker when everything else is fine, but it really exacerbates problems with the other points below.
2) Emacs Syndrome - systemd has begun to be the kitchen sink of Linux. They're adopting a philosophy that anything anything which touches/interacts with systemd and doesn't work for them (doesn't fit their new radical model) should be re-written into compliance, and since too many of the authors of these non-compliant projects are also systemd grumblers, the project has taken to the habit of rewriting these components themselves and making them a part of systemd. Thus systemd's scope has grown tremendously, and it's bundling a ton of risk into a single meta-package. Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).
3) Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons. For a traditional *nix daemon, this means the collection of POSIX-y system calls that deal with things like privilege management, daemonization, logging, socket binding, etc. The systemd model tries to replace all of this with declarative service configuration files which set all of this up from outside the daemon before it's launched, allowing it to focus on merely processing socket traffic. Think of this as a much more advanced variant of the inetd model. The problems with this approach are three-fold (and you'll see examples of these problems in other areas of systemd as well):
3a) They haven't mirrored every possible legitimate use of the old POSIX-y syscall API in the new declarative configuration. In little ways this means things like not supporting every socket option in the normal socket APIs. In big ways, this means more complex behavior patterns. For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc). Systemd's declarative model is far more limited in scope and can't possibly map to all of these creatively-beneficial uses of POSIX behaviors. Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style, and the long course is to get rid of sysv init compatibility completely. This really screws these cases.
3b) It introduces a new latency in exposing new APIs. Before if, say, a new socket option appeared that was useful to a daemon, it first appeared in the kernel, then later in glibc, at which point it's at least conditionally available in a reasonable manner to portable (among linux versions/variants) software. Now we must wait for it to hit the kernel, then glibc, then systemd, and only then can the application take advantage of the feature. Who's coordinating this the way that kernel/glibc APIs are coordinated? This stuff isn't even documented.
3c) In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case. Thus these APIs aren't well-thought-out for the server-like case, and the concerns of authors of that sort of software are not being taken very seriously (see point 1). However, the distros which have all (how the hell?) been convinced it's a good idea to move their whole distro to systemd in the long run will obviously be using the same init system in both cases. I know we all want some year to be the Yea
Re:Not in this instance (Score:4, Informative)
> GNU/Linux is still pretty irrelevant outside of cheap server
Linux is the flagship platform for a leading enterprise software vendor that sells their product for 60K per CPU.
One single server installation of their product can cost more then your domicile. This is true regardless of where you live or what kind of structure you live in.
Linux isn't just "relegated to cheap servers".
Re:My opinion on the matter. (Score:5, Informative)
Re:My opinion on the matter. (Score:5, Informative)
Systemd's strenghts are:
- Fast startup & shutdown (compared to sysVinit);
- Better on-demand loading and stopping services and processes and changing network settings.
Compared with all the problem it brings:
- That is useful on a tablet or phone - where you never have to modify the factory configuration;
- A bit useful on a laptop - if you only use GUI tools that can do a limited ammount of config editing for you;
- Not very usefullon a desktop - unless you are prepared to get your hands dirty with systemD's smelly and poorly-documented guts;
- Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.
For a server situation, the BSDrc style startup is even better than sysVinit.
Re:If systemd is deemed going against unix philoso (Score:4, Informative)
Yes, the bloated pigware Sun/Oracle has put into Solaris is against the Unix philosphy and bad. I speak as Sun Certified Systems Engineer with 24 years experience in Solaris/SunOS. Happy?
MacOSX is a desktop system, who cares how complex Apple makes it to be easy for non-admin to use? not relevant to this discussion of a bloated complex thing for servers.
There, your questions have been answered.
Re:My opinion on the matter. (Score:5, Informative)
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.
Re:My opinion on the matter. (Score:3, Informative)
My question then is why are we seeing a near universal switch?
Because Lennart works for Red Hat which is pretty much the only profitable Linux distro out there and has a massive amount of control in the Linux arena. If the change happens in Red Hat there is a 90% chance it'll happen everywhere else, which is basically what we're seeing with only a few holdouts on systemd like Gentoo.
Re:Display server (Score:2, Informative)
You _are_ pushing megabytes of pixels either way. All modern GUI toolkits disregard most of X server APIs and simply send bitmaps.
Re:Better question (Score:5, Informative)
Nobody is forcing the adoption? Really? You do know that Gnome3 has a dependency on logind and logind has a dependency on ... yes, kids ... systemd.
Re:My opinion on the matter. (Score:1, Informative)
Except for the fact that you're talking about nuance. Someone familiar with Unix would very easily be able to figure how how the environments different. Much like how people from the Debian/Ubuntu world react when going with RedHat/CentOS derivatives. The two worlds were always different but a great many of the skills from one can be used on the other which I was I was able to get Oracle installed on a Debian machine using CentOS installation instructions.
Parent did not say the interfaces were identical. Given how similar they are its fairly hard to argue that Debian and CentOS don't have the same command line interface in common, they both run bash and your scripts are quite likely to function in either environment with minor variables needed for adaptation. Depending on your app this is easy, some are hard but that is a symptom of the growing divide. The divide in and of itself is not a bad thing, you had people that thought one way was better than another, I really liked Gentoo's use of portage for instance, of course not all Linux distros jumped to portage en masse either.
It is inevitable that Linux will become more complicated, the problem is that you have the old guard following the small tools philosophy which proved highly successful for the last 40 years versus the new guard trying to make a complex monolithic environment which has proven time and time again to be a nightmare: Windows support anyone?
Re:snydeq = InfoWorld (Score:5, Informative)
I felt it was enough a problem to submit a bug report to the CentOS people: https://bugs.centos.org/view.p... [centos.org] -- the problem I see is that the documentation for systemd and the observed results are different. Further, there are no instructions on how to take a System V init and convert it cleanly to systemd. I don't have a Red Hat Enterprise support license, so I couldn't report the issue to Red Hat. One of the problem of using an alternate distribution.
To this developer's eye, the systemd documentation is not ready for prime time. Note that this bug was reported against 6.5, not 7. I'll be looking at 7 when I get a round tuit.
Re:My opinion on the matter. (Score:5, Informative)
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 [slashdot.org] and oursland [slashdot.org] 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.
Re:My opinion on the matter. (Score:5, Informative)
RHEL 6.5 uses Upstart. It does not have Systemd.
Re:Display server (Score:2, Informative)
You must have missed it...
Scrolling a pixmap (on the X Server) doesn't require any "megabytes" of pixels... a total of about 100 bytes is needed.
Updating the newly exposed portion COULD take more - but that depends on what the update is. If the data has already been transferred, nope - no action at all.
I wrote a satellite imaging system display using X... Transferring the initial data (a 4k x 12k x 24 bit image 144 MB) over the net did take a while... But scrolling around the image was nearly instant (as long as the target system had more than 8MB of available memory).
Re:My opinion on the matter. (Score:2, Informative)
Also, you should talk to your distribution's BIND maintainer about his shitty init scripts.
And that's the point. Any random Joe Shmuck can make a minor mistake in a 'blinkenlightsd' init script that can cause the whole system to collapse during the restart. Systemd deals with it, cleanly.
Re: My opinion on the matter. (Score:5, Informative)
If that is the case then someone at Redhat needs to be hit with a Clue-by-four (tm). A system should have absolutely ZERO binaries/files that are required to boot into a working (if only minimal) system in /usr. Stupid, man. It's universally stupid.
Re:My opinion on the matter. (Score:5, Informative)
An init system should do one thing and do it well, manage the startup of services when called. A proper *nix designed system for monitoring and restart would CALL init, but it shouldn't BE init, otherwise it violates the principle of modularity.
Consider for example looking for all the active settings in a standard Linux config file:
grep -v ^# ldap.conf | tr -s '\n'
By using two standard tools you can do something pretty fancy, basically stripping out all the comments. Could grep be enhanced to include the newline trimming feature? Of course it could, but that's not grep's job, its purpose is to match things not trim things. By keeping the scope narrow you reduce the error space and provide a more flexible toolset.
If you design the monitoring system into init then it can't be used generically to monitor other things and you lose half the value of the tool you've created.
Re:My opinion on the matter. (Score:5, Informative)
The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:
Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.
There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.
There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).
The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.
XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.
None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).
If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.
It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.