addie

Yeah.

There's a couple of ways of looking at it; general purpose computers generally implement 'soft' real time functionality. It's usually a requirement for music and video production; if you want to keep to a steady 60fps, then you need to update the screen and the audio buffer absolutely every 16 ms. To achieve that, the AV thread runs at a higher priority than any other thread. The real-time scheduler doesn't let a lower-priority thread run until every higher-priority thread is finished. Normally that means worse performance overall, and in some cases can softlock the system - if the AV thread gets stuck in a loop, your computer won't even respond to keyboard input.

Soft real-time is appropriate for when no-one will die if a timeslot is missed. A video stutter won't kill you. Hard real-time is for things like industrial control. If the anti-lock breaks in your car are meant to evaluate your wheels one hundred times a second, then taking 11 ms to evaluate that is a complete system failure, even if the answer is correct. Note that it doesn't matter if it gets the right answer in 1 ms or 9 ms, as long as it never ever takes more than 10. Hard real-time performance does not mean good performance, it means predictable performance.

When we program up PLCs in industrial settings, for our 'critical sections', we'll processor interrupts, so that we know our code will absolutely run in time. We use specialised languages as well - no loops, no recursion - that don't let you do things that can't be checked for an upper time bound. Lots of finite state machines! But when we're done, we know that we've got code that won't miss a time slot in the next twenty years of operation.

That does mean, ironically, that my old Amiga was a better music computer than my current desktop, despite being millions of times less powerful. OctaMED could take over the whole CPU whenever it liked. Whereas a modern desktop might always have to respond to a USB device or a hard drive, leading to a potential stutter at any time. Tiny probability, but not an acceptable one.

I don't think that even 8 years ago, the 'business' choices would have been SUSE / Fedora / Debian. If you're paying for support, then you'd be paying for RHEL, and the second choice would have been Centos, not Fedora. Debian in third place maybe, as it was the normal choice for 'webserver' applications, and then maybe SUSE in fourth.

I know you jest, but I'm going to guess it's for the same reason that the RPCS3 developers didn't just concentrate on the 'popular' games. If they know that all the janky broken games work properly, then they'll have confidence that there's no subtle issues hiding in the nearly-perfect ones. A rising tide lifts all boats.

That's Amaranthe you're thinking of. If you're a fan of the Swedish metal 'soprano and gravel' sound they're well worth a listen.

Not that I'm the biggest fan of CMake's syntax, but they are fairly concise and standardised. The XZ backdoor hid in amongst thousands of lines of autotools jank that very few people would be able to audit. A short CMakeList that generates a Makefile is a much harder place to hide something nefarious.

That's because Arch is the best, so any additional comparisons are just wasting everyone's time ;-)

Ah, that sounds a bit unfortunate. I've run AMD CPUs on Linux desktops with Bulldozer / Piledriver / Ryzen 7, my current laptop is a Ryzen 7 as well, never run into that at all. Hopefully the Arch wiki will sort you out. If not that, the third option would be 'install Linux on an M-series Mac' - don't know how feasible it is at the moment, and paying the 'Mac premium for hardware and software integration and then overwriting the software' doesn't make a lot of sense to me.

Going back a bit, but that old Bruce Willis 'classic' Hudson Hawk. The projector film broke about an hour in, and everyone cheered and about half the people in the cinema took the opportunity to walk out, never to return.

There's also the financial risk to be considered. A mainstream film release from 1970 might have been produced by fifty people, cast and crew combined. The crew for Barbie as per the image above was close to a thousand people. That's expensive. Have to put in twenty times the ante to be in the game, and all the payoff is in established properties that you already know have an audience? It would be foolish to do otherwise.

Like you say, if people actual did what they said they wanted, and go and take a punt on the new stuff rather than going to watch the same-old, then it would be different. But you can't complain about it when that's what you spend your money on.

As a programmer, Vulkan is like OpenGL has decided to stop holding your hand and let you spread your wings. Learning curve is utterly brutal, but no more assumptions - you've complete control and everything is open to you.

As a user? Install Wine and DXVK, or just Proton that brings everything with it, enjoy everything just working better. Not really a tough decision.

Can confirm that this does work perfectly for Lutris, for upgrades at least. I've got my home directory on an NVMe drive and my games installed on a slower disk; as long as you don't move or rename any of the partitions, it just keeps rocking along.

My laptop and desktop have a different list of games installed, but because Lutris uses SQLite as its backing store, it's not terribly easy to keep 'some parts' synchronised and others not. I've spent a bit of time getting all of the icons, banners, release dates, etc all correct and looking pretty, and it's a shame that it's tough to reuse. (Lutris does this automatically for Wine installs if you get the name 'just right' to start with, but not for all your other emulated stuff - all the DOS games and things.)

Using LLMs for corporate communications - automatically-generated complaint responses, and the like - usually has swearing disabled, so if you want to fuck up their shit, be sure to express yourself with as many fucking swears as possible. Let's get that shit into those cunt's language models ASAP.