On Sun, Jun 18, 2017 at 05:16:34AM -0700, Bruce Perens wrote:
> On Sun, Jun 18, 2017 at 3:19 AM, Joachim Fahrner <jf@???> wrote:
> >
> > systemd is not not only an init system, it is expanding to a whole eco
> > system around the linux kernel, creating apis for everything you can think
> > of.
>
>
> Systemd started with the desire to communicate the desktop hardware state
> to user-mode applications and to make up for the lack of login sessions in
> the Unix API. There is no reason not to have APIs for everything you can
> think of, as long as they don't depend on systemd. The bad decisions were
> to tie these things into init system, to thus require a single software
> package for all of these APIs, and to subsume a great many system tasks
> into one software project.
>
> Although Unix provided these services (to the extent that they existed at
> all) using small programs, Unix was monolithic in that the kernel and the
> system utilities were all developed by ATT or later U.C. Berkeley, with
> some tweaks by your hardware manufacturer. You got the system utilities on
> your installation tape, and most hardware only had one choice of
> installation tape.
>
> It was only with the creation of the Free BSDs and the Linux distributions
> that you got package choice of system utilities. The original Debian had
> the entire base system produced by Ian Murdock as a single package. Before
> I split up production of the base system into separate packagers, nobody
> knew that you *could *produce the base system that way, and that it would
> work.
>
> The solution for this is to restore what I did with Debian: balkanize the
> system utilities, so that the APIs are provided by separate utilities
> developed by separate projects. The APIs originally provided by systemd
> need not change in doing this, although they need not be the only APIs for
> those services. Provide package choice.
>
> Provide the expected messages regarding the hardware state and user
> sessions through libsystemd0. Just don't have them come from systemd. Don't
> just answer all calls with "systemd is not here", provide the actual
> services where they do something useful. Provide a means for any system
> utility to originate those messages.

Have the API interfaces for systemd stablized?

If not, you will end up with a maintenance headache or another
incompatible API set as systemd continues to mutate. Which may be a
good thing if the new API set is stable.

If stability is the goal instead of compatibility, I propose that the
new API be the existing traditional one wherever that is feasible and
soething new where it is not.

-- hendrik