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

331–340 of 365 posts

Re: Supporting Linux kernel development in Rust

#331

Post by nix23 »

pjmlp wrote: post #329
nix23 wrote: post #326

Earlier quoted context omitted.

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

1/3 of the us internet traffic, not counting Juniper, then add all PS2/3/4 Consoles, MacOS's, FreeNas, EMC-San's: Biggest German Online Seller, Sony Japan, Checkpoint and so on...search for yourself.

BTW: Market-share means nothing, you know Android is NOT Gnu/Linux

EDIT: Maybe your too young..but do you remember that SCO/Microsoft thingy with Linux

Re: Supporting Linux kernel development in Rust

#332

Post by pjmlp »

fluffything wrote: post #322
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. 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 contri…

Exactly because I see LLVM as an example, given that not everyone using it contributes 100% back upstream.

I wouldn't consider BSD layer from NeXTSTEP an example of success for BSD's market adoption, given that not everything goes upstream, by now it hardly represents the current state of affairs.

If anything it represents what would have happened without Linux, all major UNIX vendors would continue to take pieces of BSD and not necessarily contribute anything back.

Re: Supporting Linux kernel development in Rust

#333

Post by quietbritishjim »

snuxoll wrote: post #314
cbmuser wrote: post #80

If we get the Rust backend for gcc finalized and merged first, it would be much easier to get Rust code into the kernel: > https://github.com/philberty/gccrs/

How would that make things any easier? The kernel supports being built with clang now, and there’s no issue linking an object built with another compiler into a module either.

Even if it is possible to build the kernel with clang, presumably that doesn't mean it is acceptable to suddenly require the kernel to be built with clang?

Re: Supporting Linux kernel development in Rust

#334

Post by ColanR »

genghizkhan wrote: post #238
ColanR wrote: post #27

Earlier quoted context omitted.

I was thinking about something similar recently - if the hardware drivers could somehow be abstracted from the rest of the linux kernel (as if...), then suddenly a ton of experimental kernels could have widespread hardware availability. It would probably shake up the OS ecosystem to no small degree, but I imagine the fresh ideas that could be experimented with by non-experts would be hugely beneficial. Isn't that the…

> FreeBSD might be a better target though, since that's specifically designed to be compatible with everything. NetBSD, perhaps, would be a better choice for "tries to run everywhere"?

You're right, I confused the two.

Re: Supporting Linux kernel development in Rust

#335

Post by gsnedders »

afiori wrote: post #317
rfoo wrote: post #253

Earlier quoted context omitted.

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.

Personally I see this as a good counterargument for "just fork it." Imagine if chrome decided to crank up churn with the intention to exhaust forks. Maybe all forks would join together to fight google or more likely they would just fall behind.

This has practically already happened; there are very few Chrome-based applications that actually stay up-to-date, and Electron isn't much better.

Re: Supporting Linux kernel development in Rust

#336

Post by R0b0t1 »

JoshTriplett wrote: post #15
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…

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog pos…

>Rust does not require internet access to use

This is debatable. The default workflow requires access to crates.io, and it is pretty hard to not use crates.io.

Re: Supporting Linux kernel development in Rust

#337

Post by steveklabnik »

R0b0t1 wrote: post #336
JoshTriplett wrote: post #15

Earlier quoted context omitted.

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog pos…

>Rust does not require internet access to use This is debatable. The default workflow requires access to crates.io, and it is pretty hard to not use crates.io.

It is well supported by the project itself, we offer a variety of tools so that you do not need internet access, and this was also a hard requirement of a lot of our early important users, like Firefox and various distros.

Even with using crates from crates.io.

Re: Supporting Linux kernel development in Rust

#338

Post by R0b0t1 »

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…

Once GCC is no longer the state of the art it is unlikely MIT/BSD licensed alternatives will have their contributions publicly released.

Re: Supporting Linux kernel development in Rust

#339

Post by fluffything »

pjmlp wrote: post #332
fluffything wrote: post #322

Earlier quoted context omitted.

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

Exactly because I see LLVM as an example, given that not everyone using it contributes 100% back upstream. I wouldn't consider BSD layer from NeXTSTEP an example of success for BSD's market adoption, given that not everything goes upstream, by now it hardly represents the current state of affairs. If anything it represents what would have happened without Linux, all major UNIX vendors would continue to take pieces of…

> I wouldn't consider BSD layer from NeXTSTEP an example of success for BSD's market adoption, given that not everything goes upstream, by now it hardly represents the current state of affairs.

Its essentially what happens if (1) only one company wants to use the open source product, and (2) the open source product has a tiny community where no development happens.

In that scenario, there is no benefit from anybody forking the open source project (a private company or an individual) for upstreaming anything. It just costs time, but adds no value for them.

Linux and GCC never was like this (not even early days), and I think this is independent of its license. LLVM never was like this either.

In fact, there are many private companies that maintain a GCC fork, like arm, and due to the GPL need to provide its sources with a copy, which they do. But they are not required to reintegrate anything upstream, which they very often don't, and ARM support in gcc-arm from ARM is much better than on GCC upstream. A volunteer can't merge (review, rebase, ...) a 200k LOC patch on their free time, so once these forks diverge, its essentially game over. You'll need a team of volunteers equal in man power to what the private company provides.

So while the license affects which companies can use an open source project in practice, and what they can or cannot contribute. The GPL2 and GPL3 licenses are not a good tool to actually allow everybody to benefit from those contributions.

Maybe a GPL4 could require companies to upstream and get their contributions accepted, but IMO that would just get even less companies to use those projects.

Re: Supporting Linux kernel development in Rust

#340

Post by dang »

shock wrote: post #144
dang wrote: post #127

Earlier quoted context omitted.

Please don't be repetitive in HN comments, though. Repetition is the enemy of curiosity and curiosity is the core value here. https://news.ycombinator.com/newsguidelines.html

> Repetition is the enemy of curiosity I haven't found a source for that, but I don't believe it to be true and I'm curious why you do. I haven't seen the previous comments of the OP so for me this comment was useful.

But if you had seen the previous comments, that is, if you'd experienced repetition instead of new information, then they'd have been less curious and less useful. Curiosity wants to find new things, learn new things—it basically wants diffs because diffs are what it finds interesting. My source? Self-observation and observation of this community. Is it really a controversial point?

Even when we mark stories as dupes there are often users who say it was new to them and they appreciated the post. That makes perfect sense. No one sees everything, and if you haven't encountered the earlier elements of a repetitive sequence, then for you there is no repetition. I'm always reminded of a second-hand clothing store in my home town called "New to You".

But at a site-wide level it's not hard to understand that this is a stochastic process and we have to manage it globally. The alternative would be not to moderate repetition at all, and the community would definitely not prefer that.

Post reply on HN