Should have used Vim instead, that’s a real text editor. No-one who starts using it ever moves on to something else.

When I was still dual-booting Windows and Linux, I found that “raw disk” mode virtual machines worked wonders. I used VirtualBox, so you’d want a guide somewhat like this: https://superuser.com/questions/495025/use-physical-harddisk-in-virtual-box - other VM solutions are available, which don’t require you to accept an agreement with Oracle.

Essentially, rather than setting aside a file on disk as your VM’s disk, you can set aside a whole existing disk. That can be a disk that already has Windows installed on it, it doesn’t erase what you have. Then you can start Windows in a VM and let it do its updates - since it can’t see the bootloader from within the VM, it can’t removed it up. You can run any software that doesn’t have particularly high graphics requirement, too.

I was also able to just “restart in Windows” if I wanted full performance for a game or something like that, but since Linux has gotten very good indeed at running games, that became less and less necessary until one day I just erased my Windows partition to recover the space.

Yes, because it doesn’t do as much to protect you from data corruption.

If you have a use case where a barely-measurable increase in speed is essential, but not so essential that you wouldn’t just pay for more RAM to keep it in cache, and also it doesn’t matter if you get the wrong answer because you’ve not noticed the disk is failing, and you can afford to lose everything in the case of a power cut, then sure, use a legacy filesystem. Otherwise, use a modern one.

Note that bookmakers set their odds to minimise their own potential losses - if more bets are placed on a team, then they’ll reduce the odds. So this graph will be weighted towards the larger bets placed by supporters of the wealthier nations.

Still cool, 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.

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.

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.

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.

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.

Humble guy, but that list of features that they’re working on is really impressive. Got a wee DragonFly Black USB audio thing that just never worked quite right with PulseAudio - install PipeWire instead, and it just does all its tricks. Great work team, keep it up.

I still have a Rage 128 hanging around as a ‘temporary head’ for installing headless servers. Many happy nights playing Thief: The Dark Project with it, and now it’s only good for rendering a TTY at a barely acceptable resolution. And soon, not even that. Goodbye, little e-waste :-(

I’d kind of hope that we’re not all like that - I use Arch btw. for my computers at home, but at work we use a combination of Redhat, Centos Stream and Amazon Linux, and I spend a lot of my day helping people with ‘Linux admin’ issues even though that’s not strictly my job.

When getting started with Linux, there’s a certain ‘glossary gap’ if you’ve come from Windows, not even knowing the right term to search for. Newstarts will complain that “waa! Linux is terrible, doesn’t recognise my hardware”, to which invoking a couple of udev commands seems like magic. Some people will get irritated when answering the same question in the same way for the tenth time and just post a link; really, those people need to step back and let someone else pick it up. The Arch wiki is fantastic, but it’s particularly fantastic if you already know what all the words mean and just need your memory prodding a bit. Having someone able to interpret a page for you is a huge benefit over having to fall down a wiki hole, which is very dispiriting when you’re trying to learn.

And yes, Arch is great for gaming - latest version of everything, look at my extra frames - but really, it’s only a tiny bit better than eg. Pop! OS, and that’s a much better choice for someone who’s never used Linux before.

Yeah; my somewhat up-to-date thinkbook with NVMe drive cold boots to Cinnamon desktop in under 8 seconds, terminal window opens in the blink of an eye. BTRFS is not without its problems, but they’re more along the lines of specific RAID configs not being what you’d wish for; I’ve never heard a complaint about speed before, and I’ve never had that problem myself.

Can also recommend Just For Fun - that Finnish sense of humour doesn’t come across well, and while he’s good with English he certainly isn’t Shakespeare, but it does fly by.

History of Linux, abridged: Linus was using Minix on his own PC while at University, but was a bit fed up with its networking capabilities, so he’d written a toy operating system for a couple of his classes. While experimenting with adding features to it, he deleted his Minix partition by accident. Might as well continue with the one he’d written, since it was almost capable enough to be a daily driver. Publish the source, get a few collaborators in to add in the features that they found most useful, repeat. Boom.

Cool, will have a look at those, thanks! More looking to impress with my knowledge of using a variety of bugtrackers; have got plenty of evidence to show that there’s a couple I know how to use.