Supporting Linux kernel development in Rust • Hacker News Board

Re: Supporting Linux kernel development in Rust

#321

Post by ghostwriter » Tue, Sep 01, 2020, 2:59 PM UTC

geofft wrote: post #195

ghostwriter wrote: post #170

Earlier quoted context omitted.

> 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 si…

> ring buffers in Rust use "unsafe" and at some point there was a logical CVE in vec_deque that broke one invariant of the unsafe block First, you're talking about two different things here. Originally you were talking about incrementally adding Rust bindings to C code and how that obligated you to write "unsafe". Now you are talking about pure-Rust implementations of data structures that use "unsafe" for optimizatio…

> Then this is an axiom as input to the proof, not a proof itself. That is, ATS is no more capable than Rust of magically determining what the unstated invariants of C code are

I've never stated that there's such a capability. I was saying that unlike Rust, ATS can be used to gradually rewrite every C call into a safe and formally-verified equivalent function that has exactly the same performance and memory charactersitics as the original C function.

Re: Supporting Linux kernel development in Rust

#322

Post by fluffything » Tue, Sep 01, 2020, 3:00 PM UTC

pjmlp wrote: post #297

fluffything wrote: post #293

Earlier quoted context omitted.

Upstreaming non-GPL code is much easier for these companies to upstream GPL code, because a GPL upstream can "accidentally" leak all the IP of that company by requiring that company to publish all of its software. So the current options are: these companies don't open-source anything (which is what you get with GPL), or they open-source something (which is what you get with BSD, and in practice they open source a lot…

On the contrary, the claim is that without the GPL, commercial UNIXes would still be around. Since I am a commercial software user for most part, this is more of a philosophical question than anything else. Lets see how long Linux will hold out against the new generation of IoT OSes all being MIT/BSD based, and what the bazaar will get out of them. Or how long GCC will hold, when all major OSes use clang as their def…

> On the contrary, the claim is that without the GPL, commercial UNIXes would still be around.

I'm not sure this is true. See LLVM as an example. GCC existing and being GPL only meant that, e.g., Apple couldn't properly use it. Apple could have bought LLVM and kept it private, or develop their own proprietary solution and not make it open source, or fork the open source project into a private project and never contribute anything back, etc. There were many options.

Open source software has always existed, if anything, the GPL demonstrated that a particular open source model does not work well for a big part of the industry, while it works well for other parts, and non industrial usage.

Linux being successful seems incidental to it being GPL'ed, at least to me. Other open source OSes, like BSD 4.x, have also been quite successfull (powering the whole MacOS and iOS ecosystems, after a significant frankenstransform into Mach). Maybe Linux would have been even more succesfull with a BSD license, or maybe it would be dead.

Re: Supporting Linux kernel development in Rust

#323

Post by ghostwriter » Tue, Sep 01, 2020, 3:02 PM UTC

Ar-Curunir wrote: post #187

ghostwriter wrote: post #120

Earlier quoted context omitted.

> but I can’t imagine this being simpler than just rewriting the C in Rust. sometimes it's impossible without falling back to unsafe Rust, which kind of undermines the initial incentive. C codebases heavily utilise pointer arithmetic programming. Simplicity is a good trait though, and there are a few promising initiatives in that regard in ATS3 - https://github.com/githwxi/ATS-Xanadu#project-description

The point of Rust is not to eliminate unsafe, but to minimize it and make the actual unsafe operations visible and easily auditable.

ok, I'm fine with that, the question is why it is technically better for Linux Kernel than a proper formally-verified implementation that doesn't require Rust toolchain?

Re: Supporting Linux kernel development in Rust

#324

Post by Ar-Curunir » Tue, Sep 01, 2020, 3:08 PM UTC

ghostwriter wrote: post #323

Ar-Curunir wrote: post #187

Earlier quoted context omitted.

The point of Rust is not to eliminate unsafe, but to minimize it and make the actual unsafe operations visible and easily auditable.

ok, I'm fine with that, the question is why it is technically better for Linux Kernel than a proper formally-verified implementation that doesn't require Rust toolchain?

Because I can bet that it’s easier to write correct Rust than to write correct ATS.

Re: Supporting Linux kernel development in Rust

#325

Post by qalmakka » Tue, Sep 01, 2020, 3:59 PM UTC

de_watcher wrote: post #284

qalmakka wrote: post #228

Earlier quoted context omitted.

Developing a GCC frontend is a massive PITA, and the worst of all it was made purposefully so complicated because of RMS' concerns about closed compilers. He actually brought LLVM's existence onto himself, because it was somewhat clear no one would have bothered writing a new compiler if it had been possible to use it's frontend for other things (even from free software it's hard) and they kept the license as "GPLv2…

The fear of GPLv3 is just an excuse to pull things into proprietary. They became aware of the success of GPL and started to actively lobby against it with what they were able to come up with.

It doesn't matter.

Sometimes in order to achieve your goals you must compromise or risk loosing the footing you already have, because you have close to zero chances of succeeding.

If RMS had compromised on GCC in the '00s, i.e. if GNU had spun off the C/C++/ObjC front end as a separate GPLv2-or-later library upon which something like clangd could have been made, Clang would have never existed. Yes, LLVM would have still been present, but as a special-case backend that used GCC as its frontend instead than its own, as they were planning to do since the beginning. All these improvements you talk about would have been done under the GPL, and not BSD licenses or proprietary. IDEs like Xcode and such would still be proprietary like they are nowadays, because there was a 0% chance of getting Apple or whomever to release them under the GPL.

It doesn't matter how much strong your moral principles are, or how much you value integrity. The world is definitely more pragmatic about software and values different things than RMS; while this might or might not be beneficial to our overall society, that's the way it is. Ignoring it is myopic, if it does not outright amount to shooting yourself in the foot.

Re: Supporting Linux kernel development in Rust

#326

Post by nix23 » Tue, Sep 01, 2020, 4:00 PM UTC

pjmlp wrote: post #297

fluffything wrote: post #293

Earlier quoted context omitted.

Upstreaming non-GPL code is much easier for these companies to upstream GPL code, because a GPL upstream can "accidentally" leak all the IP of that company by requiring that company to publish all of its software. So the current options are: these companies don't open-source anything (which is what you get with GPL), or they open-source something (which is what you get with BSD, and in practice they open source a lot…

On the contrary, the claim is that without the GPL, commercial UNIXes would still be around. Since I am a commercial software user for most part, this is more of a philosophical question than anything else. Lets see how long Linux will hold out against the new generation of IoT OSes all being MIT/BSD based, and what the bazaar will get out of them. Or how long GCC will hold, when all major OSes use clang as their def…

>On the contrary, the claim is that without the GPL, commercial UNIXes would still be around.

BSD is Older than Linux:

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

Re: Supporting Linux kernel development in Rust

#327

Post by onetimertwo » Tue, Sep 01, 2020, 4:00 PM UTC

pjmlp wrote: post #297

fluffything wrote: post #293

Earlier quoted context omitted.

Upstreaming non-GPL code is much easier for these companies to upstream GPL code, because a GPL upstream can "accidentally" leak all the IP of that company by requiring that company to publish all of its software. So the current options are: these companies don't open-source anything (which is what you get with GPL), or they open-source something (which is what you get with BSD, and in practice they open source a lot…

On the contrary, the claim is that without the GPL, commercial UNIXes would still be around. Since I am a commercial software user for most part, this is more of a philosophical question than anything else. Lets see how long Linux will hold out against the new generation of IoT OSes all being MIT/BSD based, and what the bazaar will get out of them. Or how long GCC will hold, when all major OSes use clang as their def…

> the new generation of IoT OSes all being MIT/BSD based

RIOT OS is LGPLv2.1.

Re: Supporting Linux kernel development in Rust

#328

Post by pjmlp » Tue, Sep 01, 2020, 4:00 PM UTC

nix23 wrote: post #313

pjmlp wrote: post #306

Earlier quoted context omitted.

I did not said it was a cpu-drm feature, rather optimizations that could reveal hints about it. I don't know, maybe other AMD users would like to get them?

You wrote: >might provide clues how to bipass PS 4 security >AMD users would like to get them They got em: https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha... https://www.phoronix.com/scan.php?page=news_item&px=LLVM-10-... https://www.phoronix.com/scan.php?page=news_item&px=Sony-LLV... Why do i want ANY PS4 specific security feautures in the Compiler??

Why bother explaining to those that refuse to understand....

Re: Supporting Linux kernel development in Rust

#329

Post by pjmlp » Tue, Sep 01, 2020, 4:01 PM UTC

nix23 wrote: post #326

pjmlp wrote: post #297

Earlier quoted context omitted.

On the contrary, the claim is that without the GPL, commercial UNIXes would still be around. Since I am a commercial software user for most part, this is more of a philosophical question than anything else. Lets see how long Linux will hold out against the new generation of IoT OSes all being MIT/BSD based, and what the bazaar will get out of them. Or how long GCC will hold, when all major OSes use clang as their def…

>On the contrary, the claim is that without the GPL, commercial UNIXes would still be around. BSD is Older than Linux: https://en.wikipedia.org/wiki/History_of_the_Berkeley_Softwa...

It is, as anyone coding since mid-80's would be aware of, what is its market share by now?

Ah and there was that small legal issue back in the early 90's.

Re: Supporting Linux kernel development in Rust

#330

Post by pjmlp » Tue, Sep 01, 2020, 4:04 PM UTC

onetimertwo wrote: post #327

pjmlp wrote: post #297

Earlier quoted context omitted.

On the contrary, the claim is that without the GPL, commercial UNIXes would still be around. Since I am a commercial software user for most part, this is more of a philosophical question than anything else. Lets see how long Linux will hold out against the new generation of IoT OSes all being MIT/BSD based, and what the bazaar will get out of them. Or how long GCC will hold, when all major OSes use clang as their def…

> the new generation of IoT OSes all being MIT/BSD based RIOT OS is LGPLv2.1.

Fair enough, what makes it a contender versus the Amazon, Microsoft, ARM, Samsung, Google, Linux Foundation sponsored ones?