Slashdot Mirror


Linux Mint Will Continue To Provide Both Systemd and Upstart

jones_supa writes: After Debian adopted systemd, many other Linux distributions based on that operating system made the switch as well. Ubuntu has already rolled out systemd in 15.04, but Linux Mint is providing dual options for users. The Ubuntu transition was surprisingly painless, and no one really put up a fight, but the Linux Mint team chose the middle ground. The Mint developers consider that the project needs to still wait for systemd to become more stable and mature, before it will be the default and only option.

19 of 347 comments (clear)

  1. The pain isn't in the switch by Anonymous Coward · · Score: 5, Insightful

    it's in trying to resolve problems later on, when you'll find that systemd helps you obscure the source of the trouble instead of resolve it.

    1. Re:The pain isn't in the switch by Antique+Geekmeister · · Score: 5, Insightful

      It's also in maintaining distinct management tools, configuration analysis, and configuration tools for DHCP, NTP, the new binary logging, space for logging of kernel booting, and whatever other components of the one man band have been added lately. systemd, and especially its core developer Lennart Pottering, are attempting to create a "stateless Linux", and the ramifications are spilling over into other parts of the system.

      Quoting from the b log at http://0pointer.net/blog/proje...

      > A Stateless System goes one step further: a system like this never stores /etc or /var on persistent storage, but always comes up with pristine vendor state.

      That is a _huge_ shift in system management, and directly violates the file system hierarchy where host specific configurations are stored in /etc or persistent data in /var/lib. They're basically taking all the daemon specific parameters from /etc and putting them in /run, and they're going to run into most of the same problems but in unfamiliar layouts. Every component that stores history in /var/lib or configuration in /etc will have to be rewritten, including long-standing conventions such as /etc/hosts, /etc/resolv.conf, and /etc/nsswitch.conf.

    2. Re:The pain isn't in the switch by Kazymyr · · Score: 3, Insightful

      Well for one thing by obfuscating system logs in a way that is likely (and expected) to fail.

      --
      I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
    3. Re:The pain isn't in the switch by hitmark · · Score: 4, Insightful

      The only behavior systemd "expects" is for daemons to talk to it either via dbus or libsystemd.

      http://ewontfix.com/15/

      Everything else have some kind of problem attach that is just waiting for the admin to tun his back on the rack.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    4. Re:The pain isn't in the switch by Bengie · · Score: 4, Insightful

      Bug report: Logs keep getting corrupted and cannot read them at all
      Rejected with reason: Delete the corrupted logs and move on

      SystemD - works well when it works, fails spectacularly when it fails.

    5. Re:The pain isn't in the switch by Junta · · Score: 4, Insightful

      SystemD - works well when it works, fails spectacularly when it fails.

      Incidentally that is precisely the way Windows is. Windows is exceedingly structured and engineered (contrary to some beliefs), but as a a result when it fails... boy does it go down so hard that no one is going to bring it back. Not surprising many of the principles in Windows design match the design principles of many modern linux distros: Binary configuration files, binary log files, increasingly complex IPC schemes, and less and less friendly to simple scripts (though increasingly better for complex scripting).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    6. Re:The pain isn't in the switch by Anonymous Coward · · Score: 3, Insightful

      bug report: /var/log/* corrupted, all text files replaced with zeroes from hard disk failure
      Rejected with reason: Delete the corrupted logs and move on

      For fucks sake, grow up.... ALL files types are liable to corruption and depending on the extent of corruption, you ain't gonna be able to read them, text or otherwise.

      The operative words here are "depending on the extent of corruption".

      You can read text logs with a sector editor if there's any possibility at all of pulling raw data off the hardware. For lesser damage - well, Linux is awash in text utility programs and if all else fails, put it on Windows and use the Wordpad program to read them.

      Binary logs are a different matter. To read them at all, you need a matching decoding program. And the damage to the logfiles must be within the limits of the decoding program's ability to skip around damage. You're probably not going to get anything usable from a raw sector dump.

    7. Re:The pain isn't in the switch by Anonymous Coward · · Score: 2, Insightful

      >For fucks sake, grow up....

      He did, you didn't. Your argument is based on a strawman (the hard disk is at fault). Only a 5 year old would come up with such a nonsensical argument. The assumption in Bengie's comment is systemd didn't write valid data. One is because the init system sucked, the other is because you bought shit hardware.

    8. Re:The pain isn't in the switch by Junta · · Score: 3, Insightful

      I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    9. Re:The pain isn't in the switch by ookaze · · Score: 3, Insightful

      I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.

      But that's the problem: people who constantly rage against systemd and its binary logfiles are not AT ALL interested in knowing if they can read it, they never tried, they never looked at explanations of how it works or anything.
      The fact is that you can actually use "strings" (the shell command) against your journal file and get A LOT of text logs with a lot more information than in a standard log file. Of course you lose all the semantic like the integrity of the text you're reading.
      Which is because journald won't even compress small logs because it would take too much space. Only big log lines or blobs are compressed usually.
      All this talk about systemd binary logs being unreadable is just plain lies and BS from detractors.
      Of course, if you read your log with journalctl, it will get you all the extra benefits.

  2. Yeah mint! by BlackPignouf · · Score: 4, Insightful

    One more reason to use Mint.
    That's the best they could do out of this situation.

    1. Re:Yeah mint! by Feral+Nerd · · Score: 4, Insightful

      One more reason to use Mint. That's the best they could do out of this situation.

      The thing about staying neutral in a war of religion is that you run the risk of being branded a heretic by both sides.

  3. Re:But... by gbjbaanb · · Score: 4, Insightful

    To be fair, Linux has always been multiple components that you can chose which one suits you best - whether its vi or emacs, gnome or kde, sendmail or postfix, apache or nginx, etc

    This is a good thing, where you can swap out component A for B for any reason, and keeps the project competing with each other to get better and better.

    If only you could swap out Systemd so easily, things would be great.

  4. Re:Systemd detractors are like climate change deni by sjames · · Score: 4, Insightful

    Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in /lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.

  5. Lennart Poettering is cancer on the face of Linux by Anonymous Coward · · Score: 5, Insightful

    systemd is an abomination.

    Linux's benefit for a long time now has been the ability to swap functionality out you don't like for other functionality that you do. I don't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues, written mostly by a developer who has a track record of making extraordinarily poor choices in software development and writing poor code.

    What's stunning to me is that smart people in leadership positions in a variety of distributions have decided to support such an asinine system. What's even more stunning is that Lennart didn't stop them, realizing his code was not appropriate in production environments and doing the responsible thing, which is to say "We're far from ready". systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".

    For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.

    Lennart likes to whine about how much the community hates him and how much people take it out on him personally. Reality is that outside of a few people who take it much too far, the reason people don't like Lennart is because he makes poor decisions with poor forethought and his advocacy and arrogance for his own approach have a seriously negative effect on a great many people, enterprises, and efforts. He likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.

    The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.

    I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development.
    I hope it comes sooner rather than later.

  6. Re:But... by gl4ss · · Score: 4, Insightful

    because some software expects it and doesn't run without it.
    shit software, but software anyways.

    that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.

    why would startup utility provide user authentication? to conquer everything of course.

    --
    world was created 5 seconds before this post as it is.
  7. Thank you, Mint by The+Infamous+Grimace · · Score: 3, Insightful

    Seriously. Thank you for giving me a choice. If I want to try systemd and see if I run into issues with my particular use-cases, I can. If I want to avoid the possibility of conflicts and continue with the (admittedly crufty) sysvinit scripts I can.

    --
    Ignorance and prejudice and fear
    Walk hand in hand
  8. Re:I like how this got marked troll by drinkypoo · · Score: 4, Insightful

    Sincerely, all this hate towards systemd looks like pure zealotry.

    Yeah, that's what they said about our love for Linux in the first place. Now that it's successful, and specific people are helping specific corporations gain undue control of it and at the expense of quality, they say it again about our desire to protect what made us care about it in the first place. We love Unixlikes which are actually "like Unix" ("The Unix Way", blah blah blah) not solely for aesthetic reasons, but for specific technical reasons which systemd compromises.

    True, like any piece of software, systemd surely must have issues (binary logs seem like one) that should be fixed or parts that may be improved, but all this constant bashing from some members against it, is just purely irrational.

    It's constantly being bashed by "some members" of the community because it's still a problem. It's not like we pointed out the problems and they were fixed, or the community rejected it. We pointed out real problems which were summarily ignored, and which are now becoming real problems for more people. This is not production-quality software. I am not in theory against everything they are trying to do, but I am absolutely against the way they are trying to do it, and who is trying to do it as he has proven both his incompetence and unwillingness to consider user feedback in the past.

    In any case, normal users and readers of /. are sick and tired of your constant rantings about systemd.

    Riiiiight, that's why we keep having these massive arguments about systemd, because you are all so tired of it. Just like you don't need the FCC to take things off the air because you can change the channel, you don't need us to stop discussing systemd and why it's literally both bad and wrong. You can just skip the discussion.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  9. Re:Logs via network by drinkypoo · · Score: 4, Insightful

    The real, fundamental problem isn't even having binary logging, they are free to do that in whatever miserably thought out bugfest they like. The problem is that they thought binary logging should be the primary means, and that is just stupid. I am all for a binary log... right next to the good old text log like we've always had. And if this was what they had done, then they would have got no argument on this issue. Instead, they threw away what we had, what was working, what all our tools were expecting, and replaced it with something that works sometimes.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"