Re: Technical committee acting in gross violation of the Debian constitution
On Fri, Nov 28, 2014 at 4:32 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek@in.waw.pl> wrote:
> On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
>> And well, I also wonder why systemd --user functionality is in the *same*
>> binary than the PID 1 stuff… but well… I brought this upstream to no avail.
> OK, since this is a different forum, let me go over the reasons once again.
>
> The code paths in systemd which differ between --system and --user are
> relatively small.
>
> [snip]
>
> The
> majority, like the unit dependency logic, starting of processes,
> notifications from services, opening of sockets, watching of paths,
> etc, etc, are all shared. Actually systemd --user is probably closer
> to systemd --system running in a container than to systemd --system
> running on the host, because both run without full privileges and
> simply skip mounting of various things and other low-level setup.
>
> In this scenario it is natural to structure the code as a single binary
> that conditionalized parts of it logic as necessary.
+1
>
>> At least the logind stuff appears to be separate:
> Yes, logind does not share many high-level code paths with the systemd
> binary, so it is natural to keep them separate.
>
> OTOH, systemd and systemd-logind use the same primitives like string
> handling, configuration file parsing (including the logic of drop-in
> directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
> of other utility functions, which are provided by the shared systemd
> libraries, so it is much easier to develop them in a single repository.
Do you really think logind and systemd are the only pieces of C
software that struggle with strings or config parsing? Those are
definitely a couple of things that could be split out into a separate
library so we all do not have to either (a) suffer through it,
tediously writing another solution or (b) throw our software in
systemd's git repo and use the same release cycle and license and all
the other implications of being in the same repo (including not having
commit access to your own software automatically).
The config aspects especially so. It would be very positive if
software knew they could just depend on a really simple library and
get config parsing for basically free, since then users would
eventually only have to know how to write one config format and
software would only have to know how to read (parse) that same one.
I do not know why I am discussing this here though, haha.
Cheers,
--
Cameron Norman
Reply to: