Writing this from my Debian system, it's a great distro that has been excellent to me as a daily driver. I switched to Debian 6 after Ubuntu went way downhill and haven't had cause to regret it.
I like Debian's measured pragmatism with ideology, how it's a distro of free software by default but it also makes it easy to install non-free software or firmware blobs. I like Debian's package guidelines, I like dpkg, I like the Debian documentation even if Arch remains the best on that front. I like the stable/testing package streams, which make it easy to choose old but rock-stable vs just a bit old and almost as stable.
And one of the best parts is, I've never had a Debian system break without it being my fault in some way. Every case I've had of Debian being outright unbootable or having other serious problems, it's been due to me trying to add things from third-party repositories, or messing up the configuration or something else, but not a fault of the Debian system itself.
>I've never had a Debian system break without it being my fault in some way.
Debian is great but I can't say this is a shared experience. In particular, I've been bitten by Debian's heavy patching of kernel in Debian stable (specifically, backport regressions in the fast-moving DRM subsystem leading to hard-to-debug crashes), despite Debian releases technically having the "same" kernel for a duration of a release. In contrast, Ubuntu just uses newer kernels and -hwe avoids a lot of patch friction. So I still use Debian VMs but Ubuntu on bare metal. I haven't tried kernel from debian-backports repos though.
> Debian's heavy patching of kernel in Debian stable
Needs citation.
Debian stable uses upstream LTS kernels and I'm not aware of any heavy patching they do on top of that.
Upstream -stable trees are very relaxed in patches they accept and unfortunately they don't get serious testing before being released either (you can see there's a new release in every -stable tree like every week), so that's probably what you've been bit by.
These days all of my “Debian” bare metal systems are technically running Proxmox, which I think is a relatively happy medium as far as the base Debian system goes — the Proxmox kernel is basically the Ubuntu kernel, but otherwise it’s a pretty standard Debian system.
I’ve thought about (ab)using a Proxmox repository on an otherwise stock Debian system before just for the kernel…
The upstream kernel already backports enough regressions on its own to its stable releases, Debian's kernel team does not help them too much with that.
Yeah, I ditched Ubuntu Server after too many upgrade headaches. I manage 75+ VPS instances for app hosting, and it's nerve-wracking doing maintenance updates knowing there's a chance one won't boot after. That's easily an extra 1-2 hours per VPS just to get it back. Switched to Debian back in the 8.x days in 2015 and it's been smooth sailing. Never had it break unless I was the one who messed it up.
Me too. All the server software (postgres, caddy, bun, etc) I'm using runs just fine on Debian, and I never have had updates break something on my Debian servers.
The only thing I can say against Debian is that it tends to start new server software immediately after install, before I have a chance to configure it properly. Defaults are sane for most packages, but, still, it scares me a little. In that I like the Red Hat approach of installing and leaving it off until I decide to turn it on.
Just have sane firewall rules and you are good. E.g. if I install openssh-server and it auto starts, it doesn't make it out of my machine because my nftables does not allow inbound on port 22. It's just knowing the default behaviour and adjusting your practices for it.
> And one of the best parts is, I've never had a Debian system break without it being my fault in some way. Every case I've had of Debian being outright unbootable or having other serious problems, it's been due to me trying to add things from third-party repositories, or messing up the configuration or something else, but not a fault of the Debian system itself.
You're not trying hard enough ;-)
I have Debian on an old MacBook Pro and had it on an even older iMac, and I've had a few problems over the years. Always with proprietary drivers - WiFi, graphics, webcams, etc. - Apple really don't want people using free software on their hardware. There's always been a fix, but there have been a few stressful moments and hoops to jump through.
But it's definitely my favorite distro, and I run it everywhere I can. Pretty much always "just works" anywhere but Apple.
For me, it was a combination of Ubuntu breaking upstream and introducing its own unnecessary systems.
I had a few issues caused by Ubuntu that weren't upstream. One was Tracker somehow eating up lots of CPU power and slowing the system down. Another was with input methods, I need to type in a pretty rare language and that was just broken on Ubuntu one day. Not upstream.
The bigger problem was Ubuntu adding stuff before it was ready. The Unity desktop, which is now fine, was initially missing lots of basic features and wasn't a good experience. Then there was the short-lived but pretty disastrous attempt to replace Xorg with Mir.
My non-tech parents are still on Ubuntu, have been for some twenty years, and it's mostly fine there. I wouldn't recommend it if you know your way around a Linux system but for non-tech, Ubuntu works well. Still, just a few months ago I was astonished by another Ubuntu change. My mom's most important program is Thunderbird, with her long-running email archive. The Thunderbird profile has effortlessly moved across several PCs as it's just a copy of the folder. Suddenly, Ubuntu migrated to the snap version of Thunderbird, so after a software update she found herself with a new version and an empty profile. Because of course the new profile is somewhere under ~/snap and the update didn't in any way try to link to the old profile.
Then there were stupid things like Amazon search results in the Unity dash search when looking for your files or programs. Nah. Ubuntu isn't terrible by any means but for a number of years now, I'd recommend Linux Mint as the friendly Debian derivative.
I forget the exact context but I recall an Ubuntu dev stating they have more users of the Firefox snap alone than trendy distros have entire users.
I think it’s worth keeping that in mind with all the hate Ubuntu gets. Most users are just silently getting their work done on an LTS they update every two years.
I'm an old-school user so I'm not exactly Ubuntu's target audience, but for Ubuntu was bad about a lot of the older, lesser-used bits of Linux.
The two things I can remember were problems with NFS out of the box (outside having to install nfs-common, which I'm fine with) and apt-cache not displaying descriptions of packages. There were lots of other, minor annoyances that affected people like me but wouldn't affect someone who got into Linux desktops after, say, 2010. My memory sucks though so those are the two I remember. Yes, there were bug reports filed and yes, they sat in the tracker for years with no attention from Ubuntu.
I wound up back on Debian once I got old enough that I didn't care about being behind the times a couple years.
> I like dpkg, I like the Debian documentation even if Arch remains the best on that front.
That's curious, because when I was learning to make Debian packages, I found the official documentation to be far better than I had seen from any other distro. The Policy Manual in particular is very detailed, continually improving, and even documents incremental changes from each version to the next. (That last bit makes it easy for package maintainers to keep up with current best practices.)
Does Arch have something better in this department?
Are you perhaps comparing the Arch wiki to Debian's wiki? On that front I would agree with you.
You weren't around for when they broke the OpenSSL random number generator for no good reason. That was back in 2008 and it created vulnerabilities that persist to this day. https://16years.secvuln.info/
I still use Debian but it's hard to forget stuff like that even after all these years.
Though I agree with you, if that's the bar you're setting then Debian comes out far ahead of any other OS that I've ever used - Linux based or not. I can recall dozens of worse Windows bugs, most of which did not even affect me because I was not using Windows at the time. Mac has its share too.
> I like Debian's measured pragmatism with ideology
There is plenty that could be said of Debian but as far as I’m concerned that’s not part of it.
Debian patches software for purely ideological reasons because they think they are not free enough. That’s not pragmatism. That’s the reverse of pragmatism. It certainly is a real drag on the teams developing the software they try to ship.
> I've never had a Debian system break without it being my fault in some way.
My experience has been contrary to that. I'm a Linux user of 25+ years
with various distros but about half of that time with Debian as my
main desktop. I broke up with Debian about ten years ago thinking we
could still be friends, but every time I've tried to put it on a new
box it since then something weird has happened, most recently about a
month ago on a completely new Intel N150, when it gave me some stick
about video modes. Today my laptop got hosed by an attempted upgrade
from bookworm to trixie, as in tons of error messages and then no more
docker and no more virtualbox. No harm done because Debian taught me
long ago to store a copy of the whole root filesystem on external
media before an upgrade, but now the clock is ticking until I have to
migrate off it or get stuck with something too old to be compatible
with anything.
I've been always a Fedora person, still am. But my PC moved to Proxmox (debian) in 2023. Now a Fedora Atomic sits in a VM running flatpaks and podman containers :D
I think this is all true, but the "being my fault" part has gotten better for me with nixos. Broke it? just reboot into the previous version and get configuration.nix back from git. I had to reinstall exactly once in 2016 shortly after the first install, but I don't know what I did wrong. the third time I installed nixos was last week when I bought a new computer that came with Windows.
You don't mention say what you like specifically about Debian, most of what you wrote could be said for a lot of distributions.
So here is what I _don't_ like about Debian :-)
- I don't like Debian package tooling (dpkg, debootstrap, de build...). Actually I hate everything about the experience of Debian packaging. Every time I package for Debian, I end up with a messed up setup of chroots and have to make triple sure nothing leaked from my environment.
- Debian has a habit of repackaging everything at their own sauce, disregarding upstream philosophy. Debian packages will have their own microcosm of configuration directories, defaults, paths, etc. orthogonal to what a pristine installation look like.
- Debian has the annoying habit of default starting installed services. So you always have to dance around your configuration management to disable services, install them, configure them, then restart them.
Thank you to all the Debian volunteers that make Debian and all its derivatives possible. It's remarkable how many people and businesses have been enabled by your work. Thank you!
On a personal note, Trixie is very exciting for me because my side project, ntfy [1], was packaged [2] and is now included in Trixie. I only learned about the fact that it was included very late in cycle when the package maintainer asked for license clarifications. As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). I approached the maintainer and just recently added build tags [3] to make it easier to remove Stripe, Firebase and WebPush, so that the next Debian-ized version will not have to contain (so many) awkward patches.
As an "upstream maintainer", I must say it isn't obvious at all why the web app wasn't included. It was clearly removed on purpose [4], but I don't really know what to do to get it into the next Debian release. Doing an "apt install ntfy" is going to be quite disappointing for most if the web app doesn't work. Any help or guidance is very welcome!
> The webapp is a nodejs app that requires packages that are not currently in debian.
Since vendoring dependencies inside packages is frowned upon in Debian, the maintainer would have needed to add those packages themselves and maintain them. My guess is that they didn't want to take on that effort.
Debian sources need to be sufficient to build. So for npm projects, you usually have a debian-specific package.json where each npm dependency (transitively, including devDependencies needed for build) needs to either be replaced with its equivalent debian package (which may also need to be ported), vendored (usually less ideal, especially for third-party code), or removed. Oh, and enjoy aligning versions for all of that. That's doable but non-trivial work with such a sizable lockfile. If I would guess the maintainer couldn't justify the extra effort and taking on combing through all those packages.
I also think in either case the Debian way would probably be to split it out as a complementary ntfy-web package.
> As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine).
My advise to you is to deny all support from people using the Debian version of your software and automatically close all bug tickets from Debian saying you don’t support externally patched software.
You would be far from the first to do so and it’s a completely rational and sane decision. You don’t have to engage with the insanity that Debian own policies force on its maintainers and users.
I agree that maintainers should not be expected to support patched versions of their software, but as a user I like the Debian policies you call insane. I would actually pick Debian exactly because they are cautious with the dependencies.
Debian has been the stable footing of my Free computing life for three decades. Everything about their approach — from showing me Condorcet, organising stable chaos, moving forward by measured consensus, and basing everything on hard wrought principles — has had an effect on me in some way, from technical to social and back again.
I love this project and the immeasurable impact it has had on the world through their releases and culture.
> i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU. Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware.
Impressive that i386 support made it all the way to August 2025. I have Debian 10 Buster running on a Pentium 3 which only EOL'd last year in June 2024. It's still useful on that hardware and I'm grateful support continued as long as it did!
OpenBSD still supports i386 for those looking for a modern OS on old 32-bit hardware.
Hopefully i386 (or perhaps a new i386-like port with added support for 64-bit time values) can move to the unofficial Debian Ports infrastructure for Debian 14 (forky) or Debian 15 (duke). Debian Ports has a m68k port, so supporting one for i386 shouldn't be a huge problem.
To what end? Outside of sheer nostalgia if you are running ancient hardware, you probably have a bespoke application which requires that environment. Either you cannot change for hard technical, compliance, or just fear of the unknown. Firewall it from the internet and continue to run whatever release last worked.
I am not happy about unnecessary ewaste, but an i386 almost certainly has and order of magnitude less horsepower than a raspberry pi or N100.
The i386 architecture hasn't been dropped, it is still available in the archives to support 32-bit applications. The major change is that there no longer is a 32-bit kernel in the archive (the package linux-image-686 is no more). But most packages are still available in their i386 versions:
When distros mention i386 support they often actually refer to i586 or i686, yes.
True i386 support would mean compatible with the original Intel 386 processor from 1985. The 486 added a few additional instructions in 1989 but things really changed with the Pentium in 1993 - that gave us i586 which is the bare minimum for most modern software today. Much software can still run on regular Pentiums today if compiled for it, but SSE2 optimizations requires at least a Pentium 4 or Core CPUs instead.
I play with retro PCs often and found OpenBSD's i386 target stopped supporting real 386 CPUs after the 4.1 release, and dropped support for i486 somewhat recently in 6.8. It now requires at least a Pentium class CPU, i586, though the arch is still referred to as i386 likely because it's a common proxy for "32-bit".
Linux ran fine on 386 chips - that was actually what it was originally developed on. But Intel added a bunch of functionality in the 486, Pentium, and Pentium Pro chips. At some point the powers that be didn't see any value in continuing to support pre-P6 chips anymore.
It was a bit of a strange decision since there were undoubtedly more 386, 486, and Pentium users than some of the platforms Linux continued to support, but that's the choice they made. But they weren't alone. Even NetBSD requires a 486DX or better.
Yep! I did some testing and found 6.8 was the final version to support 486 CPUs. The reason is the OpenBSD project switched to clang for the compiler in 6.9, and in the process became dependent on Pentium instructions.
However, that doesn't stop one from installing a Pentium Overdrive in an old Socket 3 board and running the latest release. ;)
Hahah yeah, it's just a for fun/hobby PC. It's pretty beefy for what it is - 1.3GHz, 512MB RAM, 512GB SSD on a SATA card, fast AGP card. I can run a Debian desktop at 1080p on here.
There is a weird depends you cannot get around without simultaneously removing and installing in parallel. A Debian bug highlighted the above, with a "-" for systemd-sysv- systemd- as a fix, along with allow remove essential.
After this fix, sysvinit builds with debootstrap were almost identical as to bookworm. This includes for desktops.
As per with bookworm through buster, you'll still need something like this too:
$ cat /etc/apt/preferences.d/systemd
# this is the only systemd package that is required, so we up its priority first...
Package: libsystemd0
Pin: release trixie
Pin-Priority: 700
# exclude the rest
Package: systemd
Pin: release *
Pin-Priority: -1
Package: *systemd*
Pin: release *
Pin-Priority: -1
Package: systemd:i386
Pin: release *
Pin-Priority: -1
Package: systemd:amd64
Pin: release *
Pin-Priority: -1
Yes, MX Linux will be doing this (as a separate ISO, until now they're been able to provide a single ISO that lets you choose between systemd and sysvinit at every boot):
I've been living with sysvinit up until Debian 11. Then it became unusable with lxc containers :(, so I had to bite the bullet. But for the basic system it indeed works.
A new APT sources format "debian.sources" is announced with trixie. The now older "sources.list" format is still supported, but is likely to be deprecated in a future Debian release.
See below:
APT is moving to a different format for configuring where it downloads packages from. The files /etc/apt/sources.list and *.list files in /etc/apt/sources.list.d/ are replaced by files still in that directory but with names ending in .sources, using the new, more readable (deb822 style) format. For details see sources.list(5). Examples of APT configurations in these notes will be given in the new deb822 format.
If your system is using multiple sources files then you will need to ensure they stay consistent.
"apt modernize-sources" command can be used to simulate and replace ".list" files with the new ".sources" format.
Modernizing will replace .list files with the new .sources format, add Signed-By values where they can be determined automatically, and save the old files into .list.bak files.
This command supports the 'signed-by' and 'trusted' options. If you have specified other options inside [] brackets, please transfer them manually to the output files; see sources.list(5) for a mapping.
Oh nifty, I hand converted all mine a couple years back. It would have been nice to have that then (or know about it?). I do really like the new deb822 format, having the gpg key inline is nice. I do hope that once this is out there the folks with custom public apt repos will start giving out .sources files directly. Should be more straightforward than all the apt-key junk one used to have to do (especially when a key rotated).
Same. It took me a little bit to get used to it; my initial snap judgment was “this will be more annoying to create via scripting,” but then Ansible added deb822_repository [0] in 2.15 (shortly before Bookworm was released), and then it was no longer a concern.
Ooh, that's nice. Especially nice that it lets you specify both Suites: and Components: in the same stanza, so you don't have to repeat the rest of the line to add -updates and -backports suites.
They only mentioned it briefly, and not by number, but this release includes 95%+ bit-for-bit reproducibility on AMD64, ARM64, and RISC-V across more than 30,000 packages (92% mean across all architectures).
Could you help me understand why the remaining 5% is not bit-for-bit reproducible? For example... if you download a tar of sources pinned to a version, and you run `./configure` and `make` in some kind of container and it doesn't embed some kind of timestamp... why are 95% reproducible and some aren't? Would like to learn/understand.
Hashtables keyed off the address of objects would be an example.
On multiple runs, malloc gives out different addresses (thanks to threads or security concerns) which means things end up in different slots in the table. Then you iterate through it in memory order and you're seeing objects in non-deterministic order, which you do things with.
Embedding file paths / timestamps / git shas and similar was popular for a while too and unhelpful for reproducible builds.
I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right way to do something:
> 5.2.2. systemd message: System is tainted: unmerged-bin
systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System is tainted: unmerged-bin. It is recommended to ignore this message. Merging these directories manually is unsupported and will break future upgrades. Further details can be found in bug #1085370.
That said, my knee-jerk is also that this is about strong-arming distros. Which leaves a bad taste in my mouth. I’d be interested to hear other viewpoints though.
Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.
> Debian maintainer (and upstream dev) is open to an upstream patch to add such an option
Wild interpretation right here.
There are only 2 realistic choices: Leave it as is or patch out the warning message in the Debian package
Debian maintainer is clearly deflecting the responsibility here because everyone knows very well that upstream wouldn't accept such a patch.
As it's already explained in the bug report, since Debian has no plan to do that migration in the near future, aforementioned warning isn't only useless and annoying, it's also potentially harmful, thus the correct action would be to remove it downstream like they did it in xscreensaver (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84)
But then they'd face the wrath of Lennart, so the only choice left is ignoring the report.
Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to support both ways, by properly indicating what style of system it is for troubleshooting purposes.
> Why do you think this is an attempt at a persuasion tactic
Because they said so:
> As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1]
Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve (FreeBSD has great ZFS support btw).
Once I get the hypervisor systemd-free (no systemd on FreeBSD), I can then install a minimal distro in a VM mean to do containerization (like, say, the Talos Linux distro for K8s, that only has a few executables and they're all immutable) and then I can run containers that, by design, have something that is precisely not systemd as PID1.
So life is good: there's a systemd-free world at the end of the tunnel.
Readit News
I like Debian's measured pragmatism with ideology, how it's a distro of free software by default but it also makes it easy to install non-free software or firmware blobs. I like Debian's package guidelines, I like dpkg, I like the Debian documentation even if Arch remains the best on that front. I like the stable/testing package streams, which make it easy to choose old but rock-stable vs just a bit old and almost as stable.
And one of the best parts is, I've never had a Debian system break without it being my fault in some way. Every case I've had of Debian being outright unbootable or having other serious problems, it's been due to me trying to add things from third-party repositories, or messing up the configuration or something else, but not a fault of the Debian system itself.
Debian is great but I can't say this is a shared experience. In particular, I've been bitten by Debian's heavy patching of kernel in Debian stable (specifically, backport regressions in the fast-moving DRM subsystem leading to hard-to-debug crashes), despite Debian releases technically having the "same" kernel for a duration of a release. In contrast, Ubuntu just uses newer kernels and -hwe avoids a lot of patch friction. So I still use Debian VMs but Ubuntu on bare metal. I haven't tried kernel from debian-backports repos though.
Needs citation.
Debian stable uses upstream LTS kernels and I'm not aware of any heavy patching they do on top of that.
Upstream -stable trees are very relaxed in patches they accept and unfortunately they don't get serious testing before being released either (you can see there's a new release in every -stable tree like every week), so that's probably what you've been bit by.
I’ve thought about (ab)using a Proxmox repository on an otherwise stock Debian system before just for the kernel…
You're not trying hard enough ;-)
I have Debian on an old MacBook Pro and had it on an even older iMac, and I've had a few problems over the years. Always with proprietary drivers - WiFi, graphics, webcams, etc. - Apple really don't want people using free software on their hardware. There's always been a fix, but there have been a few stressful moments and hoops to jump through.
But it's definitely my favorite distro, and I run it everywhere I can. Pretty much always "just works" anywhere but Apple.
In what way Ubuntu went downhill?
I had a few issues caused by Ubuntu that weren't upstream. One was Tracker somehow eating up lots of CPU power and slowing the system down. Another was with input methods, I need to type in a pretty rare language and that was just broken on Ubuntu one day. Not upstream.
The bigger problem was Ubuntu adding stuff before it was ready. The Unity desktop, which is now fine, was initially missing lots of basic features and wasn't a good experience. Then there was the short-lived but pretty disastrous attempt to replace Xorg with Mir.
My non-tech parents are still on Ubuntu, have been for some twenty years, and it's mostly fine there. I wouldn't recommend it if you know your way around a Linux system but for non-tech, Ubuntu works well. Still, just a few months ago I was astonished by another Ubuntu change. My mom's most important program is Thunderbird, with her long-running email archive. The Thunderbird profile has effortlessly moved across several PCs as it's just a copy of the folder. Suddenly, Ubuntu migrated to the snap version of Thunderbird, so after a software update she found herself with a new version and an empty profile. Because of course the new profile is somewhere under ~/snap and the update didn't in any way try to link to the old profile.
Then there were stupid things like Amazon search results in the Unity dash search when looking for your files or programs. Nah. Ubuntu isn't terrible by any means but for a number of years now, I'd recommend Linux Mint as the friendly Debian derivative.
I think it’s worth keeping that in mind with all the hate Ubuntu gets. Most users are just silently getting their work done on an LTS they update every two years.
This made it more fragile. It was really nice in the late 2000s, but gradually became worse.
snap, lxd (not lxc!), mir, upstart, ufw.
It's neverending, and it's always failing.
In the early days it had a differing and usually better aligned release schedule for the critical graphics stack.
As a function of time, you are increasingly likely to get rug pulled once Shuttleworth decides to collect his next ransom.
The two things I can remember were problems with NFS out of the box (outside having to install nfs-common, which I'm fine with) and apt-cache not displaying descriptions of packages. There were lots of other, minor annoyances that affected people like me but wouldn't affect someone who got into Linux desktops after, say, 2010. My memory sucks though so those are the two I remember. Yes, there were bug reports filed and yes, they sat in the tracker for years with no attention from Ubuntu.
I wound up back on Debian once I got old enough that I didn't care about being behind the times a couple years.
That's curious, because when I was learning to make Debian packages, I found the official documentation to be far better than I had seen from any other distro. The Policy Manual in particular is very detailed, continually improving, and even documents incremental changes from each version to the next. (That last bit makes it easy for package maintainers to keep up with current best practices.)
Does Arch have something better in this department?
Are you perhaps comparing the Arch wiki to Debian's wiki? On that front I would agree with you.
I still use Debian but it's hard to forget stuff like that even after all these years.
There is plenty that could be said of Debian but as far as I’m concerned that’s not part of it.
Debian patches software for purely ideological reasons because they think they are not free enough. That’s not pragmatism. That’s the reverse of pragmatism. It certainly is a real drag on the teams developing the software they try to ship.
My experience has been contrary to that. I'm a Linux user of 25+ years with various distros but about half of that time with Debian as my main desktop. I broke up with Debian about ten years ago thinking we could still be friends, but every time I've tried to put it on a new box it since then something weird has happened, most recently about a month ago on a completely new Intel N150, when it gave me some stick about video modes. Today my laptop got hosed by an attempted upgrade from bookworm to trixie, as in tons of error messages and then no more docker and no more virtualbox. No harm done because Debian taught me long ago to store a copy of the whole root filesystem on external media before an upgrade, but now the clock is ticking until I have to migrate off it or get stuck with something too old to be compatible with anything.
https://blog.kronis.dev/blog/debian-updates-are-broken
https://blog.kronis.dev/blog/debian-and-grub-are-broken
Then again, I’ve had most software occasionally break, I’m thankful that Debian exists.
I learned nftables with Bookworm and labwc with Trixie.
labwc supports Wayland with Openbox configuration.
So here is what I _don't_ like about Debian :-)
- I don't like Debian package tooling (dpkg, debootstrap, de build...). Actually I hate everything about the experience of Debian packaging. Every time I package for Debian, I end up with a messed up setup of chroots and have to make triple sure nothing leaked from my environment.
- Debian has a habit of repackaging everything at their own sauce, disregarding upstream philosophy. Debian packages will have their own microcosm of configuration directories, defaults, paths, etc. orthogonal to what a pristine installation look like.
- Debian has the annoying habit of default starting installed services. So you always have to dance around your configuration management to disable services, install them, configure them, then restart them.
Dead Comment
Dead Comment
On a personal note, Trixie is very exciting for me because my side project, ntfy [1], was packaged [2] and is now included in Trixie. I only learned about the fact that it was included very late in cycle when the package maintainer asked for license clarifications. As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). I approached the maintainer and just recently added build tags [3] to make it easier to remove Stripe, Firebase and WebPush, so that the next Debian-ized version will not have to contain (so many) awkward patches.
As an "upstream maintainer", I must say it isn't obvious at all why the web app wasn't included. It was clearly removed on purpose [4], but I don't really know what to do to get it into the next Debian release. Doing an "apt install ntfy" is going to be quite disappointing for most if the web app doesn't work. Any help or guidance is very welcome!
[1] https://github.com/binwiederhier/ntfy
[2] https://tracker.debian.org/pkg/ntfy
[3] https://github.com/binwiederhier/ntfy/pull/1420
[4] https://salsa.debian.org/ahmadkhalifa/ntfy/-/blob/debian/lat...
> The webapp is a nodejs app that requires packages that are not currently in debian.
Since vendoring dependencies inside packages is frowned upon in Debian, the maintainer would have needed to add those packages themselves and maintain them. My guess is that they didn't want to take on that effort.
Woah. Shouldn’t Node and Golang be in Debian’s official repos by now?
Debian sources need to be sufficient to build. So for npm projects, you usually have a debian-specific package.json where each npm dependency (transitively, including devDependencies needed for build) needs to either be replaced with its equivalent debian package (which may also need to be ported), vendored (usually less ideal, especially for third-party code), or removed. Oh, and enjoy aligning versions for all of that. That's doable but non-trivial work with such a sizable lockfile. If I would guess the maintainer couldn't justify the extra effort and taking on combing through all those packages.
I also think in either case the Debian way would probably be to split it out as a complementary ntfy-web package.
My advise to you is to deny all support from people using the Debian version of your software and automatically close all bug tickets from Debian saying you don’t support externally patched software.
You would be far from the first to do so and it’s a completely rational and sane decision. You don’t have to engage with the insanity that Debian own policies force on its maintainers and users.
> The ntfy image is available for amd64, armv6, armv7 and arm64. It should be pretty straight forward to use.
Debian has been the stable footing of my Free computing life for three decades. Everything about their approach — from showing me Condorcet, organising stable chaos, moving forward by measured consensus, and basing everything on hard wrought principles — has had an effect on me in some way, from technical to social and back again.
I love this project and the immeasurable impact it has had on the world through their releases and culture.
With all my love, g’o xx
Impressive that i386 support made it all the way to August 2025. I have Debian 10 Buster running on a Pentium 3 which only EOL'd last year in June 2024. It's still useful on that hardware and I'm grateful support continued as long as it did!
OpenBSD still supports i386 for those looking for a modern OS on old 32-bit hardware.
I am not happy about unnecessary ewaste, but an i386 almost certainly has and order of magnitude less horsepower than a raspberry pi or N100.
If that's all there's to it, you can still use debootstrap, compile a kernel, and point the root parameter to your shiny new install.
If the official i386 arch was built with instructions that your hardware doesn't support, tough cookies.
https://wiki.debian.org/PortsDocs/New
True i386 support would mean compatible with the original Intel 386 processor from 1985. The 486 added a few additional instructions in 1989 but things really changed with the Pentium in 1993 - that gave us i586 which is the bare minimum for most modern software today. Much software can still run on regular Pentiums today if compiled for it, but SSE2 optimizations requires at least a Pentium 4 or Core CPUs instead.
I play with retro PCs often and found OpenBSD's i386 target stopped supporting real 386 CPUs after the 4.1 release, and dropped support for i486 somewhat recently in 6.8. It now requires at least a Pentium class CPU, i586, though the arch is still referred to as i386 likely because it's a common proxy for "32-bit".
It was a bit of a strange decision since there were undoubtedly more 386, 486, and Pentium users than some of the platforms Linux continued to support, but that's the choice they made. But they weren't alone. Even NetBSD requires a 486DX or better.
However, that doesn't stop one from installing a Pentium Overdrive in an old Socket 3 board and running the latest release. ;)
From my build box:
There is a weird depends you cannot get around without simultaneously removing and installing in parallel. A Debian bug highlighted the above, with a "-" for systemd-sysv- systemd- as a fix, along with allow remove essential.After this fix, sysvinit builds with debootstrap were almost identical as to bookworm. This includes for desktops.
As per with bookworm through buster, you'll still need something like this too:
* https://jdebp.uk/Softwares/nosh/guide/services/systemd-login...
https://mxlinux.org/blog/changes-coming-with-mx-25/
I run a full desktop too, without it. Multiple variants.
I don't use gnome's Desktop Environment though (although I do run gtk/gnome software), so cannot comment on that.
See below:
- https://wiki.debian.org/SourcesList#APT_sources_format- https://www.debian.org/releases/trixie/release-notes/upgradi...
"apt modernize-sources" command can be used to simulate and replace ".list" files with the new ".sources" format.
Oh nifty, I hand converted all mine a couple years back. It would have been nice to have that then (or know about it?). I do really like the new deb822 format, having the gpg key inline is nice. I do hope that once this is out there the folks with custom public apt repos will start giving out .sources files directly. Should be more straightforward than all the apt-key junk one used to have to do (especially when a key rotated).
[0]: https://docs.ansible.com/ansible/latest/collections/ansible/...
[0]: https://manpages.debian.org/buster/apt/sources.list.5.en.htm...
Congratulations to the team--phenomenal work!
https://reproduce.debian.net/
Alternative to parsing the reproduce web site :)
On multiple runs, malloc gives out different addresses (thanks to threads or security concerns) which means things end up in different slots in the table. Then you iterate through it in memory order and you're seeing objects in non-deterministic order, which you do things with.
Embedding file paths / timestamps / git shas and similar was popular for a while too and unhelpful for reproducible builds.
> 5.2.2. systemd message: System is tainted: unmerged-bin systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System is tainted: unmerged-bin. It is recommended to ignore this message. Merging these directories manually is unsupported and will break future upgrades. Further details can be found in bug #1085370.
No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
http://0pointer.net/blog/projects/stateless.html
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
That said, my knee-jerk is also that this is about strong-arming distros. Which leaves a bad taste in my mouth. I’d be interested to hear other viewpoints though.
The discussion in that bug is that the Debian maintainer (and upstream dev) is open to an upstream patch to add such an option.
Wild interpretation right here.
There are only 2 realistic choices: Leave it as is or patch out the warning message in the Debian package
Debian maintainer is clearly deflecting the responsibility here because everyone knows very well that upstream wouldn't accept such a patch.
As it's already explained in the bug report, since Debian has no plan to do that migration in the near future, aforementioned warning isn't only useless and annoying, it's also potentially harmful, thus the correct action would be to remove it downstream like they did it in xscreensaver (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84)
But then they'd face the wrath of Lennart, so the only choice left is ignoring the report.
Because they said so:
> As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1]
1. https://0pointer.de/blog/projects/the-biggest-myths.html
Also, like it or not, the word "tainted" bears a negative connotation. It's hard to imagine that it was chosen arbitrarily.
Once I get the hypervisor systemd-free (no systemd on FreeBSD), I can then install a minimal distro in a VM mean to do containerization (like, say, the Talos Linux distro for K8s, that only has a few executables and they're all immutable) and then I can run containers that, by design, have something that is precisely not systemd as PID1.
So life is good: there's a systemd-free world at the end of the tunnel.
Did you consider Devuan? Or is this just taking one annoyance as motivation to fix others at the same time?