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

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

Post reply on HN
Print view View original

291–300 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#291

Post by bigstrat2003 »

peoplefromibiza wrote: post #268
bigstrat2003 wrote: post #247

Earlier quoted context omitted.

> Lastly, the strongest Linux safety guarantee is IMO the GPL license, that conveniently all these Rust rewrites are turning into more permissive licenses. Which steers away from what Linux was, and still largely is, a community effort based on the work of thousands of volunteers. There is nothing about permissive licenses which prevents the project from being such a community effort. In fact, most of the Rust ecosys…

> There's no issue here Tell that to Microsoft. GPL protected Linux when Linux started to become a threat to the most powerful tech company on Earth of the time, famous for their "embrace and extend" tactic. Rust had no such problem, it was started by a company that every year takes hundreds of millions (81% of their revenues in 2022) from one of the most powerful tech companies on Earth.

I genuinely have no idea what your point is.

Re: Maestro: A Linux-compatible kernel in Rust

#292

Post by bigstrat2003 »

phkahler wrote: post #264
yoyohello13 wrote: post #220

Earlier quoted context omitted.

The amount of hate for GPL on HN is disturbing.

>> The amount of hate for GPL on HN is disturbing. I agree. I'm really baffled by the Rust community pretty much standardizing on MIT license. People laugh at "Rewrite it in Rust" which I think is a good thing but completely ignore the whole "strip users of their freedom" that is coming with it one day.

This FUD always comes up from people who support the GPL and it's so annoying. Let's say that Maestro takes off and gains popularity, and then someone decides to turn it into a commercial OS. What, exactly, is supposed to be so bad about that? Nobody loses a damn thing - if you want to use the MIT licensed original project, it hasn't gone anywhere. And for those who find that there's value in the commercial version, they have that available to them too. Everyone wins in that scenario.

There's no loss of freedom with permissive licenses.

Re: Maestro: A Linux-compatible kernel in Rust

#294

Post by [deleted] »

llenotre wrote: post #144
agentultra wrote: post #100

Sounds like a fun project. Curious though: most of the drawbacks to using C and difficulties with developing an OS are around debugging. I assume that the switch to Rust eliminated a certain class of memory error but is debugging still a pain? Or is there less of it than before the switch making debugging more tolerable?

A lot of memory and concurrency issues have been eliminated. It is still a pain to debug, but a lot less than it was before though. As an example, there is not a lot of chances you forget to use a mutex since the compiler would remind it to you by an error. This is not a silver bullet though, things such as deadlocks are still present. Especially with interruptions. To give an example, if you decide to lock a mutex,…

[deleted]

Re: Maestro: A Linux-compatible kernel in Rust

#296

Post by colonwqbang »

loeg wrote: post #261
claytonwramsey wrote: post #203

Earlier quoted context omitted.

If you’re willing to implement your own mutex, it actually is possible to enforce! You could make disabling interrupts emit a token and then require the mutex to accept that token as a parameter to its locking behavior.

How would you enforce use of (only) the correct kind of mutex in interrupt context?

In Haskell this should be "easy" to do using monads. You would have a process monad and an atomic monad (using Linux terminology). The operation to lock a sleeping mutex would live in the process monad. It would be possible to lift an atomic computation into process context (disabling interrupts) but not the other way around.

I don't think rust has such a concept of different computation contexts (does it?)

Of course Haskell may not be the most suitable kernel implementation language for other reasons...

Re: Maestro: A Linux-compatible kernel in Rust

#297

Post by [deleted] »

jancsika wrote: post #290

My two cents-- make the license be exactly whatever Linux is-- gplv2 only IIRC If you do this then you'll never waste another moment discussing licenses for the rest of your life. It's just "because it's what Linux uses" to the end of time. And even if there's some future question about license enforcement or whatever wrt gplv2, it will get decided within Linux/Linux Foundation/etc. and you just surf in on whatever h…

[deleted]

Re: Maestro: A Linux-compatible kernel in Rust

#299

Post by yoyohello13 »

bigstrat2003 wrote: post #292
phkahler wrote: post #264

Earlier quoted context omitted.

>> The amount of hate for GPL on HN is disturbing. I agree. I'm really baffled by the Rust community pretty much standardizing on MIT license. People laugh at "Rewrite it in Rust" which I think is a good thing but completely ignore the whole "strip users of their freedom" that is coming with it one day.

This FUD always comes up from people who support the GPL and it's so annoying. Let's say that Maestro takes off and gains popularity, and then someone decides to turn it into a commercial OS. What, exactly, is supposed to be so bad about that? Nobody loses a damn thing - if you want to use the MIT licensed original project, it hasn't gone anywhere. And for those who find that there's value in the commercial version,…

Copy left protects against embrace extend extinguish techniques.

It ensures everyone benefits from improvements, not just users who are willing to pay bigco.

Re: Maestro: A Linux-compatible kernel in Rust

#300

Post by yazaddaruvala »

yoyohello13 wrote: post #299
bigstrat2003 wrote: post #292

Earlier quoted context omitted.

This FUD always comes up from people who support the GPL and it's so annoying. Let's say that Maestro takes off and gains popularity, and then someone decides to turn it into a commercial OS. What, exactly, is supposed to be so bad about that? Nobody loses a damn thing - if you want to use the MIT licensed original project, it hasn't gone anywhere. And for those who find that there's value in the commercial version,…

Copy left protects against embrace extend extinguish techniques. It ensures everyone benefits from improvements, not just users who are willing to pay bigco.

But... in fairness its not feasible to extinguish rando person's school / hobby project.

Even if it "takes off", how can a commercial entity extinguish a person's motivation to keep building something they want?

Post reply on HN