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, <alast...@sceal.ie>, <mckins...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ad4f1b.6040...@sceal.ie
