[systemd-devel] What I think is really wrong with systemd

[Michał Zegan]

I actually believe that debian does some splitting, for example 
pam-systemd module is in a separate package. Actually I feel that 
particular case is wrong, but it happens there. I mean debian jessie, of 
course.

W dniu 16.09.2015 o 12:30, Colin Guthrie pisze:
> I wouldn't normally grace such rants with a reply, but I'll try and keep
> this one short.
>
> dottomi at gmail.com wrote on 16/09/15 08:47:
>> Hi, sorry for another rant, but I'm a software developer and a user of
>> a Linux-based operating system here.
>>
>> I read the post about at 0pointer.de about "myths about systemd". [1]
>> I want to address the issue of it being monolithic.
>> More specifically, I want to tell what where is that coming from.
>>
>> systemd started an an init system. It had an idea of doing one thing
>> "the proper way" - of system init on Linux-based systems.
>> That made the project easy to understand and follow.
>>
>> Now, as was written in that post, the project consists of over 69
>> binaries, where most of them are entirely optional.
>>
>> The problem with this project is not how it is written.
>> It is how it is *packaged and distributed* to end-users.
>>
>> Luckily, I use Gentoo. I have Portage, which will happily compile the
>> package on my system and I can tell it by USE flags what to compile
>> and what not to. Other package managers doesn't work this way. They
>> fetch *pre-compiled packages*.
> So basically you're complaining to the upstream systemd project about
> how downstreams consume it?
>
> You should really take this complaint to downstreams.
>
>> Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server?
>> A system logger? Something that uses QR codes? Can I replace it with
>> another package?
>>
>> The answer is: no one but the developers know.
> Not true, the developers know, but also the downstream package
> maintainers know too - or at least they should know. It's their job to
> decide which components to use to build their operating system.
>
>> The package doesn't even have an understandable version numbering. It
>> is one increasing number. How is a package maintainer supposed to know
>> if version change from 340 to 341 introduces major changes? I don't
>> even know *what* changed unless I read a ChangeLog.
> Package maintainers are *expected* to read the changelog. This isn't
> some minor part of the operating system we're dealing with. These are
> the key building blocks that make up the very base of the userspace
> layer. If I'm using a distro, I want my package maintainer to at very
> least read the changelog, but ideally be much more informed than even that!
>
>> Normally, you have a major version and a minor version. If the major
>> version changes, it is an alarm to do throught testing to see if
>> everything works wellon the new one. Minor changes are minor, so they
>> require less testing.
> Minor, major etc., this doesn't matter. Even minor changes can introduce
> major bugs. The fact that someone arbitrarily decided "this is a minor
> change" doesn't make the change safe in any way. Testing of such key
> components should be the same regardless. Adopting such a scheme in a
> project like systemd serves no purpose but to create a fake illusion of
> "safeness".
>
>> What this project needs is division of this one big have-it-all
>> package into individual packages, each containing components for a
>> specific purpose. There is nothing wrong with them depending on each
>> other, but they should be in different packages, each having a
>> separate build system and version, for the following reasons:
>>
>> 1) You as developers are more aware of what changes in the project,
>>     beause commits are associated with individual componenets.
> They already are, both in the commit message and simply by doing "git
> log" in the appropriate folders.
>
>> 2) If a component was a failure, you can just drop
>>     the package and work on another - nothing else needs work.
>>     Most importantly, the main component is not touched.
> This can still happen and is irrelevant to how the git repo is structured.
>
>> 3) The people that are not involved with the developement are more aware
>>     what the suite of packages called systemd is actually composed of.
>>     Package maintainers can now block one component if there is
>>     something wrong with it, but not all the others.
> If this is how downstream want to work (i.e. provide competing
> component) then they can package things that way if they like. Doing it
> upstream has no purpose other than adding overhead.
>
>> 4) The user can then install the init system from systemd, and keep
>>     their system logger. Example: systemd-logind should not pass the
>>     messages to another logger. The other projects should be encouraged
>>     to use systemd APIs/ABIs on Linux to get them.
>>     This makes systemd-logind more lightweight.
> This shouldn't really be about user choice, but distributor choice.
> Distributors are welcome to package things as they wish within the basic
> constructs.
>
> Your example doesn't make sense. systemd-logind already does not pass
> message to another logger, it uses the journal exclusively.
>
>> 5) Most importantly: by such a split you future-proof the project
>>     as a whole. Someone might come up with a better solution for
>>     a component than you in the future. That someone should not fight
>>     with your system in order to use other components. It should be made
>>     easy and simple to replace any binary systemd uses now
>>     with another - with another PACKAGE.
>
> Again, this is something that is for downstream packagers.
>
>
> None of these reasons identify anything that really needs to change
> upstream.
>
> Also, you have to keep in mind that a shared codebase creates much less
> overhead and problems. There is a lot of internal code used by all
> components in system that is in private APIs. Splitting out the project
> to separate sub-projects would mean committing to API and ABI stability
> on much of this code. This is a huge burden and not something to
> undertake lightly.
>
> The downstream distributions can do things as you describe now without
> the need to split things out as you describe.
>
>> If systemd keeps going the way it does, it will eventually get forked,
>> because it will become an unmaintainable mess when you notice
>> something major in the system could be done better, and that better
>> approach breaks everything else in the system. systemd works fine.
>> NOW. I also would want it to work after 20 years, because I see good
>> ideas here.
> It's precisely because it's all in one place that allows changes to be
> made in lockstep and all dependent code updated. If the changes you
> mention were related to public API then all the sub-compoenents would
> still break but you'd have to go around and update them all separately.
> Bisecting history would be a nightmare when searching for regressions
> etc. and ultimately this makes things less manageable.
>
>> Actually, I think this project's future is a "Linux-based Init and
>> Service Management System Standard", where the systemd suite
>> of packages is the reference implementation.
> Perhaps it is. If any project wants to provide alternatives to any
> component they are free to do so. If a downstream distributor wants to
> use that component over systemd's one, they are free to do so. If they
> want to offer the user a choice of which one to use, they are free to do so.
>
> Basically, tl;dr, I think some of your comments about what components
> people may want to use are valid enough, but I think that none of them
> form a basis to change anything in the way systemd codebase *upstream*
> is managed. It might make sense to change how it's consumed downstream,
> but that doesn't really affect the upstream project.
>
> All the best
>
> Col
>