5 ms·

Why not spend some money on an uncensored LLM to reverse engineer or create an open clean room reimplementation?

bluGill 1mo ago
That is only recently become an option you could try, and we don't know long term how well it will work. Remember laws may change (and there are some legal issues around LLMs that are not clear at all)
wpm 1mo ago
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.
- Almondsetat 1mo ago
  Reverse engineering is protected under certain conditions, even if the EULA prohibits it
  - jmcqk6 1mo ago
    The thing about this type of thinking is that it often requires risking millions of dollars and a major distraction from your primary goal in order to find out if it's true or not.
    - Almondsetat 1mo ago
      As would be running critical software certified for Windows on ReactOS as envisioned by GP. So, either we talk about an enterprise setting, in which GP already fucked up, or a more personal setting, in which both whaat GP and I said are reasonable
  - estebarb 1mo ago
    That is how you get a hardware provider to stop selling you stuff
- ktm5j 1mo ago
  Also, the one thing that's important above all else in industrial automation is reliability. If your LLM doesn't know about one tiny little detail that ends up causing your product to fail, your customers start losing money and you can no longer point the finger at your PLC manufacturer. Make bad gambles like that and you won't be in business for long.
kvuj 1mo ago
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 injury and you explain how you don't use the officially licensed software to program it. For personal project, that could be fun however.
- Almondsetat 1mo ago
  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.
  - nvme0n1p1 1mo ago
    If I had to explain a failure in production I would much rather say "due to availability of old hardware, we ran this on a different version of Windows/inside a VM/inside a Windows compatibility layer/Wine/ReactOS" than "we vibecoded the entire driver stack from scratch, go ask Claude why the plant blew up lol". 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.

That is only recently become an option you could try, and we don't know long term how well it will work. Remember laws may change (and there are some legal issues around LLMs that are not clear at all)

wpm 1mo ago

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.

Almondsetat 1mo ago
Reverse engineering is protected under certain conditions, even if the EULA prohibits it
- jmcqk6 1mo ago
  The thing about this type of thinking is that it often requires risking millions of dollars and a major distraction from your primary goal in order to find out if it's true or not.
  - Almondsetat 1mo ago
    As would be running critical software certified for Windows on ReactOS as envisioned by GP. So, either we talk about an enterprise setting, in which GP already fucked up, or a more personal setting, in which both whaat GP and I said are reasonable
- estebarb 1mo ago
  That is how you get a hardware provider to stop selling you stuff
ktm5j 1mo ago
Also, the one thing that's important above all else in industrial automation is reliability. If your LLM doesn't know about one tiny little detail that ends up causing your product to fail, your customers start losing money and you can no longer point the finger at your PLC manufacturer. Make bad gambles like that and you won't be in business for long.

kvuj 1mo ago

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 injury and you explain how you don't use the officially licensed software to program it. For personal project, that could be fun however.

Almondsetat 1mo ago
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.
- nvme0n1p1 1mo ago
  If I had to explain a failure in production I would much rather say "due to availability of old hardware, we ran this on a different version of Windows/inside a VM/inside a Windows compatibility layer/Wine/ReactOS" than "we vibecoded the entire driver stack from scratch, go ask Claude why the plant blew up lol". 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.