Yeah, I’m not against the idea philosophically. Especially for security. I love the idea of containerized isolation.

But in reality, I can see exactly how much disk space and RAM and CPU and bandwidth they take, heh. Maintainers just can’t help themselves.

I find the overhead of docker crazy, especially for simpler apps. Like, do I really need 150GB of hard drive space, an extensive poorly documented config, and a whole nested computer running just because some project refuses to fix their dependency hell?

Yet it’s so common. It does feel like usability has gone on the back burner, at least in some sectors of software. And it’s such a relief when I read that some project consolidated dependencies down to C++ or Rust, and it will just run and give me feedback without shipping a whole subcomputer.

I don’t want to leap into your throat, but have you tried a clean install of a different distro on a USB? And I mean clean; no reusing your home partition, no weird configs until you test out-of-the-box settings.

One thing I’ve come to realize is that I have tons of cruft, workarounds, and configurations in my system that, to be blunt, screw up Nvidia + Wayland. And my install isn’t even that old.

Hunting them all down would take so long that I mind as well clean install CachyOS.

I haven’t bitten the bullet yet (as I just run Linux off my AMD IGP, which frees up CUDA VRAM anyway), but it’s feeling more urgent by the day.

The real issue is devs not wanting to pay for hosting server side anticheat. I

Or allowing self hosted servers. With actual mods that just ban people who are being jerks, and basic anticheat tools shipped to them.

Whatever the issue and solution, the current state of the gaming market still makes mass linux gaming kind of impossible. Not from the anticheat games specifically as much as the OEM problem.

Gaming is the best commercial inroad I’ve seen, and exploding.

But I think the “kernel anticheat” thing is going to be a hard wall until Valve works it out. Unfortunately, big OEMs don’t want to ship a “gaming PC” that can’t run Fortnite.

Ah.

Well one catch I’ve found outside of CachyOS is that if something isn’t working right, it’s easy to create a ton of work for yourself trying to fix it. An example would be fighting your system trying to roll a package forward for a fix, which then gets out of sync with your distro, which requires more manual fixing since you’re the one maintaining it now…

The Arch/Cachy ecosystem, on the other hand, tends to encourage more usage of system packages, and fixes stuff quick. Usually waiting a day or a few days + a pacman -Syyuu fixes what was wrong.

If your Dad is a software engineer, it’s possible he might fall into that trap with Bazzite. It kinda just depends on his habits/personality, though from what you describe this may not be a huge danger.

AFAIK CachyOS still demands a little involvement in the OS. Like, you have to watch the logs when you update, you need keep context in mind, like knowing you’re running KDE and an Nvidia card and so on. But I feel like Bazzite would be more usable to someone who doesn’t know (and doesn’t need to know) what a filesystem or a discrete GPU are.

But in terms of stability, CachyOS has been rock solid for me. The cadence that Arch + CachyOS devs fix stuff has been utterly perfect.

So I say if your dad is more ‘software curious,’ give him CachyOS. If he doesn’t like messing with computer stuff, give him Bazzite.

Well, the next question is “what do you do when you drive?” Cars and trucks have wildly different roles they’re good at.

So basically, what do you want your computer to be good at doing? That dictates your hardware purchase and the OS you will end up using.

If you have a desktop/laptop, you run Linux.

If you have a Mac, you run OSX.

Im not sure where you’re going with this OP, unless you’re looking for purchasing advice. It’s kinda like asking if a car or truck tire is better, with the answer being “well, do you have a car or a truck?”

Neat! Bookmarking that, thanks.

Mint.

You’re already familiar with it, so it will just be the least time invested doing stuff.

If you’re trying to squeeze out performance/efficiency, you can load CachyOS and play with it. As an example, it has a scheduler (lavd) specifically designed to minimize idle power use, and another one (tickless) specifically optimized for docker containers/VMs. It has easy access to optimized Java to make modded Minecraft faster. Stuff like that. But ask yourself if you want to spend time messing with that.

I just let KDE handle it. I think… it was a long time ago. I’ll turn on my PC and check my fstab in a sec.

But yeah. I’d recommend a fresh install, with the philosophy of “don’t mess with the defaults unless it isn’t working, or you have a very good reason.” As not only are CachyOS defaults pretty good, but they’re set up in a way so the system will maintain itself through updates.

It’s (ironically) very different than my experience with Ubuntu, where I had to manually maintain a bunch of stuff and fight the system packages.

I think I may have installed ntfs-3g before the reboot

Isn’t this the legacy driver? Why do you need it?

…Respectfully, it feels like you’re falling into the classic Arch trap of “messing with too much stuff.”

I mount a whole bunch of NTFS Sata partitions at boot, on CachyOS, and they don’t need a password or FUSE driver package or anything. It just works out of the box. The only thing I chose to mess with was adding a single mount flag in fstab, and only so it plays with Windows permissions better.

https://github.com/vladmandic/sdnext

• For LLM hosting, ik_llama.cpp. You can really gigantic models at acceptable speeds with its hybrid CPU/GPU focus, at higher quality/speed than mainline llama.cpp, and it has several built in UIs.

• LanguageTool, for self run grammar/spelling/style checking.

Keep an eye on Open Web UI. I’ve heard rumblings that it’s starting to enshittify.

FYI, A1111 is obsolete. The diffusers or comfy-based backends are way faster, richer, less buggy and support newer things.

I’d recommend UIs that support SVDQuant, in particular.

I suppose not. Not yet.

I know people are particular about WMs, but having to minimize a window vs keeping the window decoration in place seems like a… very minor distinction.

Is the use case rearranging a ton of windows? Something like that?

Oops, thanks.

Apparently, this is hardly hyperbole. For example: https://bugs.kde.org/show_bug.cgi?id=377162

Talk about arrogance. In the window paradigm, only a few desktops ever REQUIRED a similar look and feel for all windows. Apple was the worst offender for that. I suggest that if Edmundson wants a similar look and feel, he should go get himself a Mac and stop mucking up KDE.

From a quick look at the proposed patch - and obviously without having the full picture - it’s true that it would add some complexity. But it’s code for the sake of people’s convenience, not the other way around, right? IMHO, as long as:

• shading is off by default,
• users get a clear message about limitations and SSD/CSD complications before enabling it,
• the implementation doesn’t introduce impossible-to-maintain logic and limits some weird edge cases like resizing a shaded window, then it’s worth doing.