[flagged]
[deleted]
Maestro: A Linux-compatible kernel in Rust
201–210 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#202I love it and hope it will catch on. I reminds me of what Linus Torvalds once said when asked about fearing competition, though. From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.
[deleted]
Re: Maestro: A Linux-compatible kernel in Rust
#203Sounds 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,…
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.
Re: Maestro: A Linux-compatible kernel in Rust
#204There's also Kerla [1] (Monolithic kernel in Rust, aiming for Linux ABI compatibility), but that seems to have gone dormant for few years. [1] https://news.ycombinator.com/item?id=28986229
Or Redox OS, which is still there: https://www.redox-os.org/. It has a micro kernel design. But it is a bit more mature probably. And also MIT licensed so, there probably is some opportunity for code sharing.
Re: Maestro: A Linux-compatible kernel in Rust
#205MIT license? If by chance this evolves into something big, it will be eaten alive by commercial interests. Look at the conflict between Linux devs and nVidia for example. Look at the IBM/RedHat stuff trying to circumvent the spirit of the GPL, if maybe not the text of it. If it becomes a thing, the most active developers will be paid by corporations and they will not be sharing code with you when it suits them - whic…
[deleted]
Re: Maestro: A Linux-compatible kernel in Rust
#206MIT license? If by chance this evolves into something big, it will be eaten alive by commercial interests. Look at the conflict between Linux devs and nVidia for example. Look at the IBM/RedHat stuff trying to circumvent the spirit of the GPL, if maybe not the text of it. If it becomes a thing, the most active developers will be paid by corporations and they will not be sharing code with you when it suits them - whic…
> I'd recommend changing to GPLv3
I'd recommend AGPLv3, to avoid the Windows 365 loophole. (As I understand, you'd still be able to run a web server without sharing the source code of the kernel.)
Re: Maestro: A Linux-compatible kernel in Rust
#207Earlier quoted context omitted.
It seems to me that your examples rather show the futility of trying to use a license to force good behaviour rather than a reason to change licenses.
The only reason there is one Linux kernel everyone uses is because of the license. If it wasn't GPL2 there would be "Microsoft Linux", "Google Linux", "Oracle Linux" all with different features and potential incompatibilities. At least with the GPL2 license those flavors have to contribute changes back upstream so everyone gets the benefits.
They don't have to contribute them upstream: they just have to give their users the permission to do so.
Re: Maestro: A Linux-compatible kernel in Rust
#208Earlier quoted context omitted.
RISC-V is a modern load-store ISA. Is is very clean, much more than the mess of x86_64 for instance. It is actually better to write RISC-V than x86_64, even if the later is CISC.
Even if this is true, which I agree it is, it’s still a 100x more painful than writing a programming language and compiling to RISC-V. That also gives you the benefit of compiling to multiple arch’s
This is where you are wrong: it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run.
Short term-ists won't understand as this is going for the long run, and that requires perspective of what happened in software in the last decades.
Re: Maestro: A Linux-compatible kernel in Rust
#209MIT license? If by chance this evolves into something big, it will be eaten alive by commercial interests. Look at the conflict between Linux devs and nVidia for example. Look at the IBM/RedHat stuff trying to circumvent the spirit of the GPL, if maybe not the text of it. If it becomes a thing, the most active developers will be paid by corporations and they will not be sharing code with you when it suits them - whic…
It seems to me that your examples rather show the futility of trying to use a license to force good behaviour rather than a reason to change licenses.
>> It seems to me that your examples rather show the futility of trying to use a license to force good behaviour rather than a reason to change licenses.
If not for the license there would be NO good behavior. Notice that nVidia is relatively Linux friendly with some exceptions and RedHat seems to be under pressure to make more money but is otherwise very Linux friendly. Without the license, all sorts of others would be blatantly ripping it off.
I contend the difference in popularity and success between the BSDs and Linux is most likely due to the GPL license.
Re: Maestro: A Linux-compatible kernel in Rust
#210Earlier quoted context omitted.
People who want stable interfaces should not touch anything Linux with a ten-foot pole.
Care to elaborate on this? I clearly understand nothing of this, but it always felt confused about it. Why won't Linux aim for ABI stability? Wouldn't that be a win for everyone involved?
TL;DR: maintaining a stable driver ABI is more work because you have to deal with backwards compatibility, and it mainly benefits vendors that don't make their drivers open source.
So the Linux devs are really against it both from a lack of resources point of view, and from an ideological "we hate closed source" point of view.
Unfortunately, most vendors with closed source drivers don't give a shit about ideology and simply provide binaries for very specific Linux releases. That means users end up getting screwed because they are stuck on those old Linux versions and can't upgrade.
The Linux devs have this strange idea that vendors will see this situation as bad and decide that the best option is to open source their code, but that never happens. Even Google couldn't get them to do that. This is one of the main reasons that Android OS updates are not easy and universal.