Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>The solution is to run Linux.

The Linux answer is often repeated but unfortunately, some users depend on various Windows software that only runs properly on Windows. E.g. CAD/CAM, Quicken finance, sewing embroidery, etc can't run in a Linux WINE emulator nor QEMU/KVM virtual machine. And avoiding the WINE/KVM incompatibilities by switching to "Linux-native" software such as Gimp often means having less features and/or not having ability to open old files because they use different formats.

Sure, there's the idea that "90% of users just use email and surf the web so they can just get by with a Chromebook" ... true, but there's still a lot of users who can't because they use other productivity software.

For me, there's always some unexpected situation that requires a working Windows computer. Last year, I had to do an unplanned firmware update on a digital audio interface via a USB cable. There was no Linux updater. They had a firmware updater for macOS but it didn't work. Based on the tech support forums, I had to download the firmware updater for Windows platform and that finally worked.

reply to: >What software do you have that doesn't work in a VM?

Example would be software that use hardware USB dongles for DRM. E.g. embroidery software for sewing machines. The passthrough USB emulation to the vm is not invisible enough to fool the software searching for hardware dongles. Another example was Trimble software for LIDAR that depended on DirectX which crashed in a vm.

reply to: >A good-enough compromise is a dual boot with a tiny Windows partition for the rare cases

That is a very techie solution that's not practical for "normies". Dual-boot creates the "2 os file systems" issue instead of having a single unified disk mount. Windows doesn't have a built-in way to read Linux ext4 file system. Linux doesn't have a bulletproof reliable way to read/Write NTFS partition (various tech forums mention data corruption). Unless one goes external with external NAS hardware and store all documents on an SMB mount -- but that also layers on more technical issues and doesn't work for laptops on-the-go being disconnected from the NAS.

Manufacturing and automation is another big one. Think about a water plant that is air-gapped but needs computer automation software to run. These things are everywhere, in every town that has indoor plumbing and sewer. The specialized software that automates these plants only runs on Windows. It relies on industrial hardware and touchscreens that are designed for use in harsh outdoor environments. All of these types of plants rely on high school educated operators that need to understand what's going on at a simple level. Having an OS that in any way relies on Internet access is a non starter. A Linux based system would be removed within a year of operation. You could get it approved maybe if you really worked at it but it would not be accepted in the long run, after the initial startup. There are physical constraints, technical constraints, and human/political constraints that are all working against Linux.

Most of that stuff is probably still running windows 98 or XP. If it's airgapped, and it works, and it controls a million dollar piece of equipment, then management will tell anybody suggesting it be updated to the newest windows version to stfu.

Also, the extent to which windows is needed to accommodate uneducated operators is overstated. A lot of industrial equipment runs other oddball operating systems configured by the manufacturer and machine operators don't need to know the difference because they just know which buttons to press to get the job done.

I work in a lab. Let me give you some ideea of what's happening:

- Some machines use embedded MCUs with no operating systems. I haven't seen one of these in the last 15 years. The last DNA extraction machine we got (a glorified sample shaker with 2 stepper motors) runs Win10! It has no keyboard, no network, and absolutely no ports of any kind (or at least not accessible without dissasembling the machine). A 8051 could do the job and still have memory left for Pong. [1]

- Very old machines run MSDOS and a proprietary software that directly talks to hardware ISA boards via I/O ports - no drivers. That software can't be ported to Windows2000+ because of the same reasons DOS games can't run in Win2000 - the kernel won't allow direct hardware access. Linux doens't allow it either.

- Newer machines run Windows 2000/XP/7/10, many of them offline. Some of them were updated to run Win10 from older versions, with the same app version (just Windows updated).

- Since Win10 can no longer be bought, newer machines run Win11 with permanent internet connection and they are minimally customized - the vendors left all ads, Copilot, Store and the kitchen sink installed. It's atrocious to work with those, but nobody cares. The management that make the decisions to buy the machines never ever touch them or even see them, and they don't take advice or feedback from us (or anyone else but accounting).

[1] https://gentechbio.com/en/producto/panamax-48/

Can you explain why you think Linux needs the internet any more than windows does?

Are you perhaps not aware of the millions of embedded Linux installations that never see the internet?

After rereading, it sounds like I meant for the two sentences to be related, but I didn't mean it that way. I was referring to the fact of Microsoft trying to force people to connect to the Internet before they can install Windows, or sign in with a Microsoft account in corporate infrastructure scenarios where that makes no sense, and so customers are forced to use Linux instead, but that's a complication being added to their overall system for external reasons.

A Linux-based system would be identical to a Windows-based system as far as operator experience goes. They interact with HMI software and only see the OS underneath when Windows pops up silly notifications and errors.

Windows owns the industrial space for historical reasons, mostly to do with OPC being Windows-only and software for doing maintenance on field devices originally running on DOS. It quickly became a chicken-and-egg situation - everyone wrote their software for Windows because everyone else wrote their software for Windows. SCO owned a decent chunk of the field before that, but we know how that worked out.

We're seeing some change now that OPC is being phased out. Ignition now has feature parity between Linux and Windows (barring OPC, of course). Windows won't go away any time soon (if ever), but you can now have a fully functioning SCADA system with no Windows at all.

What software do you have that doesn't work in a VM? Without going to extra effort the environment should be indistinguishable for the application.

For me it's ski race timing Software. Need a USB dongle and timing computer(a proprietary device that logs timestamps, prints and translates pulses offa wire into start and finish events to the PC Software) via USB. There's a lot of moving parts to manage, things like power to the USB, sleep etc. Bricking a ski race where thousands of volunteer, kid and coach hours have been spent in preparation for it is a nightmare. Last season our windows machines were in a Windows update death spiral on race day. The timing operators had no clue how to overcome it.

USB passthrough is trivial, as is PCIe passthrough which would let you pass the entire USB controller.

Yeah this is the way. I'm tented to go this route on my Mac but the licensing module won't work on ARM chips: Short answer: it’s not crazy to run Split Second in a VM—but only if you control the variables. The two biggest risk areas you called out (the USB license dongle and the timer I/O) are real. Here’s the straight path that works reliably, plus what to avoid.

Your go/no-go decision tree

1) If your MacBook Pro is Apple Silicon (M1/M2/M3): Running Split Second in Parallels with Windows 11 ARM is a no-go because the Sentinel/HASP hardware key that Split Second uses is not supported on Windows ARM. Thales (the dongle vendor) is explicit: “Sentinel HASP keys … are not supported” on Windows ARM; LDK works via emulation but not the HASP/HASP-HL USB keys you plug in.

i 100% get what you mean, it's still funny to me that you indirectly use a Windows update death spiral as an argument against using Linux :D

I'm all for Linux, The difficulty of keeping it on the shelf for a year and then running it on race days when it's in full update mode on a crappy mountain Internet connection was a near disaster.

I really wish this 3D Gerber viewer worked: https://www.zofzpcb.com/

You can feed it the output from Kicad, and if you include the ipc netlist it’ll even generate models. Great for doing a check before manufacturing, especially if the viewer matches what you see in Kicad.

Unfortunately I’ve never gotten it to run in wine.

Have you tried PCI passthrough of a USB bus? Worked for me with a device that didn't work with regular USB passthrough.

Agree on all points. Basically, Windows could suck to any degree whatsoever right now, it still has enjoyed an hegemony for decades and the vast majority of the population considers it the default, it's not impossible for this to change, but it's definitely going to take time.

A good-enough compromise is a dual boot with a tiny Windows partition for the rare cases

Rufis can make windows on-the-go installs too for this purpose.

Reply on news.ycombinator.com