Announcement

Collapse
No announcement yet.

The Switch To Systemd Will Likely Occur For Ubuntu 15.04

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Switch To Systemd Will Likely Occur For Ubuntu 15.04

    Phoronix: The Switch To Systemd Will Likely Occur For Ubuntu 15.04

    While Ubuntu was one of the last big hold-outs to systemd instead preferring Upstart, it looks like soon in the Ubuntu 15.04 cycle that systemd could become the default init manager...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I wonder when/if SteamOS will make the switch, or at least announce whether or not they will switch.

    Comment


    • #3
      Originally posted by xeekei View Post
      I wonder when/if SteamOS will make the switch, or at least announce whether or not they will switch.
      John Vert of Valve said at Debconf that at the moment they don't see a potential value for their use case.

      However Valve also wants to ship containerized applications for SteamOS, so it might be interesting for them afterall.

      SteamOS is one of the latest Debian derivatives and is set to be hugely popular. This talk will explore some of the decisions and implementation details behi...


      Some cringeworthy questions at the end of the talk.

      Comment


      • #4
        Originally posted by blackout23 View Post
        John Vert of Valve said at Debconf that at the moment they don't see a potential value for their use case.

        However Valve also wants to ship containerized applications for SteamOS, so it might be interesting for them afterall.

        SteamOS is one of the latest Debian derivatives and is set to be hugely popular. This talk will explore some of the decisions and implementation details behi...


        Some cringeworthy questions at the end of the talk.
        Thanks a lot! This looks very interesting, might even get some popcorn.

        I'm glad Ubuntu is gonna switch, and I hope SteamOS will eventually.

        Comment


        • #5
          Is SteamOS based on Debian?

          Is SteamOS based on Debian? I recall reading that somewhere.

          So I suspect they will change at some point, probably after Debian 8.0 is final?

          Comment


          • #6
            Originally posted by blackout23 View Post
            Some cringeworthy questions at the end of the talk.
            Linux people are weird.

            Comment


            • #7
              Originally posted by johnc View Post
              Linux people are weird.
              You have been extra bitter lately. Cheer up!

              Comment


              • #8
                It is sad

                Upstart was technically great.

                Unfortunately, it was covered by a CLA (contributor license agreement) which made it not so free in spirit, and kept the community and independent developers away.

                So Upstart while technically good, ended up a failure, and never reached its true potential due to being hampered by Canonical.

                Had Upstart been more free, then everyone would probably have used that instead of systemd, and the efforts and resources that Canonical spent on Upstart wouldn't have been wasted.

                Comment


                • #9
                  I've had working cryptsetup/systemd integration via custom software since May

                  I use a custom script to unlock multiple disks from one passphrase held in RAM, then cleared. In May I rewrote it to work with systemd in Dracut, if the old initramfs-tools system is used, the previous cryptsetup integration for initramfs unlocking by another version of my script also works. The "cryptall" script is just a replacement for cryptsetup's "cryptroot" script, so it should be possible for Ubuntu to use a systemd unit for a modified version of the current "cryptroot" script if they ever migrate to dracut the same as I do. Ubuntu still has an old version of Dracut (027-1) in repo, I use a modded version of Debian's 037 version as it uses systemd in the initramfs. If systemd replaces the init script in initramfs-tools as opposed to using dracut Ubuntu will obvously have to do something different. If they do not use systemd in the initramfs, Ubuntu will simply need to disable systemd's cryptsetup module entirely by masking the service, but cryptsetup will then work only in the initramfs at boot time, or post-boot when invoked on a removable volume.

                  The post-initramfs cryptsetup integration in the version of systemd Ubuntu uses, and also what goes into the initramfs in Dracut if you use normal cryptsetup integration is very buggy. Some kind of race condition causes it to check for the presence of the unlocked device before that device actually appears. That causes the passphrase dialog to reappear after the devices in question have already unlocked. I suspect that's because systemd is designed to run processes in parallel.

                  I ran into the exact same problem when I rewrote my "cryptall" script to run cryptsetup in the background so multiple volumes could unlock simultaniously. It would race to the checking process before cryptsetup finished, and the "wait" command only waited for the first instance to return. The workaround in my own program was to unlock non-root volumes in the background, but unlock the root volume last and in the foreground to force the script to wait for cryptsetup before checking to see if the root volume had sucessfully unlocked. That approach won't work for systemd's far wider range of possible encrypted volumes. When using my program I put rd.luks=0 luks=0 on the kernel command line to keep systemd from looking for the volumes and calling the passphrase after they are already unlocked.

                  Systemd's native passphrase dialog agent is supposed to have the ability to cache a passphrase in RAM for reuse on multiple devices, if they get that working it would do the same job as my program with about the same performance. As of now it does not work-at least not with the old version of systemd in Ubuntu.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    Had Upstart been more free, then everyone would probably have used that instead of systemd, and the efforts and resources that Canonical spent on Upstart wouldn't have been wasted.
                    Systemd would not exist without the CLA on Upstart and the original creator along the starting developers would fix upstart cirtical design flaws.

                    Originally posted by Kay Sievers on Jan 18, 2014
                    True statement. And yeah, without the CLA, we would very likely have worked on upstart, instead of starting the systemd project. Four years ago we talked to lawyers and tried pretty hard to convince them to give it up, but there was no way to negotiate.

                    Today, I very much enjoy the fact that this is a good example what you do to your project or company if you try to skew the free software playing field too much with tricky contracts. You just get what you build, an/your island.

                    "Wildly Off-Topic: I should note that I think if upstart did not have the CLA that it does, the rest of the FOSS world might have just improved it, and systemd might never have shown up. I suspect that the fate of bzr might be similar.

                    These should serve as a cautionary tale for for-profit companies requiring CLAs. [Or everyone, even.]"

                    Comment

                    Working...
                    X