Become a fan of Slashdot on Facebook


Forgot your password?
Debian Open Source Linux

Does Systemd Make Linux Complex, Error-Prone, and Unstable? ( 751

"Systemd developers split the community over a tiny detail that decreases stability significantly and increases complexity for not much real value." So argues Nico Schottelius, talking about his experiences as the CEO of a Swiss company providing VM hosting, datacenters, and high-speed fiber internet. Long-time Slashdot reader walterbyrd quotes Nico's essay: While I am writing here in flowery words, the reason to use Devuan is hard calculated costs. We are a small team at ungleich and we simply don't have the time to fix problems caused by systemd on a daily basis. This is even without calculating the security risks that come with systemd. Our objective is to create a great, easy-to-use platform for VM hosting, not to walk a tightrope...

[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.

The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
This discussion has been archived. No new comments can be posted.

Does Systemd Make Linux Complex, Error-Prone, and Unstable?

Comments Filter:
  • by Frosty Piss ( 770223 ) * on Monday December 11, 2017 @12:34AM (#55713785)

    Oh my! I'm going to hang back, make some popcorn, step into some Tyvek coveralls, grab a hard-hat and safety goggles and enjoy the show!

    • by Anonymous Coward

      Does systemd make writing headlines complex, error-prone, and unstable?

      • by OrangeTide ( 124937 ) on Monday December 11, 2017 @01:10AM (#55713929) Homepage Journal

        This is Slashdot, any ill you can imagine can be traced back to systemd.

        • Well, if you're going to limit us to our imaginations that seems a bit of an unjust restriction...
        • by DontBeAMoran ( 4843879 ) on Monday December 11, 2017 @01:48AM (#55714041)

          systemd turned me into a newt!

        • by Reverend Green ( 4973045 ) on Monday December 11, 2017 @04:48AM (#55714431)

          Systemd is nothing but a thinly-veiled plot by Vladimir Putin and Beyonce to import illegal German Nazi immigrants over the border from Mexico who will then corner the market in kimchi and implement Sharia law!!!

        • by Anonymous Coward on Monday December 11, 2017 @08:18AM (#55715013)

          ... their only arguments are hyperbolic personal attacks. (Look, I can do that too!)

          Hint: Your side is just as stupid as your opposing site. There is no sane or reasonable, let alone sensible side. Because that is how Americans are. At least it is beyond their *tiny* mental box.

          Regarding systemd, I state *both* A and B:

          A) Monolithic "frameworks" have always been a stupid idea. Because they disable you from plugging them into *your* system, and force you to plug into *theirs*. Because they want to dominate you! And they are mutually exclusive as a result of that.

          B) Traditional init systems are very limited and badly limiting nowadays. Like still using DOS as the underpinnings of your actual system. A more generic event/trigger system is much more sensible.

          THE PROBLEM IS: That systemd throws away what's good about traditional init systems (like "everything is a file"; modularity; being able to do things with a simple file manager, text editor and maybe a script.).

          It could have done the event/trigger thing *without* sacrificing modularity (tools that do *one* thing, and do it right!).
          It could have acted less like a dominatrix on a power trip, swallowing everything.

          The base ideas were good. The personality of the way it was implemented, was that of a complete egocentric psychopathic asshole with a god complex.

          Give me a sane eventd, and I will ditch the old init system before you can blink.

        • This is Slashdot, any ill you can imagine can be traced back to systemd.

          This is simply not true!
          A small percentage of troubles are related to the GRUB -> GRUB2 switch.

    • by JustAnotherOldGuy ( 4145623 ) on Monday December 11, 2017 @12:51AM (#55713847)

      Oh my! I'm going to hang back, make some popcorn, step into some Tyvek coveralls, grab a hard-hat and safety goggles and enjoy the show!

      LOL, I was going to say almost the exact same thing. Save me a seat if you would, I'll be along in a minute with some extra beers and a splatter-shield.

    • Re:INCOMMING! (Score:4, Insightful)

      by Anonymous Coward on Monday December 11, 2017 @02:14AM (#55714099)

      Slackware or BSD. Everything else is not worth it.
      Red Hat has managed to do what everybody compains about Windows. Embrace Extend & Extinguish. Open source means jack squat when 1 or 2 corporte entities control the whole infrastructure stack.

    • by jwhyche ( 6192 ) on Monday December 11, 2017 @02:20AM (#55714123) Homepage

      This is going to be epic....

  • by X86BSD ( 689041 ) on Monday December 11, 2017 @12:43AM (#55713821)
    The BSDâ(TM)s and Illumos. There is no reason to use the tire fire that is Linux. You have options!
  • by nightfire-unique ( 253895 ) on Monday December 11, 2017 @12:45AM (#55713823)

    Here's a list of actual problems that should have been solved instead of introducing the nightmare of systemd upon the Linux (Debian specifically) world:

    - Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
    - When I say "reboot" I mean "reboot." Hangs are not okay, ever.
    - Actual, real soft NFS failures. Do not hang during boot for any reason unless that share is marked hard,nointr. Do not hang during shutdown/reboot, either.
    - Enforce GPL-standard syntax on new incoming utilities. If you want into the package tree, use a GNU parsing library and use it correctly. Perhaps a standardized syntax wrapper available for package maintainers.
    - Bolt simple parallelization, triggers and flow control onto init/rc.
    - Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
    - Standardize and fix bluetooth support ffs.

    My $0.02, as a 25-year Linux admin.

    • by quantaman ( 517394 ) on Monday December 11, 2017 @01:27AM (#55713983)

      - Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.

      If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.

      As long as people want new features there will either be new security vulnerabilities or software you can't afford and never gets completed. If SELinux adds enough security to be worth your bother then go for it, if not then disable it.

    • by lucm ( 889690 )

      Drop this selinux shit. It's too complicated and causes more problems than it solves.

      I think the utility called audit2allow summarizes well the immense "value" of selinux.

      generate SELinux policy allow/dontaudit rules from logs of denied operations []

      The first time I heard about it I thought it was a prank.

    • by gweihir ( 88907 ) on Monday December 11, 2017 @01:56AM (#55714055)

      I disagree on SELinux, not because its interface is well-designed (it is not), but because it is needed for some things.

      On the rest, I fully agree. And instead, systemd solves things that were already solved and does it badly. The amount of stupidity in that decision is staggering.

    • by hey! ( 33014 )

      Yes, when you focus on what you intend to happen, issues seem so clear, don't they? But all this lack of responsiveness to your demands arises from attempts to contain potential unintended consequences.

      I have a pet peeve, which is people who rank "crash" or "hang" bugs at the apex of the failure scale, above data corruption and faulty outputs. Think of an automated trading system that enters an abnormal state and starts generating random buy and sell orders for example. Or a system which is supposed to aut

  • Security services (Score:5, Interesting)

    by AHuxley ( 892839 ) on Monday December 11, 2017 @12:48AM (#55713835) Journal
    How are they going to get in and stay in if admins have real logs and can detect persistence?
  • by lkcl ( 517947 ) <> on Monday December 11, 2017 @01:01AM (#55713891) Homepage

    it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.

  • by Anonymous Coward on Monday December 11, 2017 @01:04AM (#55713901)

    Do one thing, and do it well. Systemd has eaten init, udev, inetd, syslog and soon dhcpd. Yes, that is getting ridiculous.

  • by fahrbot-bot ( 874524 ) on Monday December 11, 2017 @01:10AM (#55713923)

    I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example. I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).

    In short, systemd has too many things stuffed into its kitchen sink -- if you want that, use Emacs :-)
    [ Note, I'm a fan and long-time user of Emacs, so the joke's in good fun. ]

    • by lkcl ( 517947 ) <> on Monday December 11, 2017 @01:55AM (#55714053) Homepage

      I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.

      the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.

      free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in /dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.

      then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.

      this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.

      now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.

      the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add [] to /etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.

      in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by [] is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.

      ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irrationally closing extremely important bugreports. we may have been shocked that there were people who *literally* wanted to kill him, but those people did not react the way that they did, despite their inability to properly and rationally express themselves, without having a good underlying reason for doing so.

      software libre is supposed to be founded on ethical principles. that's what the GPL license is actually about (the four freedoms are a reflection of ETHICAL standards). can you honestly declare that systemd has been developed - and then adopted - in a truly ethical fashion? because everything i see about systemd says the complete and absolute opposite. and that is why i won't allow it on any computers that i run - not just because technically it's an inferior design with no overall redeeming features (mass-adoption is NOT a redeeming feature, it's a monoculture-level microsoft-emulating disaster), but because its developers and its blatant rail-roaded adoption across so many distributions fundamentally violates the ethical principles on which the software libre community is *supposed* to be based.

  • by Guspaz ( 556486 ) on Monday December 11, 2017 @01:22AM (#55713973)

    Betteridge's Law says no.

  • by Anonymous Coward on Monday December 11, 2017 @01:47AM (#55714035)

    it's a fine OS, the only thing it's missing is a really good init system.

  • by Plus1Entropy ( 4481723 ) on Monday December 11, 2017 @02:34AM (#55714139)

    Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.

    I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.

    I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change". Whether its nostalgia or sunk-cost fallacy, I can't say, but beyond that it seems much more like a philosophical difference than a practical one. It just reminds me of people's refusal to use the metric system, for no better reason than they are unfamiliar with it.

    If systemd is so terrible, then why did a lot of the major distros switch over? If they didn't, it would just be a footnote in the history of open source: "Hey remember when they tried to replace sysV and init with that stupid thing with the binary log files? What was it called? SystemP?" The fact that Devaun has not overtaken Debian in any real way (at least from what I've seen, feel free to correct me if I'm wrong) indicates that my experience with systemd is the norm, not the exception. The market has spoken.

    I read TFA, there is not one single specific bug or instability mentioned about systemd. What is the "tiny detail" that split the community? I have no idea, because TFA doesn't say what it is. I know that part of the philosophy behind Linux is "figuring it out yourself", but if you don't explain to me these low level kernel details (if that's even what they are; again, I have no idea), then don't expect people like me to be on your side. Linux is just a tool to me, I don't have any emotional attachment to it, so if things are working OK I am not going to start poking around under the hood just because someone posts an article claiming there are problems, but never specifying what those problems are and how they affect me as a user.

    Honestly TFA reads like "We are having development problems, therefore systemd sucks." I get that when major changes to the platform happens there are going to be issues and annoyances, but that's the way software development has always been and will always be. Even if systemd was perfect there would still be all kinds of compatibility issues and new conventions that developers would have to adapt to. That's what I would expect to happen whenever any major change is made to a widely used and versatile platform like Linux.

    Even Linus doesn't really care []:

    "I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."

    I'm not saying systemd is "better" or "the right answer". If you want to stick to distros that don't use it, that's up to you. But what I am saying is, get over it.

    • by chaoskitty ( 11449 ) <> on Monday December 11, 2017 @03:14AM (#55714245) Homepage

      Perhaps you have had no problems with systemd because you aren't trying to use it to do much.

      Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.

      On the other hand, I have yet to see real technical discussion about problems that systemd apparently is fixing. I honestly and openmindedly am curious about what makes systemd good, so I've tried on several occasions to find these discussions where good technical reasoning is used to explain the motivations behind systemd. If they exist, I haven't found any yet. I'm hoping some will appear as a result of this thread.

      But you bring up the idea that the "market has spoken"? You do realize that a majority of users use Windows, right? And people in the United States are constantly electing politicians who directly hurt the people who vote for them more than anyone else. It's called marketing. Just because something has effective marketing doesn't mean it doesn't suck.

      • Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.

        Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems bu

        • by amorsen ( 7485 ) <> on Monday December 11, 2017 @04:35AM (#55714405)

          systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic

          If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.

          The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.

          A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.

          • by marcansoft ( 727665 ) <hector AT marcansoft DOT com> on Monday December 11, 2017 @05:25AM (#55714513) Homepage

            Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.

        • by sjames ( 1099 )

          Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.

          All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process

    • It's always amusing reading comments like this. I remember hearing this kind of thing when it came to software distribution.

      "Installing Microsoft Office is so easy. I install it all the time with no issues. People are just so whiny. Why don't they just grow up and get used to it?"

      Now try installing it across a few thousand, or maybe 50,000, PCs on a staggered schedule across a business where the OS installation is supposedly standardized. There's a world out there that you don't understand, and it has issue

    • by lkcl ( 517947 ) <> on Monday December 11, 2017 @05:05AM (#55714467) Homepage

      People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".

      no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work, they know *exactly* the hell that it can and will create, under what circumstances, and they know *precisely* how they've been betrayed by the rail-roaded decisions made by distros without consulting them as to the complexities of the scenario to which they have been (successfully up until that point) deploying a GNU/Linux system.

      also they've done the research - looked up systemd vs other init systems on the CVE mitre databases and gone "holy fuck".

      also they've seen - perhaps even reported bugs themselves over the years - how well bugs are handled, and how reasonable and welcoming (or in some sad cases not, but generally it's ok) the developers are... then they've looked up the systemd bug database and how pottering abruptly CLOSES LEGITIMATE BUGREPORTS and they've gone "WHAT the fuck??"

      also, they've been through the hell that was the "proprietary world", if they're REALLY old they've witnessed first-hand the "Unix Wars" and if they're not that old they experienced the domination of Windows through the 1990s. they know what a monoculture looks like and how dangerous that is for a computing eco-system.

      in short, i have to apologise for pointing this out: they can read the danger signs far better than you can. sorry! :)

    • by marcansoft ( 727665 ) <hector AT marcansoft DOT com> on Monday December 11, 2017 @05:10AM (#55714477) Homepage

      Everyone* switched to systemd because everyone* was using something that was much, much worse. Traditional sysvinit is a joke for service startup, it can't even handle dependencies in a way that actually works reliably (sure, it works until a process fails to start or hangs, then all bets are off, and good luck keeping dependencies starting in the right order as the system changes). Upstart is a mess (with plenty of corner case bugs) and much harder to make sense of and use than systemd. I'm a much happier person writing systemd units than Upstart whatever-you-call-thems on the Ubuntu systems I have to maintain.

      The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business. It's a monolithic repo, and it's trying as hard as it can to position itself as a hard dependency for every Linux system on the face of the planet. Distros needed* a new init system, and they got an attempt to take over the Linux ecosystem along with it.

      * The exception is Gentoo, which for over 15 years has had an rc-script system (later rewritten as OpenRC) based on sysvinit as PID 1 but with real dependencies, easy to write initscripts, and all the features you might need in a server environment (works great for desktops too). It's the only distro that has had a truly server-worthy init system, with the right balance of features and understandability and ease of maintenance. Gentoo is the only major distro that hasn't switched to systemd, though it does offer systemd as an option for those who want it. OpenRC was proposed as a systemd alternative in the Debian talks, but Gentoo didn't advertise it, and nobody on the Debian side cared to give it a try. Interestingly Poettering seems to be *very* careful to *never, ever* mention OpenRC when he talks about how systemd is better than everything else. I wonder why. Gentoo developers have had to fork multiple things assimilated by systemd (like udev) in order to keep offering OpenRC as an option.

    • by phantomfive ( 622387 ) on Monday December 11, 2017 @05:47AM (#55714565) Journal

      If systemd is so terrible, then why did a lot of the major distros switch over?

      There's one use case that systemd is really good at, and that is making things easier for distro maintainers. The creators of systemd spent effort discussing it with distro maintainers, and figuring out what features they wanted. That is why they switched over.

      Systemd isn't easier for any other demographic, though.

    • I was going to google and provide you with examples, but really all you need to do is look at the google results: []

      Just that "user starting with a digit" bug alone....

    • by nathanh ( 1214 )

      People who complain about systemd the most seem to have been using Linux for a very long time

      Aka people with lots of experience. 24 years Linux experience here, for example.

      and just "don't want to change"

      Happy with change. Unhappy with systemd. It's a terrible idea and a badly run project as well.

  • by arfonrg ( 81735 ) on Monday December 11, 2017 @03:52AM (#55714315)

    "but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu."

    PRO TIP: Run Slackware. Slackware is cleaner and does everything Debian does and has never been tainted with systemd.

  • by petes_PoV ( 912422 ) on Monday December 11, 2017 @04:07AM (#55714347)

    Linux (and before that: UNIX) has always had a "look how clever I am, writing all this obscure code" mentality. Since not too long after its inception, complexity - as a way of displaying the developers' prowess - has always been favoured over simplicity and elegance.

    Whether you look at systemd, or the print subsystem or emacs or sendmail. They are all over-complex and if not intended to freeze-out users without the time, inclination or ability to grok them, then to achieve this through bad design which leads to complicated implementations.

    Good design is difficult. Too hard for most coders. And it does seem that with kernel development and the systems that surround it, most of the design decisions are simply left up to the people writing the code to make, themselves. While this is standard procedure for a teenager sitting in a darkened bedroom, knocking out .... code, it is strictly amateur-hour stuff. You would have hoped that the linux community would have moved past that in these last 30 years.

  • Not just Systemd (Score:4, Insightful)

    by houghi ( 78078 ) on Monday December 11, 2017 @04:26AM (#55714381)

    I have a PC with a Bios that tries to do everything, launching a bootloader that tries to do everything, to start a DesktopManager that treis to do everything, so I can run a browser that tries to do everything to see a website that tries to do everything.

    And to think I started with Linux, because each thing had its own program and I could select what program did it.

  • by Chrisq ( 894406 ) on Monday December 11, 2017 @04:45AM (#55714421)
    Betteridge's law of headlines meets slashdot's anti-systemd bias. Could be interesting
  • by Opportunist ( 166417 ) on Monday December 11, 2017 @05:19AM (#55714501)

    Windows is a very complex system. Not necessarily because it needs to be complex, but rather because of "wouldn't it be great if we could also..." thinking. Take the registry. Good idea in its core, a centralized repository for all configuration files. Great. But wouldn't it be nice if we could also store some states in there? And we could put the device database in there, too. And how about the security settings? And ...

    And eventually you had the mess you have now, where we're again putting configuration files into the %appdata% directory. But when we have configuration in there already anyway, couldn't we... and we could sync this for roaming, ya know...

    Which is the second MS disease. How many users actually need roaming? 2, maybe 3 out of 10? The rest is working on a stationary desktop, never moving, never roaming. But they have to have this feature, needed or not. And if you take a look through the services, you'll notice that a lot of services that you simply know you don't need MUST run because the OS needs them for some freakish reason. Because of "wouldn't it be great if this service did also...".

    systemd now brought this to the Linux world. Yes, it can do a lot. But unfortunately it does so, whether you need it or not. And it requires you to take these "features" into account when configuring it, even if you have exactly zero use for them and wouldn't potentially not even know just wtf they're supposed to do.

    systemd is as overengineered as many Windows components. And thus of course as error prone. And while it can make things more manageable for huge systems, everything becomes more convoluted and complicated for anyone that has no use for these "wouldn't it be great if it also..." features.

  • by Phil Hands ( 2365 ) on Monday December 11, 2017 @06:58AM (#55714747) Homepage

    if I have a problem with e.g. my dovecot instance on a server, with rsyslogd (as default installed on Debian) I get the fun of guessing which of mail.log,, or mail.err contains the messages I might like to see (with the mild suspicion that I ought to also glance at debug.log as well, just in case), then if I like to see things in chronological order I have the added amusment of running a command line like this:

        zcat $(ls -tr /var/log/mail.log.*.gz) | cat /var/log/mail.log - | grep dovecot | grep $whatever_I_really_wanted_to_see

    and I'll get most of what I'm looking for, along with anything else that contains the word dovecot.

    [BTW hands up anyone that thinks a gzip file is a text file]

    whereas with systemd it's just so bloody tedious:

        journalctl -u dovecot | grep $whatever_I_really_wanted_to_see

    Where's the fun in that?

    • by ledow ( 319597 )

      This is one of those false arguments, though.

      Nobody really cares about the logging, so long as there's an option to have "normal" logging if that's what you want.

      But the logging has almost nothing to do with NOT NEEDING to use the logs. The problems mentioned with systemd are not "I couldn't find a line that dovecot was saying" but services literally not starting up, boots not completing, and even things like random variations on that (which is worse than not booting at all).

      I've seen such things in the wi

    • yeah, no. (Score:4, Informative)

      by Kludge ( 13653 ) on Monday December 11, 2017 @12:17PM (#55716417)

      Your example is off base.
      1. I seldom search my gzipped backlogs, because if something went wrong, it was recent. That is why they are gzipped.
      2. If I am searching for a specific error message, like "$whatever_I_really_wanted_to_see", then generally no other program will spew that and the extra "grep dovecot" is unnecessary.
      Generally this is all you need:
      grep $whatever_I_really_wanted_to_see mail*
      Which is even simpler than the journalctl bullshit.

      Second, the example that you give above is not that difficult for an admin because zcat, cat, grep ARE ALL STANDARD TOOLS that I use for the output of virtually every program and service that I use. I do not want to have to use a different command (journalctl) to look at the output of every different program (systemd) that I run.

  • by medoc ( 90780 ) on Monday December 11, 2017 @08:33AM (#55715085) Homepage

    I am an old fart. My first Unix machine was a VME 68xx running Unix Version 7 around 1986. I am mostly a developper, but I've been doing sysadmin work as an aside (unavoidable in small companies) more or less continuously for the last 30 years.

    Recently, on upgrading my Debian home server (can't remember if it was Wheezy->Jessie or Jessie->Stretch), the server did not come back on the network after the upgrade. Go down to the garage where it lives: single user mode. No explanation nothing. After wasting 2 hours trying to guess what was happening, the explanation was that there was a stray entry in fstab. Nothing related to the real important stuff (/ or /usr), something like /proc/bus/usb or such. Systemd just decided that single user was the right thing to do. No ssh, no nothing. If the server had been remote, this would have been a major issue, instead of a couple of uncomfortable hours (restarting from backups would have been possible but would have changed a quasi-routine thing into one or more days of work).

    I can't remember a machine being so nasty to me since the 90s (Unixware maybe :) )

  • Enterprise Headache (Score:4, Informative)

    by Zarjazz ( 36278 ) on Monday December 11, 2017 @08:42AM (#55715117)

    I'm curious if Redhat are regretting their decision on the early hard switch to systemd in RHEL7. I know for a fact their support system was flooded with issues from early adopters. I have friends in the industry still on RHEL6 as the upgrade to version 7 is a logistical nightmare and one who works at a reasonably large enterprise considering ditching Redhat entirely to go to a systemd-less alternative.

    That faster boot time sure helps with servers that are only restarted once a year ...

    • by jon3k ( 691256 ) on Monday December 11, 2017 @10:44AM (#55715759)
      The best part is how they want to use systemd to save 12 seconds of boot time on my servers that take 5-10 minutes to boot, once every few years. Anyone who thinks that complexity is worth that negligible difference is insane. Of course there are other arguments for systemd, but don't tell me I need it on my servers so they "boot faster".
  • by QuietLagoon ( 813062 ) on Monday December 11, 2017 @10:42AM (#55715745)
    In my experience, on the same laptop hardware, same distribution, before and after the systemd transition, the "after" has had more reliability problems, especially during shutdown. I often see the laptop not shutdown because for a couple of minutes. It just sits there with this dumb countdown on the screen. It looks like it is waiting for some process to end, but it does not indicate what process. I never had that issue prior to systemd being adopted.

    I am now actively looking for a distribution that does not use systemd.

    Sometimes I have to wonder if the wrong feature goal (faster start-up times) was over-emphasized in the whiplash switch to systemd by the distributions. For me, the faster start up is just not that big of a deal anymore, now that I've moved to SSD.

  • by walterbyrd ( 182728 ) on Monday December 11, 2017 @11:52AM (#55716221)

    I mean a sizeable company that has it's own Linux distro, and makes money supporting that distro.

    Red Hat seems to be the enterprise Linux company.

    I suppose IBM, and Oracle, somewhat support Linux. But for those companies, Linux is just a sideline.

    I bet if there were a company like Red Hat, that had a non-systemd alternative, the Red Hat competitor would win.

The one day you'd sell your soul for something, souls are a glut.