Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supporting Linux kernel development in Rust

lwn.net

Post reply on HN
Print view View original

251–260 of 365 posts

Re: Supporting Linux kernel development in Rust

#251

Post by fooker »

dnautics wrote: post #139
jasonhansel wrote: post #137

I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

Can you give an example of a non-copyleft open source product where the major improvement is proprietary?

ZFS was proprietary for several years.

Re: Supporting Linux kernel development in Rust

#252

Post by _ph_ »

pjmlp wrote: post #242
_ph_ wrote: post #240

Earlier quoted context omitted.

But if they have IP considerations or trade secrets to protect, they wouldn't contribute them to any other open source project either. This way, they can at least upstream everything, which doesn't fall under these restrictions.

They don't upstream everything, while reducing their development costs, that is the point. Personally I don't care, but I bet many FOSS anti-GPL advocates will eventually care.

They don't upstream what they never would be up streamed. But they probably they upstream a lot which they wouldn't have, if they couldn't use the open source tool at all. Also, a lot of companies reduce their development costs by using open source software, gpl or other, without ever upstreaming. So "saving development cost" doesn't sound like an argument to me.

Re: Supporting Linux kernel development in Rust

#253

Post by rfoo »

cutemonster wrote: post #223
frutiger wrote: post #218

Earlier quoted context omitted.

> One common strategy, used by Linux itself, is to maintain a high level of internal API churn coupled with genuinely good improvements in that churn Interesting angle that I had never thought of as deliberate. As someone who works on a (bespoke) integration/embedding of Chromium, I could say exactly the same thing about it too.

Meaning, internal things in chromium change so fast, so you'd slightly wish you could have your custom changes merged into upstream? (I.e into chromium) So that the ppl at Google would keep your code working? And you didn't need to spend time resolving git merge conflicts, and compilation errors? But you cannot, because some of those bespoke changes are "secret" and what you make money from? (And maybe some changes a…

Yes.

Also, the fact that Chromium is a high profile security critical software with occasional emergency security updates for bugs exploited in the wild, doesn't help at all when you want to maintain your own fork.

Re: Supporting Linux kernel development in Rust

#254

Post by thomasdullien »

JoshTriplett wrote: post #29
puzzledobserver wrote: post #9

One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls. Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the b…

The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition. There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about. Standing reminder: the Rust project is no…

Man, thank you for writing the last paragraph. I looked at Rust, I quite like the language, I think it gets a million things right and is a substantial improvement over existing languages, but ... every time I point out that Rust does not magically solve all security problems, I need to spend two days dealing with people with less security expertise than me yelling at me that I am wrong and rewriting the world in Rust will deliver enlightenment. That particular fringe of the Rust community almost turned me away from the language.

So reading your last paragraph makes me feel welcome as someone that says "Rust is great - but rewriting everything in Rust will not solve security". Thanks. <3

Re: Supporting Linux kernel development in Rust

#255

Post by nix23 »

jasonhansel wrote: post #137

I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

GCC changed from GPLv2 to GPLv3 which is a stupid license for a compiler (Thanks FSF). I'm happy that LLVM exists, happy that Microsoft, Apple, Linux, and BSD's can use it without that GPLv3 BS.

Re: Supporting Linux kernel development in Rust

#256

Post by nix23 »

zelly wrote: post #224
fractalb wrote: post #203

Earlier quoted context omitted.

What if those bigcorps don't merge some improvements for getting an edge over the competitors? And, what if every one of those bigcorps do the same? How would that impact the project in the future?

Already the case for Apple LLVM which has optimizations for Apple Silicon not upstreamed and never will be upstreamed.

I don't believe you.

https://reviews.llvm.org/D70779

Re: Supporting Linux kernel development in Rust

#257

Post by pjmlp »

roca wrote: post #250
pjmlp wrote: post #220

Earlier quoted context omitted.

Some of us are in the managed language world now, the problem is that C++ still has the best integration story with Java and .NET codebases, which Rust still needs to catch up to. So modern C++ will have to do for the few cases that require going out of them, e.g. runtime plugins for native agents, COM/UWP with access to OS APIs, IDE mixed language debugging, GUI components. Also there is the whole issue that GPGPU s…

You seem to be assuming that everyone uses Java or .NET and C++. That seems wrong to me.

No, that is where I am coming from.

I can give examples with other managed languages that are more at home with C++ infrastructure for the time being, like JavaScript, Swift, Julia.

Re: Supporting Linux kernel development in Rust

#258

Post by nix23 »

joshuamorton wrote: post #154
jasonhansel wrote: post #146

Earlier quoted context omitted.

Most of the thriving non-GPL OSS projects are supported and funded by large corporate sponsors--not by communities or foundations (e.g. React.js by Facebook, Blink by Chrome). Furthermore, many non-GPL OSS projects have eventually gone proprietary (e.g. MongoDB's switch from AGPL to SSPL).

The gpl projects are also corporately sponsored, just indirectly.

I would not call that "indirectly":

https://www.linuxfoundation.org/membership/members/

and that:

https://www.linuxfoundation.org/blog/2016/08/the-top-10-deve...

Re: Supporting Linux kernel development in Rust

#259

Post by pjmlp »

_ph_ wrote: post #252
pjmlp wrote: post #242

Earlier quoted context omitted.

They don't upstream everything, while reducing their development costs, that is the point. Personally I don't care, but I bet many FOSS anti-GPL advocates will eventually care.

They don't upstream what they never would be up streamed. But they probably they upstream a lot which they wouldn't have, if they couldn't use the open source tool at all. Also, a lot of companies reduce their development costs by using open source software, gpl or other, without ever upstreaming. So "saving development cost" doesn't sound like an argument to me.

With GPL there is a legal tool to force contribution, though.

As mentioned I don't care, after university my main UNIX platforms were HP-UX, Aix and Solaris with their respective system compilers anyway.

Linux is already getting replacement candidates in IoT space via Zephyr, NuttX, mbed, RTOS, Azure RTOS, and who knows if Fuchsia will eventually get out of the lab, so be it.

Re: Supporting Linux kernel development in Rust

#260

Post by brobdingnagians »

jasonhansel wrote: post #146
axaxs wrote: post #143

Earlier quoted context omitted.

I don't see how, personally. There are tons of thriving open source non-copyleft projects. And there are tons of GPL violators who go on business as usual. I think perhaps copyleft licenses are overattributed to the success of such projects.

Most of the thriving non-GPL OSS projects are supported and funded by large corporate sponsors--not by communities or foundations (e.g. React.js by Facebook, Blink by Chrome). Furthermore, many non-GPL OSS projects have eventually gone proprietary (e.g. MongoDB's switch from AGPL to SSPL).

But the direction of Linux as a GPL project is largely controlled by corporations e.g. Redhat now a.k.a. IBM, Intel, etc. GPL is not a cure all, it is a tool. Some licenses are better for some purposes. Use the right tool for the right job. It is nice that we have compilers (and OSes) under both licenses, it shows both strengths and weaknesses of each type of license. There are strengths, and weaknesses, to both models, and to other models, such as Intel's optimizing compiler.
Post reply on HN