Page 1 of 2 12 LastLast
Results 1 to 10 of 11

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,093

    Default 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...

    http://www.phoronix.com/vr.php?view=MTQ2MTE

  2. #2
    Join Date
    Dec 2012
    Posts
    459

    Default

    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.

  3. #3
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote 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...

    Quote 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.

  4. #4
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote 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.

    Quote 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).

    Quote 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?

    Quote 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?

    Quote 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.

  5. #5
    Join Date
    May 2010
    Posts
    684

    Default

    Quote 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; 09-14-2013 at 12:54 PM.

  6. #6
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote 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).

    Quote 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).

  7. #7
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote 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.

  8. #8
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote 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.

  9. #9
    Join Date
    Apr 2010
    Posts
    770

    Default

    Quote 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.

  10. #10
    Join Date
    Jul 2012
    Posts
    287

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •