The problem with Debian is their insistence on "stability" by not updating the packages. In the modern world, when software development speed picked up steam quite a lot, releases of new software happen much more often than distribution life cycles.
Many times I’ve add to add external/weird repositories to get some functionalities i rrallneeded (eg: appropriate codecs fir bluetooth audio and a version of bluez that supported by bluetooth headsets) and that kind of tainting really endangers the longevity of a debian-based system.
I understand that the fault is completely on the external repositories and on the user… however the choice then is to be able to use my hardware (or, in general, to the kind if computing i need) or not.
These days I’m using fedora btw, which has been really stable while providing fairly up-to-date packages.
That's not a problem with debian, that's just a mismatch in needs, you're probably better off with a "less" stable operating system.
I'll be honest, i haven't had any stability issues with Fedora either, and i've been upgrading as often as i would with Debian. And in both cases, i'm using fairly old and known hardware (years old thinkpads, the T440 and the X270).
Debian is for people who want to configure a server once and have it stay running and secure.
"Stability" in Debian's context means _version_ stability, not that it doesn't crash. I think most Linux distros aim to not crash.
Indeed, I moved to Fedora and I haven't looked back.
I was already using RHEL and CentOS (later Rocky Linux) on servers, I guess it's bye-bye time for Debian.
> Debian is for people who want to configure a server once and have it stay running and secure.
The same could be said for RHEL and most of its derivatives though.
Of course in theory they could also try to backport the changes, but I doubt anyone would bother for anything that’s not hugely popular. I’m tired of distro patches generating support load anyway.
Have the maintainer do stable/oldstable updates when backwards compatibility is broken.
Have the package removed from Debian stable/testing and have it only in unstable and the new fastrack.debian.net repo.
True. And yes, Debian stable packages do not work so well if a package needs to undergo frequent updates. As others have pointed out there are work arounds in place - like backports. Or if you want a Ubuntu / Arch like experience, you could try Debian testing. But they are kludges and for some packages the pain got so great Debian was forced to brake it's own rules and pushes new version into stable. But that's rare - Debian stable is so popular because it's stable.
The underlying reason for that focus seems to be Debian is a distribution put together by sysadmin's. A large chunk of the DD's (Debian Developers) are sysadmins pooling their resources to produce a distribution they can use in their day job. The two things that matters to them are security and stability. It's not an accident that Debian led the way on reproducible builds. This mob really cares about rock solid and secure.
To me Debian model of "sysadmin's pooling their resources" is remarkable. It's one of the few open source driver projects that combines open source and commercial objectives. At its heart is a whole pile of people teaming up in an open source project to create a tool (a server OS) they base their respective (and disparate) commercial products. The open nature of Debian - it's ethos, it's transparency, is critical to why this works so well. It allows the participants who might well be producing competing products to trust each other, and continue to work along side it other for decades now to produce a distribution. It also means it's always going to have a strong server focus.
That focus doesn't mean not to say Debian can't be used for a Desktop. A stable base like that is a very attractive thing to build a desktop on, and that's what happened. It's my daily driver, and I think it works wonderfully - but I also hand install some things from outside Debian (like youtube-dlp), and make liberal use of docker containers when I need to pin certain versions for development. It's a bit of work - but as a developer it's stuff I have to do anyway. It created an opportunity to create a derivative that caters to the desktop users who aren't like me and just want the latest shiny - and Ubuntu stepped into it.
In which case was it an actual problem for you? What about switching to testing or unstable?
In my case I like to mix stable with a few packages from testing / unstable if needed. The current stable is relatively recent, so right now I just have golang from testing for instance.
I agree with the sibling comment that it's more of a feature: it's more efficient for me to work around the bugs / missing features of packages that won't be update for a while and stick to these workarounds, rather than constantly adapt to new bugs (even if old ones are fixed) or to changing features.
It's not just a modern thing. For no other platforms are application versions so tightly coupled with the OS version. Mac or Windows users would tell you to take a hike if you tell them they can't usually get new software without upgrading their OS. Similarly Android apps typically target somewhat older platform API versions to support users who have not yet upgraded to the latest base system.
If Debian shipped version n and the upstream fixes the vulnerability in version n+5 (not unusual, as debian stable is routinely out of date for 2-4 years depending on the length of the testing freeze and the point in time of the stable lifecycle), this can range from trivial to near impossible in a timely manner.
They also tend to be opinionated about the software they ship and do include many Debian-specific patches. Most of them are harmless or just small changes to make the software work better with the Debian way of configuring things; sometimes much more catastrophic: https://github.com/g0tmi1k/debian-ssh
For desktop use, distros like Fedora strike a decent balance in my opinion, being much more up to date without sitting on the bleeding edge and usually updating without issue.
If I want the latest version of a service app, I check for a Docker container and run that. If it's a CLI tool, I'll check for an apt repo, or build it from source then copy it to /usr/local/bin/.
I feel like I'm getting the best of both worlds: a rock-solid OS, and with a tiny bit of effort I can run the newest version of any tool I want. By not doing this systematically on every single package in the OS, there's little risk of breakage.
Which is why it's so important that you have multiple choices. If you need the latest packages, use Arch. If you need stability over multiple years, use Debian.