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

151–160 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#151

Post by dublinben »

thedevil wrote: post #111
mapleoin wrote: post #22

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

Does anyone have more solid info on whether the GPL would apply in this case? I would really like to know if licensing agreements (and copyrights) still apply to ported code (assuming there's no patents on the algorithm).

Porting a program from one language to another would seem to be a pretty clear example of a derivative work. In this case, the original license (GPL) requires that any derivative works be offered under the same license.

Re: Cross-platform Rust rewrite of the GNU coreutils

#152

Post by aidenn0 »

yberreby wrote: post #124
gravypod wrote: post #64

Earlier quoted context omitted.

Here are the features I like in an IDE that make be very productive: - Autocompletion - Mass rename - Source formatting - Integrated debugger interface with breakpoint insertion and overlying of state on source - Integrated VCS control - Automated deploy - Error display - Automatic importing of modules - Source cleanup (Automatic loop transformation) - Automatically building my project That's just a few things that I…

Autocompletion: YouCompleteMe + racer + racerd Source formatting: rust.vim + rustfmt Automatic building: https://github.com/passcod/cargo-watch Error display: tmux, terminator or iTerm2 split planes Rust has pretty good tool support in vim and Atom, for example (can't speak for the rest). We don't have stellar IDE support yet, but it's on the to-do list: https://www.rust-lang.org/ides.html Personally, I don't miss ID…

> Error display: tmux, terminator or iTerm2 split planes

Split panes are a poor substitute for actual error display integration; highlighting the errors in the source-code viewer, combined with a cross-linked list of errors is far more useful.

Re: Cross-platform Rust rewrite of the GNU coreutils

#153

Post by gkya »

jfoutz wrote: post #137
gkya wrote: post #109

Earlier quoted context omitted.

For my use case, it's way more preferrable: a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex. b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS re…

there are two things that are nice about svn if you use it just like cvs. 1, atomic commits. I edit ten files, that's one checkin, rather than the per file checkins of cvs. On a low volume project, not a big advantage. if you've ever conflicted on a bigger project with cvs, it can be kind of a pain to resolve. seeing the whole commit of the other guy is helpful. If you don't run into this more than, say, monthly, it'…

All appreciated, but nowadays my biggest repo is my emacs config, some tens of thousand SLOCs, about 2000-2500 of which I authored (I commit packages I use too, no elpa). And my repositories are local, i.e. they are in /var/cvsrepos. Other than that, I admit that SVN is indeed superior.

I believe that one should use the best tool for the case, not the overall best tool in every case.

That said, I'll give a look at SVN. I can consider switch when I have the time if it is easy to import from RCS, because I do use it a lot here and there, mostly for plain text documents. I do not like maintaining unrelated things in a single repository.

Re: Cross-platform Rust rewrite of the GNU coreutils

#154

Post by wyldfire »

quotemstr wrote: post #99
ignoramous wrote: post #8

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 suppose this coreutils impl doesn't do it but one could perhaps use rust w/o its standard library and use strictly some libc instead. Would probably still be a net win.

Re: Cross-platform Rust rewrite of the GNU coreutils

#155

Post by ktRolster »

kbenson wrote: post #76
masklinn wrote: post #39

Earlier quoted context omitted.

I expect it's because because the first part is essentially preaching to the choir, and because Richard Hipp very much disagrees with the second part[0] > Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. (see link for expansion on that matter, which is a question of tooling and testing) [0] http://blog.regehr.org/archives/1292#comment-18452

Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in…

At some point some popular compiler is going to make a subtle but important change to some undefined behavior that's not going to be immediately obvious as to it's repercussions, and the fallout will be massive.

Wait until you realize that the length of a byte in C is not clearly defined. Someday a processor will come along where a byte is 6 bits, and the fallout will be massive. (Really, it's happened before).

No, actually that processor would not become popular because on one would use it.

The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language.

Re: Cross-platform Rust rewrite of the GNU coreutils

#156

Post by coldtea »

stepvhen wrote: post #54
coldtea wrote: post #40

Earlier quoted context omitted.

What exactly is this thing with 3 people commenting "I'll bite"? How is that the most obvious response to parent's observation about echo?

The OP is "luring" people with a small amount of information i.e. "bait," and other people will "bite," as a fish would, to learn the rest of the info.

Yeah, I know the phrase. What I find difficult to believe is that three random people responded with the same response on his simple 2 line comment.

I mean we see tons of comments with "small amount of information"/cryptic references that might similarly puzzle people in HN, but not equally many "I'll bite".

Re: Cross-platform Rust rewrite of the GNU coreutils

#157

Post by masklinn »

peterwwillis wrote: post #112
masklinn wrote: post #36

Earlier quoted context omitted.

http://www.in-ulm.de/~mascheck/various/echo+printf/ is the raw data version. POSIX defines echo as only taking string parameters and no options, but notes that behaviour facing `-n` is implementation-defined. BSD and GNU echo implement `echo -n` as not printing a trailing newline, but `echo` commonly calls to a shell builtin which may or may not follow that behaviour (and may switch behaviour depending on whether the…

The only operating systems that are certified to conform to POSIX are old Unix operating systems. GNU has always been non-POSIX. And honestly, a POSIX implementation would be more trouble than it's worth. The point of coreutils is to have utilities that make up the ability to write scripts for and interact with your operating system, right? Well, what operating system?? A POSIX-compliant one? Or just a mostly-POSIX-c…

That's not a question of certification or extensions, I'm talking about being able to write portable scripts. Due to the interaction between its definition and its extensions, echo is a prime example of being impossible to use portably (except in the very restricted case of only literal strings without escapes which don't start with a -).

> Ultimately, each platform has quirks, and it is up to the developer to port and test their script or application to a platform and make any necessary changes.

That is not humanly feasible and that's why specifications exists. You can't "port and test" your script to a platform which doesn't even exist yet, but if you follow the specification and the platform implements it (assuming it does so correctly) your scripts will run.

Re: Cross-platform Rust rewrite of the GNU coreutils

#158

Post by binarycrusader »

pron wrote: post #52
mapleoin wrote: post #22

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

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

#159

Post by dikaiosune »

kazinator wrote: post #104

Complete rubbish: Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old, abandoned, hosted on CVS, written in platform-specific C, etc. Rust provides a good, platform-agnostic way of writing systems utils that are easy to compile anywhere, and this is as good a way as any to try and learn it. Cygwin has…

Is the cygwin port just some different build files, or is it genuinely different code? A Rust codebase probably wouldn't (in most cases) need to be modified to run on different supported platforms.

Re: Cross-platform Rust rewrite of the GNU coreutils

#160

Post by wangchow »

thegeomaster wrote: post #12
ignoramous wrote: post #8

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.

Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust.

Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term.

Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and other optimizations.

Until hardware changes drastically there's no sense rewriting everything (unless of course it's just for fun). It's better use of time to study Math and lower-level concepts instead.

That being said, most businesses will take the quick pill instead.

Post reply on HN