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

91–100 of 175 posts

Re: Rewriting essential Linux packages in Rust

#91

Post by shmerl »

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…

I'd say POSIX is sometimes overrated.

Example: https://github.com/mpv-player/mpv/commit/1e70e82baa91

Anyway, I don't see any of that as a reason for not having ripgrep installed everywhere by default and as an argument for not using it.

Re: Rewriting essential Linux packages in Rust

#92

Post by trelane »

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?

> What would motivate a company to fork and keep private changes to a core GNU utility like chmod?

Maybe ask these folks: https://www.busybox.net/license.html

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

Re: Rewriting essential Linux packages in Rust

#93

Post by krater23 »

yjftsjthsd-h wrote: post #65
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

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

Static analysis is embedded in rust, but you can't mitigate intended malicious behavior of software dependencies. That would be like a virus killer for dependencies. The past has shown that this isn't working.

Re: Rewriting essential Linux packages in Rust

#94

Post by krater23 »

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

But Rust is so secure, what could ever happen? ;)

Re: Rewriting essential Linux packages in Rust

#95

Post by bayindirh »

surajrmal wrote: post #74
jmclnx wrote: post #41

Earlier quoted context omitted.

I did not see these posts before I posted similar. I fully believe this is a direction Corporations are pushing. Almost wonder when spyware will be added and restrictive DRM.

This is FUD. The folks funding this generally believe in the benefits. Not everything is 4D chess. There are plenty of not more of examples of rewrites where licenses do not change.

If that's no 4D chess, and if the license is not that important, why not relicense uutils to GPLv3 then?

Re: Rewriting essential Linux packages in Rust

#96

Post by krater23 »

greenheadedduck wrote: post #28

I wonder how linux devs feel about the rewrite in Rust. I mean surly loads of them have decades of experience in C, and Rust seems like such a different beast. Can any C developers provide insight, how is this transition?

There is no really transistion. Much developers just are ignoring Rust as they ignored D, E, Go, Ruby on Rails(the PHP developers) and some other fashion programming languages. It's a overhyped trend and in some years Rust will find his place beside all the other Languages, but will never be a widespread replacement of C/C++.

We tried it in a commercially project because some hyperiders in the team wanted to do so. The truth is, a thing that would be developed in C++ in 1.5 month wasn't done in 6 months caused by things like 'All our developers are newbies in the language, no one really can do meaningful reviews, tons of dependencies(often one dependency in different versions), no good way to integrate cargo in our existing build flow and the lack of fun during programming.'

When you don't start a complete new project with bloody newbies, Rust is not a good choice.

Re: Rewriting essential Linux packages in Rust

#97

Post by bayindirh »

bendhoefs wrote: post #80
grg0 wrote: post #35

Earlier quoted context omitted.

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 does Rust have to do with it? You can write MIT or GPL licensed code in any language.

It's not the language selection, but the license selection what bothers many.

Re: Rewriting essential Linux packages in Rust

#98

Post by krater23 »

WhereIsTheTruth wrote: post #82

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…

We just should ignore the evangelists that just reimplement something existing in rust again. Maybe this language will die or find his way in the corner where someone is doing soemthing useful with it.

Re: Rewriting essential Linux packages in Rust

#99

Post by preisschild »

estebank wrote: post #79
preisschild wrote: post #39

Earlier quoted context omitted.

Not yet, afaik the rust4linux devs thus want to create a rust frontend for GCC (gccrs)

gccrs (and gcc-codegen which is a project with the same objective but only implementing the backend) is an independent project to Rust4Linux (but they talk to each other).

Ah ok i thought they were the main contributers and users.

Re: Rewriting essential Linux packages in Rust

#100

Post by burntsushi »

grandempire wrote: post #42
shmerl wrote: post #3

Ripgrep should be included in all distros by default.

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

So? There are (likely) tons of tools that come installed by default in your distro that aren't POSIX compliant. Or aren't even mentioned by POSIX at all.

For example, on Archlinux, `base` (the minimal set of packages to install) includes `systemd`. `systemd` isn't POSIX.

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.

I'm just tired of people hiding behind POSIX compliance. One wonders how many of your invocations of grep are not POSIX compliant. (A strict POSIX grep is laughably minimal. To the point that not even minimal implementations of coreutils, like busybox, don't stick to the strict set prescribed by POSIX.) I'm not even aware of any grep implementation that doesn't implement something beyond what POSIX requires.

Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.

Post reply on HN