Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

Choose Your Side On the Linux Divide

Comments Filter:
  • by xxxJonBoyxxx ( 565205 ) on Monday August 25, 2014 @03:11PM (#47750327)

    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?)

  • by Eravnrekaree ( 467752 ) on Monday August 25, 2014 @03:12PM (#47750341)

    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)

    by present_arms ( 848116 ) on Monday August 25, 2014 @03:18PM (#47750425) Homepage
    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.
  • Re:Still on (Score:5, Informative)

    by Eravnrekaree ( 467752 ) on Monday August 25, 2014 @03:24PM (#47750499)

    Systemd still supports the system V boot process features, you can still run init scripts from systemd if you wish.

  • by Anonymous Coward on Monday August 25, 2014 @03:26PM (#47750531)

    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

  • by jedidiah ( 1196 ) on Monday August 25, 2014 @03:31PM (#47750587) Homepage

    > 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".

  • by thaylin ( 555395 ) on Monday August 25, 2014 @03:33PM (#47750611)
    In at least some cases the change as made because they have a dependency and that dependency will now only support systemd. Fedora/RHEL have a personal bias as they were the ones who developed systemd
  • by psergiu ( 67614 ) on Monday August 25, 2014 @03:34PM (#47750617)

    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.

  • by rubycodez ( 864176 ) on Monday August 25, 2014 @03:37PM (#47750661)

    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.

  • by 0123456 ( 636235 ) on Monday August 25, 2014 @03:39PM (#47750683)

    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.

  • by geek ( 5680 ) on Monday August 25, 2014 @03:47PM (#47750773)

    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)

    by Anonymous Coward on Monday August 25, 2014 @04:02PM (#47750919)

    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)

    by fnj ( 64210 ) on Monday August 25, 2014 @04:11PM (#47750999)

    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.

  • by Anonymous Coward on Monday August 25, 2014 @04:18PM (#47751055)

    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?

  • by satch89450 ( 186046 ) on Monday August 25, 2014 @04:45PM (#47751349) Homepage

    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.

  • by RR ( 64484 ) on Monday August 25, 2014 @04:53PM (#47751457)

    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.

  • by kthreadd ( 1558445 ) on Monday August 25, 2014 @04:54PM (#47751463)

    RHEL 6.5 uses Upstart. It does not have Systemd.

  • Re:Display server (Score:2, Informative)

    by Anonymous Coward on Monday August 25, 2014 @05:15PM (#47751663)

    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).

  • by Cyberax ( 705495 ) on Monday August 25, 2014 @06:44PM (#47752271)
    I don't fucking care how it's been done before. This is a stupid limitation that serves NO useful purpose whatsoever - lots of legitimate services use ports greater than 1024. And ejabberd quite sanely does not do any stupid dances with dropping privileges, not in the least because it can dynamically add or remove services. Can you guess the first init system to deal with this issue?

    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.

  • by Selivanow ( 82869 ) <selivanow@gmail.com> on Monday August 25, 2014 @06:54PM (#47752339)

    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.

  • by blue9steel ( 2758287 ) on Monday August 25, 2014 @07:24PM (#47752545)
    A properly designed browser using *nix philosophy wouldn't do those things directly, instead it would use plugins to add that functionality.

    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.
  • by TheRaven64 ( 641858 ) on Tuesday August 26, 2014 @04:43AM (#47754779) Journal

    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.

"I'm not afraid of dying, I just don't want to be there when it happens." -- Woody Allen