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

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

    Total Score:   3  
  • (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) Subscriber Badge on Monday September 29 2014, @09:43AM (#99519) Journal

            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.