Gentoo will work if you have the time to work through the install, and stick with provided binaries for large packages (or have a lot of patience with updates).

Gentoo will allow you to update the small set of required system packages and their dependencies separately from everything else (emerge --update system), but doing the reverse would require some pretty heavy micro-management.

exFAT is a Microsoft creation that (unsurprisingly) doesn’t understand or preserve Linux-style file permissions. Neither did any of the FAT varieties before it. So the permissions on the files when you get them back relate to the mount options you pass to the exFAT drive (in this case, you probably want to set dmask and fmask), or the permissions on the directory it’s mounted to.

If you don’t want to twiddle with mount options, you could reformat the external disks using Linux-native filesystems like ext4, but you’ll lose the ability to mount them on Windows if you do that.

Windows just worked.

Excuse me while I laugh hysterically while remembering the sorts of Windows issues I’ve troubleshot for family or coworkers. The one where the combination of a particular Windows version + a particular MS Office version + document previews being activated would cause Office to crash randomly on operations that had nothing to do with document previews was particularly memorable and difficult to figure out. The various Linux snafus I’ve had to deal with were pretty easy to handle by comparison.

Eh, it’s Ubuntu. They have a long history of trying to reinvent the wheel, getting no traction, and then reverting to whatever the rest of the world uses instead. And Linux is full of incompatible parallel packages that provide the same functionality. It ended up not mattering very much with init systems—why should this be any different, even if it’s the one Ubuntu oval-shaped wheel that catches on for some reason?

-nolisten is an actual option passed to the X server—your distro may do so by default—to work around a known security issue in some versions. I admit I’d have to look up the details, as it’s been a couple of years since that issue was reported. Recent X versions almost certainly have a patch.

There are no open security bugs against TDE that I’m aware of—if there were, I’d expect them to be fixed in the next release. In my experience, the development team, while not huge, is active and competent.

I’ve been using TDE since a little while after Gentoo sunsetted KDE3, and I’ve had no issues. Just make sure your X server is secure—-nolisten and all that stuff—and don’t try to use Konqueror as a web browser (it remains an excellent file manager), and you should be fine.

Wayland is “more secure” than X in that it makes less LAN contact by default and tries to sandbox programs from one another to an extent, just in case some future browser exploit that can copy random swathes of your screen tries to screenshot your password manager or something. There are no active exploits against a correctly-configured X server at this time that will magically vanish if you switch to Wayland, as far as I’m aware—it’s more future-proofing stuff.

One thing to keep in mind about older versions of the nvidia proprietary drivers is that they will only work with specific kernel versions (and specific X versions—not sure about Wayland). Once the driver series your card needs stops being updated, you can’t update your kernel without patching the driver. Assuming you have the skills to patch the driver, or someone who does makes their patches public.

I went through this song-and-dance with a very old laptop that had a card of the NV40 generation as its only GPU (no integrated graphics). Eventually I did install nouveau on it, and used it for several years without any issues.

Trinity Desktop Environment, forked from KDE3.

TDE has this natively under the advanced window settings, so I would expect KDE to have it too.

Or ditch udisks in favour of pmount (or udevil?), which shouldn’t be affected as far as I can tell. That will get you a few months’ grace before a similar problem pops up there.

Yeah, that’s how I was taught in school in Canada in the 1980s, although no one ever explained why. It always did seem odd.

What’s the output of cat /proc/asound/cards on your system?

The 6.6.x kernel series is LTS and should be fine as a downgrade target (6.7.x not so much so). Unless there’s something specific from the newer kernel versions that you need to drive that system, there shouldn’t be any issues. I’m still on a 6.6-series kernel.

That being said, you could try troubleshooting this from the bottom up rather than the top down.

First, use lspci -v to verify that the device is being correctly identified and associated with a driver.

Next, invoke alsamixer and make sure everything is unmuted and your HD audio controller is the first sound device. The last time I had something like this happen to me, the issue turned out to be that the main soundcard slot was being hijacked by an HDMI audio output that I didn’t want and wasn’t using, and that was somehow muting the sound at the audio jack even when I tried to switch to it. A little mucking around in ALSA-level config files fixed everything.

Wild idea: check the condition of the SDD (presumably) that you’re trying to install to. After all, an installation has two endpoints, and if the target disc is on its last legs and throwing SMART errors, it ain’t gonna be too happy getting written to.

Automated command-line jobs, in my case, which are technically not random but still annoying, because they don’t need to show a window at all. Interestingly, the one thing I can get to absolutely not pop up any window ever are Perl scripts using Win32::Detached . . . which means that it is possible, but Microsoft doesn’t bother to expose such a facility.

I wouldn’t say the proprietary nvidia drivers are any worse than the open-source AMD drivers in terms of stability and performance (nouveau is far inferior to either). Their main issue is that they tend to be desupported long before the hardware breaks, leaving you with the choice of either nouveau or keeping an old kernel (and X version if using X—not sure how things work with Wayland) for compatibility with the old proprietary drivers.

If those are your criteria, I would go with AMD right now, because only the proprietary driver will get decent performance out of most nVidia cards. Nouveau is reverse-engineered and can’t tap into a lot of features of newer cards especially, and while I seem to recall there is a new open-source driver in the works, there’s no way it’s mature enough to be an option for anyone but testers.

Unfortunately, modern web browsers are horrible pigs. No matter what distro you put on this thing, interacting with webpages will be s-l-o-w. (I have a similar laptop—2 GB RAM, Athlon64x2 CPU—running Gentoo, and while it’s functional in its primary job of “larger-screen video iPod for 720p or less”, starting a browser takes a while.) The niche your friend wants to make this machine fill is about the worst one possible for it.

The performance boost provided by compiling for your specific CPU is real but not terribly large (<10% in the last tests I saw some years ago). Probably not noticeable on common arches unless you’re running CPU-intensive software frequently.

Feature selection has some knockon effects. Tailored features mean that you don’t have to install masses of libraries for features you don’t want, which come with their own bugs and security issues. The number of vulnerabilities added and the amount of disk space chewed up usually isn’t large for any one library, but once you’re talking about a hundred or more, it does add up.

Occasionally, feature selection prevents mutually contradictory features from fighting each other—for instance, a custom kernel that doesn’t include the nouveau drivers isn’t going to have nouveau fighting the proprietary nvidia drivers for command of the system’s video card, as happened to an acquaintance of mine who was running Ubuntu (I ended up coaching her through blacklisting nouveau). These cases are very rare, however.

Disabling features may allow software to run on rare or very new architectures where some libraries aren’t available, or aren’t available yet. This is more interesting for up-and-coming arches like riscv than dying ones like mips, but it holds for both.

One specific pro-compile case I can think of that involves neither features nor optimization is that of aseprite, a pixel graphics program. The last time I checked, it had a rather strange licensing setup that made compiling it yourself the best choice for obtaining it legally.

(Gentoo user, so I build everything myself. Except rust. That one isn’t worth the effort.)