31–40 of 48 posts
Earlier quoted context omitted.
Because that requires breaking the almost assured stipulation in a software license agreement that says "You will not try to RE this software", which is fine to ignore for home gamers, but not something you generally want to mess around with in a business setting where the risks are much higher.
Reverse engineering is protected under certain conditions, even if the EULA prohibits it
This seems like the sort of project that ai would excel at. /goal excel runs flawlessly.
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.
Earlier quoted context omitted.
Now all we need is an alternative clean-room implementation of Mac OS.
You should take a look at ravynOS! https://ravynos.com/
This reminds me of the feeling of when Linux got graphical installers instead of long text based ones asking you many, many questions.
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 o…
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.
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
If you an OS based in JS, maybe the closer we had was NodeOS [1]
Earlier quoted context omitted.
The reason industrial PLCs cost so much is because of their reliability. They need to be working flawlessly 50 years in the future. Trying to vibe code your way into a PLC compiler feels like it could blow up in your face after a little while. That is also ignoring the safety PLCs with safety instructions that are certified for use with ISO 13849. Can you imagine getting inspected because your safety subsystem cause…
You completely stripped what I said from its context. GP explicitely said they donate to ReactOS in the hopes of one day being able to run that industrial software on it instead of on Windows. In this context, running the software on ReactOS instead of official Windows would already fail your hypothetical inspections. This is why I suggested trying the LLM route.
Running the same software in a different environment is unlikely to cause issues. But with vibe coding, you're throwing away the code the manufacturer certified as working, and the best possible outcome is it bricks your hardware in dev before things escalate to a post-mortem.
Earlier quoted context omitted.
Why not spend some money on an uncensored LLM to reverse engineer or create an open clean room reimplementation?
Because that requires breaking the almost assured stipulation in a software license agreement that says "You will not try to RE this software", which is fine to ignore for home gamers, but not something you generally want to mess around with in a business setting where the risks are much higher.
Hasn't the point been for the OS to be compatible with the existing Windows drivers?
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
ReactOS is way older than React. In fact, the first times when I heard about React I thought ReactOS was becoming mainstream, but no... If you an OS based in JS, maybe the closer we had was NodeOS [1] [1] https://node-os.com