3 ms·

Systemd is not a big blob, it is actually fairly well structured in its source repository. Each part has its own disable flags on compilation and makes independ

by zanny 12y ago

Systemd is not a big blob, it is actually fairly well structured in its source repository. Each part has its own disable flags on compilation and makes independent binaries. You should think of systemd less as a "program" and more as a software compilation for the core system. Yes, there is a chance that components of systemd could suffer bitrot, but I'd argue its less likely that a project under the tutelage of Red Hat in the interests of its enterprise crowd will see the rot that other projects like xinetd have in recent years, where major contributors just stop, the whole project grinds to a halt, but because its not part of some broader software project nobody notices to pick up the slack (note, my example has gone through periods of rot and revival when someone notices its become a problem). If one component starts rotting the bugs will pile up on the systemd bug trackers and the broader project will notice and respond more efficiently since everything in systemd uses the same semantics and code formatting and the developers will be more comfortable changing their working directory than their repository.

vezzy-fnord 12y ago
Each part has its own disable flags on compilation and makes independent binaries. Except for generators, certain auxiliaries like rfkill, journald, udevd and others. It's rather inconsistent, as is the specific libraries that can be disabled.
- digi_owl 12y ago
  Never mind that all the "independent" binaries depends on a certain init binary sitting as pid1...
falcolas 12y ago
> Each part has its own disable flags on compilation and makes independent binaries. I'm not speaking of the entire systemd daemon ecosystem (which already displays coupling between logind and journald), just the systemd-as-init daemon. > I'd argue its less likely that a project under the tutelage of Red Hat I'd argue in return that if the Lennart Poettering bus factor suddenly went critical, systemd development would indeed hit a significant roadblock. Perhaps not insurmountable, but how many people understand the entirety of the systemd ecosystem? How many resources would RedHat be capable of devoting to this one project? > the bugs will pile up on the systemd bug trackers The RHEL bug tracker is currently at 250 open bugs, with 40-50 of them in the "NEW" category, with some of those dating back to 2013. The oldest open bugs date back to 2011. In my opinion, this shows a lack of bug triage, one of first outward signs of "bug pileup".

by zanny 12y ago

vezzy-fnord 12y ago

Each part has its own disable flags on compilation and makes independent binaries. Except for generators, certain auxiliaries like rfkill, journald, udevd and others. It's rather inconsistent, as is the specific libraries that can be disabled.

digi_owl 12y ago
Never mind that all the "independent" binaries depends on a certain init binary sitting as pid1...

falcolas 12y ago

> Each part has its own disable flags on compilation and makes independent binaries. I'm not speaking of the entire systemd daemon ecosystem (which already displays coupling between logind and journald), just the systemd-as-init daemon. > I'd argue its less likely that a project under the tutelage of Red Hat I'd argue in return that if the Lennart Poettering bus factor suddenly went critical, systemd development would indeed hit a significant roadblock. Perhaps not insurmountable, but how many people understand the entirety of the systemd ecosystem? How many resources would RedHat be capable of devoting to this one project? > the bugs will pile up on the systemd bug trackers The RHEL bug tracker is currently at 250 open bugs, with 40-50 of them in the "NEW" category, with some of those dating back to 2013. The oldest open bugs date back to 2011. In my opinion, this shows a lack of bug triage, one of first outward signs of "bug pileup".