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

341–350 of 365 posts

Re: Supporting Linux kernel development in Rust

#341

Post by dang »

ghostwriter wrote: post #141
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

What would be the proper way of informing those who are interested in the topic about available alternatives? I assume not everyone follows the same topics and there may be people who see the presented information and the relevant references for the first time.

I think if you absorb the responses from other users here, and adapt your future comments more to the specifics of a given story, that should help a lot. geofft makes a good point about linking to past points rather than repeating them. That's the way to handle repetition on HN. Don't inline generic material from before—refer to it via links.

Re: Supporting Linux kernel development in Rust

#342

Post by R0b0t1 »

steveklabnik wrote: post #337
R0b0t1 wrote: post #336

Earlier quoted context omitted.

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

If crates.io was down tomorrow there would be a major disruption to you if you were using Rust for development. That is their point, as well as potentially exploring other reasons.

As someone who uses a source-based distro I hate language package managers. They always end up inferior to a distro package manager and create extra work for everyone, including the language developers, who tolerate it because it is in their favorite language.

Re: Supporting Linux kernel development in Rust

#343

Post by snuxoll »

pjmlp wrote: post #269
why_only_15 wrote: post #219

Earlier quoted context omitted.

This is mostly just a random tidbit but one of the fascinating things to me about Swift ObjC interop is that it's not just that Swift was modified for ObjC, but ObjC was modified for Swift as well. In general it works pretty well and I wonder how much of that is because Apple can modify ObjC whenever it wants.

.NET C++/COM also went through a similar process.

.Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition.

One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.

Re: Supporting Linux kernel development in Rust

#344

Post by pjmlp »

snuxoll wrote: post #343
pjmlp wrote: post #269

Earlier quoted context omitted.

.NET C++/COM also went through a similar process.

.Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition. One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.

Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML).

Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.

Re: Supporting Linux kernel development in Rust

#345

Post by heavyset_go »

snuxoll wrote: post #311
mac01021 wrote: post #266

Earlier quoted context omitted.

BSD -> Mac OS?

All the bits for the core of the system are open, it’s just not very exciting without the proprietary bits like WindowServer, AppKit, etc. - all of which would have been equally easy to keep closed if much of Darwin was based on GPL’d projects.

> All the bits for the core of the system are open

No, some bits are open, and some bits track what's actually being shipped. Much of what is open sourced lags behind what is running on end user machines by several years. iOS modifications to XNU and Darwin were never made open source.

Apple is also dropping GPL internals in favor of open source but not copyleft licenses so that they don't have to release source code changes to the software they release.

Re: Supporting Linux kernel development in Rust

#346

Post by pjmlp »

nix23 wrote: post #331
pjmlp wrote: post #329

Earlier quoted context omitted.

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

I known, most of them don't contribute that much upstream.

I surely remember it, except BSD did not ever had anyone like IBM jumping into the battle. :)

As for being young, thanks for the compliment

> ...as anyone coding since mid-80's....

And as information, during the early days, the Internet ran on commercial UNIXes.

Re: Supporting Linux kernel development in Rust

#347

Post by ptman »

bryanlarsen wrote: post #319
jasode wrote: post #309

Earlier quoted context omitted.

> If their only choices are developing their own compiler or basing off of gcc and releasing their work, they'd choose gcc. But that's the exact choice Apple faced in 2005 and they did not choose gcc . They paid Chris Lattner and his team to develop an alternative compiler. Excerpt from wikipedia[1]: >"Finally, GCC is licensed under the terms of GNU General Public License (GPL) version 3, which requires developers wh…

Sure, if you have the resources of Apple, you can make other choices. I'd be willing to bet that Apple has spent more than $1B on clang, llvm, tooling, testing, integration, et cetera.

How much resources did they actually have in 2005?

Re: Supporting Linux kernel development in Rust

#348

Post by pjmlp »

eptcyka wrote: post #8
boogies wrote: post #6

Earlier quoted context omitted.

The article mentions possible ABI compatibility challenges and I also think it’s not a good thing for a language in such critical applications to only have a single major implementation.

The linux kernel still can only be compiled with GCC. Of course, it's a single patch away from clang compatibility, but the kernel has never been compilable with much else but GCC.

Android and ChromeOS beg to differ, as Google has been using clang with them for at least around three years now.

Re: Supporting Linux kernel development in Rust

#349

Post by Raphael_Amiard »

pjmlp wrote: post #216
woodruffw wrote: post #162

Earlier quoted context omitted.

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

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.

How do you consider the improvements they didn't make (even before llvm was released) to gcc ?

Re: Supporting Linux kernel development in Rust

#350

Post by steveklabnik »

R0b0t1 wrote: post #342
steveklabnik wrote: post #337

Earlier quoted context omitted.

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.

If crates.io was down tomorrow there would be a major disruption to you if you were using Rust for development. That is their point, as well as potentially exploring other reasons. As someone who uses a source-based distro I hate language package managers. They always end up inferior to a distro package manager and create extra work for everyone, including the language developers, who tolerate it because it is in the…

It would only be an issue if I wanted to use crates that weren’t in my local cache already. And that’s gonna be true of any build system. It would also be true of any distro package manager.
Post reply on HN