[flagged]
What about it seems unethical to you?
Maestro: A Linux-compatible kernel in Rust
241–250 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#242[flagged]
The supreme court ruled[0] that copyright (and thus copyleft?) does not apply to APIs.
[0] https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America....
Re: Maestro: A Linux-compatible kernel in Rust
#243Is there some sort of organised push for dropping copyleft? 2nd post today going down that route
Not everyone likes copyleft licenses. It's as simple as that.
Re: Maestro: A Linux-compatible kernel in Rust
#244Earlier quoted context omitted.
There have been attempts to create kernel-agnostic interfaces for drivers such as: https://en.wikipedia.org/wiki/Uniform_Driver_Interface For my case, I am planning to re-implement them. I like doing this. I sure am not going to be able to re-implement everything myself though. I will concentrate on what I need, and I will consider implementing others if anyone else other than me is willing to use the OS (which would…
You can implement a virtual machine monitor (e.g. KVM) and then launch a Linux virtual machine to run drivers you lack.
Or NetBSD drivers via rump:
Re: Maestro: A Linux-compatible kernel in Rust
#245Re: Maestro: A Linux-compatible kernel in Rust
#246Earlier quoted context omitted.
I imagine someone could set up a complicated autofeedback loop. Describe the task to the LLM, give a development system and a possibility to run many tests, then let it rip. I still think perhaps not too soon. I think the problem that there are many things to optimize for. One of them is correctness, but if a program runs this does not mean it is correct. Another thing is security. How to test the system for security…
Because there is much more to the linux kernel than maintenance. Look at things like ebpf and uring for examples of meeting real needs with new development in the kernel. I doubt that a LLM will be able to come up with the ideas, and implement these things without substantial prompting. For the every day stuff. Yeah, sure. Though you'd be amazed how many strange corner conditions POSIX and Linux have even around "sim…
It's not neccessary that the LLM by itself comes up with ideas, only the person who tells the LLM.
«Gee what if the kernel could do clairvoyance? Implement a syscall! Specify the parameters and the structure of the data being returned!»
A more realistic scenario is just imitating Linux' syscalls.
EDIT: Just had an idea what could happen. Some guy can't do kernel development but is annoyed that a feature request got declined. Someone else set up an LLM-driven kernel development system. That guy now tells the system to implement said feature. The rest of the story: even more community fracture.
Re: Maestro: A Linux-compatible kernel in Rust
#247A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…
> if Linux had been built with safety in mind security would be a lot simpler I'm replying simply because you're getting defensive with your edits, but you're missing a few important points, IMO. First of all, the comment I quoted falls straight into the category of if only we knew back then what we know now . What does it even mean "built with safety in mind" for a project like Linux? No one could predict that Linux…
> 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 ecosystem is a community effort just like you describe, while most projects have permissive licenses. There's no issue here.
Re: Maestro: A Linux-compatible kernel in Rust
#248Earlier quoted context omitted.
Cyclic logic that says you're wrong for wanting a stable kernel interface, because the kernel keeps changing so the solution is to just get your code merged into mainline. As a tautology, it's true, but it's also a cover for "because we don't want to". See Windows or android GKI for existence proof that it can be done if so motivated.
From what I understood, I think the big difference here is the human factor: Windows and Android are maintained by employees, who have no choice but to work on things even if they don't like doing it. Linux on the other hand is a collective effort of people doing what they want to do on their free time.
That's a myth. Most Linux contributions come from paid employees from various companies not unpaid volunteers.
Re: Maestro: A Linux-compatible kernel in Rust
#249There'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.
Seems that the project is dead. The repository does not receive any commit for two years.
Re: Maestro: A Linux-compatible kernel in Rust
#250Earlier quoted context omitted.
The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.
JS and Rust are memory safe languages with a culture of pulling in hundreds if not thousands of dependencies. So unfortunately, in terms of culture, at least those languages are not Pareto improvements.
Also a lot of "in Rust" rewrites include a substantial amount of unsafe FFI calls to the original C libraries...