Live data from Hacker News

The Delusions of Debian

unixsheikh.com

51–60 of 62 posts

Re: The Delusions of Debian

#51

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 rearchi…

I 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" 4. Language-related package manager do…

> 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

> 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/

Re: The Delusions of Debian

#52

To me, the tone of the article reads a bit dismissive and sometimes borders on a rant (e.g. i doubt that things related to inclusivity/social issues are to blame for the state of the OS), however it also feels like it concisely describes many important concerns. > The fact of the matter is that Debian has long been experiencing a decline in the amount of people willing to participate in the project. > Oh, I almost fo…

> On FreeBSD, the package manager informs you if you're installing a package that has been abandoned. It also informs you about important security issues.

Debian has the package apt-listbugs

Re: The Delusions of Debian

#53
post #9

This article is full of inaccuracies and errors. > Due to the sheer size of the current Debian release it is infeasible for a small team to be able to audit all the packages, so there is a system of prioritizing packages which are more security sensitive. This was, at best, poor communication. Of course nobody would ever audit all of 90,000 packages, easily billions of LOC. Especially not when the vast majority of th…

>> Due to the sheer size of the current Debian release it is infeasible for a small team to be able to audit all the packages, so there is a system of prioritizing packages which are more security sensitive. > This was, at best, poor communication. Of course nobody would ever audit all of 90,000 packages, easily billions of LOC. Especially not when the vast majority of these packages have a very small user base. How…

The author didn't state that. That's a direct quote from the Debian page, from the "Audit Scope" section.

That statement is entirely reasonable, yet the author frames this as the the point where "things begin to spin out of control!".

Re: The Delusions of Debian

#54

Earlier quoted context omitted.

I 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" 4. Language-related package manager do…

> 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.…

> 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.

Re: The Delusions of Debian

#55
post #19

It’s a shame that after so many years and so many distributions the community could not come up with a good model for a low maintenance secure distro. IMHO the author of this post is surely the kind of people that eventually only care about their job security and just stir the water without making any progress…

"Low maintenance" and "Secure" are contradictory goals.

Maybe that’s the point of the author. But I completely disagree.

Re: The Delusions of Debian

#57

Earlier quoted context omitted.

> 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.…

> 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 no…

> 1. Not having packages depend on systemd.

This implies either (a) refusing packages that depend on systemd, or (b) patching packages. Which brings us right back to the original problem: who's on the hook for making sure it works?

> 2. Bringing up a prompt/dialog during installation to make a choice of whether or not to use it.

https://www.joelonsoftware.com/2000/04/12/choices/

... okay, I admit I also need to offer a reason why it's okay for Debian to offer the install options that they do offer, while they also refuse to offer this option, and can't really come up with one. The way that Debian allows you to pick a desktop environment at install time, while not allowing you to pick an init system, is a bit of an arbitrary decision.

But the decision being arbitrary isn't a reason to offer every single theoretically possible option at install time. Debian never allowed you to pick an init system at install time before! Why start now?

Re: The Delusions of Debian

#58
post #55

Earlier quoted context omitted.

"Low maintenance" and "Secure" are contradictory goals.

Maybe that’s the point of the author. But I completely disagree.

If programmers could write secure code from the start, then security updates wouldn't be needed.

Years of experience have shown that programmers can't write secure code from the start. Maybe some day we'll have languages & tools that allow for network-connected programs that never need security updates, but today is not that day.

Attackers often exploit vulnerabilities reasonably quickly, so updates have to happen soon after vulnerabilities are discovered.

So we need timely updates, and we keep needing updates. Unless we define "updating software" as not contributing to maintenance, I'd say my point stands.

The maintenance is made even harder for distributions like Debian that want to backport security fixes without backporting feature changes or other refactorings. That produces a lot of extra work for the maintainers, and those maintainers aren't usually as familiar with the code as the authors further increasing the maintenance burden.

Re: The Delusions of Debian

#59
post #29

Earlier quoted context omitted.

I'm not exactly sure why Debian supports alternatives, that seems like a terrible idea when you're already stretched thin, but most everything else about it seems to be less tinkerer-friendly then Arch. Seems like a lot more people can kind of grudgingly tolerate systemd, but they really seem to hate outdated packages, and anything "unnecessary".. Some of them are pretty neutral on systemd itself, or have given up on…

> I'm not exactly sure why Debian supports alternatives Debian has hurd and freebsd ports for which systemd is not available.

Supporting hurd and freebsd ports doesn't exactly seem like the best use of resouces for a smaller-than-google team either, but then again it might be important if losing those would also mean losing some key contributors.

Re: The Delusions of Debian

#60

Earlier quoted context omitted.

> 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 no…

> 1. Not having packages depend on systemd. This implies either (a) refusing packages that depend on systemd, or (b) patching packages. Which brings us right back to the original problem: who's on the hook for making sure it works? > 2. Bringing up a prompt/dialog during installation to make a choice of whether or not to use it. https://www.joelonsoftware.com/2000/04/12/choices/ ... okay, I admit I also need to offer…

> who's on the hook for making sure it works?

Well, Devuan people made it work, while also maintaining an entire distro fork. This could easily have been made to work on Debian. The alternative would have been to lean on GNOME, I think.

> every single theoretically possible option at install time

systemd-or-not is not "every single theoretically possible option". It is a highly contentious and political issue. If the systemd proponents would have accepted defaulting to no-systemd, then great, no need for the choice; but realistically, both sides are somewhat adamant, so making the user choose is a reasonable compromise IMHO.

Post reply on HN