6 ms·

glibc's actually pretty bad, and many people prefer alternatives such as musl. Ideally, it would be easier to use an alternative libc. Wherever possible we sh

by agwa 9y ago

glibc's actually pretty bad, and many people prefer alternatives such as musl. Ideally, it would be easier to use an alternative libc. Wherever possible we should encourage modularization and standards-compliance, not lock-in, so that the best implementation can rise to the top. So yes, the same centralization/reducing-choices arguments apply to glibc.

zbentley 9y ago
Those are good points. Systemd is somewhat modular/swappable for other init (et cetera) systems, but the practice of actually swapping it out as a dependency of a given package is roughly as tricky as switching out glibc for something else. You have to crack open the package and make it not depend on/automatically install the init system (or libc) you don't want, tell it to install one that you do want, and then thoroughly test to make sure that the old version wasn't depending on a piece of behavior specific to the init (or libc) that you switched out. Or you could build and package the software yourself, with similar hassles to address. The problem with standards compliance is that, once something becomes ubiquitous enough, its compliance begins to "drift", and replacement parts get harder to find. Is it tricky to swap out the init component of systemd with something else? Not terribly. Is it tricky to swap out its dbus messaging setup with something equivalent that can still be used by unaltered software that was previously talking via the systemd setup? Yes, a bit. And so on. For equivalent hassles regarding libcs, check out some of the FOSDEM talks from the musl folks, or the alpine folks, where they talked about the difficulties in porting software that had come to depend on the quirks of glibc. Or just, you know, google "quirks mode" and get simultaneously nostalgic and sad :)
- JdeBP 9y ago
  There is no need for nostalgia. There is a contemporary quirks mode to be found at http://jdebp.eu./Softwares/nosh/guide/convert-systemd-units.html http://jdebp.eu./Softwares/nosh/guide/convert-systemd-units.... . (-:

by agwa 9y ago

zbentley 9y ago

Those are good points. Systemd is somewhat modular/swappable for other init (et cetera) systems, but the practice of actually swapping it out as a dependency of a given package is roughly as tricky as switching out glibc for something else. You have to crack open the package and make it not depend on/automatically install the init system (or libc) you don't want, tell it to install one that you do want, and then thoroughly test to make sure that the old version wasn't depending on a piece of behavior specific to the init (or libc) that you switched out. Or you could build and package the software yourself, with similar hassles to address. The problem with standards compliance is that, once something becomes ubiquitous enough, its compliance begins to "drift", and replacement parts get harder to find. Is it tricky to swap out the init component of systemd with something else? Not terribly. Is it tricky to swap out its dbus messaging setup with something equivalent that can still be used by unaltered software that was previously talking via the systemd setup? Yes, a bit. And so on. For equivalent hassles regarding libcs, check out some of the FOSDEM talks from the musl folks, or the alpine folks, where they talked about the difficulties in porting software that had come to depend on the quirks of glibc. Or just, you know, google "quirks mode" and get simultaneously nostalgic and sad :)

JdeBP 9y ago
There is no need for nostalgia. There is a contemporary quirks mode to be found at http://jdebp.eu./Softwares/nosh/guide/convert-systemd-units.html http://jdebp.eu./Softwares/nosh/guide/convert-systemd-units.... . (-: