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

471–480 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#471

Post by belorn »

greggyb wrote: post #422
cname wrote: post #247

Earlier quoted context omitted.

What on earth does the GPL have to do with owning _ideas_? Please explain. Also, do you think that Linux, for example, is draining the world's resources? If so, how?

If your code is GPLed you impose a cost on someone else to use it. Whether or not that cost is morally justified is not the point of the objection. I am making no judgment as to the righteousness of the goal of using a GPL or similar license. By using a GPL you strictly limit who can consume your code to those who are willing to be bound by your views on what is right. In this way (and limited explicitly to the scope…

What you describe seems to me exactly what John Locke said about Freedom of nature vs Freedom of people.

Freedom of nature is to be under no other restraint but the law of nature. Freedom of people under government is to be under no restraint apart from standing rules to live by that are common to everyone in the society

A license which enforce a share-and-share-alike system is to me much closer to freedom than if it allowed everyone to do what he likes, to live as he pleases, and not to be tied by any laws.

Re: Cross-platform Rust rewrite of the GNU coreutils

#472

Post by belorn »

ChristianBundy wrote: post #188
pnathan wrote: post #150

Earlier quoted context omitted.

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.

I have been thinking that I should dual license my code under GPL and a license which forbids the enforcement of copyright and patents. People could then chose the one which one align closer to their philosophy.

Something like: Recipient of this software can do what ever they want so long they agree to a contract that bounds them to never do enforcement, in legal and technical form, for copyright and patents.

A complete ban on lawsuits for copyright infringement and patents, including the use of DRM technology that manage and enforces copyright and patents. It is also not limited to just the work that I distribute, but as a contract would cover everything the recipient create or has created, be indefinite, and with harsh fines if broken. I do not think a single person or company who refuse to use GPL would instead accept that deal. Will you be the first person to accept such deal and forever stop creating tumors on the worlds resources by putting software under proprietary licenses?

Re: Cross-platform Rust rewrite of the GNU coreutils

#473

Post by krylon »

eru wrote: post #456
krylon wrote: post #453

Earlier quoted context omitted.

Well. I'll gladly admit that the C code I have written was way less complex than a web browser. When I still wrote C code for a living, I worked on an application suite that was ~250k lines of code, maybe ~300k, in total, whereas e.g. Firefox is a couple of million lines. I assume other mainstream browsers are similarly big. Plus, what a browser does is, by nature, a lot more complicated than what I worked on. EDIT:…

Yeah, browsers are essentially interpreters (and nowadays compilers) for a variety of crazy languages (html, css, javascript; probably a few more?). You don't want to be writing your interpreters in C.

> You don't want to be writing your interpreters in C.

Well, technically, I think most browsers these days are written in C++, but your point remains valid.

OTOH, the "default" Python interpreter is written in C, and so is Perl (Ruby MRI, too, I think, but I am not 100% certain). I cannot recall any major security problem with those languages that originated inside the interpreter (which, of course, does not mean those did not/do not exist). Then again, a web browser is probably far messier in terms of what input is has to deal with.

Re: Cross-platform Rust rewrite of the GNU coreutils

#474

Post by masklinn »

krylon wrote: post #473
eru wrote: post #456

Earlier quoted context omitted.

Yeah, browsers are essentially interpreters (and nowadays compilers) for a variety of crazy languages (html, css, javascript; probably a few more?). You don't want to be writing your interpreters in C.

> You don't want to be writing your interpreters in C. Well, technically, I think most browsers these days are written in C++, but your point remains valid. OTOH, the "default" Python interpreter is written in C, and so is Perl (Ruby MRI, too, I think, but I am not 100% certain). I cannot recall any major security problem with those languages that originated inside the interpreter (which, of course, does not mean tho…

> Then again, a web browser is probably far messier in terms of what input is has to deal with.

That's the ticket, the browser does have a large attack surface but more importantly it's supposed to safely execute completely arbitrary and untrusted payloads. In the same category are pretty much all of the usual suspect of security issues: flash, java (applets), …

Most interpreters are only fed trusted payloads, lest the developer starts eval'ing stuff they got from god knows where, and in that case the fault is usually laid to the developer's feet rather than the interpreter's.

Re: Cross-platform Rust rewrite of the GNU coreutils

#475

Post by rkangel »

sesutton wrote: post #189
quotemstr wrote: post #99

Earlier quoted context omitted.

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.

Any time you do Box::new() you are allocating memory. There is no way do report allocation failure from that - the program will panic.

Re: Cross-platform Rust rewrite of the GNU coreutils

#476

Post by rkangel »

Maken wrote: post #74
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.

You don't need a C standard library to run programs on Linux (nor any other system). My guess is that the Rust team consider that relying on a well tested C codebase is safer than writing tons of unsafe platform-specific code, to replace the functionality offered by libc. Anyway, I think the Redo project do have a Rust standard library that calls directly the OS and doesn’t need a C library, since they are writing a…

> My guess is that the Rust team consider that relying on a well tested C codebase is safer than writing tons of unsafe platform-specific code, to replace the functionality offered by libc.

I'm copying that to my notes to use as a clear and concise explanation to people who want to work 'around' libc.

Re: Cross-platform Rust rewrite of the GNU coreutils

#477

Post by samth »

lomnakkus wrote: post #410
samth wrote: post #337

Earlier quoted context omitted.

> I don't think that they're eliminated because dynamic testing can't eliminate everything—it only finds bugs given its test inputs. I can't think of an example of UB-exploit in the compiler that wouldn't result in different branch behavior, and thus, I think, in failure of MC/DC. But I may simply be insufficiently imaginative. John makes the point about source code in a follow-up comment, and I agree, but I also see…

> I can't think of an example of UB-exploit in the compiler that wouldn't result in different branch behavior, What about Implementation-defined Behavior? This is (I think!) technically a subset of Undefined Behavior and it permits such things as setting values[1] to arbitrary (but well-defined!) values on various operations, such as "excessive" left shifts. What I'm saying is that a compiler is permitted to substitu…

I think you're confused about implementation-defined and undefined behavior. The former is not a subset of the latter, but excessive left shifts are UB.

Re: Cross-platform Rust rewrite of the GNU coreutils

#478

Post by AnimalMuppet »

pcwalton wrote: post #429
AnimalMuppet wrote: post #397

Earlier quoted context omitted.

> Yes, this is all modern C++. Is it? You're telling me that all code in all browsers have been re-written into C++11 (or C++14) with best practices? I don't believe you. At a minimum, I'm going to need some documentation before I believe that. [Edit: I'm not trying to pull a No True Scotsman here. I just doubt that browsers have been completely rewritten into modern C++, or with anything approaching best practices.…

Most exploits tend to be in new code (contrary to popular belief), which in all modern browsers is written in modern C++. The WTF (Blink/WebKit) and the MFBT (Firefox) are state-of-the-art template libraries; you are free to search for those libraries and verify for yourself. New C++11 features such as rvalue references do nothing to avoid memory safety problems; in fact, they make them worse, since "use-after-move"…

No, I wasn't asserting that there is some magic C++ feature that the browsers aren't using. "Most exploits tend to be in new code" was the piece of your argument that I was missing.

Re: Cross-platform Rust rewrite of the GNU coreutils

#479

Post by cbsmith »

kbenson wrote: post #418
cbsmith wrote: post #413

Earlier quoted context omitted.

With portable software (as in, portability is more valuable than other factors), imperfect is the enemy. ;-)

We have over four decades history of portability being valued over correctness, stability and security. I'm not impressed with where it's gotten us.

See, I look at it as the opposite. You aren't really portable if your code isn't correct.

Re: Cross-platform Rust rewrite of the GNU coreutils

#480

Post by igouy »

jfoutz wrote: post #210
andrepd wrote: post #187

Earlier quoted context omitted.

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.

Well, rust is beating g++ in the benchmark game now. [1] (please don't take microbenchmarks seriously) Performance is complicated, rust has a couple of things going for it that will help out a lot. First, there's a pretty strong bias to use the stack. As opposed to java or scheme where stuff is heap allocated by default. Second, rust avoids the pointer aliasing problems of c and c++. When someone gets around to makin…

Take microbenchmarks seriously as true statements that such & such measurements were made of particular programs.

Please don't generalize that into language X is beating language Y.

Post reply on HN