Preferences

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

LTS has had major breaking changes in various areas in recent times too, virtio was badly broken at one point this year, as was a commonly used netlink interface. Hat tip to the Arch kernel contributors who helped track this down and chase upstream, as we had mutually affected users. The debian and ubuntu bug trackers were a wasteland of silence and user contributions throughout the situation, and frustratingly continued to be so as AWS, GCP and others copied their kernel patch trees and blindly shipped the same problems to users and refused to respond to bugs and emails.

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.

One of the unsung praises of Arch is that it's turned thousands of users into testers. Before someone says "that shouldn't be the user's responsibility" I'm going to say I'm not so sure. We're all in this together. I'd rather deal with a bug or two on my desktop at home if it means it gets fixed before appearing in a distro that gets used for servers at work and causes issues there where the consequences are much higher.
> One of the unsung praises of Arch is that it's turned thousands of users into testers.

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.

I have a similar experience. My not-so-tech-savvy brother also has the same laptop setup I do (arch+XFCE). He knows to yay -Syyu and it's usually never a problem. The recent upgrade there was the vlc package split problem so I told him to hold on upgrading and that I'd come and do it. While I needed to sit and filter and install the optional dependencies myself for my upgrade, a week later it was already figured out (based on user feedback I assume) and the usual yay -Syyu installed just the right optional dependencies.
I don't consider myself particularly adept with linux. I've only been running it daily on the desktop for the last few years and, aside from mucking around with TWMs, I've not done much poking about with the internals.

Despite the reputations, I've had far fewer issues on Arch-based desktop distros than back when I was rolling Ubuntu and Debian.

That said, Debian on a server every time.

Yeah same. I think the release cycle actually doesn't matter at all. The reason for it is that the majority of breakage are caused by components/extensions of gnome and kde and non-DE-yet-complex software in distros with a lot of those present out of the box, like manjaro, breaking backwards compatibility every other week.

When people switch to arch they typically set things up from scratch, end up choosing simple tools and avoid most of the unstable stuff distros push onto you.

The virtio bug bit me. I have one hostnode (debian) with one nic that gets passed through to a virtualized opnsense. Storage is two consumer nvme in raid0 as system disk. I was expecting downtime with this setup, but kernel bug was not on my list.
Bear in mind, LTS and ELTS are not Debian maintained.

The wiki has more info on this.

The folks behind Debian LTS and Freexian ELTS are all Debian members/contributors, and the Debian LTS changes end up in the Debian archive, while the Freexian ELTS ones are publicly available, just in an external archive.

https://wiki.debian.org/LTS https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Funding https://wiki.debian.org/LTS/Extended

I think they mean the LTS kernels, not Debian's LTS.
Yep, I mean longterm trees from https://www.kernel.org/, to be clear.
Yes, seems so, thanks.
AFAICT, the patches are here: https://salsa.debian.org/kernel-team/linux/-/tree/debian/lat...

Whether that qualifies as "heavy" or not is of course a matter of opinion, but it's not nothing.

IMO, considering the size and scale of the kernel (millions of lines of code, variety of architectures supported, # of subsystems and ridiculous amount of device drivers ), these patches might as well be counted as nothing. I'd say they're basically shipping a pristine kernel :D
Classic Linux user response. Jeez…
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…

Same at $work all physical servers run proxmox VE (by policy), 90% of VMs are debian (cloudinit genericcloud), the rest misc linux and various windows.
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.
Which GPU, display server and compositor stack are you using?
Integrated Intel GPU and no graphical system, just KMS VT (text console). That's what made it so frustrating - only displaying a console should not result in kernel panics under CPU load! Admittedly, the experience was anecdotal and years ago and I heard Debian is doing less of a RHEL-style "frankenkernel" now.
drm/i915 was a pretty miserable experience for me on one machine. The Intel drivers for that chipset around the 5.3 kernel era weren't good, I recall lots of bug reports at the time. Below is one of the several issues that I was affected by

https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/673

Intel's integrated GPU driver team, actually all driver teams, had a period of frequent screw-ups a while back (five years ago? Time flies). They also borked e1000e driver in the same period.

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.

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal