Linux will soon offer switchable x86-32 binary support

The merge window has opened for what will become Linux version 6.7, and below we've compiled some things that are likely to be included in the new release. Now that really not very devilish kernel 6.6 is out, we can start to look forward to what will make up the next release, which will probably be finished some time early in …

[Orv]

Oh man, that list of cards takes me back. Especially the Orinoco cards, which at one point were the standard thing to buy if you wanted a PCMCIA WiFi card that would work with Linux. They came in two varieties, Orinoco Gold and Orinoco Silver, depending on what level of WEP encryption they supported.

[Liam Proven]

[Author here]

> hat list of cards takes me back

It could cause a tiny spike in supply of vintage wifi cards on the used market, which will be good news to fans of retro kit like Amiga 1200s and Psion Netbooks who want to put them on WLANs. :-)

[Anonymous Coward]

IIRC, the Gold firmware was applicable to Silver cards so they could also use 128-bit WEP.

Later firmware also enabled WPA-TKIP support.

[Gene Cash]

"one with 32-bit support and another without"

Alright, that raises a couple questions:

I assume from the discussion that the 32-bit support can't be compiled into a module.

If that's true, then how much does it cost? How much bigger is a kernel with it? I get the feeling it's less than 500K or so, a drop in the bucket when you've got 32GB of storage in a typical PC these days.

[Anonymous Coward]

Re: "one with 32-bit support and another without"

The Kernel isn't *that* big a deal with respect to 32-bit support. The enormous raft of libraries you will have in duplicate for -32 and -64 are more of a headache; and all the maintenance that generates.

But as the original post noted there are loads of legacy applications that people most definitely still want to run that aren't likely to be re-compiled.

I actually wonder if there is a sensible decision to be made here about having two lines of development go off their separate directions; one, a thoroughly modern and current system deliberately free of legacy cruft; the other, one with the compatibility features. Of course, we already know which would be the most popular by a large margin; which is why this won't happen.

[Ian 55]

Re: "one with 32-bit support and another without"

Hmm, depends on what you want to do. Take away the games played through Steam and I don't think I have anything that needs the 32-bit libraries.

But it depends on what you think is legacy cruft, and gamers are going to want to game on their new hardware, not just their 'legacy' kit.

[Mockup1974]

Can't believe they drop Itanium support before HP-UX is even dead!

[l8gravely]

bcachefs is exciting

I'm really excited to see how bcachefs works in practice. It's always good to see a new filesystem, and even though I won't use btrfs because I suspect it will hose me if I stare at it too long (shakes fist at sky for failed SLES 12 to 15 upgrades using btrfs!) it's also good to see new ideas on filesystems and snapshots and such. ZFS had such high hopes, but the volume management aspects were horrible. Having to replace ALL the vvols when you tried to grow, ugh!

Which is why I still like disk(s) -> LVM -> filesystems levels of abstraction. Being able to move filesystems around without caring about the underlying disks is wonderful. Having each layer of the stack concentrate on it's particular area simplifies things. Keeping nice seperations between layers is also good. zfs and btrfs both tried to combine multiple layers and both, IMNSHO, screwed it up.

[Liam Proven]

Re: bcachefs is exciting

[Author here]

> zfs and btrfs both tried to combine multiple layers and both, IMNSHO, screwed it up.

I am curious: how do you feel ZFS screwed this up?

I liked the separation myself, and though it was cleaner... until I saw how easy ZFS was to get running.

If we wanted cleanly-separated code, we should all be running Plan 9.

[Grogan]

More hoops for users to jump through. Seriously, if I had to eat dogfood from distros like Redhat/Fedora, Ubuntu or even Debian with their ridiculous policies, I would use another platform.

"All they have to do change their kernel command line and reboot" <--- lol

[Ian 55]

There would be a (very small) program

.. to do that in any distro worth the name.

Or have it as a GRUB option for the distro's boot options, instead of just 'yadistro' / 'yadistro (recovery mode)'.

[Nintendo1889]

Not trolling but hasn't MacOS had support for 32 and 64 bit apps from the start? But they removed it in 12.15.