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

101–110 of 175 posts

Re: Rewriting essential Linux packages in Rust

#101

Post by preisschild »

ajross wrote: post #51
preisschild wrote: post #32

Earlier quoted context omitted.

Just using dependencies isn't bad IMO. Your code might be of much higher quality when you use libraries that are used by many other packages instead of coding your own stuff that is only used by your package and thus less reviewed / less improved upon.

That is much less true than you think. It's undeniably true for "complicated" stuff. If you as an app developer roll your own DEFLATE implementation vs. using zlib, you're being an idiot, etc... But the lines around those utilities have long since been drawn already, and traditional open source projects have already organized themselves around this. We don't need crates.io to put libz.so into a separate package, it's…

> And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it.

Does that really matter? The compiler only includes the stuff you actually use anyways.

Re: Rewriting essential Linux packages in Rust

#102

Post by alwayslikethis »

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.

I would have said this in the past, but at this point I don't think it matters that much anymore.

1. Code copyright has devalued a lot in general, as you can code significantly faster with LLMs and use them to launder GPL'd code into whatever you want.

2. Big tech seems to be getting away with most other forms of abuses these days, GPL wouldn't really stop them from doing anything important.

To the extent that code is being devalued, I would say that these LLMs are a benefit to open source overall, as devaluing of code also reduces the opportunity cost of open sourcing software. They also somewhat level the playing field between single-contributor open source projects and companies with teams of developers, because an individual is almost always limited by the rate at which he/she can write or architecture code, whereas teams have significant non-code overheads (meetings, reviews, bureaucracy).

Re: Rewriting essential Linux packages in Rust

#103

Post by ajross »

preisschild wrote: post #101
ajross wrote: post #51

Earlier quoted context omitted.

That is much less true than you think. It's undeniably true for "complicated" stuff. If you as an app developer roll your own DEFLATE implementation vs. using zlib, you're being an idiot, etc... But the lines around those utilities have long since been drawn already, and traditional open source projects have already organized themselves around this. We don't need crates.io to put libz.so into a separate package, it's…

> And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it. Does that really matter? The compiler only includes the stuff you actually use anyways.

> The compiler only includes the stuff you actually use anyways.

Goodness, no. The compiler can elide unreferenced symbols, that's not at all the same thing as "stuff you actually use". Just build a static glibc binary someday around "int main(void) { return 0; }" for a reference as to just how much stuff can get sucked in even if you think you aren't using it.

In fact "unexpectedly included feature" was part of the xz-utils attack last year! The backdoor leveraged the fact that the openssh daemon linked against libsystemd for authentication, which links against liblzma (for some reason, I don't know why), despite xz not being required for anything in the ssh protocol. Boom.

And in that case, the two dependencies (systemd and xz-utils) were inarguably in the "complicated" category that apps can't be expected to reimplment. Think how much more complicated this gets if every bit of junk logic becomes a "dependency".

People need to be thinking about this as a problem!

Re: Rewriting essential Linux packages in Rust

#104

Post by surajrmal »

bayindirh wrote: post #95
surajrmal wrote: post #74

Earlier quoted context omitted.

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?

I don't mind GPL, but if I were to start a new project it would be MIT licensed. There is no hidden agenda in my decision to do that and it's certainly not some grand scheme by my employer to make me do that. I simply find gpl less free because it has obligations attached to it. I don't think I'm alone in feeling this way. In fact I think this may very well be the way the majority of folks feel at this point.

Re: Rewriting essential Linux packages in Rust

#105

Post by jillesvangurp »

jeroenhd wrote: post #59
jmclnx wrote: post #40

Seems this project is MIT-licensed. That is fine, but I cannot help this is a way to get Corporations from following the GPL. I wonder if Linux is re-written i rust will it too remove GPL as a factor ? Again due to the license choice I tend to believe this can be seen as a way to move Linux to a Microsoft Type Windows System.

There's no specific reason for Rust code not to be GPL licensed. For whatever reason, many Rust devs choose not to use copyleft licences in their projects, but that doesn't preclude GPL projects from using Rust. I would've preferred projects like these to be GPL licensed too, but as the author writes in the comments ( https://lwn.net/Articles/1009647/ ): what's the real-world impact of this specific project being MIT…

There's no good reason for people to use GPL either. People project all sort of idealistic stuff on this license but the reality is that healthy projects with a diverse contributor based are not at any real risk of their code being hijacked.

There are plenty of permissively licensed projects that have been around for decades. Copyleft licenses don't provide much additional protection. They impose a requirement on people that modify the software to provide those modifications under the same license. That's about it. Imposing that requirement is important to some people but not really that essential for the long term health of open source projects.

If you want to create a fork of OpenBSD kernel and call it DrEvilBSD and release it under the 100% proprietary DrEvil License 1.0, you can do that of course. The license allows you to do that. You are required to preserve the license and copyright notice, of course. For copyleft proponents, this is a wrong that needs to be corrected and they'll use big words like theft and stealing. For permissive software people this is a feature, not a bug. Do whatever you want with the software. These are both valid points of view to hold.

In practice, long lived OSS projects get more protection from the fact that they have a large amount of copyright holders (everybody that ever contributed to the code) which makes any form of re-licensing impractical. The Linux kernel will never re-license. Nor will the OpenBSD kernel. It would take the permission of many thousands/tens of thousands of developers; or their surviving relatives (quite a few are no longer alive). Not going to happen.

Anyway, the MIT license is a perfectly good license. It's widely used, well understood, easy to understand, etc. It has been around for decades. Countless of OSS projects use it. Perfectly fine choice if your goal is to facilitate others to use your software in whatever way works for them. Whether that's bundling into some proprietary firmware or distributing it in some OSS linux distribution. Giving users of the software that freedom is a fine choice.

And kind of important for operating systems. Unless your goal is to keep it out of the hands of companies that sell products to customers based on these operating systems. Which might be why there aren't many AGPL or GPLv3 licensed operating systems.

For a project like this coreutils rewrite, the MIT license makes sense. It maximizes usability across diverse systems Linux, BSD, proprietary UNIX, Windows, etc. without imposing restrictions. That’s likely an intentional choice to ensure broad adoption. There's no good reason to restrict that. Probably the developers want to see this go wherever it can go.

Re: Rewriting essential Linux packages in Rust

#106

Post by grandempire »

burntsushi wrote: post #100
grandempire wrote: post #42

Earlier quoted context omitted.

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

> I'm just tired of people hiding behind POSIX compliance.

grep exists in base primarily to support shell scripting, as well as the benefits of standardization that I mentioned. That’s not hiding - it’s a basic expectation if you want scripts to run.

Why should ripgrep be on base and what kind of overhead are we adding to install?

> how many of your invocations of grep are not POSIX compliant.

It would be a different argument if ripgrep was compliant with extensions, like gnugrep, but being a completely separate tool with a similar name, it doesn’t fill the same role.

I like it and install it when I need it.

Re: Rewriting essential Linux packages in Rust

#107

Post by grandempire »

estebank wrote: post #84
grandempire wrote: post #63

Earlier quoted context omitted.

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.

Indeed. So why it should it come by default?

Re: Rewriting essential Linux packages in Rust

#108

Post by grandempire »

shmerl wrote: post #91
grandempire wrote: post #63

Earlier quoted context omitted.

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.

It doesn’t matter if it’s over or underrated - what matters is if you want to be compatible with existing code and documentation.

I wish C didn’t have strtok, but it’s too late.

Re: Rewriting essential Linux packages in Rust

#109

Post by preisschild »

ajross wrote: post #103
preisschild wrote: post #101

Earlier quoted context omitted.

> And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it. Does that really matter? The compiler only includes the stuff you actually use anyways.

> The compiler only includes the stuff you actually use anyways. Goodness, no. The compiler can elide unreferenced symbols, that's not at all the same thing as "stuff you actually use". Just build a static glibc binary someday around "int main(void) { return 0; }" for a reference as to just how much stuff can get sucked in even if you think you aren't using it. In fact "unexpectedly included feature" was part of the…

Thanks. Definitely have to read more into this.

Re: Rewriting essential Linux packages in Rust

#110

Post by burntsushi »

grandempire wrote: post #106
burntsushi wrote: post #100

Earlier quoted context omitted.

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

> I'm just tired of people hiding behind POSIX compliance. grep exists in base primarily to support shell scripting, as well as the benefits of standardization that I mentioned. That’s not hiding - it’s a basic expectation if you want scripts to run. Why should ripgrep be on base and what kind of overhead are we adding to install? > how many of your invocations of grep are not POSIX compliant. It would be a different…

I think my comment already addressed every single piece of what you said here. And you're shifting your original claim! You are no longer hiding behind POSIX compliance here. Instead, you're making a more nuanced argument based on more than just POSIX compliance, and one that I find very reasonable! But that's not what you originally said.
Post reply on HN