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

81–90 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#81

Post by jblow »

alricb wrote: post #68
jblow wrote: post #41

Earlier quoted context omitted.

What is the roadmap on getting rid of the need for libc? Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.

Do you suggest they should use raw system calls? On most systems your options are either calling standard C functions or doing raw calls (not portable). Someone did start a C stdlib implementation in Rust, but it appears to be inactive: https://github.com/mahkoh/rlibc

Yes, the right thing is to port your language's standard library to whatever operating system you want to run on ... just like libc did.

You could have a dummy version that just calls out to libc, for compatibility with systems that you haven't finished porting to yet.

Re: Cross-platform Rust rewrite of the GNU coreutils

#82

Post by epistasis »

jeena wrote: post #63
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?

Just to give an example: https://github.com/uutils/coreutils/blob/master/src/whoami/p... looks suspically simmilar to: http://code.metager.de/source/xref/gnu/coreutils/src/whoami....

What's suspicious? Sharing the same two system calls in the same order, for a trivial function that really can be implemented the same way?

Re: Cross-platform Rust rewrite of the GNU coreutils

#83

Post by coldpie »

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?

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 if just starting a GPLed fork and building on that instead wouldn't be a better idea.

Re: Cross-platform Rust rewrite of the GNU coreutils

#84

Post by micampe »

_pfxa wrote: post #67

> 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. I have seen such a paragraph in another projects README, IIRC a Go rewrite of standard utilities. I do not understand why a project would be obsolete because it's on CVS or is old. CV…

I could see preferring svn to git because of the simpler model, but cvs? No thanks, a vcs without atomic commits is not much better than snapshot archives, maybe worse actually.

Re: Cross-platform Rust rewrite of the GNU coreutils

#85

Post by haberman »

masklinn wrote: post #39
thegeomaster wrote: post #12

Earlier quoted context omitted.

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.

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

He certainly has a point, but I think he goes too far in assurances about the current sqlite3.so.

Testing "every single instruction" does not guarantee that all C-level UB has been eliminated, because some bugs can be input-dependent. For example, even if your coverage tells you that this function has been tested, it could still trigger undefined behavior for other inputs that trigger overflow:

    int f(int x) { return x * 2; }

Re: Cross-platform Rust rewrite of the GNU coreutils

#86

Post by TallGuyShort »

amelius wrote: post #62
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?

Isn't this the same question as Google copying the API of Oracle's Java libraries?

IMO it's a little more complex: there's the question of copying interfaces, and the question of reverse engineering the implementation behind them. Many man pages are written such that it's clear how you should implement the logic so that all flags, etc. are interpreted in a well-defined and consistent manner with the original. But it's a billion times easier to just check out the source code for some of the tools and rewrite. Much easier, but possibly a different legal situation.

Re: Cross-platform Rust rewrite of the GNU coreutils

#87

Post by gkya »

ape4 wrote: post #51
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…

Whoever wrote the POSIX spec was too conservative. -n should mean no newline(s). Anything else is wrong.

  ECHO(1)                 FreeBSD General Commands Manual                ECHO(1)
  
  NAME
       echo — write arguments to the standard output
For this definition, -n should mean merely a sequence of two bytes to be written to stdout. Why not just use printf instead? It is way more flexible and powerfull, and "printf x" always prints "{'x', 0}";.

Re: Cross-platform Rust rewrite of the GNU coreutils

#88

Post by yxlx »

jeena wrote: post #63
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?

Just to give an example: https://github.com/uutils/coreutils/blob/master/src/whoami/p... looks suspically simmilar to: http://code.metager.de/source/xref/gnu/coreutils/src/whoami....

Really? I don't see much similarity.

Re: Cross-platform Rust rewrite of the GNU coreutils

#89

Post by gravypod »

niccaluim wrote: post #37
gravypod wrote: post #21

I'd really love to use rust, given the large growth of projects like this. I only need an IDE to get started, but it seems like there isn't one yet. Anyone have any pointers on where I can find a good IDE for Rust? Should I just start praying to lord-JetBrains for something that works?

If you've never programmed without an IDE I strongly encourage you to give it a go. You'll learn a lot! [Good lord, a downvote on this? I'm being completely sincere.]

I have programmed without an IDE. What I learned was that I'm much more productive with one then without.

An IDE lets me focus on the problem, not the language.

Re: Cross-platform Rust rewrite of the GNU coreutils

#90

Post by coldpie »

gravypod wrote: post #64
theonewolf wrote: post #24

Earlier quoted context omitted.

I don't understand why you need an IDE, I believe Rust is simple enough that you can work on things in Notepad++ or Vim or Emacs.

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…

Yeah. I'm a vim guy myself, but I totally understand the appeal of IDEs. Luckily Rust is a well-defined language (unlike C and C++), so building a nice IDE shouldn't be too arduous.
Post reply on HN