4 ms·
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 prod
by hombre_fatal 6mo ago
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.
- TheDong 6mo agoWhat'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.
- dbdr 6mo agoThe GPL prevents you from reading the licensed code before writing related non-GPL code? Which section of the GPL says that?
- TheDong 6mo agoIt'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/6b8a5a15b4f077f860943f4e431e26fbd56cda90/CONTRIBUTING.md#contributing-to-coreutils 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.
- i_think_so 6mo ago"clearly implies" Hmmmm....
- goodpoint 6mo ago"we cannot accept any changes based on the GNU source code" is false. They are choosing not to accept it.
- kibwen 6mo ago"We cannot accept it without issuing a breaking change to the project by significantly changing the license terms."
- snovv_crash 6mo agoThis is clean room implementation 101, and why LLMs are so controversial in terms of licensing.
- aykutseker 6mo agogood 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.
- cataflutter 6mo ago> 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
- aykutseker 6mo agothanks. honestly didn't catch the rhyme, accidental aphorism :D
- einpoklum 6mo ago> 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."