On Sun, 18 Jun 2017 08:41:15 -0400
Hendrik Boom <hendrik@???> wrote:

> 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.

Which, I believe, would either preclude inclusion of Gnome3 or make
inclusion of Gnome3 a constantly ugly problem.

SteveT

Steve Litt
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key