Re: MATE 1.8 has now fully arrived in Debian
My fear is that systemd + friends are becoming a required framework,
subverting the Unix
ethos of a bunch of co-operating tools and libraries. It becomes
increasing impossible to
simply replace a component I might disagree with, or that breaks my use
case, with one I develop
because of all the cross-dependencies. While "if you disagree, write a
replacement" is the traditional answer
in Linux/Debian, we need to look out and make sure that remains possible.
regards
Alastair
> Wouldn't glibc then fall into the list of things you don't like as a
> "required framework"? By that logic, all libraries must be hot-swappable
> with no additional effort by the end-user. That's just not realistic.
>
> -Michael
>
A good example, but even in the case of key components like the kernel
and libc,
we've got drop-in replacements in Debian. This is in large part because
there were
well-defined APIs, dating to a project that (practically) predates
Debian: POSIX.
glibc basically implements POSIX + adds some functionality; creating a
drop-in is/was
possible as shown by BSD, eglibc, etc. Now Poettering (and others) has
been dismissive
of POSIX and sets out to effectively replace it with something more
modern; arguably
a good thing to do on technical grounds but changing the "ground rules"
or assumptions
we're used to.
Another example is the shutdown/policykit discussion elsewhere in this
thread. It looks like
the functionality it offers is a good enhancement, but it pulls in the
whole of systemd
in practice, bringing along the baggage of 'no separate /usr', etc.
design choices that I might
disagree with. It _should_ be possible to write a libpolicykit-alt that
provides a policykit API
( or dbus interface? i'm unfamiliar with how processes call policykit)
but offers a possibly
degraded functionality on systems where policykit is not present. But
here i'm chasing
systemd's taillights.
I think that for fundamental changes such as systemd are implementing we
need somehow
to carefully write out an API such that it remains possible to do such
things. We need to
recognise that systemd is a major change, crossing a line compared to a
usual package
or set of packages (even big ones like KDE, GNOME) and apply a larger
"design process"
of some kind in Debian to enable us to make changes in the future.
--
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
A decent provision for the poor is the true test of civilization.
~Samuel Johnson, Boswell: Life of Johnson
Reply to: