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: 0) by Anonymous Coward on Friday September 19 2014, @05:57AM

    by Anonymous Coward on Friday September 19 2014, @05:57AM (#95368)

    Unless you're running a mainframe with redundant processors...

  • (Score: 2) by EvilJim on Friday September 19 2014, @06:00AM

    by EvilJim (2501) on Friday September 19 2014, @06:00AM (#95369) Journal

    motherboard? I cant say I've seen any servers with redundant motherboards.

  • (Score: 2) by VLM on Friday September 19 2014, @02:18PM

    by VLM (445) Subscriber Badge on Friday September 19 2014, @02:18PM (#95493)

    "motherboard? I cant say I've seen any servers with redundant motherboards."

    Talk to IBM about "real computing" aka mainframes. Thats old stuff. Lost a backplane on a clustered machine in 1994 in the middle of a trading day. No big deal. Cluster didn't even hiccup although the IBM CE was tearing his hair out in panic. (OMFG 5% of all stock trades in the entire conus in all markets went thru this system and we were redundant normally, but we lose one more, or the CE makes one false step, and he'd literally be the cause of shutting down multiple markets, likely ...) This was an outsourced financial services provider for brokerages back when outsourcing meant onshore just not your own W2 employees, not by default sending to India.

    You can get something conceptually similar in some scenarios with BGP anycast but thats cheating (this ip address exists in every routing table... it just seems to exist on numerous hardware). To do this right your BGP speaker has to be the service providing machine such that if it crashes it takes the BGP advertisement with it. That was related to my second "real job" in the 90s-00s. The first time a router jockey runs into the idea that "a" IP address doesn't really mean "a" machine it confuses the F out of them, guaranteed. This works better with things that provide a reasonably stateless service like NTP, not so good with bank balance databases perhaps.

  • (Score: 2) by VLM on Friday September 19 2014, @02:24PM

    by VLM (445) Subscriber Badge on Friday September 19 2014, @02:24PM (#95498)

    "and he'd literally be the cause of shutting down multiple markets, likely "

    Oh and forgot to mention that old piece of computing history mythology the "vaxen don't belong here" story was not so ancient at this time, maybe only 10 years old, and everyone knew that story. You know you're really in the shit when you're living out something like mythology in real life. Thats the time to panic, or at least a good excuse. Other than our scenario was more like Sun gear with "sunos" (ancestor of Solaris aka slow-aris) but VAXen. But whatever.

    You also know its a good time to panic when you get to work and the CEO of the corporation has stolen your chair to sit in the machine room looking very unhappy. My first reaction was OMFG I hope my networking gear is up and it isn't my fault. Which it wasn't. Somehow nobody got fired that day because it was no ones fault and IBM never really admitted what killed that machine backplane/chassis. Cosmic rays or who knows.

  • (Score: 0) by Anonymous Coward on Friday September 19 2014, @07:03AM

    by Anonymous Coward on Friday September 19 2014, @07:03AM (#95381)

    HP superdome series.
    Even the backplane has redundancy in the latest models.

  • (Score: 0) by Anonymous Coward on Friday September 19 2014, @06:25AM

    by Anonymous Coward on Friday September 19 2014, @06:25AM (#95374)
    It's called clustering :)
  • (Score: 2) by SlimmPickens on Friday September 19 2014, @06:22AM

    by SlimmPickens (1056) on Friday September 19 2014, @06:22AM (#95373)

    remember when Dell's website crashed because the HP non-stops they were using stopped?

  • (Score: 0) by Anonymous Coward on Friday September 19 2014, @06:11AM

    by Anonymous Coward on Friday September 19 2014, @06:11AM (#95372)

    They just only provide a benefit if proper isolation is enacted between mainboards and baseboard, and if both hardware and software are functioning correctly under all probable failure circumstances (hint: some don't, and some aren't found until they're in the field, where it may or may not be possible to repair, retrofit, or rework them.)