Live data from Hacker News

Cross-platform Rust rewrite of the GNU coreutils

github.com

181–190 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#181
post #55

Earlier quoted context omitted.

"Maybe glance" might well make it derivative.

This is very very weak grounds for any sort of lawsuit. But if having glanced at GPL source code prevents implementing similar functionalities in an entirely different language, that's a pretty darn strong argument for me to never look at GPL code again.

If you're not trying to copy someone else's product, then you're probably ok

Re: Cross-platform Rust rewrite of the GNU coreutils

#183

Earlier quoted context omitted.

Supported, just but it's a second class citizen, for example, no tab completion of directories on the cmd prompt when using forward slash. Some commands will not except it; e.g. type c:\home\foo.txt -> cats it out type c:/home/foo.txt -> 'The syntax of this command is incorrect.' whereas cd will except either forward or backslash cd c:\home/foo cd c:/home/foo work as expected.

Firstly I was talking about API support. Since that is the topic at hand. Secondly, Cmd is deprecated. Powershell supports both slashes and "type c:/home/foo.txt" works perfectly.

But Powershell redirects either don't work or can corrupt your files

Re: Cross-platform Rust rewrite of the GNU coreutils

#186
post #52

Earlier quoted context omitted.

This is a terrific project idea, but I agree that it should likely be under the GPL. Even if it is not legally derivative, it would be nice to preserve the GPL.

Sometimes the maximising the likelihood of a set of components being used is more important than potential licensing constraints. In this particular case, if they're not GPL, they're more likely to be used for various *BSD systems and in a variety of embedded contexts. Improving the general security and reliability of all systems seems like it might potentially be a more valuable goal.

I'm with you there. Plus, mobile and embedded means lots of stuff gets integrated tightly with hardware. Those people will not risk hardware or interface secrets in firmware being released under GPL. So, having BSD'd stuff for them to use in stuff we have to buy is a nice quality improvement for us. Even Stallman admits it's better for things standardized between proprietary and FOSS like codecs where they surely won't use GPL stuff.

Re: Cross-platform Rust rewrite of the GNU coreutils

#187

Rust is a great choice for systems programming it'd seem. Esp considering that a well-tested, battle-hardened code-base like SQLite faces problems [1] solely due to the nature of the language its written in. [1] https://news.ycombinator.com/item?id=11312918

Not sure why you're being downvoted. I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code.

Don't underestimate performance. I haven't seen the most recent benchmarks, but C/C++/Fortran are still unbeatable in raw speed. If you want maximum performance no matter what, these are the languages to choose, even if they sacrifice readability, maintainability or safety.

Re: Cross-platform Rust rewrite of the GNU coreutils

#188
post #83

Earlier quoted context omitted.

I've contributed to this project, and yeah, this was a major concern for me while I was doing it. If it shared a license with GNU coreutils, then code sharing would be free and the project would be built much faster because I could just use coreutils's algorithms. As it is, I haven't done any real, hard work for it because frankly, I won't want to re-invent that wheel. The project isn't terribly far along. I wonder i…

I've submitted an issue asking to shift to a GPL license. My general perspective on code I write that isn't for work - it has to be GPL. I refuse to have my code be yoinked by random corporations for their profit without having the code shared downstream.

Like many other programmers, I avoid GPL'd code like the plague. The idea that you can own an idea seems ridiculous to me, and it feels unjust to sue "random corporations" for using ideas that you published. We're standing on the shoulders of giants, and I see the GPL as a tumor that's draining the world's resources.

Just my two cents.

Re: Cross-platform Rust rewrite of the GNU coreutils

#189

Rust is a great choice for systems programming it'd seem. Esp considering that a well-tested, battle-hardened code-base like SQLite faces problems [1] solely due to the nature of the language its written in. [1] https://news.ycombinator.com/item?id=11312918

Rust is a terrible choice. Its standard library assumes malloc never fails.

I'm not a Rust expert but everywhere I could find heap::allocate it checks for null.

Re: Cross-platform Rust rewrite of the GNU coreutils

#190

Earlier quoted context omitted.

The Rust standard library does assume that allocation succeeds. The language itself knows nothing about the heap, and so you can write allocators that do whatever you wish. Side note: on most Linux distros, overcommit is on, and so malloc will basically always succeed; the OOM killer will kill your program before you'd get a failure. I am less knowledgeable about OSX and Windows. I cannot speak to SQlite in this rega…

Holy crap, I'd never have imagined that... A design that assumes allocation always succeeds flies in the face of decades of safety/security-critical coding wisdom. I strongly recommend the team revisit and change that somehow to account for failures, NULL's, whatever. Actually, same anywhere a failure-prone, esp hardware, resource is acquired. C apps can handle this issue so Rust should as well if it's to replace the…

Note that Rust, the language, is perfectly capable of handling memory allocation failures, it's just the standard library that makes the assumption. Embedded environments wouldn't use the standard library for numerous reasons anyway, and the "core" library uses no allocation at all. That said, IIRC handling of failure in the standard library will happen eventually, I believe there's just no consensus yet on the best way to do it.
Post reply on HN