Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Sunday September 28 2014, @06:27AM   Printer-friendly
from the yet-another-systemd-story dept.

Controversy is nothing new when it comes to systemd. Many people find this new Linux init system to be inherently flawed in most ways, yet it is still gaining traction with major distros like Arch Linux, openSUSE, Fedora, and soon both Ubuntu and Debian GNU/Linux. The adoption of systemd for Debian 8 "Jessie" has been particularly fraught with strife and animosity.

Some have described the systemd adoption process as having been a "coup", while others are vowing to stick with Debian 7 as long as possible before moving to another distro. Others are so upset by what they see as a complete betrayal of the Debian and open source communities that there is serious discussion about forking Debian. Regardless of one's stance toward systemd, it cannot be argued that it has become one of the most divisive and disruptive changes in the long history of the Debian project, threatening to destroy both the project and the community that has built up around it.

Related Stories

Integration with systemd Making Gnome3 the Default Debian Desktop 135 comments

Debian Jesse is going to have Gnome3 as the default desktop.

The desktop re-qualification page, used to help choose which desktop will be default, has in the Jesse version a weight for systemd integration, and of course only Gnome3 does it (at least for now). This will surely make the systemd/gnome3 fanbase happy, but possibly will make others unhappy, as it [may] be seen as another step towards mono-culture, until we soon end up with all distros being redhat clones.

Tollef Fog Heen Resigns as a Debian systemd Maintainer 134 comments

Longtime Debian contributor Tollef Fog Heen has announced his resignation from the Debian systemd maintainer team. His announcement states that "the load of the continued attacks is just becoming too much."

He has since written a detailed blog article surrounding the circumstances of his resignation. As he puts it,

I've been a DD for almost 14 years, I should be able to weather any storm, shouldn't I? It turns out that no, the mountain does get worn down by the rain. It's not a single hurtful comment here and there. There's a constant drum about this all being some sort of conspiracy and there are sometimes flares where people wish people involved in systemd would be run over by a bus or just accusations of incompetence.

This is yet another dramatic event affecting the Debian project in recent months. The adoption of systemd has been extremely controversial, even going so far as to result in calls for Debian to be forked. There have been other problems as of late, too, ranging from a serious bug breaking Wine just days before the Jessie freeze deadline, to the possibility of Debian GNU/kFreeBSD being dropped from Debian 8. And it was only just over a week ago that Joey Hess — another longtime Debian contributor — left the project, citing the "very unhealthy directions" that Debian has been led in lately.

Is the internal tension and strife caused by systemd about to tear the Debian project apart? Recent events such as the aforementioned have suggested that this is becoming more and more of a possibility. The repercussions of this drama will no doubt be felt wide and far, given Debian's own popularity, as well it forming the basis of other major Linux distros such as Ubuntu and Linux Mint.

Wine Fails to Launch under Debian Jessie, Just Days before the Freeze Deadline 119 comments

A grave bug has been introduced into the "wine" package of Debian Jessie, just days before the November 5th freeze deadline. The /usr/bin/wine launch script fails with an "error: unable to find wine executable. this shouldn't happen." message.

Debian has already suffered much unrest lately over the inclusion of systemd, with threats of a fork being issued, along with the possible cancellation of the GNU/kFreeBSD port and the possible dropping of support for the SPARC architecture. After so much strife and disruption, can Debian afford to have such a serious bug affect such a critical package so soon before such a major freeze?

Debian by Anonymous Coward
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough

Mark All as Read

Mark All as Unread

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by zeigerpuppy on Sunday September 28 2014, @07:00AM

    by zeigerpuppy (1298) on Sunday September 28 2014, @07:00AM (#99095)

    Having just commissioned a Debian 7 server (with a little of special sauce called Sid), I am very pleased with the result. 10 Xen VMs all purring away with ZFS storage with ZFSonLinux. It's totally stable and performs well. Better than that it is low maintenance. Salt and Shorewall are my friends, djbdns is excellent and bugs are well documented and traceable.
    Thank you Debian, Linux and the community for a tool which makes it possible to leverage the most advanced and open software. It makes new things possible.
    As for systemd, I think it's largely a solution looking for a problem. I can see the point of scheduling the order of services starting but I don't think there's a fix-it-all type of approach to this. Each server config is unique and some degree of hand tuning is inevitable.
    On laptops it might make sense, but Ubuntu and Mint have that pretty nicely covered. I'll use a non systemd fork if it available but I don't see really needing to dist-upgrade for a couple of years. By which time we'll likely have something else...

    • (Score: 3, Insightful) by Anonymous Coward on Sunday September 28 2014, @12:03PM

      by Anonymous Coward on Sunday September 28 2014, @12:03PM (#99168)

      What are you going to do when Debian 7 is no longer supported?

      Debian typically supports a stable distro for about a year after the subsequent stable version has been released. Jessie will be frozen on the 5th of November 2014. The release will probably be mid-2015. So it's possible that Debian 7 won't be supported by mid-2016.

      Mid-2016 really isn't that far away. Is 20 months of support sufficient for your server? I would say there's a good chance it isn't, especially if it's a production server. These servers tend to hang on for many years. But serious bugs, like the ones affecting OpenSSL and bash, do come up well into this period and they need to be patched. But if your distro is no longer supported, and you have to start patching and updating libraries and programs manually because the packages are no longer available, then your distro is hindering you more than it is helping you.

      Debian is a very important distro, and we need to be able to upgrade production servers from Debian 7 to Debian 8 without the fear of systemd coming along and trashing the server. That's the harm in systemd. It isn't just bad software. It's bad, unnecessary software. And it reduces the usability of Debian significantly for serious users.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:54PM

        by Anonymous Coward on Sunday September 28 2014, @12:54PM (#99192)

        sudo apt-get remove systemd
        sudo apt-get install sysvinit

        • (Score: 5, Informative) by Anonymous Coward on Sunday September 28 2014, @01:04PM

          by Anonymous Coward on Sunday September 28 2014, @01:04PM (#99196)

          CAUTION! CAUTION! CAUTION!

          WARNING! WARNING! WARNING!

          DO NOT ATTEMPT WHAT THE PARENT SUGGESTS! IT COULD DAMAGE YOUR SYSTEM!

          systemd is not that easy to remove from a Debian system! That's one of the problems with systemd: it infects everything in a way that makes its removal dangerous and destructive.

          SoylentNews user joshuajon posted some information about systemd removal [soylentnews.org] in other discussion.

          I haven't tried the removal myself, but please read what joshuajon wrote before attempting anything on your own system that has been infected with systemd. It may just save you a lot of time and pain.

          In one of his comments joshuajon mentions (emphasis added):

          I just did out of curiosity, doesn't work. And a bunch of stuff ended up missing from /sbin/ in the process including reboot, shutdown. When I reset the VM it now fails to boot with "Target filesystem doesn't have requested /sbin/init"

          Please, be careful when you work with systemd. As joshuajon's comment makes clear, even the slightest misstep when dealing with systemd can render a system unable to boot!

          • (Score: 3, Interesting) by Marand on Sunday September 28 2014, @01:26PM

            by Marand (1081) on Sunday September 28 2014, @01:26PM (#99201) Journal

            If your primary problem with systemd is using it as init, you can also install the systemd-shim package and a different init of your choice. The init part of systemd is systemd-sysv, so if you install systemd + systemd-shim + sysvinit (or runit, upstart, etc.) you get a non-systemd pid1 of your choice without having to worry about half your system getting trashed over it.

            Helps mitigate the "if systemd crashes your system is fucked" problem, if nothing else.

            • (Score: 3, Insightful) by Anonymous Coward on Sunday September 28 2014, @07:23PM

              by Anonymous Coward on Sunday September 28 2014, @07:23PM (#99309)

              Your comment does a great job depicting just how infectious systemd is. Even when you go out of your way not to use it, you still need to use a hack like systemd-shim, in addition to whatever real init system you want to use.

              It's completely stupid that you still need to use something like systemd-shim when the whole point is to avoid systemd and the stupidity it brings!

              Then the "systemd + systemd-shim + sysvinit (or runit, upstart, etc.)" setup you describes sounds far more complex and fragile than just using sysvinit alone, like we've done for so long now. Thanks, systemd, you've "solved" a problem that didn't even exist in the first place, you've made the system more fragile, and now you've created several new problems that never existed before!

              systemd is a menace. It's a fucking menace. It needs to go.

              • (Score: 3, Insightful) by Marand on Monday September 29 2014, @02:33AM

                by Marand (1081) on Monday September 29 2014, @02:33AM (#99435) Journal

                Your comment does a great job depicting just how infectious systemd is. Even when you go out of your way not to use it, you still need to use a hack like systemd-shim, in addition to whatever real init system you want to use.

                It's completely stupid that you still need to use something like systemd-shim when the whole point is to avoid systemd and the stupidity it brings!

                Yep, it's creeping into everything by way of a handful of packages that are basically required for a user-friendly desktop experience. Infection is a good word for it.

                For what it's worth, you can still completely avoid systemd if you're careful. Just make sure you don't need power management; are willing to handle removable storage via "mount"; don't want to use GNOME3, Cinnamon, possibly MATE, etc.; and watch the deps when adding KDE apps or anything that uses Gtk3.

                Then the "systemd + systemd-shim + sysvinit (or runit, upstart, etc.)" setup you describes sounds far more complex and fragile than just using sysvinit alone, like we've done for so long now. Thanks, systemd, you've "solved" a problem that didn't even exist in the first place, you've made the system more fragile, and now you've created several new problems that never existed before!

                So far, from what I've seen, it's not really any more fragile than parts of the system relying on HAL or dbus currently. As long as the -shim package provides an abstraction to whatever systemd expects, the rest of systemd seems to plod along being an annoyance at worst, and ignorable at best. Surprisingly, the non-init parts have been less fragile for me than HAL and dbus were during their early adoption phases. The problem is that it connects too many disparate parts together into an unfathomable mass that makes debugging problems that arise daunting.

                Oh, something I forgot: an extra benefit to using systemd-shim and your own int is the init part is what gives you the idiotic binary logs. Use the -shim and your own init and you keep text logs.

                systemd is a menace. It's a fucking menace. It needs to go.

                It doesn't need to go, it just needs better separation and interoperability with other non-systemd parts. Some parts of it could be viable alternatives to other similar software, if they didn't all require all the other parts to work. You know, like the rest of the init, logging, etc. systems.

                Won't happen, though. RedHat, GNOME, and Poettering all love their not-invented-here mindset. If anybody else makes a good solution to something, one of them will re-create it their own way, tie it to GNOME, and then refuse to support anything else, eventually becoming the de facto standard through stubbornness and unwillingness to cooperate. It's happened repeatedly in the past and it's going to keep happening.

                • (Score: 1) by linuxrocks123 on Monday October 06 2014, @03:42AM

                  by linuxrocks123 (2557) on Monday October 06 2014, @03:42AM (#102289) Journal

                  Slackware got rid of GNOME several releases ago; Slackware uses a very transparent BSD-style init system; Slackware's philosophy is that "it's your system" and you should be able to configure it however you want, and the distro should help facilitate your choices as much as is reasonable. Slackware is the oldest still-living Linux distro. Slackware's current users would probably immediately fork the distro if it adopted systemd as anything other than an optional add-on.

                  Don't want systemd? Slackware's waiting for you.

          • (Score: 2) by francois.barbier on Sunday September 28 2014, @07:05PM

            by francois.barbier (651) on Sunday September 28 2014, @07:05PM (#99297)

            I like your use of the word "infected". Because it is what it is.

          • (Score: 0) by Anonymous Coward on Monday September 29 2014, @04:32AM

            by Anonymous Coward on Monday September 29 2014, @04:32AM (#99460)

            Bollocks, I've tested this on workstations, laptops and servers. You can even skip a step: apt-get install sysvinit-core will remove systemd for you.

            Most packages only depend on an init system provider, they don't care which one it is. The only thing I lost was NetworkManager which is never installed on servers anyway and easily replaced with wicd or equivalent on laptops.

            • (Score: 1) by hendrikboom on Tuesday September 30 2014, @11:14PM

              by hendrikboom (1125) on Tuesday September 30 2014, @11:14PM (#100164) Homepage

              The only thing I lost was NetworkManager

              So does NetworkManager now depend on systemd? When did this dependency appear in jessie/testing? About a month or so ago? That's when my wifi stopped working properly.

              Also in the last month the file manager in xfce stopped having the permissinos it needs to mount USB sticks. Is there a similar problem there?

    • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @01:27PM

      by Anonymous Coward on Sunday September 28 2014, @01:27PM (#99202)

      I have two SoylentNews bugs to report:

      1) The "coup" and "stick with Debian 7" hyperlinks in the summary are correct when viewing the summary from the index page, but they are currently http://soylentnews.org/__SLASHLINK__ [soylentnews.org] when viewing the comments page.

      2) Bug reports are submitted through GitHub. I refuse to use GitHub because I do not want to be associated in any way with the Rubyers and JavaScripters who infest GitHub. But I do want to help make the SoylentNews software more robust. There should be some way of submitting a bug report anonymously from the SoylentNews website. Maybe it could then submit them as GitHub issues using a SoylentNewsAnonymousCoward GitHub account, or something along those lines.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @03:06PM

        by Anonymous Coward on Sunday September 28 2014, @03:06PM (#99223)

        I refuse to use GitHub because I do not want to be associated in any way with the Rubyers and JavaScripters who infest GitHub.

        Unless github prevents you submitting an anonymous ticket, this appears to be a bug in your logic.

        • (Score: 2) by The Mighty Buzzard on Sunday September 28 2014, @06:21PM

          It does allow anonymous coward type posting of issues and thanks to GP for the report regardless of where it went.

          --
          Save Ferris!
        • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @06:35PM

          by Anonymous Coward on Sunday September 28 2014, @06:35PM (#99281)

          When I click the "New issue" button on the GitHub site it shows me a "Sign in" form.

          How do I submit an issue anonymously with GitHub?

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @08:38PM

        by Anonymous Coward on Sunday September 28 2014, @08:38PM (#99331)

        has been added to http://wiki.soylentnews.org/wiki/Suggestions [soylentnews.org]

  • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:08AM

    by Anonymous Coward on Sunday September 28 2014, @07:08AM (#99097)

    I have neither the time nor the expertise to contribute code but I would gladly donate to help cover hosting and bandwidth costs.

    • (Score: 4, Informative) by The Mighty Buzzard on Sunday September 28 2014, @06:26PM

      Buy a subscription and you will have done so. If $20 isn't enough for you, buy several years or start gifting them to other users when they make a particularly awesome comment. We're actually in the planning stages of putting a button to gift a logged in owner of a comment a month's subscription for somewhere around $2. Look for it by the end of the year or early next year.

      --
      Save Ferris!
      • (Score: 2) by francois.barbier on Sunday September 28 2014, @07:12PM

        by francois.barbier (651) on Sunday September 28 2014, @07:12PM (#99302)

        We're actually in the planning stages of putting a button to gift a logged in owner of a comment a month's subscription for somewhere around $2. Look for it by the end of the year or early next year.

        +1 Informative; +10 Excellent idea;
        Can't wait for this.

  • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @07:11AM

    by Anonymous Coward on Sunday September 28 2014, @07:11AM (#99098)

    Today It's impossible to have a reasonable laptop experience in Debian without systemed; being reasonable the same as a year ago: suspend/hibernate working, and network management just working.

    Now, for wifi, Systemd is a necessary dependency of plasma-nm, so I'm stuck with cnetworkmanager, and that of suspending stopped working stopped working.

    Taking that into account, and the future KDM dependence on logind, points my computers future possibly on lumina.

    Which is sad, given that I'm one of the KDE translators (to galician)

    • (Score: 2) by Marand on Sunday September 28 2014, @10:54AM

      by Marand (1081) on Sunday September 28 2014, @10:54AM (#99143) Journal

      Now, for wifi, Systemd is a necessary dependency of plasma-nm, so I'm stuck with cnetworkmanager, and that of suspending stopped working stopped working.

      Switch to wicd instead of networkmanager. You'll be happier long-term: in addition to not having insane dependencies, it's a lot less fussy and not prone to random breakage like NM has been in the past. I found wicd to be far more reliable on my laptop, as well as just nicer to use overall.

      Only (potential) negative I can think of offhand is that the GUI bits aren't as fancy as the NM ones, but that could just as easily be considered a pro instead of a con.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @11:21AM

        by Anonymous Coward on Sunday September 28 2014, @11:21AM (#99149)

        or just use good ol' /etc/network/interfaces

        • (Score: 0) by Anonymous Coward on Monday September 29 2014, @04:40AM

          by Anonymous Coward on Monday September 29 2014, @04:40AM (#99464)

          That is going to get real old real quick if you actually use your laptop as a portable system. You want to manually configure wpasupplicant for every hotspot you connect to?

  • (Score: 5, Insightful) by _NSAKEY on Sunday September 28 2014, @07:19AM

    by _NSAKEY (16) on Sunday September 28 2014, @07:19AM (#99099)

    Pulse Audio has never worked for me adequately (Only solution is to apt-get purge it and fall back to ALSA, which has never caused me any grief), so I don't exactly trust Lennart Poettering and co to deliver anything that works. Combine that with all the arguments laid out against systemd in previous stories, and it all adds up to a desire to move to something else and watch the systemd-enabled distros burn. This is actually a good thing for small, up and coming distros since it has the potential to shake things up and make a lot of entrenched players irrelevant in a short amount of time (Just look at what started happening to Ubuntu once it started trying to forge its own way a few years back). Fragmentation sucks, but it's better than what we're getting now.

    That being said, if Debian doesn't reverse course or a Debian-based fork doesn't take off, I'll probably switch to a BSD full time after Wheezy is EOLed.

    • (Score: 1) by jbernardo on Sunday September 28 2014, @07:46AM

      by jbernardo (300) on Sunday September 28 2014, @07:46AM (#99107)

      According to the church of LP, repeating the fact that pulseaudio has issues is an ad hominen attack on their god, the infallible developer Lennart.Just check one guy posting as "interested" on the "boycott systemd site" thread on phoronix.

      I really should reply to him, but it is like punching walls.Nothing gets through - and worst, as he has such a view of LP and his works that even the facts that pulseaudio was unusable for ages and is still unstable could all be false, he won't acknoledge that no mather waht, the issue is always alsa drivers or users...

    • (Score: 1) by Arik on Sunday September 28 2014, @08:52AM

      by Arik (4543) on Sunday September 28 2014, @08:52AM (#99116)
      "That being said, if Debian doesn't reverse course or a Debian-based fork doesn't take off, I'll probably switch to a BSD full time after Wheezy is EOLed."

      BSDs are great but hardware support is very limited. You can keep the linux kernel with expanded hardware support and still avoid systemd quite easily, use Slackware or Gentoo.
      --
      "Unix? These savages aren't even circumcised!"
      • (Score: 2) by tonyPick on Sunday September 28 2014, @10:36AM

        by tonyPick (1237) on Sunday September 28 2014, @10:36AM (#99139) Homepage Journal

        If systemd becomes a core part of the dependencies for logging, networking tools, system login, user sessions etc. how long do you think Slack & Gentoo can avoid it for?

        • (Score: 1) by Arik on Sunday September 28 2014, @01:33PM

          by Arik (4543) on Sunday September 28 2014, @01:33PM (#99204)
          They can avoid it as long as they want. At worst they wind up either dropping or doing more work to keep things like Gnome and KDE. (Gnome is already a bear, and Slack hasnt included it in many years.)
          --
          "Unix? These savages aren't even circumcised!"
          • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @07:45PM

            by Anonymous Coward on Sunday September 28 2014, @07:45PM (#99319)

            Code doesn't bit rot. Keep on keeping on with an old version of gnome ( 2 or 1) and IDE. The different point releases are so far removed from each other they should be considered separate projects anyway, and separately install able. App armor or grsecurity completely mitigates against buffer overflow and other common attacks if you're worried about stable pieces of software having errors.

            • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @11:52PM

              by Anonymous Coward on Sunday September 28 2014, @11:52PM (#99393)

              That's total bullshit. New security flaws are discovered daily. Old code needs to continually be updated to address such flaws. The mktemp() is a good example of this. Old code that uses it needs to be updated, contrary to your bullshit claim that "code doesn't bit rot".

        • (Score: 5, Interesting) by tempest on Sunday September 28 2014, @02:47PM

          by tempest (3050) on Sunday September 28 2014, @02:47PM (#99218)

          If systemd becomes that widespread, I'd assume Gentoo and Slack will see a surge in uptake. At that point no systemd becomes a core feature people want in the distro, and I'd assume many more would put the effort in to keep it that way.

          I'm mostly a BSD user, but Linux fighting against systemd is very important for the BSDs as well. As desktop enviornments and software become dependant on systemd, they become inherintly non portable. Gnome 3 has pretty much written themselves off as Linux only. It's easy to sit back and laugh at the latest Linux cunundrum (one of the perks of being a BSD user), but in the process of fleeing systemd, you may find much of the software you want will no longer run on ANYTHING without it (Linux included).

          Also the "BSDs have no hardware support" thing is overblown in my opinion, so I wouldn't let that discourage you from trying it if you want to. One thing I don't think we need are Linux refugees, the people who use Linux because they hate windows, but now use BSD because they hate Linux. Use BSD because you love it :)

          • (Score: 3, Insightful) by Anonymous Coward on Sunday September 28 2014, @07:28PM

            by Anonymous Coward on Sunday September 28 2014, @07:28PM (#99312)

            I use Debian now, but I'm going to be switching to Gentoo.

            Systemd is actually a good litmus test of how sensible a distro's leadership is, as a collective. Smart leadership will, collectively, not put up with systemd. They'll be able to see its insurmountable technical flaws, as well as the way it can totally divide and devastate a distro's community. Debian's community is in tatters now thanks to systemd and how it has been forced on so many unwilling participants.

            I can't trust Debian, as a project, any longer. If they made such an obviously bad decision in this case, I can't help but think that they're making similarly bad choices when it comes to other decisions, some of which I may not even be aware of.

            Since I can't trust Debian, I can't trust the software they put out. The only sane thing for me to do is switch to a distro that hasn't gone all stupid and started using systemd.

        • (Score: 3, Interesting) by forsythe on Sunday September 28 2014, @06:11PM

          by forsythe (831) on Sunday September 28 2014, @06:11PM (#99266)

          I can't speak for Slackware (though I've heard very positive things about the dev team), but I know Gentoo has been willing to fork udev [gentoo.org] to get around systemd integration before.

        • (Score: 3, Informative) by tibman on Sunday September 28 2014, @07:08PM

          by tibman (134) Subscriber Badge on Sunday September 28 2014, @07:08PM (#99300)

          Gentoo has had systemd available for a while. You can actually choose what your init will be. http://wiki.gentoo.org/wiki/Comparison_of_init_systems [gentoo.org]

          --
          SN won't survive on lurkers alone. Write comments.
      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:06PM

        by Anonymous Coward on Sunday September 28 2014, @12:06PM (#99169)

        When was the last time you tried to use FreeBSD? It isn't 1997 any longer. FreeBSD has quite good support for a wide range of hardware. If we do see more and more people move to FreeBSD instead of bastardized shitheaps of systemd-infected Linux, then I think we will surely see FreeBSD's driver support improve to cover obscure edge cases that aren't currently supported well.

  • (Score: 5, Interesting) by jbernardo on Sunday September 28 2014, @07:27AM

    by jbernardo (300) on Sunday September 28 2014, @07:27AM (#99101)

    Having been involved in a distribution fork some years ago (the main developer took the repository down and left us no choice), I can say that there are two big issues to deal with.

    The first is obviously forking and all the associated logistical problems - site, forums, and repository hosting, management structure (elected "president"? benevolent dictator for life? council? Who are the electors? etc.), who maintains what, how to divide the packages, etc. - as well as the technical decisions - package format and which package manager, if any, to use, how to populate the repos, binary or source only, etc.

    The second huge issue is maintaining the core packages. I have the experience of maintaing some cumbersome ones (open office, jdk), and you really need free time to do it. Free time that I no longer had after a couple of years when I changed jobs, which meant abandoning the maintainer role, unfortunately. Lets face it, either you're paid to do the job, or you use the time where you could be with your family or doing something else. If you have the time, great - I had for some time and loved doing the maintainer role.

    Of course, this means that the paid maintainer is at an advantage, he can work only on the maintenance, not having another job to do during the day - and that any organization that wants to skew a distro only needs to devote some resources to that. But we know that, with the "redhatization" of most distros. Pushing systemd was easy as soon as some paid "volunteers" were in and had voting powers...

    • (Score: 3, Insightful) by VLM on Sunday September 28 2014, @11:50AM

      by VLM (445) Subscriber Badge on Sunday September 28 2014, @11:50AM (#99162)

      The terms of the fork need to be defined, and not just technically.

      The fork could be as minimal as a repo that never stops shipping alternative inits.

      Nobody actually wants to use gnome, so simply avoid doing so (not hard) and it'll be OK. I mean, really, its a playground for UI designers who vary from being overly experimental to being not very good. No end user wants gnome. Its the result of a committee decision about what devs think other devs think about users. What the users actually want or need is irrelevant, and it really shows in the end product.

      I'm struggling to think why I'd use oo.org instead of google docs, but if I did, its a further stretch to how it could possibly depend on the init. Ditto openjdk or emacs. Somehow I think xmonad will be free of the taint so I think I'm OK there. For over a decade my "linux desktop requirements" are openssh and a web browser and a way to switch between them, so I don't really care if someone's mp3 player or sudoku clone "needs" some weird init system.

      The other side is social. So now there's massive censorship being applied, etc. Being an "unfriendly" downstream you can realistically expect intentional sabotage, not to mention FUD. Culturally Debian is in deep decline, the whole takeover of SJW types now being in charge of censorship, weird security theater (which is another whole topic), this "if you're not with us, you're against us" WRT init systems...

      • (Score: 3, Insightful) by tonyPick on Sunday September 28 2014, @12:32PM

        by tonyPick (1237) on Sunday September 28 2014, @12:32PM (#99182) Homepage Journal

        The fork could be as minimal as a repo that never stops shipping alternative inits.

        Unfortunately the dependencies of userspace packages on other parts of systemd appear to make this a non-starter.

        So, for example when something like Gimp requires systemd (oh yes, yes it does) you're way beyond just dropping in another init. There's a fair amount of package reworking (at least rebuilding and bundling) which looks unavoidable, and going forward then compatibility with BSD and older systems doesn't appear to be something the systemd clients are losing sleep over, so syncing with a BSD distro might be simpler, at which point you might as well just bite the bullet and go the Open/Free BSD route.

        (I suppose you could run a ports on a Linux kernel, perhaps. Don't know if anyone has done that though...)

        See also: https://people.debian.org/~stapelberg/docs/systemd-dependencies.html [debian.org]

        • (Score: 3, Interesting) by Marand on Sunday September 28 2014, @01:00PM

          by Marand (1081) on Sunday September 28 2014, @01:00PM (#99195) Journal

          So, for example when something like Gimp requires systemd (oh yes, yes it does)

          I've seen this stated a few times in this and other discussions on SN and I'd like to know: what causes gimp to depend on systemd? I see nothing to indicate that when checking apt-rdepends gimp in Debian testing. I'm no systemd advocate, and I don't ask this to discredit; I just keep seeing the statement and I'm just curious where that particular belief came from. Is it an oddity in another distro?

          The only tie I can see in Debian is that, if you follow recommended packages (apt-rdepends --follow Depends,PreDepends,Recommends gimp) you get a dependency for libsystemd-login0 by way of dbus. However, that is a recommendation, not requirement, and thus optional. It's also not systemd, it's a library for interfacing with systemd. Dbus, for example, doesn't require systemd itself, while udisks2 and policykit have direct ties to systemd and will not function without it (apt-rdepends --reverse systemd).

          The curious one is udev. For a bit, Debian testing (jessie) wouldn't allow updating udev without also installing systemd because of a library it used requiring systemd. That doesn't seem to be the case currently, so it may have been a mistake. However, during that brief time, thanks to udev, nearly everything required systemd.

          • (Score: 2) by tonyPick on Sunday September 28 2014, @02:02PM

            by tonyPick (1237) on Sunday September 28 2014, @02:02PM (#99212) Homepage Journal

            I've seen this stated a few times in this and other discussions on SN

            Me too, and this is what I get for repeating things without researching them fully first :)

            You've basically hit the nail on the head with udev AFAICT - So there's a few links on google which talk about the breakages, but primarily the problem seems to be that the Gimp dependencies themselves have dependencies which will be tied to systemd components.

            So, apart from the the standard system backbone stuff like glib, dbus, etc, then the big one is gudev, which (I'm guessing, from a quick sweep through the source tree) Gimp uses to work input device management for things like graphic tablets.

            From LP himself back in May:

            this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point.

            http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI [phoronix.com]

            So, it is possibly to build without systemd (and lose functionality), and it looks like the eudev branch is providing a viable alternative for the dependencies for now, but how compatible that is I couldn't say.

            Basically this isn't as big a problem as I thought, but if Debian just goes systemd and/or doesn't package the right eudev then forking this will need more work than repackaging and it's a good example of how systemd migrates it's way through the system deps.

            (I'm looking at the gentoo deps list here: http://gentoobrowse.randomdan.homeip.net/package/media-gfx/gimp [homeip.net] and the LFS http://lfs-matrix.net/blfs/view/systemd/xsoft/gimp.html [lfs-matrix.net])

            • (Score: 3, Interesting) by Marand on Sunday September 28 2014, @02:57PM

              by Marand (1081) on Sunday September 28 2014, @02:57PM (#99219) Journal

              Me too, and this is what I get for repeating things without researching them fully first :)

              You've basically hit the nail on the head with udev AFAICT - So there's a few links on google which talk about the breakages, but primarily the problem seems to be that the Gimp dependencies themselves have dependencies which will be tied to systemd components.

              For now, at least, it's still just a case of a software recommendation that eventually leads back to systemd. The problem there is that Recommends are usually installed automatically, so the average user is likely to conflate this with a requirement when it's still optional*.

              As for Poettering's comment about not supporting systemd, that may be the case but there's still eudev (as you mentioned), and Debian has systemd-shim as a way to use other systemd (and udev) bits without requiring the init side. I don't know how long that will remain the case, but Debian has that kFreeBSD port, which can't use systemd, to consider, so it's hopefully going to last a while. Poettering and co. don't have any interest in non-Linux systems and kernels, and the longer it takes to port systemd elsewhere, the longer Debian will avoid complete tie-in.

              If you don't have access to Debian or Ubuntu directly, you can look at Debian and Ubuntu deps at packages.debian.org and packages.ubuntu.com, respectively, for an idea of how their dependencies work out. If you do, though, apt-rdepends is probably the best way to check the dependency tree. Even allows output in a format springgraph (from signing-party package) understands for creating an image from the relationships.

              ---

              * For the curious: synaptic has a checkbox to turn this off; apt-get has --no-install-recommends switch; aptitude has a checkbox to disable it; or you can change it by hand by putting APT::Get::Install-Recommends "false"; in a file in /etc/apt/apt.conf.d/

              I turned off auto-recommends years ago because it kept trying to add a lot of insane cruft I didn't care about. Good default for newbies, crap setting for Linux vets.

              • (Score: 2) by tonyPick on Sunday September 28 2014, @03:51PM

                by tonyPick (1237) on Sunday September 28 2014, @03:51PM (#99231) Homepage Journal

                I don't know how long that will remain the case, but Debian has that kFreeBSD port, which can't use systemd, to consider, so it's hopefully going to last a while.

                Yes, but it's pretty clear that the solution to that is that "supporting the kFreeBSD port isn't important" by at least some of the package maintainers, so I'm less hopeful.

                Skip to around 21:30 in this (Michael Stapelberg from Debconf 2013): http://www.youtube.com/watch?v=Hvy0e9kbAos [youtube.com] and the first two questions cover this (or watch it all; it's rather good and not very long).

              • (Score: 1) by canopic jug on Monday September 29 2014, @09:43AM

                by canopic jug (3949) on Monday September 29 2014, @09:43AM (#99519)

                Debian has that kFreeBSD port, which can't use systemd, to consider, so it's hopefully going to last a while.

                It's on the chopping block [debian.org] as far as jessie is concerned due to needing more porters. If a few more porters show up very, very soon, then the risk goes down.

                --
                Money is not free speech. Elections should not be auctions.
                • (Score: 2) by Marand on Monday September 29 2014, @10:27AM

                  by Marand (1081) on Monday September 29 2014, @10:27AM (#99522) Journal

                  Great, if that happens, we'll be lucky if the systemd-shim lasts beyond jessie's release. :( One Redhat to rule them all...

        • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:56PM

          by Anonymous Coward on Sunday September 28 2014, @07:56PM (#99322)

          I've been using both GIMP and Debian since the very early days.

          You know what? Fuck GIMP. It won't even let me ctrl-s anymore without awkard plugins or stay in its own desktop workspace. I never liked the feel of KDE much, but I'm sure there's an image manipulator tool there which hasn't gone full retard. And it has gotten to the point where I'm willing to give up my years of muscle memory and working knowledge of the program.

          • (Score: 0) by Anonymous Coward on Monday September 29 2014, @11:51AM

            by Anonymous Coward on Monday September 29 2014, @11:51AM (#99537)

            Yeah, the new versions of GIMP are really confusing for me, too. Why do I have to "export" to save as a PNG? Why does "save" only support XCF files? Why doesn't it just let me "save" as PNG, like it used to?

            • (Score: 0) by Anonymous Coward on Monday September 29 2014, @04:37PM

              by Anonymous Coward on Monday September 29 2014, @04:37PM (#99662)

              So you don't accidentally hose all your layer/undo information!

              I actually did that on a project years ago. Thankfully it turned out I still have a previous copy in xcf format, but as far as idiot proofing goes, it isn't a bad idea.

              On the other hand gtk-3 got me to drop everything gtk/gnome related until my desktops had 3d acceleration. GTK-3 is easily 3x or more slower than gtk 2 on non-composite capable hardware. I have no idea why, or if it has been remedied, but I've stuck to gtk2 or qt apps for everything now. And honestly given QT being under the LGPL for the past 3+ revisions I see no reason to use gtk2 if you're writing a C++ app, and if you're writing a pure c app, there's far far better alternatives than gtk3+glib that are far more likely to provide future compatibility and far fewer compatibility headaches.

            • (Score: 1) by GeminiDomino on Monday September 29 2014, @04:40PM

              by GeminiDomino (661) on Monday September 29 2014, @04:40PM (#99665)

              Because the developers know better than you what "users" want.

              And by "users", they mean "professional users", of course. There are "plenty of alternatives for amateur" use. (Yes, this was actually their excuse).

              Nevermind the fact that "professional users" are all using photoshop et al... which behave the same way that the old GIMP used to, wrt saving.

              In other words, more of the same self-indulgent wankery by asshole developers who apparently don't understand what a "Use case" is and bring us things like GIMP 2.8+, "Unified interfaces", and everything LP's ever shat out.

              --
              "We've been attacked by the intelligent, educated segment of our culture"
      • (Score: 2) by Marand on Sunday September 28 2014, @12:39PM

        by Marand (1081) on Sunday September 28 2014, @12:39PM (#99187) Journal

        The fork could be as minimal as a repo that never stops shipping alternative inits.

        If that's the case, the fork would only need to exist if Debian stops packaging systemd-shim and alternative inits. That isn't the case currently. That, however, isn't a good solution for avoiding systemd, because all you're avoiding is the init portion. You still have systemd installed, with all its other parts that you may not want*.

        As it stands currently, a systemd-free desktop distro is going to have to fork all the projects that depend on systemd in some form, such as udisks, upower, libpam-systemd, etc. Udisks is used for friendly block device management (removable storage), Upower for power management, and libpam-systemd (which directly requires systemd) is used for things like packagekit (package management stuff).

        Somehow I think xmonad will be free of the taint so I think I'm OK there. For over a decade my "linux desktop requirements" are openssh and a web browser and a way to switch between them, so I don't really care if someone's mp3 player or sudoku clone "needs" some weird init system.

        It doesn't really matter how little you use, or how far removed you think you are from the use cases that will put you in systemd's path. For example, udev has been folded into systemd upstream. At one point, Debian testing wouldn't allow updating udev without installing systemd, though I'm not sure if that was a temporary fluke that's since been fixed. When that happens, you don't avoid systemd unless you only use the console.

        If you want to abandon udev, you have to give up xserver-xorg-core, which means goodbye to xmonad and your (graphical) browser. At some point in the past few months, during an update, I was given two choices: "remove udev, xorg and anything that needs either" or "use systemd". I found systemd-shim, so I got to keep my init, but I've still got the other parts, like it or not. Eventually you will, too. Like you've said about systemd before: Embrace, Extend, Extinguish.

        The ray of hope here is that Gentoo has forked udev (eudev [gentoo.org]), so there's a possibility of eventually having repositories for other distros, if everybody else goes completely insane.

        this "if you're not with us, you're against us" WRT init systems...

        I don't think it's even that simple socially. When they were making the decision of whether to use upstart, init, something else, or stick to sysv-init, there were a lot of dissenting voices against systemd among the Debian people. And that's not even getting into the way it was presented as a purely technical issue, which limited discussion and voting to a subset and affected the outcome. It's quite possible that, depending on how this is handled from here, enough people will get pissed off and make a Debian fork possible.

        Might be futile in the long-term, though, because of how systemd is tying itself to everything possible. Normally if you don't like the direction distros are taking, you can just roll your own and avoid what you don't like, but this is different. If something doesn't change, it's possible that it will be easier to replace the Linux kernel in a Linux system than it will be to replace systemd.

        ---

        * You can avoid systemd as init easily enough, but you're still saddled with logind, journald, etc. I'm still using sysv init, but I'm not enjoying seeing systemd's other parts shit up my system logs.

        • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:49PM

          by Anonymous Coward on Sunday September 28 2014, @07:49PM (#99320)

          My system doesn't use any of that except udev for one.

          • (Score: 2) by Marand on Monday September 29 2014, @02:15AM

            by Marand (1081) on Monday September 29 2014, @02:15AM (#99432) Journal

            My system doesn't use any of that except udev for one.

            Irrelevant unless you've somehow convinced the would-be forkers to support a distro for one user. Those things provide functionality that's considered standard now, and are needed for most of the desktop environments (not window managers) in some form. Leaving out all the pieces that depend on systemd without providing alternatives means problems providing MATE, Cinnamon, KDE, possibly even Xfce. Power and removable storage management are used a lot by DEs. Even WindowMaker depends on upower now by way of the wmbattery dock-app.

            Even without udev (which is part of systemd now), systemd has managed to get its hooks into some of the most important parts of making a system user-friendly. Systemd's already reached the point where completely avoiding it will require a lot of work, forking, and maintaining your own versions unless you can convince the various upstreams to use alternatives.

            Unless someone is going to make a distro that only provides console apps and a tiling window manager, they're going to have to face these problems. It's not pretty, it's getting worse by the day, and people predicted it early on so there was plenty of warning that went unheeded.

  • (Score: 4, Informative) by LookIntoTheFuture on Sunday September 28 2014, @07:29AM

    by LookIntoTheFuture (462) on Sunday September 28 2014, @07:29AM (#99102)
    http://www.debianuserforums.org/viewtopic.php?f=12&t=3031 [debianuserforums.org]
    (This is the last link in the summary)

    I guess it was all a matter of time before Debian got tainted by corporate interests. So long, Debian! You've given me a choice, and I choose the highway.
    • (Score: 2) by LookIntoTheFuture on Sunday September 28 2014, @07:37AM

      by LookIntoTheFuture (462) on Sunday September 28 2014, @07:37AM (#99105)

      systemd criticisms silenced

      • (Score: 2) by aristarchus on Sunday September 28 2014, @08:04AM

        by aristarchus (2645) Subscriber Badge on Sunday September 28 2014, @08:04AM (#99108) Journal

        Do you seriously think that that was a typo? Their critics are sillienced!

        --
        came from aris5tarcfhus..; wee probably shouldn't run it
        • (Score: 3, Funny) by maxwell demon on Sunday September 28 2014, @09:54AM

          by maxwell demon (1608) Subscriber Badge on Sunday September 28 2014, @09:54AM (#99130) Journal

          Ah, I see a new flamewar coming up: Between the proponents of the silience daemon and the proponents of the silence daemon. ;-)

          --
          The Tao of math: The numbers you can count are not the real numbers.
          • (Score: 2, Funny) by Anonymous Coward on Sunday September 28 2014, @11:32AM

            by Anonymous Coward on Sunday September 28 2014, @11:32AM (#99152)

            I lold. (lol daemon)

    • (Score: 1) by Arik on Sunday September 28 2014, @08:58AM

      by Arik (4543) on Sunday September 28 2014, @08:58AM (#99119)
      This was pretty much inevitable from the moment they started allowing 'volunteers' who were actually corporate employees.
      --
      "Unix? These savages aren't even circumcised!"
    • (Score: 2, Flamebait) by darkfeline on Sunday September 28 2014, @10:00PM

      by darkfeline (1030) on Sunday September 28 2014, @10:00PM (#99363) Homepage

      Stop spreading more FUD. If you look at the supposed "systemd criticisms", they were inflammatory and deserved to be silenced


      Don Armstrong

      6:26 PM (11 hours ago)

      to listmasters, me
      On Thu, 25 Sep 2014, Gregory Smith wrote:
      > That is the story, that is what has happened. They have taken our
      > Linux distribution from us. The Frenchman above me is one of that
      > number.

      On Thu, 25 Sep 2014, Gregory Smith wrote:
      > This was an orchestrated fraudulent oligarchic takeover and charges
      > need to be brought agains you and them.

      These messages are off topic and inflammatory and have no place on
      -user.

      Further messages along these lines may result in removing your ability
      to post to -user or additional Debian mailing lists without further
      warning.

      --
      Don Armstrong http://www.donarmstrong.com/ [donarmstrong.com]

      This isn't life in the fast lane, it's life in the oncoming traffic
      -- Terry Pratchett

      Running around shouting "Systemd apocalypse is HAAAPENNINGG" will convince no one except other children like you.

      Now, there does seem to be a few good points in there from a quick skim, but all of them are accompanied by some version of "Lennart's cabal" or "Lennart POETTERING, PULSE-SHIT". Can the systemd-haters refrain from fear-mongering and ad-hominem, for maybe a week? long enough for a level-headed discussion to take place.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @11:13PM

        by Anonymous Coward on Sunday September 28 2014, @11:13PM (#99383)

        Oh systemd, Oh systemd
        Thy features are creeping
        Oh systemd, Oh systemd
        Thy features are creeping
        Taking over syslog, udev and cron
        Why, oh why can I not logon
        Oh systemd, Oh systemd
        Thy features are creeping

        Oh systemd, Oh systemd
        Much pain thou can give me
        Oh systemd, Oh systemd
        Much pain thou can give me
        How often has the binary log
        Corrupted X��[Kak�N��QS�� ��$tt(P�-#13
        Oh systemd, Oh systemd
        Much pain thou can give me

        Oh systemd, Oh systemd
        How poorly implemented are ye?
        Oh systemd, Oh systemd
        How poorly implemented are ye?
        Thou boots up fast but treacherous be
        You fuck up Unix unapologetically
        Oh systemd, Oh systemd
        How poorly implemented are ye?

        • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @11:56PM

          by Anonymous Coward on Sunday September 28 2014, @11:56PM (#99395)

          This briefly made the pain of systemd go away. But it roared back, like only a systemd infection can do.

      • (Score: 2, Informative) by Anonymous Coward on Monday September 29 2014, @12:04AM

        by Anonymous Coward on Monday September 29 2014, @12:04AM (#99399)

        Have you seen what has happened to Firefox? Have you seen what has happened to GNOME? Those are two projects that have been utterly destroyed thanks to stupidity like we're seeing with systemd. It's utter, utter stupidity, and the end result is always the same: the project that's infected ends up dead.

        Firefox is well under 10% of the market now. GNOME 3 is a complete disaster. They're dead projects, for all intents and purposes. Maybe they'll still put out releases, but they've only got a very small number of users remaining.

        Nobody is crying wolf here. Systemd is a serious problem, and it looks like it's going to tear apart the Debian project. If Debian does manage to survive, it will be a severely wounded project. There are many long-time Debian users who are feeling very betrayed over how this inferior technology has been forced upon them, and they will move to another distro that doesn't make such asinine decisions about such critical software.

        The only projects that are going to win out of all of this are Gentoo and FreeBSD, and maybe Slackware. They're the only ones showing any sense in this matter.

      • (Score: 2) by LookIntoTheFuture on Monday September 29 2014, @08:00AM

        by LookIntoTheFuture (462) on Monday September 29 2014, @08:00AM (#99499)

        children like you.

        I am not a child. Attacking me personally isn't going to solve anything. Silencing speech is a bad idea. Does that really need to be said? People are angry for some very good reasons. Let them speak.

        • (Score: 2) by etherscythe on Monday September 29 2014, @10:12PM

          by etherscythe (937) on Monday September 29 2014, @10:12PM (#99802)

          By way of comparison, what do you suppose would happen if we applied the same standard to Linus Torvalds? Is he qualified to speak on this matter perhaps? He hasn't, really, but I expect he'd have some choice words on the subject if he cared one way or another. Somehow I think calling him a child is not what we would do, and he would probably still be right.

  • (Score: 2) by present_arms on Sunday September 28 2014, @08:44AM

    by present_arms (4392) on Sunday September 28 2014, @08:44AM (#99115) Homepage Journal

    It's said earlier that laptops need systemd, that's utter bollox, I have 4 running PCLOS, no systemd and all run like a champ, one hasn't been rebooted except for kernel updates and more recently bash updates (I rebooted anyway although wasn't actually needed), to say systemd is needed for lappies is just wrong, systemd would be more for servers where if it does need a reboot can be brought back up faster due to parallel services being started, and that's all, as for the Debian fork, I look forward to one, no reason why not, then people who use debian can have a choice, with or without systemd, personally I'd go for the fork, if that doesn't happen I'll stick with PCLOS or Slack :)

    --
    http://trinity.mypclinuxos.com/
    • (Score: 5, Funny) by tonyPick on Sunday September 28 2014, @10:32AM

      by tonyPick (1237) on Sunday September 28 2014, @10:32AM (#99138) Homepage Journal

      would be more for servers where if it does need a reboot can be brought back up faster due to parallel services being started

      This is not what I hear from server admins, who find startup times dominated by POST up front and the Primary applications at the back, and seem to be viewing diagnosing parallel startup and binary logging as the devil.

      I've noticed a circular not-for-you-but-these-guys from various systemd arguments.

      "It's for Servers"
      "Wait, I administer servers, and this won't really help me in any way and is particularly bad in others"

      "Actually it may help servers, but really it's going to be great for embedded systems"
      "Hang on, I develop embedded systems and (outside of SBC and the odd system integrator), everybody either ignores it or migrates away from it"

      "Ah, well. It's laptops that really need it."
      "My laptop does fine without it"

      "Maybe. But in the connected devices world of mobile phones it's essential"
      "The phone distros generally aren't using it though. And they're doing fine."

      "Well, actually it's the kernel guys that made us do it. For cgroups. And that matters for Servers!"
      ...repeat...

      • (Score: 2) by E_NOENT on Sunday September 28 2014, @10:41AM

        by E_NOENT (630) on Sunday September 28 2014, @10:41AM (#99141) Journal

        ...who find startup times dominated by POST up front...

        Amen to that. It's gotten a little out of hand...

        --
        I'm not in the business... I *am* the business.
        • (Score: 4, Interesting) by VLM on Sunday September 28 2014, @11:32AM

          by VLM (445) Subscriber Badge on Sunday September 28 2014, @11:32AM (#99151)

          For reasons very on topic to this article discussion, I installed freebsd 10.0 on Friday and started working on my recipes to integrate it with everything else.

          The default boot loader for freebsd pauses for 10 seconds asking if I wanna go normal/multiuser or singleuser/rescue or whatever other options. The rest of the boot takes less time than that bootloader pause.

          There's some heavy propaganda that its impossible to boot quickly without systemd but freebsd is pretty snappy, and it wastes most of its time in POST and bootloader anyway.

          Another weird problem I've observed is xorg and friends take longer than the rest of the system.

          So its like 10 seconds to post, 10 seconds for the boot loader, system boots in like 5 seconds, X takes maybe 10 seconds. Then LDAP and AFS (or maybe kerberos?) are unhappy for perhaps the first 3 minutes or so, such that I can't log in. If I could magically lower my system boot time to zero it would only improve boot times by about 3%. And the improvement isn't going to be that great and the pain isn't going to be worth it (very gentoo)

          And this is on a desktop with all kinds of stuff running. The servers usually only have one service, so "mysql", thats it, so they boot even faster.

          • (Score: 0) by Anonymous Coward on Monday September 29 2014, @04:48PM

            by Anonymous Coward on Monday September 29 2014, @04:48PM (#99669)

            Are fscks, scsi device enumeration, and more recently: udev(systemd?) hanging the system for 30 seconds over whatever that module 'issue' was that Lennart complained to Linus about. The only other one has been ubuntu hanging for 60 seconds on network bringup for devices that aren't in the system (I've migrated HDDs between systems pretty regularly, either due to upgrades, to save time rearranging hardware, or just curiousity.) In that regard I haven't found a good way to either purge old network configs, or at least get it to ignore them for a faster bootup. Given that these systems are up for weeks/months at a time on average it hasn't been a major deal however. And in that regard system falls flat regarding benefits versus complexity. Most all of the plug and play features offered by systemd were already available from other sources. Most of them worked in a transparent fashion (Save maybe using Thunar or E17 for removable drive mounting instead of gnome/systemd.. do both of those use gvfs as their backend?)

        • (Score: 2) by present_arms on Sunday September 28 2014, @11:32AM

          by present_arms (4392) on Sunday September 28 2014, @11:32AM (#99153) Homepage Journal

          Can't argue with any of those points, POST on a server is a bane sometimes. Luckily a reboot for servers is a rare occaision (one would hope). I personally will be avoiding systemd with a passion, I'm pretty sure there will be more forks happening as more distros move to systemd.

          --
          http://trinity.mypclinuxos.com/
          • (Score: 2) by present_arms on Sunday September 28 2014, @11:37AM

            by present_arms (4392) on Sunday September 28 2014, @11:37AM (#99156) Homepage Journal

            apt-get install systemd
            Reading Package Lists... Done
            Building Dependency Tree... Done
            E: Couldn't find package systemd

            This is what I like to see :D

            --
            http://trinity.mypclinuxos.com/
            • (Score: 2) by maxwell demon on Sunday September 28 2014, @12:22PM

              by maxwell demon (1608) Subscriber Badge on Sunday September 28 2014, @12:22PM (#99178) Journal

              As a workaround you could create and install a package "sanity" which declares conflict with systemd. Then any attempt to install systemd will tell you that you'd first have to remove sanity.

              Now all you have to do is to make the kernel package depend on sanity, and systemd cannot be installed any more. :-)

              --
              The Tao of math: The numbers you can count are not the real numbers.
              • (Score: 2) by present_arms on Sunday September 28 2014, @12:58PM

                by present_arms (4392) on Sunday September 28 2014, @12:58PM (#99194) Homepage Journal

                That's actually a cool idea :)

                --
                http://trinity.mypclinuxos.com/
                • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @01:19PM

                  by Anonymous Coward on Sunday September 28 2014, @01:19PM (#99198)

                  A better idea is for Debian to just not include systemd at all.

                  • (Score: 2) by present_arms on Sunday September 28 2014, @02:58PM

                    by present_arms (4392) on Sunday September 28 2014, @02:58PM (#99221) Homepage Journal

                    Right, but it seems to be a done deal and anyone objecting seems to be silenced, it's heartbreaking that a once great distro is willing to be this stupid.

                    --
                    http://trinity.mypclinuxos.com/
          • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:00PM

            by Anonymous Coward on Sunday September 28 2014, @12:00PM (#99164)

            Luckily a reboot for servers is a rare occaision (one would hope).

            Even on a rolling release distro like arch, It used to be kernel upgrades only. I could skip minor kernel releases for months unless I knew there was an issue. Now with systemd, there's so many packages not to be upgraded that it's impossible to keep track of what exactly is going on. Basically, I wait until I start seeing weird log messages about missing PAM modules and the like. Wait until I'm next on site (because if something goes wrong with pid 1...) and reboot then. For offshore cloud based servers, I run a backup and cross my fingers before rebooting.

            Systemd -- the spanner in the works.

            • (Score: 1, Informative) by Anonymous Coward on Sunday September 28 2014, @12:34PM

              by Anonymous Coward on Sunday September 28 2014, @12:34PM (#99183)

              Jesus Christ. Are these log messages about missing PAM modules showing up in systemd's binary logs? As an AIX admin, all of this stupidity from the systemd crowd really blows my mind. The fact that their software can fuck up PAM while logging about it to an unreadable binary log file is just astoundingly dumb.

        • (Score: 2) by cafebabe on Sunday September 28 2014, @12:38PM

          by cafebabe (894) on Sunday September 28 2014, @12:38PM (#99186) Journal

          By my calculations, a full marching bit test [eventhelix.com] on DDR3-1600 RAM would progress at 50MB/s. I assume shortcuts are taken, such as testing memory modules in parallel.

          --
          Now is a good time to clear your cookies.
          • (Score: 2) by E_NOENT on Sunday September 28 2014, @02:17PM

            by E_NOENT (630) on Sunday September 28 2014, @02:17PM (#99213) Journal
            --
            I'm not in the business... I *am* the business.
            • (Score: 2) by cafebabe on Sunday September 28 2014, @05:38PM

              by cafebabe (894) on Sunday September 28 2014, @05:38PM (#99254) Journal

              So, in that example, a server with 64GB takes 309 seconds to boot. 137 seconds is for the memory test. That's about 0.5GB/s. But, hey, after you've diagnosed conflicts, systemd will reduce that by about 0.5 seconds.

              --
              Now is a good time to clear your cookies.
              • (Score: 2) by E_NOENT on Sunday September 28 2014, @07:44PM

                by E_NOENT (630) on Sunday September 28 2014, @07:44PM (#99317) Journal

                I agree.

                The whole "faster boot times" schtick is pretty meaningless IMHO.

                --
                I'm not in the business... I *am* the business.
                • (Score: 2) by cafebabe on Sunday September 28 2014, @07:51PM

                  by cafebabe (894) on Sunday September 28 2014, @07:51PM (#99321) Journal

                  The claim of faster boot times is worse than meaningless. It demonstrates a lack of understanding of typical requirements and it demonstrates a lack of understanding of Amdahl's law [wikipedia.org].

                  --
                  Now is a good time to clear your cookies.
      • (Score: 2) by emg on Monday September 29 2014, @03:53AM

        by emg (3464) on Monday September 29 2014, @03:53AM (#99452)

        Yep. Our new servers take six minutes to get through POST. Linux boot time is irrelevant in comparison.

        Fortunately they only get rebooted about once a year.

        • (Score: 2) by cafebabe on Monday September 29 2014, @06:37PM

          by cafebabe (894) on Monday September 29 2014, @06:37PM (#99714) Journal

          It occurs to me that 99.999% uptime allows 315 seconds of downtime per year. Therefore, high availability can definitely not be attained with a single server, a large amount of memory and an annual reboot.

          --
          Now is a good time to clear your cookies.
    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @11:49AM

      by Anonymous Coward on Sunday September 28 2014, @11:49AM (#99160)

      i'm still using sysvinit on a debian wheezy vm on my laptop, but when i eventually decide to dist-upgrade i might avoid systemd if it turns out to be as bad as folks are suggesting

      i'll just make sure the init system i want is installed (sysvinit most likely since it has worked well) and avoid any packages that depend on the parts of systemd that i don't like. particularly with all the hatred of systemd, i can't imagine it will be hard to find alternatives to various systemd-dependent packages in a couple of years... "may the forks be with you!"

      at the moment i use gnome (which i have discovered seems to have some dependency on systemd components on my system already) but if it gets to the point where gnome no longer serves my interests i'll probably switch to something like xfce (already using on my desktop).

      there seems to be a lot of hype about systemd. i'm not sure what's true and what's fluff, but eventually it will all settle down and i might find some reasonably technical and objective breakdowns of the differences and similarities between various init packages. till then i'm not going to get too excited.

      one of the strengths of linux has always been freedom of choice... there is little argument that corporate interests would aim to lock us in, but by the power of the almighty toe-cheese-infused gpl2, freedom will prevail.

      • (Score: 2, Interesting) by Anonymous Coward on Sunday September 28 2014, @12:13PM

        by Anonymous Coward on Sunday September 28 2014, @12:13PM (#99173)

        I'm writing this comment using a dinky Acer C720 chromebook running a systemd infected distro. It makes no difference to me in this case, the machine is nippy and boots to a shell prompt in just a few seconds. Overall, systemd is not something I need to mess with on this machine and the user experience is smooth. My definition of 'smooth' is perhaps different than most as I do almost everything from the shell (ie: login, su, systemd wifi-menu, package updates, exit su shell, startx).

        I have no reason to object to systemd based on the experience of running it on this machine. On my servers though, systemd is a complete disaster.

        • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:27PM

          by Anonymous Coward on Sunday September 28 2014, @12:27PM (#99181)

          can't imagine servers would have a big dependency on systemd... most debian servers would be better off sticking with tried and trusted sysvinit

          gnome doesn't really have any business being on a server

          • (Score: 1, Informative) by Anonymous Coward on Sunday September 28 2014, @12:36PM

            by Anonymous Coward on Sunday September 28 2014, @12:36PM (#99185)

            GNOME 3 doesn't really even have much business being on a workstation.

          • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @02:38PM

            by Anonymous Coward on Sunday September 28 2014, @02:38PM (#99217)

            can't imagine servers would have a big dependency on systemd...

            Err, systemd logind and systemd networkd for starters and of course they have their own (much maligned) journald and are about to add dhcp and ntp daemons. If only there were a light weight alternative that started processes and kept itself the hell off the rest of the system. We could call it 'initd'.

  • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @09:15AM

    by Anonymous Coward on Sunday September 28 2014, @09:15AM (#99123)

    Debian. Another entity to join the Gnome Foundation and Mozilla on the ash heap of history I see.

    • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @11:52AM

      by Anonymous Coward on Sunday September 28 2014, @11:52AM (#99163)

      I weep for the fallen! These once great projects, these once great communities, ruined by hipsters and systemd idiocy. Why, oh why, did it have to be them? Why did they have to succumb? WHY?

  • (Score: 1) by boristhespider on Sunday September 28 2014, @09:47AM

    by boristhespider (4048) on Sunday September 28 2014, @09:47AM (#99126)

    of what's so bad about systemd and so great about init? I've got no irons in the fire here - I just like machines that work. Is there a genuine reason for all this upset over systemd? (Beyond the understandable reaction to change for change's sake.) For the record my desktop machine is currently dual-booting Mint, which so far as I know is on systemd, and my Macbook is dual-booting Fedora, which is definitely on systemd.

    • (Score: 5, Informative) by tonyPick on Sunday September 28 2014, @10:18AM

      by tonyPick (1237) on Sunday September 28 2014, @10:18AM (#99135) Homepage Journal

      Init isn't great, but it's been good enough for 20 or 30 years, and whilst systemd is sort of replacing init, it's also throwing in a much wider re-architecture of the basic system at the same time, and then pushing this onto most everyone else by breaking compatibility with "non-systemd" approaches and making sure Gnome requires it.

      And, reprinting my comment from the last time we did this:

      Fundamentally? systemd is trying to do Too Damn Much and weld it in via the init system, which could be better, but isn't terribly broken for most all the traditional use cases.

      Removing and improving on legacy init is one job (which does need doing). The consolidation and centralisation of a grab bag of system capabilities into a common infrastructure is a different job; systemd is munging them both into one thing. Bad.

      So for any core system update you're balancing risk, benefits and costs: As a developer/user (primarily in the mid-range embedded space) I'm seeing no solid benefits, large risks and massive knock on costs on the future of the infrastructure, as systemd becomes an increasingly pervasive dependency for everything from logging to authentication to networking etc...

      It's not a "vi versus emacs" that if you don't like it you pick something else and go with that - it's becoming increasingly hard (as per TFA) to avoid the damn thing. This should be because it's *better*, but it isn't - it's because it's *different*. This is not a problem for Gnome and Redhat, and if you're looking at their distribution then this may even be a good thing, but the world is not RHEL, and we aren't all worried about containerised Gnome.

      I could go on, but whilst I don't agree with it all this essentially covers a lot of what I would say: http://ewontfix.com/14/ [ewontfix.com] [ewontfix.com]

      Now having said all that; I'd _like_ to be wrong, and for it to be a painless improvement, but having looked at it I'm not seeing anything persuasive from the systemd folks and from the sheer level of crud thrown about (e.g. the Kernel debug line debacle, wrong on *so* many levels) to the state of the docs (quantity != quality) to the source code in the repo (journal-qrcode.c? Seriously?) don't fill me with the warm and fuzzies.

      See also: http://blog.lusis.org/blog/2014/09/23/end-of-linux/ [lusis.org]

      • (Score: 3, Insightful) by maxwell demon on Sunday September 28 2014, @11:30AM

        by maxwell demon (1608) Subscriber Badge on Sunday September 28 2014, @11:30AM (#99150) Journal

        breaking compatibility with "non-systemd" approaches

        That's the biggest problem. Just like Gnome 3 making sure you couldn't run your old Gnome 2 applications (not even by installing Gnome 2 on the side, due to conflicts between the libraries). And Firefox breaking some extensions on almost every update.

        Thou shalt not create incompatible interfaces.

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 0) by Anonymous Coward on Monday September 29 2014, @03:18AM

          by Anonymous Coward on Monday September 29 2014, @03:18AM (#99441)

          That's the biggest problem. Just like Gnome 3 making sure you couldn't run your old Gnome 2 applications (not even by installing Gnome 2 on the side, due to conflicts between the libraries). And Firefox breaking some extensions on almost every update.

          Thou shalt not create incompatible interfaces.

          The same for Linux API. So what? Don't use programs that you don't like. I haven't had Firefox break any extensions I use on any upgrade yet, and I don't even use Gnome since it's slow and bloated.

          • (Score: 0) by Anonymous Coward on Monday September 29 2014, @11:54AM

            by Anonymous Coward on Monday September 29 2014, @11:54AM (#99538)

            I don't want to use systemd. I'd love to avoid it completely. But how the fuck am I supposed to do that if Debian forces it onto my systems? Now I have to give up Debian completely, just because they made a stupid decision in one area? That's bollocks! Total bollocks! Systemd just shouldn't be included in Debian at all. If users want systemd, make them switch to Fedora or one of the other shitty distros that uses it.

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @10:32AM

      by Anonymous Coward on Sunday September 28 2014, @10:32AM (#99137)

      First off there isnt really a single init, we talk about SysV but that's just a specification and everyone made their own slightly different implementation. Some are better than others. There are also a whole new generation e.g. runit s6 finit openRC monit dmd and others that enable the same sorts of additional features that systemd does.

      The difference is that systemd has powerful corporate backing, and it keeps rolling up other aspects of the system, completely outside of the scope of an init system, which it then alters. Embrace, extend, extinguish - well systemd is classic extend. Journald is required, and it uses a binary file format for logging, which is ridiculous and unacceptable. It's eaten consolekit, it's eaten udev, and it's getting harder and harder to work around it.

      A couple of differences between it and the alternatives; working with existing tools versus requiring reinvented tools, and being designed to work with arbitrary components versus requiring unrelated components all be selected as a block.

      One more difference - a corporation funding development and pushing adoption. Now why on earth would free software people let anyone *push* us to adopt something? Have we really learned nothing?

      This [coreos.com] is what it is about - and in a nutshell you could say it's Android for server farms.

    • (Score: 5, Insightful) by mtrycz on Sunday September 28 2014, @10:57AM

      by mtrycz (60) on Sunday September 28 2014, @10:57AM (#99144)

      I won't go into the gritty details, here's a quick overview. It'll be lenghty nonetheless.

      I don't know if this was clear form the start, but systemd wants to become the OS. Instead of small and simple (single-purpose) utilities, you have centralized everything: startup, logs, etc. It's a monolithic piece of software. It does present advantages: mainly performace increases (since it's tightly coupled with many software, last addition is Gnome3, so you have a faster desktop, like it even matters) and startup times (am I the only one to think this doesn't even matter?). For distro developers systemd comes in handy, because the more things are integrated, the less things they need to configure. Also they say it's well documented, so it's easier to integrate and use than replacement software (can't confirm: didn't check it out).

      This philosophy goes right against the unix motto of doing one thing right. That's how admins like their systems, for lots of hardened reasons. One example: this week we had a serious vulnerability in bash. bash is a widely used piece of software, it does one thing, it has alternatives you can use (been looking into zsh lately), and when a fix comes out you can easily patch it. The codebase is kinda big, but it's focused on one thing only: processing commands and running scripts. Bugs (and security holes) pop around all of the time, even in time-proven software, but then it's not that difficult to fix. Also, small, modular software is easier to audit, if need be.

      systemd is ever growing, instead. It does multiple things, and is over 250k lines-of-code already; it will continue to grow, because features! You probably already know that big software is harder to debug (or audit) than smaller code. We'd all rather stick with single-purpose utilities.

      An other fact is that the authors of systemd don't really like being questioned. If you ask "did you really had to do binary logs?" you'll just get a middle finger. If you say "my binary logs got corrupted, how do I restore them?", they'll just WONTFIX.

      -------------------------
      TINFOILHAT WARNING: all of the above are facts; all of the below are my personal conjecture.
      -------------------------

      systemd is made at Red Hat, which has the US Army as their biggest contractor. It's not improbable that the services want to install a backdoor in you linux system. They pay Microsoft for backdoors in Windowses, they pay the big IT companies to hand over data, why wouldn't they want access to your Linux too? systemd is the perfect piece of software to install a backdoor to: it has all of the systems priviledges, it's too big and too fast-moving to audit; it's easy to put an undiscovered "bug" inside. Even if you assume the devs are in good faith.

      As I see it, Red Hat should roll their own OS (even if it's with the Linux kernell), and leave GNU/Linux alone. Let's call it sytemd/Linux, or something, or maybe Red Hat Enterprise OS?

      There are lots of other things to say, but this is *my personal* main concern. You can obviously read up more at
      http://boycottsystemd.org/ [boycottsystemd.org]
      http://judecnelson.blogspot.com.au/2014/09/systemd-biggest-fallacies.html [blogspot.com.au]
      and other sources. Some are more technical, others more security oriented, others more choice oriented, but for me the backdoors in Linux is the #1 reason not to go with systemd.

      Everybody is welcome to add their own.

      --
      In capitalist America, ads view YOU!
      • (Score: 1) by boristhespider on Sunday September 28 2014, @11:04AM

        by boristhespider (4048) on Sunday September 28 2014, @11:04AM (#99145)

        Thanks to all three of you - very informative.

      • (Score: 2) by tonyPick on Sunday September 28 2014, @11:14AM

        by tonyPick (1237) on Sunday September 28 2014, @11:14AM (#99147) Homepage Journal

        TINFOILHAT WARNING:

        That _is_ a bit tinfoily. I'd agree that it's a lot harder to audit the systemd codebase, and that certain security agencies will *love* the opportunity to sneak in a bit of malicious code there and get it to own the entire system, however RH aren't necessarily in need of any further motivation than owning the core integration, and (by extension) being able to monetize a bigger slice of the market, control the direction of development, and keeping Oracle and Canonical on the back foot is a definite plus.

        (And hey, if I worked at RH I'd probably be busy convincing myself the whole "integrated modular platform" thing was a good idea too: It'd be developing tons of the shiny cool "stuff", and probably solving problems I actually had in the process).

      • (Score: 5, Insightful) by VLM on Sunday September 28 2014, @11:39AM

        by VLM (445) Subscriber Badge on Sunday September 28 2014, @11:39AM (#99158)

        One thing that concerns me about monoliths is giant codebase = giant security patches and giant updates in general. You can't upgrade init without rebooting for all practical purposes and even if there is a hack if something goes wrong...

        So in a non-monolith I can upgrade sysklogd or more likely rsyslog without rebooting anything or even the slightest danger of reboot. With a monolith, nope. Like using Windows again. Reboot reboot reboot reboot. No thanks.

        I mean, my god, they're trying to integrate dhcp and ntp into it. Thats insane. All tightly coupled into ring 0. Dumb architectural idea.

        The other thing that concerns me is EEE embrace extend extinguish. Someone is being paid to shove a unreplaceable no-upgrade path unavoidable universal system down our throats because they have a submarine patent on "integrating ntp into an init system" or some such foolishness and after its utterly unavoidable we'll be issued lawsuits and licensing offers and gigatons of FUD from competitors. Pretty much the SCO/Novell thing all over except it won't be a lie, it'll really be true.

        • (Score: 1) by canopic jug on Sunday September 28 2014, @02:36PM

          by canopic jug (3949) on Sunday September 28 2014, @02:36PM (#99216)

          I mean, my god, they're trying to integrate dhcp and ntp into it. Thats insane. All tightly coupled into ring 0. Dumb architectural idea.

          The other thing that concerns me is EEE embrace extend extinguish. Someone is being paid to shove a unreplaceable no-upgrade path unavoidable universal system down our throats because they have a submarine patent on "integrating ntp into an init system" or some such foolishness and after its utterly unavoidable we'll be issued lawsuits and licensing offers and gigatons of FUD from competitors...

          Or DRM, to follow on with more speculation. There is no technical advantage to the architecture of systemd that I can see, only disadvantages -- unless. Unless the goal is to be a blob between the kernel and userspace and restrict and monitor all system components and data.

          The part that I find particularly strange and unfortunate is the fact that it is being slammed through important distros like Debian. Getting it into Debian means it spreads to downstream distros like Ubuntu and Knoppix, to name just two. But it also means further disregard for healthy software engineering practices. I could have seen either phasing it in over several releases and/or offering it as an option along side Upstart and Openrc. However, just slamming it through reeks. It raises big red flags about the process and the people pushing systemd.

          --
          Money is not free speech. Elections should not be auctions.
      • (Score: 5, Interesting) by zocalo on Sunday September 28 2014, @03:09PM

        by zocalo (302) on Sunday September 28 2014, @03:09PM (#99224)
        I'm no fan of SystemD, in fact we are currently migrating a large number of RHEL systems to BSD in part because of it [1], but some of your "facts" are actually FUD:

        SystemD is *not* monolithic, at least not any more. It's actually quite modular, consisting of a large number of separate binaries that can be include or excluded at build time. The problem here is that it is very easy for distros that have decided to adopt SystemD's init replacement to adopt everything else that does with it - it does make life a lot easier for them, so users get SystemD versions of Cron, Syslog and all the others on the growing list by default, whether they want them or not. Depending on the daemon it may be possible for the user the disable and replace the SystemD version, or they may need to run both in parallel - the amount of effort to do this however can be quite cumbersome, in a way no different from how Microsoft embeds IE into Windows (albeit at a much lower level, at least for now) - and that quite rightly provoked a lot of protests from those that didn't want it on their system in the first place.

        SystemD is *not* responsible for the applications that rely on the services it provides; e.g. Gnome. That is a decision that you need to lay with the relevant developers of the tools that have SystemD as a dependency, although since many of those development teams are heavily influenced by Red Hat you may feel free to make allegations of collusion - I certainly suspect this may have occured. SystemD itself actually has very few pre-requisites; the Linux kernel and a few other essential bits and pieces that will almost certainly need to be installed anyway, but that's about it.

        When it works (which is most of the time, to be fair), then for many users it does generally make life easier, and few users will need to do more than use SystemD to start/stop/disable daemons anyway. The original init, while it gets the job done, *is* long in the tooth. Debugging it can be a nightmare, despite the claims made by the team, and while the code might be somewhat modular many of the interprocess communications are still hard, if not impossible, to get a handle on depending on what state the system is in - especially given the braindead decision to adopt a binary logfile format. The "NOTABUG" / "WONTFIX" attitude of the devs is also well documented - unlike the software itself, although the documentation is still better than many other OSS projects.

        Personally though, I've made my view clear in several discussion on the topic here and on the other site: I'd still like to see SystemD replaced with something else, or at least take the current modularity to the next step, making it much easier for users to disable and/or replace services that it provides. Specifically, I'd like to see the various daemons SystemD is replacing in their own packages so I can, for instance, choose to install systemd-{daemon}, a third party daemon of my choice, neither, or both, depending on my personal preference and build requirements. That's an issue for the distros though, not the SystemD team, although they could certainly help make this task a lot easier for packagers to undertake. I'd also say that they need to make troubleshooting it when you are in recovery mode following a major crash or system compromise much easier, provide an option for text only logfiles, and addressing several other outstanding issues that people clearly have with it. SystemD is clearly dividing the Linux community, and while some might jump ship to BSD, the main beneficiary of this infighting is going to be Microsoft - and none of us want that.

        [1] We started looking elsewhere because we didn't like RHEL6 in general. We run a mix of desktops and servers, but mostly headless servers. The prevalence of SystemD prompted us to include BSDs in our candidates along with other Linux distros and the cleaner installs, less complex dependencies, and generally much faster performance we saw with BSD made us make the leap.
        --
        UNIX? They're not even circumcised! Savages!
        • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @03:54PM

          by Anonymous Coward on Sunday September 28 2014, @03:54PM (#99232)

          Some of the complaints could be expressed better, interesting that you dissected them when you are well aware of the real issues.

          SystemD is *not* monolithic

          Technically correct but as you point out, effectively not since the default for everything will be systemd-daemons and replacing them is cumbersome. I fear the word monolithic is being banded about here when the real complaint is that linux distros may become a monoculture.

          SystemD is *not* responsible for the applications that rely on the services it provides

          Systemd *is* responsible for consuming udev and dbus. The developers are responsible for making underhand political decisions and attempting to pass them off as technical concerns -- as if we're all morons.

        • (Score: 4, Insightful) by tonyPick on Sunday September 28 2014, @04:37PM

          by tonyPick (1237) on Sunday September 28 2014, @04:37PM (#99240) Homepage Journal

          SystemD is *not* monolithic, at least not any more. It's actually quite modular, consisting of a large number of separate binaries that can be include or excluded at build time.

          Great. So you can take a machine that doesn't have systemd and is running a 2.6 series kernel, and just run the standalone journald binary on it? Or put it on a BSD box? (Answer: not really)

          The thing that makes it monolithic is the fact that all the pieces of it are interdependent. Putting it into separate binaries makes it Modular, but it can still be a Monolithic architecture. Monolithic and Modular are not antonyms.

          Or, to quote wikipedia, a monolithic architecture is one in which the functionally distinct aspects:

          are not architecturally separate components but are all interwoven

          And given the systemd authors stance that you can't take out some key pieces like logind and reimplement it separately (See http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ [freedesktop.org]), that's a pretty good description of systemd to me.

          • (Score: 2) by zocalo on Sunday September 28 2014, @05:13PM

            by zocalo (302) on Sunday September 28 2014, @05:13PM (#99247)
            That's a semantic difference that you didn't make in your original post, hence my response. It is, however, one that I agree with - that's what I was getting at with the bit about being able to break the SystemD bundle up into different packages, then more cleanly and completely swap the non-PID1 components of SystemD out for alternates. At the moment I would also argue that it is monolithic in that context, but there is no technical reason why it couldn't become a suite of standalone tools, albeit with a high level of integration. The biggest issue with that though is likely breakages of those projects that have drunk deep of the SystemD kool-aid and insist on it being present to run, but you reap what you sow...

            Ultimately, I think SystemD is here to stay, and will likely end up as much a part of Linux as the kernel and GLibC. Too many distros have too much invested in it now to change direction, and it would be a rare distro that will be prepared to completely drop all of the growing numbers of packages that only work if SystemD is present. We can either keep bitching about it (which appears to be futile), produce a workable alternative that is appealing enough to encourage distros to switch (which will probably take too long given the growing list of dependencies upon SystemD that will break), or try and convince the SystemD team and distro packagers to address the concerns being raised by the community (which currently appears to be falling on deaf ears). It's a Hobson's Choice, but I think the last one is probably the best option - other than switching to BSD, anyway.
            --
            UNIX? They're not even circumcised! Savages!
      • (Score: 4, Funny) by maxwell demon on Sunday September 28 2014, @04:02PM

        by maxwell demon (1608) Subscriber Badge on Sunday September 28 2014, @04:02PM (#99235) Journal

        Maybe they should rename systemd to Master Control Program.

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 2) by aristarchus on Sunday September 28 2014, @07:44PM

          by aristarchus (2645) Subscriber Badge on Sunday September 28 2014, @07:44PM (#99318) Journal

          Tron? Is that you?

          --
          came from aris5tarcfhus..; wee probably shouldn't run it
        • (Score: 2) by danomac on Sunday September 28 2014, @10:18PM

          by danomac (979) on Sunday September 28 2014, @10:18PM (#99367)
          Better yet just rename it to Borg.
      • (Score: 2) by cafebabe on Sunday September 28 2014, @07:02PM

        by cafebabe (894) on Sunday September 28 2014, @07:02PM (#99295) Journal

        250k lines-of-code

        That code is likely to have more than one bug per 1,000 lines. A proportion of those bugs may be security flaws. Unlike init, systemd is network exposed. So, some of those bugs may allow remote attacks.

        Old code has less bugs per line because the bugs have been found in audits and through deployment. Unfortunately, the number of bugs may never be zero. As we've seen with a security flaw in bash being network exposed via various daemons, some bugs may survive for decades and may be deployed on hundreds of millions of devices before they are found. However, new code (especially code which replaces a working implementation [joelonsoftware.com]) is almost guaranteed to be a greater risk.

        --
        Now is a good time to clear your cookies.
    • (Score: 2) by Nerdfest on Sunday September 28 2014, @02:35PM

      by Nerdfest (80) Subscriber Badge on Sunday September 28 2014, @02:35PM (#99215)

      If nothing else, binary logging and binary configuration. Windows uses these and it causes rather a lot of problems.

    • (Score: 1, Informative) by Anonymous Coward on Sunday September 28 2014, @06:41PM

      by Anonymous Coward on Sunday September 28 2014, @06:41PM (#99283)

      systemd-udevd[142]: renamed network interface wlan0 to wlp1s0

      This is most helpful. Take descriptors that we understand perfectly like eth1 and wlan0 and turn them into cryptic strings.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:09PM

        by Anonymous Coward on Sunday September 28 2014, @07:09PM (#99301)

        Holy fuck, that is not acceptable. Every day I learn some new way that systemd fucks up something very basic.

      • (Score: 1) by GeminiDomino on Monday September 29 2014, @01:51PM

        by GeminiDomino (661) on Monday September 29 2014, @01:51PM (#99575)

        Dafuq? My first thought was "why would they turn the wireless card into a UFS partition?"

        --
        "We've been attacked by the intelligent, educated segment of our culture"
    • (Score: 3, Interesting) by hash14 on Sunday September 28 2014, @09:53PM

      by hash14 (1102) Subscriber Badge on Sunday September 28 2014, @09:53PM (#99362)

      The problem isn't just limited to the awful technical and design decisions which went into making it. Though systemd is rife with poor decision-making and design (which I will not get into), the biggest problem to me is what it means for the future of Linux and the Free Software environment.

      I personally have no qualms with _using_ systemd and am currently using a distro running it (which will be wiped in a few weeks and replaced with Slackware, Gentoo, or Freebsd). It's buggy, but that's the price you pay for user-friendliness.

      I was largely on the fence about systemd for a while - I knew a lot of people didn't like it, but wasn't sure if they were being purists or pedants. But now that Debian has been overtaken by the systemd mafia and the absurd political games taking control of the project and its technical decisions, I can see that it's the centerpiece of Red Hat taking a page from Redmond's book and using Embrace, Extend, Extinguish to eliminate all competitors. And the longer we delay in fighting it, the more hopeless the fight will become because systemd is such an important player in this vertical integration scheme.

      It's frankly shocking to me to see this happening in the Linux world, but I fear very much what will happen to the kernel, the popular DEs, and the myriad userspace applications which will become unusable simply because I choose to do something different from what Lennart Poettering tells me to do. In short, systemd is nothing less than a way for Lennart to take over the Free Software ecosystem (via udev, dependencies, etc.) and play Steve Jobs - you will get what I will give you, you will be told that it's the best thing you could possibly want, and (worst of all), dissent will be silenced.

      The Free Software ecosystem doesn't need a Steve Jobs. It does not need to become corrupted by Red Hat's commercial interests. And if it does, then we need a way to separate ourselves out from that - if we don't, then we risk losing everything that Linux has become up to this point.

      While this explanation may not pertain to you and your uses, I frankly think it would be a shame to see projects like BSD fade (or even disappear entirely) because they chose to not go down the same path of poor design that systemd decided to become. And I don't feel like I should be forced to use what other developers and maintainers decide simply because it was technically designed to preclude those alternatives.

      --
      In developed societies, "copyright infringement" is merely the sharing and partaking in culture.
    • (Score: 1) by Arik on Monday September 29 2014, @12:42AM

      by Arik (4543) on Monday September 29 2014, @12:42AM (#99407)
      I've been thinking about this for some time and I think I have come up with an analogy that should make it reasonably accessible (at least to a geek) and yet still not take more than a page.

      Think of the BASH bug. What would you do if you found out tomorrow that it was deliberately introduced, and furthermore that the core team had been compromised from the beginning and there were probably dozens of more subtle exploits left?

      Well, we'd switch to zsh. Or csh, tcsh, ksh, whatever freaking sh you prefer. There are several, they are independent, and they are essentially drop in replacements for each other, with each adding new features but maintaining backward compatibility so that scripts dont break. Each does the same job, and you dont really have to worry about 'does the new shell support all the same programs as the old one' - there is a standard interface and the program doesnt care which shell you used to start it.

      Same is true for practically any element of the architecture. Same is definitely true for inits. People talk about 'SysV Init' like it's a thing, but it's just a spec a lot of people implemented in their own way. But each init basically does that one thing, and each can be ripped out and replaced with whatever you want. Like, ironically, /bin/sh. Yes, that's right, want a really fast boot? Set /bin/sh to init, done, go home. Most people want a little bit more setup than that done before getting to the login prompt, but it DOES work, and your init CAN be as simple as a shell script with a few commands you got sick of typing in every boot.

      Now imagine a shell replacement that included an incompatible format for text, an editor for that incompatible format, and a large and growing pile of ABIs for program development and system management and so forth. It doesnt just replace the shell, but a good chunk of your system. And if you adopt it and use it, more and more of your work going forward will only be accessible to people using the same shell. Which is all well and good, cause it's better, see?

      Systemd is not just an init system, and you cannot just rip it out and replace it with another init system when you want to. The seriously disturbing track record of the main personalities behind it in regards to bugs is really beside the point. I want an init system. Not an init system + obligatory binary logger with a pointless broken text option + superwonderful obligatory binary log file viewer (want to suck it into vi for a sec for something? NO SOUP FOR YOU!) + dev manager (only non-obligatory at this point because of eudev - thank you gentoo!) + consolekit replacement (someone want to pick that one up and dust if off?) + "services management" suite all in one non-negotiable whole.

      I've watched the same kind of thinking at work in the Windows world for decades and Linux has been my refuge from that insanity. I have no intention of importing it.
      --
      "Unix? These savages aren't even circumcised!"
  • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @10:09AM

    by Anonymous Coward on Sunday September 28 2014, @10:09AM (#99132)

    nt

  • (Score: 5, Insightful) by pTamok on Sunday September 28 2014, @10:40AM

    by pTamok (3042) on Sunday September 28 2014, @10:40AM (#99140)

    One thing about the Unix philosophy, later adopted by many of those interested in GNU/Linux is the idea of "do one thing, and do it well".

    A problem I have seen for a while is the creeping existence of mandatory dependencies: both in requiring a large amount of software installed before a new package will work; and in packages having dependencies on software which seems completely orthogonal to the packages reasonable requirements.

    Why should a desktop requirement have a mandatory dependency on a system startup manager? Why should a particular software package have a dependency on a particular desktop environment? You get to the point that a simple wish to use a text editor or teminal emulator 'forces' use of a desktop environment, which in turn 'forces' the use of a particular system startup manager.

    A problem is that even if you choose to use a distribution that currently does not choose to use systemd, much, if not all of your favoured software will soon have systemd dependencies forced upon it, either directly, or via a desktop environment.

    One of the things that has characterises the free software movement is the availability of choice, but the situation described above appears to be shutting down choice. I suspect this runs contrary to what a large number of contributors to free software think is the right approach.

    I'm not a programmer, and I don't have the economic means to finance a maximal-choice distribution. At the moment, most people seem to be pointing towards Slackware as the hold-outs against systemd, but I wonder how long that can remain the case when desktop environments and other software force systemd dependence. I can move towards the BSDs, but it will be with a sad look back to the Linux ecosystem that seems to be deliberately imploding. That said, all is not completely rosy in the BSD world, if you look at this list of reasons NOT to use BSD: http://www.phoronix.com/scan.php?page=news_item&px=MTExMjE [phoronix.com] which followed a list of reasons why you might want to use BSD: http://www.phoronix.com/scan.php?page=news_item&px=MTExMDg [phoronix.com]

    How long will it be before LibreOffice and Thunderbird have systemd dependencies, I wonder?

    As a long-standing GNU/Linux user, I have dabbled in Debian and SuSE, but ended up using Ubuntu (as I didn't have the time to dabble any more). I wonder what I'll be using in 5 years.

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:02PM

      by Anonymous Coward on Sunday September 28 2014, @12:02PM (#99166)

      Most of LibreOffice user base, same for Mozilla products, are Windows users, so enforcing dependency on a Linux specific feature seems a little like ninihammering.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:14PM

        by Anonymous Coward on Sunday September 28 2014, @12:14PM (#99174)

        For those who don't know, "ninihammering" is British slang for an act that involves one gay man anally penetrating the anus of another man (the "ninny") with swift and hard thrusts (the "hammering") without the use of lubricant. Apparently this is often done at gay clubs, where the encounters are casually done in washroom toilet stalls without much time to prepare.

  • (Score: 2, Funny) by Anonymous Coward on Sunday September 28 2014, @10:49AM

    by Anonymous Coward on Sunday September 28 2014, @10:49AM (#99142)

    Systemd is the linux/unix equivalent of the Holocaust. It's a 'there's one right choice' solution to the citizenry of a 'nation', the elimination of existing minorities who were influential in the shaping of the history of the illustrious nation and a condemnation of much or all of their potential for future improvements. It is the will of an 'influential minority' convincing the majority of what is good for them while silencing any similiarly influential opinions and focusing the peoples rage on groups they are willing to hate to subvert their democratic process.

    A blog is Lennart Poettering's Mein Kampf, Redhat is his NSGWP, Debian's current 'inner circle' is his SS, and Ubuntu/Fedora are his Hitlerjungend.

    All hail the rise of the 4th Reich, for it is they who know best and they who shall control the world!
      0
    \|_
      ^
    / \

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @11:40AM

      by Anonymous Coward on Sunday September 28 2014, @11:40AM (#99159)

      As Godwin would have it, the moment you compare someone to Hitler you've lost. In this instance however - you win.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:23PM

        by Anonymous Coward on Sunday September 28 2014, @12:23PM (#99179)

        ...do we all lose, because those who don't remember history are doomed to repeat it. And since the people snowballing the current systemd situation are all far to young to remember this firsthand, having neither cracked open a history book nor asked their, no doubt now deceased, forebears about the situations which they had lived through since the turn of the 21st century. The consequences of an uneducated majority being that against the protestations of an educated minority and a 'more agreeable' minority, educated or not, the sheeple will always choose the latter.

      • (Score: 1) by GeminiDomino on Monday September 29 2014, @02:14PM

        by GeminiDomino (661) on Monday September 29 2014, @02:14PM (#99585)

        As Godwin would have it, the moment you compare someone to Hitler you've lost

        Not actually true. Godwin's Law simply states "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1."

        --
        "We've been attacked by the intelligent, educated segment of our culture"
    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @02:57PM

      by Anonymous Coward on Sunday September 28 2014, @02:57PM (#99220)

      So there must be a wealthy businessman who's keeping a secret list of machines that will be spared from the devastation of systemd?

  • (Score: 2) by LookIntoTheFuture on Sunday September 28 2014, @12:10PM

    by LookIntoTheFuture (462) on Sunday September 28 2014, @12:10PM (#99172)
    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @12:24PM

      by Anonymous Coward on Sunday September 28 2014, @12:24PM (#99180)

      Christopher Barry knows what's going on and says it like it is. That man is a true gem among the dirt.

  • (Score: 2) by kaszz on Sunday September 28 2014, @03:02PM

    by kaszz (4211) on Sunday September 28 2014, @03:02PM (#99222) Journal

    All this uproar and coups make me wonder what forces are really running the show..

    SCO was a Microsoft puppet. Perhaps there are more..

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @03:35PM

      by Anonymous Coward on Sunday September 28 2014, @03:35PM (#99229)

      Sure but there's no need for tinfoil hattery. The facts are:

      1. We all know Microsoft would love linux to be this singular thing that it could pick a fight with (halloween documents etc).
      2. We all know systemd is not at all unix-like, resembling something an obnoxious phb may shit out at a meeting.
      3. Systemd is aggressively positioning itself as the only option for linux.

      .

      It's the 3rd point that raises our suspicions and ire and it's also why systemd free distros can be guaranteed wide support.

    • (Score: 2) by tonyPick on Sunday September 28 2014, @04:53PM

      by tonyPick (1237) on Sunday September 28 2014, @04:53PM (#99243) Homepage Journal

      I have to say I think that's a bit of a Tin-Foil-Hat stance.

      If you read around the thread you can see I'm far from convinced about systemd (to put it mildly), but I think that it's fairly clear that the developers think they're doing the best they can for the problems they have, and that they *are* taking a lot of uninformed flack which makes them prone to be... undiplomatic at times.

      And there *is* a lot of cool stuff in systemd, and some nice ideas, it's just I think the way it's being made into a system wide dependency is the wrong approach. I'd like a new init, and the systemd folks want, in their own words

      systemd is in the process of becoming a comprehensive, integrated and modular platform providing everything needed to bootstrap and maintain an operating system’s userspace.

      and

      Choosing systemd means redefining more closely what the Linux platform is about.

      Neither of which I'm a fan of.

      Or, if you want to put it more cynically, in the words of Humbert Wolfe:

      You cannot hope to bribe or twist,
      thank God! the British journalist.

      But, seeing what the man will do
      unbribed, there's no occasion to.

  • (Score: 1) by Whoever on Sunday September 28 2014, @06:47PM

    by Whoever (4524) on Sunday September 28 2014, @06:47PM (#99286)

    systemd is supposed to be a replacement for syslog, ntpd, dhclient, etc.. All these individual programs have their own maintainters and yet there are almost certainly bugs.

    He reliable and bug-free can systemd possibly be when replacing all these other daemons? One small team to produce functionality that has been supported by people with years of experience of that particular problem. I expect that systemd will be full of bugs.

    The next problem is the demonstrated attitude of the systemd maintainers to bugs.

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @08:56PM

      by Anonymous Coward on Sunday September 28 2014, @08:56PM (#99341)

      The NSA, Spooks, Criminals are gonna love these "bugs".
      NSA is behind this mess.

  • (Score: 2, Informative) by Anonymous Coward on Sunday September 28 2014, @07:05PM

    by Anonymous Coward on Sunday September 28 2014, @07:05PM (#99298)

    Since I'm a Debian Developer, though I don't work with any init system, may I suggest that Debian is not "ramming something down your throat". SysV was abandoned for some good reasons, like no one maintained it upstream or cared to. It's also a fragile system. Anyway, you can use any of

    1. systemd
    2. sysvinit-core
    3. upstart

    And with sysvinit-core, you can use sysv-rc, file-rc or openrc

    Just because systemd will be the default, does not mean you can't use another init. What's the purpose of a fork anyway? If the purpose of a fork is to just make sysvinit-core with sysv-rc the default - each use can do that already. Maybe instead of forking Debian, invest that time helping sysvinit maintainers in Debian that are trying to keep SysV functional.

    There is also, https://wiki.debian.org/Debate/initsystem/openrc [debian.org]

    I use Debian on my desktop since the turn of this century. I've only recently started using systemd and the experience is relatively good. It does not matter to me which init system Debian runs as long as it runs, and the system is maintained.

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:34PM

      by Anonymous Coward on Sunday September 28 2014, @07:34PM (#99313)

      That description is disengenous at best. The real situation there is

      1. systemd
      2. systemd+sysvinit-core
      3. systemd+upstart

      That's systemd being rammed down our throats. The Linux way would have been to arrange the init systems so that any one of them could be swapped for any other. That scenario is not possible.

      Stupidly, the final vote was deadlocked and should have gone on to vote F for further discussion, since more discussion is obviously needed, Overall the whole thing has been mismanaged, to add to the technical problems.

      • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @08:14PM

        by Anonymous Coward on Sunday September 28 2014, @08:14PM (#99328)

        Fundamental architecture changes weren't even within the purview of the technical committee to begin with. That requires a general resolution which never happened. The whole thing was a sham. Or a "bug" (not having systemd as default for us poor lemmings)

      • (Score: 0) by Anonymous Coward on Monday September 29 2014, @03:50AM

        by Anonymous Coward on Monday September 29 2014, @03:50AM (#99448)

        I was just able to completely purge systemd from Debian installation in Sid and use sysvinit-core instead.

        init
          --\ PreDepends (1)
                --\ systemd-sysv | sysvinit-core | upstart
        id systemd-sysv 215-4 -73.7 kB
        pd systemd-sysv 215-5
        p sysvinit-core 2.88dsf-53.2
        p sysvinit-core 2.88dsf-53.4
        pi sysvinit-core 2.88dsf-55.3 +254 kB
        p upstart 1.11-4

        Where is this "systemd is everywhere"? Don't use it. Don't use GNOME, I don't. I'm using fluxbox and starting X with startx from console. Now, if you want some notifications about volume mounting and stuff like that, then yes, you probably need systemd for it. And the reason is no one cares enough to provide an alternative with similar functionality.

        So, there are 3 choices,

        1. Use systemd and have functionality you like
        2. Don't use systemd and don't have functionality (because you don't care about it anyway)
        3. Cry on forums because world doesn't listen to you

        Anyway, here's the entire removal of systemd in Debian,

        --\ Packages to be installed (1)
        ci sysvinit-core +254 kB 2.88dsf-55.3
        --\ Packages to be removed (11)
        idA colord -879 kB 1.2.1-1 1.2.1-1
        idA gvfs -565 kB 1.22.0-1 1.22.0-1
        id gvfs-daemons -682 kB 1.22.0-1 1.22.0-1
        id libpam-systemd -304 kB 215-4 215-5
        id policykit-1 -337 kB 0.105-6.1 0.105-7
        id policykit-1-gnome -820 kB 0.105-2 0.105-2
        id systemd -12.0 MB 215-4 215-5
        id systemd-shim -47.1 kB 8-2 8-2
        id systemd-sysv -73.7 kB 215-4 215-5
        id systemd-ui -222 kB 3-2 3-2
        id udisks2 -1,525 kB 2.1.3-3 2.1.3-3

        In the end, I'm keeping Systemd for now, but I removed some of the cruft here that I don't use anyway (like udisk2, gvfs, colord, etc.)

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @08:50PM

      by Anonymous Coward on Sunday September 28 2014, @08:50PM (#99339)

      It does not matter to me which init system Debian runs as long as it runs

      It's when it doesn't run when it matters.

      But hey, when it doesn't you can always debug it or check the logs... oh wait!

    • (Score: 1) by Arik on Sunday September 28 2014, @11:11PM

      by Arik (4543) on Sunday September 28 2014, @11:11PM (#99382)
      "Since I'm a Debian Developer, though I don't work with any init system, may I suggest that Debian is not "ramming something down your throat". SysV was abandoned for some good reasons, like no one maintained it upstream or cared to."

      There is no upstream. SysV is a specification, not a project. Each implementation is specific to the OS it's designed for. If you, as a debian developer, thought there was some mythical 'upstream' that was unresponsive here you were sadly misinformed. But in actual fact these things tend to be nearly 'unmaintained' for the reason that mature stable software rarely requires maintenance.

      --
      "Unix? These savages aren't even circumcised!"
      • (Score: 1, Informative) by Anonymous Coward on Monday September 29 2014, @03:32AM

        by Anonymous Coward on Monday September 29 2014, @03:32AM (#99443)

        There was an upstream, look at the changelog,

        http://metadata.ftp-master.debian.org/changelogs//main/s/sysvinit/sysvinit_2.88dsf-13.1+squeeze1_changelog [debian.org]

        sysvinit (2.87dsf-1) unstable; urgency=low

            * New upstream release.
                - Update patch 10_doc_manuals to drop the parts now included upstream.
                - Drop patch 11_doc_mountpoint now included upstream.
                - Drop patch 13_doc_telinit now included upstream.
                - Update patch 14_doc_fsf_addr to drop the parts now included upstream.
                - Drop patch 15_doc_pidof now included upstream.
                - Drop patch 16_doc_runlevel now included upstream.
                - Drop patch 17_doc_halt now included upstream.
                - Drop patch 25_last_sanify now included upstream.
                - Drop patch 26_last_ipv6 now included upstream.
                - Drop patch 27_last_usageopts now included upstream.
                - Drop patch 28_last_full-time now included upstream.
                - Drop patch 30_strip now included upstream.
                - Drop patch 31_build_warnings now included upstream.
                - Drop patch 40_selinux now included upstream.
                - Drop patch 41_utmp_64bit now included upstream.
                - Drop patch 42_utmpdump_retval now included upstream.
                - Drop patch 45_pidof_symlink now included upstream.
                - Drop patch 47_pidof_chroot now included upstream.
                - Drop patch 50_bootlogd_exitcode now included upstream.
                - Drop patch 51_bootlogd_syncalot now included upstream.
                - Drop patch 52_bootlogd_createlogfile now included upstream.
                - Drop patch 53_bootlogd_ttyB now included upstream.
                - Drop patch 60_init_race now included upstream.
                - Drop patch 61_init_msg now included upstream.
                - Drop patch 63_init_longer_procname now included upstream.
                - Drop patch 64_init_reexec_env now included upstream.
                - Drop patch 64_init_set_PATH now included upstream.
                - Drop patch 65_init_u_in_06 now included upstream.
                - Drop patch 66_init_emerg_tty now included upstream.
                - Drop patch 67_init_hddown now included upstream.
                - Drop patch 69_init_waiting now included upstream.
                - Drop patch 70_init_consoleopen now included upstream.
                - Drop patch 70_wall_ttyname now included upstream.
                - Drop patch 71_wall_hostname now included upstream.
                - Drop patch 80_killall_pidof now included upstream.
                - Drop patch 80_killall_sched now included upstream.
                - Drop patch 81_killall_avoid_init now included upstream.
                - Drop patch 82_killall_exclude_pids now included upstream.
                - Drop patch 82_killall_retval now included upstream.
                - Drop patch 83_killall_manref now included upstream.
                - Drop patch 84_killall_fuse now included upstream.
                - Drop patch 85_killall_safecwd now included upstream.
                - Drop patch 90_shutdown_H now included upstream.
                - Drop patch 92_sata-hddown now included upstream.
                - Drop patch 93_sulogin_fallback now included upstream.
                - Drop patch 95_halt-name now included upstream.
            * Modify shutdown(8) manual page to make it more clear when -c
                work (Closes: #374038). Based on text proposal from Dan Jacobson.
            * New patch 50_bootlogd_devsubdir to change bootlogd to recursively
                search /dev/ for the correct terminal device (Closes: #376406).
            * New patches 60_init_selinux_ifdef and 70_compiler_warnings to get
                rid of compiler warnings.
            * Rewrite rules to unpatch after the 'make clean' to get rid of binaries
                depending on debian patches.

          -- Petter Reinholdtsen Sat, 25 Jul 2009 16:44:55 +0200

        Homepage: http://savannah.nongnu.org/projects/sysvinit [nongnu.org]

        If you think someone rewrites /sbin/init for every Linux flavour out there, you would not be correct.

  • (Score: 4, Interesting) by Subsentient on Sunday September 28 2014, @08:41PM

    by Subsentient (1111) <{subsentient} {at} {universe2.us}> on Sunday September 28 2014, @08:41PM (#99334) Homepage Journal

    The Epoch Init System [universe2.us]

    --
    Instead of getting bogged down in the infuriating details, focus on the unquestionably terrible big picture. -The Onion