Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-platform Rust rewrite of the GNU coreutils

github.com

Post reply on HN
Print view View original

441–450 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#441

Post by losvedir »

jahewson wrote: post #285
jordigh wrote: post #226

Earlier quoted context omitted.

> This is very very weak grounds for any sort of lawsuit. Not according to the lawyers who have advised us GNU Octave developers to never read Matlab source code.

Your lawyers are peddling FUD because they make money that way. "Hey, it looks like you need another legal agreement, can't be too safe!" The reality is that an "unintentional copying" claim against source code makes for a very weak lawsuit and it's close to unimaginable that such a case would even make it into a court room. You're free to read whatever you like. Don't let anybody tell you otherwise.

Just stop man. You don't know what you're talking about.

There are plenty of lawyers who are also software people. For example, DannyBee[0] or rayiner[1] on HN.

That's why people are asking you if you're a lawyer like them; they have interesting perspectives and experience in both fields.

But no, it sounds like you're just a software guy who's read a wikipedia article like the the rest of us.

So, please, stop.

[0] https://news.ycombinator.com/user?id=DannyBee [1] https://news.ycombinator.com/user?id=rayiner

Re: Cross-platform Rust rewrite of the GNU coreutils

#442

Post by dikaiosune »

kazinator wrote: post #439
dikaiosune wrote: post #248

Earlier quoted context omitted.

That looks pretty clean, but they're still applying looks like 5 patches which would need to be maintained separately. It's certainly not as bad as a full port, but it's still not the same codebase. Rust's cross-platform efforts would (I think?) obviate that process.

But, nevertheless, it's not exactly a port of Coreutils to Windows per se . For instance, let's take the "cp" utility. A Windows port "cp" should be able to copy Windows-specific file attributes. Does the Cygwin "cp" do that? How about NTFS forks? I don't believe that you can write some portable code in Rust, and have a "cp" utility which correctly handles every quirk of every OS's file structure.

Not familiar with Windows' filesystem APIs, but the description for the Rust function in the stdlib is here:

https://doc.rust-lang.org/std/fs/fn.copy.html

Seems like it should handle platform specific attributes?

Re: Cross-platform Rust rewrite of the GNU coreutils

#443

Post by tatterdemalion »

quotemstr wrote: post #438
tatterdemalion wrote: post #205

Earlier quoted context omitted.

The standard allocator will abort on oom error. For applications which need to be tolerant to oom errors, you need to use a different allocator. Most programs can't tolerate oom errors, though, and it would be absolutely unreasonable for every function in the standard library that might perform an allocation to return an error that has to be handled by every programmer all the time. EDIT: C's solution is to make it v…

Every function in the C++ standard library reliably communicates allocation failure to the application without relying on aborting the whole program. If Rust can do it, C++ can do it too. Rust got itself into this trap by eschewing exceptions.

Maybe avoid using judgmental language like calling a standard allocator that aborts on oom a "trap." The Rust team made conscious design choices in full awareness of the trade-offs. Moreover, Rust actually does have thread unwinding, and even the ability to catch an unwinding thread, so it is not true that the Rust standard library could not have unwound on oom.

Rust's standard library just isn't designed for writing applications that need to survive oom errors. That's fine, its not designed for a number of other applications which Rust the language is well-suited for either (operating systems, for example). Its designed for the majority use case, because life is full of trade offs.

Re: Cross-platform Rust rewrite of the GNU coreutils

#444

Post by kbenson »

pcwalton wrote: post #433
kbenson wrote: post #371

Earlier quoted context omitted.

I think that's mostly solved by changing the whole of the idea from "remove/disallow all undefined behavior" to "remove as much of the common needed undefined behavior as possible such that most programs need not really use it". Perfect is the enemy of good.

That'd be fine if use-after-free was a corner case that doesn't show up often in practice, but every single exploit at Pwn2Own this year was UAF…

Are we arguing the same thing? If UAF is the cause of security problems, and UAF is undefined behavior now, redefining it under a special mode to mean "this is an error (whether or not the compiler enforces it)" at least clarifies the situation,and lets and included static analysis report an error as needed and capable.

That is, I'm not arguing that as much undefined behavior as possible should be made defined and possible, just that it's defined. That definition may very well be "you are not allowed to do this. Don't do this."

Re: Cross-platform Rust rewrite of the GNU coreutils

#445

Post by Dylan16807 »

pcwalton wrote: post #440
Dylan16807 wrote: post #434

Earlier quoted context omitted.

For the price of removing some of the rusty nails sticking out of C, I'll happily pay a few 16KB on a binary as large as clang. Plus in most or all of those cases, the optimization would still be possible even with stable uninitialized values. It just needs to be done in a different way. You might be able to get 13 of those 16KB back with a very minor amount of work.

> For the price of removing some of the rusty nails sticking out of C, I'll happily pay a few 16KB on a binary as large as clang. Lots of LLVM users won't. The competition between LLVM and GCC is (or was) pretty brutal. > Plus in most or all of those cases, the optimization would still be possible even with stable uninitialized values. It just needs to be done in a different way. I doubt that's possible without justi…

The goal is to refine the semantics of C. Removing a valid optimization doesn't help that.

It's not that I think the Chris is wrong, it's that I think other optimizations related to dead code have gotten better in the last many years, and focused effort could improve them more.

Re: Cross-platform Rust rewrite of the GNU coreutils

#446

Post by ploxiln »

pcwalton wrote: post #261
Alupis wrote: post #258

Earlier quoted context omitted.

> We think of ourselves as one of the most fast-moving industries We're fast-moving because our foundation is solid and not changing (ie. CoreUtils and gang). It's an assumption that these things "just work" with zero fuss and weirdness between systems. We build on-top of these systems, so changing them out from underneath us all is a dramatic shift. Perhaps Rust is the key to making these things better. I never clai…

> We're fast-moving because our foundation is solid and not changing (ie. CoreUtils and gang). That isn't a definition of "fast moving" that I would use. It sounds like slow moving. Why is innovation in the core layers of the system less legitimate than innovation in social media apps? Boeing has no problem upgrading their engines every few years for better fuel efficiency. Why can they do that, whereas can't we do t…

Boeing's engines for passenger jets are not substantially different than they were 20 years ago, are they? coreutils also got some feature additions, fixes, and optimizations over the years.

Aircraft technology may not have been the best comparison for your argument. Have you seen http://idlewords.com/talks/web_design_first_100_years.htm

Re: Cross-platform Rust rewrite of the GNU coreutils

#447

Post by pcwalton »

Dylan16807 wrote: post #445
pcwalton wrote: post #440

Earlier quoted context omitted.

> For the price of removing some of the rusty nails sticking out of C, I'll happily pay a few 16KB on a binary as large as clang. Lots of LLVM users won't. The competition between LLVM and GCC is (or was) pretty brutal. > Plus in most or all of those cases, the optimization would still be possible even with stable uninitialized values. It just needs to be done in a different way. I doubt that's possible without justi…

The goal is to refine the semantics of C. Removing a valid optimization doesn't help that. It's not that I think the Chris is wrong, it's that I think other optimizations related to dead code have gotten better in the last many years, and focused effort could improve them more.

I think "refining the semantics of C" is a doomed effort that we shouldn't undertake. We'll lose performance for very little benefit, if market game theory even made it possible (and it doesn't: benchmarks of C compiler performance are much more important to customers than friendliness of the C dialect). We should just be moving away from C instead, or if we must stick with C we should invest in dynamic checks for undefined behavior.

My position, by the way, is hardly uncommon among longtime C compiler developers.

Re: Cross-platform Rust rewrite of the GNU coreutils

#448

Post by cyphar »

gkya wrote: post #123
geofft wrote: post #105

Earlier quoted context omitted.

Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. (Incidentally, while I think that part of the reason why Git is this way is due to design differences from CVS, this isn't essential to it being true. Git is also better than Monotone or Fossil or Bazaar, despite being much closer in design, because it has network effects…

> Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. It is very easy to contribute if you know git. But you can mess it up if you don't know. I made a two-line bugfix patch to flycheck, and heck, I was nearly pasting the patch into a comment in issues because I didn't know anything about how to make a pull request on githu…

If you want to contribute to the Linux kernel, that's how it works as well. You just mail your patch and don't need to know anything about git.

Re: Cross-platform Rust rewrite of the GNU coreutils

#449

Post by Dylan16807 »

pcwalton wrote: post #447
Dylan16807 wrote: post #445

Earlier quoted context omitted.

The goal is to refine the semantics of C. Removing a valid optimization doesn't help that. It's not that I think the Chris is wrong, it's that I think other optimizations related to dead code have gotten better in the last many years, and focused effort could improve them more.

I think "refining the semantics of C" is a doomed effort that we shouldn't undertake. We'll lose performance for very little benefit, if market game theory even made it possible (and it doesn't: benchmarks of C compiler performance are much more important to customers than friendliness of the C dialect). We should just be moving away from C instead, or if we must stick with C we should invest in dynamic checks for un…

Do you think C managed to get things exactly right? Or should we add more kinds of undefined behavior?

What do we do about the fact that undefined behavior actually makes it harder or impossible to write efficient code in some cases, like checking for integer overflow?

Even if your goal is performance over anything, there are a whole lot of undefined behaviors that have absolutely zero performance benefit.

Re: Cross-platform Rust rewrite of the GNU coreutils

#450

Post by pcwalton »

Dylan16807 wrote: post #449
pcwalton wrote: post #447

Earlier quoted context omitted.

I think "refining the semantics of C" is a doomed effort that we shouldn't undertake. We'll lose performance for very little benefit, if market game theory even made it possible (and it doesn't: benchmarks of C compiler performance are much more important to customers than friendliness of the C dialect). We should just be moving away from C instead, or if we must stick with C we should invest in dynamic checks for un…

Do you think C managed to get things exactly right? Or should we add more kinds of undefined behavior? What do we do about the fact that undefined behavior actually makes it harder or impossible to write efficient code in some cases, like checking for integer overflow? Even if your goal is performance over anything , there are a whole lot of undefined behaviors that have absolutely zero performance benefit.

> What do we do about the fact that undefined behavior actually makes it harder or impossible to write efficient code in some cases, like checking for integer overflow?

This is a good example of why we should be moving away from C. :) Signed overflow being undefined is basically necessary due to a self-inflicted wound from 1978: the fact that "int" is the easiest thing to type for the loop index when iterating over arrays. Nobody is going to go through and fix all the C code in existence to use unsigned, so we're stuck with that UB forever. The realistic solution is to start migrating away from C (and I have no illusions about how long that will take, but we'll never get there if we don't start now).

> Even if your goal is performance over anything, there are a whole lot of undefined behaviors that have absolutely zero performance benefit.

Sure. But compilers don't exploit those in practice (because compiler authors are not language lawyers for fun), so they're basically harmless in practice. They're essentially just spec bugs for the committee to fix in the next revision.

Post reply on HN