Hacker News Reader

Hacker News

Comment by naturalmovement | Hacker News Reader

Parent Full thread

naturalmovement

[flagged]

View on HN

The most recent Linux kernel releases are: 7.1, 7.0, 6.19, 6.18, …:

* https://en.wikipedia.org/wiki/Linux_kernel_version_history

7.0 is already present in forky (current testing), and available as a backport for trixie (current stable):

* https://packages.debian.org/search?keywords=linux-image-amd6...

* https://packages.debian.org/trixie-backports/linux-image-amd...

The default kernel for trixie/stable is 6.12, initially released in November 2024, and officially supported upstream until December 2028.

Just hope there’s never a Lillypad version

I know it's a bit of a meme but I'm on Debian Stable and I am running the backport kernel, which is on version 6.19. So only one minor version away from the current 7.0.

I wish more people would consider Debian for their devices. It is a very stable system, which I appreciate, and, unlike Ubuntu, it was really an "it just works" experience, without any of the friction points that smaller distros have. I installed Debian Trixie on a very recent device (granted, all AMD for compatibility) when Trixie was still the Testing version, and all the necessary drivers were present.

Now if only I could figure out how to build packages and contribute back to Debian... Also if only AMD could get their NPU support for Linux figured out...

Actually, I'm running the backports kernel which is at 7.0 today.

  $ uname --kernel-release 
  7.0.10+deb13-amd64

If you run stable, Debian backports takes care of a lot of the popular stuff. Kernels, kernel modules, Rust/Cargo, CMake, Clangd, GPU firmware (AMD/Intel), GDB, LibreOffice, OpenShot video editor, and Wireguard are all kept current in backports. And there's way more than I mention here, of course. Worst case I can install unstable in a schroot and run some bleeding-egde software.

I did all of my distro hopping when I was young, 20+ years ago. I settled on Debian because life got busy and I had no time to fuss with broken software updates.

The full list of what's available in trixie-backports, if anyone is curious: https://backports.debian.org/uploads/trixie-backports/

I’ll never understand why people like Ubuntu. It’s a really hard toss up for me if I’d rather be stuck with Ubuntu or windows.

Probably because it got popular as the easy Linux distro back in the 2000s and that label is sticking.

I remember that I attempted to install Debian on my laptop in 2009. It was ugly. I installed Ubuntu 8.04 and it was a totally different and much nicer experience. Because of that I've been on Ubuntu until they started pushing snaps very aggressively. I live booted Debian 11 and realized that its UI was exactly the same. I don't know when it happened during that dozen of years but there wasn't anymore a reason to stick to Ubuntu. I installed Debian 11 and got a faster machine with less background processes. I'm on Debian 13 now. I've been told that KDE is much better than what I attempted to use in 2014 so maybe I could give it a try, but it's unclear to me what I have to gain.

I prefer KDE (on Ubuntu, because I tried it and it's good enough) - it's got more stuff built into the OS in terms of settings. I tended to find that Gnome needs you to install more things to expose configuration settings, whereas KDE's configuration UI is pretty good.

For me, it was kubuntu. Back in late 2005 or early 2006. The reason? They were always pretty good at shipping the latest KDE. I had grown tired of hoping someone would compile a new version for my preferred distro.

So kubuntu it was, and has been ever since. I'm currently looking into whether I should change to something else - as I've started growing tired of Ubuntu/Kubuntu after some 20 odd years.

I'm of the belief that the more popular an OS is, the more maintainers it will have (and thus less bugs). The only thing about Ubuntu that I hated was its choice of windowing manager. That's why there are so many variants like KUbuntu, XUbuntu, etc. Are there other reasons to not like Ubuntu other than the windowing manager?

> Are there other reasons to not like Ubuntu other than the windowing manager?

Snap applications are still not “equal enough” to installed apps.

They have gotten better, but it’s not seamless and when you get burned it’s 2 hours debugging. Each time.

An app I use/help maintain regularly gets bug reports about sandboxed behavior. It’s understandable but the easiest fix is to install an unsandboxed version.

I personally have some extra steps in my workflow for printing from a snap application because it doesn’t just work and I don’t want to spend the hours needed to debug it.

Ubuntu offered a slightly prettier installation experience.

Sure, no matter which distro you were installing you still had to provide a hostname, a domain name, some IP info (maybe), and an opinion on partitioning - there's only so many ways to ask the user these questions - but the ubuntu installer was prettier.

Around the time it was gaining popularity, almost every 'reviewer' (blogger) seemed to waste about 85% of their distro reviews talking about the installer - as though this was somehow important. The big sell of Debian, and Debian-derivatives, is that you install once, and then it's just in-place upgrades forever. The distro-hoppers, Microsoft evacuees, content-creators, etc - didn't really get that.

Anyway, once Ubuntu was installed it was much the same to operate as a Debian box. Obviously there were some surprising differences. Unity. Mir. One Cloud. Wubi. Upstart. Bazaar.

Come on - at least make one substantive criticism in your post putting down Ubuntu.

I came to Ubuntu because Wine worked on it with no effort. Yes, this was a long time ago. I have certainly cursed some of their changes since then, but I don’t want to spend my time doing yet another sysadmin job, so the less I change the better.

Well, it starts with when I have to opt out of location services during install, and Ubuntu reserving usernames (admin, for example) and ends with how aggressively they shut down upstream repos… if they’re not being DDoSd. Package conflicts are miserable, so they tried to paper over it, adding yet another bullshit layer of things to debug when something invariably breaks.

I’d rather flip the question back on you, how is Ubuntu better than, say, Rocky? If you say “upgrading is easier” I’ll chuckle for the rest of the day.

> (granted, all AMD for compatibility)

I get that you mean that AMD is more compatible than... what? Intel? Arm?

Nvidia, I think? That's what people say but has never been my experience.

Debian unstable/testing? Is quite good too. As well as OpenSUSE.

Check out FastFlowLM for AMD NPU support.

what doesn't just work in Ubuntu, compared with Debian?

Not a serious question but I'll give a serious answer anyway.

The last time I worried over which kernel was used in Debian Stable was... never. If I want a more recent kernel I run Debian unstable (Sid) which currently is at 7.0.12 (the current 'stable' kernel where 7.1 is 'mainline') but on my servers Stable (currently 'Trixie') does just fine with its 6.17.3 kernel. Debian 'Forky' will be released somewhere in 2027 with either a 7.0.x or 7.1.x kernel depending on how things go. The current kernel used in 'testing' (which will become 'stable' on the next release) is 7.0.10.

People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.

To do so, add the sources for trixie-backports and unstable, and add the following configuration (e.g. /etc/apt/preferences.d/trixie-sid-pin) so that the system knows which sources your prefer:

   # Default to trixie
   Package: *
   Pin: release n=trixie
   Pin-Priority: 990
   
   # Very low priority for sid
   Package: *
   Pin: release n=unstable
   Pin-Priority: 100
   
   # Give backports medium priority
   Package: *
   Pin: release n=trixie-backports
   Pin-Priority: 500

Now the system can access the latest kernel from unstable (and backports), while keeping everything else on stable:

   # apt policy linux-image-amd64
   linux-image-amd64:
     Installed: 7.0.12-1
     Candidate: 7.0.12-2
     Version table:
        7.0.12-2 500
           500 http://deb.debian.org/debian unstable/main amd64 Packages
    *** 7.0.12-1 100
           100 /var/lib/dpkg/status
        7.0.10-1~bpo13+1 500
           500 http://deb.debian.org/debian trixie-backports/main amd64 Packages
        6.12.90-2 500
           500 http://security.debian.org/debian-security trixie-security/main amd64 Packages
        6.12.86-1 990
           990 http://deb.debian.org/debian trixie/main amd64 Packages

I believe the kernel in backports gets updated only after it is live in unstable for at least a week, which lately still feels like forever.

> People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.

Which is just as well, because that's not generally a good idea unless you really know what you're doing:

https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...

Granted, the kernel is probably the best thing to do it with, on account of their aggressive stance on compatibility and the narrowness of impact (no .so files in play).

Backports are meant to work well along stable packages, but I agree it's definitely not a good idea to start pulling from sid from trixie (for regular packages, kernel is fine), this is asking for a ruined system.

Chaing priority wholesale is not needed just to install kernel image and might break other packages. Just install kernel image from backports after enabling backports.

> apt install linux-image-amd64/stable-backports

Somehow installing with `trixie-backports` isn't picking up latest kernel for me. Used what is being displayed in `apt search linux-image-7`

> The last time I worried over which kernel was used in Debian Stable was... never.

It was briefly a little annoying to deal with wireguard. But it was only a bit annoying, and then they updated. That's the only time I recall specifically caring.

Yes, when that was a thing I just compiled the wireguard module myself to feed it to the virtual router. It was only needed for a short interval and was thereafter handled by dkms, i.e. no problem.

It’s fairly easy to build your own kernel packages from vanilla sources in Debian. I’m running the latest 7.0.x within a few hours of its release. The build takes about 30-45 minutes depending on how much time I spend on skimming the ChangeLog. YMMV.

> The build takes about 30-45 minutes

If you don't actually need all the drivers, you can use "make localmodconfig" to substantially reduce that. My local kernels build in 90 seconds on a 32-thread desktop machine :)

The kernel is a lot more stable than people think: I run the daily linux-next on my Debian stable gaming PC to look for bugs, and I don't find very many.

You're being a bit disingenuous, it builds in 90 seconds because you build it daily and the vast majority of objects are unchanged and cached by ccache.

No, I don't think that's what happening actually.

A stripped down cold build will literally take 90 seconds without caching on modern hardware.

The overwhelming majority of stuff that is being built is drivers, and most of them probably aren't needed for any specific user, so you can disable quite a lot of stuff.

Fwiw a full build of the fedora kernel config takes around 5-10m for my 12core ryzen 3900x, and it's definitely not the fastest CPU around.

No, 90 seconds is the clean build time without ccache.

try to build it with make clean first

It's actually faster than I remembered:

  {0}[calvinow@sousa ~/git/linux] git describe
  v7.1
  {0}[calvinow@sousa ~/git/linux] git clean -dffxq
  {0}[calvinow@sousa ~/git/linux] zcat /proc/config.gz > .config
  {0}[calvinow@sousa ~/git/linux] time make -skj32 tar-pkg
  './System.map' -> 'tar-install/boot/System.map-7.1.0'
  '.config' -> 'tar-install/boot/config-7.1.0'
  './vmlinux' -> 'tar-install/boot/vmlinux-7.1.0'
  'arch/x86/boot/bzImage' -> 'tar-install/boot/vmlinuz-7.1.0'
  
  real    0m56.539s
  user    18m41.863s
  sys     2m8.754s

I did that for a while because of compatibility issues with a newer laptop, it works but generally if there is no reason it's way easier to stay with the provided packages. Compiling weekly due to security patches becomes annoying over time for no real gain other than the version number

> It’s fairly easy to build your own kernel packages from vanilla sources in Debian.

IIRC, Debian has a command called "make-kpkg" which does nearly all the work for you, ending up with a installable package which works identically to the standard Debian kernel packages.

I miss the days when my 486 took about 12 hours to compile a kernel

Or it took >15 minutes to generate PGP 2.x private keys due to entropy generation and prime calculations/tests.

what about your carbon footprint

I build using excess solar from my house. The build host is a small arm64 SBC that doesn’t require cooling in my passively cooled garage.

The resources behind your post likely have a larger carbon footprint.

Turn the shed light off overnight and you’re at net zero

They ship every other (boreal!) summer, so more like this time next year.

Wouldn't Forky/14 have this or newer when it releases next year? Debian moves slow - deliberately so, if you want fast use Arch or Fedora - but it does move.

Yes, best guess is forky will adopt the LTS kernel that will release at the end of this calendar year.

doesn't debian usually stick to LTS kernels? afaik 7.0 was designated as an LTS release so it'll probably be the version that next major release will ship with (next year maybe?)

Reply on news.ycombinator.com