:: Re: [DNG] I have a question about l…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Bruce Perens
Fecha:  
A: Joachim Fahrner
Cc: dng
Asunto: Re: [DNG] I have a question about libsystemd0 in devuan ascii,
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.

    Thanks


    Bruce