4 ms·
There are two different kinds of updates. One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount
by zrm 5mo ago
There are two different kinds of updates.
One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now. These are the updates stable gets.
The other is changes and additions. They're both more likely to break things and less important to move into production the same day they become public.
You don't have to wait until testing is released as stable to run it in your test environment. You can find out about the changes the next release will have immediately, in the test environment, and thereby have plenty of time to address any issues before those changes move into production.
- koverstreet 5mo agoYou definitely need different channels for high priority fixes and normal releases, stable and testing releases and all that. But two years is impractical and Debian gets a ton of friction over it. Web browsers and maybe one or two other packages are able to carve out exceptions, because those packages are big enough for the rules to bend and no one can argue with a straight face that Debian is going to somehow muster up the manpower to do backports right. But for everyone else who has to deal with Debian shipping ancient dependencies or upstream package maintainers who are expected to deal with bug reports from ancient versions is expected to just suck it up, because no one else is big enough and organized enough to say "hey, it's 2026, we have better ways and this has gotten nutty". Maybe the new influx of LLM discovered security vulnerabilities will start to change the conversation, I'm curious how it'll play out.
- rlpb 5mo ago> ...upstream package maintainers who are expected to deal with bug reports from ancient versions... They are not expected to deal with this. This is the responsibility of the Debian package maintainer. If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it. If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.
- koverstreet 5mo agoIf package maintainers were always fine upstanding package maintainers as you imagine them to be I wouldn't be complaining, but I have in fact had Debian ship my software and screw it up and gotten a flood of bug reports, so... :) I think you need to chill out. Relicensing the way you suggest would be _quite_ the hostile act, and I'm not going to that either. But I am an engineer, so of course I'm going to talk about engineering best practices when it comes up. You don't have to take it as an attack on your favorite distro - that really does pee in the pool of the upstream/downstream relationship between distros and their upstream.
- fc417fc802 5mo ago> I am an engineer, so of course I'm going to talk about engineering best practices when it comes up. The trouble is you seem to be assuming that best practices for you, in your opinion, also apply to everyone else. They don't. Not everyone sees things the way you do or is facing the same issues or is making the same set of tradeoffs. There are downsides to what debian does but there are also upsides. At this point, given the plethora of high quality options available as well as how easy it is to mix and match them on the same system thanks to container-related utilities and common practices I really don't think there's any room for someone who doesn't like the debian model (ie in general, as opposed to targeted objections) to complain about how they do things. If you want cutting edge userspace on debian stable at this point you have at least 3 options between nix, guix, and gentoo. There's also flatpak and snap which come built in.
- koverstreet 5mo agoWe're in the middle of a huge spike in LLM discovered security vulnerabilities, which means not everything will get assigned a CVE, a lot of people are watching repositories to look for exploitable bugs, and in the frenzy of backporting that people are now having to do things will get missed. I wager it's only a matter of time before we see a mass rooting event that hits Debian hard while everyone running something more modern has already been patched. I think that might be what cuts down on the grandstanding about "freedoms" and "that's how we've always done things". You certainly are, up until it becomes a public nuisance.
- b112 5mo agoGood grief, you are not forced to uae Debian! Please leave the only stable distro alone, and just use one more to your style. I assure you, enormous sums of people prefer Debian the way it is. I do not, ever, want "new stuff" in stable. I have better things to do than fight daily change in a distro, it's beyond a waste of time and just silly. If you want new things, leave stable alone, and just run Debian testing! It updates all the time, and is still more stable than most other distros. Debian is the way it is on purpose, it is not a mistake, not left over reasoning, and nothing you said seems relevant in this regard. For example, there is no better way than backporting, when it comes to maintaining compatibility. And that's what many people want.
- washingupliquid 5mo ago> One is security updates and bug fixes. That's where you're wrong. They're not one and the same. Debian stable often defers non-security bug fixes for up to two years by playing this game. I'm not interested in new features unless they make things actually work. Debian stable time and again favors broken over new. Broken kernels, broken packages. At least they're stable in their brokenness. Hence my complaint.
- PunchyHamster 5mo agoHaven't noticed much broken. But I have noticed far more broken in distro that DOES backport features, RHEL/Centos. So many that we migrated away from it, when they backported a driver bug into centos 5 and then did the same backport of a bug for centos 6. Also rebuilding package is trivial if you don't agree with what should and should not go into stable version