I was browsing through the issues of extrepo and found deb-get, seems pretty useful too:

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

I learned about extrepo when trying out LibreWolf. Then I realized theres plenty of stuff on extrepo I could install. No more curl installs or third-party package sources for me mostly.

This repo has a list of extrepo stuff - https://salsa.debian.org/extrepo-team/extrepo-data/-/tree/ma...

I was thrilled to learn about this, too. I wasn't aware of it even as a long-time Debian user.

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

what's the difference with PPAs?

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

Does it enable access to software-properties-common?

Back when I wanted new packages, I ran Debian unstable.

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 work in the refurb division of an ewaste recycling company[0]. Due to the certifications we have (and the lack of MS licensing), we can't install Windows on anything we sell. I started off installing Debian on things I list, but switched to Mint. I've fallen in love with the OEM install option they have[1]. It sets up a pre-OOBE environment, letting me run things like fastfetch to get the system specs, then click the 'prepare for shipping to end user' command to trigger the user and password setup on next boot (so I don't have to set and write a password on a postit note on the laptop, and hope it doesn't get lost).

[0] https://www.ebay.com/str/evolutionecycling

[1] https://linuxmint-installation-guide.readthedocs.io/en/lates...

> bummed to see firefox at version 128

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

I tried debian several times over the years, but it was with bookworm (debian 12) that i decided to make the switch on all my PCs and laptops, macbook included.

(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've been happy with Fedora for my personal systems, and it's the only blessed distro at work for those who don't want Windows or Mac.

Heck, I use Fedora Server as my homelab OS to run Incus. Works For Me.

You can always work with backports! It's the way Debian has to bring more recent packages to older stable versions.

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 :)

if you want a newer firefox use flatpak, don't pollute your system with unofficial debs or source installs

I prefer to install Firefox directly from the Mozilla. I’ve had too many issues with the Debian ESR version being too far behind the mainline in features.

You can manually install Mozilla's Linux binary and it will update itself as on other platforms. I've been doing this since the Iceweasel days and it's always been solid.

I've been on Debian 11 for a few years and I'm installing 13 on another disk (dual booting until it's ready for my job.)

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 see testing as a better fit for general-purpose desktop setups, stable is a bit too conservative in that regard.

Firefox 140 ESR was released this month. I expect Debian will publish an update to it soon.

>This is on a desktop system so somewhat recent versions of software is desirable.

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!

Same here. Only stick up is that for those with NVidia GPU's (yes...) for some reason the kernel headers don't install when you install the driver, plus the secure boot signing simply does not work (Ubuntu, Fedora, they all manage OOTB). I see it is generating MOK stuff, but it does not work. Because of that, it's pretty hard to troubleshoot. Plus, Debian-provided drivers do not work/enable at all on Optimus machines, and not a single option (I tried them all, except those no longer available) on the Debian wiki. (Let's hope the Arch colab works out.)

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

> apt modernize-sources

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

    apt-sources available # prints known dists, marked by their support status
    apt-sources list         # prints all active dists
    apt-sources add trixie   # or "testing", "unstable", "sid"
    apt-sources remove bookworm
    apt-sources dist-upgrade # combo of the previous two

> Did things like updated KDE desktops make it to backports for bookworm?

If only :(

https://packages.debian.org/bookworm-backports/kde/

Anyone happen to have a good primer on these? Have been around a decade or two but I know almost nothing about them.

You are explictly requesting the bookworm versions, I'm not sure what you're expecting?

At least google's got you covered, if you simply ask nicely:

  $ curl -s https://packages.cloud.google.com/apt/dists/cloud-sdk-trixie/InRelease | grep -E Suite:\|Date:
  Suite: cloud-sdk-trixie
  Date: Wed, 27 Aug 2025 18:45:14 UTC
  $ curl -s https://packages.cloud.google.com/apt/dists/google-compute-engine-trixie-stable | grep -E Suite:\|Date:
  Suite: google-compute-engine-trixie-stable
  Date: Mon, 25 Aug 2025 21:24:03 UTC

The Nvidia CUDA repos are still on Debian 12 as well which was a blocker for me. (Some claim it works fine anyways, but not in my experience.)

It's not like the Debian release schedule is a secret, I suspect there's just less corporate pressure to prioritize Debian.

Because in June 2005 the simple response to the Debian bug filed in September 2004 was to comment the global setting out of /etc/login.defs rather than change it to 0027. And after some back and forth there's now the explanation in /etc/login.defs that you can read today (q.v.).

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269583

Yeah, the distro for "Truly adventurous users" has never broken in a decade of use by myself and is essentially as bleeding edge as Arch.

It's just old ideas that get repeated even once they stop being true.

> been running "unstable" since 2007 as my daily driver, work-horse, dev-machine, ... Not once faced a "problem" I couldn't recover from.

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.

Well with a lot of packages, including from 3rd party repos, and only seldomly doing upgrades, one can get pretty stuck in resolver hell.. of course, noone to blame for the frankendebian approach but myself xD

Never been a Sid user (occasionally for specific packages) but I do find articles like these amusing - for me the transition from testing to stable is usually where I say goodbye to a Debian release. So farewell Trixie! Onto forky I go.

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.

Isn’t it also unstable in that packages may be removed or updated which could break your workflows?

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.

Long term usually equates to a bit stale/out of date with distributions that only release every few years. Appropriate for stuff you don't really care about.

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.

> On the desktop though they are a bit too stable.

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.

Indeed, with the tmpfs move (tmp in RAM) however it sounds like they have more Desktops in mind.

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.

As far as I know, BBR3 is not in the mainline Linux kernel, so obviously it will not be in Debian by default.

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.