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.
Cross-platform Rust rewrite of the GNU coreutils
181–190 of 498 posts
Re: Cross-platform Rust rewrite of the GNU coreutils
#182Doesn't this imply there needs to be the Rust compiler / Cargo (if it needs that) installed on the system? And what versions - stable / unstable ?
Re: Cross-platform Rust rewrite of the GNU coreutils
#183Earlier 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#184Written in Rust, MIT-licensed, designed to be portable...I wonder if this is something that might eventually get merged into Redox?
Re: Cross-platform Rust rewrite of the GNU coreutils
#185Re: Cross-platform Rust rewrite of the GNU coreutils
#186Earlier 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#187Rust 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#188Earlier 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.
Just my two cents.
Re: Cross-platform Rust rewrite of the GNU coreutils
#189Rust 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#190Earlier 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…