The kernel option is mitigations=off, if you want to try adding it to your Grub command line? From the testing I’ve done, provides no benefits whatsoever - no more frames in games, compilation runs no quicker, battery life on a laptop is no better.

https://wiki.archlinux.org/title/Improving_performance#Turn_off_CPU_exploit_mitigations

If you made memory access lines twice as wide, they’d take up more space. More space means (a) chips run slower, because it takes time for the electricity to get there (b) they’d be bigger and more expensive.

The main problem with 32-bit, as others have noticed, is that that’s not really so much RAM. CPUs do addition and subtraction the way we were taught at school - ‘carry the one’, they’ve an overflow bit that’s set when your sum doesn’t fit in the columns. On 8-bit CPUs, we were always checking back when adding up large numbers. On 64-bit CPUs, we can deal with truly massive numbers anyway, it’s not such a hassle. And they’re so fast at doing sums anyway and usually waiting for memory, it’s barely a hassle.

Moving to 128-bit would give us a truly minuscule, probably unmeasurable, benefit in exchange for significant downsides. We could make them, but it would be pointless.

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.

I thought that it was encrypted if your home directory was encrypted? The impression that I got was that it was just a SQLite database stored in the clear. The user must certainly be able to make queries of that database in order for it to work, so even if it’s hosted by a non-user service, malware running locally will still be able to exfiltrate the data.

Nice insight, thank you.

I can see that there will be a range of markets for these. Installing them in the desert (efficiency not as important as pure cost-per-watt, long-term stability very important) is not the same as installing them on your roof (limited space but fairly easy access, payback time dominated by efficiency) and so the ‘customer’ sweet point for these will not be the same as the ‘industrial’ one.

Sorry if I was ambiguous - it was me that received a spectacular number of downvotes for a comment that I’d not think controversial in any way, and then realised that I might as well ignore all that because it doesn’t matter here.

There’s a few arseholes running bots that seem to downvote every post on a topic sometimes. Don’t let that get you down - no point putting more thought into it than they did. Your opinion matters, dude (-ette), don’t let anyone tell you otherwise.

Once you’ve posted a comment that implies that China is imperfect in some way and received a truly spectacular number of downvotes, and then realised that it makes no difference whatsoever because Lemmy votes only affect your ego and nothing else, then you can move on. We aren’t “the other website”.

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

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