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

81–90 of 175 posts

Re: Rewriting essential Linux packages in Rust

#81

Post by surajrmal »

silon42 wrote: post #71
brian-armstrong wrote: post #17

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

... when rewriting Linux system software, I'd only use Rust dependencies from a distro (probably something LTS, like Debian stable, or such).

Given how simple it is to use cargo, and avoiding the per distro dependency problem being one of the reasons people like rust, what are the chances people actually bother doing that? Especially given most dependencies are statically linked

Re: Rewriting essential Linux packages in Rust

#82

Post by WhereIsTheTruth »

This article is funny

> "I'm going to state the obvious, that Rust is very good for security, for parallelism, for performance".

> The idea to replace GNU coreutils with Rust versions was not about security, though, because the GNU versions were already quite secure. "They did an amazing job. They almost don't have any security issues in their code base." And it's not about the licensing, he said. "I'm not interested in that debate."

> One of the reasons that Ledru liked Rust for this project, he said, is that it's very portable. He is "almost certain" that code he writes in Rust is going to work well on everything from Android to Windows.

> Ledru cited laziness as another reason for using Rust. "So if there is a crate or library doing that work, I'm going to use it. I'm not going to implement it [myself]." 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.

People who keep promote this fraud are fraudsters too

Re: Rewriting essential Linux packages in Rust

#83

Post by bayindirh »

switchbak wrote: post #76
bayindirh wrote: post #58

Earlier quoted context omitted.

As a person who shares OPs concerns, (A)GPL is acceptable, in v2 or v3 form. Anything permissive is not, because allows a closed fork, which everybody wants to do to rob free software ecosystem to undo what has been done over these years. Because "monies".

Personally I haven’t seen this motive across any of the organizations I’ve worked at. They usually seem more interested in minimizing maintenance costs, which means they try to upstream changes where possible or practical. What would motivate a company to fork and keep private changes to a core GNU utility like chmod?

Any hardware company which would want to block 3rd party firmware from loading or executing on their systems. They can add a small handshake code to every binary on that system to authenticate via TPM or the processor's embedded secure element on start.

They don't need to make extensive changes. Pull the latest, patch, compile, burn to FW. TaDa!

IOW, TiVoization 2.0. GPL2 makes it very hard already, but GPL3 makes it impossible.

With permissive licenses, it's very possible.

ref: https://en.wikipedia.org/wiki/Tivoization

Re: Rewriting essential Linux packages in Rust

#84

Post by estebank »

grandempire wrote: post #63
shmerl wrote: post #61

Earlier quoted context omitted.

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

Having ripgrep installed by default doesn't preclude grep also being installed.

Re: Rewriting essential Linux packages in Rust

#86

Post by mubou »

evanwpm wrote: post #30
janice1999 wrote: post #8

Earlier quoted context omitted.

fd is also great and I install it everywhere. https://github.com/sharkdp/fd

I also really like: https://github.com/eza-community/eza (modern ls replacement) https://github.com/BurntSushi/erd (modern tree replacement) https://github.com/sharkdp/bat (modern cat(1) replacement) my .zshrc for every system now uses these as drop in replacements

Wrong erd! https://github.com/solidiquis/erdtree

This looks really cool, though. I might try using this as an `ls` replacement, too, just because of how it shows the recursive directory size like `du`. I've always wished windows explorer did that (do any linux gui file managers?)

Re: Rewriting essential Linux packages in Rust

#87

Post by yjftsjthsd-h »

mustache_kimono wrote: post #69
yjftsjthsd-h wrote: post #57

Earlier quoted context omitted.

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

Fair. I suppose it comes down to what "supported" means. AFAICT there's no official CI testing for any platform; the closest thing seems to be a mailing list where people will sometimes test new releases. It would be interesting to see what would happen if someone found and reported a bug for something obscure.

Re: Rewriting essential Linux packages in Rust

#88

Post by nine_k »

mubou wrote: post #67
nine_k wrote: post #52

Earlier quoted context omitted.

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

Libraries are normally released under LGPL, which allows the use inside your differently licensed code.

A ton of commercial services and products somehow use Linux, the poster child of GPL2, while also running tons of their proprietary code. Python is GPL, and it's all over the place in the computing world.

If you just want to take some code someone else wrote, for free, and alter and meld it into your commercial product, well, yes, GPL does not allow that. I don't think it's a huge impediment for legitimate use.

I'd say that all open-source approaches have their own use cases. Certain things are easier to release under BSD / MIT license, some makes sense to release under GPL, some have to resort to AGPL, to the detriment of commercial adoption. A dual restrictive open-source + paid commercial license can be the best in many cases.

Re: Rewriting essential Linux packages in Rust

#89

Post by yellowbat »

mubou wrote: post #67
nine_k wrote: post #52

Earlier quoted context omitted.

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

[dead]

Re: Rewriting essential Linux packages in Rust

#90

Post by surajrmal »

blueflow wrote: post #72
surajrmal wrote: post #64

Earlier quoted context omitted.

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

> The primary advantage here is big tech employees can safely [...] contribute to these tools without fear of upsetting some internal lawyers Doesn't GPL do that better by mandating that changes must be accessible to the public? Like, if an employee worked out some patch, it would be a violation of the license to not make it accessible to the public.

No, because the fear of possibly not complying is enough to stop folks from even getting near it. I would argue that's worse for the ecosystem.
Post reply on HN