> Like it or not (and I pretty much dislike it), the way systemd went
> down incorporating almost everything is a "natural" way to try to
> tackle complexity, i.e., by centralising things in the hands of a
> minimal number of actors and creating a whole lot of
> interdependencies.

Hi KatolaZ,

This is almost exactly the advice I got about the base system in Debian.
There were too many inter-dependencies and too many ways that one
programmer could break things for everyone with a single package and bring
down all of the users systems. And no Unix anywhere had ever been built
that way.

In my ignorance, I went ahead despite the advice of experts and with less
than 20-20 foresight about how it would turn out. Luck loves a fool, and
things worked out all right.

So, I think we should go ahead and experience for ourselves how badly we
can break the system and what we can do about that.

    Thanks

    Bruce

On Mon, Jun 19, 2017 at 4:24 AM, KatolaZ <katolaz@???> 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.
> >
>
> Dear Bruce,
>
> the main problem with this is that if you want to provide a consistent
> interface to the upper-level userland and to include support for fancy
> concepts like "session" and "seat", as systemd aspires to, you must
> have control on all the low-level userland. There is no other
> way. Your interface cannot remain consistent if a random developer can
> change a functionality in consolekit without letting you know. This
> is why systemd "had" to incorporate the functionalities of a few
> dozens different daemons and projects down there, including logging,
> hardware detection, authentication, network connection, and a myriad
> more.
>
> Like it or not (and I pretty much dislike it), the way systemd went
> down incorporating almost everything is a "natural" way to try to
> tackle complexity, i.e., by centralising things in the hands of a
> minimal number of actors and creating a whole lot of
> interdependencies. I personally think this does not work in the long
> run, and I find it clashing with the most basic KISS principle. This
> is enough for me to firmly refuse similar attempts.
>
> My2Cents
>
> KatolaZ
>

> --
> [ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]
> [     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
> [       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
> [     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
> [ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]

>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>