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

271–280 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#271

Post by pcwalton »

samth wrote: post #263
pcwalton wrote: post #138

Earlier quoted context omitted.

> This is itself a straw man. Follow the link to Mr. Hipp's comments and read them. He did not say this. "Rust doesn't eliminate all bugs" is a rephrased version of "Some well-formed rust programs will generate machine code that behaves differently from what the programmer expected." > That a programmer who has produced such high-quality and rigorously tested software as sqlite should be portrayed as either cavalier…

I don't think he's making the argument you think he's making. This is clearer in his later comments in the thread, in which he says that UB is much scarier in systems like Fossil. His argument is that achieving the level of quality that SQLite has requires verification (in a broad sense) after the compiler, and that's what he does. If you consider the goal to be producing quality-assured binaries, then you can treat…

> His argument is that achieving the level of quality that SQLite has requires verification (in a broad sense) after the compiler, and that's what he does.

> If you consider the goal to be producing quality-assured binaries, then you can treat UB, compiler bugs, and many other things as falling in a similar category, which are almost certainly eliminated by an MC/DC test suite.

I don't think that they're eliminated because dynamic testing can't eliminate everything—it only finds bugs given its test inputs.

Moreover, though, I'm also skeptical of the claim that binaries are all that matter. Lots of software projects (for example, Firefox) import SQLite as source into the project instead of using the binaries. They upgrade their compilers without running the SQLite test suite to catch regressions. (Firefox might, but I'm sure lots of other projects using SQLite from source don't.)

> But it does mean that rewriting SQLite in Rust wouldn't provide as much value as rewriting many other things where the binaries do not have such guarantees.

Sure; static analysis is more useful in systems that aren't as well dynamically tested. But static analysis still has value.

Re: Cross-platform Rust rewrite of the GNU coreutils

#272

Post by jahewson »

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....

No it really doesn't. Code which implements the same API is going to look pretty similar, for example ReactOS looks a hell of a lot like Windows. But it's not been copied.

Re: Cross-platform Rust rewrite of the GNU coreutils

#273

Post by jahewson »

TallGuyShort wrote: post #86
amelius wrote: post #62

Earlier quoted context omitted.

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 an…

There's nothing wrong with reading the source code. You're allowed to read whatever you like! Just don't copy it.

Re: Cross-platform Rust rewrite of the GNU coreutils

#274

Post by pcwalton »

Alupis wrote: post #269
pcwalton wrote: post #261

Earlier quoted context omitted.

> 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…

> That isn't a definition of "fast moving" that I would use. It sounds like slow moving. Perhaps I didn't word it correctly. When you want to write the next WhatsApp, you don't have to start from scratch. The OS has been taken care of for you, and you can expect it to "just work". This solid foundation allows innovation to build on-top, at a rapid pace. If your foundation was constantly changing, you'd have to accoun…

> At the time, a lot of systems were written in pure assembler, and it took a long time to convince those guys that C was ready as a replacement for most tasks (and C changed dramatically in that time period).

And they were wrong to resist C. They should have switched over sooner.

> today with all these things built on top (financial markets, governments, big mega-corps, small ma n' pa shops, etc...), we need slower changes in order to keep the stability.

Stuart Feldman, on why Makefiles insist on tabs:

"After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history…"

Stability is important, but eventually you do have to go back and fix things that are wrong for us to move forward.

Re: Cross-platform Rust rewrite of the GNU coreutils

#275

Post by alixaxel »

The CoreUtils sort is amazingly efficient, it can sort files nearly as big as your hard drive without matching memory requirements.

With all these node.js / Go / Rust CoreUtils implementations I'm still hoping for one of them to actually match the efficiency of the original implementation.

Re: Cross-platform Rust rewrite of the GNU coreutils

#276

Post by jordigh »

jahewson wrote: post #262
jordigh wrote: post #214

Earlier quoted context omitted.

Reading GPL'ed code and reimplementing it makes a good case for why the rewrite should also be GPL'ed. I don't know if they did this here, but if so, they should GPL their version as well. For GNU Octave, we stress very strongly that anyone who has read Matlab's source code is ineligible to contribute to Octave. This is because, should it ever come down to it, we want to be able to ascertain that our implementation i…

Nope, just as reading non-GPL'd code and then writing a GPL'd version is legitimate, so too is reading GPL'd code and writing a non-GPL'd version. As long as you're not literally copying and pasting the code. While you're free to invent any contribution rules you like for Octave, there's really no need for such drastic measures. It might give you a nice piece of mind, but it's not legally necessary - it's perfectly p…

Are you a lawyer? Because other lawyers have told me otherwise. Would you happen to know of cases where your interpretation has been upheld?

Re: Cross-platform Rust rewrite of the GNU coreutils

#277

Post by mikevin »

yberreby wrote: post #266
mikevin wrote: post #215

Earlier quoted context omitted.

Do you use all of the autocompletion options you listed? Or is YCM with --racer-completer enough?

I don't see another autocompletion option than YCM with --racer-completer in my list, so yes and yes. I use all the tools I listed regularly.

You listed racer + racerd separately so I wasn't sure if you meant the --racer-completer option or a different approach. Thanks.

Re: Cross-platform Rust rewrite of the GNU coreutils

#279

Post by pjmlp »

pcwalton wrote: post #240
Alupis wrote: post #113

Earlier quoted context omitted.

> 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 agree in principal, however the timing is wrong. Rust is a very new language (less than 6 years old), and is undeniably totally unproven. It is the latest "buzz" language, and may not be around long term... nobody knows. What-more, a full-fledged re-write of CoreUtils in…

> Flatly, re-writing a several decade's old, matured codebase in today's flavor-of-the-week language is not a good idea. It's odd that so many in the computing industry are unwilling to move on from a language from 1978 . We think of ourselves as one of the most fast-moving industries, but we have this odd reverence for early C and Unix that makes us stubborn and resistant to change. The fact is: we didn't know how t…

> The fact is: we didn't know how to do some things properly in 1978.

Actually we did know how to make it properly, as Extended Algol in Burroughs B5000 in 1961 was being used, just to cite one example from many others that were ignored by the UNIX authors, because they didn't want to spend too much effort designing a proper compiler.

Re: Cross-platform Rust rewrite of the GNU coreutils

#280

Post by jahewson »

pron wrote: post #55
steveklabnik wrote: post #26

Earlier quoted context omitted.

Well, that's a very large assumption, and it is a big part of that answer. I have sent in a few PRs to this project, and I have never done more than maybe glance at the source of coreutils, and it was for unrelated reasons. can't speak to the regular contributors, though.

"Maybe glance" might well make it derivative.

Nope. Reading something does not make any future work you do derivative. Discouraging people from reading and understanding the work of others is a particularly bad idea.
Post reply on HN