[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

Lennart Poettering lennart at poettering.net
Tue Oct 21 02:52:50 PDT 2014


On Tue, 21.10.14 11:25, Martin Steigerwald (Martin at 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


More information about the systemd-devel mailing list