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

491–498 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#491

Post by Dylan16807 »

pcwalton wrote: post #490
Dylan16807 wrote: post #489

Earlier quoted context omitted.

They got a report of dodgy code. Looking at the code, it was intentional but unimportant and also violated the C standard. So they removed it, and they removed it badly. If it had been valid by the C standard, it is not unlikely that they would have kept it. Then there would have been no disaster. They would not have gotten confused about what was valid and what wasn't. Extra entropy to mix in isn't that silly. Edit:…

No, this is again completely incorrect. This had nothing whatsoever to do with the C standard. This is Valgrind's issue. Valgrind does not care about what the C standard says. Valgrind is a bug-finding tool and as such can make its own rules. Once again, if the C standard were to change to allow uninitialized variables to have live ranges, Valgrind would not just "git rm -rf memcheck; git commit". That is because Val…

I think it's likely they would have kept the code that valgrind didn't like if it was not a violation of the C standard. I don't understand why you completely reject that as a possibility.

I don't blame all problems on C, but I think it should be easier to write valid C. Dealing with uninitialized variables was just an example of something that could be changed. It wasn't supposed to be the biggest most horrible problem with C.

Compilers may not turn functions that hit most kinds of UB into { return; }, but they can. As a general category, that's a bad thing.

Re: Cross-platform Rust rewrite of the GNU coreutils

#493

Post by pcwalton »

Dylan16807 wrote: post #491
pcwalton wrote: post #490

Earlier quoted context omitted.

No, this is again completely incorrect. This had nothing whatsoever to do with the C standard. This is Valgrind's issue. Valgrind does not care about what the C standard says. Valgrind is a bug-finding tool and as such can make its own rules. Once again, if the C standard were to change to allow uninitialized variables to have live ranges, Valgrind would not just "git rm -rf memcheck; git commit". That is because Val…

I think it's likely they would have kept the code that valgrind didn't like if it was not a violation of the C standard . I don't understand why you completely reject that as a possibility. I don't blame all problems on C, but I think it should be easier to write valid C. Dealing with uninitialized variables was just an example of something that could be changed. It wasn't supposed to be the biggest most horrible pro…

> I think it's likely they would have kept the code that valgrind didn't like if it was not a violation of the C standard. I don't understand why you completely reject that as a possibility.

It's highly unlikely that the maintainer of OpenSSL at Debian is a spec lawyer. The maintainer ran Valgrind because, as a general principle, reading undefined memory is bad. That is independent of whether the C standard says that it's OK. If I were the maintainer of the package in question, I would not ignore reads of undefined memory just because the C committee has declared that it has some kind of behavior. That would be silly.

Valgrind contains many tools that check for things that are not violations of the C standard: for example, memcheck checks for "fishy" arguments to malloc that are not C standard violations but are nevertheless usually bugs.

> Compilers may not turn functions that hit most kinds of UB into { return; }, but they can. As a general category, that's a bad thing.

Depends on the undefined behavior. For undefined behavior coming from the C preprocessor, sure, that shouldn't be undefined, and the committee should change the spec. For other kinds of UB, if compiler authors hadn't figured out those tricks, we'd have slower programs today. Undefined behavior is much of what has allowed performance of our programs to keep improving despite the language not changing over decades.

Re: Cross-platform Rust rewrite of the GNU coreutils

#494

Post by greggyb »

belorn wrote: post #471
greggyb wrote: post #422

Earlier quoted context omitted.

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…

The basic division is negative rights vs positive rights, or at least that's how I frame it internally. A negative right is, very simplified, a right to be left alone. A positive right is a right to a specific item/privilege/behavior.

I think the wikipedia article[0] sums it up better than I can:

> positive rights usually oblige action, whereas negative rights usually oblige inaction.

There's some nuance between "do whatever you want" and "do whatever you want so long as it doesn't fuck with someone's day."

I'd really recommend the wikipedia article for a better treatment than I have time to give the discussion right now.

[0] https://en.wikipedia.org/wiki/Negative_and_positive_rights

Re: Cross-platform Rust rewrite of the GNU coreutils

#495

Post by greggyb »

abecedarius wrote: post #451
greggyb wrote: post #422

Earlier quoted context omitted.

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…

Curious: I'm an admirer of Friedman and a developer of GPL code. (GPLv3 is my default for new code.) Note that you can offer your code on different terms to customers who won't 'pay' the GPL. Is your position that software should be public domain?

I'm actually not taking a position, but trying to help provide nuance in a debate that often teems with zealotry, and do so in a reasonable manner to provoke thought rather than vitriol.

My unexamined default inclination would be toward a BSD or MIT style license than a GPL. You may infer what you like about my default leanings in other areas if you like.

I've not given enough thorough thought toward software copyright to have a strong opinion as to the morally right position. This is not to undercut my comment and the observations I made above, but to make clear my standing which is ambivalent. I can certainly understand both sides of the argument and respect the position people speak from for either (to be explicit, the poles of the continuum being public domain on one end, with MIT/BSD licenses leaning far that way and hardcore copyleft on the other with GPL being the canonical example toward that end).

Toward the Friedman quote, that was not an attempt at appeal to authority to discredit the idea of copyleft, but an observation about the type of person (or at least the general tone of argument) who most vocally defends GPL licensing. If anything it was an appeal to authority to please be thoughtful about how to respond to my comment, and more to the point of why I included it, because it popped into my mind while responding.

This is a long-winded non-answer so far.

Really, what I was trying to do was to emphasize that there are costs to a GPL license, and that a reasonable person may think of those costs as such and not as freedoms. If you look at my response to a sibling comment, I'm thinking about this in terms of negative vs positive rights.

Looking at Friedman, I would certainly characterize him as someone who leans toward defining negative rights as freedom/liberty and positive rights as limitations thereupon. I would also characterize myself as leaning that way (so maybe I'm attributing my own views onto him). This is not to imply you are a hypocrite or declare that it is right or in any way argue against a GPL copyright in general, but just an observation.

Re: Cross-platform Rust rewrite of the GNU coreutils

#496

Post by abecedarius »

greggyb wrote: post #495
abecedarius wrote: post #451

Earlier quoted context omitted.

Curious: I'm an admirer of Friedman and a developer of GPL code. (GPLv3 is my default for new code.) Note that you can offer your code on different terms to customers who won't 'pay' the GPL. Is your position that software should be public domain?

I'm actually not taking a position, but trying to help provide nuance in a debate that often teems with zealotry, and do so in a reasonable manner to provoke thought rather than vitriol. My unexamined default inclination would be toward a BSD or MIT style license than a GPL. You may infer what you like about my default leanings in other areas if you like. I've not given enough thorough thought toward software copyrig…

The arguments can get unfortunate, yeah.

With copyright (unlike patents), when I offer some code under some conditions, to first order I haven't subtracted anything from you -- you're free to ignore my code, maybe write your own. This isn't so different from offering you a banana for a buck, or a free bench in the park provided it carries a memorial plaque to my grandfather.

I used to default to the MIT license, basically saying "just don't be a dick about the authorship or the non-warranty". Over the years many companies, like Apple, incorporated this sort of software into platforms and products that circumscribe my freedom -- products that I "own" but can't legally control. The GPL (especially v3) is a compact of people building an alternative to this locked-down world. Closed platforms seem to me a much greater, and increasing, encroachment on our freedom in practice than the inability to legally incorporate GPL code into closed software. Both of these restrictions, closed-only platforms and open-only code, are things someone is choosing to offer and you are choosing whether or not to use -- I don't see a difference re: positive or negative rights, technically. (But I'm not super-interested in rights-centric political theory.)

Re: Cross-platform Rust rewrite of the GNU coreutils

#497

Post by eru »

masklinn wrote: post #474
krylon wrote: post #473

Earlier quoted context omitted.

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

Yeah. The browser is more like a hypervizor that Amazon might be running to run arbitrary people's VMs. But it has an unimaginably larger surface area than Xen.

Re: Cross-platform Rust rewrite of the GNU coreutils

#498

Post by goodplay »

lfowles wrote: post #487
goodplay wrote: post #458

Earlier quoted context omitted.

The only reason I use the GPL is to safeguard the general public's rights to modify and distribute my software. If anything, I'd argue that releasing GPL software works against the author as it makes making money off it substantially more difficult.

The general public still retains the right to modify and distribute your software with a license such as MIT. Your software does not cease to exist once megacorp uses it for a product. The guarantee of GPL is that megacorp is now obligated to share their modifications (but practically, to go find another library or write their own).

You're missing the forest for a single tree. The obligation to redistribute changes under the same license is not the only reason to use the GPL. The license's safeguarding of end-users' right to fix and modify GPLed software is a far more important reason, and is the reason why I and many people like me choose the GPL.

I don't want to restrict developers and corps. After all, I am a developer who wants control over my hard work. However, I also don't want to erode the rights of end-users - of whom I also am. I don't want to end up in a situation where I can't fix a bug in my own software because a corporation wont let me.

It's a trade off. I choose end-users.

Post reply on HN