Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ubuntu To Officially Switch To systemd Next Monday

Posted by Soulskill on from the dissenting-dachshund dept.

jones_supa writes: Ubuntu is going live with systemd, reports Martin Pitt in the ubuntu-devel-announce mailing list. Next Monday, Vivid (15.04) will be switched to boot with systemd instead of UpStart. The change concerns desktop, server, and all other current flavors. Technically, this will flip around the preferred dependency of init to systemd-sysv | upstart in package management, which will affect new installs, but not upgrades. Upgrades will be switched by adding systemd-sysv to ubuntu-standard's dependencies. If you want, you can manually do the change already, but it's advisable to do an one-time boot first. Right now it is important that if you run into any trouble, file a proper bug report in Launchpad (ubuntu-bug systemd). If after some weeks it is found that there are too many or too big regressions, Ubuntu can still revert back to UpStart.

509 of 765 comments (clear)

  1. ABOUT FUCKING TIME! by Anonymous Coward · · Score: 3, Funny

    Now time for me to switch to Windows!

    1. Re:ABOUT FUCKING TIME! by dotancohen · · Score: 3, Insightful

      Interestingly enough, 15.04 is deep into the Beta status and due for release next month. A major change, such as swapping out the init daemon, should be done in Alpha, and far before any Beta release. Certainly not in the month before a release!

      Why is everything connected to systemd pushed out in such a hurry? Why isn't systemd getting proper time for review?

      Here is the Ubuntu 15.04 release schedule:
      https://wiki.ubuntu.com/VividV...

      --
      It is dangerous to be right when the government is wrong.
    2. Re:ABOUT FUCKING TIME! by FreonTrip · · Score: 3, Insightful

      It's like hastily cobbling PulseAudio into the works so many years ago, but dramatically worse. Ubuntu's its own worst enemy, and you're foolish if you slap 15.04 onto bare hardware on day one.

    3. Re:ABOUT FUCKING TIME! by Anonymous Coward · · Score: 5, Informative

      Ubuntu 15.04 is not a LTS release, it's a testbed for features looking to be included on the upcoming Ubuntu 16.04 LTS.
      It is not recommended for production systems. If you want the latest stable version, use Ubuntu 14.04.2.

    4. Re:ABOUT FUCKING TIME! by Anonymous Coward · · Score: 2, Informative

      Train crashes cannot be moderated.

    5. Re:ABOUT FUCKING TIME! by Anonymous Coward · · Score: 4, Interesting

      What you say is very true. IMHO Ubuntu has become an answer but someone that forgotten the question.
      I lost faith with it around the 2012.4 release. Far too much essential stuff unfinished.
      Went back to Debian for a while but a new job in 2013 has given me an insight into the RedHat world. now I run CentOS on my laptop. Rock solid.

      However if you want nowt to do with 'systemd' then there is very little choice left. Even Debian has gone to the dark side.
      BSD? Off you go then.

      Personally, I think that Ubuntu is becoming increasinly irrelevant with each release.

    6. Re:ABOUT FUCKING TIME! by Anonymous Coward · · Score: 2, Interesting

      systemd is actually pretty kool. I mean, except for running Windows, how else could
      you introduce subtle regressions into linux?

      The LUKs wait for password at boot timeout is back again; policy kit thinks I need root
      permission to mount devices already mounted, etc.

      There are other regressions,too, but you just get used to them :(

    7. Re:ABOUT FUCKING TIME! by gweihir · · Score: 2, Informative

      Why is everything connected to systemd pushed out in such a hurry? Why isn't systemd getting proper time for review?

      Is it not obvious? They are trying very hard to get it in everywhere before people wake up. As their technology sucks badly, they have to force too short testing intervals so people will not find too many of the problems. If this were a stable, feature complete piece of software that actually solves the things it is targeted at well and significantly better than the alternatives, there would be no need for rushing it out in such an unprofessional manner.

      Here is my take on it and why systemd is a problem, not a solution:
      -----
      Not that I can be sure, but at I see:
      - No technical merits of systemd that are important or critical, just some convenience issues
      - Systemd is in hurried development, a stable feature set is nowhere in sight
      - The development leads are known incompetents with inflated egos and no communication skills
      - There are a number of design decisions that are very, very bad for security and stability

      At the same time I see:
      - Systemd is pushed strongly with emotional (not factual) arguments
                    This is a coordinated and targeted propaganda campaign. A campaign focused on technical merits is not even attempted seriously.
      - Systemd opponents are ridiculed, insulted and their arguments are not taken seriously
      - Systemd is getting very hard to avoid

      I can only deduce that there _must_ be one of or a combination of the following going on:
      - Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
      - Linux did not generate enough support revenue for Red Hat and this is intended to fix that
      - Red Hat wants total control over Linux and systemd is their attempt to establish that

      So if it walks like a duck, quacks like a duck, the most probable explanation is that it is a duck and hence I conclude that something nefarious is going on and the last three items are the most likely candidates IMO. I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves. They must have significant, coordinated help, with significant propaganda and manipulation experience. Whether it is military PsyOps or just commercial PR, the effects are the same. And they are massively negative and destructive for Linux and its community if not repelled decisively.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:ABOUT FUCKING TIME! by gweihir · · Score: 2, Insightful

      The push not on technical merit but on emotional arguments is unmistakable. This is not what should be happening with Linux. It is just the same propaganda BS that is all too common in the commercial space and has been used to hype many bad and broken products.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1, Insightful

      While I agree, the style of pushing it is similar. And while such a despicable style does not reflect on the product being pushed, it is in itself a problem, as you can push arbitrary bad or evil things this way, as systemd nicely demonstrates. And "by their methods thous shalt know them" does have merit, even if it is not universally true.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    10. Re:ABOUT FUCKING TIME! by DoofusOfDeath · · Score: 3, Funny

      Happily, if systemd really is a train-wreck in the making, there are still some other distros keeping the altneraties alive. So if Canonical and/or Debian ends up regretting the choice, there should be the living knowledge for a while to revert.

    11. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1, Insightful

      Thanks for confirming my point: "Systemd is pushed strongly with emotional (not factual) arguments".

      It does not get more obvious than you just were.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    12. Re:ABOUT FUCKING TIME! by DoofusOfDeath · · Score: 1

      Thank goodness for forks.

    13. Re:ABOUT FUCKING TIME! by Barsteward · · Score: 1

      whats the "carrot" and whats the "stick"? this author must have real power to force virtually every distro to adopt it

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    14. Re:ABOUT FUCKING TIME! by RoccamOccam · · Score: 2, Insightful

      Doug, Ian, and Robert are standing next to a cliff. Doug says "let's jump!"

      Robert says "No!!" and lists all the bad things that could happen. Doug yells at Robert "You're just a Contrarian! Besides, I got the idea from your Uncle Mitt!" Robert retorts "Sure, but that was just jumping off of a sand pile. Also, I never liked that idea, none of my other relatives liked that idea, and none of my friends liked that idea. And I dislike this idea even more!"

      Ian mumbles "I don't know. I want to think about it."

      "Too late!" screams Doug, while grabbing Ian and Robert and jumping.

      As they lie in a broken heap at the bottom of the cliff, Doug stumbles to his feet, having used Ian and Robert to break his fall, and points at them "Remember, we all wanted to do this!"

    15. Re:ABOUT FUCKING TIME! by Barsteward · · Score: 2, Informative

      a site for you http://www.amazon.com/Aluminum...

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    16. Re: ABOUT FUCKING TIME! by buchanmilne · · Score: 2

      Really? Please link to mailing list posts from Lennart pushing Debian or Ubuntu to to adopt systemd (advising on features/benefits relevant to an upcoming decison the distro already had to make does not count).

    17. Re:ABOUT FUCKING TIME! by almitydave · · Score: 2, Informative

      The question is: "What is the maximally fucked-up linux distro?"

      Well, that would be Suicide Linux, obviously.

      --
      my, your, his/her/its, our, your, their
      I'm, you're, he's/she's/it's, we're, you're, they're
    18. Re:ABOUT FUCKING TIME! by almitydave · · Score: 4, Informative

      Link: Suicide Linux

      --
      my, your, his/her/its, our, your, their
      I'm, you're, he's/she's/it's, we're, you're, they're
    19. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 5, Informative

      I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves.

      I don't think it's that bad, they don't have to convince the entire 'tech-savvy community,' they only need to convince a very small subset of that community, the people who are writing init scripts for distros. And that subset is very small.

      Systemd knows that very well. They've worked very hard to make init-script writers happy, and have been very responsive in making changes. If you look through the Debian mailing lists, you can see this......there's no need to blame the NSA or others. They're just following a useful principle: find the ones who have power to do what you want, then make them as happy as possible. The systemd people have done that.

      --
      "First they came for the slanderers and i said nothing."
    20. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 5, Insightful

      Systemd has laudable goals and people do want it. That's why it's been adopted, because some people want what it does. "It fills a use case people have" is what Linus says. And that use case happens to be the one that desired by the people responsible for building distros.

      --
      "First they came for the slanderers and i said nothing."
    21. Re:ABOUT FUCKING TIME! by sound+vision · · Score: 1, Insightful

      Resistance to the ACA mobilized fast and hard, from the moment it was proposed, and court challenges to it have proceeded non-stop from the beginning right up to this year. There are fundamental flaws in the ACA (like insurance companies and employers still being the gatekeepers to healthcare) but they don't need "careful vetting" to spot.

    22. Re: ABOUT FUCKING TIME! by phantomfive · · Score: 2

      Here's a link I have handy to where he was pushing it for Gnome.

      --
      "First they came for the slanderers and i said nothing."
    23. Re:ABOUT FUCKING TIME! by DoofusOfDeath · · Score: 2, Interesting

      I'm thinking of a few specific aspects of how the ACA passage happened.

      The first is Pelosi actually convincing members of Congress to vote on the bill before reading it. I.e., her infamous "you'll have to pass the bill to find out what's in it" gambit. (It takes a lot of self control to not go into a tirade every time I think of that.)

      The second is this: NPR did a great story talking about a variety of healthcare systems around the world, in terms of cost, outcomes, and implementation details. (Germany's looked especially good.) But nothing in the ACA seemed to indicate any of those vetted designs was seriously considered. It's like the authors of the ACA suffered from Not Invented Here syndrome. Or perhaps just as likely, the lobbyists didn't find it to their liking.

    24. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 2

      The carrot is making things as easy as possible for the people who write init scripts in distros (since they are the ones who are responsible for deciding whether systemd is adopted or not). That is discussed here and here. The stick are the emotional posts that the author spreads throughout the internet (threatening distro irrelevance, etc).

      --
      "First they came for the slanderers and i said nothing."
    25. Re:ABOUT FUCKING TIME! by marcello_dl · · Score: 1

      > Now time for me to switch to Windows!
      Why bother switching now? wait for next monday and you will automatically have the full windows experience.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    26. Re:ABOUT FUCKING TIME! by Carewolf · · Score: 3, Insightful

      I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves.

      I don't think it's that bad, they don't have to convince the entire 'tech-savvy community,' they only need to convince a very small subset of that community, the people who are writing init scripts for distros. And that subset is very small.

      Systemd knows that very well. They've worked very hard to make init-script writers happy, and have been very responsive in making changes. If you look through the Debian mailing lists, you can see this......there's no need to blame the NSA or others. They're just following a useful principle: find the ones who have power to do what you want, then make them as happy as possible. The systemd people have done that.

      You mean they took the people that actually have to deal with init scripts and made them happy? Instead of making something good that would make people using init scripts happy?

      Wait. What is the difference?

    27. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 1

      The main thing I think you're missing is that systemd makes some people happy and some people sad. And the set of people it has to make happy is very small (as to the set of people who it actually makes happy and the set of people it actually makes sad: I have no idea how large those sets are, and probably no one else does either).

      --
      "First they came for the slanderers and i said nothing."
    28. Re:ABOUT FUCKING TIME! by NotDrWho · · Score: 1

      Thank goodness for forks.

      That's exactly what MS and Apple say every time someone brings up the possibility that Linux may one day be a serious competitor with their OS's.

      --
      SJW's don't eliminate discrimination. They just expropriate it for themselves.
    29. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1

      Indeed. It is hard to believe any actual person that read my comment could be this stupid.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    30. Re:ABOUT FUCKING TIME! by Anonymous Coward · · Score: 2, Insightful

      Um, I disagree with the way you've worded just about everything but you've basically hit upon it with #3: this is about control and standardization, and working around the GPL (kinda like tivo-ization).

      It doesn't come up that often in the arguments as it's gone under the radar, but if you notice systemd keeps pulling in more and more aspects of the OS (networking, virtualization, etc.), and that's because they want to be able to package commercial software without worrying about linking issues for commercial customers because everything passes through their shims.

      Soon they'll be able to have an app store/linux where they're selling working photoshop running in a DRM'd way but because everything is being passed as messages to the various libraries instead of accessing them directly. Their corporate customers end up with a locked down environment doing an end-run around the GPL and we get a technically open-source OS filled with a bunch of software passing through redhat as an app-store.

    31. Re:ABOUT FUCKING TIME! by meta-monkey · · Score: 3, Informative

      Wow, what the hell do you take us for? Aluminum foil? Aluminum foil?! The shit you put on your TV antenna to get better reception? Yeah, yeah, that's really going to block the government mind control rays.

      Jesus. Tinfoil man. Tinfoil.

      --
      We don't have a state-run media we have a media-run state.
    32. Re:ABOUT FUCKING TIME! by zidium · · Score: 1

      All I know is that systemd has screwed up so many times on just dev vms I have to use for various clients' devwork, that there is NO WAY I'd ever put it on my production boxes! Gosh! There is something really wrong when PID 1 uses 1 MB of RAM, and something even worse when you can swear it has a memleak...

      --
      Slashdot Valentines Beta Massacre: iT WORKED! The boycotts killed Beta!!
    33. Re: ABOUT FUCKING TIME! by phantomfive · · Score: 2

      GNOME single-handedly fucked up the Linux ecosystem when they decided to make systemd a hard dependency!

      Systemd is not a hard dependency of Gnome, and probably never will be. I'm not sure why people think that.

      --
      "First they came for the slanderers and i said nothing."
    34. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1

      Indeed. Good point.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    35. Re:ABOUT FUCKING TIME! by Pope+Hagbard · · Score: 4, Informative

      Really, though, if you're sticking anything but an LTS version onto bare hardware you're asking for trouble. They're very up-front about non-LTS releases like 15.04 being barely-supported betas for LTSes. So in that sense rolling out systemd at this stage is a pretty good idea since they'll have a year to work out kinks before 16.04, while IIRC they switched to PulseAudio not long before the LTS 8.04 release, with disastrous results.

    36. Re:ABOUT FUCKING TIME! by kthreadd · · Score: 1

      With the current trend of containerized environments the LTS releases are not necessarily the go-to choice for servers. Since everything about your deployment is automated moving to newer base OS is not really that big of deal in most cases. Getting access to newer versions of software can actually be desirable.

    37. Re:ABOUT FUCKING TIME! by caseih · · Score: 1

      How many years are you looking for? Systemd has been in production for a long time now. We're talking four years now. The actual init daemon is small and very stable and has been so for years (I might also add Pulseaudio is stable and has been for years now too).

    38. Re:ABOUT FUCKING TIME! by caseih · · Score: 3, Insightful

      Funny-looking duck you have there.

      Almost everything you say there is blatant misinformation. Way to spread the FUD. Pretty amazing stuff. Especially your idea that there's no technical merit to systemd, and by extension replacing upstart, which replaced sysv.

      90% of systemd's suite of utilities are not part of init, and not even required or used by most people and their distros. It does, though, make containers and cloud a lot easier for those who want to do that. Certainly makes administration better on servers.

      Before you launch into this sort of diatribe, would it hurt to learn a bit about systemd and what it's doing than to simply parrot old FUD and unsubstantiated claims (and I use that word rather loosely)? Wild conspiracy theories make all of us in the Linux and Open Source world just look silly and hurts all of our credibility.

    39. Re:ABOUT FUCKING TIME! by mark_lybarger · · Score: 1

      push of binary files for a gentoo based system sounds like a hand grenade. one use flag change, or one package.keywords change and the whole system can need changed. each system is really best built and maintained on its own.

    40. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 3, Informative

      Gimp doesn't seem to depend on systemd (here is a brief discussion on the topic). It seems to be a rumor, but I don't know where it started.

      --
      "First they came for the slanderers and i said nothing."
    41. Re:ABOUT FUCKING TIME! by Movi · · Score: 2

      Well, Gentoo will never make your run systemd, or even udev. Come over, we have cookies (which you can compile yourself)!

    42. Re:ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Except that the ACA had laudable goals and was basically embraced by everyone except the Contrarian Party. Systemd has no such support and nobody wanted it from day 1.

      systemd has the full support of the American Communist party.

      --
      Watch this Heartland Institute video
    43. Re:ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Actually, the stick is the fact that Gimp and some other notable software now depend on systemd. I have no idea why an image manipulation application needs any particular init daemon, but that is the case.

      Factually, the only "notable" software that depends on systemd is gummiboot.

      --
      Watch this Heartland Institute video
    44. Re: ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Here's a link I have handy to where he was pushing it for Gnome.

      And that dates from 2011, and when the consensus went against him he specificly included code in Gnome to make it not depend on systemd.

      --
      Watch this Heartland Institute video
    45. Re: ABOUT FUCKING TIME! by BarbaraHudson · · Score: 1

      GNOME single-handedly fucked up the Linux ecosystem when they decided to make systemd a hard dependency!

      I think you're being too optimistic - they were screwing up long, long before that ...

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    46. Re:ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      What distro?

      What versions?

      What w as the error?

      Have you made a bug report?

      --
      Watch this Heartland Institute video
    47. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 1

      a!=b?a^=b^=a^=b:0;

      Good thing there is no != assignment operator.......

      --
      "First they came for the slanderers and i said nothing."
    48. Re:ABOUT FUCKING TIME! by reboot246 · · Score: 1

      No, the ACA was not vetted and tested before implementation. That's why it's so screwed up now.

      The deal with Romney-care was that it was a STATE program. It was never meant to scale up to be nationwide. That's the way this country is supposed to work. Let the ideas begin and get problems solved on a state level first so that you don't fuck up the whole country with a bad idea.

      Some people are just too impatient to wait for change the proper way.

    49. Re:ABOUT FUCKING TIME! by steveg · · Score: 1

      Not according to the experts.

      For certain values of "expert," of course.

      --
      Ignorance killed the cat. Curiosity was framed.
    50. Re:ABOUT FUCKING TIME! by blackomegax · · Score: 2

      If 15.04 really were a beta for 16.04, it would be called THE FUCKING 16.04 BETA. But no, they push it as 'release' so it should be fucking HELD TO THAT. /rant

    51. Re:ABOUT FUCKING TIME! by DamnOregonian · · Score: 2

      Ehhhhh, I'm not going to argue that the PPACA passage wasn't a massive circus, but you are taking her comments pretty far out of context. When she said that, her chamber of Congress had already passed its bill (HR 3962) and was waiting on Senate passage/reconciliation. There are 2 possibilities regarding her statement- the first being that she forgot the House had passed the bill off to the Senate, or she was referring to what would come of the reconciliation, since at the time there was a massive effort to get Republican senate approval and changes were being actively made to it at their request.

      The people making a massive deal of that soundbite also have 2 possibilities: They're woefully ignorant of how the US Congress works, or they're trying to capitalize off of a poorly worded statement by turning it into something it's not.

      I hate that I'm having to defend Nancy fucking Pelosi, but media soundbites are fucking ridiculous.

    52. Re: ABOUT FUCKING TIME! by phantomfive · · Score: 1

      Did he add that code to Gnome?

      --
      "First they came for the slanderers and i said nothing."
    53. Re:ABOUT FUCKING TIME! by znrt · · Score: 1

      ubuntu has always been linux for casual users.

      well, the initial motto was "linux for human beings" but, well, it's just a catchy motto.

      now if you consider what it really means to be "an operating system for casual users" you realize that ubuntu is not at all far from windows or macos on that level, don't expect too much. however, it's free, and it's an entrypoint to more advanced distros. it's still not irrelevant.

    54. Re:ABOUT FUCKING TIME! by znrt · · Score: 1

      Link: Suicide Linux

      lol.

      Things Of Interest Blog
      Suicide Linux
      You know how sometimes if you mistype a filename in Bash, it corrects your spelling and runs the command anyway? Such as when changing directory, or opening a file.

      no. never. really?

      any time - you type any remotely incorrect command, the interpreter creatively resolves it into rm -rf / and wipes your hard drive.

      freaky idea anyway, can't say i don't like it.

    55. Re:ABOUT FUCKING TIME! by khallow · · Score: 1

      Ehhhhh, I'm not going to argue that the PPACA passage wasn't a massive circus, but you are taking her comments pretty far out of context.

      I don't think so. It's doubtful she had a clue what was in it aside from a broad overview of the key parts. It was after all over 2,000 pages, right? It was a glib assurance which we see in hindsight was unjustified.

      The people making a massive deal of that soundbite also have 2 possibilities: They're woefully ignorant of how the US Congress works, or they're trying to capitalize off of a poorly worded statement by turning it into something it's not.

      Or they aren't at all ignorant of how US Congress works, where each congresscritter come with its own reality deflection system, and things, like the actual content of bills, don't really matter.

    56. Re:ABOUT FUCKING TIME! by DamnOregonian · · Score: 2

      I don't think so. It's doubtful she had a clue what was in it aside from a broad overview of the key parts. It was after all over 2,000 pages, right? It was a glib assurance which we see in hindsight was unjustified.

      Sigh. As I said, the bill had already passed her chamber of congress, so she had either forgotten about that (I suppose you'll say that's possibility), or she was referring to the Senate reconciliation process. I'm not even saying I disagree with the point you're trying to make, but the comment is still taken entirely out of context. I'm certain there were people in the Senate debates... the *year* of debates, that knew full well what was in the bill.

      FY2007's omnibus budget bill was 1400 pages. You're using an absolute number that is shocking with nothing for comparison. Either you knew that, and are being disingenuous, or you didn't, and now you do.

    57. Re:ABOUT FUCKING TIME! by dltaylor · · Score: 1

      Remindes me of the time, many moons ago, when I wanted to clear a lot of junk from "/tmp" on System V.

      About a half-second after typing "rm -rf /tmp/.*\n", I realized that "/tmp/.." was "/", which was, of course, too late.

      I was truly thankful for a rigorous and thorough backup schedule.

    58. Re:ABOUT FUCKING TIME! by sfcat · · Score: 1

      Systemd has laudable goals and people do want it. That's why it's been adopted, because some people want what it does. "It fills a use case people have" is what Linus says. And that use case happens to be the one that desired by the people responsible for building distros.

      Ah, so its just like the cloud then.

      --
      "Those that start by burning books, will end by burning men."
    59. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1

      Anything conducting will do, but Aluminum is a lot less effective than Copper or even Gold and forget about foil. A nice general-purpose HF box will be 0.5 to 1mm of copper with tin(Sn)-plating so it can be soldered well.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    60. Re:ABOUT FUCKING TIME! by fisted · · Score: 1

      /tmp/.??* gets 'em all. nearly.

      --
      CLI paste? paste.pr0.tips!
    61. Re:ABOUT FUCKING TIME! by dbIII · · Score: 1

      The first is Pelosi actually convincing members of Congress to vote on the bill before reading it

      Just like then "PATRIOT" act. Once you start a race to the bottom things go downhill.

    62. Re:ABOUT FUCKING TIME! by dbIII · · Score: 1

      Red Hat wants total control over Linux and systemd is their attempt to establish that

      I'm not so sure whether that is Red Hat itself or Lennart exerting his influence within Red Hat. He's certainly made no secret that he wants to rebuild linux userspace to a new design.

    63. Re:ABOUT FUCKING TIME! by dbIII · · Score: 2

      90% of systemd's suite of utilities are not part of init

      That's kind of the point. It's a fucking octopus that doesn't even offer enough of an improvement over other forms of init to justify such widespread adoption. It's not ultra-fast like the one that had a proof of concept on the eeepc, so instead it's more like change for the sake of change. Binary log files at startup when you have little available if it hangs and other idiocies that are a step backwards.

    64. Re:ABOUT FUCKING TIME! by Phil+Urich · · Score: 1

      Ack, hit the keyboard and accidentally moderated you troll. Weirdly fitting to make such a mistake in relation to Suicide Linux.

      --
      I remember sigs. Oh, a simpler time!
    65. Re:ABOUT FUCKING TIME! by Kevin+Fishburne · · Score: 2

      I started with Linux in 2007 experimenting with Debian and later using Ubuntu. Switched to Kubuntu for several years and just recently to Mint. I think at some point Mint is going to drop its dependence on Ubuntu for its main distro and use Debian exclusively. They're already well-positioned to do so with their Debian variant, and have a rock-solid understanding of what a desktop computing experience should feel like to the average user. To systemd or not to systemd is not the question for most people, the quality and intuitiveness of the user experience is, and I think the Mint team understands that as well as the importance of sane underpinnings. There will come a time when all of us thank Ubuntu for what it has done before letting it go forever.

      --
      Buy your next Linux PC at eightvirtues.com
    66. Re:ABOUT FUCKING TIME! by zdzichu · · Score: 1

      In a hurry? Systemd is almost five years old, distributions have now *years* of experience integrating it.

      --
      :wq
    67. Re: ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Did he add that code to Gnome?

      Yes

      Some people don’t realise that when Gnome started making use of Logind, I actually wrote the patch for that. I ported GDM onto Logind. But when it did that, I was very careful to make sure it would still run on ConsoleKit.

      http://www.linuxvoice.com/interview-lennart-poettering/

      --
      Watch this Heartland Institute video
    68. Re: ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      At least on Debian the Gnome requires gvfs, which requires systemd.

      No it doesn't:

      $ apt-cache depends `dpkg -l | grep gvfs |nawk '{print $2}'` | grep systemd
        Depends: libsystemd0

      No dependancy on systemd.

      --
      Watch this Heartland Institute video
    69. Re:ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Thanks for confirming my point: "Systemd is pushed strongly with emotional (not factual) arguments".

      It does not get more obvious than you just were.

      Projection?

      I've never seen you make a techncal argument, just a long list of insults and consiracy theories.

      --
      Watch this Heartland Institute video
    70. Re:ABOUT FUCKING TIME! by Barsteward · · Score: 1

      You are blaming the wrong person, if something like Gimp decided to interface with systemd, its the Gimp developers.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    71. Re:ABOUT FUCKING TIME! by khallow · · Score: 1
      So what if you "said" that? I'm pointing out the obvious. This wasn't a small bill and I doubt she had much of a clue what was actually in the bill.

      FY2007's omnibus budget bill was 1400 pages. You're using an absolute number that is shocking with nothing for comparison. Either you knew that, and are being disingenuous, or you didn't, and now you do.

      You're not helping your case here. An omnibus budget bill, covering a lot more stuff, just happened to be considerably smaller than the bill Pelosi was speaking of.

    72. Re:ABOUT FUCKING TIME! by Barsteward · · Score: 1

      "The carrot is making things as easy as possible for the people who write init scripts in distros" - nothing wrong with that.

      "The stick are the emotional posts that the author spreads throughout the internet " - can you link to those, all i've seen is him answer the stupid trolls misinformed understanding of how systemd works? i can't see pointing out the obvious as a "stick", must make the rest of the distro decision makers a bunch of wimps.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    73. Re:ABOUT FUCKING TIME! by Barsteward · · Score: 1

      ok, if you've lost your sense of humour try this instead http://www.skeptic.com/reading...

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    74. Re:ABOUT FUCKING TIME! by Jobless+*topia · · Score: 1

      It's like hastily cobbling PulseAudio into the works so many years ago, but dramatically worse. Ubuntu's its own worst enemy, and you're foolish if you slap 15.04 onto bare hardware on day one.

      Speaking of PulseAudio, it seems Bluetooth audio no longer works purely with the Alsa sound drivers. The package bluez-audio has been removed from the testing and unstable branches of Debian. A package search for bluetooth audio results however in pulseaudio-module-bluetooth, which I'm hesitant to install because it would pull in the whole PulseAudio stack. I'm wondering how the lightweight Ubuntu/Debian derivatives, not to mention the embedded distros like OpenWRT, are going to cope with this horrible mess just to get something basic as wireless sound.

    75. Re: ABOUT FUCKING TIME! by segedunum · · Score: 1

      It's getting slightly tiring watching morons pull out their apt-cache and grep magic in order to try and search for plain strings of 'systemd' and deny the obvious dependency chain going on here every time a systemd topic comes up:

      http://packages.ubuntu.com/viv...

      libudev:

      http://packages.ubuntu.com/viv...

      Source: systemd

      Besides, for anyone who has the vaguest idea of how systemd actually works, or tries to work, then you would know that playing dependency tennis doesn't work. systemd works through the house of cards IPC system that is DBus so dependencies are now exceptionally well hidden amongst a fucking forest of namespaces.

    76. Re: ABOUT FUCKING TIME! by segedunum · · Score: 1

      Well, of course he would as ConsoleKit was the current component at the time, so he had to. That doesn't alter the fact that ConsoleKit is being deprecated and Lennert has said as much. Anyone hoping to depend on it to get around systemd is going to be disappointed.

    77. Re:ABOUT FUCKING TIME! by segedunum · · Score: 1

      Funny-looking duck you have there.

      90% of systemd's suite of utilities are not part of init, and not even required or used by most people and their distros.

      Strange that you've just described a very bog standard duck and pretty much repeated verbatim the OP's problem. This is kind of strange for something that purports to be an init system, no? I think you need to sit down for a little while, lay off the keyboard and have a think about the ramifications of what you wrote there.

      It does, though, make containers and cloud a lot easier for those who want to do that. Certainly makes administration better on servers.

      No it doesn't - and especially in the latter case. I've been managing containers for quite a long time and frankly, I'm not the slightest bit interested in companies who want to fuck up the Linux userspace so they can cram as many hapless customers on to a piece of cloud hardware as they can. That is simply all that it is for.

    78. Re:ABOUT FUCKING TIME! by segedunum · · Score: 1

      Have look at the title of this article and read it back to yourself a couple of times.

    79. Re:ABOUT FUCKING TIME! by segedunum · · Score: 1

      Have a look at the title of this article and read it back a few times if you're not getting it.

    80. Re: ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Does gvfs depend on systemd? No, it depends on udev.

      Does udev depend on systemd? No.

      The source code of udev is in the same directory as that of systemd, but you don't have to install systemd to use udev and removing systemd will not remove udev or gvfs.

      I can't help it if you don't know what the word "depends" means in this context.

      --
      Watch this Heartland Institute video
    81. Re: ABOUT FUCKING TIME! by Calavar · · Score: 1

      State-level reform is a step in the right direction, but it will not work as a final solution when nearly a quarter of healthcare spending in the country goes through Medicaid/Medicare or the VA; we need federal-level regulation as well. And regulation at the national level is precisely what has been working on other countries -- I dare you to give me one example of a nation where the majority of health care funding is governed by legislation at the state or provincial level.

    82. Re: ABOUT FUCKING TIME! by TooTechy · · Score: 1

      RevengeD? Is that part of the suicide distribution?

    83. Re:ABOUT FUCKING TIME! by dotancohen · · Score: 1

      Gimp doesn't seem to depend on systemd (here is a brief discussion on the topic). It seems to be a rumor, but I don't know where it started.

      Thanks. That link doesn't seem to be much of a discussion, but I'll take your word for it being just a rumour as it certainly does not make much sense that an user-facing app would depend upon any specific init system. We know that there are quite a few rumours about systemd floating about.

      --
      It is dangerous to be right when the government is wrong.
    84. Re:ABOUT FUCKING TIME! by dotancohen · · Score: 1

      In a hurry? Systemd is almost five years old, distributions have now *years* of experience integrating it.

      Correct. Distros typically integrate software, especially system-critical software, at the beginning of a release cycle. We are now nearing the _end_ of the Ubuntu 15.04 release cycle. I have no problem with including systemd. I do find it unusual that such a critical system component is being swapped out so late in a release cycle. It should have happened three or four months ago for Ubuntu 15.04, or in two months from now for Ubuntu 15.10.

      --
      It is dangerous to be right when the government is wrong.
    85. Re:ABOUT FUCKING TIME! by dotancohen · · Score: 1

      You are blaming the wrong person, if something like Gimp decided to interface with systemd, its the Gimp developers.

      I'm not placing blame, and you are right that it would be Gimp devs who would be responsible for including such a dependency.

      In any case, the assertion that Gimp depends on systemd seems to be rumour anyway. I hope that my GP post gets modded off the page, I have no way to retract it.

      --
      It is dangerous to be right when the government is wrong.
    86. Re:ABOUT FUCKING TIME! by jc79 · · Score: 1

      Systemd is LGPL but it doesn't matter what license it has if it's the copyright holder that's packaging and linking the commercial software alongside it. What Red Hat do with their commercial products is literally their business. It's up to you to choose to buy their stuff or not. All the Free stuff will remain Free - it's not like distros based on the Free RHEL sources such as Scientific Linux will be going away any time soon.

    87. Re:ABOUT FUCKING TIME! by jc79 · · Score: 1

      Well don't use it then, and stop whining. No one's forcing this on you. Use a different distro instead. That's how the free market is supposed to work isn't it?

    88. Re:ABOUT FUCKING TIME! by zdzichu · · Score: 1

      So? Ubuntu decided to go systemd in February 2014. It was over a year ago? Is year "hurry"?

      --
      :wq
    89. Re:ABOUT FUCKING TIME! by jbernardo · · Score: 1

      I still am not sure if it is "I'm paid to mod this down" or "it criticises the work of the prophet! Destroy!". So many of the pro-systemd gang seem to take everything LP writes on faith and react violently against any critic that I wonder...

    90. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 1

      Yeah. When I get time, I'll dig in deeper to verify, but Gimp runs on non-Linux systems, so it seems unlikely. I could imagine in some distros systemd has been listed as a dependency, but that's not because of Gimp, it's because of their dependency tree.......

      --
      "First they came for the slanderers and i said nothing."
    91. Re:ABOUT FUCKING TIME! by Samizdata · · Score: 1

      So Quora is a casual user then?

      --
      It's not the years, honey, it's the mileage. - Colonel Henry Walton Jones, Jr., Ph.D.
    92. Re:ABOUT FUCKING TIME! by Ol+Olsoc · · Score: 1

      Why is everything connected to systemd pushed out in such a hurry? Why isn't systemd getting proper time for review?.

      Choose from the list:

      1. Liberals

      2. Ancient Aliens 3. The Illuminati

      4. Thanks, O'Bama

      4. Global Warming Hoax

      5. Sexist Pig programmers keeping women out of STEM.

      Feel free to add as you see fit.

      --
      The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
    93. Re:ABOUT FUCKING TIME! by Ol+Olsoc · · Score: 1

      you're foolish if you slap 15.04 onto bare hardware on day one.

      Umm, that's how you should do any OS. I've waited From W95 and System 6.7 through today, Always wait a few months at least, although in the case of Windows, it's Service Pack 1.

      --
      The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
    94. Re:ABOUT FUCKING TIME! by Ol+Olsoc · · Score: 1

      Well, Gentoo will never make your run systemd, or even udev. Come over, we have cookies (which you can compile yourself)!

      But do you have T-Shirts? People love T-Shirts.

      --
      The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
    95. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1

      Hehehehehe, nice! I have a move to Gentoo planned for when Debian wheezy runs out of LTS or becomes too clunky. (Unless by that time Debian has pulled back, some sanity may still to be had even with all the people in Red Hat's pocket...)

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    96. Re:ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Hint: I had an academic course once that covered these methods. It was specifically designed to allow engineers and scientists to identify when they are attacked in this fashion. These are well known methods to sabotage opposition in negotiations, conflicts, etc. Of course such methods are not employed with people that have intact honor and integrity.

      You seem to have learned the lesson well.

      To reiterate -- you have never made a technical argument about systemd. All your posts are calls to emotion, insults and attempted manipulation.

      I agree. such methods are not used by people with intact honor and integrity.

      --
      Watch this Heartland Institute video
    97. Re: ABOUT FUCKING TIME! by Eunuchswear · · Score: 1

      Anyone hoping to depend on [consolekit[ to get around systemd is going to be disappointed.

      Or, rather than being disappointed they could work on loginkit, systemd-shim or systemd-bsd.

      But maybe it's more fun to bitch.

      --
      Watch this Heartland Institute video
    98. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1

      Indeed. This whole thing is a giant step backwards, and it does just one thing well: It gives Red Hat an exceptional level of control. That is the only plausible explanation why they are pulling in everything. It is a clear "embrace and extend" move, and utterly evil.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    99. Re:ABOUT FUCKING TIME! by gweihir · · Score: 1

      Possible, but I think the smear-campaign against opponents is too large. There is no sane reason to "rebuild linux userspace" at this time, except that Poettering may have kernel-envy. If this where Linus, I would at least give this the benefit of the doubt, but Poettering is a known incompetent with bad communication and coding skills and delusions of grandeur.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    100. Re:ABOUT FUCKING TIME! by Shirley+Marquez · · Score: 1

      There is Devuan, a fork of Debian without systemd. No release yet, but they hope to have one ready by the time jessie is released so a modern alternative will be available. https://devuan.org/

    101. Re:ABOUT FUCKING TIME! by MoonSweep · · Score: 1

      How many years are you looking for? Systemd has been in production for a long time now. We're talking four years now.

      Then we don't have the same definition for the term "production".

      With all due respect for their respective users, Fedora, Arch or OpenSUSE are not production OSes. Debian, RHEL and SLES are. For me, and (at the risk of hurting some people) for real system administrators, systemd has been in production only since June 9th, 2014 (release date of RHEL 7.0), which is, as of right now, barely 11 months.

    102. Re: ABOUT FUCKING TIME! by MoonSweep · · Score: 1

      Really? Please link to mailing list posts from Lennart pushing Debian or Ubuntu to to adopt systemd (advising on features/benefits relevant to an upcoming decison the distro already had to make does not count).

      Does this qualify ?

    103. Re:ABOUT FUCKING TIME! by darenw · · Score: 1

      And Linux From Scratch too, I suppose.

      I mean, concerning choice about avoiding systemd. As for cookies, bake your own from scratch!

    104. Re:ABOUT FUCKING TIME! by dbIII · · Score: 1

      except that Poettering may have kernel-envy.

      That could be it, from the following quote I get the idea that he thinks he could have made a better linux than Linus:
      http://www.zdnet.com/article/lennart-poetterings-linus-torvalds-rant/

      "If Linux had success, then that certainly happened despite, not because of this [Torvald's] behavior. I am pretty sure the damage being done by this is quite obvious, it not only sours the tone in the Linux community, it is also teaches new contributors to adopt the same style, but that's only if it doesn't scare them away in the first place. In other words: A fish rots from the head down."

      What I just do not get is the host of fanboys that turn up to insist that all software that started before 2010 is shit and we should just get out of the way and swallow anything new whether it works or not.

    105. Re:ABOUT FUCKING TIME! by phantomfive · · Score: 1

      Looks like it's true

      --
      "First they came for the slanderers and i said nothing."
    106. Re: ABOUT FUCKING TIME! by lems1 · · Score: 1

      You are misled. This is well tested. Now it's just making it official.

      --
      This sig can be distributed under the LGPL license
    107. Re: ABOUT FUCKING TIME! by dotancohen · · Score: 1

      I never implied that systemd is not well tested. I stated that the beta release state is not the state to make major changes in the OS. The feature freeze for this release was one month ago:
      https://wiki.ubuntu.com/Featur...

      --
      It is dangerous to be right when the government is wrong.
    108. Re: ABOUT FUCKING TIME! by lems1 · · Score: 1

      So wait... 15.04 was supposed to get systemd and now they activate it and you think it shouldn't be activated until ...

      I don't see your argument as valid. However, this is slashdot and you can rant all you want.

      --
      This sig can be distributed under the LGPL license
  2. Not ready for primetime by halivar · · Score: 5, Funny

    It still doesn't have a decent architecture for scheme plugins and a robust text editor.

    1. Re:Not ready for primetime by Shakrai · · Score: 3, Informative

      There's always Slackware. I still use it as "go to" distro for both desktop and server roles. It's not as sexy other distros but there's no better way to learn Linux. I highly doubt Patrick is going to jump on the systemd bandwagon any time soon, if ever.

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    2. Re:Not ready for primetime by buchner.johannes · · Score: 3, Informative

      The upstart team will be disappointed.
      Here are two interesting talks presenting the two approaches: systemd vs Upstart for Debian.

      I learned a lot about what systemd actually is and does.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    3. Re:Not ready for primetime by Anonymous Coward · · Score: 1

      > I highly doubt Patrick is going to jump on the systemd bandwagon any time soon, if ever.

      Patrick told me earlier that Slackware is moving to upstart soon

    4. Re: Not ready for primetime by TheBilgeRat · · Score: 4, Informative

      Seriously? Puppet Labs has supported it for 5 years now. Managing a slackware sever or servers is no harder or easier than any other one. Now, if you're hand rolling special snowflakes and have no strategy to manage them, sure. But that would be true for any distro or OS.

    5. Re:Not ready for primetime by phantomfive · · Score: 1

      Serious question: how do you deal with updating your system? With no 'apt-get update' what do you do? Most importantly, how do you make sure to get the latest security updates?

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Not ready for primetime by Clopnixus · · Score: 2

      slackpkg update
      slackpg install-new
      slackpkg upgrade-all

      Or so my notes tell me... Switching over when Debian Jessie is out.

    7. Re:Not ready for primetime by phantomfive · · Score: 1

      Sweet thanks!

      --
      "First they came for the slanderers and i said nothing."
    8. Re:Not ready for primetime by Phreakiture · · Score: 1

      Is there a deb based derivative of slack?

      Um . . . . . No.

      Slackware is kind of . . . manual. In fact, the only distro I can think of that is more manual is Gentoo. Even Gentoo is capable of resolving dependencies automatically, though, which Slack is not. This is actually why Slack is such a good distro for learning the guts -- if you have an unresolved dependency, it is up to you to figure out how to resolve it.

      I used to run my systems as a very bare-bones Slack (or Slamd64 before Slack finally went to 64-bit) and then install whatever else I wanted from source. It was loads of fun to tinker on because it never tried to second-guess you. Good times!

      --
      www.wavefront-av.com
    9. Re:Not ready for primetime by Shakrai · · Score: 1

      Ah, I remember Slamd64. I had that puppy on my first ever 64 bit machine, it took a few years for Slackware to jump on the 64 bit train.

      I don't see the issue with using it as a server in a production environment, particularly if you roll servers with a specific role rather than trying to Swiss Army Knife them. If you monitor slackware-current they're as responsive as any distro with security updates and the package management isn't that cumbersome. Of course, if you're using Slackware the odds are good that you've compiled your own daemons and should be on top of patches/security updates yourself.

      Either way it's not a deal breaker for a production server, unless you need a big company to hold your hand for everything, and in that instance why not just runa Windows server?

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    10. Re:Not ready for primetime by hitmark · · Score: 1

      Then again, half the supposed issues that the push to containerize everything "Linux" can be fixed by not having the package manager do dependencies.

      This because it is Linux or the GNU toolchains that has issues with multiple lib versions (the major source of "dependency hell"), it is the package managers.

      Both DEB and RPM balk at having libxyz-v1.0 and lubxyz-v1.1 installed at the same time (unless you do something fancy with the package names). Libtool don't care, as it has SONAME to keep track of the lib version that the binary wants.

      But to "fix" this the clever boys behind systemd and Gome are planning to cram everything into containers so that each "app" can only see the libs it claims to need.

      Dude that's a tweety bird you are trying to shoot down, not a B-52!

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    11. Re:Not ready for primetime by hitmark · · Score: 1

      Not surprising, given that the systemd talk is done by the head honcho himself. Do wonder what kind of bus factor he was within the project...

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    12. Re:Not ready for primetime by psmears · · Score: 1

      This because it is Linux or the GNU toolchains that has issues with multiple lib versions (the major source of "dependency hell"), it is the package managers.

      Actually the package managers can handle it just fine (well, I know RPM can, and I *think* dpkg/apt can too); usually the problem is that the libraries are packaged in a way that doesn't support this. If two versions of a package share no files (e.g. if you provide "libxyz.so.1.0.0" in one package, and "libxyz.so.1.1.0" in another version of the same package, RPM can handle having both versions of the package installed with no problems at all. This is used, for example, to support having multiple kernel versions installed on RedHat-type systems. What becomes a problem is if you have (say) binaries in the same package, with the same name in each version, but different contents: naturally RPM will report a conflict if you try to install both.

      --
      Need to type accents and special characters in Windows? Use FrKeys
  3. Watching systemd evolve by Shakrai · · Score: 5, Funny

    Enjoy

    --
    I want peace on earth and goodwill toward man.
    We are the United States Government! We don't do that sort of thing.
    1. Re:Watching systemd evolve by Penguinisto · · Score: 1

      Needs more blood.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    2. Re:Watching systemd evolve by kolbe · · Score: 3, Informative

      But but Fedora has been using it for years without issue! Oh wait, that's because no Admin in their right mind would use Fedora as a server. But but it is stable and secure. Oh wait, your high load servers keep corrupting the journald and journalctl can't read portions of it without trying to replace the who journal with a new one. But but you can install rsyslog to fix that! Yeah, because we ALL like having to beta test an unproven product in a production environment only to be forced in resorting to something else that actually works as intended.

      I'm caring less about systemd and more about how shortsighted they were when they forced everyone to use journald. The fact that I have to configure rsyslog to have a working log that does not constantly get corrupted and restart a new log, erasing the old one is annoying and shows just how unproven this entire systemd implementation truly is.

    3. Re:Watching systemd evolve by OzPeter · · Score: 1

      When I saw that link all I could think of was Pam's dolphin puppet

      --
      I am Slashdot. Are you Slashdot as well?
    4. Re:Watching systemd evolve by DoofusOfDeath · · Score: 4, Insightful

      "But but ...

      When you pretend to be a foolish version of someone else, in order to mock them, you only make yourself look foolish.

      If you really have a valid point to make, argue against your opponents' best points. Don't make an ad hominem attack against a caricature of the opponent.

    5. Re:Watching systemd evolve by devent · · Score: 4, Informative

      Fedora is a testing ground for Red Hat Linux, you know, the predominant server distribution. Red Hat Enterprise Linux have systemd starting with version 7.0 and Ubuntu just joins the ranks of every other enterprise Linux distribution to use systemd, like SUSE Linux Enterprise Server and Mageia. So, you are ignorant of the facts to call systemd an "unproven product".

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    6. Re:Watching systemd evolve by kolbe · · Score: 4, Informative

      Here is one of many:

      https://bugs.freedesktop.org/s...

      The TL;DR resolution: journalctl --fsck after rotation or pump it into a traditional syslog

      Lennart Poettering's comments about it:

      "our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse"

    7. Re:Watching systemd evolve by kolbe · · Score: 1

      I may have weakened my point by indeed mocking people on the conjecture that so many /.'ers simply jump on a bandwagon without knowledge of the entire entity. However, it is hard to ignore the sheer ignorance of some at times and I admit fault in letting it get to me. Regardless, journald is still a huge thorn for many and needs to be addressed.

    8. Re:Watching systemd evolve by Barsteward · · Score: 1

      "your high load servers keep corrupting the journald " corrupting a daemon?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    9. Re:Watching systemd evolve by gweihir · · Score: 2

      Indeed. This is crap-ware in the finest tradition of old Windows releases. Unfortunately, parts of the Linux-community seem to have forgotten why good Linux software is stable, secure and mature.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    10. Re:Watching systemd evolve by gweihir · · Score: 4, Insightful

      Nice. This person does not even understand what logs are for and why it is critical to make sure they get to disk uncorrupted if possible at all. A decent system will achieve that as long as the disk is still up. systemd apparently does not even try to.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:Watching systemd evolve by gweihir · · Score: 1

      There are quire a few people and organizations that are avoiding the downgrade to RHEL 7.0 like the plague and with good reason. Most of these have given it a shot and have good reasons.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    12. Re:Watching systemd evolve by Peter+H.S. · · Score: 5, Informative

      Don't get your panties in bunch just because you discover that the journal is "corrupted"; usually it is just trivial stuff like a malformed timestamp or a field value that isn't valid in a single log entry. journald actually test and validate incoming log messages and report errors as it finds them. Even then, you can often read the log entry, but of course, the invalid field value will be missing.

      The reason why people discover "corrupted" journal log files is because systemd's journal have integrity checks, unlike syslog who doesn't and where the admin therefore never will know if there are spurious or invalid log entries unless he happens to stumble upon them by chance.

      Seriously, if you really care about each and every log entry, you should never have been using syslog anyway; it simply silently drops messages under load, and both local and remote logging are inherently unreliable. Yeah, I know Rainer have made a signal-safe syslog library, but does anybody actually use it?

      There are simply too many Linux newbies who seems to be unaware of decade long struggle to improve the many, many problems with syslog. The "rsyslog" team have fought heroically, but often in vain, to try to fix many of the problems.

      Syslog, like cron and SysVinit are among the several pieces of Linux infrastructure that can't be changed or radically improved. Because if you change your syslog/cron/SysVinit implementation, it would be incompatible with syslog/cron/SysVinit, so no one would use it, because user space programs doesn't support it etc. A circular dependency that prevent all progress. The systemd project have finally broken Linux free from that quagmire, so now we can actually have Linux infrastructure developed in the same pace as the kernel and user space programs and daemons.

      systemd's journal is, warts and all, a massive improvement over the what existed before.

    13. Re:Watching systemd evolve by Barsteward · · Score: 1

      if a disk is corrupting sectors where the logs (or anything) are being written, nothing will stop the corruption, not even syslog or rsyslog. "systemd apparently does not even try to." -eh?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    14. Re:Watching systemd evolve by Barsteward · · Score: 1

      want to link to them so we can see their reasons?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    15. Re:Watching systemd evolve by gweihir · · Score: 2, Interesting

      Systemd causes log corruption where sane alternatives do not have such issues. Ever wonder why?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    16. Re:Watching systemd evolve by unrtst · · Score: 4, Informative

      The bug report linked by kolbe (https://bugs.freedesktop.org/show_bug.cgi?id=64116) is, IMO, a very good read to give a quick glimpse of the fine lines between the two camps (pro-systemd; anti-systemd).

      Poettering's first reply/answer was simple, "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."

      That embodies the "here's a bug; our answer is to say it's a feature and not a bug; NOFIX" that some people feel.

      He then follows it up with a much longer reply because, "Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd". I'm not quoting out of context - that's the first sentence of his reply. Regardless of the motivation to his reply, the reply was much more thorough and he seems to truly want to help others understand. IE. I think it shows some of the good side there.

      However, I'm still anti camp, and I'm not there because bugs like this are not directly fixed. I'm anti because of the underlying assumptions that are needed in order for his reasoning to be justified. In this case, that reasoning only works if one assumes the need for a binary log whose format includes re-writable parts at the front of the file, and whose corruption results in an non-repairable state. However, if the format is such that, after corruption, it's difficult or impossible to fix, why are they using that format?

      FWIW, that specific bug report was, "How does one fix journal corruptions?". In that context,his answer is completely sufficient - you don't. The next question seems obvious to me though - how do we avoid that in the future? Currently, it seems that the systemd solution is to make the log reader more intelligent so that it can handle the corruption, like an FSCK, and read as much as it can.

      Personally, I'm really hoping that uselessd matures and becomes commonplace and easy to drop in. It's not ideal, but it seems that systemd is going to be everywhere through the Linux community, and there's no good way to avoid that at this time. Uselessd would at least allow someone to use alternative init systems while still being able to use modern applications and environments without crippling them. Regardless of ones opinions on systemd and other init systems, the ability to swap out a subsystem is something that we should all be able to recognize as valuable.

    17. Re:Watching systemd evolve by Anonymous Coward · · Score: 1

      Systemd causes log corruption

      Lots of things cause log corruption.

      In the case of a failing disk or file system, the likes of rsyslog would be worse off because the daemons don't even know the logs are corrupt.

    18. Re:Watching systemd evolve by vakuona · · Score: 1

      So post as anonymous!

    19. Re:Watching systemd evolve by Peter+H.S. · · Score: 3, Informative

      Here is one of many:

      https://bugs.freedesktop.org/s...

      The TL;DR resolution: journalctl --fsck after rotation or pump it into a traditional syslog

      Lennart Poettering's comments about it:

      "our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse"

      Totally sensible solution, why would you edit log files? They are not meant to be changed.

      Besides that, the log entries that are mangled are in them self important info; How can you detect a pattern of a misbehaving program that sends wrong field values if you delete the entry every time it happens?
      Or what if the log corruption is caused by a failing disk where the bad blocks are spreading like wildfire? If you silently delete such entries and files, you delete the evidence for that something is wrong.

    20. Re:Watching systemd evolve by Carewolf · · Score: 1

      But but Fedora has been using it for years without issue! Oh wait, that's because no Admin in their right mind would use Fedora as a server. But but it is stable and secure. Oh wait, your high load servers keep corrupting the journald and journalctl can't read portions of it without trying to replace the who journal with a new one. But but you can install rsyslog to fix that! Yeah, because we ALL like having to beta test an unproven product in a production environment only to be forced in resorting to something else that actually works as intended.

      I'm caring less about systemd and more about how shortsighted they were when they forced everyone to use journald. The fact that I have to configure rsyslog to have a working log that does not constantly get corrupted and restart a new log, erasing the old one is annoying and shows just how unproven this entire systemd implementation truly is.

      Journald is is not forced. Like everything in systemd the services are modular, and you can use them or not. Debian for instance does not use journald.

    21. Re:Watching systemd evolve by gweihir · · Score: 3, Informative

      Fascinating. You have not the least clue what you are talking about. Obviously nobody with the least bit of clue would expect logs to be cleanly written on failing disks, hence this is not even a subject for discussion. As to rsyslog, you really are utterly stupid: Failing disks or filesystems are detected rightfully by the kernel, nothing else has any business doing so. Different from systemd "logging", rsyslog will not make the log problem worse by using a binary format and a broken flush strategy, and for remote logging will transfer the messages off-site.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    22. Re:Watching systemd evolve by Anonymous Coward · · Score: 1

      The organization I work for, which manages multiple servers and research clusters, is very carefully avoiding RHeL7 (and the derivitave CentOS 7) on the majority of our systems at least partly due to systemd, and our experiences with attempted version changes to it, which then had to be backtracked to older installs to get things running properly again. It will likely be at least another year or two before we consider the technology stable enough to put into a system that our users rely on.
      (Not gweihir by the way, no idea what his examples are. Also not telling you which organization I work for.)

    23. Re: Watching systemd evolve by gilboad · · Score: 1

      Just for the sake of the argument, on how many say, 2S and 4S servers have you tested systemd before judging it broken?
      Oh, what please post the combined load your high end servers handle.

    24. Re:Watching systemd evolve by gweihir · · Score: 1

      You obviously have no idea ho easy it is to identify people once you have a warrant.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    25. Re:Watching systemd evolve by Jamie+Lokier · · Score: 4, Informative

      Systemd causes log corruption where sane alternatives do not have such issues. Ever wonder why?

      Utterly false. The idea that syslog doesn't have corruption is false. I have seen syslog corruption many times. Whether it's truncated lines, merged lines because half of an old truncated line has a new message appended, blocks of 4k zero bytes, or single bit or single character errors.

      In particular if a syslog file is truncated mid-line by either disk full, system failure, filesystem bug or drive bug, the best thing syslog could do when it resumes after boot would be to rotate log files at that point, instead of appending to the truncated file.

      These are quite rare, but not so rare that I haven't seen them maybe 50 times in 20 years in Linux syslog files.

      I have no opinion on systemd particularly, but with regard to this single thing of rotating logs on detecting corruption, instead of attempting to patch the corruption or continue appending to the file, I think the right decision was made, from the perspective of an admin wanting the best available information after a problem.

    26. Re:Watching systemd evolve by kolbe · · Score: 4, Informative

      > Have better hardware, have a RAID, transfer the log messages over the network, have a UPS on your computer, invent a time machine.

      You do realize this happens regardless of what hardware you are running. In my case, I have a VCE VBLOCK 720 running VMware Vsphere 5.5 against an EMC VMAX 10K that is only only 40% full and has 1ms FC latency across an ALUA mode4 (MPIO least-connect) configured path.

      The issue isn't some out of place one off situation, but rather a consistent issue that other admins have experienced while running applications like Oracle E-Business Suite (EBS), SAP and Oracle RAC 12c with high limits of logging facilities. Visit VMworld, go to a VMUG, a VCE UG or any other group that runs lots of priority 1 applications on high end systems for their corporate environment and you will hear the same issue crop up in conversation many times.

      Transferring log messages via rsyslog or snmp traps is CURRENTLY the only resolve here and it is one I find to be annoying.

      "The next question seems obvious to me though - how do we avoid that in the future?"

      I do not know, I am not a programmer. All I can say though is that it is an issue where the systemd camp has yet to satisfy sysadmins.

    27. Re:Watching systemd evolve by Eunuchswear · · Score: 1

      So you reported this serious security bug when? What is the bug report URL?

      Can you explain why this mysterious bug doesn't happen on a newly installed CentOS 7 system?

      --
      Watch this Heartland Institute video
    28. Re:Watching systemd evolve by Barsteward · · Score: 1

      i can google and i do in order to sort out the shit posted about systemd. if you really had information, you'd have posted it

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    29. Re:Watching systemd evolve by Barsteward · · Score: 1

      i can also make up stuff thats not supported by evidence

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    30. Re:Watching systemd evolve by Barsteward · · Score: 1

      "Systemd causes log corruption where sane alternatives do not have such issues." - just why do you propagate this shit?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    31. Re:Watching systemd evolve by Barsteward · · Score: 1

      " Obviously nobody with the least bit of clue would expect logs to be cleanly written on failing disks, hence this is not even a subject for discussion" exactly so if rsyslog logs are corrupted its expected but if journald logs are corrupted, its the fault of systemd, great logic

      " Failing disks or filesystems are detected rightfully by the kernel, nothing else has any business doing so" so what else does?

      ""Different from systemd "logging", rsyslog will not make the log problem worse by using a binary format " - it doesn;t make any difference what format the logs are written in, if the location of the log file data is trashed, then its totally or partially unreadable in any format.

      " and for remote logging will transfer the messages off-site." and if the system fails before rsyslog is actually running or the network is not yet loaded? rsyslog is loaded quite late in the boot process as opposed to journald

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    32. Re:Watching systemd evolve by devent · · Score: 1

      So, your issue with systemd is that it works just like syslog, only that systemd makes the issue more transparent by showing corrupted logs instead of just silently drop them like syslog?

      "Transferring log messages via rsyslog or snmp traps is CURRENTLY the only resolve here and it is one I find to be annoying."

      Just like you would without systemd. I don't see why you think then it is a bug of systemd. I think you should open a feature request.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    33. Re:Watching systemd evolve by gweihir · · Score: 1

      And you confirm your complete cluelessness: Log corruption is almost never due to hardware problems with the storage these days.

      Funny thing is you just conform what most of us already have observed: Proponents of systemd are "useful idiots" for the side pushing it, but are utterly clueless about what the problems with it actually are and why they are problems.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    34. Re:Watching systemd evolve by gweihir · · Score: 1

      No, I would not. I like working in this industry and violating a customer NDA is a sure way to end that. But I am pretty sure you know that and are just being dishonest.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    35. Re:Watching systemd evolve by gweihir · · Score: 1

      It is not. First, no enterprise-grade log is ever stored (only) on the machine itself. Sure, local logs have some merits, but they are a nightmare to handle on enterprise-scale. And also sure, quite a few enterprises are still in the process to centralize logging. But the last thing needed is binary logs that can only be reliably read on the machine where they were created. One very strong argument for plain-text logs is that they can be centrally collected and evaluated without running any system-specific binaries. As such, systemd logging is a massive step backwards to the dark ages of computing.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    36. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      The major point of systemd's binary logs are that they are both structured, indexed, and contain rich meta-data, something plain syslog logs isn't.

      That again means that when you export your logs to a log-sink, you can do so in a format that fits directly into the log-sinks database like JSON format and preserve the rich meta-data like the "_MACHINE_ID" field, that uniquely are tying every log-entry to a certain machine. You can also be sure that that the program claiming to generate the entry actually is correct since journald provides kernel guarantee for this.

      If you choose to keep the logs in journald's binary format on the log sink server, you gain the benefit of indexed fields when analysing data; a huge win when it comes to random access. So much faster than trawling through text logs (O(n) complexity and all that).

      Every log entry can be traced back to a certain machine (not just hostname), many log fields have kernel guarantee for what they say, besides having integrity checking and even strong cryptographically "forward secure sealing" (FSS) security against tampering.
      The journald logs are simply designed from the ground up to be read an analysed on other computers than the one they were generated on, either in their native format or as exported logs.

      Since the journald can be accessed programmatically, it can aggregate and analyse logs across different languages and has strong immunity against changing wording of the daemons log output (it operates on fields, not words).

      And since the journal logs are structured identically by a documented standard, they are trivial to aggregate, unlike the output of many different syslog implementations.

      Since the journald binary logging file format is stable and fully documented, and can be accessed programmatically with language bindings, you don't need a specific binary like "journalctl" to read them. In fact, there are there is a Rsyslog module that allows it to directly read (and export with metadata) systemd journal's. There are also Python modules etc. that acts as journal readers etc.
      In fact, it is quite possible to make a systemd journal reader that works on non-systemd platforms like MS-Windows or OSX.

      The journald collate all logging on the Linux machine, that means everything can be trivially exported to a remote log-sink, including the kernel ring buffer and the binary utmp and wtmp log files that syslog doesn't know about, and it can include early boot and late shutdown log info because it can work in initramfs, something syslog can't.

      How about journald being designed as signal-safe from the ground up (unlike syslog) and that it doesn't silently drop messages under load etc. etc.....

      systemd's binary log format is simply a massive win for both the enterprise user and the Linux newbie and everything in between.

      The arguments against it are based on contrived scenarios, like professional admins that doesn't have (systemd) boot medias and lack access to a pc, a usb stick and a internet connection so they can make one in 5 minutes.

      All the standard Linux text tools like grep, tee, sed, sort etc. work with systemd's journal through the Linux/Unix concept of piping.

      Sure, systemd's journal still doesn't have as many tool sets and projects around it as syslog. But that it is simply a matter of time.

    37. Re:Watching systemd evolve by segedunum · · Score: 1

      Journald is is not forced. Like everything in systemd the services are modular, and you can use them or not. Debian for instance does not use journald.

      Repeating this tripe like a broken record won't make it true I'm afraid. Yes, people are using rsyslog....so they can avoid having their logs corrupted.

    38. Re:Watching systemd evolve by segedunum · · Score: 1

      The reason why people discover "corrupted" journal log files is because systemd's journal have integrity checks, unlike syslog who doesn't and where the admin therefore never will know if there are spurious or invalid log entries unless he happens to stumble upon them by chance.

      Seriously, if you really care about each and every log entry, you should never have been using syslog anyway; it simply silently drops messages under load, and both local and remote logging are inherently unreliable. Yeah, I know Rainer have made a signal-safe syslog library, but does anybody actually use it?

      What a load of utter claptrap. Just when you think the brain damage and denial can't get worse........it does, in spades.

      A logging system corrupts logs, in a format specified by it, because it checks their integrity. I can only suggest checking into a clinic somewhere.

    39. Re:Watching systemd evolve by segedunum · · Score: 1

      Totally sensible solution, why would you edit log files? They are not meant to be changed.

      They aren't meant to be corrupted in this manner either, but apparently journald has a fsck option in an attempt to fix it. Crazy. I don't know where editing files was mentioned.

      Or what if the log corruption is caused by a failing disk where the bad blocks are spreading like wildfire? If you silently delete such entries and files, you delete the evidence for that something is wrong.

      Ahhhh, the whole 'disk corruption' misdirection. Yes, corruption could also be caused by solar flares, but this isn't, nor is it caused by a failing disk. It is caused by the journalling system itself. No investigation of this has happened, according to the maintainer 'it happens', we rotate and move on. Lunacy of the top order.

    40. Re:Watching systemd evolve by segedunum · · Score: 1

      Utterly false. The idea that syslog doesn't have corruption is false.I have seen syslog corruption many times. Whether it's truncated lines, merged lines because half of an old truncated line has a new message appended, blocks of 4k zero bytes, or single bit or single character errors.

      Ahhhh, the 'syslog is just as bad' defence. We're going to see more of this kind of defensive butt covering as the inevitable problems continue to crawl out of the woodwork with the smorgasbord of systemd components.

      In particular if a syslog file is truncated mid-line by either disk full, system failure, filesystem bug or drive bug, the best thing syslog could do when it resumes after boot would be to rotate log files at that point, instead of appending to the truncated file.

      I can literally count on the fingers of a lot less than one hand the number of times I've seen this, and they're all related to a rotation procedure not being done properly, a problem in the software you're logging for or a catastrophic failure of the system. syslog hasn't found the fountain of eternal youth, so one can only apologise for that, but I have never heard of the kinds of corruption caused with it on a perfectly running system as journald has chalked up.

      These are quite rare, but not so rare that I haven't seen them maybe 50 times in 20 years in Linux syslog files.

      Yer. Go figure.

      I have no opinion on systemd particularly, but with regard to this single thing of rotating logs on detecting corruption, instead of attempting to patch the corruption or continue appending to the file, I think the right decision was made, from the perspective of an admin wanting the best available information after a problem.

      Personally, I would prefer an investigation into why logs are being corrupted like this and a willingness to take it seriously rather than a 'corruption happens, rotate' attitude, but I'm just funny like that.

    41. Re:Watching systemd evolve by segedunum · · Score: 1

      " Obviously nobody with the least bit of clue would expect logs to be cleanly written on failing disks, hence this is not even a subject for discussion" exactly so if rsyslog logs are corrupted its expected but if journald logs are corrupted, its the fault of systemd, great logic

      For the umpteenth time, these corruptions are not being caused by failing disks, but that is the only thing that you have here so things are understandably getting a little desperate.

      These reports are happening on perfectly running systems and they are a lot more frequent than they should be from a logging system.

    42. Re:Watching systemd evolve by segedunum · · Score: 1

      Lots of things cause log corruption.

      In the case of a failing disk or file system, the likes of rsyslog would be worse off because the daemons don't even know the logs are corrupt.

      No, you're actually worse off with journald. Piecing together a partial text file is actually possible. However, if you lose a corrupt binary file you lose the whole thing. It's all or nothing.

    43. Re:Watching systemd evolve by segedunum · · Score: 1

      So, your issue with systemd is that it works just like syslog, only that systemd makes the issue more transparent by showing corrupted logs instead of just silently drop them like syslog?

      No:

      1. This is happening *a lot* more frequently than on syslog based systems, and on seemingly perfectly running systems at that.

      2. With a binary log file you've lost the whole thing. Unless the fsck happens (I still can't get over that - fsck on log files) and works then you've lost it. Putting together a partial text log is certainly possible. I would expect we will see a whole lot of third-party tools cropping up in the future to attempt to 'solve' these corruptions.

      This is just.......basic.

    44. Re:Watching systemd evolve by segedunum · · Score: 1

      This is the merest tip of the iceberg of the problems we're going to have.

      There are a lot of 'difficult' developers in the community that we've all heard of or had to deal with but no one I knows compares to the obvious issues that Lennart seems to have.

    45. Re:Watching systemd evolve by segedunum · · Score: 1

      Because it's true.

    46. Re:Watching systemd evolve by segedunum · · Score: 1

      When you pretend to be a foolish version of someone else......

      It's not terribly hard I'm afraid.

      If you really have a valid point to make, argue against your opponents' best points. Don't make an ad hominem attack against a caricature of the opponent.

      If only you could hold everyone in the 'discussion' to such high standards.........

    47. Re:Watching systemd evolve by segedunum · · Score: 1

      You asked for it you idiot.......

    48. Re:Watching systemd evolve by segedunum · · Score: 1

      contain rich meta-data....

      What a load of claptrap. People log to log files for reasons of the lowest common denominator. We have things called 'databases' for this kind of stuff and there's perfectly good reasons we don't use them for logging which should be obvious to anyone with an ounce of sense.

      Since the journald binary logging file format is stable and fully documented....

      I sincerely hope Red Hat and Lennart is paying for this piece of contrived PR.

      The arguments against it are based on contrived scenarios

      Corrupted logs on a perfectly running system isn't a contrived scenario.

      ....through the Linux/Unix concept of piping.

      Piping eh? Wow. You give the impression you haven't heard of it before ;-).

    49. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      A logging system corrupts logs, in a format specified by it, because it checks their integrity. I can only suggest checking into a clinic somewhere.

      I can only suggest that you start to read up on systemd and the journal. You seem utterly confused about even basic facts.

    50. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      They aren't meant to be corrupted in this manner either, but apparently journald has a fsck option in an attempt to fix it. Crazy. I don't know where editing files was mentioned.

      You misunderstand; there _isn't_ a "fsck" option for systemd journals and there won't be because that would be equivalent of "editing the log files".

      Ahhhh, the whole 'disk corruption' misdirection. Yes, corruption could also be caused by solar flares, but this isn't, nor is it caused by a failing disk. It is caused by the journalling system itself. No investigation of this has happened, according to the maintainer 'it happens', we rotate and move on. Lunacy of the top order.

      You simply don't understand how journald works. Let me explain again: systemd marks certain log entries as "corrupted" if eg. they are plain wrong, that is the client is sending obviously wrong or malformed log entries. That way you avoid impossible field values that may otherwise have screwed the log watch or log analysing programs; think of it as discarding bad data. This is the most common "journal" corruption that people discover when using the journalctl "verify" option. It is usually totally harmless and usually limited to a single log entry. It happens all the time with syslogd text logs too, people just don't discover them because syslogd doesn't have log file integrity checks.

      When journald discover such malformed entries, it log rotates as a simple preventive security measure.

      Sure, the journald log files are sensitive to real file corruption too (but so is syslogd log files), so clean unmounts of file-systems is a good idea (it always is). But the whole issue is massively overblown by people who doesn't use systemd anyway.

    51. Re:Watching systemd evolve by gweihir · · Score: 1

      You really have no idea how enterprise logging works. None at all. The binary logs of systemd are a problem for everybody except a small group of people that are too incompetent to handle small plain logs and have logs that are not large enough to need centralization. That is almost nobody.

      And yes, I have extensive experience with log analysis. You do not turn the logs into a database unless you are fully clueless. You extract what you need from the logs and _then_ organize that as your task requires, whether it is sorted, indexed, hashed, aggregated, etc. The log demon cannot know what you need. But I see now why this bad decision was made: Far too many people have no clue how to process large amounts of log-like data and these incompetents are asking for a tool to make it "easy".

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    52. Re:Watching systemd evolve by gweihir · · Score: 1

      Indeed. And if you pipe your logs directly into a database, you get this little thing called ACID, which apparently the systemd folks have never heard about. Their current solution is about the worst one possible. Closed, proprietary, unreliable. A "fair weather only" system that falls over dead as soon as the conditions are not ideal anymore.

      As to being paid for this propaganda trash, this person almost certainly is.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    53. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      contain rich meta-data....

      What a load of claptrap. People log to log files for reasons of the lowest common denominator. We have things called 'databases' for this kind of stuff and there's perfectly good reasons we don't use them for logging which should be obvious to anyone with an ounce of sense.

      Really, are you unaware how common it is to aggregate log files in databases? This is a major selling point for Rsyslog that it is able to do so.
      In fact, Rainer started Rsyslog exactly in order to overcome the many deficiencies with syslog(3), including the severe limitations of unstructured text files.

      systemd's journal is pretty much a stroke of genius in that it overcomes all the limitations of unstructured, unindexed text logs, while not being a full blown DB either (the journal files are basically appended text files with a different line delimiter and an index in front).

      Log files keep on growing every year, because people log more and more, and systems are running more and more daemons. Analysing such logs means machine parsing, and structured and indexed log formats like the journal have a huge advantage for this kind of work.

      Since the journald binary logging file format is stable and fully documented....

      I sincerely hope Red Hat and Lennart is paying for this piece of contrived PR.

      Ah, so now facts and reality is propaganda. Take a look here
      http://www.freedesktop.org/wik...
      and here (about the file journal file format)
      http://www.freedesktop.org/wik...

      The arguments against it are based on contrived scenarios

      Corrupted logs on a perfectly running system isn't a contrived scenario.

      It is when the corruption means squat for the ability to actually read the logs.

      For some reason you seem to think that "corruption" discovered by "journalctl" means the logs are unreadable, but as explained, they are often marked "corrupted" just because a single field value in a single log entry was discovered as impossible. This doesn't mean that the log file can't be read.

      ....through the Linux/Unix concept of piping.

      Piping eh? Wow. You give the impression you haven't heard of it before ;-).

      I don't care what you think, as long as you agree that the whole notion of not being able to use standard Linux text tools like grep together with systemd's journal is just plain wrong and a total non-issue.

      There just aren't any good arguments against structured, indexed log files that can be programmatically accessed and has rich meta-data.

    54. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      Disagree or not; logging directly to a full DB is very common, which is why it is a selling point for every commercial syslog implementation I know of.

      Regarding the indexing and structuring of log files, this is exactly what journald does. This dramatically reduces work needed to analyse them, even if you re-index them and convert them another structured file format like JSON.
      Working with indexed and structured files with defined field values, is always better than working with unstructured, un-indexed text files.

      systemd's journal log files will always have an advantage over the poorly defined syslogd text logs, no matter how you spin it.

    55. Re:Watching systemd evolve by MoonSweep · · Score: 1

      Red Hat Enterprise Linux have systemd starting with version 7.0

      You mean, the one which was released in June 2014 ?

      like SUSE Linux Enterprise Server

      You mean, the one which was released in October 2014 ?

      and Mageia

      With all due respect to their community, Mageia isn't what I'd call an "enterprise Linux distribution".

      The oldest "enterprise Linux distribution" which have systemd as default is RHEL 7, which was released 11 months ago. Sounds quite "unproven" to my sysadmin ears.

    56. Re:Watching systemd evolve by MoonSweep · · Score: 1

      if a disk is corrupting sectors where the logs (or anything) are being written, nothing will stop the corruption, not even syslog or rsyslog.

      That's why we use smartd.

    57. Re:Watching systemd evolve by segedunum · · Score: 1

      Really, are you unaware how common it is to aggregate log files in databases? This is a major selling point for Rsyslog that it is able to do so.

      No, I am aware but you're putting up a strawman there for obvious reasons. The point is that the lowest common denominator is always the plain text log file for reasons that this bug report makes clear.

      However, given that we can have the option to drop logs into databases or pipe and arrange them how we want kind of begs the question why we need the binary journald format. You're going to have difficulty squirming your way out of that one.

      Ah, so now facts and reality is propaganda.

      The bug reports on corruption ain't a piece of propaganda I'm afraid. You can shout from the hills that it is nicely documented as much as you want, but this remains a problem I'm afraid. I'm not the slightest bit interested in trawling through documentation so I can piece back together a log file that the logging system itself has corrupted. It's wheel spinning.

      It is when the corruption means squat for the ability to actually read the logs.

      1. journald is causing this corruption.

      2. What makes you think that plain text logs can't be read in the event of any corruption (which I have seen once in a blue moon by the way)? When you have a binary format the clue is in the name - you can read it or you can't. If you can't read it then it needs repaired, and one has to hope that the repair works. If it doesn't good luck.....

      For some reason you seem to think that "corruption" discovered by "journalctl" means the logs are unreadable, but as explained, they are often marked "corrupted" just because a single field value in a single log entry was discovered as impossible. This doesn't mean that the log file can't be read.

      In other words you haven't the slightest clue as to what this corruption is or where it's coming from. I can count on the fingers of one hand the number of times I've seen corruption in plain text logs and all of them have been down to hardware failure. I have always had a fighting chance of piecing together the low level plain text logs to find out what happened.

      As a sys admin I really don't give a shit and I'm not the slightest bit interested in washing it through a fsck system once I actually discover it or having to trawl through its format documentation so I can piece it back together. It's retarded.

      Quite apart from Freedesktop and systemd documentation generally being a constantly moving target.......

      I don't care what you think, as long as you agree that the whole notion of not being able to use standard Linux text tools like grep together with systemd's journal is just plain wrong and a total non-issue.

      It is when I have to pipe it through yet another application that generates corrupted logs.

      There just aren't any good arguments against structured, indexed log files that can be programmatically accessed and has rich meta-data.

      Apart from the fact that we can already do that (and we can use far, far more mature software than journald), and we can also have the low-level text logs available as a last resort to piece together what happened, I don't have to run a fsck on them and I don't need to trawl through its format documentation so I can piece them back together in the event of inevitable issues. No, nothing apart from that ;-).

    58. Re:Watching systemd evolve by segedunum · · Score: 1

      Indeed. And if you pipe your logs directly into a database, you get this little thing called ACID, which apparently the systemd folks have never heard about. Their current solution is about the worst one possible. Closed, proprietary, unreliable. A "fair weather only" system that falls over dead as soon as the conditions are not ideal anymore.

      It's bloody laughable isn't it? I can have the low-level text logs available and I can pipe into a database and aggregate and search as I want with a mature piece of software. But no, what we get is a completely new and totally immature piece of software and a new format that rolls over when there are problems.

    59. Re:Watching systemd evolve by segedunum · · Score: 1

      You misunderstand; there _isn't_ a "fsck" option for systemd journals and there won't be because that would be equivalent of "editing the log files".

      No, I'm not misunderstanding. You will need a repair option to make the logs readable. If there is not, they're left in a corrupted state which is just plain daft and is no use to anyone or you're leaving it to people to trawl through whatever format documentation there is to piece it back together. I have *never* had to do this with a text log file.

      I don't know where this 'editing' notion comes from. You can't edit them......they're binary. I'm relying on journald to keep these in a consistent format. Either give me a consistent and readable log file or get the fuck out of my way. Dead simple.

      Ahhhh, the whole 'disk corruption' misdirection. Yes, corruption could also be caused by solar flares, but this isn't, nor is it caused by a failing disk. It is caused by the journalling system itself. No investigation of this has happened, according to the maintainer 'it happens', we rotate and move on. Lunacy of the top order.

      You simply don't understand how journald works. Let me explain again

      Ahhhh, yes, the 'You don't understand' angle........

      The claptrap you've written there has nothing do do with the original comment and reply that I wrote - that somehow this corruption occurs because of other issues, namely disk corruption. This is happening on an otherwise perfectly running system.

      systemd marks certain log entries as "corrupted" if eg. they are plain wrong, that is the client is sending obviously wrong or malformed log entries.

      As a sys admin I'm not interested in what it is doing. It is producing corrupted logs regardless I'm afraid. I don't care how or why, but it does greatly concern me that journald is somehow deciding what is or isn't corrupted log data. Neither you or the tin pot systemd crew have any idea what logging actually means. That's not something for a logging system to decide and it's amusing that this is actually sanitising and 'editing' logs.

      Once again, either give me a consistent and readable log file that I don't have to wash through *any* further tools or get the fuck out of my way.

    60. Re:Watching systemd evolve by Jamie+Lokier · · Score: 1

      I make no defence of systemd, I only respond to implications that syslog doesn't have its own problems with lost and corrupt messages.

      Personally, I would prefer an investigation into why logs are being corrupted like this and a willingness to take it seriously rather than a 'corruption happens, rotate' attitude, but I'm just funny like that.

      Good engineering would be to do both, not assume it's to be one or the other. This thread seems to be derived from 'Lennart said if there's corruption we rotate', I didn't see anything factual about the frequency and circumstances of corruption compared between different logging systems. It is a fact in my experience that all systems experience it occasionally.

      You may know better than I do about systemd, which I don't currently use.

      For Linux systems where the power is cycled often without warning, I have to use other kinds of logging for some things because syslog is too unreliable.

    61. Re:Watching systemd evolve by Jamie+Lokier · · Score: 1

      That is not what I said. I never claimed that rsyslogd cannot cause corruption. I just claimed that there are not-so-rare cases where rsyslogd and alternatives work, while systemd causes corruption.

      If that's what you said I'm afraid it wasn't obvious to me. I took "Systemd causes log corruption where sane alternatives do not have such issues" at face value.

      In addition, the corruption by rsyslogd is usually what you describe, namely things cut short. With the binary log-format from systemd, the damage is far more extensive, so, yes, rotating them is "right", but having binary logs is deeply wrong in the first place.

      I don't know anything about journald's format, but if it suffers 'extensive' damage under challenging conditions that syslog handles fine then it's not an appropriate binary format for this job. That's not a fault of binary (which can be as robust as you want), that's a fault of the wrong kind of binary.

    62. Re:Watching systemd evolve by gweihir · · Score: 1

      Logging into a full DB has certain advantages, like ACID. Systemd does not offer them. Plain-text logging also has certain advantages, like easy aggregation and processing on entirely different systems with different OSes. Systemd does not offer this advantage either.

      Systemd is a "worst possible solution" with regard to logging. Somebody really had no clue when they designed this.

      And incidentally, you are the one "spinning" anything here (as you well know), since both proper DB and plain text are solutions that have been established a long time ago and have proven themselves. Systemd is doing some home-cocked thing that does nothing well.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    63. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      So now you are going from saying that people do not use DB's for logging unless they are clueless; (Let me quote you on this:)

      And yes, I have extensive experience with log analysis. You do not turn the logs into a database unless you are fully clueless.

      ..to that DB's can be a good thing?
      And please remember that ACID doesn't give any protection against file corruption, nor does it prevent user space programs corrupting the logs by generating obviously impossible field values. But then again, neither does the journal nor plain text logs.

      Again, for those who need to run a full DB for their logs, systemd's binary file format is great, because it allows the journal to be exported in industry standard formats like JSON. That way the remote log-sink database can receive and store rich meta data in a totally stable and structured way; changing hostnames, IP's, or even different wordings or even different and changing languages used by the daemon log output isn't a problem with the journal, since it is based on field values, not complex regex-ing of unstructured, undocumented, unstable, language specific words.

      Oh, and tamper proof, cryptographically "sealed" logs too (FFS) if you want that.

      If your remote log-sink solution isn't a full DB, you still gets all the benefits of receiving structured log entries with eg. full microsecond precision timestamps _and_ monotonic timestamps. It is trivial to convert eg. JSON output with defined field names to any other structured format, while converting and aggregating unstructured text files is a pain.

      It is also great for those who only needs local logging; the journal has many of the advantages of a full DB, but without the complexity and overhead. Its append based file format is also much more robust against file level corruption than databases. Since the log files are structured and indexed with field values, they are easy to perform powerful, yet simple queries on.

      How do you find all syslog entries with the priority level "error" generated by the previous boot only?
      With the journal it is : "journalctl -b -1 -p err"

      And how do you generate a full list of every executable, including their path?

      Since you can "tab" trough the values in the journal this can easily be done: "journalctl -F _EXE "

      And with the -x switch, the help database is activated, giving further explanation on what the log entry means, and gives direct links to upstream support, perhaps linking directly to a page that explains the error code etc:

      Example:
      # journalctl -b -x -u systemd-logind.service

      mar 07 16:46:16 localhost systemd-logind[546]: New session 1 of user Peter H.S.
      (log entry above, help database output below:)
      -- Subject: A new session 1 has been created for user Peter H.S
      -- Defined-By: systemd
      -- Support: http://lists.freedesktop.org/m...
      -- Documentation: http://www.freedesktop.org/wik...

      There are seriously many people who just trawls through long log files (even using vi apparently), because it is hard to grep for anything unless you already know what to grep for, and because regex'es are well, regex'es; difficult to use, understand and to remember all the many variations. Basically, newbies can't read or filter Linux syslog log-files by other means than trawling through them.

      They can't have a useful GUI either because it is impossible to make a distro-agnostic syslog gui. Again, a problem that systemd's journal solves.

      The bottom line is, that the only virtue syslog files have, namely that they are human readable, is a serious hindrance for their use too: they can't add monotonic timestamps and micro-precision timestamps and other meta-data without being excessively difficult to read for humans.

      With the journal you can give machine parsers exactly the structured log info they need and can benefit

    64. Re:Watching systemd evolve by Peter+H.S. · · Score: 1

      What I am saying is that what systemd calls "log database" is no such thing and massively inferior to the real thing.

      Please don't confuse the term database with a RDBMS or similar. A database can be a simple text file with structured data like /etc/passwd.
      http://en.wikipedia.org/wiki/F...
      systemd's journal is by any definition a database file and since it contains logging info, I fail to see the problem in calling it a "log database".

      I also _know_ that people that put logs into databases uses real databases, you know the ones that come with ACID.

      Some use ACID RDBMS, some use non-ACID NoSQL databases, etc. It all depends on needs and to why they collect the logs in the first place.

      What you do _not_ do is change the on-machine logs into a wannabe-database. That is about the worst thing you can do.

      You are of course wrong about this, Enterprise log analysers like Splunk uses simple files and indexes to store events etc. pretty much the same way that systemd does.

      There is considerably overhead when using ACID RDBMS', so when things needs to be really fast you do stuff like systemd and Splunk does. Logstash (probably one of the more popular log-analysers) doesn't use a ACID compliant RDMBS as backend either (though it can if you want to).

      The point is that the world of logging and databases have moved on considerably the last decade. The primary reason being more and more data that needs to be analysed (fast) for one reason or another (Business, real-time security etc.).

      systemd's journal is a pretty significant upgrade to the otherwise rather fossilised world of Linux logging. Don't get me wrong, I have tremendous respect for the Rsyslog team, but they have been struggling for over a decade to solve just some of the problems systemd's journal now have solved.

      And I have have never really seen any good argumentation against using binary, structured and indexed log files:

      They can be read by all standard Linux text tools with piping.
      There exist multiple independent readers for them.
      The logs can be programmatically accessed through a myriad of languages.
      They provide functionality that can't be matched with legacy syslog files.
      There is no non-contrived scenario where they can't be read one way or another.
      They can be exported in any format and have default export options for all relevant industry standards.
      Unlike syslog output, they have a stable and documented API.

      So there isn't any real downside to using binary journal log files, while there is considerably advantages.

    65. Re:Watching systemd evolve by devent · · Score: 1

      1. my impression is that systemd is just more transparent about it, because syslog just drops the corrupted log entries silently.
      2. that is just wrong. journald just rotates the log files, nothing is lost. journald shows all partials log files together as one journal:

      http://www.freedesktop.org/sof...

      If called without parameters, it will show the full contents of the journal, starting with the oldest entry collected. [...] Output is interleaved from all accessible journal files, whether they are rotated or currently being written, and regardless of whether they belong to the system itself or are accessible user journals.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    66. Re:Watching systemd evolve by devent · · Score: 1

      Are you joking right? You are saying that it is in production use for 11 months, and it had about 2 years of testing in Fedora, and that is "unproven"?

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    67. Re:Watching systemd evolve by MoonSweep · · Score: 1

      Is Fedora used by (serious) system administrators on servers in corporate environments ? No, so these 2 years of "testing" are moot concerning the viability of systemd on enterprise-grade Linux distros. As for the 11 months of RHEL, serious administrators (meaning, the ones who actually understand what's going on under the hood and are able to investigate problems and report bugs) never rush on a new release of their installed distros, so I'm quite inclined to think that compared to RHEL/Centos 6 (or even 5), the pool of RHEL 7 installed on actual production servers is still very tiny. So yes, in regard of actual production environments, systemd is still largley "unproven".

    68. Re:Watching systemd evolve by devent · · Score: 1

      You are free to use RHEL 6 or any other distribution that don't use systemd if you think it is unproven. You can even deinstall systemd on RHEL 7 and continue with sysvinit. PS: nice no true Scotsman fallacy.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    69. Re:Watching systemd evolve by MoonSweep · · Score: 1

      This answer only proves what people say about the pro-systemd people's bad faith. You clearly pretend to misunderstand the point of my post.

      So (I'll bite) to be clear, I wasn't saying that RHEL 7 is mandatory, or that systemd is mandatory in RHEL 7, but only that systemd hasn't been thoroughly tested in the real world yet. I'm sick of pro-systemd people harping on about systemd being mature because it's now the default in so many distros used by so many people since so many years, blah blah blah. None of the distros which ships systemd as default for more than a year is used in a serious corporate environment.

      Most job offerings I see ask for RHEL/CentOS skills. Next comes Debian, then Ubuntu, and occasionally SLES. Only once in my career I had an job interview in a company which used an infrastructure based on Gentoo; but I never ever saw a job offering asking for Fedora or Arch skills, let alone OpenSUSE or Mageia.

      So stop the bullshit about systemd being ready for prime time. it may be so for personnal or SOHO infrastructures, but in the real world of enterprise-grade distros, it still has to prove it's stable, secure and properly working as expected. I don't say it's not, I say it still has to be proven.

    70. Re:Watching systemd evolve by devent · · Score: 1

      That is your opinion. I wrote reasons why I think it is proven and obviously a lot of Linux distributors think that, too. Lets assume you are correct and it is unproven and will break in RHEL 7 and a lot, if not all, customers will get very angry with Red Hat and switch to sysvinit or stick to 6 or switch to a different distribution or to Windows. Do you think Red Hat will live with that risk? So, why would Red Hat use systemd in their enterprise distribution if they not think it is ready? Red Hat, Inc. is even a publicly traded company and since May 2014 their stock continues to grow in value, i.e. there is no sign that customers are running away from RHEL 7.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    71. Re:Watching systemd evolve by MoonSweep · · Score: 1

      [...] and since May 2014 their stock continues to grow in value, i.e. there is no sign that customers are running away from RHEL 7.

      Ah, because Red Hat's stock value is entirely based on RHEL 7 ?

    72. Re:Watching systemd evolve by devent · · Score: 1

      I have the impression that it's their core business. My point was that Red Hat is publicly traded and thus they are much more transparent than private businesses and the value of their stock reflects the performance.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
  4. Goodbye, Ubuntu by drinkypoo · · Score: 1

    I've been a user since Dapper Drake. Later, gator.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:Goodbye, Ubuntu by Penguinisto · · Score: 1

      All the sudden I don't feel so bad about using OSX as my primary personal laptop (where I can keep pre-systemd CentOS 6.6 on a VM until the heat death of the universe...)

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    2. Re:Goodbye, Ubuntu by fisted · · Score: 1

      Yes.

      --
      CLI paste? paste.pr0.tips!
    3. Re:Goodbye, Ubuntu by bhcompy · · Score: 1

      The fact that you stayed into Unity shows that you're lying and going to continue to stay.

    4. Re: Goodbye, Ubuntu by buchanmilne · · Score: 1

      So sysv init (or bsd init) isn't good enough for your desktop, why is it (or in actual fact, upstart in sysv compat mode) good enough for servers (where some of its features are more useful). Or do you want to duplicate configuration or functionality by running an 'init' system which basically has no useful features during the majority of time it is running and a supervising system (which doesn't integrate at all with supplied diatro packages)?

      Do you really like the fact that all distros require separate scripts (e.g. some that use /etc/rc.d/functions for RH-derived distros, other scripts that work on Debian-derived distros, others for SUSE, Arch etc., because sysv init basically has no useful features and all distros implemented the missing minimumfunctionality differently?

    5. Re:Goodbye, Ubuntu by drinkypoo · · Score: 2

      The fact that you stayed into Unity shows that you're lying and going to continue to stay.

      The fact that you haven't heard of lubuntu or xubuntu shows that you're an ignoranus who should shut his cakehole.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Goodbye, Ubuntu by drinkypoo · · Score: 1

      I left years ago when they decided to not give a fuck about good display support. Someone sure has the blinders on.

      Since I have an nVidia card, I'm really not having any problems. I recently upgraded from a 450GTS OC to a 750 Ti (per Slashdot groupthink) and continue to not have problems there.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    7. Re:Goodbye, Ubuntu by Lord+Apathy · · Score: 1

      You need to get caught up on modern theories. The big bang and the head death of the universe is old news. The hot new theory is the universe had no beginning and will have no ending.

      Wait? Haven't we heard that before?

      --

      Supporting World Peace Through Nuclear Pacification

    8. Re:Goodbye, Ubuntu by hitmark · · Score: 1

      Launchd is nowhere near as sprawling as systemd.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    9. Re:Goodbye, Ubuntu by hitmark · · Score: 1

      Maybe at first. But by now it has outgrown launchd massively.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
  5. beta lovers use systemd by surd1618 · · Score: 1

    and liked the new star trek movies

    1. Re:beta lovers use systemd by ArcadeMan · · Score: 1

      and their favorite movies are Event Horizon and Battlefield Earth.

      --
      Get free satoshi (Bitcoin) and Dogecoins
    2. Re:beta lovers use systemd by gatkinso · · Score: 2

      What was wrong with Event Horizon?

      --
      I am very small, utmostly microscopic.
    3. Re:beta lovers use systemd by Penguinisto · · Score: 1

      Ditto sibling... Event Horizon was campy as hell and even funny at times - I actually liked that movie.

      Now Battlefield Earth? It and all of its Hubbardite followers can all die in a fire.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    4. Re:beta lovers use systemd by Anonymous Coward · · Score: 1

      What was wrong with Event Horizon?

      Everything

    5. Re:beta lovers use systemd by ArcadeMan · · Score: 1

      The first half was a very good science-fiction movie, reminded me a bit about The Black Hole from Disney.

      The second half was a bad horror movie.

      --
      Get free satoshi (Bitcoin) and Dogecoins
    6. Re:beta lovers use systemd by fahrbot-bot · · Score: 5, Funny

      The first half was a very good science-fiction movie ... The second half was a bad horror movie.

      So, just like systemd then.

      --
      It must have been something you assimilated. . . .
    7. Re:beta lovers use systemd by jcarr · · Score: 1

      I don't think you are being fair to science fiction by tossing out Hubbard or Battlefield Earth. Hubbard did write some interesting science fiction & Battlefield Earth isn't terrible either. If you ignore the whole scientology shit show, from a purely SF perspective, I'd say both are average or above average.

  6. Floating by Anonymous Coward · · Score: 1

    This systemd mess has me floating now. I've been just using windows since Debian announced they were switching to systemd. I haven't really been investing any time in Linux on the desktop at all. But I am lost. No idea where I'll end up at this point. All I know is, I am not interested in Gnome 3 or systemd. Any operating system that is aligned with these two things is not currently a candidate for my home.

    1. Re:Floating by Lord+Apathy · · Score: 2

      This systemd mess has me floating now

      Yeah, that was me for awhile. Systemd has it's problems but over all I've not seen any real issues with it that didn't just simply involve me learning a new way of doing something. I've been using fedora, now 21, on my desktop at work for 2 years now. I've not really seen any issues at all with the it doing its job. Infact fedora 21 has been the best workstation OS I've used.

      I was against systemd for a while, I'm still kind of iffy on some of the issues it has. I don't like binary logfile over ascii log file. I've stated my reasons for that before.

      Over all systemd is a new way of doing things, and I think that is a lot of the resistance to it. Init is 20 years old, might be time to try something new.

      --

      Supporting World Peace Through Nuclear Pacification

    2. Re:Floating by gweihir · · Score: 2

      While trying something new can have merit, throwing away the old, reliable and perfectly usable alternative is not. And that is what systemd is trying to force people to do.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Floating by Lord+Apathy · · Score: 1

      Sticking to old and reliable has it merts too but not when it gets in the way of trying something new. Change for changes sake is seldom good but sticking to the old an familiar just because its familiar is seldom good too.

      Being forced to change can be called evolution. As technology progresses there will always be a forced change to adapt to the new technology. Init is 20 years old, its old, and reliable but it will stand in the way of new and better ways to do things. An like it or not linux is moving away from its unix roots. It will have to do that to survive and continue to be a usable system.

      Init has, had a 20 year run. That is a good run for any system.

      --

      Supporting World Peace Through Nuclear Pacification

    4. Re:Floating by Barsteward · · Score: 1

      why not go back to life before "init" if you are against progress?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    5. Re:Floating by Barsteward · · Score: 1

      its not thrown away, its still there is you want it. if you can't manage it yourself, move to Slackware or Gentoo, thats the beauty of the linux ecosystem.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    6. Re:Floating by Anonymous Coward · · Score: 1

      I'm not against progress, I'm against blindly replacing things with incomplete crap "because progress". Progress isn't "replace everything old because it's old", progress is "make things better". This is just like Gnome3 - if they'd waited to replace the old system until the new one was actually, you know, finished, there wouldn't have been so many people angry about it. Instead, they ripped out the old one and replaced it with half of a new one, then idiots like you started accusing anyone who didn't like that the replacement wasn't actually complete or working properly of being "against progress".

      systemd doesn't make things better, it makes them pointlessly complicated, more likely to crash, and harder to debug when they do. (ie: binary log files, the stupidest derp in the whole pile)

    7. Re:Floating by gweihir · · Score: 4, Informative

      Init is still good for many applications (and completely satisfactory for server use). If somebody tries to prevent me from using it or to make that hard, then these people become an enemy. The systemd crowd qualifies.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Floating by gweihir · · Score: 2, Insightful

      Simple: I am not against progress if it has merit. Systemd has none.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:Floating by Lord+Apathy · · Score: 1

      Nonsense. Nobody is any ones enemy here. Just people with different points of view.

      Init is still good for many things. I still use it on my personal server at home. I imagine that it will be good for another 5 years or so. But, still there will come a time where init will hold back development in the server market too.

      --

      Supporting World Peace Through Nuclear Pacification

    10. Re:Floating by gweihir · · Score: 1

      I think it has moved far, far beyond that and the systemd folks are enemies of choice in Linux. As choice is a core principle in Linux and FOSS, these people are enemies of Linux itself.

      And different from you, I see absolutely nothing limiting the useful lifetime for init. In fact, it will likely be good until computing changes completely, and that may be centuries in the future.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:Floating by dbIII · · Score: 2

      On Fedora systemd updates managed to break zfs startup so now I just login as root via the command line and mount the drives instead of second guessing which change will break it next time.

    12. Re:Floating by gweihir · · Score: 1

      You overlook that "merit" is not a list of features, but an overall appreciation. Complexity has a price, and here it is far too high. You also seem to be unaware that everything you list is either available in other forms or not important, some of them both.

      Really, even though a great deal of effort is spent by the systemd fanatics top obscure the fact, it has no merit.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    13. Re:Floating by Barsteward · · Score: 1

      well as you seem so negative about systemd. why not create and publish a report comparing all the features of systemd and various other init systems as you see them and what your solution is to counter all the systemd features and stand up and present it to Red Hat et al and make your case? Get some of the anti-systemd supporters to help. so far all i've seen from the anti's is personal opinions of systemd and personal attacks on the developers, nothing really technically decisive only misinformed comments touted as "information"

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    14. Re:Floating by Barsteward · · Score: 2, Insightful

      anti-systemd attacks have no merit, they are just a list of vitriolic personal attacks on the developers and lies about what systemd does or can do.

      If systemd had no merit, it would not be adopted by so many distros

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    15. Re:Floating by thegarbz · · Score: 1

      Complexity has a price, and here it is far too high.

      Quantify that point for us. What price is too high for complete system management that simplifies many of the tasks of getting a system to run?

      Oh you mean complexity in a piece of software? Well fortunately that price is exclusively decided by the software maintainer. For the rest of systemd actually simplifies the entire system making starting applications easier, chasing log files easier, managing hardware events easier, the list goes on.

      You are of course right. Complexity has a price, and that is exactly why so many distributions are opting to adopt systemd.

    16. Re:Floating by thegarbz · · Score: 1

      As choice is a core principle in Linux and FOSS, these people are enemies of Linux itself.

      And you are free to chose any distribution you want. You are also free to create your own at any time and set it up just the way you want. And of course you're free to come and moan on forums that your favourite distro is disagreeing with your choice.

      But that is actually where your choice ends. You do not have a choice of every component of every distribution. If you did we wouldn't have distributions. A Red Hat developer a few years ago said that "choice" is a meme of Linux that has to die as every choice provided to the end user creates a mountain of work for a maintainer and even more for a developer.

      So you don't like systemd. What's your favourite distribution? Debian? Then how about you stop moaning and actually get behind the Devuan project. They could use donations / developers. They have realised that the existance of a package in linux doesn't magically remove choice and are doing something about it.

      So you can start working with alternatives, or you can whine on Slashdot. That's your choice.

      By the way computing well and truly has changed every 5-10 years or thereabouts. You may want to broaden your view a bit if you've missed the fact that most of us now use computers in a very VERY different way.

    17. Re:Floating by hitmark · · Score: 1

      Want to try something new in init, go with openRC or similar projects that do init and init only.

      One may wonder when Gnome will announce that the project will be renamed systemd-gnome, and the code of its projects will be merged with that of systemd.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    18. Re:Floating by gweihir · · Score: 1

      Nice propaganda piece. Utterly dishonest and ignoring the facts of course, like all systemd propaganda. You people have gotten extremely repetitive a long time ago.

      I will not even bother addressing any of your "arguments", as they are all pretty transparent. Only one thing: If "choice" dies in Linux as you predict, then Linux dies. Surprisingly, everybody except Red Hat seems to have managed fine until now. I think who actually needs to die is Red Hat.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    19. Re:Floating by gweihir · · Score: 1

      You just live on in you fantasy world, but I will just name you an enemy of freedom and choice in Linux.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    20. Re:Floating by gweihir · · Score: 1

      Fascinating. Pure propaganda of course.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    21. Re:Floating by gweihir · · Score: 1

      Nice inversion. Init is the status quo, systemd is the intruder. Hence anybody sane would require the systemd proponents to do what you claim I should do. (And nice rhetoric trick to portray me as individual while your side is of course a large and powerful group, when no such thing is true.)

      Of course this is a well-known tactics: Cannot defend what you want? Make the other side defend theirs! Face opposition? Claim these are are all somehow disturbed individuals only expressing personal opinions of questionable merit, with no common ground while the proponents of the "thing" to be pushed are an unified movement with large numbers and deep wisdom. Need to lie to justify the "thing" you are pushing (and for systemd you need to lie a lot)? Simple: just claim the other side is lying all the time. Oh, and require the other side to somehow fight "honorably" ("make your case"), when the side pushing the "thing" could not be farther from doing so itself.

      But thanks for confirming basically everything in my original analysis. The greatest achievement for any PsyOps campaign is of course to recruit a large number of "useful idiots" that push their agenda for free. I do of course not know whether you are paid to lie or are just an useful idiot.

       

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    22. Re:Floating by Eunuchswear · · Score: 1

      Nice inversion. Init is the status quo, systemd is the intruder.

      In your haste to bash systemd you seem not to have noticed that we're talking about Ubuntu adopting systemd. init isn't the status quo, upstart is.

      --
      Watch this Heartland Institute video
    23. Re:Floating by LesFerg · · Score: 1

      If you are happy using Windows, my guess is you probably wouldn't have even noticed the change-over in Debian.
      Did you even try it? Did you have some amazingly complicated problem that made your computer unusable? Did the sun stop rising in the morning?

      Nothing is any different for me using Debian with systemd. If you don't have the need to tweak start/stop scripts or mess with default configurations then you most certainly won't have any issues. Isn't that the primary reason people used to praise Ubuntu? Installing and using it without having to edit text files, seems to be one of the good points people talked about.

      The only serious complaint I have read by anti-systemd folks appears to be those responsible for setup and maintenance of complex servers or non-standard hardware combinations, where they rely on a lot of custom coded config files. The rest just seem to be parroting nonsense and hate without any proof that they have even experienced an actual bad problem from using it.
       

      --
      If I had a DeLorean... I would probably only drive it from time to time.
    24. Re:Floating by thegarbz · · Score: 1

      Fascinating. Pure propaganda of course.

      I wish I had you on my debating team in highschool. I could have saved myself having to go at all.

    25. Re:Floating by thegarbz · · Score: 1

      I will not even bother addressing any of your "arguments", as they are all pretty transparent.

      You should be a CEO. It's amazing how little you can say while actually still typing otherwise coherent sentences. You win. Have a pay rise oh mighty knowledgeable one.

      If "choice" dies in Linux as you predict

      It's not a prediction. It's an observation. Most distros just are and provide very little choice. In some cases they are so heavily fixed that they provide multiple different releases for each major component. I.e. Mint comes in 4 flavours for different DEs, Ubuntu comes in 4 flavours for different device types, Red Hat just is, and while the most part you're usually free to install what you want on distributions, this often comes at the price of support and will result in a long trip down the bug tracker to get something different working.

      There are notable exceptions: Gentoo, and LFS being about the only ones.

      But for the most part the only choice you have in Linux is a choice of a distribution or a choice to roll your own to begin with. But hey I don't need to convince you of this. If you think otherwise just tell Red Hat what you want, and then see if you get a response from the developers that goes something like: Linux is not about choice

  7. Bug report by Anonymous Coward · · Score: 2, Funny

    The bug is systemd.

  8. Dumped for BSD by Anonymous Coward · · Score: 1

    Linux has become an utterly chaotic mess that isn't fun anymore because most of my time is spent relearning the bullshit that comes with software designed by consensus. I haven't had fun with it in several years, and I've been there since the beginning, in the 90s.

    Switched to OpenBSD and FreeBSD for my solutions and haven't looked back.

    1. Re:Dumped for BSD by serviscope_minor · · Score: 3, Insightful

      Linux has become an utterly chaotic mess that isn't fun anymore because most of my time is spent relearning the bullshit that comes with software designed by consensus

      Actually Linux always was an utterly chaotic mess and that's precisely what made it so fun. It's the waves of Windows envy followed by waves of Mac envy which have sucked the fun out of it.

      Still it's all relative and I'd rather use Linux than one of the more commercial offerings by a very long way.

      --
      SJW n. One who posts facts.
    2. Re:Dumped for BSD by kthreadd · · Score: 1

      Well, there is no operating system anymore called BSD. BSD was around back in the 80's and early 90's. The free software operating systems that end in *BSD are not one operating system, and they don't share the kernel like the Linux distribution do. They are simply distinct operating systems that has a common historical heritage.

      There are at least two alternatives for virtualization on FreeBSD, VirtualBox and Bhyve. I've never used Bhyve but it's designed similar to KVM on Linux.

  9. What is systemd exactly? by ArcadeMan · · Score: 4, Interesting

    Can someone explain to us Windows and OS X users, without using acronyms and Linux-only mumbo-jumbo, what exactly is systemd and why do we keep hearing so much about it?

    Telling us to go read a wikipedia page probably won't help because it will be either too long to read, too complex or require knowledge about other topics to understand.

    --
    Get free satoshi (Bitcoin) and Dogecoins
    1. Re:What is systemd exactly? by Anonymous Coward · · Score: 3, Informative

      It's a system for managing the start, stopping and restarting of system services and a whole other slew of important system tasks. Unlike previous init systems, it does its job significantly better.

      Unfortunately slashdot is filled with armchair sysadmins who are upset they'll have to learn something new, while the real sysadmins are out their already using systemd in production. More systemd, I say.

    2. Re:What is systemd exactly? by Anonymous Coward · · Score: 4, Interesting

      Don't forget that SystemD also has integrated into it, boot manager(not INIT, think GRUB), DHCPD, DHCP, an actual NAT, Firewall interfacing, keyboard culture, time settings, USB notification. etc etc. At one point, if your logging didn't work, it broke your keyboard so you could not terminal in. Don't you love it when two unrelated services with no logical dependencies can some how affect each other?

    3. Re:What is systemd exactly? by Anonymous Coward · · Score: 1

      For the Windows users: think of it as SVCHOST.EXE ...
      It finally brings the joy of having to reboot after minimal system updates to Linux.

      For the MacOS users: it wanted to be a copy of launchd, not it became the MCP.

    4. Re:What is systemd exactly? by Anonymous Coward · · Score: 2, Informative

      As an OS X user, you know it as launchd.

    5. Re:What is systemd exactly? by Anonymous Coward · · Score: 5, Informative

      I am not especially well versed in the systemd vs sysinit issues. However, it is my understanding from reading other posts and articles on the issue is that those who are complaining about systemd are concerned unhappy with the non-linuxy way systemd approaches system process management.

      What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.

      That is my understanding looking in from the outside.

    6. Re:What is systemd exactly? by blue9steel · · Score: 5, Informative

      The init system handles the initial startup of a linux os. It's been acknowledged for some time that it has some limitations, especially in terms of threading and dependency management but for the server world that's usually not that big a deal since the primary users are technical specialists who are comfortable mucking around with that sort of thing. For desktops and mobile devices though those are more serious concerns because they impact user experience and many users don't have the skills to modify things themselves. Systemd is a replacement for init.

      PROS: It has faster boot time and more sophisticated dependency management

      CONS: It's new (which means lots of people who understand the current system will have to relearn how things work), it's harder to directly customize (requires a higher level of skill to modify), it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.

      In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.

    7. Re:What is systemd exactly? by Anonymous Coward · · Score: 1

      As a Windows user, picture one executable that runs as LocalSystem

      SystemD is not one executable but each service runs as its own subprocess. Even Windows Service Host is broken down into smaller pieces, try tasklist /svc in PowerShell.

    8. Re:What is systemd exactly? by Anonymous Coward · · Score: 1

      It's a shambling sprawling piece of bloated excrement that should have been aborted.

      Every Linux kernel variant that is infected with systemd dies a horribly agonizing death as anyone with any experience stops using that variant due to systemd's complete lack of transparency, myriad of binaries that haven't undergone a single security audit, going the opposite way of what an init based system should go.

      Any worthy init replacement would shrink, do less, not bloat like a dead hog during the summer, trying to do more, overreaching itself causing system instability while lowering system security.

    9. Re:What is systemd exactly? by Anonymous Coward · · Score: 2, Interesting

      At one point, if your logging didn't work, it broke your keyboard so you could not terminal in.

      Source? A quick google of "systemd logging keyboard issue" didn't turn that up.

      I've only recently started trying CentOS 7, so I'm still getting a feel for systemd, but I haven't had a lot of problems doing the stuff I usually do in 6.x - first time I try something I might have to google it, otherwise no real issues.

    10. Re:What is systemd exactly? by macs4all · · Score: 1

      Plus the joy of not being able to tell what process is using all the RAM/CPU because they're *all* called svchost.exe according to the task manager... except for the ones that are viruses, which are called scvhost.exe

      ...and because of that little fact, most AV apps won't delete a virus so-named.

      Isn't Windows wonderful?

    11. Re:What is systemd exactly? by jedidiah · · Score: 1, Troll

      > Unfortunately slashdot is filled with armchair sysadmins

      Nope. Slashdot is filled with people that have been using multiple Unixen since the 80s as well as genuine sysadmins of various kinds. Many of us find systemd problematic just because of the way it's designed.

      The term "defective by design" comes to mind.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    12. Re:What is systemd exactly? by Gr8Apes · · Score: 2

      In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.

      I'd say in short, it sounds like a terrible idea. If it takes something that people already have issues dealing with because it's too complicated, and makes it more complicated and non-standard to boot, what's the benefit? And binary log files? I must be missing something here. Haven't run a "new" Linux server in a year, so haven't really dealt with nor read anything on systemd at all, other than to know there's a large contingent of folks that don't like it, have lots of reasons for hating it, and the "pro" side is "just because we like it". BSD could be solidly in my future for the next rollout if systemd sucks even half as badly as detractors claim, although I can guarantee I won't need to make that call anytime soon as current systems planned and running will remain on pre-systemd releases for the foreseeable future, so someone else can take all those hits with the inevitable bugs and failures that will ensue.

      --
      The cesspool just got a check and balance.
    13. Re:What is systemd exactly? by ledow · · Score: 4, Interesting

      Collate all the thousands of customised, random and disparate init scripts that start up the system (what services to run, in what order, when to mount the filesystem, how to do so, what flags to use, how to tie it all in so you boot properly every time, etc.) into a handful of huge binaries that do some clever magic to do roughly the same job (maybe quicker, maybe more reliably, maybe not - there's evidence both ways depending on the usage case in question).

      The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems. Systemd is tying into everything from initial boot to how to configure your soundcard.

      On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.

      It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.

      I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.

      On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.

      More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.

      It doesn't help that personalities on both sides fan the flames in the heated debate.

    14. Re:What is systemd exactly? by macs4all · · Score: 3, Informative

      As an OS X user, you know it as launchd.

      And all the people whining about how systemd is the ruination of all that is hole-y in Linux conveniently ignore, OS X switched over to launchd (from its previous use of init rc, IIRC) way back in the 10.4 (Tiger) days.

      And guess what? Virtually no one noticed. The sky didn't fall. Legions of OS X admins didn't crawl out of their holes to proclaim that the switch to launchd (which, BTW, Apple created and Open-Sourced, thankyouverymuch) was the end of civilization as we know it, blah, blah, woof, woof.

      Linux fans are SUCH luddites...

    15. Re:What is systemd exactly? by houghi · · Score: 1

      The speed of boottime is a dick-size contest at best. As soon as boot times are below 1 minute, it isn't relevant anymore. The process of typing login and password takes longer.

      And if boottime is a serious issue, don't shut down at all. You can put the machine to sleep and go on with what you were doing the next day.

      The ONLY moment I reboot is when I need to (e.g. new kernel). Otherwise I use suspend or hybernate.

      I even use it instead of a screensaver.

      So yes, faster boottimes, but how much faster? How much time do you gain really? Reading one article here will make you loose what you gained for a month. (Invented statistic). Writing this is the same as the time gained in difference in a year.

      --
      Don't fight for your country, if your country does not fight for you.
    16. Re:What is systemd exactly? by Anonymous Coward · · Score: 1

      OS X admins

      Hahahaha!

    17. Re:What is systemd exactly? by Marginal+Coward · · Score: 1

      Here's a related question I have as someone who doesn't use Linux: if systemd is so terrible and arouses so much ire, why does it seem to be appearing in almost every major Linux distribution?

      Without knowing anything about it besides what I read here, the only way to reconcile this paradox seems to be that the hatred is coming from some small vocal minority, but there is a less vocal but more powerful majority (such as distro makers) who think it's a good thing. Is that true?

    18. Re:What is systemd exactly? by PPH · · Score: 4, Interesting

      then you need to know that "sudo service apache2 restart" is now "sudo systemctl restart apache2" (probably) and that is about all you need to know.

      But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.

      Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.

      Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.

      *Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.

      --
      Have gnu, will travel.
    19. Re:What is systemd exactly? by hawkeey · · Score: 2

      It depends how well you know Windows or Mac OS X.

      systemd is roughly equivalent to Window's svchost / Services [1] or Mac OS X's launchd [2]. Maybe if you remember DOS, it's kind of like autoexec.bat / config.sys (shudder). systemd is meant to replace the init system in Linux.

      Right after your computer boots and loads the hardware interface (the kernel), systemd or init is the first program that starts that is meant to start all the other programs. Traditional UNIX philosophy is to keep things extremely modular and simple. Each piece of software should do a single job and do it well. Furthermore, it should easily work with other modular programs. The controversy is that systemd has a tendency to expand in scope. While it has various subsystems and modules internally, it is trying to do "everything".

      The motivation for systemd is that modern systems have many services which need to interoperate, particularly at boot time. The old init system would start each service sequentially, one right after another. Modern systems now have multiple-cores and it would be advantageous in time to start services in parallel to take advantage of multiprocessor systems. In order to do this, there is a dependency graph problem where you have figure out which processes can start in parallel and which one depends on the others. For example, before you start a web server, you probably want to make sure that that the Internet connection is up. This problem has been solved and part of the solution was retrofitted onto init. Systemd, however, also wants to supervise services as they are running and possibly respond to events. These features are more important to laptops which boot frequently and change environment. Servers, however, boot infrequently and exist in relatively static environments where the additional complexity of systemd might cause an issue.

      Windows and Mac OS X have embraced solutions similar to systemd earlier to take advantage of tighter integration and also partly due to development being centralized. Linux development is more distributed and many would prefer it to be more modular and simple. The fight over systemd is a philosophical debate about whether the core services in Linux should be centralized and integrated or highly modular and simple.

      The dichotomy is false, however, as what is really needed is specialized configurations for different situations. What people are squabbling over is whether generalized solutions should lean towards supporting their specialized application (stable servers vs flexible laptops). The distributions which package software have been leaning towards systemd to support both, but those interested in servers see little advantage, greater complexity, and more security issues in systemd than in the previous init system.

      In summary, systemd is a replacement for the first process that starts in Linux that is supposed to provide core services. At the cost of simplicity, systemd integrates many services internally. The disagreements over this are philosophical and are about people fighting over the direction of generalized solutions rather than working towards optimal solutions for their specific needs.

      [1] http://en.wikipedia.org/wiki/S...
      [2] http://en.wikipedia.org/wiki/L...

    20. Re:What is systemd exactly? by Gr8Apes · · Score: 1

      These Linux distros must have watched MS's registry cause lots and lots of service contracts and work. Even though the registry isn't hard to understand or work with, the sheer amount of crap shoved into it and its constant morphing for any system change make working with it challenging enough that most won't do it. Undoing a bad install of Oracle 8 on Windows 2K Server so it could be reinstalled, for instance, was loads of fun as you tracked down every single badly inserted key. Other apps and malware especially require similar work in cases where the uninitiated don't have backups. There's a case to be made for individual startup files, it's easy to see what changed when, and to only backout or replace that set of items instead of corrupting the entire binary POS (a la the MS registry). Somehow, I get the feeling that systemd is closer to that latter vision and will raise the bar for true system operators, while possibly allowing the currently unemployed Windows certified sysop to take over some Linux boxes too, much like exists in the MS world.

      --
      The cesspool just got a check and balance.
    21. Re:What is systemd exactly? by mrchaotica · · Score: 2

      If you have any reason to care how long it takes for your server to boot, you're already doing it wrong.

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    22. Re:What is systemd exactly? by Gr8Apes · · Score: 1

      We get that with every new MS OS release (Win Vista: whole new user subsystem, Win7: fixed a bunch of Vista's issues, Win8: whole new interface etc, Win9: oops, missed the date we'll call it Win10: revert a bunch of Win 8's issues, cross their fingers, and hope and pray that the enterprise will embrace it like they did Win7.

      --
      The cesspool just got a check and balance.
    23. Re:What is systemd exactly? by jedidiah · · Score: 1

      If systemd were actually what you are describing there, then there would be much fewer objections to it.

      You are ridiculously misrepresenting the situation.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    24. Re:What is systemd exactly? by vux984 · · Score: 5, Insightful

      what exactly is systemd and why do we keep hearing so much about it?

      Part of the problem is that its poorly defined. It's touted as a replacement for the init system. (The system that manages other services. So for a windows user it's core functions as the services host process -- its where you can start and stop services, determine which startup at system startup. Stop them. See which are running. Restart crashed services, etc. It does startup in parallel so it's faster than the traditional init system.

      But doesn't just replace init, it relplaces cron (the task scheduling system -- "scheduled backups and such" not "cpu thread scheduling"; it replaces the event logging system, it replaces the login system...

      The unix philospophy is for components to be small and do one thing well and to to let users build a system out of the different pieces they want. systemd is big and tightly integrated and more of an all-or-nothing and that rubs a lot of people the wrong way.

      And the main valid criticisms of are (IMHO)

      1) Binary logging -- the advantages of the systemd logging system are apparent, but there are disadvantages too; users should have

      2) It potentially creates a layer between kernel and the rest of the system that becomes entrenched and irreplaceable. As applications going forward will develop dependencies on the rich services of systemd it will become impossible to replace systemd with anything else, except maybe a fork of systemd. (This rubs a lot of people the wrong way.)

      3) the rich service layer and tight integration stifles innovation; for example assuming systemd has traction someone can't make a "better cron" now, because that functionality is part of systemd. They can't make a better init-only system because applications will be relying on all the other services of systemd.

      4) it gets between the rest of the system and the kernel, and in many cases you have to work through systemd and can't just go to the kernel. This has its good points, but also its problems and further entrenches systemd.

      Perhaps GNU/Linux systems with systemd should properly be called GNU/systemd/Linux systems to emphasize the point.

      I don't personally hate systemd; I recognize a lot of thing it does are good for large parts of the linux user base. But I do agree with the 'haters'; that its not modular enough and that leads to several valid complaints.

      I doesn't help that the egos involved on all sides are large and uncompromising.

    25. Re:What is systemd exactly? by Anonymous Coward · · Score: 1

      Since when is the linux community capable of authoritatively academic sources? If systemd borks, everything goes with it. That is enough for anyone that cares about integrity to not use it.

    26. Re:What is systemd exactly? by devent · · Score: 1

      Can you define "SystemD also has integrated into it"? Because that what you have listed are independent daemons that offer functionality and are not "integrated" into systemd. The only "integration" you have is the common name prefix "systemd-" like "systemd-tty-ask-password" to avoid name conflicts.

      "At one point, if your logging didn't work, it broke your keyboard so you could not terminal in. Don't you love it when two unrelated services with no logical dependencies can some how affect each other?"

      What are you talking about?

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    27. Re:What is systemd exactly? by serviscope_minor · · Score: 1

      Linux fans are SUCH luddites...

      That and we've suffered the slow transition to Potterix before (*cough* pulseaudio *cough*). I mean those problems have *mostly* gone away not that I had to restart the pulse daemon the other day or anything, or have a problem with it randomly flipping to headphones on loud parts on another machine.

      I mean for audio, it's an entertaining griping point but unimportant. For a system daemon?

      And then there's the mind numbingly stupid things like binary journal files. Which get regularly corrupted. *brilliant*. Apparently they're needed for speed, though I don't really understand why they couldn't just use text+index which would still work just as fast and be more reliable.

      Oh and then there's the excessive complexity. I STILL can't get my laptop to sleep via the ACPI key because no one has the faintest clue where the event is getting eaten. Hell no one has even been able to give me much information about how to even try to debug the blasted thing.

      It's not luddism to not want to switch to a system with serious problems, such as corrupting log files and undebugability.

      New-for-the-sake-of-new is as bone-headded as luddism for the sake of luddism.

      --
      SJW n. One who posts facts.
    28. Re:What is systemd exactly? by tlhIngan · · Score: 5, Informative

      The init system handles the initial startup of a linux os. It's been acknowledged for some time that it has some limitations, especially in terms of threading and dependency management but for the server world that's usually not that big a deal since the primary users are technical specialists who are comfortable mucking around with that sort of thing. For desktops and mobile devices though those are more serious concerns because they impact user experience and many users don't have the skills to modify things themselves. Systemd is a replacement for init.

      Kinda sorta. You missed the fact that init itself is also a process manager. In that it's responsible for starting and stopping processes based on runlevels. (Yes, init can start and stop processes on runlevels)

      There's a nasty hack called SysVInit that adds a bunch of shell scripts to init in order to try to replicate the functionality of init. This is done because instead of fixing init's fundamental flaw, people decided to hack a workaround and create a lamer version of a process manager and its hacks. The flaw? Init relies on /etc/inittab for all its process management information needs. One file makes it extremely non-trivial to add and remove services from it programmatically.

      It's why we have to deal with daemons that monitor other daemons that restart daemons should they quit (something init does quite well - even handling cases where a daemon restarts too quickly by pausing it so it doesn't hog system resources).

      And on another note, we have userspace versions of init that manage user processes on login. The desktop/mobile use cases often have per-user applications that startup and run in the background for the user, and need to be managed on a per-user basis.

      So in the end, we end up with the system master process manager, init, a set of hacks and shell scripts to try to emulate it (SysVInit), and one for individual users who wish to have personal services run. Because it's more unix-y to hack three different tools that do almost the same thing, but each with their own limitations and idiosyncrasies rather than one tool to do the job well.

    29. Re:What is systemd exactly? by ArcadeMan · · Score: 1

      As I can recall, 10.4 was the first really good and stable OS X version.

      --
      Get free satoshi (Bitcoin) and Dogecoins
    30. Re:What is systemd exactly? by phantomfive · · Score: 3, Informative

      What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well.

      To be clear, the unix philosophy is much deeper than that. Here's an example. Here is a different set.

      IMO the only way to describe the unix philosophy in a single sentence is, "write good code."

      --
      "First they came for the slanderers and i said nothing."
    31. Re:What is systemd exactly? by Barsteward · · Score: 1

      all those are optional, not mandatory. and for the rest of your comment, more verbal diarrhea

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    32. Re:What is systemd exactly? by Barsteward · · Score: 1

      "but the group implementing it have a horrible architecture and do no understand that problems they are attempting to solve" - you've been reading too many troll posts and believing them

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    33. Re:What is systemd exactly? by Barsteward · · Score: 1

      well, step up to the plate and develop a new shrunken init that every troll would love.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    34. Re:What is systemd exactly? by Anonymous Coward · · Score: 1

      Huh, I always thought it was "write good code, and terrible documentation"

    35. Re:What is systemd exactly? by Barsteward · · Score: 1

      "And then there's the mind numbingly stupid things like binary journal files. Which get regularly corrupted" - not on my machine, is your disk dying and corrupting sectors? there was a poster on phoronix bleating to high heaven about corrupt journals and he was pointed to checking his disk. He discovered it was failing and once he sorted that out, his journals were fine

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    36. Re:What is systemd exactly? by Barsteward · · Score: 1

      he's right though, most of the anti-systemd posters mention pulse....

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    37. Re:What is systemd exactly? by Barsteward · · Score: 1

      "possible downgrade for systems administrators who manage servers." - no, its one of its aims to help admins by standardizing and speeding start up across all linux flavors that use systemd, just a learning curve for the admins

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    38. Re:What is systemd exactly? by MachineShedFred · · Score: 4, Informative

      In fact, launchd was a godsend in the early OS X days. Instead of a mishmash of INIT and Classic MacOS nonsense (/Library/StartupItems), you ended up with one system that could handle per-user agents as well as system daemons, process monitoring and respawning, jobs defined in the same property list format everything else in the system is, and a scriptable interface (launchctl) for simple administration.

      Then they open sourced it. And nobody decided to use it, even though it has been bulletproof for 10 years now.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    39. Re:What is systemd exactly? by Barsteward · · Score: 1

      depends what your servers are doing, ours were bank branch controllers that dealt with all comms etc between the branch and head office mainframes and they took 20 minutes to get up to full operation and thats a long time when you have a branch full of customers wanting to withdraw or deposit money

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    40. Re:What is systemd exactly? by Barsteward · · Score: 1

      read this, it might help http://www.freedesktop.org/sof...

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    41. Re:What is systemd exactly? by Barsteward · · Score: 1

      its more than a speed up of boot, thats just one of its features

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    42. Re:What is systemd exactly? by CurryCamel · · Score: 4, Interesting

      That baffles me too.

      But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).

      I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows:
      -About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know.
      -The same Fedora box cannot mount /home at bootup. I have to log in as root, and mount it over command line.
      -Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.

      The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it.
      Reading bash scripts is much easier.

    43. Re:What is systemd exactly? by Barsteward · · Score: 1

      "Systemd is tying into everything from initial boot to how to configure your soundcard." are you confusing the project "systemd" (they should have called it something else) with the systemd daemon?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    44. Re:What is systemd exactly? by cheesybagel · · Score: 2

      UNIX manpages were great. The problem was when people stopped writing manpages.

    45. Re: What is systemd exactly? by buchanmilne · · Score: 4, Informative

      Note that sysv init only does anything useful for 3 use cases:
      -booting the system
      -shutting down the system
      -changing run levels (which both of tje above are considered to be)

      On most machines these days, no one changes run levels more than once or twice a month.

      Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.

      Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.

      On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the /proc/$pid/environ of a service started at boot to one that has been restarted since ...

      systemd is noy perfect, but it is much better in all of these aspects.

    46. Re:What is systemd exactly? by cheesybagel · · Score: 1

      Why do you think MacOS X is considered unusable for server purposes?

      Damned desktop users.

    47. Re: What is systemd exactly? by buchanmilne · · Score: 1

      systemd can run legacy sysv init scripts just as badly (or better than) as sysv init can. No need for alarm or panic.

      But, why do that when a 4-line config file can do most of what you need.

      In the case of a more complex service, you can write a pre-exec script, so that may require some conversion.

    48. Re:What is systemd exactly? by macs4all · · Score: 1

      OS X admins

      Hahahaha!

      Tell that to the MacCoLo Admins.

    49. Re:What is systemd exactly? by macs4all · · Score: 1

      As I can recall, 10.4 was the first really good and stable OS X version.

      I'd argue that that title goes to 10.3; but YMMV.

      Yes, and in a lot of people's minds, 10.6 was the last, sigh...

    50. Re:What is systemd exactly? by phantomfive · · Score: 1

      Cool thing, even in the beginning Unix had man pages. You can check them out.

      --
      "First they came for the slanderers and i said nothing."
    51. Re:What is systemd exactly? by macs4all · · Score: 1

      Then they open sourced it. And nobody decided to use it, even though it has been bulletproof for 10 years now.

      Yeah, especially odd that the systemd folks didn't just adopt it. There'd be a LOT less to bitch about in the Linux "community" if they'd simply ported an already-stable daemon.

      Not that that would have stopped the bitching, of course...

    52. Re:What is systemd exactly? by macs4all · · Score: 2

      Why do you think MacOS X is considered unusable for server purposes?

      Damned desktop users.

      Unfortunately, Saint Jobs never really believed in OS X Server; so it never got the development resources it needed to grow into a worthwhile product.

      Kind of like Mssr. Cook seems to feel about the Mac Pro...

    53. Re: What is systemd exactly? by PPH · · Score: 2

      But, why do that when a 4-line config file can do most of what you need.

      Because the systemd supporters seem to think that they can second guess what "we" need. Without understanding the requirements of a few dozen subsystems that have evolved over time.

      --
      Have gnu, will travel.
    54. Re:What is systemd exactly? by Barsteward · · Score: 1

      "It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process." - wrong, all the other processes are optional. Unfortunately the collective software project is also called "systemd" so people get confused that when other processes are mentioned and think that the systemd executable does it all.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    55. Re:What is systemd exactly? by phantomfive · · Score: 1

      PROS: It has faster boot time and more sophisticated dependency management

      You can add that it makes init scripts a lot easier to write.

      --
      "First they came for the slanderers and i said nothing."
    56. Re:What is systemd exactly? by Barsteward · · Score: 2

      "All subprocesses running as root " - bollox, do some research instead of spreading crap

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    57. Re:What is systemd exactly? by mrchaotica · · Score: 1

      See, that's exactly what I mean by "doing it wrong!" The proverbial "real WTF" is that you didn't have backup servers handling the load so that you could reboot as leisurely as you like without downtime.

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    58. Re:What is systemd exactly? by TopherC · · Score: 1

      The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems. Systemd is tying into everything from initial boot to how to configure your soundcard.

      Those established-over-decades init scripts are fragile and difficult to maintain. My observation is that this is what drives system developers to push for systemd. Well, this and the order of startup, dependencies, etc.

      Maybe we need a fork of systemd that takes some of the more common complaints seriously enough to do something about them. I see limitations of plain-text logging systems, but can't these be addressed with a text-based, human-readable log that uses some kind of mark-up for timestamps, PIDs, etc? While there may be some small efficiency gains by incorporating more services into systemd like networkd and such, we could set a higher bar for module inclusion -- there has to be an overwhelming argument for tight integration. And so on.

    59. Re:What is systemd exactly? by fluffernutter · · Score: 1

      Dude, I was there last week! I spent 45 minutes on the first page that came up in Google and I was golden.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    60. Re:What is systemd exactly? by blue9steel · · Score: 1

      "possible downgrade for systems administrators who manage servers." - no, its one of its aims to help admins by standardizing and speeding start up across all linux flavors that use systemd, just a learning curve for the admins

      Startup speed isn't a server issue, frankly it's irrelevant from that perspective. The startup is already standardized so I fail to see how changing the standard is a net benefit. The main benefit of systemd is for mobile and tablet users with a slight bump for desktops.

    61. Re:What is systemd exactly? by Prune · · Score: 1

      it's a more monolithic design (which violates the linux design principle of do one thing and do it well)

      Is this a joke? That is a Unix principle, not a Linux principle — for what violates it more than the monolithic Linux kernel?

      --
      "Politicians and diapers must be changed often, and for the same reason."
    62. Re:What is systemd exactly? by blue9steel · · Score: 1

      As long as the feature you want is one of the pre-defined set then service definitions are probably easier than init scripts even though you have to learn a new syntax. For customization the advantage seems less obvious. One advantage with init scripts over service definitions is that you can read them to figure out how something works, service definitions hide the complexity, which is both good and bad depending on the situation.

    63. Re:What is systemd exactly? by nabsltd · · Score: 1

      wrong, all the other processes are optional.

      Here's a test: uninstall all those other "optional" processes and see what happens. Is systemd still installed, or does it get uninstalled because of dependency resolution? Does your system still boot? Can you log in?

      Report your results back here, so we can all see how "optional" those extra processes are.

    64. Re:What is systemd exactly? by sansprivacy · · Score: 1

      This is my understanding as well. I had not really paid much attention to it until this past week when it was mentioned at work. Since we are still working with older releases of the major distros it hasn't come up. Last night I read up on the topic and was disturbed with what I found with respect to Linus's calling out of one of systemd's prime movers for some blatant ignoring of kernel development etiquette. I think systemd does introduce some good things as well as some not so good. None of that should matter in the long run if improvements / bug fixes are handled properly. I think the systemd maintainers are well aware that they are on thin ice with the community, so we should hopefully already be seeing improvements.

    65. Re:What is systemd exactly? by devent · · Score: 2

      It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process.

      Your understanding is wrong. systemd init have only a few components, and everything else is in independent daemons/tools. It follows exactly the Linux "Philosophy".

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    66. Re:What is systemd exactly? by blue9steel · · Score: 1

      Sure, you can say it's a Unix principle, of course Linux is a Unix based OS so in general that's the principle. Yes, this mostly applies to things other than the kernel, though I'm sure we're all eager to see how HURD works out if it's ever actually finished. If the systemd developers had wanted to solve multiple problems the more Unix-ish way they would have done something more like this:

      Init sucks, so we built newinitd (it's awesome because it's threaded and shiny, did we mention shiny?)

      Oh by the way since SysVInit scripts are lame we also wrote newscriptd (has a great new service definition language, try it out, or don't since it will execute your old SysVInit scripts just fine if you're too lazy to learn something new)

      While we were at it we decided that syslog is boring so in a Mountain Dew fueled coding spree we also created newloggerd (has funky binary logs but we think you'll love the features we created and besides who likes using vi to read log files anyways? Oh, if you're not as cool as us both newinitd and newscriptd have syslog support)

      Hey, you know how services die and don't get restarted easily, yeah we hated that too so we wrote newprocessd (does all kinds of spiffy process management things and integrates well with our other new tools, but since you might be old and not hip with them it can be run using syslog and init, you really should try our cool new stuff though)

      We kind of got excited and carried away so after laughing at one of the old timers stories about how great vt220s were we wrote a replacement for terminals we're calling newconsold (who uses terminals anymore anyways?)

      By this point we were so charged up we wrote a bunch of other stuff which you can download as bigbundleofshiny.deb, there are like twelve more bits of awesome in there that you should totally check out. (if you don't it will hurt our feelings but none of them are required for our other stuff to run)

    67. Re:What is systemd exactly? by Ben+Hutchings · · Score: 1

      or have a problem with it randomly flipping to headphones on loud parts on another machine

      Because obviously broken jack detection is the fault of the daemon, not the hardware or sound driver.

    68. Re:What is systemd exactly? by serviscope_minor · · Score: 1

      Because obviously broken jack detection is the fault of the daemon, not the hardware or sound driver.

      Well, gee I never thought of that.

      Tell me then, smart arse, why does ALSA work perfectly and not do that? So why are the two failure modes to (commonly) switch to headphones and (uncommonly) get into an oscillation where it switched rapidly back and forth. These are:

      (a) only triggered by loud volumes
      (b) specific to PA and not present with ALSA
      (c) always solved by restarting the daemon.

      This is not a hardware problem, this is a PA problem.

      --
      SJW n. One who posts facts.
    69. Re:What is systemd exactly? by Lord+Apathy · · Score: 1

      At one point, if your logging didn't work, it broke your keyboard so you could not terminal in. Don't you love it when two unrelated services with no logical dependencies can some how affect each other?

      Oh horse shit. Crap like that has been on my linux bullshit list long before systemd rolled out of the gate.

      Many years ago when I was running linux at home 24/7 as my main OS I installed several rpms from redhat not related to keyboards and shit. All of a sudden my keyboard stopped working, for no reason what so ever. Other issue like this had happened before but this was the last straw.

      That night I pulled my data off the system and installed windows on that box. I still run linux as a desktop at work and I have a linux server at home but I'll never run linux as my primary desktop at home.

      --

      Supporting World Peace Through Nuclear Pacification

    70. Re: What is systemd exactly? by Ash-Fox · · Score: 1

      On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did

      You can by using the 'service' command and ensuring everyone uses that method with init scripts.

      --
      Change is certain; progress is not obligatory.
    71. Re:What is systemd exactly? by StillAnonymous · · Score: 1

      Not all systems can be designed that way, either due to technical reasons, or financial ones (you are sometimes required to pay full licensing fees on a standby node for the software you have, which can be very substantial)

    72. Re:What is systemd exactly? by Phil+Urich · · Score: 1

      Huh, I always thought it was "write good code, and terrible documentation"

      No, that's just the motto of all programmers.

      --
      I remember sigs. Oh, a simpler time!
    73. Re:What is systemd exactly? by dbIII · · Score: 1

      That's because it wasn't written by the guy responsible of inflicting pulseaudio and NetworkManager on people before they were ready for use. Systemd is his new thing, and it still needs a lot of polish before it can be compared with launchd.

    74. Re:What is systemd exactly? by dbIII · · Score: 1

      Because it's the same problem as with pulse - rushed into production too early.

    75. Re:What is systemd exactly? by strikethree · · Score: 1

      You nailed it on a lot of points.

      2) It potentially creates a layer between kernel and the rest of the system that becomes entrenched and irreplaceable.

      You would think this reason alone should be enough to push people far away form SystemD. To me, that is probably the largest reason to avoid it, but certainly not the only valid reason.

      I wish your point could be echoed loud and clear and that the concern could be addressed. I do not see how it can be addressed though.

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    76. Re:What is systemd exactly? by Barsteward · · Score: 1

      the only dependencies are systemd, journald and udev. all others are configurable for use. if a developer makes changes to his/her app to depend on systemd in any way, its their development choice and their efforts.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    77. Re:What is systemd exactly? by Eunuchswear · · Score: 1

      systemd has no registry.

      --
      Watch this Heartland Institute video
    78. Re:What is systemd exactly? by macs4all · · Score: 1

      Bullshit. All the svchost.exe processes you see are the exact same executable. There isn't a different svchost.exe for each process. Only the most naive AV imaginable would put any trust in the name of an executable anyway, let alone most AV apps. Giving malware the same executable name as common system processes is the oldest trick in the book. AV apps would be fucking useless if it were that easy to avoid detection. As far as made up bullshit goes, that's not even very creative. 0/10.

      While I admit that my knowledge of the design of Windows AV Applications is limited, and my knowledge of the design of Windows viruses is even more limited (but maybe you have more experience in that regard, eh?); however, all I know is that I was asked to disinfect a friend's Windows XP machine a couple of years ago. He was already running Kapersky AV, and I subsequently tried AVG and Avast, and maybe one of two others.

      ALL of them identified several pieces of malware under the name of svchost.exe, but NONE of them would do anything about it, for the very same reason: Bcause they had svchost.exe on some sort of internal "cannot delete" list.

      So, I call Bullshit on your Bullshit, because that's the way it happened. I went around and around with this for nearly a week. The only way I eradicated this particular infection was the time-honored Windows Admin's friend: Wipe and Reload (which I REALLY wanted to avoid on this particular machine)

    79. Re:What is systemd exactly? by macs4all · · Score: 1

      That's because it wasn't written by the guy responsible of inflicting pulseaudio and NetworkManager on people before they were ready for use. Systemd is his new thing, and it still needs a lot of polish before it can be compared with launchd.

      Ok, I'll bite.

      So, instead of getting all butthurt about the systemd "virus", why isn't there a movement among kernel-development-minded Linux Admins to change to launchd in lieu of systemd, for the very reasons you mentioned? After all, Apple thought that releasing launchd into the F/OSS "community" was a responsible thing to do. That act didn't cost Apple zero dollars, or require zero effort; so why not take advantage of a daemon that you, yourself have identified as superior?

      Could it be that bitching about something is far easier than actually DOING something?

      It is clear that, good or bad, INIT is being phased out by every, or nearly every major Linux distro. So why not move in the direction of "most stable" (launchd has been working essentially flawlessly in OS X for a DECADE) and "most well-developed" (based on your comparison of how much "polish" systemd will need before it could compare to launchd?)

      Could it possibly be that the Linux "community" would rather suffer a decade's sputtering and insufficiently-tested systemd development than accept (yet another) gift from Apple?

      Think carefully before you respond.

    80. Re:What is systemd exactly? by hitmark · · Score: 1

      Don't have a URL handy, but i think it may be a reference to systemd presenting the user with a emergency login prompt that would execute commands, as root no less, entered at the password prompt.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    81. Re:What is systemd exactly? by hitmark · · Score: 1

      Fundamentally the "server" argument is not aimed at traditional (some would call it "pet") servers. It is aimed at cloud servers, like amazon's EC2 service. There being able to spin up 1000 extra "server" instances at the drop of a fedora is key.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    82. Re:What is systemd exactly? by hitmark · · Score: 1

      It "is", if you treat your laptop like a oversized smartphone.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    83. Re:What is systemd exactly? by hitmark · · Score: 1

      With systemd a troubled boot seems to go from "it booted, but lack half the daemons" to "something in the dependency chain broke, here is a (buggy) emergency login, you're on your own" (the last bit systemd will actually state when presenting you with said login).

      At that point you are better off hitting hardware reset and fire up the kernel with /bin/bash as init (not sure how friendly journald is about giving out anything without systemd running though).

      Seriously, at one point that emergency login was found to be executing commands, as root, if they were typed into the password prompt.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    84. Re:What is systemd exactly? by hitmark · · Score: 1

      With roid rage.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    85. Re:What is systemd exactly? by hitmark · · Score: 1

      Maybe i am old, but i kinda liked the autoexec.bat/config.sys duo. Open up two files, see exactly what the system was doing to get started. But then DOS booted fairly rapidly at the worst of times, thanks to not having a massive tree of interlocking processes that all needed to save state upon shutdown.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    86. Re:What is systemd exactly? by Gr8Apes · · Score: 1

      I'm aware, but the thinking is the same - monolithic binary architecture (with logs, as an example). I only have to go to one place and everything's there. Not having things packaged in a component oriented manner is only begging for trouble down the road IMNSHO.

      --
      The cesspool just got a check and balance.
    87. Re:What is systemd exactly? by Gr8Apes · · Score: 1

      Sometimes a standard is bad even if everyone uses it. Take COBOL, for instance, the "standard" language of financial and reservation systems in the day. Everyone used it, and pretty much everyone hated it except for the few that didn't mind the money flow over having to work with a horrible system. There are still systems out there from the 70s running today. I personally know of 2 relatively large ones. They cost a fortune, but the people working with them haven't been able to replace them with something more modern (wrong people for the job).

      --
      The cesspool just got a check and balance.
    88. Re:What is systemd exactly? by gweihir · · Score: 1

      There is zero need to speed-up startup times on server installations. Breaking things to do so is insane.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    89. Re:What is systemd exactly? by gweihir · · Score: 1

      Seriously? What nonsense is this? The kernel is special, hence it is called "the kernel". The architecture of the kernel and the architecture of user-space are two different things. But you are right in one respect: Clearly Poettering wants to be more important than Linus and hence is trying to put a wrapper around the kernel.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    90. Re:What is systemd exactly? by gweihir · · Score: 1

      Indeed. Professional operations even does fail-over tests to make sure booting and outages are not a problem. If you do not have a fully redundant infrastructure for such applications, then you do not have a professional operation. Reducing boot-times is for convenience, not for mission-critical things.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    91. Re:What is systemd exactly? by vux984 · · Score: 1

      Poorly defined?

      Yes.

      It replaces sytsemd [I assume you mean init.d] and more besides

      The "and more besides" is the vague poorly defined part.

      and does a better job.

      In many cases yes.

      People are crying over it because of some misplaced loyalty to a shitty, broken, half assed system that might have passed muster in 1990 but should have been long replaced.

      Their loyalty is to modularity of the existing system, not the existing system itself. If systemd was more modular, less tightly integrated and interdependent there would be no real objection to it.

      If some whiners got over themselves they'll realise that systemd is vastly superior in every respective.

      Except that once it's entrenched it can't be replaced with something even better in the future. It can't be improved one piece at a time, because its all or nothing and tightly integrated. A better event logging system can't arise independently because the rest of systemd won't work with it.

      Its a golden cage... even if we agreed that it is nicer than where we live today (many do, many do not but that's beside the point): once your inside your stuck with it.

    92. Re:What is systemd exactly? by gweihir · · Score: 1

      Those established-over-decades init scripts are fragile and difficult to maintain.

      Oh? In about a decade of also doing system administration and maintaining my own init scripts for some things, I hadn't noticed. Maybe the problem is not with the init scripts, but a vocal minority of those trying to maintain them?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    93. Re:What is systemd exactly? by segedunum · · Score: 1

      Yeah, especially odd that the systemd folks didn't just adopt it. There'd be a LOT less to bitch about in the Linux "community" if they'd simply ported an already-stable daemon.

      It would have been if they were simply developing an init system. However, systemd isn't one.

    94. Re:What is systemd exactly? by segedunum · · Score: 1

      With exceptionally good reason...........

    95. Re:What is systemd exactly? by macs4all · · Score: 1

      Yeah, especially odd that the systemd folks didn't just adopt it. There'd be a LOT less to bitch about in the Linux "community" if they'd simply ported an already-stable daemon.

      It would have been if they were simply developing an init system. However, systemd isn't one.

      But launchd is much more than simply a replacement for INIT.

    96. Re:What is systemd exactly? by Pav · · Score: 1

      So what you're saying is if it's modular in theory, but monolithic in practice it's not a systemd design problem but a problem with developers? Right, got it! In other news : those encryption standards that people say were "subverted" by the NSA to make a correct implimentation less likely are perfectly fine... nothing to see... move along. Any problems are with the developers.

    97. Re:What is systemd exactly? by Pav · · Score: 1

      That's interesting... the guy who maintains the init scripts for a project I'm involved with (ie. FusionDirectory) has some quite complicated init stuff going on, and yet he still agrees that accepting the genuine systemd goodness is not worth its bundled shortcomings.

    98. Re:What is systemd exactly? by dbIII · · Score: 1

      why isn't there a movement among kernel-development-minded Linux Admins to change

      Because the old system is not seen as broken, Lennart just wants something that's not as old as he is. Change for the sake of change which has led to some very unusual choices (eg. binary log files that get corrupted via race conditions which still have not been dealt with).
      Lennart was pushing systemd HARD for immediate adoption in 2010 when it could barely do anything - speaking all over the place with RedHat paying the airfare. The drive is more political (as in office/club/group politics in case someone wants to pretend to misunderstand that) than practical.

    99. Re:What is systemd exactly? by macs4all · · Score: 1

      So how is all that responsive to my question, to wit: "Since it is very clear that change is a-comin', and it don't include INIT, then why not turn the ship away from the iceberg, and start a movement to replace systemd with launchd, because it is so much more mature, and even more capable, than systemd?"

      Broken or no, INIT's days in Linux-Land are numbered. Deal with it. I'm just suggesting that you Linux guys get behind launchd instead of systemd, for the good of the "community".

    100. Re:What is systemd exactly? by ookaze · · Score: 1

      What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.

      That is my understanding looking in from the outside.

      Your understanding is wrong, but you're not to blame, it's understandable because those opposed to systemd have no other argument than to make you believe all the components you cited are integrated into one tool/process. Of course this is false.
      systemd, the PID 1 process, manages initializing processes on bootup and scheduling jobs after boot-up, like sysvinit. It has lots of features to do these tasks even when the environment dynamically changes.
      Maintaining logs is in another process, managing devices alo in another process, managing network devices in another process ...
      So actually, if that's your definition of Unix "philosophy", systemd pretty much is adequate.
      There is no Linux "philosophy", but you believe that because Unix "philosophy" (which has as many meanings as there are people using these words) is used to attack systemd, as if Linux and Unix were the same things. Actually, Linux (and GNU) by itself already detracts from Unix in lots of ways already.

    101. Re:What is systemd exactly? by ZeroWaiteState · · Score: 1

      I disagree. Dependency management is hugely important for servers. That's the whole reason things like apt and rpm exist, to say nothing of orchestration and configuration management stuff like Puppet and Chef. The fact is servers are run by operators who usually wear many hats and don't have time to "muck around" with failed software upgrades because services didn't shut down/upgrade/restart in the correct order. That's all cool when you have 2 or 3 servers to manage. When you have 1000 servers and 100 of them are down it's a huge inconvenience to troubleshoot.

    102. Re:What is systemd exactly? by ZeroWaiteState · · Score: 1

      The Linux kernel is monolithic because that's what runs efficiently on current processors. Microkernels have some nice features regarding safety, but they are slow. Doing stuff like filesystem access in the userspace involves a context switch, which means you leave the CPU cache in many cases. Linus had a big discussion with Tanennbaum over that. Microkernels are good theory, and I think they are the future of reliable operating systems. However, current widely available CPU hardware is not DESIGNED to run microkernels in a way that is cache-local. Operating systems have to work with the reality the hardware provides. Mac OSX has a microkernel system, but Apple ended up having to move some userspace drivers into the microkernel for the same reason described above.

    103. Re:What is systemd exactly? by ZeroWaiteState · · Score: 1

      You mean like an embedded/portable device, or a server that operates in an environment where you want to recover quickly from loss of power (such as when a server gets power-killed via a Smart PDU due to a transient hardware/software fault detected by an external monitor), or a server in an auto-scaling VM environment.

    104. Re:What is systemd exactly? by blue9steel · · Score: 1

      If you have 100 servers down due to a bad software upgrade you didn't do a very good job of testing before rolling it out to production did you?

    105. Re:What is systemd exactly? by ookaze · · Score: 1

      it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.

      There is no so called "linux design principle" of do one thing and do it well, and even if there was, it would be the contrary of what you're saying as Linux (the kernel) has a monolithic design. In the case you were talking about GNU, systemd uses the same design as most GNU software, which is a "software collection".
      There is no linux principle of "everything is a text file", this is pure nonsense as sure enough, not everything in Linux is a text file (just look at sockets or block devices).
      There is a Unix principle that says everything is a file, but not a "text file". You're mixing several things without understanding the purpose of what you're talking about.
      Anyway, guess what, outside the United States, often the classic log files are actually binary files. Because what you describe as "text files" are actually "ASCII files" which is an encoding, but if your kernel or tools don't support UTF-8 encoding which is mostly used on Linux, you will extract mostly garbage from log files (all of mine are UTF-8 files, and yes I have log files despite using systemd). But that's nitpicking, binary log files are not a problem with systemd as you can use classic "text files" juste the same with systemd.
      Finally, there's no "single subsystem" that takes a large number of roles with systemd, each subsystem in systemd has one role.

      In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.

      Actually, systemd is an actual huge upgrade for system administrators who manage servers, in the actual world, not in an hypothetical one.
      The problem is that actual administrators, to switch to systemd, will have to manage the more or less huge number of hacks they inserted into deficient init.d scripts, which can be a huge tasks depending on if they documented them or not. And probably most didn't...

    106. Re:What is systemd exactly? by ookaze · · Score: 1

      If you have any reason to care how long it takes for your server to boot, you're already doing it wrong.

      You are plain wrong added to the fact that you're not a good sysadmin then, or one with very little experience if any.
      You need a threshold of time to know if your server will go up or not.
      Guess what, a server won't always go up for various reasons, especially when you have init.d scripts patched everywhere with various timeouts, that can break at any reboot. You need to monitor your server startup, and it starts to become tedious when you have tens of server startup to monitor.

    107. Re:What is systemd exactly? by ookaze · · Score: 1

      The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems.

      There is no such "established-over-decades code in scripts" in the real world, which is why sysadmins around the world constantly had to tinker with these scripts. This is also the exact reason why if no one cares about them, these init scripts will wither and die.
      The most important plumbing init scripts are flawed by design, init is flawed in a dynamic environment like the one created by the Linux kernel, which is why everyone wanted to flee it since a long time. But sysadmins and distro makers couldn't agree on anything until systemd.

      Systemd is tying into everything from initial boot to how to configure your soundcard.

      Actually, systemd doesn't tie into how to configure your soundcard, but if you don't understand what people are talking about, especially systemd opponents, I see why you would think that. You must believe pulseaudio is part of systemd I gather.

      On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.

      I don't understand why you're talking about Windows here as a party, you're not making any sense.
      systemd is free software, so I assure you that you don't have to deal with undebuggable binaries, as the code to these binaries is readily available. Exactly like the source code of sysvinit or the numerous daemons launched by the scripts you're talking about.
      Perhaps you believe the init scripts themselves were serving as daemons, but that's rarely the case : these scripts were just there to try (badly) to understand the context to then launch "undebuggable binaries".

      It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.

      I don't understand what is scary about that. Your system depends on lots of binaries working as expected, starting with your bootloader, your kernel, your daemons, ...
      That's the job of a sysadmin, I can assure you they're not scared at all providing they know what they are doing.

      I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.

      Actually you can still do that with systemd, but even better than before, especially when your keyboard is not qwerty or your character encoding not ASCII.

      On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.

      Why? I'm on the second side and I do exactly as advertised, even better than with sysvinit.

      More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.

      This was always the case in Linux, like most of the Linux plumbing ecosystem, which is not a bad thing imho, as long as the projects are active.

    108. Re:What is systemd exactly? by blue9steel · · Score: 1

      Actually, systemd is an actual huge upgrade for system administrators who manage servers, in the actual world, not in an hypothetical one.

      In what way? I see how it's great for mobile, tablet and even desktop users but frankly I fail to see how it improves server administration. Sure, we trade init scripts for service definitions but that's more of a sidegrade than an improvement.

    109. Re:What is systemd exactly? by ookaze · · Score: 1

      But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.

      Yes, these scripts are workaround for the deficient sysvinit, like trying to guard against environment tampering, managing user options without modifying the init script itself (often scattered over several locations), ...
      systemd removes these nonsense scripts and replaces them with a simple configuration file (a unit) without any drawback. You can even modify the systemd units, with your modifications usually still valid after an upgrade (it won't work if your unit is renamed to something else than apache2).
      This just shows how horrible init scripts were. It's even worse when you know you can manage isolation like chroot, or security features very useful for a web server like hiding filesystems or directories from the daemon.

      Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.

      This is correct, except for the bunch of people unfamiliar with modern OS operation. Their goal was to reduce this number, which doesn't solve any use case I know for big servers, except reduce attack surface at boot perhaps, this I can agree with.
      For smaller servers and limited resources systems, like embedded systems, the efficiency is very welcome. My security frontends say thanks to systemd.

      Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.

      *Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.

      Actually, systemd works far better with my use cases. It works far better with LVM2 for instance, than my shell scripts ever could.
      Actually, it works every time now with systemd. mysql and apache works far better now, especially mysql which was a pain to start and especially to stop with the initscripts. Now with systemd it's far better.
      I agree there's some tuning to do at first, but not the kind of bad hacks we had to use with init scripts.
      The attack surface of init scripts was also huge, without any hope to discover it without constant monitoring. Some init scripts had 4 (yes four) different ways to configure them, each one could be exploited.

    110. Re:What is systemd exactly? by ookaze · · Score: 1

      That baffles me too.

      But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).

      You would not understand as you've shown below and above that you're not the audience to even start to understand what it's all about.
      The minority you're talking about is the exact same that was maintaining the init scripts before, you can be assured they know what it is about. And I can perfectly understand why these people would ditch sysvinit and init scripts as soon as possible.
      systemd is a good thing for a lot of reasons that you will be unable to understand, given what you write below.

      I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows:
      -About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know.
      -The same Fedora box cannot mount /home at bootup. I have to log in as root, and mount it over command line.
      -Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.

      The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it.
      Reading bash scripts is much easier.

      Now you're spewing nonsense. This is not your experience with systemd, this is your experience with some specific version of Fedora.
      Linux crashes, /home not being mounted and other problems are not fixed by searching Google blindly or reading manuals or reading bash scripts, this makes no sense at all. Reading init scripts wouldn't help you understand what is going on.
      There is one thing to do in this case : searching for logs that will give you a hint at your problem (the error at bootup is not enough), to have a start of an understanding of what's going on. That's the basic and you don't even have that. Fortunately you have the sense of not being vocal about systemd when you don't have the basics of system administration. Other vocal people don't even have that common sense unfortunately.

    111. Re:What is systemd exactly? by devent · · Score: 3, Informative

      What are you talking about? In the core systemd have only 5 daemons: systemd, journald, networkd, logind and user session, and it depends only on dbus, cgroups, autofs and kdbus. That is very minimalistic. The rest are optional daemons and tools that make your life easier.
      http://en.wikipedia.org/wiki/S...

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    112. Re:What is systemd exactly? by CurryCamel · · Score: 1

      And I can perfectly understand why these people would ditch sysvinit and init scripts as soon as possible.
      systemd is a good thing for a lot of reasons that you will be unable to understand, given what you write below.

      My point was - I don't understand why they'd want to do it. And nobody seems to want to explain it beyond a rather lame "faster boot". If SystemD makes life easier for the distro maker for reasons unknown to me, fine. Let them make the switch.
      If it makes life more difficult to me, I can always switch distros, then.

      There is one thing to do in this case : searching for logs that will give you a hint at your problem (the error at bootup is not enough), to have a start of an understanding of what's going on. That's the basic and you don't even have that.

      Please don't jump to conclusions like that.

      Fortunately you have the sense of not being vocal about systemd when you don't have the basics of system administration.

      And especially like that.
      I didn't include the exact error reports here, as this is no systemd support forum.

      No, I am no sysadmin. I am a user and have to administrate most of my computers myself. And as you write, that is the crux of the matter I guess: SystemD is so difficult to use that one needs to be a professional to manage it. Or did I misinterpret what you were writing above? ;)

  10. Re:Delicious geek tears. by Anonymous Coward · · Score: 1

    >meets more people's needs than your own special pet niche

    I wouldn't mind your rant if you weren't tossing the baby out with the bathwater like this. But I guess it's easier to just count old users as not worthy, and try to shame them into changing, rather than trying to cater to their needs as well.

  11. Re:Delicious geek tears. by Penguinisto · · Score: 1

    Meh - my personal laptop runs OSX.

    Professionally, I'm stuck with learning and using it.

    As ugly as it is, systemd is still better than Windows Server 2012, the registry, services.msc, and (*puke*) Powershell.

    --
    Quo usque tandem abutere, Nimbus, patientia nostra?
  12. I was on the fence by wisnoskij · · Score: 4, Funny

    I never really understood either side, far above my head. But I have used Ubuntu a few times and followed their major changes over the last decade. If there is one thing I do understand is that if Ubuntu is switching to it it must be a trendy piece of crap, far from ready for prime time.

    --
    Troll is not a replacement for I disagree.
    1. Re:I was on the fence by gweihir · · Score: 1

      +1 Funny!

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  13. Yea, another systemd thread! by Anonymous Coward · · Score: 1

    Every time I see another systemd thread pop up in the slashdot headers I start popping a bowl of popcorn and get ready to sit down for another entertaining thread filled with adamantium opinions and name calling. Seriously, these threads are gold! The slashdot server should run a weekly cron that posts a new systemd-ish thread each week.

    1. Re:Yea, another systemd thread! by macs4all · · Score: 1

      The slashdot server should run a weekly cron that posts a new systemd-ish thread each week.

      But, isn't cron one of the casualties of systemd?

      I know that on OS X, launchd usurped cron, so I assumed that the same would be true of systemd...

  14. Re:I come here for the comments. I stay for the fl by WindowPane · · Score: 1

    With all the flames you should grab the Jiffy Pop.

    --
    No Brains, No Headaches
  15. Question from a non-Linux user by i+work+on+computers · · Score: 1

    If everyone hates systemd so much, why is it being incorporating into all these Linux distributions? Have all the major ones incorporated it? Does this "evil" Poettering guy really have that much clout in all the disparate distros?

    1. Re:Question from a non-Linux user by Anonymous Coward · · Score: 1

      If everyone hates systemd so much, why is it being incorporating into all these Linux distributions? Have all the major ones incorporated it? Does this "evil" Poettering guy really have that much clout in all the disparate distros?

      systemd is being incorporated into the linux distributions because of dependencies and reverse dependencies making it by far easier to use systemd than to fork packages that don't rely on something that relies on something that relies on systemd. Whenever one of the systemd people touches another piece of software, it's usually to add a dependency on systemd or another package that depends on systemd. It's become a cthulhu with tentacles everywhere.

      As for Poettering, some say he's good at giving head.

    2. Re:Question from a non-Linux user by Anonymous Coward · · Score: 5, Insightful

      The SystemD crowd are windows devs who hate 8 so much, they finally decided to get into linux. Sadly, they want linux to work like windows, so they foist their shit into it. It does make boot times faster: something sysadmins usually don't give a shit about since you don't reboot servers. Red Hat wants systemD because it will let them abstract linux (the kernel) away to the point where they can control it instead of "the community". In addition, several genuinely nice tools, UUID for disks, are being folded into SystemD so, in order to get those tools, you *must* also use SystemD. Essentially it's being bundle in with other services.

      Sadly, SystemD is not well tested enough for most people running linux on a server to trust it especially since the guy who wrote it wrote PulseAudio and people are still having issues related to that piece of shit.

      Pros:
      * Boots fast

      Cons:
      * When it breaks, you're fucked
      * Obsoletes 20-30 years of accepted best practices and knowledge of how to use linux tools
      * No real new features
      * Is network connected and running as superuser
      * Is unaudited
      * Is virtually untested
      * Was written by a raging moron
      * Is completely unneeded by a large section of people who have run linux for a long time

      Essentially, it's the Windows 8 of the *nix world

    3. Re:Question from a non-Linux user by Anonymous Coward · · Score: 1

      Red Hat is pushing SystemD. They're a heavy-weight in the Linux world and SystemD gives them more influence over other distros.
      Not all major distros adopted it, although the majority did. Gentoo for instance doesn't force you to use it.
      And not everyone hates it. People who want Linux to be Windows like it since it's svchosts.exe, and BSD people love it since it's bringing them new users.

    4. Re: Question from a non-Linux user by kthreadd · · Score: 1

      Red Hat did not create systemd. It was created independently and Red Hat only adopted it after it proved itself in Fedora, and it even took a couple of years until Fedora adopted it.

    5. Re:Question from a non-Linux user by Peter+H.S. · · Score: 3, Informative

      If everyone hates systemd so much, why is it being incorporating into all these Linux distributions? Have all the major ones incorporated it? Does this "evil" Poettering guy really have that much clout in all the disparate distros?

      The systemd haters are actually a tiny but vocal minority. They tend to flash-mob systemd threads, so you can often see here on slashdot, how a little handful of systemd-haters post 10-20 anti-systemd posts in anything remotely related to systemd. They seem like they are many, but when counting they are quite few.

      No distro have lost users because of switching to systemd, in fact, systemd is part of the whole OS container wave that are fuelling the Linux engine at the moment. Not a single non-systemd commercial Linux distro have emerged since all the major Linux distro announced their shift to systemd, so the server market seems firmly behind systemd.

      One reason why Canonical is changing to systemd as fast as it can, is because their OS container costumers are impatiently tapping their feet, waiting for systemd integration.

      People have started to ignore this small, sometimes very toxic minority for quite some time, since the anti-systemd people are basically uninformed about any technical aspects of systemd, because they rely on hearsay and random hate blogs for their information about systemd instead of actually reading the systemd documentation.

    6. Re:Question from a non-Linux user by Anonymous Coward · · Score: 1

      Even better, they're apparently also trying to make it as insecure as Windows. They want to throw out 20+ years of incremental improvement and testing, and replace it with a un-audited binary that touches everything and thus has a ridiculously huge attack surface.

    7. Re:Question from a non-Linux user by byuu · · Score: 1

      It's good not to think of it as "a small number of detractors, and a lot of supporters." The real breakdown is, "a small number of proponents, a small number of detractors, and a huge swath of people who don't know or care enough to have an opinion on the matter." The real question is, "what's the breakdown of people who actually know and care enough?" In that regard, it's a lot closer to 50/50, and honestly, I'd suggest the anti-systemd crowd is in the majority here. People who don't care about an issue shouldn't be counted as "on your side", because they'd just as easily be "on their side" if you weren't the default choice.

    8. Re: Question from a non-Linux user by dbIII · · Score: 1

      Incorrect. The lead developer and initiator of systemd has been at RedHat since before the project started.

    9. Re:Question from a non-Linux user by dbIII · · Score: 1

      They may just be fanboys who think new is always good as we see with the Wayland vs X comments from people who have seen either only one or none.

    10. Re:Question from a non-Linux user by dbIII · · Score: 1

      Yes, we're just greasy Moorlocks who only know how to run machines and not the pretty Eloi in the garden listening to marketing folk who are pushing a product that is not ready yet.

    11. Re: Question from a non-Linux user by kthreadd · · Score: 1

      That does not mean that everything he does on his spare time is done by Red Hat.

    12. Re:Question from a non-Linux user by Peter+H.S. · · Score: 2

      I have been using systemd since its inception, and it has been rock solid. It is better tested and documented than most other FOSS projects; a Jenkins back-end and Coverty scans, integrated self tests, and rather strict coding practise really helps too in that regard. Take fx. SysVinit; their developers doesn't even have build test framework, so the only way to test whether a new patch doesn't break everything, is to make a live boot. No wonder they haven't made a release for many years despite the patches are accumulating.

      Claiming that it isn't ready yet is just plain wrong and just seems to be some sorry excuse for not bothering to learn something new.

    13. Re:Question from a non-Linux user by Peter+H.S. · · Score: 4, Informative

      No, systemd detractors really is a tiny minority; some ways this really shows is how there are almost no developers working to maintain even critical needed infra structure for non-systemd distros; ConsoleKit has been abandoned for years now, eudev is just a shadow fork of udev with no independent development going on, and several key components like systemd-shim and cgmanager are only kept alive by paid Canonical developers and a few Debian devs; once Ubuntu and Debian shifts to systemd, those projects will languish too. SysVinit will properly also deteriorate completely; Red Hat/Suse was the defacto upstream before, and now it is only Debian as long as it last. So the non-systemd infrastructure will probably deteriorate further as the commercial distros stops to maintain it.

      In short, almost no developers are working on maintaining non-systemd infrastructure, this reflects how few the systemd-detractors really are.

      The recent Debian debate also show how few the systemd detractors really are when the numbers are shown: The system-detractors made a lot of noise on the Debian mailing list, but after the technical committee had decided that systemd should be the new Debian Linux init system, the detractors were unable to even gather 5 (like in five) Debian developers out of around 1000 to sponsor a vote on this subject.

      Even the GR bill trying to keep other init-systems equally supported was clobbered at the GR vote.

      So going by the noise on the mailing lists, the systemd-detractors seemed like a force, but when voting they where nowhere to be seen.

      Same with Linux distros; you would think that the non-systemd distro ranks would be swelling with the numbers of systemd-refugees. This certainly doesn't seem to be the case. A couple of rather obscure distros like Funtoo and Void are among the few distros that don't want to support systemd. Slackware is undecided on the issue, and Gentoo etc. support systemd, with a growing number of its users that prefer it to OpenRC.

      Also no medium/major commercial non-systemd Linux distro have emerged this last couple of years, this is a strong indication that the paying costumers wants systemd, and doesn't care at all for the alleged superiority of SysVinit. Several companies made it clear during the Debian debate that they favoured systemd, none spoke for SysVinit or Upstart.

      No wonder; systemd is great and it solves real world problems like daemon management and security much better than any other alternative.

    14. Re:Question from a non-Linux user by Eunuchswear · · Score: 1

      It doesn't "swallow stderr", it logs stderr output in the journal instead of losing it on the unconnected monitor. See journalctl and systemctl status.

      It doesn't "ignore exit statuses", it, unlike sysvinit, knows the exit status of all processes it starts. Check out the systemctl status command.

      One of the craziest things about systemd haters is they accuse it of doing the things that sysvinit does, that systemd is explicitly designed to fix.

      --
      Watch this Heartland Institute video
    15. Re:Question from a non-Linux user by dbIII · · Score: 1

      I'm using it and learning with each thing that breaks. Most recent was zfs and there were a few before that. If it hasn't ever caused you any trouble I doubt you've been using it much.

    16. Re:Question from a non-Linux user by Peter+H.S. · · Score: 1

      I'm using it and learning with each thing that breaks. Most recent was zfs and there were a few before that. If it hasn't ever caused you any trouble I doubt you've been using it much.

      zfs has been working for years now with systemd, despite it not being part of the Linux kernel and therefore not really supported by many major distros.

      So if you are experience troubles, it is most likely distro specific troubles like using a distro that haven't converted to systemd yet (Debian) or using zfs on a distro that didn't officially support it in the first place (CentOS/Fedora) and perhaps because you haven't read the zfs support docs carefully enough.

      The systemd bugs I have encountered have been really trivial and not pertaining to core functions; it has never let me down by not being able to stop or disable daemons, or having run away processes, or suddenly consume lots of memory or cpu time. It is far better than SysVinit and Upstart in that regard too.

    17. Re:Question from a non-Linux user by DrXym · · Score: 1

      And this horseshit is modded insghtful?

    18. Re:Question from a non-Linux user by DrXym · · Score: 1

      Yes it's all a vast conspiracy. Meanwhile back on planet earth...

    19. Re:Question from a non-Linux user by Eunuchswear · · Score: 1

      Damned but you are not just a lying troll, you are also an idiot.

      Script started on Sat 07 Mar 2015 07:58:37 PM CET
      [root@centaur ~]# cat /etc/redhat-release
      CentOS Linux release 7.0.1406 (Core)
      [root@centaur ~]# grep ExecStart /usr/lib/systemd/system/named.service
      ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf
      ExecStart=/usr/sbin/named -u named $OPTIONS --broken
      [root@centaur ~]# systemctl start named.service
      Job for named.service failed. See 'systemctl status named.service' and 'journalctl -xn' for details.
      [root@centaur ~]# echo $?
      1
      [root@centaur ~]# systemctl status named.service
      named.service - Berkeley Internet Name Domain (DNS)
        Loaded: loaded (/usr/lib/systemd/system/named.service; disabled)
        Active: failed (Result: exit-code) since Sat 2015-03-07 20:00:11 CET; 27s ago
        Process: 2344 ExecStart=/usr/sbin/named -u named $OPTIONS --broken (code=exited, status=1/FAILURE)
        Process: 2343 ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf (code=exited, status=0/SUCCESS)
       
      Mar 07 20:00:11 centaur named-checkconf[2343]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
      Mar 07 20:00:11 centaur named-checkconf[2343]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
      Mar 07 20:00:11 centaur named-checkconf[2343]: zone 0.in-addr.arpa/IN: loaded serial 0
      Mar 07 20:00:11 centaur named[2344]: usage: named [-4|-6] [-c conffile] [-d debuglevel] [-E engine] [-f|-g]
      Mar 07 20:00:11 centaur named[2344]: [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username]
      Mar 07 20:00:11 centaur named[2344]: [-m {usage|trace|record|size|mctx}]
      Mar 07 20:00:11 centaur named[2344]: named: unknown option '--'
      Mar 07 20:00:11 centaur systemd[1]: named.service: control process exited, code=exited status=1
      Mar 07 20:00:11 centaur systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
      Mar 07 20:00:11 centaur systemd[1]: Unit named.service entered failed state.
      [root@centaur ~]# exit
       
      Script done on Sat 07 Mar 2015 08:01:10 PM CET

      --
      Watch this Heartland Institute video
    20. Re:Question from a non-Linux user by gweihir · · Score: 1

      Sounds all very impressive, but that changes very quickly on closer inspection. For example, Coverty gives you pretty graphs, but is fundamentally broken in many regards. My take is that the tools and coding practices are used only because the while complex KISS violating mess would come tumbling down immediately otherwise. That does not make systemd better. It makes it worse as it is so complex is not had dependencies on tools. Of course this also means external contributors can easily be fended off, as nobody can afford the licenses on their private budget.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    21. Re: Question from a non-Linux user by kthreadd · · Score: 2

      And you know and trust this person and Red Hat management to not lie about it?

      Given that they were heavily pushing Upstart at the time, yes.

      To me this sounds like an all too convenient artificially created "legend" of the heroic single developer that changed the world. In other words, complete BS.

      He has obviously not done it alone, just check the git commit log.

    22. Re:Question from a non-Linux user by Peter+H.S. · · Score: 1

      You seem to be somewhat confused here:

      Coverty is static code analysis that find potential stability and security problems. https://scan.coverity.com/
      Think "Unix Lint".

      Many FOSS projects like the Linux kernel and LibreOffice uses Coverty. It isn't a magic wand, but it plain works nevertheless. No systemd contributor needs a licence in order to contribute to systemd, even if they get commit access. Coverty can trivially be replaced or complemented by other static code analysers, or even be omitted; it is something helpful, not something systemd depend upon.

      The Jenkins builder provides: "Continuous Integration with automated test execution", something that really improves code stability since it ensures that eg. a patch isn't committed if it breaks the build.

      Again, no contributor needs any kinds of licence for this, and again, this is a nice to have thing, not something systemd depends upon.

      You seem to be arguing against code discipline and the use of automated tools, just because systemd have them (while SysVinit doesn't). That is just bizarre.

      Anyway, systemd's developer community is extremely vibrant and growing all the time; there are hundreds of people who have contributed already with new ones coming every month. So there doesn't seem to be anything that scares contributors away, unlike, sorry for putting the boot in, the tiny and deteriorating non-systemd developer eco-system.

    23. Re:Question from a non-Linux user by Peter+H.S. · · Score: 1

      Seriously? Try again. I am not confused at all. But you are blind to what is happening.

      But you really seems to be very confused since you erroneously talk about systemd contributors needing to pay licensing fees: "Of course this also means external contributors can easily be fended off, as nobody can afford the licenses on their private budget.

      That is just totally misunderstanding how things works, so it really seems like you are very confused about even basic facts how systemd is developed.

    24. Re:Question from a non-Linux user by gweihir · · Score: 1

      I am not confused at all, you have a reading comprehension problem. I am talking about a _possibility_, quite obviously. It goes like this: "Sorry, your patch did raise red flags in Coverty, please fix it and submit again." And this way every contributor that is unwelcome can be neatly fended off. Or have you forgotten how systemd is _actually_ developed? There are now enough examples around to know that the project leads are very full of themselves and do not play nice with others at all. "God complex" seems to be a fitting description.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    25. Re:Question from a non-Linux user by dbIII · · Score: 1

      Fedora - was working then broke again.
      Systemd is a moving target and things do break from time to time, which you would be aware of if you have the exposure to it that you pretend to have.
      How did you go converting init scripts to it - oh you haven't even done that much before putting yourself up as an authority?

    26. Re:Question from a non-Linux user by Peter+H.S. · · Score: 1

      Fedora - was working then broke again.

      Ah, so you where trying to use zfs on Fedora, despite that this isn't supported. Problems may occur in such cases but the problems have nothing to do with systemd since systemd works fine with zfs.

    27. Re:Question from a non-Linux user by Peter+H.S. · · Score: 1

      Yes you are confused about several things, including licensing payment.
      Your claim that people are discouraged from contributed because Coverty/Jenkins may discover that their patch have security issues or breaks the build is laughable; of course such patches should be rewritten, and the submitter would be glad they such problems was discovered. Asking the submitter to rewrite the patch, or that the developer with commit access fix it, is everyday work in FOSS land. It happens all the time and it discourages nobody; this is something the submitter learns from.
      Really, should the alternative be to accept every broken patch just so not hurt the submitters feeling? I don't think anybody wants that.

      Regarding your claim that the systemd developers don't play nice to others and suffer from "God complex" (talk about hyperboles), then this is plain wrong:

      You can find lots of statements from people actually contributing, even small patches, that the systemd developers where really friendly and helpful. The proof is also in the numbers; there hundreds of such minor contributors to systemd, something that strongly indicate a good and including developer community. Compare that to the almost non-existing non-systemd developer eco systems.

      Sure, the systemd developers sometimes says no to certain patches or features, but again, this isn't having a "God complex" but about project leadership and the technical know-how to reject things that are bad for the project. This happens in all FOSS projects.

    28. Re:Question from a non-Linux user by dbIII · · Score: 1

      And other stuff but that was the one three weeks ago.

    29. Re:Question from a non-Linux user by byuu · · Score: 1

      You're welcome to tell yourself whatever narrative you want to ignore the criticism. I really don't care, even if you are right (and I still think you aren't.) I abandoned Linux for the BSDs over this, as I suspect many others have, and I'm not looking back. I found a system that was far cleaner, far leaner, less dogmatic about licensing (eg I don't have to run broken-as-hell cdrkit, I can use the proper, working cdrtools; firefox isn't renamed to something stupid like iceweasel; etc), with a better file system, network packet filter, with better all-around design (of eg /dev/random, no /proc, etc) and superior leadership (luminaries such as PHK.) Of course, the more people that follow suit, the more unanimous you'll think systemd support is. But oh well.

    30. Re:Question from a non-Linux user by gweihir · · Score: 1

      I am still not confused at all. But I now know what you are doing: You try to twist my words.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    31. Re:Question from a non-Linux user by Peter+H.S. · · Score: 1

      I am not twisting your words. Let me quote you verbatim:

      That does not make systemd better. It makes it worse as it is so complex is not had dependencies on tools. Of course this also means external contributors can easily be fended off, as nobody can afford the licenses on their private budget.

      Isn't it straight up obvious that you claim that external contributors can be fended off because they can't afford licenses? Isn't this exactly what you are claiming?

      Since this claim is totally untrue, isn't it then obvious that you are utterly confused about how Coverty and Jenkins work, and have no clue whatsoever on how systemd development is done?

    32. Re:Question from a non-Linux user by ookaze · · Score: 1

      The SystemD crowd are windows devs who hate 8 so much, they finally decided to get into linux. Sadly, they want linux to work like windows, so they foist their shit into it. It does make boot times faster: something sysadmins usually don't give a shit about since you don't reboot servers. Red Hat wants systemD because it will let them abstract linux (the kernel) away to the point where they can control it instead of "the community". In addition, several genuinely nice tools, UUID for disks, are being folded into SystemD so, in order to get those tools, you *must* also use SystemD.

      Isn't that supposed to be funny? People on Slashdot actually believe this load of bullshit?
      UUID for disks folded into systemd? systemd crowd (developers?) are windows devs? sysadmins don't reboot servers?
      If that's the "knowledge" of the new wave of Linux users, I guess old Linux sysadmins won't have to fear for their jobs.

      Essentially it's being bundle in with other services.

      That's the only truth in this post till now.

      Sadly, SystemD is not well tested enough for most people running linux on a server to trust it especially since the guy who wrote it wrote PulseAudio and people are still having issues related to that piece of shit.

      Another lie. The main problem of systemd is that there's so much to do given the state of Linux init systems, that it's still a fast moving target, too fast for distros. It will stabilise when most of the features are implemented.

      Pros:
      * Boots fast

      Cons:
      * When it breaks, you're fucked
      * Obsoletes 20-30 years of accepted best practices and knowledge of how to use linux tools
      * No real new features
      * Is network connected and running as superuser
      * Is unaudited
      * Is virtually untested
      * Was written by a raging moron
      * Is completely unneeded by a large section of people who have run linux for a long time

      Essentially, it's the Windows 8 of the *nix world

      This shows a lot of ignorance on even how a Unix like system works. Init is launched by the kernel, so of course it runs as super user, and no, it's not network connected, not PID 1 at least. The rest is drivel or nonsense, like it obsoletes 20-30 years of best practices and knowledge, this makes no sense, I can operate my servers with best practices that I couldn't use with sysvinit, and I still use the linux (you mean GNU?) tools the same with systemd.
      Executables configuration scripts (init scripts) are not at all best practice, even less when they use configuration files of their own, scattered in several different files, and whose behaviour can be modified by the environment, making for a huge attack surface that can go undetected. That's what you call best practices? And calling people names doesn't make your argument any better.

  16. No. by waspleg · · Score: 4, Interesting

    I just installed Linux Mint 17.1 Cinnamon (Rebecca release) on the machine I'm typing from this week. While it does have some things I don't like (some weird config location choices, /var/run, /etc/bash.bashrc, bash_completiond,WTF is up with dnsmasq?, some weird sound behavior, semi-broken bash tab completion, won't mount my cellphone no matter what, etc - aka issues I've never had with CentOS).

    I also still have 2 several years old but up to date CentOS boxes I use every day and prefer them but I picked Mint because it's supposed to be better for day to day regular desktop use, has far more up to date packages, and I was tired of fighting dependency hell with extra packages from 2008 (my own fault, admittedly) for things like VLC.

    My understanding, and I can't find where I read it before I went and downloaded/installed it, is that Mint is in wait-and-see mode and will be waiting until their next LTS release in a few years and then re-evaluating whether to switch to systemd. Looking at the system I have installed right now, it looks like there are a few pieces installed for compatibility (although none of them are running) but the init system is still old school init.d and runlevels.

    I haven't looked at systemd in depth but my gut feeling is it throws away the UNIX mindset of, do one thing and do it well, output/input everything in text in favor of aping Apple (paritcularly)/Microsoft and the politics behind it seem dirty. I have watched a few Poettering videos and he comes off as a massively arrogant douche bag (but I am a fan of Linus and RMS so *shrug*).

    $.02

    1. Re:No. by DoofusOfDeath · · Score: 3, Informative

      I'm using Mint 17, and I also had trouble getting it to mount my Galaxy Note 4. FYI, I was able to solve it with about 15-20 minutes of Googling + a reboot.

    2. Re:No. by phantomfive · · Score: 1

      I have watched a few Poettering videos and he comes off as a massively arrogant douche bag (but I am a fan of Linus and RMS so *shrug*).

      How do you feel about Theo?

      I think there must be some deep psychological understanding you can come to based on people's reactions to Linus, RMS, Theo, and Poettering, but I have no idea what.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:No. by fahrbot-bot · · Score: 3, Insightful

      I have watched a few Poettering videos and he comes off as a massively arrogant douche bag (but I am a fan of Linus and RMS so *shrug*).

      How do you feel about Theo? I think there must be some deep psychological understanding you can come to based on people's reactions to Linus, RMS, Theo, and Poettering, but I have no idea what.

      All four of them are massively arrogant, though three have earned it and deserve some respect, but only one is a douche bag.

      --
      It must have been something you assimilated. . . .
    4. Re:No. by ckatko · · Score: 1

      While I am not qualified to discuss the merits of systemd, I do absolutely know this:

      Unix Philosophy is wonderful.. but systemd isn't the first, or biggest violator. Everything in Linux violates that philosophy to a degree. I mean, have you ever checked the man page for ls? (5 pages) mail? (10 pages) Or my god, ssh? (16 pages

      Let's all stop using "unix philosophy" as a method to decide a piece of software is bad, because 99% of the software we DO like is already violating it. Let's not make it look like we're using it as a "tool to make a decision," when in reality we're using it as a "source to reinforce our already-made-up decisions."

    5. Re:No. by organgtool · · Score: 1

      It's worth knowing that despite the fact that Mint is based on Ubuntu, it does not support dist-upgrade. When you want to upgrade releases, their solution is for you to back up your system with a special tool, wipe your system clean, create new boot media, install the new OS, and restore from your backup. This was enough to push me back to Xubuntu. Mint was nice, but Xubuntu is nearly as nice and much easier to upgrade. I just thought you should know before you get too heavily invested in the distro.

    6. Re:No. by afseraph · · Score: 1

      This is not true. I upgraded my Mint from 16 to 17 with dist-upgrade. And now with the new GUI system updater it's even simpler. Upgrade from 17 to 17.1 was just a matter of a few clicks. No backuping, wiping and restoring needed.

    7. Re:No. by strikethree · · Score: 1

      FYI, I was able to solve it with about 15-20 minutes of Googling + a reboot.

      My my, how far we have come. How much more like Windows can we get?

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    8. Re:No. by toddestan · · Score: 1

      C'mon guys. I have the same problem. What registry setting did you change to get it to work?

    9. Re:No. by Blaskowicz · · Score: 1

      It's a conservative, "cover you ass" statement given that is not unreasoable considered the distro is meant for grandmas and joes not only computer geeks.
      The dist-upgrade from Mint 16 to 17 I did went good : 99.99% of everything went perfect and eventless, except there were a couple blocking issues that required me to do some "sysadmin" work.
      A "supported" upgrade from lenny to squeeze on a very simple desktop system required much more babysitting and pampering from me.

      Now : what you miss is this is history, as Mint has concentrated on Ubuntu LTS and soon debian stable upgrades are now explicitly supported (if you start from Mint 17)

  17. This is degeneration by choke · · Score: 1

    I guess the waves of less technically apt engineers is driving the project now. Congrats, you've turned linux into something I wouldn't move to from Solaris because it actually sucks the same or worse.

    --
    "No good deed goes unpunished"
  18. themes and skins? by bmajik · · Score: 5, Funny

    I won't use systemd until it is themeable, or at least skinnable.

    Also, where are all the good screenshots showing cool systemd setups?

    --
    My opinions are my own, and do not necessarily represent those of my employer.
    1. Re:themes and skins? by Gunstick · · Score: 1

      I would like to have the ASCII theme for the log deamon instead of the sandard BINARY theme

      --
      Atari rules... ermm... ruled.
  19. Why binary logging? by mike2006 · · Score: 1

    How did this get past consensus? It almost seems like the plan is to make Linux more like Windows.

    1. Re:Why binary logging? by ZorinLynx · · Score: 1

      Keep in mind the binary log is just the internal format it's stored in for systemd. You can configure rsyslogd just as before to log to plaintext files.

    2. Re:Why binary logging? by gweihir · · Score: 1

      No "almost" about it. Just look at the frank disdain Poettering displays for tried-and-true Unix principles. These principles are what makes Unix worthwhile doing and superior and that is no accident at all.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re: Why binary logging? by kthreadd · · Score: 2, Informative

      Systemd stores a lot of metadata in the journal, not just simple text rows. A custom format allows this to be queried very quickly.

    4. Re: Why binary logging? by gweihir · · Score: 1

      Again that "speed" fallacy. If you need to look into the syslog, then you are debugging a problem. Speed is pretty immaterial. Completeness is critical. But it is no surprise that the systemd-crowd does not understand the purpose of logging. I mean, they even had a major run-in with Linus because they have no clue about the established ways logs are handled. (And no, deviating from them unless there is a real need is not called "progressive", it is called "stupid" and "arrogant".)

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re: Why binary logging? by mike2006 · · Score: 1

      What you posted seems so obvious to me. It get caught between figuring these guys are brilliant so lowly me must be missing something or there are political motivations behind it.

    6. Re: Why binary logging? by gweihir · · Score: 1

      My money is on political. Interestingly you will find many systemd advocates that will claim what I posted is completely wrong, but will not be able to give any good reasons.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    7. Re: Why binary logging? by gweihir · · Score: 1

      I _already_ can and do handle logs like I want. I have zero reason to hand them to systemd first and zero intention of ever doing so. There is also the little problem that I have to handle logs by other people on occasion and making them use an inferior solution (systemd) makes my work harder.

      Fortunately, RHEL faces really stiff opposition (needs some insider-knowledge so see), not only because some problematic, instable and in-transparent monster is handling the system init. One group is people that want to get away from Solaris, just to find that RHEL 7 is actually _worse_.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Why binary logging? by MoonSweep · · Score: 1

      Keep in mind the binary log is just the internal format it's stored in for systemd. You can configure rsyslogd just as before to log to plaintext files.

      You can configure rsyslogd just as before to log to crippled plaintext files.

      FTFY

  20. Re:Another one bites the dust... by TheBilgeRat · · Score: 2

    Er...not Archlinux... ( cached page as the original seems to be down )

    In fact, Arch adopted it pretty early on. Its Slackware, Crux, or Gentoo these days, unless you head on over to BSD land...

  21. Gentoo FTW by Maltheus · · Score: 4, Insightful

    Ubuntu is geared more toward people who don't care much about managing the boot details. So I think it might make sense for them. I chose my distro based on how much control it gave me. And luckily, they still seem committed to OpenRC. When it comes to booting, keep it simple!

  22. Why systemd took over by jbernardo · · Score: 4, Interesting

    There are several main reason why systemd has overrun some of the best known distros. On of the biggest is simple. Gnome depends on it, and soon KDE will too. Distro maintainers either bend over for systemd, or will spend a lot of time patching and trying to get these two desktops working on GNU/Linux.

    Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.

    Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.

    But what do I know, I've been told enough times that I am heretic (hater in doubleplusgood newspeak) for daring to criticise systemd.

    1. Re:Why systemd took over by Marginal+Coward · · Score: 1

      There are several main reason why systemd has overrun some of the best known distros. On of the biggest is simple. Gnome depends on it, and soon KDE will too. Distro maintainers either bend over for systemd, or will spend a lot of time patching and trying to get these two desktops working on GNU/Linux.

      Thanks, that's interesting. I always thought one of the strengths of Linux was that the OS was highly separated from the GUI. However, you're suggesting that the two dominant Linux GUIs are driving the design of the OS. Windows and Mac users have always been used to these things being intimately tied together (and therefore not having to/getting to decide which GUI they'd like to run on their chosen OS), but I would think that a system where the OS and GUI were separate and distinct would carefully retain that.

      In that context, it might be OK for a GUI to influence the OS in some way, but hopefully such influence would be only around the edges rather than something as consequential as requiring systemd.

    2. Re:Why systemd took over by jbernardo · · Score: 1

      The main push has been from Gnome. KDE only very recently, and almost in secret (in a comment made by one of the developers in a blog post) announced that they had decided to drop support for the alternatives in kde5.6, due in less than 6 months.

      Unfortunately gnome seems to drive many distros - and as it happened with pulseaudio, now they are driving systemd adoption, not only on distros that use it as the main desktop, but also on derivatives.

    3. Re:Why systemd took over by Peter+H.S. · · Score: 2

      Thanks, that's interesting. I always thought one of the strengths of Linux was that the OS was highly separated from the GUI.

      Don't believe him, what he says is demonstrably untrue. Both KDE and Gnome runs just fine on non-systemd distros and on BSD. This couldn't happen if they somehow where totally dependent on systemd.

      The real story is that systemd provides some very needed OS infrastructure that Desktop Environments (DE's) like KDE and XFCE needs. The old non-systemd infrastructure that DE's could use instead, like ConsoleKit (CK), hasn't been maintained for years. The DE developers have warned the non-systemd distros for years that they needed to maintain CK, or that things would stop working, but they were ignored.

      So Gnome, KDE, XFCE etc. still have support for non-systemd distros that are using eg., CK's login API, but things are beginning to fall apart since nobody have bothered to maintain that for years.

      The point is that that Gnome and KDE played no role in why all major Linux distros have shifted to systemd. The simple fact is, that systemd simply is light-years ahead of any competing init-system; integrated groups support so each and every process can be controlled regarding resources, no more hard to write and debug shell scripts to start daemons (executable config files; who thought that was a good idea?), integrated kernel Capabilities(7) to provide defence in depth for all running daemons etc.

      Read here for more reason to what systemd can and why it was developed:
      http://0pointer.de/blog/projec...

    4. Re:Why systemd took over by Eunuchswear · · Score: 1

      On of the biggest is simple. Gnome depends on it

      And oft repeated claim, that happens to be untrue.

      Gnome depends on some facilities of systemd, but those same facilities can be provided by things other than systemd (consolekit, systemd-shim, loginkit, maybe uselessd or systembsd if they get their act together).

      https://blogs.gnome.org/ovitters/2015/02/24/consolekit-in-gnome-3-16-and-beyond/

      --
      Watch this Heartland Institute video
    5. Re:Why systemd took over by Eunuchswear · · Score: 1

      Perhaps you would like to point to a set of current Gnome packages that dont have any SystemD dependency?

      How current do you want?

      https://forums.freebsd.org/threads/gnome-3-14-port-is-solid.49299/

      Or do you think FreeBSD runs systemd now?

      --
      Watch this Heartland Institute video
    6. Re:Why systemd took over by ookaze · · Score: 1

      Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.

      Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.

      What you are saying doesn't compute. If the init scripts were working well in the last 20 years, why do you need distro maintainers to maintain them? Why is there the fear of these init scripts rotting away if not tend for?
      Real sysadmins who have worked with these damned init scripts and are not lying to themselves know perfectly why.
      Init scripts are flawed by design on a dynamic kernel like the Linux kernel, and this problem was there before 2000 already.
      That's actually one of the main huge benefit of systemd, with gettiong rid of executable configuration files (init scripts), which are a huge surface attack on any sysvinit system. I have seen countless security issues related to bad things done in init scripts, like for example creating temporary files or directories, which is handled securely by systemd.

    7. Re:Why systemd took over by jbernardo · · Score: 1

      Nice straw man you got there. I didn't even talk of init scripts vs binary crap in my message. But I'll bite.

      Init scripts have been the best solution for over 20 years, not because distro maintainers need to maintain them, but, unlike huge binary hydras obscuring the functionality, they are easy to debug and fix by a sysadmin with only small, standard and tested tools, like vi, cat, etc. When systemd breaks, you are on your own. Either you can take out the disks from the machine and try and open the obfuscated logs in another PC, or you can boot a full distro on a usb stick and do the same. In both cases, pray that the logs haven't been corrupted, as it usually happens when systemd fails to shutdown or reboot. But worst, and more important - if it is a bug in systemd or some of your use cases that isn't supported by the devs, you are well and truly fucked.

      You can fuck things up with scripts, sure. The power they give might be misused by some "windows admin". But real system administrators prefer scripts to a unfixable blob with init files, because they know that scripts allow them to be in control of their systems and of being able to support their use cases, instead of having to beg to some rude, conceived developer, for a fix that most of the times will be refused because said developer doesn't see the use. And even if the request is gracefully granted by the magnanimous dev, then the sysadmin will have to wait for months until the package is available for the distribution he is running. A really good idea...

      Replacing an (imagined) attack vector with a huge, real one, and losing functionality in the way can only appeal to those who have never known anything else than windows and are afraid of the complexity and the power of a truly configurable system. Really, replacing a simple init with a great collection of scripts by a huge monster, which has everything from process management to IPC to time and date to networking to binary logging inside or tied up to it? Can anyone who is not deluded or a liar claim that it isn't a huge security disadvantage?

  23. systemd AND daylight saving time on Monday by turkeydance · · Score: 1

    i want to see the emails/texts/video for that first work day.

  24. What's the big deal with systemd by hyperar · · Score: 1

    I'm completely ignorant about Linux, i've installed it on my pcs a few times and never boot it up again after that. I want to know, what is the motivation behind systemd?, It seems like a lot of trouble to fix something that wasn't broken, and considering the love/hate reaction of the community, i wonder why was it developed on the first place?

  25. Re:Another one bites the dust... by Barsteward · · Score: 1

    "kids" describes you well. don't you mean Slackware and Gentoo?

    --
    "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
  26. Not ready for prime time by Todd+Knarr · · Score: 1

    I run servers on Linux. My attitude: if testing of a new component is so incomplete that there's still a concern for significant bugs and regressions when it goes into production, it's not ready to go into production. If I told my managers "Throw it into production and if it breaks things too badly we'll roll it back.", they'd tell me to get a proper test plan written like I should have the first time (assuming they didn't fire me for incompetence, since decent testing is both best practice and a company standard). And this is for mere application software, not a critical part of the boot process where a failure has the potential to render servers in the data center not remotely accessible.

    1. Re:Not ready for prime time by thule · · Score: 1

      I run Fedora/RHEL boxes. Fedora 15 had some issues when it introduced systemd. I haven't had issues since. RHEL7 has been smooth. Try using a mature systemd distro and see if it works for you.

    2. Re:Not ready for prime time by Zan+Lynx · · Score: 2

      Oh yes. I am so sure that your test plans include such unlikely things as your customers deciding to run your app on a Pentium III with no SSE support. That's when you discover that the compiler settings are defaulted for SSE support. Or you discover that a shared memory file is being used by an old software version and a new software version at the same time, resulting in disagreements about exactly what should be locked when. Or maybe you find out that if a customer opens more than 1024 file descriptors your app starts to get silent memory corruption and eventually crashes. (POSIX, select(), FD_SET with fds higher than FD_SETSIZE). Did you check every single POSIX resource limit before using the system libraries? Did you do it correctly?

      You can have 100% test coverage and still fail in the real world because of issues with the hardware, libraries and operating system.

      You surely must realize that the real world contains so many possible ways to break software that you can't possibly test them all. At some point you just have to go for it.

    3. Re:Not ready for prime time by gweihir · · Score: 1

      I fully agree. This is not about good engineering, this is about pushing things on users by force.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:Not ready for prime time by Todd+Knarr · · Score: 1

      All but the first are standard items that should be covered by normal testing (they would be where I worked, at least). The first is a build-environment issue, and I'd expect Ubuntu to audit the build options for every single package they bring into the distro to make sure they're correct for what Ubuntu wants to support by way of CPUs, hardware and so on.

      Yes, you can always miss problems. However, by the time we got done with QA and final testing (trial installation into a replica of production and a set of acceptance tests to make sure it was really running correctly), we were pretty confident we'd caught everything we could think of. We had a rollback plan and were prepared to use it, but we weren't expecting to need it and we rarely did need it. It was a big thing if we did, resulting in a lot of "What was the problem, how did we miss it in testing and what do we need to do to make sure we don't miss that kind of thing again?" and modification of the test plans so we wouldn't have a repeat in the future.

      This kind of thing is what a beta release is for, and everything I'm hearing from the systemd team and supporters says it ought to be in beta right now getting exposure to real-world environments to nail down any incompatibilities and fix them before release.

  27. Great consolidation GWeihir! by See+Attached · · Score: 1

    There are many reasons Systemd is a departure from what makes Linux great. (see above) Those that were part of that explosion are disenfranchised because the system feels more cathedral than bazaar http://en.wikipedia.org/wiki/T... . What's good for a laptop is not necessarily good for a server. We can fix init, but don't have to change the ethos so dramatically. How Redhat will put systemd into its products is another matter. Systemd's scope of controls seem to spread like Kudzu. A RHEL release is supposed to be feature-static. Is this a good place to fork into a server OS branch and a laptop OS branch?? The latter festooned with Systemd, at least till it stabilizes for the former?

    --
    Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
    1. Re:Great consolidation GWeihir! by gweihir · · Score: 1

      Thanks.

      As to server vs. "laptop" distro, I have absolutely no issue with that. I could then put the server distro onto my laptop and be free of systemd. As I do not use all these newfangled window managers anyways (fvwm for 25 years now, has everything I need), I care very little about what "desktop" comes with a distro.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re: Great consolidation GWeihir! by kthreadd · · Score: 1

      Fvwm has been around for 22 years so saying 25 years is probably almost correct. It was actually quite popular back in the early 90s.

    3. Re:Great consolidation GWeihir! by gweihir · · Score: 1

      As some people have pointed out I miscalculated here. With a close look on my CV, I have determined that I was apparently among the users of the first fvwm release in 1993, which would be 22 years ago. (This was on my first SunOS account at university. Alternative was CDE, which was basically unusable in comparison.) I still use it and see zero need to switch and I fully expect to use it for the foreseeable future. It has everything I need, and the pager is just exceptionally good. Without at least 6 virtual desktops I am not happy.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  28. Re:Delicious geek tears. by gweihir · · Score: 1

    Hahahahahahaha, just thinking that somebody could actually be this cretinistic made my day. Unfortunately, I guess you are a honor-less paid-for liar, and that is just sad.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  29. INI files vs the Registry by justthinkit · · Score: 2

    pre-systemd : systemd :: INI files : the Registry

    --
    I come here for the love
    1. Re:INI files vs the Registry by Eunuchswear · · Score: 1

      systemd has no registry. It does have a bunch of files that look suspicously like INI files.

      --
      Watch this Heartland Institute video
  30. MCP? by Ungrounded+Lightning · · Score: 1

    I don't have a firm opinion yet on the internals and suitability of systemd, or whether its improvements are worth the thrash. Having been burned by a number of changes (including, notably, init -> upstart), I'm likely to be a hard sell on the cost-benefit tradeoff of "fixing'' what it purports to fix.

    But the discussion around it makes it remind me of a movie "character":

    The Master Control Program in Tron.

    --
    Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
  31. loose coupling would be a good thing by pereric · · Score: 1

    It seems highly illogical that even a desktop environment should depend on a particular piece of init software. It Loose coupling - it's a good thing ...
    Maybe if we could have some standard that both upstart and the more byzantine init deamons could parse. Perhaps like the extra parseable properties in init files.

    1. Re:loose coupling would be a good thing by phantomfive · · Score: 1

      Gnome doesn't have a hard dependency on systemd. The systemd team was pushing for that, but the Gnome team made it an optional dependency.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:loose coupling would be a good thing by Eunuchswear · · Score: 1

      The systemd team was pushing for that, but the Gnome team made it an optional dependency.

      It was Lennart Poettering who wrote the code that made it an optional dependancy. Is he "the Gnome team" or "the systemd team"?

      --
      Watch this Heartland Institute video
    3. Re:loose coupling would be a good thing by phantomfive · · Score: 1

      I was referring to this. Consolekit is deprecated, now the options are systemd and systemd-shim, or systembsd. Some people are saying that if you don't use systemd, then you lose functionality, but I haven't had time to look into that yet.

      --
      "First they came for the slanderers and i said nothing."
  32. embracing change by dltaylor · · Score: 1

    I've been running various *nix since AT&T Version 7 and UC BSD on VAXen. I'm hardly "uninformed". I know the intent and philosophy of systemd and the history of its creator; neither of those is acceptable.

    The "change" I am embracing is back to *BSD (OpenBSD, currently).

  33. Why are slashdot comments always about systemd? by thisisauniqueid · · Score: 1

    Oh wait, in this case the story is, in fact, about systemd.

  34. Devuan? Also, why does Debian suck so bad now? by walterbyrd · · Score: 1

    I used to love debian.

    When I heard about devuan, I thought I would install debian 7.6, then upgrade to devuan when systemd/debian 8 came out.

    Debian is much worse than I remember. Debian used to have the best package management in the business, not anymore.

    I cannot install plex, kodi, or mediabrowser, on debian 7.6. As I understand it, all of those install easily on Ubuntu.

    This makes me wonder about how well package management will work with devuan. I am beginning to suspect that anything that does not have systemd will not install packages very well. I suspect this may even affect FreeBSD ports.

    1. Re:Devuan? Also, why does Debian suck so bad now? by Clopnixus · · Score: 1

      I'm running Plex media server on Debian 7.6 without problems.

      I followed this thread on the Plex forums - https://forums.plex.tv/index.p...

  35. Re:What. the . fuck by walterbyrd · · Score: 1

    > whats the best ubuntu fork that will support the "old" init.d system?

    There is "Devuan."

    Devuan is a Debian fork, not an Ubuntu fork.

  36. In Soviet Russia, the Kernel switches YOU! by Thor+Ablestar · · Score: 1

    The switch to FreeBSD does not solve the problem if there is a critical piece of code that is suddenly made dependent on something Linux-specific but not implemented in FreeBSD.

    It has been mentioned that GNOME is systemd-dependent. I don't know whether it's true or not but if it's true then Gnome and a lot of software that depends on Gnome would be broken.

    Due to transition of Xorg Radeon drivers I lost about 30000 Rubles ($1000 that time) in unusable hardware, and the KMS mess continues since it requires the Newcons which requires UTF-8 instead of KOI-8 which requires a lot of dependent ancient systems to migrate to UTF-8 too. And since in these systems there are lots of operators such as output_string[5]=RUSSIAN_LETTER_Y; the dumb recode will not help. Luckily I have the source.

  37. In Soviet Russia, the Kernel understands YOU! by Thor+Ablestar · · Score: 1

    Not only Unix manpages. Long time ago, when computers were big, I was able to understand all the source code of Unix version 6 kernel except the little piece with commentary "You are not expected to understand this". There were more commentaries than the code itself. Now, I cannot understand about 90 per cent of current FreeBSD kernel.

  38. Re:FreeBSD by Thor+Ablestar · · Score: 1

    You are running FreeBSD until the first port that is Linux dependent. If this port is critical (such as part of Xorg, which has already been with Radeon KMS) - you either get a barebone unusable system or throw your hardware to the wastebin and buy the new one, with supported drivers.

  39. Re:FreeBSD by byuu · · Score: 1

    I switched to VESA. I'm not shitting you, either. I found a card that handles my native widescreen resolution, and I'm going to keep that card as long as humanly possible. I might even go buy a few more of them for backups. VESA is slow out of the box, but when you use tools to set the MTRR to write-combine (FreeBSD ships such a tool called memcontrol), then it speeds up by more than an order of magnitude (no exaggeration.)

    So long as you're not playing hi-res 3D games (I'm not), problem solved. I don't have to deal with nVidia binary blob kernel panics, I don't have to deal with AMD rendering bugs, I don't have to deal with Intel GPUs only coming on certain motherboards and lacking PCIe cards, etc.

    I suspect that what's going to happen with systemd requirements will be a combination of systemd emulation (OpenBSD already working on it), patching out code, and eventually just freezing ports at older versions. The most major software programs aren't going to become dependent on this crap, because they already need to run on Windows, OS X, etc. Even in the worst case scenario, we're going to be fine for at least another decade.

    In the very, very long-term ... the solution could well end up being that FreeBSD and Linux diverge to their own display servers and software stacks. I've been starting on some work to that effect, myself, but am going about it top-down (starting at the UI toolkit) rather than bottom-up (from the display server.)

  40. RHEL/CentOS adoption often a version or two behind by dbIII · · Score: 1

    Also commercial software development is slow so RHEL 7 and systemd is not even on the radar of a lot of people that run RHEL or CentOS. As an example, I'm upgrading a machine to CentOS 6 this weekend because a version of some software that doesn't need RHEL5/CentOS5 has finally become available.

  41. But systemd is the thing getting in the way by dbIII · · Score: 1

    Sticking to old and reliable has it merts too but not when it gets in the way of trying something new.

    That's the thing, systemd DOES GET IN THE WAY OF TRYING SOMETHING NEW since it's no longer easy to have your own init scripts for new things, especially since systemd is a fast moving target so your new init scripts may not work for long (eg. the linux zfs project init scripts for systemd).

  42. KDE is only soft-depending on systemd by Phil+Urich · · Score: 1

    It's for the sake of niceness (well, security and consistency) with locking/unlocking a session. KDE can be run just fine without systemd, just regresses slightly (to how it has acted in all times previously) without systemd.

    Frankly, that's the completely sensible way to act towards systemd, and I would be baffled why GNOME didn't follow a similar path if I didn't know that the GNOME and systemd camps are both heavily connected due to Red Hat (the same folks have long talked about the concept of "GnomeOS", and Poettering has called the kernel a mere "implementation detail"; KDE doesn't have the same ties, and has over time gotten less wedded to specific underlying structures and stacks at the same time that GNOME and GTK has gotten moreso).

    Personally, I find systemd just a little too complicated, and have run into at least one showstopping issue that, while not a bug in systemd itself, wouldn't really have happened without the level of interlocking complexity that systemd inserts. Distro-creators love it, and it honestly does work well on things like mobile devices (hello there, SailfishOS!) because it makes easier the process of setting up a specific system to be used widely in that exact configuration. But I'm quite apprehensive of how it will interact with more chaotic systems, like normal Linux desktops and servers where many different pieces of hardware and software are installed and all affecting and interacting with systemd. I've installed Debian Jessie on my Raspberry Pi 2 for the sake of toying around with it so I get some experience with it (and immediately ran into the aforementioned issue and created a bug report for it).

    --
    I remember sigs. Oh, a simpler time!
    1. Re:KDE is only soft-depending on systemd by jbernardo · · Score: 1

      KDE will hard depend on systemd (logind and timedated, which according to some marketeers isn't the same as depending on systemd) in less than 6 months, in KDE 5.6. David Edmundson says so very discreetly in his blog, in a comment.

      Gnome seems to have gone back a little in their objective of tying directly to logind, but they link libsystemd, so yes, they have a hard dependency on systemd. A marketeer will soon claim that depending on libsystemd is not the same as depending on systemd, but I think that is one of the reasons they keep the definition of the init daemon and the project so fluid and easy to mix, so that they can have credible denial of everything, either claiming the init doesn't do that or that the project should do that but doesn't completely mandate the init (for now).

  43. Re:Another one bites the dust... by Eunuchswear · · Score: 1

    It's a sad day for ubuntu users everywhere, it's as if a million init scripts cried out in horror.

    Among all the craziness about systemd this is one of the best.

    Hint -- ubuntu doesn't use init or sysvinit, it's used upstart up to now. upstart is systemd done wrong -- it uses ptrace to keep track of running processes for fucks sake.

    --
    Watch this Heartland Institute video
  44. Re:Whiner brigade - ACTIVATE! by Eunuchswear · · Score: 1

    Init has 1 binary and only 1 binary, and it does what it does perfectly.

    Init does indeed have only one binary, and only one configuration file.

    It does its rather limited job quite well.

    sysvinit, by contrast, has the whole of /bin, /sbin, /usr/bin, /usr/sbin and fuck knows what else. It does less than /sbin/init can, and it does it badly.

    sysvinit doesn't even know whats running, It doesn't know what messages the services it started logged.

    With 300+ binaries [ in systemd ] that's a lot of places to have your system go tits up.

    $ file `dpkg -L systemd `| grep ELF | wc -l
    70
    $ ps -ef | grep systemd | wc -l
    8

    That's 70, not 300, and only 8 of them are actually running.

    --
    Watch this Heartland Institute video
  45. Re:What. the . fuck by Eunuchswear · · Score: 1

    this has NSA written all over it.

    No, that's selinux.

    $ apt-cache rdepends libselinux1 | wc -l
    105
    $ apt-cache rdepends systemd | wc -l
    32

    --
    Watch this Heartland Institute video
  46. It's his job! by dbIII · · Score: 1

    It's his paid time and there been plenty of press about his progress, especially the RedHat newsletters I've been getting every month or so. I really don't get why you have chosen to assert something as a truth when you clearly are unaware of the situation.

    1. Re:It's his job! by kthreadd · · Score: 1

      It's his job now in 2015, but we were talking about when systemd was created back in 2010. At that time Red Hat had just adopted Upstart and was initially quite uninterested in systemd. It wasn't until a couple of years later that Red Hat got convinced to adopt systemd, until then he was not payed to work on systemd.

  47. Re:Excellent news by hitmark · · Score: 1

    I have yet to figure out why this is such a big deal for everyone.

    What kind of gordian knot of a boot up sequence does the daemon has that only the provider can do the init script properly?

    Ship the binary, ship proper instructions, let the admin do his job.

    --
    comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
  48. for a faster boot, roll your own kernel by bzipitidoo · · Score: 1

    You know one thing that can be done for a faster boot? Without systemd, that is? Roll your own kernel, containing only the drivers for the hardware that the system actually has. Strip it down. Strip out all the other cruft, like support for file systems that you are not going to use. And, this is the critical part, make them all part of the kernel, not modules. Don't even have modules.

    No dsitro that I know of goes this exact direction. Gentoo sort of does.. Distros go as generic and inclusive as possible so that their one-size-fits-all system will work on almost any hardware out there.

    I wonder why no one has created tools to probe the hardware and generate a suitable kernel config file, and actually automate this into building a custom kernel for the user, as part fo the system installation and update process. make localmodconfig is as close as it gets right now.

    --
    Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
  49. Tinfoil hats at the ready by jc79 · · Score: 1

    So you think the NSA and Redhat are engaging in a conspiracy with Ubuntu to implement a new init system that somehow has a hidden backdoor? FFS. Don't like it, don't use it. There's no shortage of distros that don't have systemd as the default init. It's all open source under Free licenses. Do what you want with it.

  50. Re:Delicious geek tears. by gweihir · · Score: 1

    A minor calculating error, completely irrelevant. I used the original release in 1993 on SunOS.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  51. Welcome to Amish country by DrXym · · Score: 1

    I've never read such irrational and ludicrous objections to a piece of infrastructure.

  52. Here we go again by Ol+Olsoc · · Score: 1
    systemd is the latest Mayan Apocalypse. Probably with the same results.

    As for me, I'll install the latest Ubuntu on a sacrificial machine about a month or two into release.

    And did y'all know that the History2 channel is still showing Mayan Apocalypse videos today? So fear not, systemd haters, you'll be able to look back ten years from now and still say it is the demise of fLinux.

    --
    The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
  53. Re:RHEL/CentOS adoption often a version or two beh by gweihir · · Score: 1

    Indeed. Some people need things to actually work. It will be pretty amusing when these people run into systemd.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  54. Re:Look like you got caught in a lie by Eunuchswear · · Score: 1

    systemd will nicely warn you if a unit file for a daemon changed. The output above should have had the warning:

    That's interesting, I didn't see this warning when I tried it first -- I'd guess because I installed named for this test and modified the unit file before starting it for the first time. If I modify the file again I see the warning.

    Why would you expect "systemctl daemon-reload" to return nonzero? It's "systemctl start" that tells you that named didn't start.

    What version of systemd are you testing this on?

    Script started on Sat 07 Mar 2015 09:58:01 PM CET
    [root@centaur ~]# echo '#idiots are idiots' >> /usr/lib/systemd/system/named.service
    [root@centaur ~]# systemctl start named.service
    Warning: Unit file of named.service changed on disk, 'systemctl daemon-reload' recommended.
    Job for named.service failed. See 'systemctl status named.service' and 'journalctl -xn' for details.
    [root@centaur ~]# systemctl status named.service
    named.service - Berkeley Internet Name Domain (DNS)
      Loaded: loaded (/usr/lib/systemd/system/named.service; disabled)
      Active: failed (Result: exit-code) since Sat 2015-03-07 21:58:45 CET; 12s ago
      Process: 2264 ExecStart=/usr/sbin/named -u named $OPTIONS --broken (code=exited, status=1/FAILURE)
      Process: 2262 ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf (code=exited, status=0/SUCCESS)
     
    Mar 07 21:58:45 centaur named-checkconf[2262]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
    Mar 07 21:58:45 centaur named-checkconf[2262]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
    Mar 07 21:58:45 centaur named-checkconf[2262]: zone 0.in-addr.arpa/IN: loaded serial 0
    Mar 07 21:58:45 centaur named[2264]: usage: named [-4|-6] [-c conffile] [-d debuglevel] [-E engine] [-f|-g]
    Mar 07 21:58:45 centaur named[2264]: [-n number_of_cpus] [-p port] [-s] [-t chrootdir] [-u username]
    Mar 07 21:58:45 centaur named[2264]: [-m {usage|trace|record|size|mctx}]
    Mar 07 21:58:45 centaur named[2264]: named: unknown option '--'
    Mar 07 21:58:45 centaur systemd[1]: named.service: control process exited, code=exited status=1
    Mar 07 21:58:45 centaur systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
    Mar 07 21:58:45 centaur systemd[1]: Unit named.service entered failed state.
     
    Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
    [root@centaur ~]# exit
     
    Script done on Sat 07 Mar 2015 10:02:54 PM CET

    --
    Watch this Heartland Institute video
  55. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  56. Re:Look like you got caught in a lie by Eunuchswear · · Score: 1

    p># journalctl -r -u named | head -5
    -- Logs begin at Wed 2015-03-04 19:06:46 UTC, end at Sat 2015-03-07 20:43:55 UTC. --
    Mar 07 20:43:55 proxy systemd[1]: Stopped named.service.
    Mar 07 20:43:55 proxy named[23860]: exiting
    Mar 07 20:43:55 proxy named[23860]: no longer listening on ::1#53
    Mar 07 20:43:55 proxy named[23860]: no longer listening on 10.63.228.1#53

    There's nothing about the failure to start.

    Interesting. Why did you add the 'head -5" there? What was the 6th line output?

    Why didn't you use "systemctl status" to see what was going on?

    You clearly know a lot about systemd but (deliberatly?) use strange commands to hide information.

    --
    Watch this Heartland Institute video
  57. Re:Look like you got caught in a lie by Eunuchswear · · Score: 1

    So why doesn't it show it when I try?

    Why won't you say what version you are using?

    why won't you show the systemctl status output?

    --
    Watch this Heartland Institute video
  58. It isn't systemd... by WebCowboy · · Score: 1

    ...it is the way Ubuntu has been for a long time.

    Nobody is pushing systemd into the OS any more than any other big change. Ubuntu has done, or tried to do, the same with pulseaudio, unity desktop and mir and even upstart. At least systemd has cross distro support. Usually Ubuntu charges ahead with something invented in house at canonical and then try to own it completely and alienate development community.

    Also though systemd is not how i would exactly do things i am getting used to it and it is WAY WAY BETTER than the old init and isnt the odd man out, not invented here solution that is upstart.

    But whatever you think of systemd...even if you love it or dont care either way, Ubuntu is repeating history by doing major screwing with things at inappropriate times in the release cycle and it really should have been put on the 15.10 roadmap instead. Part of the reason people jumped on the systemd hatewagon, or kde4 or gnome3 pulseaudio or whatever, is because of how aggressively they were adopted in general releases before their time. All of the above are just fine...now..but all were barely beta quality when they started to receive wide adoption. The antics of Ubuntu management and their ilk don't help engender support.

    I will likely stick with Debian. As painful as it was to witness the immature sh!t-slinging by political factions on both sides of the debate that added nothing useful to the discussion, at least there was a debate, and a very extended time with systemd being an optional experimental/unstable package. That has never been the ubuntu way. The systemd suite of software may be finally ready for prime time, but nothing of that sott of nature should be done on an apparent whim. Thats why i stopped using Ubuntu after lucid lynx.

  59. rsyslog and SNMP traps by WebCowboy · · Score: 1

    You boast of running enterprise class systems that certainly command six figure budgets just to set up. Whether or not systemd is involved you should be using the aforementioned tools.

  60. It's his job and has been since 2010 - after pulse by dbIII · · Score: 1
    Bullshit. He was working for RedHat back then:

    http://www.webupd8.org/2010/11...
    Well, Lennart Poettering, a RedHat developer replied to Linus Torvalds on a maling list with an alternative to this patch that does the same thing

    He's been employed by RedHat to develop systemd for several years - thus RedHat is creating systemd or you could say he's creating it for RedHat. You would have been aware of that if you were following the issue at all instead of just making an assertion in ignorance.
    We're supposed to be setting a good example here instead of blatantly lying to the kiddies and making shit up to push some utterly trivial agenda. I don't get what the agenda is - hero worship of a drama queen who pretends to have a loose grip on reality just to push a point?
    http://www.phoronix.com/forums/showthread.php?107338-Lennart-Poettering-On-The-Open-Source-Community-A-Sick-Place-To-Be-In/page11

  61. Just in case 2010 was too late: by dbIII · · Score: 1

    Fri Jun 13 2008 Lennart Poettering
    lpoetter@redhat.com
    http://rpmfind.net/linux/RPM/sourceforge/s/sl/sl7-i686-project/yum/FEDOREL7/FULLMISSING/libcanberra-gtk2-0.30-5.el7.i686.html

    A bit more honesty would be appreciated instead of making shit out and then adamantly insisting that it is real.
    What agenda do you have here that you think is worth lying for?

  62. blame systemd? by WebCowboy · · Score: 1

    Curious, i have not in the past year of using NFS mounts on systemd based systems encountered 90s hangs you describe. What distro do you use? Did you set up the unit files yourself or stick with packaged ones?

    Sounds like a configuration problem to me, not specifically an issue with systemd doing something wrong. It is simpler and more complex than init scripts. Enabling concurrent service startup by its very nature is more complex, regardless of the implementation. But if it is configured right systemd won't even try to start nfs if the network is not reporting it is up....if it is configured right ;-)

  63. Re:It's his job and has been since 2010 - after pu by kthreadd · · Score: 1

    You still don't get it. Just because he works at Red Hat does NOT mean that every single thing that he does when he's not doing his regular work is copyright Red Hat, approved by Red Hat and is set for inclusion in the next RHEL release. He does personal projects too, every single good programmer does that. Some of them takes of, this one did.

    But consider for a moment that you're right, that as soon as you've seen a @redhat.com email address in the wild then that is confirmation that it represents Red Hat's official opinion and goals, then how do you explain this? An @redhat.com email back in 2011 that downright criticizes systemd for being too big and too bloated, in 2011!
    https://lists.fedoraproject.or...

  64. The answer again for the slow by dbIII · · Score: 1

    Because the old system is not seen as broken.

    1. Re:The answer again for the slow by macs4all · · Score: 1

      Because the old system is not seen as broken.

      Apparently, it, um, is, and curiously by the maintainers of nearly all of the major dirstos.

      So you all keep chanting that tired refrain, while Distro after Distro falls victim to the ridiculousness that is systemd.

      Maybe by the time you wake up, it won't be too late; but, with your obdurate attitude, I doubt it.

    2. Re:The answer again for the slow by dbIII · · Score: 1

      Only by people like Lennart who have their own thing to promote. Systemd is a solution in search of a problem.
      Upstart was all about getting laptops to start very quickly but hibernate renders that less relevant. Embedded systems and tablets can start very quickly without going anywhere near the bloated (for tiny systems) systemd.

    3. Re:The answer again for the slow by macs4all · · Score: 1

      Only by people like Lennart who have their own thing to promote. Systemd is a solution in search of a problem. Upstart was all about getting laptops to start very quickly but hibernate renders that less relevant. Embedded systems and tablets can start very quickly without going anywhere near the bloated (for tiny systems) systemd.

      As an Embedded Dev for nearly forty years, I'd wholeheartedly agree that the overhead of something like systemd or launchd is just silly. But having said that, iOS seems to include launchd, and no one seems to mind.

      As far as systemd being a solution in search of a problem, the same could have been said of launchd and OS X. After all, *nix Systems, including three major revisions of OS X, had been doing stuff with a mashup of INIT, rc, inetd, cron and watchdogd for quite some time. So why did Apple spend the non-trivial time and resources to polish-up launchd, change EVERY daemon to use launchctl and launchd, and TEST, TEST, TEST? And then furthermore, Lennart and Poettring, et al, notwithstanding, why would Distro after Distro of Linux go to the same trouble (and generally, with only a small fraction of Apple's development budget and resources), especially with St. Linus (not surprisingly) apparently in disagreement with the whole systemd thing?

      Is the Linux kernel Dev community really THAT Pusillanimous that one or two loose cannons can take over the majority of popular Distros? If true, then Linux is in sad shape indeed, and the end is nigh for it as a general-purpose platform.

    4. Re:The answer again for the slow by dbIII · · Score: 1

      Lennart and Poettring, et al

      His name is Lennart Poettring, I just rudely refer to him by his first name because I can spell that without looking it up. He likes to change things, even things that are pretty solid (eg. *nix networking). He's been doing it ever since he left school. That's not a bad thing, the problem is a lot of his work has been rushed out unfinished by people in Gnome (pulseaudio, NetworkManager) and RedHat (NetworkManager, systemd).
      Now there's been a lot of bugs with systemd over the last five years, which makes sense for a new project, however many have been in what should be "stable" systems if it wasn't from gnome and redhat politics meaning the golden boy gets to put his stuff in before it's really ready. His goal, from his blog, is unashamedly to replace everything at what MS Windows people would call the "service" level - good luck to him with that, but IMHO it should be as functional as what he wishes to replace before we get it shoved down our throats.

      Are you getting why this discussion is happening now or is there something I need to clarify a bit more?

    5. Re:The answer again for the slow by macs4all · · Score: 1

      [...] but IMHO it should be as functional as what he wishes to replace before we get it shoved down our throats.

      On that, we wholeheartedly agree...

      So, the real "fault" lies not with Poettering, per say; but rather, with the maintainers of those Distros who are letting this "loose cannon" run amok in the kernel.

    6. Re:The answer again for the slow by dbIII · · Score: 1

      RedHat appears to applaud his goal of taking over linux userspace since if it works they'll effectively own it, and Poettering is a big wheel in maintaining the Fedora and RHEL distributions himself.

    7. Re:The answer again for the slow by macs4all · · Score: 1

      RedHat appears to applaud his goal of taking over linux userspace since if it works they'll effectively own it, and Poettering is a big wheel in maintaining the Fedora and RHEL distributions himself.

      But the L. Poettering virus has not been contained to RHEL and Fedora, and therein lies the key to what I was saying about "The train has already left the station" and likely cannot be completely stopped (from moving away from INIT, et al), but MAYBE there is still time to at least throw the switch to put it on the "launchd" track rather than the "systemd" one.

    8. Re:The answer again for the slow by dbIII · · Score: 1

      That would require getting very political with the "gnome" developers who are the ones that are making things that will only work is systemd is present. They are an odd bunch so doing so would be like diving head first into student politics at a white only, male only third rate deep south Bible college. While I am both male and white things do turn to shit when an org gets too inbred, especially when the "elder statesman" they hold in awe started coding in 2003.
      What is happening is that servers and workstations are on distros without systemd, apart from a tiny minority on RHEL7/CentOS7, so the "train" hasn't even turned up on the timetables of many. Commercial software on *nix is developed very slowly - I'm currently waiting for an important addon for a geophysical package to be updated so that it can run on RHEL6/CentOS6 - 7 isn't even on the radar of most.
      So Lennart's solution to the "problem" of linux not having a single unifying structure under his own control is likely to mean old distros hang around a bit longer than they otherwise would. If Wayland (Mac and MS style dumb framebuffer for local only use instead of X) actually gets to be useful that may make gnome irrelevant and the problem may get leapfrogged over.

    9. Re:The answer again for the slow by macs4all · · Score: 1

      That would require getting very political with the "gnome" developers who are the ones that are making things that will only work is systemd is present. They are an odd bunch so doing so would be like diving head first into student politics at a white only, male only third rate deep south Bible college. While I am both male and white things do turn to shit when an org gets too inbred, especially when the "elder statesman" they hold in awe started coding in 2003.

      Holy Sh**!!! *I* started coding in 1976!!! I'm a frickin' FOSSIL!!!

      Great analogy, BTW...

      What is happening is that servers and workstations are on distros without systemd, apart from a tiny minority on RHEL7/CentOS7, so the "train" hasn't even turned up on the timetables of many. Commercial software on *nix is developed very slowly - I'm currently waiting for an important addon for a geophysical package to be updated so that it can run on RHEL6/CentOS6 - 7 isn't even on the radar of most.

      Interesting. So, in reading /., people who are NOT Linux Devs. really get a somewhat skewed view of the imminent nature of the systemd (and likely other) "nerd-fights" involved with Linux, right?

      So Lennart's solution to the "problem" of linux not having a single unifying structure under his own control is likely to mean old distros hang around a bit longer than they otherwise would. If Wayland (Mac and MS style dumb framebuffer for local only use instead of X) actually gets to be useful that may make gnome irrelevant and the problem may get leapfrogged over.

      Wait! Ya lost me! I admit that most of what I know about Linux comes from reading /. ; but I REALLY don't understand what a [display?] framebuffer has to do with a kernel-level daemon like systemd.

      But beside that, it STILL sounds like you (not necessarily "you" personally), are just kind of hoping that systemd will go away. And if Linux wares are as slow-to-change as you say (which doesn't seem to be the case with systemd!!!), then it still seems like there is time to start changing hearts and minds in favor of launchd (assuming SOME change from INIT is inevitable).

    10. Re:The answer again for the slow by macs4all · · Score: 1

      You guys are both way off base with why systemd is a thing, and why launchd wasn't adopted.

      Um, quit lumping our statements together.

      *I* wasn't saying anything about systemd, per se; as an OS X guy, *my* only question was the "why wasn't launchd adopted, since it was already baked and time-tested".

      I see that *you* have failed to answer that as well. This leads me to the inescapable conclusion that it is simply a case of NIH (Not Invented Here), plus the latent Apple-Hate that seems to (needlessly) foment in so many Linux fanbois.

      Sigh...

  65. Re:It's his job and has been since 2010 - after pu by dbIII · · Score: 1

    Except it WAS. RedHat were paying for him to fly around and promote systemd in 2010. It was his JOB.
    Why are you continuing after being caught out in a lie?

  66. Re:It's his job and has been since 2010 - after pu by kthreadd · · Score: 1

    Right here and now his job is to develop systemd. Back then he was still in the desktop group at Red Hat and his job was certainly not to fly around and promote his side-project. He was actually in the desktop group up until about a year ago when he moved to the server experience group.

  67. Re:I love how the systemd guys ignore bugs! by Eunuchswear · · Score: 1

    This guy is a troll. "systemctl daemon-reload" just tells systemd the re-read its configuration files:

    daemon-reload
              Reload systemd manager configuration. This will reload all unit
              files and recreate the entire dependency tree. While the daemon is
              being reloaded, all sockets systemd listens on on behalf of user
              configuration will stay accessible.
     
              This command should not be confused with the load or reload
              commands.

    There is no reason to expect it to give an error.

    He "forgot" to try launching the broken service after changing the configuration. If he had done a "systemctl start named" he would see the error message and the error status from "systemctl start".

    --
    Watch this Heartland Institute video
  68. Re:Look like you got caught in a lie by Eunuchswear · · Score: 1

    Why what returned a zero exit status?

    With the "--broken" argument added to named.service then "systemctl start named" prints an error message and gives a non-zero exit status.

    --
    Watch this Heartland Institute video
  69. Re:Look like you got caught in a lie by Eunuchswear · · Score: 1

    I just assumed everyone already has BIND installed.

    Why the fuck would I install that buggy horror! Next you will be suggesting that I install sendmail.

    --
    Watch this Heartland Institute video
  70. Re:It's his job and has been since 2010 - after pu by dbIII · · Score: 1

    Back then he was still in the desktop group at Red Hat and his job was certainly not to fly around and promote his side-project.

    Because it was his main project. Take a look at his blog and you'll see how many places he visited to speak about systemd in 2010 alone.

    Why are you persisting in this attempt to mislead on a topic that really should not be worth lying about? Are you hoping people will not remember details or look things up and will take your word for it, and somehow give you the jollies for tricking people?

    If I was him I'd actually be proud that RedHat was supporting it right from the very start, so I really do not get why you think it matters so much.

  71. Re:FreeBSD by byuu · · Score: 1

    With the MTRR tweak, I can even watch video at 2560x1600 at 60fps. I've benchmarked it and I can get up to 95fps of solid memory copying into VRAM. Compositing works fine, but I turn off all but shadows. It also helps to run at 16bpp (half the bandwidth needed per screen fill), which only really hurts you when you're working with artificial gradients, or are a photo editor. Kind of sucky to give up the color detail, but I'll take twice the speed over colors the majority of which I cannot distinguish. The one thing I lament heavily is that there's no Vsync support. It's impossible to even add it manually: the video card doesn't provide Vsync timing info at all (even tried probing the VGA ports and looking at the VESA timing extensions ... they don't work on this card.)

    I've also been thinking about running a headless server for stability reasons, but haven't gone that far yet. If Xorg+Xfce eventually falls apart entirely over systemd; then I'll probably resort to running my own basic apps (text editor, file manager, terminal emulator, MP3 player) using FreeBSD's ioctl's for setting VESA mode right from the console. Then I'll just use my Windows box next to it for web browsing, movie watching and gaming.

    Unfortunately, I doubt we'll see a lot more pushback on this. Linux users are quick to complain when Windows/OS X software doesn't run on Linux, yet are surprisingly hypocritical to not care when Linux software doesn't run on other systems (BSDs, Haiku, etc.) The BSD ports trees are littered with patches for pointless Linuxisms. They won't even add trivial compatibility features like SO_NOSIGPIPE to their system. Of course in the case of systemd, I really couldn't be happier that Poettering has a raging hate-on for it. I don't want his shit running on BSD either.

  72. Re:It's his job and has been since 2010 - after pu by kthreadd · · Score: 1

    Well, I guess he's been lying to me during the two talks I've heard him say that.

  73. Re:FreeBSD by gweihir · · Score: 1

    Nice numbers!

    As to the future of systemd, we will see. I really have no issue moving to the BSDs if it gets to bad on Linux, all my own software and everything else I need should run there as well, non-portable programming is for lusers. The only thing that still gives Linux an edge today is good hardware support, but that becomes less and less important, especially on a headless server. And if running Linux means letting abominations like systemd in, then I can just migrate away. Before that, I will give Gentoo a try though, as I am just way more familiar with Linux internals. It is still possible that once mainstream adoption is forced, systemd will finally reveal itself as a problem not as a solution to enough people.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  74. This is how you solve "Bug 1" by Gunstick · · Score: 1

    Yeah, bug 1 was resolved recently. https://bugs.launchpad.net/ubu...
    But as I see it, using systemd makes linux as useless and undebuggable than windows.
    So there is no point to use linux, nothing different, sam black box as windows. Result: microsoft has won. Thanks Poettering.

    Solving Bug 1 by making linux the same as Windows. Yeah! Sure, that's how you do it!

    --
    Atari rules... ermm... ruled.
  75. Re:I love how the systemd guys ignore bugs! by Eunuchswear · · Score: 1

    You are misreading the message. systemctl is telling you that the unit file has changed, and you should probably do a daemon-reload before doing the systemctl start. It is not a bug.

    --
    Watch this Heartland Institute video
  76. Smooth switch by lems1 · · Score: 1

    I started using Vivid months ago and manually switched to this atrocity. It worked well but I still want to be a contrarian and protest it.
    It works and it's smooth but I hate that it works well and it works smoothly.

    --
    This sig can be distributed under the LGPL license
  77. Re:I love how the systemd guys ignore bugs! by Eunuchswear · · Score: 1

    No it doesn't you illiterant cretin. I tells you that, since you have modified the unit file,start may not be doing what you think it is.

    Anti systemd trolls seem to be getting stupider as time goes by.

    --
    Watch this Heartland Institute video
  78. Re:I love how the systemd guys ignore bugs! by Eunuchswear · · Score: 1

    illiterant? what the fuck does that mean. Illiterate.

    memo to self -- stop posting to slashdot from idiotphone.

    --
    Watch this Heartland Institute video
  79. Re:It's his job and has been since 2010 - after pu by dbIII · · Score: 1

    Ah - the appeal to authority without citations now since the lie was too obvious and didn't work. What exactly is it that he said in those two talks that gave you the impression? Are you sure you heard it correctly or are you putting words in his mouth and making a false appeal to authority?
    Getting paid to work on your pet project and getting paid to travel and promote it is something to be proud of. Redhat were most definitely behind him on this one and treated it as a professional project and not a "side project".