← Back to context

Comment by acedTrex

7 hours ago

I didn't think it needed to be said... If you need it spelled out the LLM rust rewrite is very clearly what is being referred to.

10 comments

acedTrex

Reply
gbin  7 hours ago

I think it needed to be said because I really don't see why.

LLM are excellent translation tools. Nothing is learned or stolen from them out of this exercise if this is a copyright issue you are getting at.

Then Rust? Why picking on it, the language is morally corrupt? In what way? If it were a rewrite in Object Pascal it would be better?

  • DetroitThrow  6 hours ago

    I personally think object pascal, or perhaps think c, would be a better choice here.

    I will not explain why.

germoney  7 hours ago

Help me get the argument please I might be dense: is the rewrite unethical or the llm use or rust or any of the combinations?

  • hansvm  6 hours ago

    The usual argument I see goes something like:

    1. There are major obvious flaws

    2. Most of those are obviously LLM-induced, unless there's a new breed of human trained on just the failures of LLMs and not the successes or other relevant information

    3. I therefore assume that the rest of the project is an unverified LLM psychosis without meaningful human review

    That's not the worst thing in the world for all software maybe. I recently found out my apartment complex in their latest AI rewrite generates SMS OTP based purely on the timestamp and ignores passwords, so I can log in as anyone else by knowing their email and having a valid email to grab the current OTP. That's a major security failing, but how bad is it really? I can grab the last-4 of their credit card numbers, pay their rent, see how much other tenants are being screwed, and so on, and only if I know their email addresses (solvable with a tiny bit of social engineering, but let's assume that's also moderately hard). How bad is that really? On the one hand, it's terrifying, since I presume they have the same level of attention to detail with respect to payment methods and PII despite my having opted out of having them stored, but (a) that's all already been exposed via dozens of breaches and is being handled behind the scenes by my bank anyway, and (b) if we examine the immediate blast radius of the known bugs then there's approximately fuck-all an attacker can do with that information.

    For a multi-threaded linker? Come the fuck on. I don't care if it's written in Rust. If you ignore all of the memory ordering intrinsics and `unsafe` then maybe it's more okay, but not having easily available UAF and other memory bugs is very different from actually implementing the correct behaviour, and for a linker where you're explicitly joining together multiple independent binary blobs and choosing what and how to execute on a machine instruction level, Rust's guarantees 100% don't save you from broken, unvalidated "business logic."