Got this installed on all my work machines - if you’re wanting to stick a screenshot on Jira or Slack with a couple of arrows, wavy lines, or a bit blurred out then it’s dead quick and has just the functionality that you need. Yes, it’s simple and lacks a lot of ‘power tools’. Sometimes that’s just what you need, tho.

emerges from a brand you’ve probably never heard of

Writing this on a Tuxedo Pulse 14 / gen 3 as we speak. Great little laptop. I’d wanted something with a few more pixels than my previous machine, and there’s a massive jump from bog-standard 1080p to extremely expensive 4K screens. Three megapixel screen at a premium-but-not-insane price, compiles code like a champion, makes an extremely competent job of 3D gaming, came with Linux and runs it all perfectly.

“Tuxedo Linux”, which is their in-house distro, is Ubuntu + KDE Plasma. Seemed absolutely fine, although I replaced it with Arch btw since that’s more my style. Presumably they’re using Debian for the ARM support on this new one? This one runs pretty cold most of the time, but you definitely know that you’ve got a 54W processor in a very thin mobile device when you try eg. playing simulation games - it gets a bit warm on the knees. “Not x64” would be a deal-breaker for my work, but for most uses the added battery life would be more valuable than the inconvenience.

btw

Finest advice possible for any Linux sysadmin.

Agreed. JSON solves:

• the ‘versioning’ problem, where the data fields change after an update. That’s a nightmare on packed binary; need to write so much code to handle it.
• makes debugging persistence issues easy for developers
• very fast libraries exist for reading and writing it
• actually compresses pretty damn well; you can pass the compress + write to a background thread once you’ve done the fast serialisation, anyway.

For saving games, JSON+gzip is such a good combination that I’d probably never consider anything else.

One of the things that got me to change my gaming desktop from Mint to Arch was the fact that you get the cutting-edge version of everything; kernel and amdgpu being the most important, but also getting the latest version of Lutris and things is nice too. Brought me from “usually about 50 fps outdoors in Elden Ring” to “usually about 60 fps” on the same machine.

Makes sense for a gaming machine to only include the services you actually want, which Arch enables. Supports my hardware better too - my audio gear works perfectly in Pipewire but is ropey in ALSA, so rather than “install Mint -> install Pipewire -> remove ALSA -> hope ALSA is gone”, the sequence is “install Arch -> install Pipewire”, which make more sense.

Other cutting-edge rolling release distros are available, of course, but once you learn Arch, it makes a lot of sense for gaming.

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.

For some reason, I thought that was going to be a twenty-minute video, not a five-and-a-half hour sequence. Dang.

Think you’re understating it there. Network call takes milliseconds at best. Function call, if the CPU has correctly predicted the indirect branch, is basically free, but even if it hasn’t then you’re talking nanoseconds. It’s slower by millions of times.

Been playing it on Arch all morning - runs beautifully straight out the box on a gaming desktop. Forgotten how (a) dark (b) bastard hard it is. Superb game, tho, and all the loading screens being essentially gone adds back a bit of pace it was missing.

And yeah, mapping the weird N64 controller to an xbox pad is always going to be strange - been wasting a lot of items when I’d been intending to look around.

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.

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.)

I prefer the must of white grapes for wine making than the must of red grapes.

The sound will eventually dissipate in the air as heat. The light will be absorbed into surfaces, like any other radiation, as heat. Still 100%, but with a couple extra stops along the way.

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.

That’s almost exactly the problem. English uses helper words exclusively for future tense, and indeed, helper words like ‘to’ to form an infinitive. ‘Will’ is the helper word to show that something is a fact, that it is definite - grammatically, it is indicative. (The sun will rise tomorrow.) ‘Would’ is the helper word to show that something is an opinion, or dependent on something else - grammatically, it is subjunctive. (If you push that, it would fall; if it was cheaper, I would buy it.)

Spanish has both helper words for future tense (conjugations of ‘ir’, analogous to ‘going to’, often used in speech) and straight-up conjugations for future tense (doesn’t exist in English; often used in writing). It also conjugates verbs differently if they’re indicative, subjunctive, or imperative (asking or telling someone to do something). This is how Spanish manages to have fifty-odd ways to conjugate every verb, which is very confusing to English speakers who make do with three ways and helper words.

Translating a ‘future tense sentence’ for Duolingo requires you to have psychic powers about whether something is fact or opinion, which helper words are wanted, and so on, and it usually comes down to guessing between multiple ‘correct’ answers, which Duo will reject all but one of.

Absolutely this. I’d have argued that ‘every day’ is a more idiomatic translation than ‘daily’, and what native speakers would say, but that’s irrelevant. English tends to emphasise the end of sentences as the most important part, so all these translations are correct depending on the nuance that you intend:

• Daily in Hamburg, many ships arrive (as opposed to eg. cars, or few ships)
• Daily, many ships arrive in Hamburg / Many ships arrive daily in Hamburg (as opposed to eg. Bremen)
• Many ships arrive in Hamburg daily (as opposed to eg. weekly)

Wouldn’t question any of those constructions as a native speaker. In fact, original responders’ example was why I gave up on Duolingo myself originally, some years ago. Translating ‘future tense’ sentences from Spanish into English or back again is always going to be a matter of opinion, since English doesn’t have the verb conjugations that Spanish does. Guessing the ‘sanctified answer’ is tedious, when a lot of the time it’s not even the most natural form of a sentence.