15 ms·

Cross-platform Rust rewrite of the GNU coreutils

302 points by jcbhmr 3y ago

taspeotis 3y ago
Did they rewrite it again? https://news.ycombinator.com/from?site=github.com/uutils https://news.ycombinator.com/from?site=github.com/uutils
- nindalf 3y ago
  No its the same one, but they’ve made progress. The test suite that compares it to GNU had more passes than fails in 2022 and today passes outnumber fails by 2:1. And it’s been a while since the last discussion.
- deleted 3y ago
  [deleted]
coldtea 3y ago
The issue with all these efforts is whether they'll be sustained and maintained long term, or merely until the 1-2 maintainers lose interest. GNU coreutils on the other hand have been going for decades.
- cmrx64 3y ago
  uutils just elapsed its first decade and going strong.
  - sph 3y ago
    coreutils is 33 years old and going strong. https://en.wikipedia.org/wiki/GNU_Core_Utilities#History https://en.wikipedia.org/wiki/GNU_Core_Utilities#History This one might have been around for 10 years, but it's disingenuous to claim it is as extensive, feature-full and tested as the real thing.
    - dcsommer 3y ago
      Who claimed that?
- eviks 3y ago
  Indeed, there are no examples of decades-old projects dying, so that risk doesn't exist
  - coldtea 3y ago
    It's almost as if existing longevity is a sign of project community/support structures/resilience [1], and what matters for such an assessment is not a knee-jerk pointing to the existence of counter-examples to show that non-zero risk exists (as if anybody said anything about the risk being zero), but the relative probability of a fresh && much less used project dying vs a widely used mature project that has already proven it can survive for a long period of time... Who would have thought! [1] https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
    - eviks 3y ago
      It's almost as if you didn't read the first sentence in your own link, which states that this "is a theorized phenomenon", not some established law of practical software development nature. So instead of knee-jerk posting of a "proof" as a response to a criticism of a knee-jerk pointing to the existence of some risk or pointing to some straw man of zero risks you might actually realize that the main thing that matters for such an assessment is an actual assessment
      - coldtea 3y ago
        It's almost as if you let the whole point fly over your head, and just hanged on the first thing you read on the link that could serve as a hail Mary attempt to build a semblance of an argument. Yes, it's a "is a theorized phenomenon", it's not a "law of practical software development nature". The whole point is the statistical relevance of it on accessing such a risk - not it being some kind of absolute law. It's the second time in this argument thread that you point to the lack of absolute guarantees (as if anybody said that long standing projects don't fail at all, or as if anybody said that the Lindy Effect is some absolute law), failing to see that they don't mean that long-term vs short-term project survivorship rate is the same. You know that outcomes can have probabilities attached to them too, not just absolute guarantees, and that it's the former that are the most common tool for accessing risks, right? >you might actually realize that the main thing that matters for such an assessment is an actual assessment You might not actually realize that in practice any such an actual assessment will be based on risk factors, statistical observations, and handy heuristics for longevity such as the Lindy Effect. Who would have thought, huh?
znpy 3y ago
> uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs. Now this is something I can get into. I'm okay with having stuff rewritten in Rust, but I'm not into learning some snowflake ls/grep and having to go edit all the scripts written over the years.
billpg 3y ago
[flagged]
- sneak 3y ago
  Memory safety comes to mind. Maintainability is another. I don’t recall if file(1) is part of coreutils or not, but there was a somewhat unexpected exploit for it a few years ago.
  - xyzzy123 3y ago
    Most of this stuff tends not to run in a privileged / network context so it's not clear to me that there are big security gains to be had? To be fair there are daemons and scripts that shell out to these things and when all the stars align you maybe get an exploitable scenario - but these tend to be situations where doing that in the first place was a bad idea (e.g. $PAGER is not meant to be a load bearing security component and rewriting in Rust is unlikely to fix all the issues with this class of usage).
    - roca 3y ago
      Whenever you run one of these tools on a file you downloaded from the Internet, you're relying on the tool having no exploitable security bugs. Regardless of whether or not $PAGER was intended to be a "load bearing security component", it definitely is.
  - ok123456 3y ago
    The lifetime of these programs is maybe a hundred milliseconds. You could write "memory safe" versions of them by just not using "free" in C, as many early versions of these tools did.
- martin8412 3y ago
  MIT license
  - itsphilos 3y ago
austinjp 3y ago
Genuine question: since these are core utils, and probably used billions of times every day, is anyone actually going to switch to this version? I see that the intention is for this to be a drop-in replacement, but some options and behaviours are still different. To clarify, I'm not intending this as a negative comment. It's an impressive project, and aiming for cross-platform sharing of scripts seems a worthy goal. The graph of progress against the GNU test suite is neat and encouraging. However, I can't imagine anyone in Unixy lands moving to this - although I may be wrong there - so it feels like a "compatibility" project for MacOS and Windows. I'm not familiar with the situation on MacOS but how bad is the compatibility issue? Similarly, on Windows what's the situation with WSL or VMs or even Cygwin? Is performance the issue? Do people actually want this, is there a market for it? It's got 17.8k stars so seemingly so? Again, I'm not intending to cast aspersions, just trying to understand the audience. This is clearly different from a "for the fun of it" side project.
- noirscape 3y ago
  Well for one, uutils is in rust. That alone can be pretty desirable for some people because that infers assumptions about memory safety, especially compared to the coreutils which are in C. The license stuff is what people focus on, but to me that is much more interesting. C is a pretty decrepit language and while I don't care much for the "rewrite it in rust" cult, the coreutils are exactly the type of program rust excels at - a non-iterative target that doesn't change often and can be made with "best practices" in mind. Not having to deal with the utterly inane amount of dead architectures that GNU projects inherit probably helps them too on that end.
  - lohnjemon 3y ago
    What kinds of memory safety bugs do you really care about in coreutils? Genuinely curious. Given how mature and well defined the GNU Coreutils are, how small their scope is, how they are used, I really don't see the supposed security upside here. There simply has to be a better reason to me, than "Rust good".
    - 3y ago
tetris11 3y ago
License.md: Copyright (c) uutils developers Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: Yep. This project is definitely going to be embraced by the community in the long run, and definitely supplant GNU coreutils. The MIT and GPL ideologies are completely aligned.
- oblio 3y ago
  > MIT license ???
- Affric 3y ago
  Yep. GPL is the greatest thing that has ever happened to software and this stuff seeks to destroy it.
  - arghwhat 3y ago
    As we all know, evil corporations have waited all this time for the opportunity to ship modified versions of specifically non-BSD coreutils without sources to end-users.
    - toyg 3y ago
      It's mostly that evil corporations have waited to get free work from the community on everything, and they're now getting it.
      - cmrdporcupine 3y ago
        I think a broad bias against copyleft has existed because people felt that it got in the way of just "getting things done" and felt that significant efforts contributed to BSD-style licenses would just "get rewarded" through patronage from the larger entities in silicon valley; leading to jobs, or donations, etc. I think that worked for many while the job market was pumping, VC was flowing, and the BigCorps were hiring and spending money like crazy. So people didn't feel particularly exploited. But I'm expecting the bias in the community will shift back to copyleft as the BigCorps show their true nature with the rounds of layoffs, mandatory RTO, cutbacks in perks, etc. Why spend a single moment of your time doing unpaid hours doing free work for these people? I've personally gone back to putting my (modest and used by nobody, to be fair) projects under GPLv3.
andrewstuart 3y ago
With an MIT License - be good in the title/headline. How certain is it that such utilities would be compatible including any weird edge cases?
- cmrx64 3y ago
  that’s what the automated test suite is for! and the graph in there is looking pretty good.
  - Someone 3y ago
    And they (somewhat/largely) avoid the “a test can’t check for issues we don’t know about” problem by running the GNU CoreUtils test suite, not a suite they wrote themselves. (Browsing https://github.com/coreutils/coreutils/tree/master/tests https://github.com/coreutils/coreutils/tree/master/tests that test suite is written in shell and Perl)
- deleted 3y ago
  [deleted]
Dinux 3y ago
We have switched to Rust about 4 years back for most of our robotics and embedded control systems. I has been a blessing to move away from C/C++ after 10 years. Sure Rust has its problems and issues, especially when it comes to async and concurrency. Yes it has a steep learning curve, yes the compiler gets in the way often but the number of _actual_ bugs (not design flaws) is probably less than 10 over 4 years. Every time I work on a C/C++ i'm painfully reminded how easy it is to shoot yourself in the foot. I hope coreutils and Rust in the kernel will eventually become the default
- PartiallyTyped 3y ago
  I genuinely can't get enough of rust tbh. It "just" works. Don't get me wrong, a few things could be better, e.g. compile times, but it's so much easier to work with.
  - klabb3 3y ago
    Please include the domain you’re working in and what you’re comparing against when making value statements like this. It can be helpful for others and the debate at large.
    - PartiallyTyped 3y ago
      I do software analysis, with some query engines, and backend. My comparisons are against java, python, and C, though I did try to get into C++. I also contribute to rust-lang/clippy and other rust projects.
- thesnide 3y ago
  i wonder how much of that is due to rust being too young to have myriads of dubious code to copy from. Perl is even more memory safe than Rust, but the amount of crappy code is overwhelming...
  - steveklabnik 3y ago
    That's the thing about a compiler enforcing rules: you can't even get some kinds of dubious code to compile, so therefore, it will never meaningfully be copied. Of course, that doesn't mean that all bugs are prevented, or that Rust code has no bugs, or that you can't write bad Rust code. But in the context of robotics and embedded control systems, Rust solves a lot of those "bad code" issues at compile time. And you're not using Perl in that context regardless.
ingen0s 3y ago
Very cool! How long did this take?!
- KolmogorovComp 3y ago
  First commit was 11 years ago.
Decabytes 3y ago
I don’t understand how they can rewrite the core útiles in Rust with a different license, especially if the intent is a like for like end product? One of the things “open” game engines run into (IE OpenMW) is that if source code for a game engine they are reimplementing leaks, they avoid it at all costs, since it could “contaminate” the project and ruin their protection as a fair use project. I feel like this sets a bad precedent for the GPL because if anyone can do that, then it weakens the power of copy left licenses as a whole, but maybe I’m missing something because I’m not a lawyer
- Aissen 3y ago
  Think of it like a blackbox reimplementation, not porting existing code to another language: https://github.com/uutils/coreutils/blob/244693f50e224abf72686305cbc784fd5f3b022d/CONTRIBUTING.md?plain=1#L17-L21 https://github.com/uutils/coreutils/blob/244693f50e224abf726...
  - cmrdporcupine 3y ago
    Can we truly believe that not a single one of these authors didn't peak over at the GNU coreutils source to get a handle on how something there worked?
    - Aissen 3y ago
      You can believe it or not, but please stop spreading FUD disguised as a question. If you have proofs, you can post them, and then interested people can try to dissect them.
  - nairboon 3y ago
    That warning was added 2 months ago.
    - Aissen 3y ago
      Maybe they got tired of people making unsubstantiated remarks that were never made for bsdutils, busybox or toybox ? Just look at the level of the current HN discussion.
nairboon 3y ago
This is interesting as it is. But just as a heads up for those who get interested specifically because this project's license file says 'MIT'. It's is going to be very difficult to justify this license for a project that is a ' Cross-platform Rust rewrite of the GNU coreutils'. Rewriting GPL-licensed GNU software while dropping the GPL license? To be on the safe side, one should assume that thise coreutils rewrite is concealed GPL.
- tmalsburg2 3y ago
  My understanding (IANAL) so far was that licenses apply to the code and binaries derived from the code. Why do you think that GPL also applies to a from-scratch rewrite? There are cases where a rewrite was done precisely to circumvent license restrictions.
  - nairboon 3y ago
    This is a question of Copyright law [1], which also differs depending the jurisdiction. > from-scratch rewrite rewriting is literally a derivative work. With 'from-scratch' you probably mean some form of 'clean-room implementation', which is specifically required to circumvent copyright protection. Performing such an implementation is quite laborious and needs to be properly documented. That an opensource project with more than 400 contributors can reasonably attest this is somewhat questionable. 1: https://www.copyright.gov/title17/92chap1.html#101 https://www.copyright.gov/title17/92chap1.html#101
    - tzs 3y ago
      Clean-room implementations are not required to avoid infringing when you make your own version of something else. They just make it easier to successfully defend if you are sued for infringement. If your code does not copy any copyrightable expression from mine it is not a derivative work, so if I sue you (legitimately, not because I just hope a lawsuit will intimidate you into agreeing to my demands) it means I've found things in your work that I think are copies of copyrightable things from my work. If you haven't done a clean-room implementation your defense is probably going to rely on finding those things in other works besides mine and using one or more of these arguments: (1) these things are widely used and known and your copied yours from somewhere other than my work, (2) the ones in my work are just copies from those other works so I don't have any copyright on them for you to infringe, and (3) there are so few reasonably ways to do these things that everyone who writes them comes up with nearly identical solutions and that's why yours are similar to mine. If you have done a clean-room implementation and kept good records to prove that, your defense is that you never saw any of my copyrightable expression so cannot possibly have copied.
moby_click 3y ago
I am surprised, that these are not called oreutils.
- deleted 3y ago
  [deleted]
tallmed 3y ago
[flagged]
andsoitis 3y ago
Not that it should represent the rubicon of when to/not to rewrite code, but when you do, you do trade one set of bugs for a new set of bugs: https://github.com/uutils/coreutils/issues https://github.com/uutils/coreutils/issues
rednafi 3y ago
[dead]
einpoklum 3y ago
Has there really been no effort to modernize some/most/all of the GNU coreutils code - while keeping the language and the license? Switching language to Rust and changing the license does not make for a drop-in replacement, I would say.
- awestroke 3y ago
  GNU coreutils will never modernize. Nobody is switching language and license of GNU coreutils. This is a greenfield project.
- pie_flavor 3y ago
  > Switching language to Rust and changing the license does not make for a drop-in replacement, I would say. Why?
  - steveklabnik 3y ago
    Not your parent, but, to "replace" something means that it fills the same need you have as something else. The trick with talking about this in a generic context is that some people "need" some things and some do not. Your parent is saying "I do not like Rust and I prefer the GPL, and so this is not equivalent in my eyes." This can be true, while for a different person, simultaneously, "I like Rust and dislike the GPL, and so this is an equivalent in my eyes" can be true as well.
LaGrange 3y ago
[flagged]
sntran 3y ago
Coincidentally, I was just reading about how VSCode support WASM on their web edition[1] and this was mentioned in their effort to implement the Terminal. [1] https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-wasi https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-w...
w10-1 3y ago
Great progress, but the last 10% often takes 50% of the time. In this case, there may be little value to the last bits, but people are going to wait to use these until that last bit is done, for fear of what might happen. Which triggers ranting... Q: Why exactly are we stuck targeting cross-platform compatibility for every possible option in every possible tool? A: Because there is no good way to check the impact of removing options or tools, or for migrating clients. By this mechanism, "OS" and "core" features grow forever, and the convention-bound C ABI is, well, as close to forever as we get. Rewriting in Rust does not help that one bit (nor is it supposed to). Has no one written literate ABI interfaces that support static validation and backwards compatibility via shims and automatic migrations? Must scripting be such a drag on progress? We do automatic migrations in databases all the time; we should be able to do it in code.
ary 3y ago
People seem very focused on “should they or shouldn’t they, and why”, which somewhat perplexes me given that there is at least one really good reason for doing this: to create Rosetta Stones for very common pieces of software. To really and truly know if Rust should become the new C we have to start seriously exercising it in the places where C reigns. That’s not a bake-off entirely defined by technological superiority, but also of practical applicability, maintainability, and ability to ship pervasively deployed solutions. This project is a great test of Rust. RIIR isn’t merely a “sprinkle Rust magic because I believe” thing. The tech has clear potential and I personally think a version of it will take hold where C was once assumed. To know for sure we have to ship more software with it, and we need good comparisons. I’m quite thrilled to have projects like this pressing on.

302 points by jcbhmr 3y ago

Did they rewrite it again? https://news.ycombinator.com/from?site=github.com/uutils https://news.ycombinator.com/from?site=github.com/uutils

nindalf 3y ago
No its the same one, but they’ve made progress. The test suite that compares it to GNU had more passes than fails in 2022 and today passes outnumber fails by 2:1. And it’s been a while since the last discussion.
deleted 3y ago
[deleted]

coldtea 3y ago

The issue with all these efforts is whether they'll be sustained and maintained long term, or merely until the 1-2 maintainers lose interest. GNU coreutils on the other hand have been going for decades.

cmrx64 3y ago
uutils just elapsed its first decade and going strong.
- sph 3y ago
  coreutils is 33 years old and going strong. https://en.wikipedia.org/wiki/GNU_Core_Utilities#History https://en.wikipedia.org/wiki/GNU_Core_Utilities#History This one might have been around for 10 years, but it's disingenuous to claim it is as extensive, feature-full and tested as the real thing.
  - dcsommer 3y ago
    Who claimed that?
eviks 3y ago
Indeed, there are no examples of decades-old projects dying, so that risk doesn't exist
- coldtea 3y ago
  It's almost as if existing longevity is a sign of project community/support structures/resilience [1], and what matters for such an assessment is not a knee-jerk pointing to the existence of counter-examples to show that non-zero risk exists (as if anybody said anything about the risk being zero), but the relative probability of a fresh && much less used project dying vs a widely used mature project that has already proven it can survive for a long period of time... Who would have thought! [1] https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
  - eviks 3y ago
    It's almost as if you didn't read the first sentence in your own link, which states that this "is a theorized phenomenon", not some established law of practical software development nature. So instead of knee-jerk posting of a "proof" as a response to a criticism of a knee-jerk pointing to the existence of some risk or pointing to some straw man of zero risks you might actually realize that the main thing that matters for such an assessment is an actual assessment
    - coldtea 3y ago
      It's almost as if you let the whole point fly over your head, and just hanged on the first thing you read on the link that could serve as a hail Mary attempt to build a semblance of an argument. Yes, it's a "is a theorized phenomenon", it's not a "law of practical software development nature". The whole point is the statistical relevance of it on accessing such a risk - not it being some kind of absolute law. It's the second time in this argument thread that you point to the lack of absolute guarantees (as if anybody said that long standing projects don't fail at all, or as if anybody said that the Lindy Effect is some absolute law), failing to see that they don't mean that long-term vs short-term project survivorship rate is the same. You know that outcomes can have probabilities attached to them too, not just absolute guarantees, and that it's the former that are the most common tool for accessing risks, right? >you might actually realize that the main thing that matters for such an assessment is an actual assessment You might not actually realize that in practice any such an actual assessment will be based on risk factors, statistical observations, and handy heuristics for longevity such as the Lindy Effect. Who would have thought, huh?

znpy 3y ago

> uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs. Now this is something I can get into. I'm okay with having stuff rewritten in Rust, but I'm not into learning some snowflake ls/grep and having to go edit all the scripts written over the years.

billpg 3y ago

[flagged]

sneak 3y ago
Memory safety comes to mind. Maintainability is another. I don’t recall if file(1) is part of coreutils or not, but there was a somewhat unexpected exploit for it a few years ago.
- xyzzy123 3y ago
  Most of this stuff tends not to run in a privileged / network context so it's not clear to me that there are big security gains to be had? To be fair there are daemons and scripts that shell out to these things and when all the stars align you maybe get an exploitable scenario - but these tend to be situations where doing that in the first place was a bad idea (e.g. $PAGER is not meant to be a load bearing security component and rewriting in Rust is unlikely to fix all the issues with this class of usage).
  - roca 3y ago
    Whenever you run one of these tools on a file you downloaded from the Internet, you're relying on the tool having no exploitable security bugs. Regardless of whether or not $PAGER was intended to be a "load bearing security component", it definitely is.
- ok123456 3y ago
  The lifetime of these programs is maybe a hundred milliseconds. You could write "memory safe" versions of them by just not using "free" in C, as many early versions of these tools did.
martin8412 3y ago
MIT license
- itsphilos 3y ago

austinjp 3y ago

Genuine question: since these are core utils, and probably used billions of times every day, is anyone actually going to switch to this version? I see that the intention is for this to be a drop-in replacement, but some options and behaviours are still different. To clarify, I'm not intending this as a negative comment. It's an impressive project, and aiming for cross-platform sharing of scripts seems a worthy goal. The graph of progress against the GNU test suite is neat and encouraging. However, I can't imagine anyone in Unixy lands moving to this - although I may be wrong there - so it feels like a "compatibility" project for MacOS and Windows. I'm not familiar with the situation on MacOS but how bad is the compatibility issue? Similarly, on Windows what's the situation with WSL or VMs or even Cygwin? Is performance the issue? Do people actually want this, is there a market for it? It's got 17.8k stars so seemingly so? Again, I'm not intending to cast aspersions, just trying to understand the audience. This is clearly different from a "for the fun of it" side project.

noirscape 3y ago
Well for one, uutils is in rust. That alone can be pretty desirable for some people because that infers assumptions about memory safety, especially compared to the coreutils which are in C. The license stuff is what people focus on, but to me that is much more interesting. C is a pretty decrepit language and while I don't care much for the "rewrite it in rust" cult, the coreutils are exactly the type of program rust excels at - a non-iterative target that doesn't change often and can be made with "best practices" in mind. Not having to deal with the utterly inane amount of dead architectures that GNU projects inherit probably helps them too on that end.
- lohnjemon 3y ago
  What kinds of memory safety bugs do you really care about in coreutils? Genuinely curious. Given how mature and well defined the GNU Coreutils are, how small their scope is, how they are used, I really don't see the supposed security upside here. There simply has to be a better reason to me, than "Rust good".
  - 3y ago

tetris11 3y ago

License.md: Copyright (c) uutils developers Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: Yep. This project is definitely going to be embraced by the community in the long run, and definitely supplant GNU coreutils. The MIT and GPL ideologies are completely aligned.

oblio 3y ago
> MIT license ???
Affric 3y ago
Yep. GPL is the greatest thing that has ever happened to software and this stuff seeks to destroy it.
- arghwhat 3y ago
  As we all know, evil corporations have waited all this time for the opportunity to ship modified versions of specifically non-BSD coreutils without sources to end-users.
  - toyg 3y ago
    It's mostly that evil corporations have waited to get free work from the community on everything, and they're now getting it.
    - cmrdporcupine 3y ago
      I think a broad bias against copyleft has existed because people felt that it got in the way of just "getting things done" and felt that significant efforts contributed to BSD-style licenses would just "get rewarded" through patronage from the larger entities in silicon valley; leading to jobs, or donations, etc. I think that worked for many while the job market was pumping, VC was flowing, and the BigCorps were hiring and spending money like crazy. So people didn't feel particularly exploited. But I'm expecting the bias in the community will shift back to copyleft as the BigCorps show their true nature with the rounds of layoffs, mandatory RTO, cutbacks in perks, etc. Why spend a single moment of your time doing unpaid hours doing free work for these people? I've personally gone back to putting my (modest and used by nobody, to be fair) projects under GPLv3.

andrewstuart 3y ago

With an MIT License - be good in the title/headline. How certain is it that such utilities would be compatible including any weird edge cases?

cmrx64 3y ago
that’s what the automated test suite is for! and the graph in there is looking pretty good.
- Someone 3y ago
  And they (somewhat/largely) avoid the “a test can’t check for issues we don’t know about” problem by running the GNU CoreUtils test suite, not a suite they wrote themselves. (Browsing https://github.com/coreutils/coreutils/tree/master/tests https://github.com/coreutils/coreutils/tree/master/tests that test suite is written in shell and Perl)
deleted 3y ago
[deleted]

Dinux 3y ago

We have switched to Rust about 4 years back for most of our robotics and embedded control systems. I has been a blessing to move away from C/C++ after 10 years. Sure Rust has its problems and issues, especially when it comes to async and concurrency. Yes it has a steep learning curve, yes the compiler gets in the way often but the number of _actual_ bugs (not design flaws) is probably less than 10 over 4 years. Every time I work on a C/C++ i'm painfully reminded how easy it is to shoot yourself in the foot. I hope coreutils and Rust in the kernel will eventually become the default

PartiallyTyped 3y ago
I genuinely can't get enough of rust tbh. It "just" works. Don't get me wrong, a few things could be better, e.g. compile times, but it's so much easier to work with.
- klabb3 3y ago
  Please include the domain you’re working in and what you’re comparing against when making value statements like this. It can be helpful for others and the debate at large.
  - PartiallyTyped 3y ago
    I do software analysis, with some query engines, and backend. My comparisons are against java, python, and C, though I did try to get into C++. I also contribute to rust-lang/clippy and other rust projects.
thesnide 3y ago
i wonder how much of that is due to rust being too young to have myriads of dubious code to copy from. Perl is even more memory safe than Rust, but the amount of crappy code is overwhelming...
- steveklabnik 3y ago
  That's the thing about a compiler enforcing rules: you can't even get some kinds of dubious code to compile, so therefore, it will never meaningfully be copied. Of course, that doesn't mean that all bugs are prevented, or that Rust code has no bugs, or that you can't write bad Rust code. But in the context of robotics and embedded control systems, Rust solves a lot of those "bad code" issues at compile time. And you're not using Perl in that context regardless.

ingen0s 3y ago

Very cool! How long did this take?!

KolmogorovComp 3y ago
First commit was 11 years ago.

Decabytes 3y ago

I don’t understand how they can rewrite the core útiles in Rust with a different license, especially if the intent is a like for like end product? One of the things “open” game engines run into (IE OpenMW) is that if source code for a game engine they are reimplementing leaks, they avoid it at all costs, since it could “contaminate” the project and ruin their protection as a fair use project. I feel like this sets a bad precedent for the GPL because if anyone can do that, then it weakens the power of copy left licenses as a whole, but maybe I’m missing something because I’m not a lawyer

Aissen 3y ago
Think of it like a blackbox reimplementation, not porting existing code to another language: https://github.com/uutils/coreutils/blob/244693f50e224abf72686305cbc784fd5f3b022d/CONTRIBUTING.md?plain=1#L17-L21 https://github.com/uutils/coreutils/blob/244693f50e224abf726...
- cmrdporcupine 3y ago
  Can we truly believe that not a single one of these authors didn't peak over at the GNU coreutils source to get a handle on how something there worked?
  - Aissen 3y ago
    You can believe it or not, but please stop spreading FUD disguised as a question. If you have proofs, you can post them, and then interested people can try to dissect them.
- nairboon 3y ago
  That warning was added 2 months ago.
  - Aissen 3y ago
    Maybe they got tired of people making unsubstantiated remarks that were never made for bsdutils, busybox or toybox ? Just look at the level of the current HN discussion.

nairboon 3y ago

This is interesting as it is. But just as a heads up for those who get interested specifically because this project's license file says 'MIT'. It's is going to be very difficult to justify this license for a project that is a ' Cross-platform Rust rewrite of the GNU coreutils'. Rewriting GPL-licensed GNU software while dropping the GPL license? To be on the safe side, one should assume that thise coreutils rewrite is concealed GPL.

tmalsburg2 3y ago
My understanding (IANAL) so far was that licenses apply to the code and binaries derived from the code. Why do you think that GPL also applies to a from-scratch rewrite? There are cases where a rewrite was done precisely to circumvent license restrictions.
- nairboon 3y ago
  This is a question of Copyright law [1], which also differs depending the jurisdiction. > from-scratch rewrite rewriting is literally a derivative work. With 'from-scratch' you probably mean some form of 'clean-room implementation', which is specifically required to circumvent copyright protection. Performing such an implementation is quite laborious and needs to be properly documented. That an opensource project with more than 400 contributors can reasonably attest this is somewhat questionable. 1: https://www.copyright.gov/title17/92chap1.html#101 https://www.copyright.gov/title17/92chap1.html#101
  - tzs 3y ago
    Clean-room implementations are not required to avoid infringing when you make your own version of something else. They just make it easier to successfully defend if you are sued for infringement. If your code does not copy any copyrightable expression from mine it is not a derivative work, so if I sue you (legitimately, not because I just hope a lawsuit will intimidate you into agreeing to my demands) it means I've found things in your work that I think are copies of copyrightable things from my work. If you haven't done a clean-room implementation your defense is probably going to rely on finding those things in other works besides mine and using one or more of these arguments: (1) these things are widely used and known and your copied yours from somewhere other than my work, (2) the ones in my work are just copies from those other works so I don't have any copyright on them for you to infringe, and (3) there are so few reasonably ways to do these things that everyone who writes them comes up with nearly identical solutions and that's why yours are similar to mine. If you have done a clean-room implementation and kept good records to prove that, your defense is that you never saw any of my copyrightable expression so cannot possibly have copied.

moby_click 3y ago

I am surprised, that these are not called oreutils.

deleted 3y ago
[deleted]

tallmed 3y ago

[flagged]

andsoitis 3y ago

Not that it should represent the rubicon of when to/not to rewrite code, but when you do, you do trade one set of bugs for a new set of bugs: https://github.com/uutils/coreutils/issues https://github.com/uutils/coreutils/issues

rednafi 3y ago

[dead]

einpoklum 3y ago

Has there really been no effort to modernize some/most/all of the GNU coreutils code - while keeping the language and the license? Switching language to Rust and changing the license does not make for a drop-in replacement, I would say.

awestroke 3y ago
GNU coreutils will never modernize. Nobody is switching language and license of GNU coreutils. This is a greenfield project.
pie_flavor 3y ago
> Switching language to Rust and changing the license does not make for a drop-in replacement, I would say. Why?
- steveklabnik 3y ago
  Not your parent, but, to "replace" something means that it fills the same need you have as something else. The trick with talking about this in a generic context is that some people "need" some things and some do not. Your parent is saying "I do not like Rust and I prefer the GPL, and so this is not equivalent in my eyes." This can be true, while for a different person, simultaneously, "I like Rust and dislike the GPL, and so this is an equivalent in my eyes" can be true as well.

LaGrange 3y ago

[flagged]

sntran 3y ago

Coincidentally, I was just reading about how VSCode support WASM on their web edition[1] and this was mentioned in their effort to implement the Terminal. [1] https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-wasi https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-w...

w10-1 3y ago

Great progress, but the last 10% often takes 50% of the time. In this case, there may be little value to the last bits, but people are going to wait to use these until that last bit is done, for fear of what might happen. Which triggers ranting... Q: Why exactly are we stuck targeting cross-platform compatibility for every possible option in every possible tool? A: Because there is no good way to check the impact of removing options or tools, or for migrating clients. By this mechanism, "OS" and "core" features grow forever, and the convention-bound C ABI is, well, as close to forever as we get. Rewriting in Rust does not help that one bit (nor is it supposed to). Has no one written literate ABI interfaces that support static validation and backwards compatibility via shims and automatic migrations? Must scripting be such a drag on progress? We do automatic migrations in databases all the time; we should be able to do it in code.

ary 3y ago

People seem very focused on “should they or shouldn’t they, and why”, which somewhat perplexes me given that there is at least one really good reason for doing this: to create Rosetta Stones for very common pieces of software. To really and truly know if Rust should become the new C we have to start seriously exercising it in the places where C reigns. That’s not a bake-off entirely defined by technological superiority, but also of practical applicability, maintainability, and ability to ship pervasively deployed solutions. This project is a great test of Rust. RIIR isn’t merely a “sprinkle Rust magic because I believe” thing. The tech has clear potential and I personally think a version of it will take hold where C was once assumed. To know for sure we have to ship more software with it, and we need good comparisons. I’m quite thrilled to have projects like this pressing on.