Hi, Neil Williams <codeh...@debian.org> writes: > Atually, not particularly thinking of systemd at this point, but in > *general* there is a good technical advantage to this approach: > migrations & dependency control. It avoids the "fingers in every pie" > problem common to a number of source packages in Debian. > [...more stuff...]
This reasoning is basically "turtles all the way down". Let me give you two examples to illustrate: The first are the coreutils, often invoked as a good example of how to do the unix-philosophy right. But if you look at pretty much any modern implementation of (for example) ls, it certainly breaks with the unix-philosophy *very* violently. It should just give you a listing of all the files, but it also does: • stat()ing (duplicated from stat(1)) • Sorting (duplicated from sort(1)) • Colorization • Column-formatting • --ignore,--hide (duplicated from grep(1)) • String escaping It is also is unnecessarily intertwined with different software: At least on my system there is --dired which only works with emacs. Now it forces me to use emacs, instead of vim, or I have to implement this functionality myself! So really, ls should just offer a simple stable API to list files and if you want colorized output, or more information about the files, you can parse it's output and feed it to stat and/or grep and/or sort. So it should basically just be a thin-wrapper around getdents(2). Though, of course, getdents is just a syscall, so it is just part of example number two: The linux userspace API. Because let's be honest: It is next to impossible, to replace any part of the linux kernel or any module, without having to constantly play catch-up. Because the kernel does not offer any stable APIs to it's modules, you have to develop modules in lockstep with the kernel. If the kernel would offer a stable API, hardware-vendors could just develop their drivers against this API and have it run for every kernel-version. Majorly painless updates for proprietary drivers, finally! Though, of course, there is no good reason, why a graphics-driver should stop at OpenGL (or similar) as a stable-API for it's functionality. After all, this prevents me from rolling my own OpenGL-implementation for this particular driver. In both cases, the devs certainly acknowledged the need for a stable API. But they had to choose one boundary where to provide this. So they made their choice and committed to it. And one can disagree with these choices (in both cases there are people who have very strong opinions that these boundaries are indeed wrong), but ultimately it was the choice of the maintainers, what level of modularity to provide. The same goes for systemd: It actually *does* provide modularity and stable APIs. In your opinion their choice of this boundary was wrong. But boundaries are, in the end, arbitrary and it is ultimately up to the maintainer of the package to decide, where they draw the line. At the very least, if you want them to change their minds, it is up to *you* to provide a justification why *your* choice of boundary is the better one (i.e. no one argues *that* you need stable APIs. The question is at what level and I have so far not seen any good arguments for a different boundary). Best, Axel Wagner -- 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/8738941e43.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
