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

241–250 of 365 posts

Re: Supporting Linux kernel development in Rust

#241

Post by pjmlp »

qalmakka wrote: post #228
pjmlp wrote: post #217

Earlier quoted context omitted.

GCC has plenty of frontends to choose from. The license was the biggest deal.

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…

Sure, now you get to enjoy all those PS4 optimizations, and watchOS bitcode portability fixes in LLVM.

Re: Supporting Linux kernel development in Rust

#242

Post by pjmlp »

_ph_ wrote: post #240
pjmlp wrote: post #216

Earlier quoted context omitted.

I don't consider the improvements that ARM, Apple, Sony, CodePlay, NVidia, AMD, among others, don't upstream due to IP considerations or revealing of hardware secrets, niche.

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.

Re: Supporting Linux kernel development in Rust

#243

Post by joshuamorton »

jcelerier wrote: post #239
joshuamorton wrote: post #154

Earlier quoted context omitted.

The gpl projects are also corporately sponsored, just indirectly.

A fair amount of GPL work is done by researchers in public universities

The same is true of non-gpl work.

Half the linux foundation's funding comes from 6 companies. Not to mention the full time employees paid to work on it. And I find that there's similar patterns in a lot of other widely used gpl software. Similarly, MIT/Apache software gets tons of contributions from non-corp people too.

Re: Supporting Linux kernel development in Rust

#244

Post by jabl »

frutiger wrote: post #218
geofft wrote: post #205

Earlier quoted context omitted.

Right, the reality is that if you want to be a profitable tech company today, you have to leverage open source. "Their use cases" includes, like, everything in a Linux distro. (And yes, this applies to Apple and Microsoft as well as Google.) The necessity of open source for industry has both negative and positive implications for those of us who care about open source / free software as an ideal and not simply a tool…

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

It's not churn for churn's sake. But having a policy of having drivers in-tree and explicitly not caring about out-of-tree stuff allows them a relatively free hand to improve the internals. Which is then seen as churn by out-of-tree code.

Re: Supporting Linux kernel development in Rust

#245

Post by weinzierl »

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…

> "One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers [..]"

This reminds me of an interview with Linus Torvalds from many many years ago, when he was still very young. The interviewer asked him if he was afraid of getting replaced by someone young and hungry. Torvalds shrugged it of with something along the lines of: Nah, no one likes to do driver development.

Re: Supporting Linux kernel development in Rust

#246

Post by manvendrasingh »

aey wrote: post #212

We built a whole BPF tool chain for rust :), although not for kernel development. https://github.com/solana-labs/rust If this kind of seems interesting please send us a CV.

It does, problem is i am in IST Timezone, Will that work for the team ?

Re: Supporting Linux kernel development in Rust

#247

Post by smabie »

pjmlp wrote: post #215
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.

Yes, we are short of getting back into the days of Shareware and PD, and then the anti-GPL crowd will be happy with the outcome. As commercial software user, I don't have much issue with it, after all I have been coding since the early 80's. And in spite of it and my occasional Linux rants, I am thankful for GPL, because without it there wouldn't be a UNIX to install at home to get my university work from DG/UX done…

I mean, without Linux the arguably superior BSDs would rule the roost, not commercial unices.

Re: Supporting Linux kernel development in Rust

#248

Post by JetSetWilly »

ArchOversight wrote: post #19
boogies wrote: post #2

Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU / formerly Linux-libre, in future using a fork of the OpenBSD kernel https://itsfoss.com/hyperbola-linux-bsd/ ) devs that Rust in Linux is not necessarily a good thing, for the reasons they mentioned when they announced they were switching kernels ( https://www.hyperbola.info/news/announcing-hyperbolabsd-road... ) (Edit: and the LLVM depe…

Once again the GPL camp takes and relicenses a project so that further improvements they make can't be used by the original authors. Shame really.

If they didn't want people to be able to make changes that cannot be used upstream, there's a license for that. It's called the GPL.

Re: Supporting Linux kernel development in Rust

#249

Post by pjmlp »

smabie wrote: post #247
pjmlp wrote: post #215

Earlier quoted context omitted.

Yes, we are short of getting back into the days of Shareware and PD, and then the anti-GPL crowd will be happy with the outcome. As commercial software user, I don't have much issue with it, after all I have been coding since the early 80's. And in spite of it and my occasional Linux rants, I am thankful for GPL, because without it there wouldn't be a UNIX to install at home to get my university work from DG/UX done…

I mean, without Linux the arguably superior BSDs would rule the roost, not commercial unices.

Sure keep believing it, I love the Apple and Sony contributions to upstream.

Re: Supporting Linux kernel development in Rust

#250

Post by roca »

pjmlp wrote: post #220
roca wrote: post #188

Earlier quoted context omitted.

And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.

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.
Post reply on HN