5 ms·
If your marriage is ending over a toilet paper roll... it's not actually about the toilet paper roll. It's the same deal with Debian and systemd. It's not the
by notriddle 5y ago
If your marriage is ending over a toilet paper roll... it's not actually about the toilet paper roll.
It's the same deal with Debian and systemd. It's not the init system. It's the thing it represents. Having to either adopt systemd or run GNOME in an unsupported configuration seems like a clear-cut choice (which is why systemd is now the Debian default), but having a major upstream force you to significantly rearchitect the distribution seems like a pretty significant loss of control. This is at the same time as other upstreams have gradually ripped control out of the hands of Debian developers in other ways: Firefox, librsvg, and python-cryptography adopting Rust suddenly made it a lot harder to support a bunch of niche CPU architectures. Speaking of Rust, and also Go, they use static linking and have their own library package managers, which both makes it harder for Debian to package and simultaneously easier for users to install a binary directly provided by upstream. And languages that don't have static linking support can always use Docker.
Honesty, I wouldn't want to be a Debian developer right now. Red Hat has tried to reinvent themselves in a world of containers, but since Debian is a volunteer organization and not a corporation, it's a lot harder to pivot (attempting to pivot would probably cause all their existing volunteers to quit, while failing to attract new ones). What sort of future does Debian even have, if they have no decision-making power over the core OS, and all the applications route around them?
- einpoklum 5y agoI would downvote you because: 1. "GNOME in unsupported configuration" is, with due respect, FUD. 2. There was no dichotomous choice to make. Debian could have let you decide whether or not to install systemd. Instead, the project decided to essentially force the use of systemd, necessitating a fork. 3. "suddenly made it a lot harder to support a bunch of niche CPU architectures" <- why is it difficult to offer a different selection of potential default browsers, on those niche platforms or in general? 4. Language-related package manager do make things difficult for an OS distribution, at least somewhat - but that's not particular to Debian. However - I actually agree with your main point. I'm sure Debian maintainers/developers have it hard. I really wish Debian would: 1. Admit the Devuan people were right and re-merge the distributions. 2. Recruit, offering a self-training track for aspiring package maintainers. 3. Modernize some of their tooling (as people seem to be complaining about that) 4. Fundraise effectively, to finance the above.
- notriddle 5y ago> 1. "GNOME in unsupported configuration" is, with due respect, FUD. If GNOME doesn't work with Debian's systemd-shim, are they going to accept patches to fix it? Or will it be up to Debian to maintain those patches? > 2. There was no dichotomous choice to make. They didn't make a dichotomous choice. They made systemd the default, but maintained the ability to switch to another init system [1]. [1]: https://packages.debian.org/sid/init-system-helpers https://packages.debian.org/sid/init-system-helpers > Debian could have let you decide whether or not to install systemd. Instead, the project decided to essentially force the use of systemd, necessitating a fork. If this is "essentially forcing" the use of systemd, then what possible choice would have counted as not forcing it other than making sysv the default? > 4. Language-related package manager do make things difficult for an OS distribution, at least somewhat - but that's not particular to Debian. You're not wrong, but most Linux distributions either don't have "LTS" releases [2], or they have commercial backing. [2]: Not having to backport security fixes saves them a lot of hassle. > 1. Admit the Devuan people were right and re-merge the distributions. Right about what? Devuan/Debian is hardly a comparable situation to LibreOffice/OpenOffice. It's more like the relationship between Librewolf and Firefox, where a bunch of loud fans are praising the fork to the sky, but most of the developers are still working on the original project and the "fork" is busy rebasing their patches onto each new upstream release. > 2. Recruit, offering a self-training track for aspiring package maintainers. That would be great, but are there volunteers lined out the door who want to join the program, and just can't? Or is it boring, frustrating work that few people are interested in? > 3. Modernize some of their tooling (as people seem to be complaining about that) I actually agree with this point, but I'm not sure if this is the primary problem, or if it's just a minor issue that distracts from the main problem. > 4. Fundraise effectively, to finance the above. There is no Debian Foundation. They would have to have somewhere to send the funds to, before they'd be able to collect it. Obviously, this is almost as contentious as systemd was [3]. [3]: https://lwn.net/Articles/888752/ https://lwn.net/Articles/888752/
- einpoklum 5y ago> They made systemd the default, but maintained the ability to switch to another init system [1] No, they didn't. You can't install debian without systemd. They _said_ they let you switch, but they don't. People did not fork an entire distro just because they didn't like to press "option B" instead of "option A". > If this is "essentially forcing" the use of systemd, then what possible choice would have counted as not forcing it other than making sysv the default? 1. Not having packages depend on systemd. 2. Bringing up a prompt/dialog during installation to make a choice of whether or not to use it. > most of the developers are still working on the original project Because Devuan is just Debian with some tiny changes and a different choice of packages. And of course, the infrastructure of a project - website, forum, IRC, download servers, etc. So of course most developers aren't concerned with that, they just provide/maintain upstream packages. > Obviously, this is almost as contentious as systemd was I didn't know about this aspect, thank you.