Jesus_666

Ah, so they actually got that implemented. Nice.

Garuda for me. The reasons are similar; just replace some optimization with some convenience. It's a bit garish by default but pleasant to use.

Flatpak has its benefits, but there are tradeoffs as well. I think it makes a lot of sense for proprietary software.

For everything else I do prefer native packages since they have fewer issues with interop. The space efficiency isn't even that important to me; even if space issues should arise, those are relatively easy to work around. But if your password manager can't talk to your browser because the security model has no solution for safe arbitrary IPC, you're SOL.

I run Garuda on my 16 and my desktop PC.

It's basically a KDE-centric Arch build but with some quality of life tools and XTREME GAMER default theming, plus you're not legally required to say you're using Arch all the time.

No complaints so far. Sure, you're expected to update all packages on your computer about once per day but I find that process to be fairly smooth. You can always configure your desktop to stop looking like a bordello for dragons and I rather like how garuda-update automates some of the housekeeping involved with the package manager.

If I had to pick a different distro I'd probably try out something immutable but so far I have no intention to switch.

Exactly. If this was "Marathon: Return to Deimos" or "Marathon: Battleroid Arena" or even "Marathon Infinity Plus One" I wouldn't complain. Much.

But just taking the name (and logo) of the original one? The game that started Bungie's path towards being one of the big names of the FPS genre? That's like saying they went straight from Pathways Into Darkness to Halo. That's not honoring Marathon, it's a soulless recycling of an old IP.

My vent cores feel distinctly unblasted.

Man, I hate it when they make new games that have exactly the same name as an older game by the same company. And this one's not even a remake. I have no idea if Marathon (1994) and Marathon (upcoming) even play in the same universe but they don't seem to have much in common gameplay-wise. Ugh.

Makes me wanna install ~~M1A1~~ Aleph One (didn't know it does M1 directly these days) and shoot some Pfhor, though.

"You finished a computer game, Atticus."

The truth was a burning green crack through my brain.

Credits scrolling by, a reminder of the talent behind a just-finished journey. The feeling of triumph, slowly replaced by the creeping grayness of ordinary life.

I had finished a computer game. Funny as hell, it was the most horrible thing I could think of.

Hoo boy, you weren't kidding. I find it amazing how quickly this went from "the kernel team is enforcing sanctions" to an an unfriendly abstract debate about the definition of liberalism. I shouldn't, really, but I still am.

Oh yeah, the equation completely changes for the cloud. I'm only familiar with local usage where you can't easily scale out of your resource constraints (and into budgetary ones). It's certainly easier to pivot to a different vendor/ecosystem locally.

By the way, AMD does have one additional edge locally: They tend to put more RAM into consumer GPUs at a comparable price point – for example, the 7900 XTX competes with the 4080 on price but has as much memory as a 4090. In systems with one or few GPUs (like a hobbyist mixed-use machine) those few extra gigabytes can make a real difference. Of course this leads to a trade-off between Nvidia's superior speed and AMD's superior capacity.

These days ROCm support is more common than a few years ago so you're no longer entirely dependent on CUDA for machine learning. (Although I wish fewer tools required non-CUDA users to manually install Torch in their venv because the auto-installer assumes CUDA. At least take a parameter or something if you don't want to implement autodetection.)

Nvidia's Linux drivers generally are a bit behind AMD's; e.g. driver versions before 555 tended not to play well with Wayland.

Also, Nvidia's drivers tend not to give any meaningful information in case of a problem. There's typically just an error code for "the driver has crashed", no matter what reason it crashed for.

Personal anecdote for the last one: I had a wonky 4080 and tracing the problem to the card took months because the log (both on Linux and Windows) didn't contain error information beyond "something bad happened" and the behavior had dozens of possible causes, ranging from "the 4080 is unstable if you use XMP on some mainboards" over "some BIOS setting might need to be changed" and "sometimes the card doesn't like a specific CPU/PSU/RAM/mainboard" to "it's a manufacturing defect".

Sure, manufacturing defects can happen to anyone; I can't fault Nvidia for that. But the combination of useless logs and 4000-series cards having so many things they can possibly (but rarely) get hung up on made error diagnosis incredibly painful. I finally just bought a 7900 XTX instead. It's slower but I like the driver better.

They did PR campaigns against Linux and OpenOffice for quite some time – until cloud computing took off and it turned out they could earn more money by supporting Linux than by fighting it.

In fact, Microsoft weren't happy about FOSS in general. I can still remember when they tried to make "shared source" a thing: They made their own ersatz OSI with its own set of licenses, some of which didn't grant proper reuse rights – like only allowing you to use the source code to write Windows applications.

And I wouldn't know where to start using it. My problems are often of the "integrate two badly documented company-internal APIs" variety. LLMs can't do shit about that; they weren't trained for it.

They're nice for basic rote work but that's often not what you deal with in a mature codebase.