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.

 
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, 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...

    Starting Score:    1  point
    Moderation   +3  
       Insightful=1, Funny=2, Total=3
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (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) 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.

      --
      1702845791×2
      • (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.

          --
          1702845791×2
          • (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].

              --
              1702845791×2
  • (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.

      --
      1702845791×2