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.
You're right stability comes from testing, not enough testing happens around Linux period, regardless of which branch is being discussed.
It's not easy testing kernels, but the bar is pretty low.
You can do that well enough with Debian's "testing" and "unstable" release channels. Aside from the few months leading up to a new "stable" release, which usually isn't a big deal (and fixing regressions in "stable" should then be a higher priority anyway). Just don't install it on systems that you actually depend on to keep working. But running it on your desktop at home that you only use to play and experiment with is just fine.
The wiki has more info on this.
https://wiki.debian.org/LTS https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Funding https://wiki.debian.org/LTS/Extended
Whether that qualifies as "heavy" or not is of course a matter of opinion, but it's not nothing.
I’ve thought about (ab)using a Proxmox repository on an otherwise stock Debian system before just for the kernel…
On the other hand, I had and still have many Debian installations, some with Intel integrated graphics. None of them created any problems for a very, very long time. To be honest, I don't remember even any of my Intel iGPU systems crashed.
...and I use Debian for almost two decades, and I have seen tons of GPU problems. I used to write my Xorg.conf files without using man, heh. :)
Maybe you can give Debian another chance.
echo exit 101 > /usr/sbin/policy-rc.d
chmod +x /usr/sbin/policy-rc.d
Still should be the default behavior.
But you can't (easily) configure package X itself before you install it; and after you install it, it runs immediately so you only get to configure it after the first run.
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.
Of course that goes against the spirit of FOSS, but there's a bit more nuance there than simply saying "snaps are proprietary".
Containers, popular as they may be on servers, can only add breakage and overhead to desktops, especially for an established and already much better organized system like Debian's apt. There just haven't been any new desktop apps for way over a decade that would warrant yet another level of indirection.
For example, with flatpak you select a base runtime for your package that contains mostly system-agnostic libraries. With snap, you specify an Ubuntu version as a base runtime and additional dependencies that are Ubuntu packages.
The end result should be similar to FlatPak where you have practically no dependencies as it should package almost everything.
I can't seem to find it. Any pointers would be helpful, so at least I can know the latest state of this thing.
I didn't say "the snap format".
The server isn't, and the client is hostile to using an alternative server. Snaps are a solution, and picking out one piece is deceptive.
The topic is not whether snaps are avoidable or not, but the Ubuntu is going downhill. And snaps are purported to be part of that downhill, which would be Ubuntu's NIH syndrome. As far as I know, Ubuntu's only successful development is Ubuntu itself - the other projects have all failed over the years, and snap, while ongoing, is not winning any popularity contests either.
But in practice even for flatpak the only realistic place you can publish your flatpak if you want any traction at all would be flathub, so both formats have only one store right now. But flatpak allows a custom store while for some strange reason Canonical decided not to allow snap that freedom.
Red Hat do the same. They reinvented the wheel on multiple occasions (systemd and it's whole ecosystem like systemd-resolved and timed and the whole kitchen sink; podman, buildah, dnf, etc etc.)
They just have more success on getting their NIH babies accepted as the standard by everyone else. Canonical just fail at that (often for good reasons, Unity was downright crap for some time) and abandon stuff, which doesn't help their future causes.
Using apt to install some packages installs snap plumbing and downloads the package as a snap automatically. You don't have to install it manually.
There's no malicious intent though, it's made to "impose a positive pressure on the snap team to produce better work and keep their quality high" (paraphrased, but this was the official answer).
This has got to be the most user-blind self-imposed preference in a modern operating system outside of Microsoft's BS.
If you're going to use an OSS operating system, the control of what is placed on the system should be inherently with the user. If the developer has a question if a new package should be added or is required, throw a prompt and ask -- with a default to not use application containers and the default packaging system.
Really not hard.
Debian has been a safe haven since.
Packaged as: https://github.com/justinclift/snapd-empty/releases/download...
It's just an empty package that tells the system snap is installed, to stop the broken dependency chains you otherwise get from force uninstalling snap.
It's been working fine on a handful of Ubuntu 24.04 systems I've been handed and can't change the OS of, for about half a year now.
It should be this: https://github.com/justinclift/snapd-empty/
Then you add e.g. the mozilla PPA such that its firefox package gets installed instead.
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.
Most of the Linux-based (enterprise and/or embedded) appliances are built upon Debian, for example.
P.S.: The total number of Debian installations and their derivatives are unknown BTW. Debian installations and infra do not collect such information. You can install "popularity-contest", but the question defaults to "no" during installation, so most people do not send in package selection lists, unlike Canonical's tracking of snap installations.
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.
Seamless LXC and virtual machine management with clustering, a clean API, YAML templates and a built-in load balancer, it's like Kubernetes for stateful workloads.
Switch to sudo-rs, uu-coreutils (rust based stuff), etc., etc.
It's not a Debian derivative anymore. It's something else.
Was not my cup of tea before, it's even more not my cup of tea now.
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.
Their lawyers' willingness to risk shipping pre-built zfs kernel modules (that are always in sync with the kernel). Pretty important if you're into that sort of thing, it's easier to remove cruft once post-install than to keep an eye on DKMS for years (making sure that it hasn't disassembled itself and continues working).
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.
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.