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.
Biggest change for me is /tmp behavior. In Debian 13 /tmp become RAM-disk by default (instead of files on the file system) and uses up to 50% of available ram. But as expected of Debian the release notes included an easy fix to restore normal /tmp behavior for people and applications that place many small or large files there.
>"You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting."
I kind of wish the distros had decided on a new /tmpfs (or /tmp/tmpfs, etc) directory for applications to opt-in to using ram-disk rather than replacing /tmp and having to opt-out.
I can't believe we've come to such a high number, and a particularly lucky one at that
Alas it's still not suitable as a daily driver for the average home user and probably never will be. It is unfortunate that Ubuntu has to reign supreme in that regard.
> Alas it's still not suitable as a daily driver for the average home user and probably never will be.
Why not?
My family members need little more than a web browser, media player, and office suite. Debian Stable is very suitable here; arguably more so than other distros, which tend to require maintenance more often.
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
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.
> 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.
The 403GB figure represents the total size of all source packages in the Debian archive, not the disk space required for a typical installation which is usually under 10GB for a desktop system.
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.
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.
> 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.
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.
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 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.
> 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.
Debian 13 trixie includes numerous updated software packages (over 63% of all packages from the previous release)
I’m not familiar with the metric definition they use, but I’d be worried if close to 100% of the packages they included in bookworm hadn’t been updated in the roughly 2 years between releases.
I use Debian for most of my servers, so I’m sure there is a valid explanation of that phrase.
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!
> 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 have been tracking Trixie on my Resolve workstation for the past couple of months. The only hiccup was that the latest kernel did not support the ondemand governor, so I had to build a custom kernel to fix that.
I have used Debian starting sometime around slink. I still type "apt-get ..." and it still works reasonably well. There have definitely been hiccups in upgrades over the last 25+ years but the amount of time/effort dealing with those is almost nothing in comparison to other linux and non-OSS systems I've dealt with over the same span of time. My only regret is not contributing more to the community.
The thing I like most about Debian is that you need to know at least a little about what is going on to use it. For me, it does a good job of following "as simple as possible and no simpler."
My first Debian install was in 1996. I had no real idea what I was doing, but it was amazing to me that I could remote-display windows from machines across campus, and it was alien compared to the windows 3.x/95 I was used to at that point. There was no apt at that point, or none that I was aware of, and adding new stuff was painful.
I started using debian preferentially as my workstation/desktop OS in about 2005, and was installing it on embedded systems (linksys nslu2) to make micro servers by … etch I think it was.
By 2008 I was at IBM and they allowed a choice of windows or redhat on your laptop, and if you were adventurous there was experimental support for Ubuntu which might work on Debian. I made it work and discovered that among 330k people there were 22 of us running it!
Always loved it, it always just made more sense than other distros somehow. My daily driver is a Mac now, but I still have a few Debian machines around.
I have been using Debian Trixie for a few months in testing now, I can attest that its a great, stable operating system. Definitely better than Ubuntu in terms of user experience.
The only complaint on a fresh install is that Cinnamon seems to use a ton of CPU when there's a little moving thingy anywhere on the screen (a browser tab that has a loading icon in the tab list is sufficient). This is most noticeable when you have a VM without graphics acceleration (don't ask why in the world my job requires that). Graphics without acceleration is always heavy, but this is an extra process doing whatever on top of the actual load
Then my private laptop has had a bunch of graphic issues after upgrading to 13 (it manifests differently in a lot of applications and it changes when you pick a different desktop theme, not even sure how to describe it). The new pipewire (pulseaudio replacement, idk why that needed replacing) does not work properly when the CPU is busy (so I currently play games without game sounds or music in the background). The latter then also sometimes (1 in 5 times maybe?) crashes when resuming from suspend, but instead of dying, spams systemd which diligently stores it all in a shitty binary file (that you can't selectively prune), runs completely out of disk space, and breaks various things on the rest of the system until you restart the pipewire process and purge any and all logs (remember, no selective pruning)... Tried various things I found in web searches and threw an LLM at it as well, but no dice. I assume these issues are from it not being a fresh install, so no blame/complaint here really, just annoying and I haven't had these issues when doing previous upgrades. Not yet sure how to resolve, perhaps I'll end up doing a completely new install and seeing what configs I can port until issues start showing up
Surely these things are not a Debian-specific issue, but I haven't noticed something like that with either 11 or 12
Edit: oh yeah, and the /tmp(fs) counter is at 1 so far. I wonder how many times I'll have run out of RAM by Debian 14, by forgetting I can't just dump temporary files into /tmp anymore without estimating the size correctly beforehand
# example:
udevadm test-builtin net_setup_link /sys/class/net/eno4 2>/dev/null
ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
ID_NET_LINK_FILE_DROPINS=
ID_NET_NAME=eno4 <-- note the NIC name that will happen after reboot
Here's a one-liner, excluding a bond interface and lo. Gives a nice list of pre and post change.
for x in $(cat /etc/network/interfaces | grep auto | cut -d ' ' -f 2 | grep -Ev 'lo|bond0'); do echo -n $x:; udevadm test-builtin net_setup_link /sys/class/net/$x 2>/dev/null | grep NET_NAME| cut -d = -f 2; done
The doc's logic is that after you've upgraded to trixie, and before reboot, you're running enough of systemd to see what it will name interfaces after reboot.
So far I have not had an interface change due to upgrade, so I cannot say that the above does detect it.
enoX should always stay stable, as it's the BIOS (in some ACPI table) telling that this device/port has this ID.
ensX means the NIC in PCIe slot X, but in your PCIe tree you can have PCIe bridges, so technically you could have multiple NIC in the same slot (what the BIOS declare as a slot), so there was a lot of breaking NIC naming changes over the years in systemd to figure out the right heuristics that are safe, enabling/disabling slot naming if there is a PCIe bridge, but just in some cases.
Also for historical reasons the PCIe slot number was read indirectly leading to some conflicts in some cases (this was fixed in systemd 257)
Debian's signature feature (upgrade from stable to stable under 15 minutes) shines here too.
My first system migrated in less than 10 minutes, incl. package downloads and reboot. It's not a beast either. N100 mini PC connected to a ~50mbps network.
A total of seven architectures are officially supported for "trixie":
"trixie"
64-bit PC (amd64),
64-bit ARM (arm64),
ARM EABI (armel),
ARMv7 (EABI hard-float ABI, armhf),
64-bit little-endian PowerPC (ppc64el),
64-bit little-endian RISC-V (riscv64),
IBM System z (s390x)
It's good to see RISC-V becoming a first-class citizen, despite the general lack of hardware using it at the moment.
I do wonder, where are PowerPC and IBM System z being used these days? Are there modern Linux systems being deployed with something other than amd64, arm64, and (soon?) riscv64?
Mainframes are still holding on in use cases where a single server having continuous uptime is vital. They're designed to have uptime measured in decades, so even components like the processors and main memory have hot spares available and can be hot-swapped without interrupting the OS or running services. They also have continually running system monitoring and diagnostics at the hardware level (not running as an OS service) that will alert both the owner and IBM if they detect some sort of hardware fault. IBM has supported Linux as a first-class OS option for their mainframes since the early 2000s.
From a developer perspective, s390x is also the last active big-endian architecture (I guess there's SPARC as well, but that's on life support and Oracle doesn't care about anyone running anything but Solaris on it), so it's useful for picking up endianness bugs.
Another interesting thing is that the only two 32-bit architectures left supported are armel and armhf. Debian has already announced that this will be the last release that supports armel (https://www.debian.org/releases/trixie/release-notes/issues....), so I guess it'll be a matter of time before they drop 32-bit support altogether.
Yeah, mainframes are all about cases where the uptime is critical. Most modern systems are good with offering 99.9% or 99.99% reliability, with the understanding that trying to offer more than that just gets more and more expensive. Well... spending huge amounts of money on mainframes is one of the strategies to get to reliability numbers like 99.9999999%.
The legitimate usage is typically for workloads like relational databases (which are anyway single-machine architectures) that experience heavy load 24/7, part of fragile architectures that cannot tolerate downtime (remaining fragile as such because the original source code has been lost etc.), where "the system is down" causes tens of thousands if not hundreds of thousands of people to stop work.
> Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware.
In the abstract I'm a big fan of supporting me old machines forever, but I have to ask out of curiosity - what hardware is practical to run these days and only has a 32-bit processor?
108 comments
[ 3.4 ms ] story [ 87.3 ms ] threadDebian 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
https://www.debian.org/releases/trixie/release-notes/issues....
>"You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting."
I kind of wish the distros had decided on a new /tmpfs (or /tmp/tmpfs, etc) directory for applications to opt-in to using ram-disk rather than replacing /tmp and having to opt-out.
Alas it's still not suitable as a daily driver for the average home user and probably never will be. It is unfortunate that Ubuntu has to reign supreme in that regard.
Why not?
My family members need little more than a web browser, media player, and office suite. Debian Stable is very suitable here; arguably more so than other distros, which tend to require maintenance more often.
Lucky 13 and all... And not a single issue so far. Very happy!
Thanks to the Debian team for putting out yet another high quality, reliable 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...
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.
What does this mean? If all 69k+ packages are installed, it will take up this much space?
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 learned nftables with Bookworm and labwc with Trixie.
labwc supports Wayland with Openbox configuration.
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.
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.
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.
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.
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’m not familiar with the metric definition they use, but I’d be worried if close to 100% of the packages they included in bookworm hadn’t been updated in the roughly 2 years between releases.
I use Debian for most of my servers, so I’m sure there is a valid explanation of that phrase.
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...
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.
Have had my RPi on Debian since Debian 9, with smooth upgrades every time.
The thing I like most about Debian is that you need to know at least a little about what is going on to use it. For me, it does a good job of following "as simple as possible and no simpler."
My first Debian install was in 1996. I had no real idea what I was doing, but it was amazing to me that I could remote-display windows from machines across campus, and it was alien compared to the windows 3.x/95 I was used to at that point. There was no apt at that point, or none that I was aware of, and adding new stuff was painful.
I started using debian preferentially as my workstation/desktop OS in about 2005, and was installing it on embedded systems (linksys nslu2) to make micro servers by … etch I think it was.
By 2008 I was at IBM and they allowed a choice of windows or redhat on your laptop, and if you were adventurous there was experimental support for Ubuntu which might work on Debian. I made it work and discovered that among 330k people there were 22 of us running it!
Always loved it, it always just made more sense than other distros somehow. My daily driver is a Mac now, but I still have a few Debian machines around.
Then my private laptop has had a bunch of graphic issues after upgrading to 13 (it manifests differently in a lot of applications and it changes when you pick a different desktop theme, not even sure how to describe it). The new pipewire (pulseaudio replacement, idk why that needed replacing) does not work properly when the CPU is busy (so I currently play games without game sounds or music in the background). The latter then also sometimes (1 in 5 times maybe?) crashes when resuming from suspend, but instead of dying, spams systemd which diligently stores it all in a shitty binary file (that you can't selectively prune), runs completely out of disk space, and breaks various things on the rest of the system until you restart the pipewire process and purge any and all logs (remember, no selective pruning)... Tried various things I found in web searches and threw an LLM at it as well, but no dice. I assume these issues are from it not being a fresh install, so no blame/complaint here really, just annoying and I haven't had these issues when doing previous upgrades. Not yet sure how to resolve, perhaps I'll end up doing a completely new install and seeing what configs I can port until issues start showing up
Surely these things are not a Debian-specific issue, but I haven't noticed something like that with either 11 or 12
Edit: oh yeah, and the /tmp(fs) counter is at 1 so far. I wonder how many times I'll have run out of RAM by Debian 14, by forgetting I can't just dump temporary files into /tmp anymore without estimating the size correctly beforehand
https://www.debian.org/releases/trixie/release-notes/issues....
Here's a one-liner, excluding a bond interface and lo. Gives a nice list of pre and post change. The doc's logic is that after you've upgraded to trixie, and before reboot, you're running enough of systemd to see what it will name interfaces after reboot.So far I have not had an interface change due to upgrade, so I cannot say that the above does detect it.
*haha
enoX should always stay stable, as it's the BIOS (in some ACPI table) telling that this device/port has this ID.
ensX means the NIC in PCIe slot X, but in your PCIe tree you can have PCIe bridges, so technically you could have multiple NIC in the same slot (what the BIOS declare as a slot), so there was a lot of breaking NIC naming changes over the years in systemd to figure out the right heuristics that are safe, enabling/disabling slot naming if there is a PCIe bridge, but just in some cases.
Also for historical reasons the PCIe slot number was read indirectly leading to some conflicts in some cases (this was fixed in systemd 257)
My first system migrated in less than 10 minutes, incl. package downloads and reboot. It's not a beast either. N100 mini PC connected to a ~50mbps network.
Minimal: https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/deb...
Full: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/de...
I do wonder, where are PowerPC and IBM System z being used these days? Are there modern Linux systems being deployed with something other than amd64, arm64, and (soon?) riscv64?
From a developer perspective, s390x is also the last active big-endian architecture (I guess there's SPARC as well, but that's on life support and Oracle doesn't care about anyone running anything but Solaris on it), so it's useful for picking up endianness bugs.
Another interesting thing is that the only two 32-bit architectures left supported are armel and armhf. Debian has already announced that this will be the last release that supports armel (https://www.debian.org/releases/trixie/release-notes/issues....), so I guess it'll be a matter of time before they drop 32-bit support altogether.
Source: https://itic-corp.com/itic-2023-reliability-survey-ibm-z-res...
The legitimate usage is typically for workloads like relational databases (which are anyway single-machine architectures) that experience heavy load 24/7, part of fragile architectures that cannot tolerate downtime (remaining fragile as such because the original source code has been lost etc.), where "the system is down" causes tens of thousands if not hundreds of thousands of people to stop work.
The end of an era.
IBM.
And they own redhat, so I imagine they put a lot of time and money into making the kernel work.
Why Debian in particular, not sure.
What I did is switch to NetBSD.