It's not only that it was text based, but that it failed in all sorts of ways.
I had a particularly bad afternoon in early 2000s when I tried to install Linux on various machines (4 or 5, each one with different hardware) and failed with all of them. Of course, I wasn't as savvy as I am now, but it's been years since I've seen an issue with a Linux install; although I might have to download and compile a driver for one thing or another, the install itself doesn't fail.
Same with me - late 90s. Celeron 366Mz, 64 MB RAM, 4.3 GB HDD. Don't remember the video card and the sound card. Used to stay up all night to try and fix X11. And once you got it running - victory !!!
It's also the kind of project where LLM license-washing is going to be the most dangerous for the project itself. Projects like Wine and ReactOS have to be extremely careful about what kind of code to accept, because taking code from one of the countless Windows source leaks is just a recipe for legal disaster.
Looks like a lot of improvements on long-standing hard-to-find issues. Kudos to the team and thank you for providing an alternative OS that keeps getting better
One of my favorite projects, maybe someday it can be a true daily driver, I wonder if that's the goal for 1.0 is to claim that they've gotten it stable enough to run as though it were Windows 7 or something to that effect.
TIL that the GUI of ReactOS isn't based on React. All these years spent baffled that who would like to build an OS with JS, thanks to me only reading the headlines lol
I do a lot of industrial automation and it is the one thing that keeps me boat-anchored to Windows. Every little programmable doodad like signal conditioners and temperature transmitters have their own USB programming cables and their own, mostly crappy windows config software. PLC software is another abomination, hopelessly Windows anchored, bloated GUI monsters, some built on top of Visual Studio (Beckhoff TwinCAT.)
I have donated to ReactOS in the past in the hopes of one day freeing myself from this hell.
You can forward USB devices into a VM. About 15 years ago I was using a Windows VM on Linux to program PIC18F??? devices with the custom (JTAG based?) programmer provided by Microchip. The upside is that you can preserve and share this windows environment for other coworkers, and have separate VMs for different projects (perhaps one you can update, and one you can't ...)
This is exactly what I do currently but it's flaky. Bekhoff installs a runtime on the development PC that works its way deep into the system that can and does crash the VM. Some USB devices work, some don't, some are buggy and may hang or fail in the middle of programming. I have to keep a dedicated Win PC just to make sure I have a working Winstall for my work. I keep VM's of 2k, XP, and 7 as I have to maintain a wide variety of hardware and software. I just want off the Windows upgrade treadmill.
Yes, but native open-source drivers are needed for out-of-the-box support, legal compliance, and debugging missing kernel/NDIS APIs during development.
36 comments
[ 0.51 ms ] story [ 12.0 ms ] threadI had a particularly bad afternoon in early 2000s when I tried to install Linux on various machines (4 or 5, each one with different hardware) and failed with all of them. Of course, I wasn't as savvy as I am now, but it's been years since I've seen an issue with a Linux install; although I might have to download and compile a driver for one thing or another, the install itself doesn't fail.
Unrecognized/unsupported hardware is another thing but I always could finish the install and at least reach the console login prompt.
I've never used bleeding edge equipment though, euther second hand or brand new but proven tech.
Now we have an infinite loop
> must be running a 64-bit x86
If you an OS based in JS, maybe the closer we had was NodeOS [1]
[1] https://node-os.com
I have donated to ReactOS in the past in the hopes of one day freeing myself from this hell.
Hasn't the point been for the OS to be compatible with the existing Windows drivers?