Slash Boxes

SoylentNews is people

posted by janrinok on Wednesday November 19 2014, @11:25AM   Printer-friendly
from the I-hope-we-don't-regret-this dept.

Ian Jackson's general resolution to prevent init system coupling has failed to pass, the majority vote deciding that the resolution is unnecessary. This means that not only will Debian's default init be systemd, but packages will not be required to support other init systems. Presumably, this means that using other init systems on Debian (without using systemd as a base) will not be possible without major workarounds, or possibly at all. It also leaves the future of Debian projects such as kFreeBSD unclear, as systemd is linux specific.

The vote results can be found here

The winners are:

Option 4 "General Resolution is not required"

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, Informative) by Marand on Wednesday November 19 2014, @06:08PM

    by Marand (1081) on Wednesday November 19 2014, @06:08PM (#117768) Journal

    Now I'm going to have to switch distros again. I guess I had a good run with Debian, but I'm not going to stay with a distro that doesn't care about what the users want. I usually expect that crap from proprietary software projects, so I'm just amazed this is happening.

    I'm not giving up on using Debian just yet. It still has systemd separated, so you only run it as init if you install systemd-sysv, and can instead install systemd-shim if something else on the system needs to use the other parts of systemd (like systemd-logind). That means it's possible to pin systemd-sysv to -1 priority and not have to worry about abrupt init and logging system changes, which is what I did.

    I created a file (name doesn't matter, but I used nosystemd) in /etc/apt/preferences.d/ with the following contents:

    Package: systemd-sysv
    Pin: release o=Debian
    Pin-Priority: -1

    With that in place, systemd-sysv can't be installed, so the worst that will happen is an update will try to install systemd-shim instead and you'll get the parts of systemd that the desktop bits (upower, policykit, etc) want without changing your init or logging. With that done it's just another annoying dbus/hal/etc layer of bullshit and is mostly harmless.

    (Another note for anyone upgrading from wheezy: you'll want to install sysvinit-core before doing the full update because of the old sysvinit package becoming a transitional one)

    I don't really like the situation, but it's still better than most distros and I'm not ready to jump ship to BSD yet. Ubuntu purged sysvinit a while back in favour of upstart and others are doing the same thing for systemd now. Debian still gives you some choice in the matter in a way that's reasonably flexible, so I'm taking a "wait and see" approach for now.

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

    Total Score:   5  
  • (Score: 2) by HiThere on Wednesday November 19 2014, @10:11PM

    by HiThere (866) Subscriber Badge on Wednesday November 19 2014, @10:11PM (#117873) Journal

    What I decided to do was revert from testing to stable...i.e. Wheezy. What I'll do when support for Wheezy ends I haven't yet decided...and don't plan to decide for awhile.

    Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    • (Score: 2) by Marand on Wednesday November 19 2014, @11:23PM

      by Marand (1081) on Wednesday November 19 2014, @11:23PM (#117898) Journal

      That could be a good choice for some, though it wouldn't be great for me because I follow testing and use it like a rolling-release distro so that it's easier to cherry pick software from experimental, unstable, and Ubuntu PPAs. Stable gets too far behind Ubuntu so it's harder to keep the PPAs working.

      Except for a bit of a shock when Debian first tried to dump systemd on me, and a brief burp when there was a bad dependency (it got fixed; that's what testing is like sometimes), it hasn't really been a problem. There are only a couple things that attempt to install systemd*, and they're desktop-specific bits, so for servers it's a non-issue right now. For desktops the parts that you lose don't prevent you from running a desktop, just some convenience bits. (Unless you use GNOME, at least, but if you use GNOME you've probably already accepted the systemd overlords)

      I kept systemd completely off my system for a while, but then decided to give the non-init parts a fair shot. Installed the shim, blocked systemd-sysv, and let the the desktop-friendly bits do their thing. Figured it'd be easy enough to remove if it becomes problematic, and since my gripes with systemd (from a technical perspecive) are mostly with the init and logging, I had no issue with giving the other parts a chance.

      So far, barring some really minor annoyances, the logind+shim haven't been a problem. It makes crap like upower and udisks happy, neuters most of systemd, and basically turns systemd into another dbus-esque abstraction that I ignore unless something goes wrong. Meanwhile, my old-fashioned init and syslog processes just keep doing what they've been doing for years.

      As long as the systemd-shim package is maintained we're probably okay, and it seems there are still people in Debian that care enough about it, so there's some hope.

      * By "systemd" I mean the actual systemd processes, not the libs that other apps have as dependencies so they can use systemd if it exists. That crap is harmless, and even my wheezy-using laptop has had them installed forever. Without systemd installed they're just a few megabytes of wasted disk space that do nothing.

      • (Score: 2) by HiThere on Thursday November 20 2014, @08:01PM

        by HiThere (866) Subscriber Badge on Thursday November 20 2014, @08:01PM (#118225) Journal

        OK. But I have one system, so it's both a desktop and a server. Until I'm assured that systemd won't cause problems, I'm just going to avoid it, and everything linked to it. Since my system *is* a desktop as well as a server, well...

        The question, really, is "Is systemd actually a desirable way to go?". I haven't encountered anything that makes me say yes, so I don't want to commit to it. Particularly as it seems to be an increasingly intrusive and entangling system. I don't mind building things from source, though. (Well, most things.) If I must, I can cut my main system off from the internet and communicate intermittently through a laptop, but that would be much less desirable than finding some better way. But stable is good enough, so there's no hurry. And maybe I'll even be convinced that its a good idea.

        Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
        • (Score: 2) by Marand on Thursday November 20 2014, @09:59PM

          by Marand (1081) on Thursday November 20 2014, @09:59PM (#118264) Journal

          Yeah, I totally get that. I use a VPS for stuff I need up reliably, and for home stuff it doesn't matter much if I mix desktop+server bits because if the desktop is down I've got bigger concerns than worrying about mpd or my LAN-only httpd not running. I can afford to experiment a bit. Though I still refuse to let systemd become init, and I'm going to continue to refuse to do that for as long as possible.

          I don't necessarily think systemd's a great way to go, but neither was HAL, which is why it ended up superseded eventually. Meanwhile I'm just going to hold out as long as possible using sysv init, and if I start having issues with the non-init side of systemd (right now the only part that seems to run is logind, so the annoyance is minimal) I'll just throw it out and deal with clunkier USB storage mounting.

          Either way -- sticking with stable or using shim -- the idea's same. The situation isn't exactly dire yet, so it's a bit premature to be freaking out and switching to BSD. By the time it gets to that point, the entire landscape could change again. That's what happened not long after I finally got forced into using HAL. "Damn I'm stuck with it now. Oh look it's deprecated, yay" :)

  • (Score: 2) by melikamp on Thursday November 20 2014, @03:30AM

    by melikamp (1886) on Thursday November 20 2014, @03:30AM (#117979) Journal
    You actually sound like a sane normal person caught amid a giant foodfight full of rotten tomatos. Looks like everyone decided to overreact at the same time. It's not like wheezy will ever switch, and wheezy is good to go for a couple of years at least, and more on servers, which is the use case everyone is crying about. Why all the panic and the message of doom? Anti-systemd crowd likes to point at the refuge of Slackware, but Slackware is the distro where the user is expected to pick up the slack. Don't like the systemd? Well roll your own distro, right? Fork something. While some posters whail and tear their clothes, others are forking udev. No serious userland application (and that includes all servers) will ever tie itself to init, because their respective developers are not insane. So SUPPOSE we loose Gnome, that's one environment among half a dozen by now, and not a very good one. The doom will simply fail to materialize. systemd will proceed to become more sane, reliable, and unixlike if that's what works. Alternative inits will continue to exist. I will continue to use (deblobbed) Slackware and chew gum, and at this point I really don't care which init I end up with, as long as it works. The more I read about the technical differences between systemd and more traditional shell-driven inits, the more I am convinced none of this is really a big deal. It only becomes that when people take their emotional response to the forums.
    • (Score: 2) by Marand on Thursday November 20 2014, @06:09AM

      by Marand (1081) on Thursday November 20 2014, @06:09AM (#118011) Journal

      I might sound sane and normal about it right now, but if systemd-shim vanishes for some reason, I can guarantee that I'll be frothing at the mouth along with rest over it. Nearly all of my systemd complaints are about the init, logging, and the shitty, politically-charged adoption. Using the shim lets me avoid two of the three, and the third doesn't affect me in day-to-day use. I've already said a fair bit about Poettering, Sievers, and the pushy, rushed adoption of systemd already in other threads, so there isn't much point revisiting the complaints, but it's still a sore point with me. Still, that's not reason enough by itself to flee to BSD when Ubuntu and Debian have worked around some of the brain damage with the shim package.

      One potential fear with systemd, and one I do agree with, is that Poettering, Sievers, and co. are using their influence in so many pieces of Linux software to unfairly tie everything together in a way that will make systemd unavoidable. It's a sleazy tactic and it's pretty obvious it's really happening. Pulseaudio depends on systemd now. udev is folded into systemd. NetworkManager requires systemd now. udisks and upower (which I believe Poettering has been involved in) need systemd. Probably some more but I can't think of what else.

      Another is that distros will stop providing non-systemd start/stop scripts after systemd becomes the default, effectively making non-systemd impossible. I think this is a legitimate concern, but not necessarily a serious one, because someone that's serious about using an alternate init will be willing (and hardcore enough) to make their own init scripts or whatever. Someone might even rig up a systemd-to-sysv script generator of some kind to serve as a starting point.

      All said, I do think the systemd problem is a fairly big deal, but I don't think it's going to destroy Debian or Linux. Like you said, there are enough sane users and devs around that eventually, even if systemd ends up ubiquitous, it'll get tempered into something less insane. The real problem is the sleazy and suspicious way the whole thing has happened, and I have a feeling that's where a lot of the vitriol and emotion comes from. There's a huge backlash here because people feel cornered, forced into something abruptly. Hell, Debian's normal decision-making could reasonably be compared to an Entmoot, but not with systemd. Just for a comparison, I think systemd may have made its way from newcomer to default faster than Debian switched from KDE 3.5 to KDE 4.x

  • (Score: 2) by cafebabe on Thursday November 20 2014, @03:36AM

    by cafebabe (894) on Thursday November 20 2014, @03:36AM (#117980) Journal

    This approach is not sufficient because behavior remains dangerous. For example, it does not prevent an ancillary service from being too trusting [].

    • (Score: 2) by Marand on Thursday November 20 2014, @05:21AM

      by Marand (1081) on Thursday November 20 2014, @05:21AM (#118000) Journal

      This approach is not sufficient because behavior remains dangerous. For example, it does not prevent an ancillary service from being too trusting.

      I'm not entirely sure about that. Systemd is split up into a bunch of different pieces, and right now because of the shim, the only piece that seems to be necessary for desktop components is systemd-logind. As best I can tell, my system isn't making much (if any) use of the other systemd "modules" or whatever you want to call them. systemd-login and systemd-shim are the only persistent processes, and everything else is either completely unused or only being exec'd briefly just like any other program, so they're subject to the same security concerns as any other process doing the same jobs.

      There are still good arguments that can be made about various pieces of systemd not being mature enough yet, but it's far less of an issue when they're just another set of processes that get run, rather than the init and logging being new and untested. As long as systemd-shim remains supported and doing what it's doing, systemd's a lot more tolerable, at least to me, because you get some of those purported systemd benefits (for desktops mostly), without being forced to deal with the contentious parts like binary logs and your desktop forcing you into a specific init.

      ...Doesn't mean I like it, though. It's just not particularly more offensive than hal or dbus in this neutered form, so I'm taking it cautiously for now and waiting to see where Debian (and Linux in general) goes with it.

      • (Score: 2) by cafebabe on Thursday November 20 2014, @06:02AM

        by cafebabe (894) on Thursday November 20 2014, @06:02AM (#118009) Journal

        I do not want systemd, systemd-shim or a modular re-implementation of systemd. And that was before inexcusable issues such as the DNS cache ignoring recommendations in RFC5452.

        I think you are vastly underestimating the scale of problems in systemd and I ask you to consider how many times you are prepared to be burned.

        • (Score: 2) by Marand on Thursday November 20 2014, @06:25AM

          by Marand (1081) on Thursday November 20 2014, @06:25AM (#118018) Journal

          Meh. I don't want systemd, but I also didn't want HAL or dbus, either. Especially HAL, which was extremely fragile and fraught with problems for a very long time. I got stuck with them too, and learned to deal with it. I especially hated udev, because the initial adoption was a mess and broke a lot of things I had carefully set up, but nowadays it's actually a pretty useful thing. As long as it's not the init and not forcing its own DNS and other bullshit, I can deal with it being another lame dbus/HAL piece of shit that will eventually become more mature. (Maybe one day it'll even become a useful piece of shit like udev eventually did, but I wouldn't take those odds.)

          Right now thanks to the shim package, it's doing almost nothing on my system, and I can tolerate that. If it annoys me enough despite that, I can safely remove it and only lose some convenience stuff. I can tolerate that option, too. No reason to jump ship to BSD just yet, and definitely no reason to switch away from Debian when the alternatives don't even have the shim, making them less flexible than Debian regarding systemd.

          If/when something happens to change the landscape further, I'll worry about switching to something else. Right now it would be premature.