Announcement

Collapse
No announcement yet.

Systemd 207 Gets Many Bug-Fixes, Minor Additions

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

  • Systemd 207 Gets Many Bug-Fixes, Minor Additions

    Phoronix: Systemd 207 Gets Many Bug-Fixes, Minor Additions

    Lennart Poettering has announced the release of systemd 207 and with it comes many changes...

    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
    Eventually, I guess that even Gentoo will have to migrate over to SystemD to support Gnome. However, I do find it rather interesting to see SystemD growing to do a lot of things HALd and Udev did. And exactly HAL was killed since it started to do literally everything, and now SystemD is going the same way. But now, it's okay?

    Why does it all have to be done in one program? Isn't it better to have it all seperately? I use rsyslog, openrc, udev and consolekit + bunch init scripts. Each component works happily independently. I sometimes wonder what the added benefit is of SystemD over each and every customized set of related programs that achieve the same.

    Comment


    • #3
      Originally posted by Rexilion View Post
      Eventually, I guess that even Gentoo will have to migrate over to SystemD to support Gnome.
      How does that work? Currently Gnome on Gentoo depends on systemd but there's absolutely no need for it be default because not everyone uses Gnome...

      Originally posted by Rexilion View Post
      But now, it's okay? -- Why does it all have to be done in one program? Isn't it better to have it all seperately?
      Probably because it's modular? It's build of around eighty binaries. You can disable virtually everything but systemd PID1, systemd-journald and systemd-udev. The generators (for example the now added GPT one) are separate modules. The session management stuff are handled by the optional systemd-logind process. Virtual machines and containers are tracked by the optional systemd-machined process and so on and so forth.

      Comment


      • #4
        Originally posted by Teho View Post
        How does that work? Currently Gnome on Gentoo depends on systemd but there's absolutely no need for it be default because not everyone uses Gnome...
        I find this hilarious. An init system that does not init your system is required to run Gnome . Made my day. But, this indeed in favor of SystemD. It's so modular, that it does not even have to be pid 1.

        Originally posted by Teho View Post
        Probably because it's modular? It's build of around eighty binaries. You can disable virtually everything but systemd PID1, systemd-journald and systemd-udev. The generators (for example the now added GPT one) are separate modules. The session management stuff are handled by the optional systemd-logind process. Virtual machines and containers are tracked by the optional systemd-machined process and so on and so forth.
        That's impressive. And could someone, like me who did not study CS, do that? (without getting bitten by some sort of semi-transparent dependency hell).

        Originally posted by Teho
        Systemd is not one program, much code can be used seperatly, and it populated many PIDs. Systemd is just one git tree, and that is the beauty of it. NO time is wasted on testing the combination of different versions of seperate programs like the old days. Today distributions can't screw it up. Just package systemd at a version to you liking and pull the commits marked suitable for backporting. Sure there is an initial cost to do away with distroism but that is worth it, and systemd upstream will take it, if it worth keeping.
        Yes, I agree with that. Each distribution like Debian, Gentoo and Fedora each have their own implementation of network configuration in case you are not using nm. But, isn't the distribution specific features that make a distribution a distribution. I.e. something worth choosing or preferring?

        Originally posted by Teho
        Anyone who don't like this should remember to justify the extra cost of maintaining the old distroism and point to resources who will do the extra work.
        I never said I did not like it. I just made an observation: HAL + friends is considered bad. SystemD is considered good. Why? As for the extra work, each distribution files a gap providing specific features. That is not a wasted 'cost of maintaining the old distroism'. Are you suggesting you should all migrate to one generic distribution?

        Originally posted by Teho
        (This was written from asystemd v207 computer, and works without flaws, such an easy transistion would never have happened in the old days.)
        I'm sure it works without flaws. Don't know why the easy transition argument would imply that it's a good piece of software though.

        Comment


        • #5
          Originally posted by Rexilion View Post


          I never said I did not like it. I just made an observation: HAL + friends is considered bad. SystemD is considered good. Why?
          You ignored almost everything he said... HAL was considered bad because it was extremely monolithic and became difficult to maintain. Systemd, as mentioned above, is built in a very modular way and is very well maintained.

          HAL was a single daemon, systemd is 80 well defined binaries that each serve specific purposes. Systemd is typically packaged in a 'monolithic' way by distros (typically just one or two systemd packages that include all the binaries), but the project itself is quite modular and doesn't have the same flaws HAL had.
          Last edited by bwat47; 14 September 2013, 12:54 PM.

          Comment


          • #6
            Originally posted by Rexilion View Post
            I find this hilarious. An init system that does not init your system is required to run Gnome . Made my day. But, this indeed in favor of SystemD. It's so modular, that it does not even have to be pid 1.
            I'm not sure what you are refering to here. Altough systemd doesn't have to be PID1 (it can also manage user session among other things) you can't run it on top of OpenRC. The point was that Gnome depends on systemd-logind (to some extent) that depends on systemd (as of 205+). In case you want to run Gnome, you just use systemd as your PID one (you only need to add one line to GRUB).

            Originally posted by Rexilion View Post
            That's impressive. And could someone, like me who did not study CS, do that? (without getting bitten by some sort of semi-transparent dependency hell).
            Probably yes. Those are just compile time and/or runtime options. Distributions could work on packaking them separately but I don't think anyone has stepped up to do the work.

            Rest of your quotes are falsely pointed at me (they were written by Honton).

            Comment


            • #7
              Originally posted by Teho View Post
              I'm not sure what you are refering to here. Altough systemd doesn't have to be PID1 (it can also manage user session among other things) you can't run it on top of OpenRC. The point was that Gnome depends on systemd-logind (to some extent) that depends on systemd (as of 205+). In case you want to run Gnome, you just use systemd as your PID one (you only need to add one line to GRUB).
              Why the hell is everyone saying this?
              They want to deny that Gnome now has a hard dependency on systemd, but then they double back and say it isn't a hard dependency, it's just logind and that inconveniently depends on systemd.
              Then it always ends with the implication that you should have been running systemd in the first place and not even worry about the systems that don't.

              Comment


              • #8
                Originally posted by intellivision View Post
                Why the hell is everyone saying this?
                They want to deny that Gnome now has a hard dependency on systemd, but then they double back and say it isn't a hard dependency, it's just logind and that inconveniently depends on systemd.
                Then it always ends with the implication that you should have been running systemd in the first place and not even worry about the systems that don't.
                I'm in absolutely no way associated with Gnome nor Gentoo nor systemd so I might be wrong. I have followed the Gentoo/Sabayon Gnome discussion to some extent though and I don't believe it's easily feasible to run Gnome without systemd as PID1. The thing was that pre-205 systemd-logind happened to relatively easily separateable from systemd (for example Ubuntu 13.10 uses it by default) however that changed with the recent cgroup revamp in systemd where are cgroup functionality was moved to PID1 due to the upcoming kernel changes that require a single writer for the cgroup hierarchy. It's probably possible to disable the functionality in Gnome that require logind APIs though.

                Comment


                • #9
                  Originally posted by Rexilion View Post
                  But, isn't the distribution specific features that make a distribution a distribution. I.e. something worth choosing or preferring?
                  Only if the differences are actually useful. If not, it's just extra burden without benefit - extra work for distros to maintain things themselves, and extra difficulty for users switching between different systems.

                  Comment


                  • #10
                    Originally posted by Teho View Post
                    I'm in absolutely no way associated with Gnome nor Gentoo nor systemd so I might be wrong. I have followed the Gentoo/Sabayon Gnome discussion to some extent though and I don't believe it's easily feasible to run Gnome without systemd as PID1. The thing was that pre-205 systemd-logind happened to relatively easily separateable from systemd (for example Ubuntu 13.10 uses it by default) however that changed with the recent cgroup revamp in systemd where are cgroup functionality was moved to PID1 due to the upcoming kernel changes that require a single writer for the cgroup hierarchy. It's probably possible to disable the functionality in Gnome that require logind APIs though.
                    That is correct.

                    GNOME does not have a hard dependency on systemd. It only requires logind for the Wayland support in Mutter in 3.9/3.10; Wayland support is still under development and if you run X11 the dependency is still optional. Some things assume some functionality in an init system that not every init system could do (e.g. clean all the children of a daemon; GDM 3.8+). Wayland support in Mutter relies on logind to handle VT switching and some other tasks IIRC (so the Wayland bit in Mutter, not Wayland itself). This means that in future if we'd _only_ have Wayland support it would result in a hard logind depedency (thus systemd).

                    Now for logind, systemd changed after Canonical packaged it so that logind requires systemd due to cgroups. But that was not a known change, we assumed we it was more portable and would stay that way.

                    Note that I had pretty extensive discussion on #gentoo-desktop regarding the issues that they face. GNOME within Gentoo still might depend on systemd to make it easier to avoid any issues, but that would (at the moment) be more to reduce the amount of work to package it. Providing choice simply requires effort.

                    For people suggesting that ConsoleKit should be used: If I check the git logs, the logs indicate that it was started by William Jon McCann, a person involved within GNOME. Aside from that you see various other GNOME developers. If the people (not me) who wrote and for a long time maintained ConsoleKit give their opinion, I assume it is worth listening to. They ensure non-logind is possible. In GNOME 3.8 as well as upcoming GNOME 3.10 (except Wayland support).

                    It would be nice if logind did not depend on systemd.

                    PS: Functionality of OpenRC was extended for GNOME 3.8 in Gentoo. IIRC by GNOME packagers in Gentoo.

                    Comment

                    Working...
                    X