Lucky 13: A Look at Debian Trixie
Original: Lucky 13: a look at Debian trixie
Key topics
Debian's stability is a double-edged sword - while it's a blessing for servers and corporate users, some argue it's a curse for desktop users who crave newer features. Commenters weighed in, with some like scbrg and pmontra proudly declaring themselves "stable package users" who don't need the latest and greatest, while others like trabant00 lamented the lack of a server-focused review. The discussion revealed a nuanced divide, with some pointing out that corporate users often rely on containers or VMs to manage development environments, and others suggesting that atomic distributions could be a solution. Amidst the debate, a surprising consensus emerged: many users value stability over bleeding-edge features, and Debian's approach is perfectly suited to their needs.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
5h
Peak period
63
0-12h
Avg / period
9.7
Based on 107 loaded comments
Key moments
- 01Story posted
Aug 28, 2025 at 9:55 PM EDT
4 months ago
Step 01 - 02First comment
Aug 29, 2025 at 2:27 AM EDT
5h after posting
Step 02 - 03Peak activity
63 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 3, 2025 at 12:46 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
You're obviously correct here. But perhaps there are users who prefer stable packages on the desktop too. Corporate users most likely (yes, there are such users too). It helps with their security strategy and a development environment similar to their server.
To be very honest, I think the stable security-oriented approach is better than that of a rapid update distro. You should probably use an overlay package manager like flatpak, mise (for dev tools) or even Nix/Guix for anything modern. Preferably something with minimal installs and good sandboxing features. Please let us know if anybody has better suggestions to offer.
It's a tricky thing to solve. One the one hand, you don't want your system to stop working due to an update but also want to keep the software you use updated, both in terms of security and functionality.
Mark Shuttleworth talked about this many years ago before snaps were introduced as a solution to this. The idea at the time was that a rolling release distro is too much of a hassle to maintain and even the 6-month cycle was getting to be too much. So he talked about having a stable core with a long release cycle and rolling releases for software that need to be frequently updated, both desktop and server software. The idea was great but the details of the execution left a bitter taste for many users.
The only problem I had on Debian 11 desktop was related to the new openssh libraries. I could not install the latest nodes and rubies because 11 had older libraries. However there are workarounds related to providing some environment variables (from memory: some legacy_providers_*) so after a little googling I made them work on my dev machine (and on some old server from a customer of mine.) I'm installing Debian 13 in these days so no more workarounds, for a few years.
Everything else worked fine. I don't install much on this machine: no flatpacks, no appimages, no snaps (I left Ubuntu because of them.) Only debs and docker images. I install languages through their language manager, never through the OS: I could have only one version of them, which is useless. Same about databases. There are hardly two projects on the same language and db version. I could be using LibreOffice and GIMP from 20 years ago: they already had all the features I need.
I like to build things which last. I like to craft a software system and then use it for decades, moving it from machine to machine and intentionally upgrading the components at my pace.
I don't understand why people like the rigmarole of constantly updating their systems. The only things that come down the wire are security updates.
Installer newer software can be managed. I use the following strategy:
- For Discord / Slack / <something that needs to be the newest>. I can normally use Flatpak.
- Use a third party repo. For Brave, Node and some other things. I use their repository.
- Open source stuff. For smaller stuff that is easy to compile from source e.g. vim / neo-vim I just compile from source so I have the newest versions.
- Python Apps / NPM tooling. I install them in my local user directory.
- Docker is installed in rootless mode.
My reasoning is quite simple: I really don't need the latest versions of everything. Were computers useful two years ago? Yeah? OK then, then a computer is obviously useful today with software that is two years old. I'll get the new software eventually, with most of the kinks ironed out. And I've had time to read up on the changes before they just hit me in the face.
Sure, it was a bit painful with hardware support some twenty years ago or so, but I can barely remember the last time that was an issue.
For the very few select pieces of software where stable doesn't quite cut it there's backports, fasttrack and other side channels.
>> You're obviously correct here.
It's neither obvious nor correct, the "stability vs. features" expected is completely subjective. I run Debian Stable on my desktop because I've almost never encountered needing newer versions of anything, and when I did I could usually jump to testing (i.e. the upcoming release) rather than unstable, and even then the next release usually wasn't that far away, so it was still very stable.
As other commenters have pointed out, you can run Debian Sid (unstable), but I'll also agree that if that is what you want long-term then maybe running something like Arch makes more sense anyway.
You don't want to use RAM for tmp files for which you probably can't do capacity planning, and you don't to enable swap on server either.
I sometimes manually changed the /tmp to be in memory, or used /dev/shm which by default is in memory. Did not run into any problems just yet, but then again it's just a home server.
That's why I use rolling release distributions on my Desktop. For Debian, people recommend Debian testing usually. And that's fine. Maybe they should just call it Debian rolling releases and rename stable to Debian LTS. I think it's more appropriate to how people actually use these things.
Manjaro is not without issues but I've had it on one of my laptops for the last four years and it's nice to have the latest driver updates, kernels, etc. working together. It also helps that the community is just focused on current versions of stuff and fixing minor integrations with released packages rather than working around issues in some long forgotten release with distribution specific patches, etc. You find relatively little of that in Arch (which underlies Manjaro).
For production servers, the server just needs to boot my docker containers and get out of the way. IMHO There's no need to support > 10K packages for god knows what there. Most of that stuff probably has no business being installed on a server. I'm actually leaning towards immutable distributions and servers for that reason. The business of manually fiddling with servers in a production environment is something I'm trying to avoid/do less off. They shouldn't need a package manager if they are properly immutable.
Was bummed to see firefox at version 128 as I've been missing features from the more recent versions. I don't know how I'm going to address that yet as I prefer not to add external apt sources, if I can. This is on a desktop system so somewhat recent versions of software is desirable.
What do other people do for desktop systems? Go with testing/unstable or just another distro for desktops?
Heck, I use Fedora Server as my homelab OS to run Incus. Works For Me.
In your case I guess it makes sense since you have to run Fedora at work, but I was under the impression that the support for Incus (i.e. official packaging etc) was better on Debian.
I did not use the Firefox coming with 11 and I won't use the ESR version in 13. I downloaded the deb from Mozilla's site once and it autoupdated itself up to the current version. No problem at all. I'll do the same on 13.
I trust Debian, and I trust the Debian Firefox team to secure Firefox, but I do not trust Mozilla.
You can tell apt to prefer a given source list only for a few packages.
It’s a fair move to minimise the risk, so I’ll be pinning on my system if it’s not already, but it won’t make a whole world of difference if the remote actor starts misbehaving. The other alternative is to disable automatic updates entirely and hope the version you’re pinned to is okay, but vulnerabilities in browsers are common, that’s basically what LTS is for anyway.
I believe that is because Debian ships Firefox "Extended Support Release" (ESR) as a security precaution, and the firefox-esr package[1] is quite out of date in absolute terms.
If you want the newest Firefox (not ESR), just add Mozilla's own repo instead: https://blog.mozilla.org/en/mozilla/4-reasons-to-try-mozilla...
[1]: https://packages.debian.org/trixie/firefox-esr
(mainly, it was the fact that the installer finally included firmwares out of the box which made installing much, much easier on laptops)
Because i want updated packages, the first thing i do is enable backports (otherwise i think that trixie still comes with kicad 5? hugh!) and do a full upgrade.
as for firefox, debian's repositories use firefox esr, which is why you are still on 128. There are instructions on firefox's site on how to switch to the regular release channels, just do that. If you can't trust firefox's own sources i don't know how you can trust debian's.
Debian + KDE is my favourite combo. I don't do anything different for desktop. When there was the debian 13 freeze i simply waited a couple of days, edited the sources to point at trixie and did a full-upgrade and an autoremove to clean old stuff. That's it.
I don't consider outdated packages to be a problem on any distro because I just use Nix (which doesn't interfere with other package managers) whenever I want a more recent package.
You can however get all stability of a released version with newer packages if you use stable+backports. This would give you a stable system, and allow you to upgrade selected packages to newer versions. This can be tedious, so running testing is also possible.
And well, overall, you can also install other distributions that are bleeding-edge (Arch based?). That's why I like about the distro ecosystem :)
Protip: don't use Pacman directly, just use 'yay' which comes with EndeavourOS. Yay is an interface to Pacman, now while it may sound silly, its totally worth its salt. I'm probably still on Endeavour because of yay.
In order to update your system just type 'yay' into a terminal and it does the work prompting you for confirmation.
If you want to install anything its as simple as 'yay packagename' and then it gives you options, including from the User repos (AUR) which are like Ubuntu's PPAs.
I spent probably 15 years on Debian / Ubuntu (though it mostly became Ubuntu even for servers, I got too used to Ubuntu over the years). I installed Arch this past year because I wanted more up to date packages, I didnt want bleeding edge, but it hasn't been so much bleeding so I'm okay with it. I update every few days, or when Discord decides to tell me to download the DEB package or it wont open.
I’ve had more trouble and time wasted with snap Firefox than I’ve had with official Mozilla repos under both Debian and Ubuntu.
This is why I stopped using Debian on the desktop. Now I use Fedora KDE (Kinoite, to be specific) and get updates very quickly. Highly recommended!
Occasionally I'd find myself having to manually fix dependencies, but for the most part it worked great for me. I don't bother now, since it's rare that I want something newer than what backports can give me and I'm not adverse to compiling my own stuff if I need to.
I solved all of the above by switching to the NVidia Cuda repo (well, I did not reenable Secure Boot, so not sure if that would work now).
https://backports.debian.org/Instructions/
If I'm not mistaken, repo is already included by default, so you just need:
''' # apt install -t trixie-backports <package> '''
This will install backported package _and_ dependencies, so you will be good to go :)
[0] https://www.ebay.com/str/evolutionecycling
[1] https://linuxmint-installation-guide.readthedocs.io/en/lates...
been running "unstable" since 2007 as my daily driver, work-horse, dev-machine, ... Not once faced a "problem" I couldn't recover from. Not once a restore from backup of the main OS due to something the upgrade or OS had caused, no booting from a rescue-image. For something that comes without warranty and has "unstable" in it's name, it's pretty solid.
Apples and oranges of course, but it holds up also well compared to Windows (which tbf, has gotten more stable since Win98), or even compared to MacOS that also crashes at times even after version MacOS 9.x (which was when MacOS became usable in the sense of "stability").
It's just old ideas that get repeated even once they stop being true.
Debian release cycles have a strong focus on stability, and for those situations where it matters, like running a production server, that is a pretty important feature. Just because your desktop never broke doesn't mean it's not "unstable", it's more of a disclaimer that if you put serious things on top of it and it breaks, that's much more on you because you chose to go against maintainer advice.
For me personally, with exception of the Enterprise Linux family (Alma, Rocky etc.), there's no Linux distribution I'd rather run on a workhorse, production, long term deployment server than Debian.
I’ve had a few instances of X not starting, over the years. Nothing terrible, and that’s as much down to me using nvidia cards as anything.
There’s a small number of packages unavailable in Deb 13 that exist in 12. I assume at some point all of them existed in pre-stable trixie.
I stopped running sid not because of any instability or unreliability in the included programs themselves but because unstable required more active administration: apart from temporarily broken dependencies or upgrade paths, it made sense to stay informed on potential breaking changes. Stable(r) releases or distros rarely require almost any active care nowadays apart from installing security updates.
Again, my experience with sid was years and years ago but I don't suppose its fundamental nature as the active development branch has changed.
To be fair, sid had various bugs leading to unbootable systems since then. While it's possible to recover in such situations without re-installation or data loss, I believe that makes the term "unstable" quite fitting.
From https://groups.google.com/g/bbr-dev/c/i-sZpfwPx-I/m/0jmNry0A... :
> To make sure we're all on the same page: currently the TCP BBR code in Linux is BBRv1. We are working on getting BBRv3 upstream into Linux TCP.
> BBRv1 is definitely not ready to be the default on any Linux distribution. Whether BBRv3 is ready to be a distribution default is arguable.
I'm running somebody's rebase tracking things. 6.13 I believe. Worked on one box, not on another. Oh well. Doubly irritating is that the sysctl only flags bbr not which version.
Come on guys, Debian 13 has been in testing for months, and you can't be arsed to update your apt repos from bookworm to trixie by release, or even weeks after release? That's embarrassing.
These apt repos are still bookworm-only after the trixie release, and it's been weeks. And Cloudflare is still stuck on SHA1.It's not like the Debian release schedule is a secret, I suspect there's just less corporate pressure to prioritize Debian.
Realistically I can live on X11 outside of my dual monitor setup and that one application, but things get very choppy with mixed refresh rates. Still not the biggest fan of Gnome, but if I'm using deskflow only Gnome or KDE support the input sharing portal on Wayland.
At least google's got you covered, if you simply ask nicely:
Another useful thing from the article for me was `apt modernize-sources` to update the existing sources.list to the new structure. Now I need to check if scripts like this run automatically on my auto-updating desktop from my parents.
[0]: https://packages.debian.org/trixie/extrepo
What I lack with the "modern" `sources.list.d/` file schema is a command to perform common types of edits. Something like `extrepo` but generic and with knowledge of Debian repos/dists. It's a small thing but I want to be able to type commands like
Perhaps `extrepo` would be extended to include Debian-proper or this hypothetical `apt-sources` would be kept Debian-repo-only or perhaps it would cover extrepo's scope.Would it really be so hard to make that switch to a more privacy focused umask?
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269583
With Trixie, PAM's "User Private Groups" are by default enabled and default umask thus is 002 instead of 022.
(Personally, I'm irritated by the rather silent way this invasive change got introduced -- it is mentioned in /usr/share/doc/libpam-modules/NEWS.Debian.gz together with instructions to restore the old behavior.)
Yes, yes, we all run Postgres in containers, but if you don't, and you upgrade to a new Postgres major version, gladly using the Debian scripts that make it all more comfortable, while using umask 027, you will enjoy your day. Though I don't remember if those upgrade-scripts where from Debian proper or from Postgres.
Since that experience I always wondered what other tools may have such bugs lurking around.
The Libreoffice 5.8 (which was just released very recently) is already packaged in backports for trixie for instance. Did things like updated KDE desktops make it to backports for bookworm?
If only :(
https://packages.debian.org/bookworm-backports/kde/
TIL. What a superpower!
the main reason i always fall back to Ubuntu is bc everyone has a PPA for it. Sometimes the PPA also works for Debian, but its 50/50 (from what i understand its not an official thing under Debian?)
AppImages have aleviated this.. but appimagelauncher is broken under Ubuntu and theyre annoying to integrate manually
Generally, these are repos maintained by the upstreams themselves, e.g. Docker, Tor, Armbian, Dovecot... my guess (and it's just a guess, I haven't used Ubuntu PPAs much lately) the PPAs are maintained by not-the-upstreams. Or perhaps some of the upstreams are maintaining both a PPA and their own hosted repo.
However, trying the specific example that was listed in the article, I installed extrepo and enabled the mozilla repo. Unfortunately, firefox is not installable on trixie in it's current form because it depends on libasound2 and the trixie package is called libasound2t64. : (
It should definitely work with an 'apt install firefox' from the cli - perhaps you're using a different package management frontend? If so, installing libasound2t64 first should force it to see the virtual package - but it might be worth filing a bug report as this really shouldn't require manual intervention...
This repo has a list of extrepo stuff - https://salsa.debian.org/extrepo-team/extrepo-data/-/tree/ma...
> deb-get makes it easy to install and update .debs published in 3rd party apt repositories or made available via direct download on websites or GitHub release pages.
https://github.com/wimpysworld/deb-get/
In particular, the list of software is a bit longer than extrepo (e.g. includes zoom):
https://github.com/wimpysworld/deb-get/blob/main/01-main/REA...
> Truly adventurous users may take their chances with the unstable ("sid") release.
It's been years since I've run Linux as a daily driver, but when I did it was Sid, and it didn't feel particularly adventurous. Over a 10-15 years timespan, I think there were 2 breakages, one of them being the difficult KDE 3.x transition.
I've long meant to try Fedora, but apt/dpkg is in my muscle memory, and I never got the handle of dnf/rpm.
One of the features I'm most excited about is access to Podman 5.4.2, and the ability to use Podman Quadlets. It'll be nice to start transitioning my systemd service units over to the new format for my containers.
I tried the 580 bundle with the same problem. I had to revert to the 535 bundle.
[1]: https://forums.developer.nvidia.com/t/nvidia-555-58-4k-120hz...