Live data from Hacker News

Rewriting essential Linux packages in Rust

lwn.net

61–70 of 175 posts

Re: Rewriting essential Linux packages in Rust

#61
post #3

Ripgrep should be included in all distros by default.

It’s a great tool, but it’s not a posix compliant grep.

I think it's more about having a stable interface. If it's not stable - you can't use it as a base tool long term. But if it's stable, what difference does it make if it's POSIX compliant or not?

Re: Rewriting essential Linux packages in Rust

#62
post #47
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.

Thanks for sharing this thought, it hadn't occured to me that this could be an issue. Would the choice of AGPL or MPL for a licence have satisfied your concerns?

Having both available means that someone can use it under the MIT license to produce a proprietary version.

Re: Rewriting essential Linux packages in Rust

#63
post #61

Earlier quoted context omitted.

It’s a great tool, but it’s not a posix compliant grep.

I think it's more about having a stable interface. If it's not stable - you can't use it as a base tool long term. But if it's stable, what difference does it make if it's POSIX compliant or not?

Because you aren’t the first one here. Countless lines of software exist which assumes posix. People learned how to use computers and know the grep commands. There is documentation for posix in places where it needs to be. It handles important edge cases which were needed by some groups and that was formalized into a standards requirement.

So changing to the new thing invalidates all that existing value.

That’s not argument to never do anything new, but it’s an argument why for your UNIX-like OS should ship the standard boring thing instead of the shiny new thing in the base install.

Re: Rewriting essential Linux packages in Rust

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

You say that like big tech doesn't use these tools when they are gpl. The primary advantage here is big tech employees can safely read and contribute to these tools without fear of upsetting some internal lawyers or getting explicit permission. No one is arbitrarily forking, extending, and keeping that new source hidden despite placing it in some commercial product. Working upstream is far less costly for long term maintenance and everyone knows that. Sure there are exceptions but far from the common case

Re: Rewriting essential Linux packages in Rust

#65

> " There are between 200 and 300 dependencies in the uutils project. He said that he understood there is always a supply-chain-attack risk, "but that's a risk we are willing to take". There is more and more tooling around to help mitigate the risk, he said. left-pad II, coming soon to a Linux distro near you

> There is more and more tooling around to help mitigate the risk, he said.

Could anyone expand on this? I could imagine tools... better static analysis, maybe? being able to help. But I'd really want to see details. Both to see if it really helps, and because if there is tooling to help then I want to know so I can adopt it!

Re: Rewriting essential Linux packages in Rust

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

+1 also, it is much less interesting if this is not sent upstream (even if upstream is not interested at this point)

Re: Rewriting essential Linux packages in Rust

#67
post #52
post #48

Earlier quoted context omitted.

It would depend on what the end goal of the rewritten project is. If they pursue widespread adoption GPL licenses can definitely hinder it in many cases.

AGPL? I can understand. Pure GPL 2 or even GPL 3? Never heard of that.

You've never heard that GPL can hinder adoption? Most codebases simply cannot use GPL code because if they do, they'd be forced to relicense under GPL (obviously). Not everyone wants to do that, even setting companies aside.

Even people who nominally agree with the concept of Free Software might not want to be forced to use GPL. The freedom to choose how to license one's work is also an important freedom, after all. GPL can be confusing, so you can't fault anyone from not wanting to use it even if they agree with the spirit of the license.

(For the record, I use GPL on some of my projects. I don't hate it, but I also like to use MIT on some projects, too.)

Re: Rewriting essential Linux packages in Rust

#68
post #47
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.

Thanks for sharing this thought, it hadn't occured to me that this could be an issue. Would the choice of AGPL or MPL for a licence have satisfied your concerns?

While I don't share OP's concern, I believe AGPL is much more preferable, yes.

Re: Rewriting essential Linux packages in Rust

#69

Earlier quoted context omitted.

> Is Rust (llvm?) supported on all platforms Linux targets? AFAIK, no. Linux chooses to support platforms from which we haven't seen new releases in decades, like DEC Alpha. Although in recent years, Linux has dumped support for many older platforms including IA-64. But my guess is GNU coreutils also doesn't support all Linux targets. I mean this in two ways -- 1) AFAIK coreutils does not expressly support each and e…

I can't find an official list of supported targets, but https://github.com/coreutils/coreutils/blob/master/README-in... contains notes on compiling for IRIX, HPUX, AIX, and OSF/1 . So no, I would bet that it very much does run anywhere Linux runs, and a lot of places it doesn't.

> contains notes on compiling for IRIX, HPUX, AIX, and OSF/1.

Again, how well tested do you imagine the OSF/1 target is? Do you imagine each merge pops off a CI test for that platform? My guess is -- it's been a long time since anyone connected with the GNU coreutils project built for that platform.

See the reply from estebank to me, below:

> Platform support goes beyond "does a compiler happen to produce a binary".

Re: Rewriting essential Linux packages in Rust

#70

Earlier quoted context omitted.

Perhaps, but MIT licensed code is Free like Air and Sunshine.

...and can be closed anytime, if the author wants to. Which will happen with these tools, anyway.

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.
Post reply on HN