On Tue, 21.10.14 11:25, Martin Steigerwald (mar...@lichtvoll.de) wrote: > > The "scopes" and "slices" concept does not exist elsewhere, and > > there's nothing comparable around, so even if we wanted we couldn't > > make logind work on anything else. > > Then why in the first hand are the "scopes" and "slices" concepts within > systemd *tightly* coupled when it is functionality that makes sense to be > utilitizes in a component that provides a different functionality.
It's how people generally build systems: the lower layers provide basic functionality, the upper layers then make use of. To keep our code small and simple we do things that way. We don't reimplement all functionality all the time on all levels, because we don't want to make any assumptions about what the layers below us provide us with. > I wonder what functionality systemd provides right now in one more or less > tightly coupled package: > > - early boot process > - managing kernel drivers and device files (via coupled udev) > - resource control for process groups > - logging > - core dumping > - network while I think a distro-unified way to approaching network that > replaces the current distro specific ways like ifupdown and so on, why does > it > have to be coupled with systemd? We maintain this stuff in one repository, and release it with simultaneous release cycles. We can share tons of code that way, and easily give it a uniform, integrated feel from the outside. Things like the core dumping or networkd are purely optional. If you don't like them, don't use them. > - cron, although that at least in Debian is separate as systemd-cron Hmm? not sure what that is supposed to be. We have no "cron" in systemd, only timer units. > Way more than traditonal sysvinit covered. yeah, systemd is a basic toolbox to build an OS from, sysvinit was just a minimal init system, and nothing else. > What of this actually *needs* to be coupled with systemd? What of this needs > to be coupled tightly to Linux kernel? No, nothing "needs" to be coupled. But it makes development for us vastly simpler and the system altogether more uniform and smaller. > systemd is driving a road where its all of this functionality by default is > only available for Linux and where upstream said they just won´t accept > patches – is that still true? – for portability. systemd provides more and > more functionality that desktops like to use, that other tools like > to use. We take portability patches for other archs, but not for other kernels. It's also really a pointless excercise, the BSDs or Solaris would never adopt systemd anyway, I am not sure why you'd think otherwise. They all have their own (unportable) service management logic they don't make portable either. Most prominent is Solaris' SMF which is tied closely do their "contract" ids, which is not portable. Moreover note that the BSDs at least actually are much stricter then we are. We *just* put the moszt basic bits of the OS glue into one repository and apply one common release cycle to it. On FreeBSD they also maintain the libc and the kernel in the same framework and schedule. > When Microsoft back then did something like this it was called "Embrace, > Extend and Extinguish"¹… Oh come on. You are just being a dick now. > a) Embrace: systemd provides functionality that is mostly compatible or > similar with what sysvinit and other components provided > > b) Extend: systemd extends on that functionality and makes it more and more > difficult for desktops and apps to ignore that kind of functionality offers > > c) Extinguish: The scope of systemd becomes so broad, the functionality it > offers in a – admittedly – convenient package to often needed and used, that > other ways of providing the functionality are extinguished. > > Really… it matches quite closely. No it doesn't. We provide you something for free. We don't care if you use it or you don't. We don't take your freedom away by offering this to you for free. Show some respect, man! > I don´t think this was your plan. But… when looking at the currently visible > outcome this is quite exactly what is happening here. Please, instead of making up your weird theories, actually do something about things. I'd welcome any competition. It's really not my fault if the people who actually like systemd appear to do almost all work and thus adopt it. And the people who don't just sit around and talk. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel