Actually, if you check deep down in the list of installables, you'll find that Gentoo still supports the even less capable i486 variant. A laptop from 2010 is positively a spring chicken compared to some of the things it can be made to run on. Itanium is only being desupported because it's being dropped upstream by the kernel and other chunks of the toolchain (and the only actual hardware they had to test on died a while ago).

I only need it for the very occasional testing of open-source software on Windows, using the precanned VM images provided by Microsoft (last I checked, they had none for qemu, or I would be using that instead). And if you're using software commercially, you'd better be damned sure you understand the licensing before setting up. A company of any size will have lawyers vetting that anyway.

In other words, I don't disagree with you, but those issues don't matter for my use case.

Raw qemu at the command line for the one I use on a daily basis (not recommended for the average user). VirtualBox if I need to spin something up quickly but don't expect to need to keep it past the current testing cycle.

ext4 on all hard disks, but my installs are all several years old at this point, and I might choose differently if I were starting over from scratch. The boot partition on the ancient laptop might actually be ext2; I don't remember and it's certainly old enough that that might still have been preferred Gentoo procedure when I first set it up. Removable media might be ext3, ext4, or vfat, depending on compatibility needs and how long ago I formatted it. If I buy an SD card or USB stick that turns out to be preformatted in exFAT, I reformat it before use to ensure everything can read it.

They're all solidly reliable filesystems (well, except for the vfat), but perhaps not the most featureful.

In the general case, no, but there are some rare specific cases where that does work.

If you're trying to produce Linux media that will boot on a single-board computer that has an onboard bootloader, like a Pi 4, you can indeed just partition the target medium and copy the files manually (been there, done that, working with a custom Gentoo install with no ISO).

If the bootloader has to be on the target medium (as it would for a desktop or laptop), then that won't work unless you also do a manual bootloader install after copying everything. Not impossible, but at that point you're hitting the level of complexity where it's easier to figure out the correct dd command.

(As for Windows? Don't even bother. It hates being worked on with anything but its own tools.)

"WM8650" seems to indicate a VIA WonderMedia WM8650 armv5te chipset, used by a lot of anemic Android laptops circa 2011 (sold under various brandnames, but apparently all made in the same factory). People have installed Linux on them in the past (there seems to have been a fad for Arch on these for a while, given the search results), but you might have trouble getting a device tree that will work with a modern kernel.

Honestly, though, it has less processor than a Raspberry Pi 3. Unless you've already thought of a specific use for this, I'd dump it back in the junk drawer.

The Gentoo news post is not about having /bin and /usr/bin as separate directories, which continues to work well to this day (I should know, since that's the setup I have). That configuration is still supported.

The cited post is about having /bin and /usr on separate partitions without using an iniramfs, which is no longer guaranteed to work and had already been awfully iffy for a while before January. Basically, Gentoo is no longer jumping through hoops to make sure that certain files land outside /usr, because it was an awful lot of work to support a very rare configuration.

Gnome and other desktops need to start working on integrating FOSS

In addition to everything everyone else has already said, why does this have anything to do with desktop environments at all? Remember, most open-source software comes from one or two individual programmers scratching a personal itch—not all of it is part of your DE, nor should it be. If someone writes an open-source LLM-driven program that does something useful to a significant segment of the Linux community, it will get packaged by at least some distros, accrete various front-ends in different toolkits, and so on.

However, I don't think that day is coming soon. Most of the things "Apple Intelligence" seems to be intended to fuel are either useless or downright offputting to me, and I doubt I'm the only one—for instance, I don't talk to my computer unless I'm cussing it out, and I'd rather it not understand that. My guess is that the first desktop-directed offering we see in Linux is going to be an image generator frontend, which I don't need but can see use cases for even if usage of the generated images is restricted (see below).

Anyway, if this is your particular itch, you can scratch it—by paying someone to write the code for you (or starting a crowdfunding campaign for same), if you don't know how to do it yourself. If this isn't worth money or time to you, why should it be to anyone else? Linux isn't in competition with the proprietary OSs in the way you seem to think.

As for why LLMs are so heavily disliked in the open-source community? There are three reasons:

1. The fact that they give inaccurate responses, which can be hilarious, dangerous, or tedious depending on the question asked, but a lot of nontechnical people, including management at companies trying to incorporate "AI" into their products, don't realize the answers can be dangerously innacurate.
2. Disputes over the legality and morality of using scraped data in training sets.
3. Disputes over who owns the copyright of LLM-generated code (and other materials, but especiallly code).

Item 1 can theoretically be solved by bigger and better AI models, but 2 and 3 can't be. They have to be decided by the courts, and at an international level, too. We might even be talking treaty negotiations. I'd be surprised if that takes less than ten years. In the meanwhile, for instance, it's very, very dangerous for any open-source project to accept a code patch written with the aid of an LLM—depending on the conclusion the courts come to, it might have to be torn out down the line, along with everything built on top of it. The inability to use LLM output for open source or commercial purposes without taking a big legal risk kneecaps the value of the applications. Unlike Apple or Microsoft, the Linux community can't bribe enough judges to make the problems disappear.

Dude. I actually have sources for most of my installed packages lying around, because Gentoo. Do you know how much space that source code takes up?

Just under 70GB. And pretty much everything but maybe the 10GB of direct git pulls is compressed, one way or another.

That means that even if your distro is big and has 100 people on development, they would each have to read 1GB or more of decompressed source just to cover the subset of packages installed on my system.

How fast do you read?

sudo is already an optional component (yes, really—I don't have it installed). Don't want its attack surface? You can stick with su and its attack surface instead. Either is going to be smaller than systemd's.

systemd's feature creep is only surpassed by that of emacs.

If I recall correctly, ext3 is ext2 with journalling on top, so they can't really get rid of ext2 without also ditching ext3.