Announcement

Collapse
No announcement yet.

Systemd 240 Released To End 2018 On A High Note

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

  • Systemd 240 Released To End 2018 On A High Note

    Phoronix: Systemd 240 Released To End 2018 On A High Note

    Zbigniew Jędrzejewski-Szmek, part of the systemd team at Red Hat, has taken the reins from Lennart Poettering to release systemd 240 ahead of Christmas...

    http://www.phoronix.com/scan.php?pag...d-240-Released

  • #2
    I wonder if systemd development should try to synchronise with the distros' release cycles, maybe Ubuntu's since it's the major distro that releases the most often?

    Comment


    • #3
      That’s an impressive amount of features and developers.

      Comment


      • #4
        Originally posted by jacob View Post
        I wonder if systemd development should try to synchronise with the distros' release cycles, maybe Ubuntu's since it's the major distro that releases the most often?
        Does it release more than two times a year these days or what?

        Comment


        • #5
          Originally posted by jacob View Post
          I wonder if systemd development should try to synchronise with the distros' release cycles, maybe Ubuntu's since it's the major distro that releases the most often?
          nah, releasing often enables finding bugs faster. release often is better imho

          Comment


          • #6
            Originally posted by boxie View Post

            nah, releasing often enables finding bugs faster. release often is better imho
            I think releasing often is better in the early stages of a project. Now that systemd is mature and a core component of all the main distros, the problem with releasing often is that distro releases get versions of systemd that have many new and comparatively untested features. Targetting six monthly cycles would allow them to deliver a more polished code base for the main distro releases and still keep a relatively rapid development pace.

            Comment


            • #7
              I'm just switching from systemd to a different init system. I already experienced an unbootable system (doing nothing) because of it. That's all.
              I remember Sysvinit, I remeber how easy it was to manage, I remeber everythin, so I'm just switching over.

              Comment


              • #8
                Originally posted by frank007 View Post
                I'm just switching from systemd to a different init system. I already experienced an unbootable system (doing nothing) because of it. That's all.
                I remember Sysvinit, I remeber how easy it was to manage, I remeber everythin, so I'm just switching over.
                The problem with sysvinit is that it is not a service manager, and as such it will only get everything up but not supervise it's running correctly (and restart failing services).

                Of course a service manager can be built on top of sysvinit, like OpenRC.

                Comment


                • #9
                  Originally posted by tildearrow View Post

                  The problem with sysvinit is that it is not a service manager, and as such it will only get everything up but not supervise it's running correctly (and restart failing services).

                  Of course a service manager can be built on top of sysvinit, like OpenRC.
                  A proper service manager should have a number of features:

                  - have an API so that services, events etc. could be managed programmatically, rather than by a sysadmin writing scripts and editing config files;
                  - have a real process and resource tracking capability (cgroups etc.);
                  - support containerisation;
                  - allow services to depend on time events, network events, system events, user events etc.
                  - allow unprivileged users to install and run their own unprivileged services
                  - understand the notion of a user session and associate events and services with it
                  - ideally remain strictly declarative and avoid shell scripting totally, for security reasons (among others)
                  - be predictably present on user systems so that application developers can assume it and rely on it (e.g. deliberately NO "choice"), just like they can assume the semantics of system calls.

                  Sysvinit and OpenRC meet none of these criteria while systemd meets them all. That's not saying that systemd is perfect or ideal or optimal or whatever, but it's really the only one.

                  Comment


                  • #10
                    Zbigniew is at Red Hat? That's surprising news, since when?

                    Comment

                    Working...
                    X