Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That way of thinking just means it'll never be fixed


"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds


The problem there is that this is exactly the class of bug that does not exist in GNU coreutils because of philosophy of that project. Non-existence of such bugs proves that the impementation is not copied from AT&T code.


It's complicated to do it yourself when upstream won't accept your code.


What approach would you suggest for priorisation of tickets?


Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.


This isn't a port - it's a re-implementation without any use of the original source.

That's also not all that's happening. It's also making improvements like better internalization support, better error messages, and a small handful of other extensions.


I have had to tell them repeatedly to stop copying tests verbatim, including the original comments from GNU coreutils. So I doubt this is true, which is frustrating.


What's wrong with them using the coreutils tests?


If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.


But you should be able to use a GPL test suite on an MIT-licensed program (or even a proprietary one, without the program needing to be under the GPL.


Ehh... Technically yes but when you don't own the copyright on the tests you need to be very careful against creating derivative works, and you need to preserve both licenses in the distributed source.


> and you can't include GPL code in a MIT licensed project without making it GPL.

Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.


Capitalism.


Nah, people should (and do) fix small issues as well as big issues. Lying about the scale of issues and calling them "big" when they aren't just leads to no ability to prioritize or evaluate.

Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)


Because Collin reported it in Ubuntu too :)




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: