nyan

Early true BIOSen were stored on EPROM, which couldn't be rewritten while on the board, so those were read-only.

Later BIOSen were often on EEPROM or other chips that could be reflashed while on the board. According to Wikipedia, that started in the mid-1990s. However, you usually needed physical access and/or special software tools to do an overwrite—you couldn't mount these as a filesystem.

UEFI is quite different from legacy BIOSen and can be mounted as a filesystem, but how much it can be tampered with varies between implementations and devices.

So you would have been correct up until about 30 years ago, but not for modern systems.

Gentoo specifically switches off the telemetry (-Daudacity_has_sentry_reporting=off,-Daudacity_has_crashreports=off). The cloud saving facility is also off by default, but can be added to the build by enabling the audiocom USE flag.

The method of last resort would be to place the files you want shared on a virtual drive that you pass to the Windows guest, then mount that virtual drive as a loopback device under Linux. I have only done this for very old versions of Windows that can't talk to normally configured current versions of Samba, so I don't know how it will behave with 11—simultaneous access doesn't really work with my Win 98SE guest, but the method is adequate for passing files back and forth.

(The person who suggested wsdd2 is likely right on the money, though—a Samba share won't be browsable without it from modern Windows, although you may still be able to connect to it blind if you know the address. Problem is, in my experiences with Samba, the address was usually not quite what I expected . . .)

Surely the bomb isn't the only computer in the immediate area.

What I've always wondered about that one is: why bother forbidding Google but not 'man tar'? 🤨

I've got a 6TB SATA HDD (also formatted ext4) and while files on it don't always open instantaneously, the pause is only a fraction of a second at most (barely enough to notice). So I'll join the chorus suggesting you check for hardware issues—bad drive, bad or loose cables, or a bad controller on the mobo.

Reading between the lines on the gentoo-dev mailing list, I gather that the old system just was not working very well, with friction between the Foundation and the technical side of the distro.

ext4 is still solid for most use cases (I also use it). It's not innovative, and possibly not as performant as the newer file systems, but if you're okay with that there's nothing wrong with using it. I intend to look into xfs and btrfs the next time I spin up a new drive or a new machine, but there's no hurry (and I may not switch even then).

There's an unfortunate tendency for people who like to have the newest and greatest software to assume that the old code their new-shiny is supposed to replace is broken. That's seldom actually the case: if the old software has been performing correctly all this time, it's usually still good for its original use case and within the scope of its original limitations and environment. It only becomes truly broken when the appropriate environment can't be easily reproduced or one of the limitations becomes a significant security hole.

That doesn't mean that shiny new software with new features is bad, or that there isn't some old software that has never quite performed properly, just that if it ain't broke, it's okay to set a conservative upgrade schedule.

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

Simply put, no one with the necessary skills has come forward and demonstrated the willingness to do the work. No programmer I've ever met enjoys wrestling with other people's crufty old code. It isn't fun, it isn't creative, and it's often an exercise in, "What the unholy fsck was whoever wrote this thinking, and where did I put the 'Bang head here' mousepad?" So getting volunteers to mop out the bilges only happens when someone really wants to keep a particular piece of software working. It's actually more difficult than getting people to contribute to a new project.

So getting rid of X's accumulated legacy cruft isn't impossible, but I suspect someone would need to set up the "Clean up X" foundation and offer money for it to actually happen. (I'm no happier about that than you, by the way.)

Start with a minimalist distro that ships without any desktop environment, of which there are many.

You sometimes can build software that will work with more than one version of a C library, but less and less software is being written that binds only to C libraries. The key topic you want to look up is probably "ABI stability".