On Tue, Oct 21, 2014 at 11:35 AM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie: >> On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald >> >> <mar...@lichtvoll.de> wrote: >> > Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek: >> >> > Systemd-shim provides some functionality that systemd-sysv provides, >> >> > >> >> > and allows admins to use init systems other than systemd while still >> >> > installing things like brasero. I think this is a great thing, >> >> > except I wonder why the systemd project didn't separate this >> >> > functionality from the init system in the first place. Systemd-shim >> >> > is a duplication of effort. Not only that, but it must time its >> >> > releases with the releases of systemd-sysv. That's no big deal for >> >> > Debian's stable release, but it can be problematic in Debian's >> >> > unstable and testing branches. >> >> >> >> Because it's additional work and complications. Apparently providing >> >> systemd functionality without systemd running is not a trivial >> >> undertaking, as the lag between systemd and systemd-shim releases >> >> shows. I could spend my time for open source development on a >> >> (technically) pointless (from my vantage point) split, but I >> >> prefer to improve systemd instead. >> >> >> >> Debian as a project already paid significant to support systemd as an >> >> alternative, when systemd version was held back for a year waiting >> >> for systemd-shim to catch up. This is certainly not the last time. >> >> >> >> [snip] >> > >> > I think exactly this kind of attitude is what triggers most of the >> > polarity >> > around systemd. >> > >> > Its like "We don´t force systemd on anyone, but we provide as lots of >> > functionality tightly coupled with it and if you do not implement it >> > elsewhere, i.e. catch up, you need systemd anyway". >> > >> > While I believe it is *extra* work to separate functionality, I think it >> > is >> > *important* work. It would raise the acceptance of systemd, it would >> > reduce >> > the polarity it triggers. And it would make it more interoperable. >> > >> > Right now people are duplicating systemd stuff in several other areas. The >> > reluctance to adopt systemd with certain distributions creates friction. >> > Other implementations need to catch up and at any point in time may not >> > be compatible. >> > >> > So, aside from it being additional work, is there any *solid* or even >> > *unavoidable* technical reason to couple functionality that tightly? >> > >> > Wherever I look free software projects do great extra work to modularize >> > and separate out functionality that can be separate. For a reason. See >> > KDE community for example. They spend years of development work into >> > separating things out into separate packages and have a clear ruling on >> > what may depend on what. There are other examples for sure, OpenStack for >> > example, while I do not yet know it in detail consists of a ton of >> > separate packages in Debian. >> > >> > So or so… I think its this kind of attitude that triggers most of the >> > polarity and split. >> >> Most of the modules in systemd do not depend on eachother. However, >> logind does depend on the cgroups dbus API of systemd (PID1). In the >> past logind interacted with the cgroups fs directly, but this had to >> be changed as the kernel is moving to a model where only one process >> may be in charge of cgroups. On systemd systems that one process is >> PID1 (why that is so has been discussed elsewhere so won't repeat >> that), so anything needing to deal with cgroups needs to go through >> the systemd API. >> >> I hope that explains why logind has to depend on systemd (or at least >> something implementing the systemd API). > > Thanks, Tom. > > As explained in another post – I didn´t read all the new answers… but it makes > sense to do so – actually I feel uncomfortable about the new cgroup API. Its a > kernel API. The Linux Kernel is a kernel supporting preemptive multitasking. > Yet the new cgroup API requires or at least strongly recommends that only one > process uses it. And… additionally to that that is a change that has been > proposed by developers that to me oppinion are quite near or even working for > systemd upstream. > > To me a single-process-usable API in the kernel seems broke. It may be hard to > get the locking right… but still… I think the current cgroup API is still as > broke as it can get. The unified hierarchy approach makes some sense to me, > but > requiring that only one process modifies it, instead of providing an API > mutiple processes can use just seems plain broke to me. > > And I know, thats probably something to raise on LKML. And I may be inclined > to do so.
The systemd project does not have much (any?) influence over what interfaces the kernel provides, so I suggest you take your concerns up with them. That said, you will likely get further with technical arguments, and preferably an alternate implementation, than just claiming you have a bad feeling. Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel