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

161–170 of 175 posts

Re: Rewriting essential Linux packages in Rust

#161

Post by grg0 »

Gud wrote: post #141
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’s the problem with FreeBSD? It’s been my daily driver for 20 years. That it has an open license is a good thing.

That it's irrelevant outside of the server space and has terrible hardware support. FreeBSD folks themselves use Macs.

Don't get me wrong, I very much like FreeBSD, but I believe a liberal licence on critical infrastructure like an OS is detrimental. Of course, FreeBSD folks will argue the opposite.

Re: Rewriting essential Linux packages in Rust

#162

Post by kazinator »

pabs3 wrote: post #157
kazinator wrote: post #149

Earlier quoted context omitted.

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.

That is definitely not what the word prepare means in that sentence. Its more like the meaning in the phrase "prepare a meal".

I'm guesssing that likely intent is so that the authorities could raid a large scale copyright infringment operation, and obtain convictions based on evidence of perparation alone. I.e. not have to catch anyone red-handed redistributing the prepared materials.

Kind of like how cops in some places in America can evidently arrest someone for DUI if that person merely walks to their car with their car keys, intending to sleep inside until sober.

Re: Rewriting essential Linux packages in Rust

#163

Post by mustache_kimono »

grg0 wrote: post #160
mustache_kimono wrote: post #154

Earlier quoted context omitted.

> Isn't it likely that newer projects licensing under GPL are also unlikely to be using GitHub and instead be using a platform like GitLab or Forgejo (or previously Gitea or something)? Why? But let's assume you're correct. What better metric do we have about which license OSS projects are using?

Because the kind of people who use the GPL do not entirely appreciate Microsoft profiting from all code hosted on Github without respecting the original licence. And before you reply; yes, there is litigation ongoing on that front. And who cares about those ad-hoc metrics? GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL. That alone is a good metric. Blender an…

> GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL.

I don't disagree, but you're missing the point which is -- the reason why the GPL is not popular is not only because corporations disfavor it, it's because devs disfavor it too. You might ask yourself, "Why?"

> Blender and OBS are also heavy hitters.

And so is Firefox which is MPL2, etc. If your point is -- OSS can't be successful (or successful and copyleft) without the GPL, then you're obviously wrong.

> It is easy to take these things for granted, and anyone seeking to rewrite GPL software under a liberal licence (whether it is in Rust is irrelevant) would benefit from reading a little history.

Is this meant to be maximally patronizing? I am old enough and I was there. It is also fair to see the world differently than you do, and to appreciate different things (as others do and will do.) Some may say, "More than 25 years have passed since the Halloween documents and I am no longer on a jihad."

What I am saying is not that the GPL is not good, only that the GPL isn't the highest good, and more important than the GPL (or the MIT license for that matter) is my freedom to reimplement any software in whatever language and under whatever license I choose.

Re: Rewriting essential Linux packages in Rust

#164

Post by yjftsjthsd-h »

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

Earlier quoted context omitted.

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.

It also works for creating directories, ex.

  install -d -m 755 somedir
And yeah, I'm pretty sure the owner/group thing is just noting that at least on GNU/Linux that's just how the OS works (I think that varies among unix-likes).

Re: Rewriting essential Linux packages in Rust

#165

Post by Tomte »

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…

> Permissive licenses sometimes allow sublicensing, which allows changing of the license

No! Sublicensing simply means that there can be a chain of licensing, e.g. author —— Linux distribution —— end user. Not that the middleman can change the license.

(It's actually irrelevant in Germany, because consensus in our legal community seems to be that there is a direct licensing relationship between author and end user, even if they don't know each other and never interact)

Re: Rewriting essential Linux packages in Rust

#166

Post by kazinator »

wakawaka28 wrote: post #158
kazinator wrote: post #115

Earlier quoted context omitted.

The GPL does not prevent closed versions because of Tivoization, and SaaS. For instance, Facebook is closed, in spite of running on a mountain of GPLed stuff. A locked device may prevent the user from running a kernel image that is not signed with a certain private key, even though the vendor of the device complies with the GPL and provides the matching kernel sources and the correct toolchain to reproduce the build…

>The GPL does not prevent closed versions because of Tivoization, and SaaS. This is exactly what AGPL is for. Of course, AGPL is too overbearing for most projects, and only makes sense for SaaS. >A locked device may prevent the user from running a kernel image that is not signed with a certain private key, even though the vendor of the device complies with the GPL and provides the matching kernel sources and the corr…

The AGPL does squat all for the social problems causes by SaaSS, and only succeeds in being a technically non-free license.

Nobody cares if you take some open source server software, and run version that you modified with your own cool features, without sharing the source code, and this is something you're entitled to under the FSF's Freedom Zero.

Among the social harms of SaaSS, this is not on the radar; and obsession with it shows either that the FSF are out of touch, or that they think that any action is better than inaction, so that if they take a swing at the problem with the wrong tool (copyright licensing) they look like they gave it a good college try.

The problem of SaaSS is people being locked to a service because that's where their data is siloed. This harm can be perpetrated with completely unmodified software you can download yourself. Running your own copy does nothing to solve the problem; your copy is not where the data is, where the other users are.

Re: Rewriting essential Linux packages in Rust

#167

Post by grg0 »

mustache_kimono wrote: post #163
grg0 wrote: post #160

Earlier quoted context omitted.

Because the kind of people who use the GPL do not entirely appreciate Microsoft profiting from all code hosted on Github without respecting the original licence. And before you reply; yes, there is litigation ongoing on that front. And who cares about those ad-hoc metrics? GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL. That alone is a good metric. Blender an…

> GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL. I don't disagree, but you're missing the point which is -- the reason why the GPL is not popular is not only because corporations disfavor it, it's because devs disfavor it too. You might ask yourself, "Why?" > Blender and OBS are also heavy hitters. And so is Firefox which is MPL2, etc. If your point is -- OS…

Your points are valid and the comparisons between liberal and copyleft licenses have been discussed a million times. But scroll up to the original context here: what's the advantage of rewriting large swathes of critical OS infra that already works fine?

Re: Rewriting essential Linux packages in Rust

#168

Post by M95D »

mrighele wrote: post #70
bayindirh wrote: post #60

Earlier quoted context omitted.

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

> that will affect only future developments.

There's a term for that: Embrace-Extend-Extinguish

Re: Rewriting essential Linux packages in Rust

#169

Post by sylvestre »

grg0 wrote: post #120
timewizard wrote: post #31

> "I'm going to state the obvious, that Rust is very good for security, for parallelism, for performance". That's not obvious. > He is "almost certain" that code he writes in Rust is going to work well on everything from Android to Windows. I'd think the problem with security in code is cocky developers who believe that some part of the environment is magical and can save them from themselves. > Ledru cited laziness…

This Ledru comes across as a total noob indeed. > He is thinking about "what we are going to leave to the next generation". A history lesson in software licensing, maybe? Certainly not one he bothered to learn himself, lol.

+1 ;)

Re: Rewriting essential Linux packages in Rust

#170

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

Okay, so I was curious enough to check... I can install NetBSD on an emulated VAX (opensimh), run

  pkgin install coreutils
and those binaries do in fact work. I can't seem to find documentation of whether they run tests on every build, but I'm going to tentatively take that as a strong signal that GNU coreutils is still portable across more machines than even Linux can run on.
Post reply on HN