Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Friday September 19 2014, @05:47AM   Printer-friendly
from the voice-from-on-high dept.

Systemd has turned into the Godzilla of Linux controversies. "Everywhere you look it's stomping through blogs, rampaging through online discussion threads, and causing white-hot flames that resemble Godzilla's own breath of death," writes Jim Lynch. Now Sam Varghese reports at iTWire that although Linus Torvalds is well-known for his strong opinions, when it comes to systemd, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," says Torvalds. "I don't personally mind systemd, and in fact my main desktop and laptop both run it."

Oh, there's been bitter fights before. Just think about the emacs vs vi wars. Or, closer to systemd, the whole "SysV init" vs "BSD init" differences certainly ended up being things that people had "heated discussions" about. Or think about the desktop comparisons.

I'm not really sure how different the systemd brawls are from those. It's technical, but admittedly the systemd developers have also been really good at alienating people on a purely personal level too. Not that that is anything particularly new under the sun _either_: the (very) bitter wars between the GPL and the BSD license camps during late-80s and early-90s were almost certainly more about the persons involved and how they pissed off people than necessarily deeply about other differences (which existed, obviously, but still).

Torvalds was asked if systemd didn't create a single point of failure which makes a system unbootable if it fails. "I think people are digging for excuses. I mean, if that is a reason to not use a piece of software, then you shouldn't use the kernel either."

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by jbernardo on Friday September 19 2014, @09:45AM

    by jbernardo (300) on Friday September 19 2014, @09:45AM (#95410)

    For me, the systemd "war" appears to be divided between two camps; on one side, young reckless developers who think that experience isn't all and that if users don't like their radical new ideas they should just fork the code and stop complaining, on the other, experienced power users and system administrators who like things simple and modular, have seen complex crazy ideas blow up spectacularly several times, but can't develop - be it by a lack of time, or lack of skill in that area.
    Developers just dismissing warnings and complaints with a "if you don't like fork it" only serves to get the other camp mad and dismiss developers as "arrogant idiots". Neither of the groups understands the other...

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  

    Total Score:   3  
  • (Score: 0) by Anonymous Coward on Friday September 19 2014, @01:25PM

    by Anonymous Coward on Friday September 19 2014, @01:25PM (#95476)

    That is a pretty good assessment.

    Much like the old xfree86 stuff. We used it because it worked and was about all there was. Once the real X11 guys paid any attention to linux and didnt do crap things everyone ran for the hills. The same will happen with systemd.

    The *idea* of systemd is a decent one. Get the system started up in a consistent non cryptic way. Put in watchdogs for known services. Give external applications one API to get the status. The init.d way served us well for a long time. But it has shown it is brittle and easy to break. But by necessity it logged itself very well and very simply. People are understandably upset that it is now 'binary' for the logging. So instead of using less/cat/more/tail/grep to find something out you need to use some other specialized tool that needs all the features of those apps.

    The systemd guys have a brilliant idea. They need to stop dragging things into it though. Let the particular well understood subsystems do their job and hook into the 'new' way. Reinventing the wheel is pretty much how linux got started. But they have decided everyone should use their new wheel. Which is not how linux started... It just serves to piss people off. Eventually someone *WILL* fork it and leave RH as irrelevant.

    For me as a normal 'end user'. It does not affect me much. Other than it is a pain to look at the logs now. As there is 'yet another way' to look things up. As I still have to use all my old systems and old busybox distro installs.

    • (Score: 0) by Anonymous Coward on Friday September 19 2014, @02:05PM

      by Anonymous Coward on Friday September 19 2014, @02:05PM (#95489)

      Let the particular well understood subsystems do their job and hook into the 'new' way.

      Isn't that basically what the BSDs are doing with OpenRC? Replace the quirky part (rc.d), and hook the replacement up with the working parts of the system, instead of replacing everything.

    • (Score: 2, Informative) by Arik on Friday September 19 2014, @04:26PM

      by Arik (4543) on Friday September 19 2014, @04:26PM (#95546) Journal
      "The *idea* of systemd is a decent one. Get the system started up in a consistent non cryptic way. Put in watchdogs for known services. Give external applications one API to get the status."

      You have this almost exactly backwards.

      Traditional init systems are deterministic, they do get the system started in a consistent non cryptic way. That's why we like them.

      Systemd emphatically does NOT do this. What it DOES is add the extra, non-init related functionality you mention  (which are fine functions for a system to have, but should not be sitting at PID1 or complicating the boot process.) In the process, it robs you of 'consistent non cryptic' deterministic startup and gives you a much more complicated, much more error prone, and non-deterministic boot process. For example, systemd will happily start your wireless daemon in the background, then start other services that depend on it immediately! That's gives a faster 'boot' only if you do not understand what the word means. It's like windows, it rushes to pretend it's ready as quickly as possible,  but there is no guarantee that when it pronounces the system 'up' it is really 'up.'

      The whole project only makes sense for people that are running thousands of VMs on a server farm, but never installing it on bare hardware at all.
      --
      If laughter is the best medicine, who are the best doctors?