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

161–170 of 365 posts

Re: Supporting Linux kernel development in Rust

#161

Post by lacker »

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

I think this gets the cause and effect backwards. No corporate lawyer prefers the GPL, so when companies start new open source projects, they don’t pick the GPL. Once a project has been started, GPLing it doesn’t really make it any easier to get it non-corporate support.

Re: Supporting Linux kernel development in Rust

#162

Post by woodruffw »

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.

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

As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are massive and complicated beasts, and the "moat" for proprietary improvements is small: they're either niche and therefore not of interest to the majority of programmers, or they're sufficiently general and easiest to maintain by releasing back upstream (where Apple, Google, and Microsoft will pay a small army of compiler engineers to keep them working).

Your concern is the one that kept GCC from stabilizing its various intermediate representations for decades, which is why virtually all program analysis research happens in LLVM these days.

Edit: To elaborate on the above: neither Apple, nor Google, nor Microsoft wants to individually maintain LLVM. Microsoft appears (to this outsider) to be actively looking to replace (parts of) MSVC/cl with the LLVM ecosystem, because they're tired on maintaining their own optimizing compiler.

Re: Supporting Linux kernel development in Rust

#163

Post by dbaupp »

ghostwriter wrote: post #87
dbaupp wrote: post #76

Earlier quoted context omitted.

Popularity and momentum translate into (and are proxies for) important things like: library availability, long-term maintenance and support, more edge cases are explored (so less “research”, breaking new ground and bugs when going off the beaten track), tooling and even availability of teaching material like documentation and tutorials.

In case of ATS, any C library can be treated as a "unsafe-marked" ATS library, so there's no problem with library support, the problem is with their formal verification. And Rust libraries regularly suffer from the same lack of formally-verified and proven-to-be-safe APIs.

Ah, furthermore, looking at a comment below, it seems ATS's support for C libraries is almost identical to Rust's: specify a list of functions and their signatures on the ATS/Rust side. From your adoring descriptions, I had been assuming it simplified the process properly, by allowing importing a C header directly (like Swift can).

(The main difference seems to be ATS allows inline C, since it looks to be tied to C as a compilation target.)

Re: Supporting Linux kernel development in Rust

#164

Post by jahewson »

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

Are the thriving GPL’d projects not also sponsored by corporations - who fund the foundations and whose employees contribute the most code?

Re: Supporting Linux kernel development in Rust

#165

Post by jahewson »

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.

I think GCC’s resistance to modularisation and the resulting rise of LLVM has proven beyond doubt that the greater risk is that by putting up barriers to corporate contribution there will not be any major improvements in first place.

Re: Supporting Linux kernel development in Rust

#166

Post by pvg »

ghostwriter wrote: post #159
pvg wrote: post #147

Earlier quoted context omitted.

You know the sort of person who comments 'Just install Linux' in every thread about more or less any kind of computer problem? You don't want to be that sort of person. If you're starting your comments with 'I'm not going to stop telling you to install Linux', it's probably a good time to check if you're not turning into the sort of person who's always telling you to install Linux.

If I ommited that first part of the sentence the points made afterwards would remain the same. I did so to indicate that it's not the first time the Rust community suggests that something should be (re-)written in Rust for memory-safety reasons, in a project that has a well-established C-codebase. I'd argue it's the same "Just install Linux" situation that you mention, and that "Linux" may not be the answer.

it's not the first time the Rust community suggests that something should be (re-)written in Rust

The article is not about that, though, it's specifically about the various issues surrounding the use of Rust for Linux kernel development.

Re: Supporting Linux kernel development in Rust

#167

Post by sroussey »

woodruffw wrote: post #162
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.

> 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. As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are massive and complicated beas…

But Intel put proprietary work in ICC and their math libs, so there is something on periphery that’s going to keep the worry alive even if it doesn’t have a base.

Re: Supporting Linux kernel development in Rust

#168

Post by kabacha »

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

> Furthermore, many non-GPL OSS projects have eventually gone proprietary

Every time it happens people are upset and then forget everything a day later. To me non-GPL + corporate involved is a huge flag, especially if it's a more complex or niche project that'd be difficult to fork.

Re: Supporting Linux kernel development in Rust

#169

Post by sisu »

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?

Wine used to have some proprietary forks such as Cedega before they switched from MIT to LGPL.

Re: Supporting Linux kernel development in Rust

#170

Post by ghostwriter »

geofft wrote: post #160
ghostwriter wrote: post #122

Earlier quoted context omitted.

I meant not having to think about wrapping/boxing/unboxing, as they have exactly the same native data representation, so it's slightly different than LTO. But mine using "FFI" there was probably too vague and frivolous, I agree. > You can do this in Rust, too. not always within boundaries of safe Rust though (assuming each iteration is allowed to brings zero unsafe/unverified code), which undermines the initial safet…

> wrapping/boxing/unboxing, as they have exactly the same native data representation Rust's Box and Option > have the same representation as a C pointer to the same type, so this is true of Rust too. You do have to wrap the type in source code to indicate what the ownership guarantees/contracts are. (Is this not also true of ATS? That is, if ATS code calls a C function that returns a pointer, how do you know how long…

> No, adding unsafe Rust does not undermine the safety argument

But it does, see my answer in the thread below regarding ring buffers - https://news.ycombinator.com/item?id=24337184

> Is this not also true of ATS? That is, if ATS code calls a C function that returns a pointer, how do you know how long that pointer is valid for and whether you're expected to free it?

the C implementation needs to be known, then the signature (interface) of the extern-annotated C function would define a pointer that will be associated with a proof object. Every ATS program that compiles must consume all instantiated proofs (with a proper proof-consuming function), and the proof itself can indicate whether a pointer is stored/taken care of inside the C function or it should be taken care of outside the function (the latter is indicated by a prefixed "!" to the pointer type). An example could be found here - https://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-mem...

Post reply on HN