Re: Clarifying what 'systemd' actually means
On 07/02/2017 01:37 PM, Alessandro Vesely wrote:
> On Sun 02/Jul/2017 12:37:33 +0200 Christian Seiler wrote:
>> This bug has nothing to do with systemd as the init system, it's in an
>> optional component that's disabled by default on Debian. In principle,
>> I suspect that resolved could also be used on sysvinit, if you really
>> wanted to, though I haven't tried it.
>>
>> Furthermore, the systemd versions of Wheezy and Jessie are too old to
>> already include systemd-resolved, so they are not affected at all.
>
> Yet, there's a man page:
> https://manpages.debian.org/jessie/systemd/systemd-resolved.service.8.en.html
Oh, my bad, it's shipped in Jessie, but in a very early state of
development. I suspect that the functionality that has the bug
wasn't already implemented in the Jessie version. I'm not
completely sure about resolved, but networkd in Jessie is only
shipped as a technical preview (see Jessie's release notes), by
the way, so people shouldn't be using Jessie's networkd for
production purposes anyway.
> I'd be curious on why tools which don't even require that systemd be PID1 go
> under the systemd umbrella.
The technical reason (which has been mentioned multiple times by
the systemd developers in various places) is that these utilties
share code with systemd when it comes to basic utility functions,
such as configuration file parsing, or wrappers around common
tasks that are quite cumbersome to do with just the standard C
library. And since they don't want to provide a stable API and
ABI for C utility helper functions, these programs are put
together in the same repository.
The reasoning is very similar to how the Linux kernel works,
albeit on a much smaller scale. Sure, some things are definitely
things that do belong in the core kernel, but there are a _ton_
of drivers and other functionality that technically could be
managed outside of the kernel tree. But for the very same reason
(the kernel developers don't want to have to guarantee a stable
ABI for modules) people are encouraged to only have out of tree
kernel modules during the initial development, and that these
should be merged into the mainline kernel at some point.
How somewhat related projects should or shouldn't be bundled in
the same repository has always been something that doesn't have
a clear right or wrong answer, and a lot of that will depend on
the personal tastes of the people working on this.
For example: why are most standard shell utilities all bundled
together in the 'coreutils' package, but e.g. find is in the
separate 'findutils' package? And 'ps' in the 'procps' package?
Wouldn't it also make sense to either unbundle all utilities
into their own tiny packages, or bundle them all into a large
global package? And the answer to that is simply: if you had to
develop all of these tools from the ground up again, then you
might choose one of the other schemes, or split it up differently
altogether. But because of historic reasons, and because of
how the developers of the respective utilities feel, the split
is the way it is at the moment. There simply is no right or wrong
answer here.
> Doesn't that contribute to make systemd appear
> like some kind of conspiracy?
I don't know about the systemd developers, but I personally
don't think it's fruitful to make decisions based on the
irrational beliefs of other people. If a person came up to me
in the supermarket and said I shouldn't buy a particular brand of
milk because the company is affiliated with the Illuminati, I'm
not going to base my decision whether I'm going to buy that brand
or not on that statement.
(To clarify: I'm not saying that people who don't like systemd
can't be rational, but I do think that anyone who claims to see
a conspiracy here is not taking a rational position.)
> BTW, is resolved one of them or does it require systemd?
I suspect it doesn't need systemd as PID1, but I'm not sure and
I haven't tried it. I'm pretty sure it doesn't come with an init
script though, so that you'd have to write yourself if you
wanted to use it without systemd.
Regards,
Christian
Reply to: