Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting essential Linux packages in Rust

lwn.net

Post reply on HN
Print view View original

141–150 of 175 posts

Re: Rewriting essential Linux packages in Rust

#141

Post by Gud »

grg0 wrote: post #35
tmtvl wrote: post #29

Rewriting GPL software under the MIT license is a terrible thing to do. The GPL is meant to protect and preserve what should be basic human rights. So-called "permissive" licenses are meant to provide big tech with free labour.

Yup, and one doesn't need to look further than FreeBSD to see what the end result is. I wonder, to what extent is the Linux Rust effort "generously subsidized" by corporations? > He is thinking about ""what we are going to leave to the next generation"". Developers starting out don't want to use COBOL, Fortran, or C, he said. They want to work with fancy stuff like Rust, Swift, Go, or Kotlin. Oh, think about the chil…

What’s the problem with FreeBSD?

It’s been my daily driver for 20 years. That it has an open license is a good thing.

Re: Rewriting essential Linux packages in Rust

#142

Post by Gud »

bayindirh wrote: post #75
mrighele wrote: post #70

Earlier quoted context omitted.

What is released under MIT (or BSD) will stay under that license forever, so it cannot "be closed anytime". The owner can change the license, but that will affect only future developments.

Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made. IOW, this is de-facto closed source distribution. What happens when a company decides to add their own secret sauce and release that version only, or what happens tons of slightly incompatible, closed source variants pop-up, what happens upstream decides to not…

Yes, obviously the license can change by the author. The same can be done with GPL software.

But what has once been licensed under a permissive license, will remain free forever.

Only the changes will be affected.

Re: Rewriting essential Linux packages in Rust

#143

Post by kazinator »

pabs3 wrote: post #136
kazinator wrote: post #134

Earlier quoted context omitted.

You don't need to read the GPL, or any other free software license, to modify a program and to run it.

Modifying a program is illegal under copyright law, so yes you do need to read the license before doing that.

No, copyright law doesn't say anything about privately modifying a work. Only about distributing derived works.

It would behoove you to check the license in order to confirm that whoever gave it to you had the right to do so.

Beyond confirming that you have a legit copy, you don't have to be concerned with the license at all, if you're not redistributing anything.

The vendors of proprietary software and their lawyers dreamed up this idea that a license can lapse based on the user's non-redistributing uses of the work. For instance, if the user reverse-engineers the binary code to understand how it works, then they become unlicensed, the idea then being that they are perpetrating copyright infringement by continuing to have a copy.

The AGPL falls into this category.

The restriction itself does not come from copyright law; copyright law doesn't say things like that allowing network users to interact with a software program is an infringing activity, or that reading the work to understand it is infringing activity.

Re: Rewriting essential Linux packages in Rust

#144

Post by noja »

yjftsjthsd-h wrote: post #73
nine_k wrote: post #50

Earlier quoted context omitted.

The previous developers might have written it at the time when VM disk RAID images were not a consideration. (Apparently it was Linux 3.0, 2011.)

But even then, the device nodes should be protected by file ownership+permissions; why does the tool do its own check?

Chesterton’s fence. Ask the developer.

Re: Rewriting essential Linux packages in Rust

#145

Post by grandempire »

burntsushi wrote: post #140
grandempire wrote: post #126

Earlier quoted context omitted.

> I think my comment already addressed every single piece of what you said here. You did not mention a word about scripting. > But that's not what you originally said. It is. The reason ripgrep should not be in base is because it’s not posix compliant.

As I said, there are tons of things in `base` that aren't POSIX compliant. So that is clearly not a sufficient criteria to exclude something from `base`. You need something else (like what I said, and then you repeated without acknowledging that I had already said it). > You did not mention a word about scripting. WTF. Literally right there in my first comment: > Of course, grep still has a POSIX compliant base. And…

> Literally right there in my first comment:

In regards to ripgrep

> that is clearly not a sufficient criteria to exclude something from `base`. You need something else

The burden is on you to demonstrate why it should be included absent of a standard, not me to show why it should be excluded. Base maintenance work is a scarce resource.

Your only argument so far has been that posix compliance doesn’t matter.

This interaction is actually souring me on the project.

Re: Rewriting essential Linux packages in Rust

#146

Post by burntsushi »

grandempire wrote: post #145
burntsushi wrote: post #140

Earlier quoted context omitted.

As I said, there are tons of things in `base` that aren't POSIX compliant. So that is clearly not a sufficient criteria to exclude something from `base`. You need something else (like what I said, and then you repeated without acknowledging that I had already said it). > You did not mention a word about scripting. WTF. Literally right there in my first comment: > Of course, grep still has a POSIX compliant base. And…

> Literally right there in my first comment: In regards to ripgrep > that is clearly not a sufficient criteria to exclude something from `base`. You need something else The burden is on you to demonstrate why it should be included absent of a standard, not me to show why it should be excluded. Base maintenance work is a scarce resource. Your only argument so far has been that posix compliance doesn’t matter. This int…

How could you possibly miss this in my first comment???

> Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default.

...

> This interaction is actually souring me.

You and me both. Maybe you could try actually reading my comments. I feel like I'm talking to an AI that has been trained to be maximally annoying through gaslighting.

So unless you can demonstrate that you're a real person (like my profile does), you're now on my ignore list.

Re: Rewriting essential Linux packages in Rust

#147

Post by [deleted] »

burntsushi wrote: post #146
grandempire wrote: post #145

Earlier quoted context omitted.

> Literally right there in my first comment: In regards to ripgrep > that is clearly not a sufficient criteria to exclude something from `base`. You need something else The burden is on you to demonstrate why it should be included absent of a standard, not me to show why it should be excluded. Base maintenance work is a scarce resource. Your only argument so far has been that posix compliance doesn’t matter. This int…

How could you possibly miss this in my first comment??? > Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default. ... > This interaction is actually souring me. You and me both. Maybe you could try actually reading my comments. I feel l…

[deleted]

Re: Rewriting essential Linux packages in Rust

#148

Post by pabs3 »

kazinator wrote: post #143
pabs3 wrote: post #136

Earlier quoted context omitted.

Modifying a program is illegal under copyright law, so yes you do need to read the license before doing that.

No, copyright law doesn't say anything about privately modifying a work. Only about distributing derived works. It would behoove you to check the license in order to confirm that whoever gave it to you had the right to do so. Beyond confirming that you have a legit copy, you don't have to be concerned with the license at all, if you're not redistributing anything. The vendors of proprietary software and their lawyers…

AFAICT, American copyright law does say "To prepare derivative works based upon the work" is not allowed, and doesn't say anything about private derivatives being an exception to that.

https://en.wikipedia.org/wiki/Copyright_law_of_the_United_St...

Certainly if you privately modify it is going to be unlikely for someone to find out you did that, but that doesn't make it any less illegal.

Re: Rewriting essential Linux packages in Rust

#149

Post by kazinator »

pabs3 wrote: post #148
kazinator wrote: post #143

Earlier quoted context omitted.

No, copyright law doesn't say anything about privately modifying a work. Only about distributing derived works. It would behoove you to check the license in order to confirm that whoever gave it to you had the right to do so. Beyond confirming that you have a legit copy, you don't have to be concerned with the license at all, if you're not redistributing anything. The vendors of proprietary software and their lawyers…

AFAICT, American copyright law does say "To prepare derivative works based upon the work" is not allowed, and doesn't say anything about private derivatives being an exception to that. https://en.wikipedia.org/wiki/Copyright_law_of_the_United_St... Certainly if you privately modify it is going to be unlikely for someone to find out you did that, but that doesn't make it any less illegal.

Preparation means getting ready for something. here, that almost certainly means redistribution.

You're not breaking the law if you scribble notes in the margin of a textbook; that's just crazy. Even if you pass that on to a friend, for that matter.

Anyway, if a license tries to rely on such draconian doctrines to prevent uses, it's obviously not a free license.

Re: Rewriting essential Linux packages in Rust

#150

Post by linsomniac »

yjftsjthsd-h wrote: post #45
linsomniac wrote: post #37

Earlier quoted context omitted.

I like some of the directions you're heading with that. One thing I've thought is it might be useful to have tools that create filesystem objects (like "new" or "mov foo bar/") be able to take permissions. "mov --umask 027 --owner alice:bob foo bar/" and "new --mode a=rx foo/" for example.

install(1) does that: https://www.man7.org/linux/man-pages/man1/install.1.html

Indeed, under very limited circumstances of copying files and the man page says "-o" and "-g" only work as superuser, though I just tested it and that seems to be more a note about how chgrp()/chown() work (if you are changing to a group/user you don't have privs for), and it works in the case of a copy. Indeed very useful in some cases; I use it in CI/CD pipelines and Dockerfiles typically.
Post reply on HN