Please create an account to participate in the Slashdot moderation system


Forgot your password?
Open Source Debian Operating Systems Linux

Systemd-Free Devuan Announces Its First Stable Release Candidate 'Jessie' 1.0.0 ( 372

Long-time reader jaromil writes: Devuan 1.0.0-RC is announced, following its beta 2 release last year. The Debian fork that spawned over systemd controversy is reaching stability and plans long-term support. Devuan deploys an innovative continuous integration setup: with fallback on Debian packages, it overlays its own modifications and then uses the merged source repository to ship images for 11 ARM targets, a desktop and minimal live, vagrant and qemu virtual machines and the classic installer isos. The release announcement contains several links to projects that have already adopted this distribution as a base OS.
"Dear Init Freedom Lovers," begins the announcement, "Once again the Veteran Unix Admins salute you!" It points out that Devuan "can be adopted as a flawless upgrade path from both Debian Wheezy and Jessie. This is a main goal for the Devuan Jessie stable release and has proven to be a very stable operation every time it has been performed. "
This discussion has been archived. No new comments can be posted.

Systemd-Free Devuan Announces Its First Stable Release Candidate 'Jessie' 1.0.0

Comments Filter:
  • Systemd! (Score:5, Insightful)

    by phantomfive ( 622387 ) on Saturday April 22, 2017 @02:55PM (#54283551) Journal
    Most Linux users don't have a strong opinion on systemd either way, because the system boots up reliably without systemd, and it also boots up reliably with systemd. Overall it's barely noticeable and doesn't matter (right now, anyway) for most users.

    There are people who write startup scripts for Linux, and they tend to have a stronger opinion, because it affects them more directly. Some really like systemd, some really don't. Some (like Patrick Volkerding) are fairly neutral about the whole thing but see no pressing need to switch.

    Then there are people who are system designers, who are ok with systemd as an init system, but see it as horrid when it's a platform for building an entire OS. As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.
    • Re:Systemd! (Score:5, Interesting)

      by OrangeTide ( 124937 ) on Saturday April 22, 2017 @03:09PM (#54283619) Homepage Journal

      I only care when I have to debug my more custom setups. Then I really hate systemd, as well as dbus. I would be surprised if anyone "really liked" it, except the original author. Most people are like "whatever, I just want X and pulseaudio to start". I, as a system developer, have built products around systemd because the product architect insisted on it. I was like "whatever, your funeral".

      All my authoritative DNS servers are running custom builds (not BIND) and require custom start-up scripts for the chroot and health monitoring.

      • Re: (Score:3, Insightful)

        by Cyberax ( 705495 )
        I'm also a systems architect and I have built rather complicated event-driven systems around systemd. Systemd worked just fine for me, without any unexpected problems.
        • Sounds great. I did manage to trim 200K of ram usage in an embedded system (no swap!) by tearing systemd out.

          Systemd is way more modular though, and it has a lot of benefits for a desktop environment and for distro maintainers. But if you system doesn't want dbus, pulseaudio and those sort of things, it probably also doesn't want systemd. And if you are using pulseaudio and dbus, then the framework that Systemd presents might be something you want. I don't have any use for Systemd or dbus or other desktop o

          • by Cyberax ( 705495 )
            Sure. If you're doing slimmed-down devices where evety KB of RAM counts then systemd is not really needed, busybox and static init scripts are the way to go.

            Surprisingly, servers are a good fit for systemd - a lot of modern devices and services come and go asynchronously, so writing reliable initscripts without something like systemd is not easy.
    • All I know is on a completely idle box systemd is the top resource hog. Why is this "startup shceduler" even consuming resources?

    • Re:Systemd! (Score:5, Interesting)

      by gringer ( 252588 ) on Saturday April 22, 2017 @04:05PM (#54283873)

      Most Linux users don't have a strong opinion on systemd either way,

      Maybe not on slashdot, but you will probably find that people over at soylentnews [] have a different opinion. The systemd issue was a contributing factor to the creation of soylentnews.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Wow, just checked an idle CentoOS 7 server we have that we aren't using yet:

        root 1 0.0 0.0 46168 4940 ? Ss Mar14 254:19 /usr/lib/systemd/systemd --switched-root --system --deserialize 20

        How has it used over four hours of CPU time in less than eight days? It's has a Xeon E5-2689 CPU, so it's one of the fastest Intel CPUs available.

        Extra text to get rid of the ridiculous "Filter error: Please use less whitespace." I still need to add more text. This filter is a pain. I know what I'm talking about. Please

    • by Kjella ( 173770 )

      As long as it stays as an init program, it's fine because it can be swapped out easily. But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.

      Well it has to talk to something. I mean we had applications that used to talk directly to the hardware back in the DOS days, this application can talk to Soundblaster and Gravis Ultrasound, I don't want to go back there. So you want to fix it a bit on the hardware side so all the apps can talk to one interface and it'll play on all sound cards. And you want to fix it on the software side so more than one application can play sound at the same time.

      And then the ball starts rolling, does it have a hardware m

    • Re:Systemd! (Score:5, Insightful)

      by gweihir ( 88907 ) on Saturday April 22, 2017 @08:52PM (#54284855)

      The problem here is that the systemd-people are trying an MS-like strategy to make it impossible to swap it out: They try to replace everything else they can get their hands on and they try to sabotage whatever else they can so it does not run without systemd anymore. If these were decent people and they were just providing an alternate init-system, I would have absolutely not problem with this and just ignore it. But this embrace-extend-extinguish approach is utterly evil and marks this as a hostile takeover that will benefit nobody. There are not even any good technical reasons for this. I can only guess that they want their stuff to be the one true "does everything" because of pure ego.

      • Re:Systemd! (Score:4, Interesting)

        by dbIII ( 701233 ) on Saturday April 22, 2017 @11:38PM (#54285341)
        Spot on. All that's needed to confirm it is to look at Lennert's blog where he states most of the things above as his goals. He is not shy in saying that he wants to recreate linux HIS way and the rest can just go jump. If he listened to others and was a bit more patient in testing before getting things out the door that may not even be a bad thing, and it's probably fine for desktops. It kind of sucks for servers though when software depends on things working in the same sort of way they did a couple of years ago and where getting hung up on boot is a hassle for a lot of people instead of a single desktop user.
    • Re:Systemd! (Score:5, Interesting)

      by geoskd ( 321194 ) on Saturday April 22, 2017 @11:27PM (#54285315)

      But if it starts becoming a required component for turning up the volume, that is clearly a sign of poor design.

      Systemd's integration into more than just init is a fundamental result of a singular problem that has been facing all operating systems for about 15 years now: Hot plugging. Hot plugged devices need to be handled in almost exactly the same way as non-hot swapped devices during boot, so it makes sense to use the same code path for both processes. This effectively means that your init system needs to also handle pretty much every type of device that can be hot plugged. This includes: any and all USB devices, large parts of the audio sub-system, network devices, damn near everything these days. By definition, the software that handles this needs to underly everything except the kernel. Since the kernel does not deal with this (by design), something else has to. Prior to SystemD, the various methods for handling it were a complex jumble of incompatible broken-ness.

      • by dbIII ( 701233 )
        Perhaps - but why put the thing on servers where hot plugging is not an issue but a beta init system managed by a guy that throws bug reports back in people's faces is?
        Like PulseAudio and NetworkManager there's places where it makes sense and others where it should just be torn out.
        • by mvdwege ( 243851 )

          servers where hot plugging is not an issue

          Here's a nickel kid. Go buy yourself a real server

          guy that throws bug reports back in people's faces

          He doesn't. Stop drinking the Kool-Aid and depending on secondary sources. Go read the actual bugreports and discussion.

          • by dbIII ( 701233 )
            Been there, done that - even better read Lennart's blog.
            He doesn't care if he breaks stuff in server space and RedHat are not reining him in as much as they should.
      • You have not addressed the point at all. Hot plugging doesn't mean you should create a bad design.
    • Re:Systemd! (Score:4, Informative)

      by vovin ( 12759 ) on Sunday April 23, 2017 @02:36AM (#54285767)

      Yes ... but systemd is a 'happy path' only.
      When something goes wrong then the thing just shits all over itself. Just like everything else pottering has ever touched,
      Just went through the shit this weekend .. CD drive died (no big, wasn't being used for anything) but systemd managed to fubar the whole f'ing system. Fallback to upstart worked fine.

      Other stuff that is a major PITA with systemd: OpenVPN. Whenever I change my .conf file I have to update systemd with some whacky config because it 'caches' my config file in it's own little world. WTF is that about? Dunno but it's enough of a pain that I'll be jumping to the debian boxen to devuan and tossing the ubuntu for the same reason.

      Let CentOS / RHEL 7 deal with all the SystemD crap .. when it's actually decent (after pottering gets bored and real developer fixes all his shit) then maybe it will be the init system that it is being touted as.

  • I think the should've called it 'Jevuie'.
  • I am missing Fedora without systemd.
  • Wasn't Open/Free/whatever software about choice ?

    I can understand that systemd brings some improvements.
    In specific contexts.
    For example, when your profession is sysadmin, when you have more than, let's say 4 or 5 servers to administrate, OK, may be systemd brings improvements over scripts. Real sysadmins are responsible of dozens, hundreds of servers.

    What about other people like me ? I'm in computer programming since 1982, very well, but I'm no sysadmin.
    A very kind friend told me once that, as a programmer

    • Re: (Score:3, Insightful)

      by gweihir ( 88907 )

      "If it is not broken, do not fix it." That and KISS is something the systemd-team is too stupid, too inexperienced and too arrogant to understand. Or they are just riding over it because they believe they are god's gift to Linux. They are not. They are a force of destruction, exactly because they fight choice, compatibility, simplicity and reliability. Sure, in some situations their approach may make sense, but that means systemd should be a specialized init-system (and nothing else) for specific situations

  • Jessie + Wheezy = Jizzy.

  • Are they working on removing systemd from Stretch? Also what's the performance difference between the two? Can someone benchmark both startup systems on modern nVMe ssds on same hardware? I'd be interested in some comparisons.

"Our vision is to speed up time, eventually eliminating it." -- Alex Schure