You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...

So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun.

And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.

So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.

▲

dagenix an hour ago | parent | next [-]

If you don't like the debian model, didn't use debian. There are people that like the debian model, it seems like you aren't one of them, though. That doesn't make them wrong.

▲

zrm an hour ago | parent | prev | next [-]

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 35 minutes ago | parent [-]

You 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 15 minutes ago \| parent \| next [-]
		> ...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.
	▲	b112 5 minutes ago \| parent \| prev [-]
		Good grief, you are not forced to uae Debian! Please leave the only stable distro alone, and just use one more to ypur 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.

▲

zie an hour ago | parent | prev [-]

Clearly you disagree with the debian stable perspective. That's fine, it's not for everyone. You can just run debian unstable or debian testing, depending on where exactly you draw the line.

If you want the rolling release like distro, just run debian unstable. That's what you get. It's on par with all the other constantly updated distros out there. Or just run one of those.

Also, Debian stable has a lifetime a lot longer than 2 years, see https://www.debian.org/releases/. Some of us need distros like stable, because we are in giant orgs that are overworked and have long release cycles. Our users want stuff to "just work" and stable promises if X worked at release, it will keep working until we stop support. You don't add new features to a stable release.

From a personal perspective: Debian Stable is for your grandparents or young children. You install Stable, turn on auto-update and every 5-ish years you spend a day upgrading them to the next stable release. Then you spend a week or two helping them through all the new changes and then you have minimal support calls from them for 5-ish years. If you handed them a rolling release or Debian unstable, you'd have constant support calls.