Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moss: a Rust Linux-compatible kernel in 26,000 lines of code

github.com

Post reply on HN
Print view View original

131–140 of 163 posts

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#131

Post by beeflet »

LeFantome wrote: post #80
leo_e wrote: post #65

The choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to. We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix. Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedd…

Not sure why am getting in the middle of this but I need to point out that you are not even correct for Linux. Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this. As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open…

>Probably not.

Probably not, but possibly yes. Which is more than the cuck license guarantees. See postmarketOS and such, which would be impossible in a BSD world.

>The vast majority of vendors that use Linux embedded never contribute a single line of code

It doesn't matter. The point is just that they can be legally compelled to if needed. That is better than nothing.

>The level of contribution has nothing to do with the GPL.

None of this would be feasible if linux wasn't a platform where the drivers work. They wouldn't have worked on the linux userspace in the first place if it didn't have driver support: it wouldn't be a viable competitor to windows and the whole PC platform would probably be locked down anyways without a decent competitor. Permissive software is parasitic in this sense that it benefits from inter-operating in a copyleft environment but cooperates with attempts to lock down the market.

LLVM was made after GCC and is designed with a different architecture. It is apples and oranges.

Apple is a great example of a company that is flooding the world with locked-down devices. Everything they do is an obstacle to general purpose computing. What do they meaningfully commit to the public domain? Swift? Webkit? It is part of a strategy to improve their lock-in and ultimately make collaboration impossible.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#132

Post by loeg »

nmz wrote: post #90
wmf wrote: post #85

Earlier quoted context omitted.

That's 1980s-90s thinking. Nobody is making proprietary BSD forks any more and new kernels probably have no chance of reaching production anyway so worrying about proprietary forks is irrelevant.

The most recent and most used fork for freebsd is for the ps4 https://en.wikipedia.org/wiki/PlayStation_4_system_software

A console that launched 12 years ago.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#133

Post by loeg »

leo_e wrote: post #65

The choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to. We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix. Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedd…

This comment is a tangential distraction, but it's not even correct. Linus Torvalds has specifically claimed that he wouldn't have created Linux at all if 386BSD was available at the time. But BSD was tied up in a lawsuit with USL, discouraging companies and individuals from use.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#134

Post by woodruffw »

RealityVoid wrote: post #93
woodruffw wrote: post #82

Earlier quoted context omitted.

> There’s an LLVM fork for every esoteric architecture now Can you provide examples of these? I'm aware of temporary forks for things like Xtensa, but these typically get merged back upstream.

Infineon tricore compiler from hightec. Compilers are actually, IMO, one of the things that are the most easy to have GPL because you can use it internally however you want without releasing the source outside. You could build whatever you want and you don't have to ship it on the final HW. A kernel does not afford you such a thing, you MUST ship it with your product.

Thanks for the example! Your opinion here aligns with mine: GCC's GPL status has manifestly not been an issue for vendors in the past. I think the reason for vendors selecting LLVM has much more to do with the fact that LLVM is easier to develop on than GCC.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#137

Post by imiric »

nickpsecurity wrote: post #123
imiric wrote: post #40

Earlier quoted context omitted.

A gift where the recipient can remove the freedoms that they've been enjoying themselves is a bad deal for ensuring those freedoms are available to everyone. A permissive license is a terrible idea for a F/LOSS kernel. This is the paradox of tolerance, essentially. Also, seeing F/LOSS as a "gift" is an awful way of looking at it.

They can't remove it. They gave it to you. They just don't have to keep giving you more stuff. Many people think they're owed more software, including fixes to software, without compensating the laborer. That worldview is the real problem. So, we have a variety of licensing styles that meet various goals. People can pick what suits their needs and wants. That's a good thing.

> They can't remove it. They gave it to you. They just don't have to keep giving you more stuff.

Who is "they" in this context?

A permissive license allows anyone to take someone else's work, profit from it, and never contribute back to the original project. For someone advocating for fairness, it's remarkable how you ignore this very real and common scenario.

> Many people think they're owed more software, including fixes to software, without compensating the laborer. That worldview is the real problem.

Compensation is orthogonal to F/LOSS. Authors are free to choose whatever income streams they like, and many successful businesses have been built around F/LOSS. Whoever is expecting people to work without compensation is being unreasonable, of course.

But F/LOSS as a social movement goes beyond a mere financial transaction. It works on the basis of mutual trust, where if I share something you find valuable, then the acceptable "payment" for that work is for you to do the same. This collaborative effort is how the highest quality products are produced.

The irony of your point is that a permissive license allows precisely the scenario you're arguing against. We've seen corporations profit from the work of others without compensating them for it. So much so, that OSS projects are forced to roll back their permissive licenses, often going too far in the other direction, to where they can no longer be labeled as "Open Source". E.g. Elastic: Apache -> SSPL -> AGPL; Redis: BSD -> SSPL; HashiCorp: MPL -> BSL; etc.

That is the actual problem which copyleft licenses prevent.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#138

Post by ece »

LeFantome wrote: post #80
leo_e wrote: post #65

The choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to. We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix. Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedd…

Not sure why am getting in the middle of this but I need to point out that you are not even correct for Linux. Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this. As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open…

A few vendors have been stopped from shipping binary modules with Linux, notably those linking to certain symbols. Enough vendors have contributed enough to make Linux actually usable on the desktop with a wide range of off the shelf hardware and more and more are announcing day one compatibility or open source contributions. The same is hardly true for the BSDs.

It's obvious Sony is keeping certain drivers closed source while open sourcing other things, and why Nvidia decided to go with an open source driver. It's not hard to understand why, it could be some pressure or a modified GPL2.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#139

Post by procaryote »

nickpsecurity wrote: post #121
pessimizer wrote: post #44

Earlier quoted context omitted.

> It's more like a contractual agreement with something provided and specific, non-negotiable obligations. The obligation is not to the author of the code, it is to the public. MIT-style licenses are gifts to people and companies who produce code and software, copyleft licenses are gifts to the public. I don't give a shit about the happiness of programmers any more than the happiness of garbage collectors, sorry. I d…

A gift is when you do something without expecting anything in return, esp compensation. If I use GPL'd code, I have to keep releasing my modifications for free because it's mandated. I have to do that even if I do 1000 hours of labor but they gave me 30 min of it. So, it's also near-infinite work required in return for finite work they did. And I have to bind others to this with my own work. That's not someone giving…

If you intend to spend 1000 hours extending a gpl project someone put 30 minutes into, and you wouldn't have wanted to use GPL, perhaps don't use that project as a base? Spend 1000.5 hours and pick whatever license you like

The point of copyleft is that the author wants the code to remain available to the public, not to give it as a gift to whoever wants to build their own closed source system

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#140

Post by whitequark_ »

hexagonal-sun wrote: post #42
andrewl-hn wrote: post #33

Earlier quoted context omitted.

> no networking support Would something like Smoltcp be of help here? https://github.com/smoltcp-rs/smoltcp Great project either way! How do you decide which sys calls to work on? Is is based on what the user space binaries demand?

Yip, I panic whenever I encounter a syscall that I can't handle and that prompts me to implement it. Yeah, I was thinking of integrating that at some point. They've done a really nice job of keeping it no_std-friendly.

Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.
Post reply on HN