Hacker News Reader

Comment by hombre_fatal | Hacker News Reader

One thing that's hard about rewriting code is that the original code was transformed incrementally over time in response to real world issues only found in production.

The code gets silently encumbered with those lessons, and unless they are documented, there's a lot of hidden work that needs to be done before you actually reach parity.

TFA is a good list of this exact sort of thing.

Before you call people amateur for it, also consider it's one of the most softwarey things about writing software. It was bound to happen unless coreutils had really good technical docs and included tests for these cases that they ignored.

View on HN

good example from the article: the chroot+nss CVE. the rule that nss is dynamic and dlopens libraries from inside the chroot isn't anywhere obvious. it's encoded in 25+ years of sysadmins finding it out. clean-room rewrites end up re-learning that, usually as new CVEs. and LLM ports of the same code inherit the problem: the function signature is what they read, but the scars are what they need.

> the function signature is what they read, but the scars are what they need.

This feels like a golden quote. Don't know if you intended for it to rhyme, but well done :D

thanks. honestly didn't catch the rhyme, accidental aphorism :D

> The code gets silently encumbered with those lessons, and unless they are documented, there's a lot of hidden work that needs to be done before you actually reach parity.

It should be stressed that failure to document such lessons, or at least the bugs/vulnerabilities avoided, is poor practice. Of course one can't document the bugs/vulnerabilities one has avoided implicitly by writing decent code to begin with, but it is important to share these lessons with the future reader, even if that means "wasting" time and space on a bunch of documentation such as "In here we do foo instead of bar because when we did bar in conditions ABC then baz happens which is bad because XYZ."

What's even harder is doing that while trying to avoid the GPL, so doing that without reading the original source code.

uutils would be so much better imo if it was GPL and took direct inspiration from the coreutils source code.

The GPL prevents you from reading the licensed code before writing related non-GPL code? Which section of the GPL says that?

It's based on an interpretation of "derived from".

It does not matter if it's in the GPL explicitly or not since we're talking about uutils and their stance on it, and they've written that:

https://github.com/uutils/coreutils/blob/6b8a5a15b4f077f8609...

> we cannot accept any changes based on the GNU source code [..]. It is however possible to look at other implementations under a BSD or MIT license like Apple's implementation or OpenBSD.

The wording of that clearly implies that you should not look at GNU source code in order to contribute to uutils.

"clearly implies"

Hmmmm....

"we cannot accept any changes based on the GNU source code" is false. They are choosing not to accept it.

"We cannot accept it without issuing a breaking change to the project by significantly changing the license terms."

This is clean room implementation 101, and why LLMs are so controversial in terms of licensing.

Reply on news.ycombinator.com