addie

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.

Seems fair both ways to me. That doesn't seem an unreasonable amount of pay for a day's work, as even if the 'final product' is only a minute, it will still have stopped him from doing much other work that day. Contrariwise, if he'd been asking for any more, the client would have been able to find someone else to do it just as well at the original price, since the requirement is basically 'clearly spoken'. Wouldn't make sense to get Ian McKellen in to interpret this bit of acting work.

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.

Such a fan that you've gone with the username, too? Good stuff.

Same problem as the old Infocom Hitchhiker's Guide adventure, I think. They'd prioritised making 'Discworld' puzzles over puzzles that were fun, interesting or made any sense. The animation, voice acting still make it an entertaining game if you've got a guide next to you, and it's great seeing how they've interpreted what's in the books onto the screen. The design hasn't aged well, though?

Really? If it's a big enough treatment works to warrant a SCADA, then I doubt an automation engineer with the experience to set it all up would be asking this question, but here goes. You've a couple of obstacles:

• every contract I've ever seen for industrial automation has either specified which control plane they want directly, or they'll have a list of approved suppliers which you must use. Someone after you will have to maintain this. Those maintainers will only accept the things that they have been trained on. Those things are Windows PCs running Windows software. They will reject anything else. The people running network security on those machines will have a very short list of the acceptable operating systems for running SCADA systems. That list will be a couple of versions of Windows Server. They will also reject anything else.

• that's not nearly enough information to make a recommendation. Which PLCs? Allen Bradley, Siemens, Mitsubishi, ...? I can't think of a job I've ever been on where the local HMI hasn't matched the PLCs. The SCADA software almost invariably matches the PLCs used in the main motor control centre, with perhaps a couple of oddball PLCs for proprietary panels and such like. Could maybe ask the supplier if they've a Linux alternative? Siemens will laugh at you and Mitsi won't understand the question, but AB just might.

Sorry - I'm a Linux evangelist, but I don't think it's a good fit for here. SCADA performance generally isn't bad due to Windows Server - it's fine, does what it's intended to - but because eg. STEP 7 is an appallingly slow and bloated piece of software which would bring a mainframe to its knees. Which is bizarre - the over-the-wire protocol connecting the machines is generally a short binary blob described in the PLC configuration - these bits are the drive statuses, these bits are an int or a float for an instrument readout - and it shouldn't be at all slow updating it all, but slow it is.

Nah, it's repeating the installation process until you finally get enough stuff working to have internet, and then you can bootstrap installing every other bit of software that you need. Thank goodness for rolling release - I can't imagine having to go through that again.

There are, but it's complicated. Doom (2016) for instance - it doesn't handle the very large Vulkan swap chain that's possible on some modern graphics cards, crashes on start-up. Someone patched Proton around that time so that Doom would start; the patch was later reverted since it broke other games. Other games based off of that engine - couple of Wolfensteins, Doom Eternal - have the problem fixed in the binaries, and so run on up-to-date Proton, but depending on your hardware, only a few specific, old, versions of Proton, will do for Doom.

Regressions get fixed - that's okay. Buggy behaviour which depended on regressions that got fixed - that's a problem.

Between 'caps lock' -> 'actual control key', 'alt gr' -> 'compose', and 'right ctrl' -> 'virtualbox functions', I'm running out of things that I actually need to remap, or have enough fingers to press without stopping touch-typing. But hey, might come in handy for something...

Spot on advice. I'd observe that media files tend to be quite large, and if all that the disk has been used for has been copying these files onto it, then they're likely to be both relatively defragmented and at the start of the disk, so the reduction in partition size isn't going to be as slow as it usually is. (Which is very slow.)

Since media files are relatively infrequently read, I'd probably want to use a filesystem that checks against bit rot instead of ext4 - make sure that they've not become corrupt when you want to use them. But that's Linux holy war territory, so I'll leave it alone.