Linux 7.1

The old unmaintained ISDN hardware for which the code has been removed is likely 20 years old, or so. The perfectly good laptops are usually 3-4 times younger.

FreeBSD and NetBSD aren't going anywhere and can be used for older hardware, for the amount of production and load bearing use Linux sees there's an enormous amount of cruft and garbage in it.

That's good for your personal computing, but a renewing forest fire is good for all sorts of organizations. And species. It's a very good algorithm to run.

It's naturally de-ossifying and forces uptake of new methods and practices.

It gives you an opportunity to question assumptions and do things greenfield again.

I remember working with a guy who apparently deleted more code than he added in his time at the company. I think it said more about the codebase than anything but it was good that someone was trying to make it better.

>"Perfection is achieved..."

I, too, am a fan of RFC 1925.

Is the parent really being sarcastic? I read it as genuine.

There’s presumably plenty of code bloat in the kernel, and while no human would ever scan for bugs in a corner of the kernel that hasn’t been used or touched in decades, AI 100% will. And while those bug reports might be useless as bug reports, they seem promising as “why is this code even here?” flags.

Exploit paths in unloaded modules, I guess.

Chesterton's Fence only says to learn why the fence was erected, it gives no other guidance on what to do after that. There isn't too much mystery in why a device driver was made, so Chesterton's Fence yields next to nothing here.

It's ok, you can let go of Chesterton's ISDN phone pole now. Come, we have cable, we have fiber. Just for you, I'll even fire up a little hotspot from the palm of my hand as we walk away.

Presumably that old code was actually useful at the time it was added. It might not be used now, but it helped someone back then. One of the great things about early Linux was that it tried to run on every piece of hardware available. If Linus only wrote drivers (or allowed others to submit drivers) that worked on his personal computer, Linux would have never flourished this far.

Ah, it's yet another "let's paper over this firmware bug because the manufacturer can't be arsed to properly support their own product" I see.

What SoC?

Ubuntu switched to the Paragon NTFS driver by default. When I upgraded to kernel 6.5 (I think) from Ubuntu, I started getting frequent kernel panics, like every day. Soon, I noticed that I couldn't even compile a Rust project on an NTFS partition because the compiler was getting random file system errors, and compiling was at high risk of causing a kernel panic. The NTFS driver in that kernel version is just totally broken. I switched to the FUSE NTFS-3G, and then I stopped getting panics and can compile stuff again no problem.

Looking at kernel commits, it looks like the driver may have been fixed since, but I'm scared to use it after it had such major brokenness in that version.

It wound up being OK, but it had a long span of time where it was virtually unmaintained and turned out to be buggy at points. The newer NTFS driver is based off of the old read-only NTFS driver which subjectively many claim is cleaner (I honestly haven't done a head to head so idk) and they're having an easier time modernizing it with support for things like large folios. Seems like a good deal to me.

Personally: I used NTFS3 and it was alright. If anything the biggest thing I got hit by was an issue where the udisks2 mount call from Dolphin would result in NTFS-3g specific flags getting sent to it, causing the mount to fail. But in actual usage it actually worked just fine for me.

The Paragon v3 NTFS driver was in perpetual beta with a scary warning about data loss whenever it was enabled.

I think users moved on when they saw no real harm in continuing to use it.

He's just writing about the changes since last week. Not about 7.1 as a whole. No last minute scary things means 7.1 released as planned.

But 7.1 new features can still be exciting.

But not a very accurate blogpost. "Here's why this literally cannot work (in theory)" to denigrate a system that actually works (in practice). Their goal is to convince people to stop using it because it personally inconveniences them, but they never provide an alternative solution that actually solves the problem (in practice) that Anubis actually solves (in practice). If leaving the problem unsolved (in practice) was a desirable option, the site owner would not have turned to Anubis in the first place.

Aw, but what have you against kawaii?

  Future banned user: It weirds me out a bit how young the mascot looks. I've never been comfortable with cutesy, underage-looking mascots.
  
  The dogpile: How dare you insinuate that the dev a pedophile? Don't you know how anti-trans that dogwhistle is?

Just hope there’s never a Lillypad version

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.

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.

> (granted, all AMD for compatibility)

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

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?

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.

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

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

  {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

what about your carbon footprint

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

yeah about 3 to 5 codes /s