I 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.
But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied…
Maestro: A Linux-compatible kernel in Rust
91–100 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#92I wonder how far we are from having a GPT-X.Y operating in a loop, creating a fully Linux-compatible kernel with all 437 system calls in Rust within a day, which includes testing, debugging, and recompiling.
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? Have another LLM playing an adversary and try to hack the system?
This said, I wonder if someone manages to pull this off what the implications might be.
One of them: Have this system re-run automatically everytime as long as the Linux kernel is maintained.
Then why should anybody invest the effort of continuing development of the Linux kernel?
Then how to advance the development? Just tell the LLM to add a feature?
Re: Maestro: A Linux-compatible kernel in Rust
#93A 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…
Re: Maestro: A Linux-compatible kernel in Rust
#94Small feedback: On mobile the back button (and nav bar) block 1/6th of the page, probably could use a bit less padding
Re: Maestro: A Linux-compatible kernel in Rust
#95Earlier quoted context omitted.
Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, ac…
You can get your assembly-written kernel right now for every OS out there: just compile Linux using a RISC-V backend of your favourite compiler.
Re: Maestro: A Linux-compatible kernel in Rust
#96Unrelated but at same time related, feel your self absolutelly free to ignore this message,
Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode.
As an [put operative system name here] user, I need (desire) to know when a process/program wants to access the network or internet, if it wants to act as a server, what port, what IP's wants to call at that moment, and to be able to block the operation before happen, limit what IP's are allowed to serve or not to the program, being able to sniffing the program behavior.
In that moment/event, I need to know how was launched the process/program, what parent process launched it. To know if the process wants to inject over another one own resource something, or wants to access not natural system resources. And before it happens, being able to block such intention for folder/files/disk access, keyboard, screenshots, configuration system files, console commands and so on.
If that program wants to launch another program, or service and so on, it's needed to control even if it is allowed to launch an executable in its own folder. Absolutely supervise the program and system access.
As user, I need to be prompted about all of this before happens, with information, for to give permission or not, temporally at that moment, or session, or to save it as decision that will taken the next time the program run.
Being able to configure latter it is essential, a UI more or less like a uMatrix UI point of view, and so on, designed for usability.
When one run a program, the gears of the HISP always are runing:
- Why is trying to inject this program the browser memory? of course I do not allow it, it's more, I kill the process right now . System scan now, we are in troubles. Log, were are the logs!! Damn, the next two days are going to be miserable... I'll probably format the whole system when I find from were entered this.
- Why is this trying to connect to internet? it's more, this IP is from XXXXX, isn't it? sorry, I do not allow it, run without this requests or die.
- What, this is requesting DNS?, And now it is requesting a local network IP address? Houston...
- Ehhh, what are you doing with that keyboard capture try? unnecessary, akta gammat.
- Ok server installed running for first time, but only under this specific port, and only the loopback IP is allowed to access, this computer and anyone else. This was fast.
- Ok, I allow you to access such internet IP, but only this time, keep asking the next time you run, I'll decide.
- Thanks for warning about the port scan, I guess with IPv6 this would be even worst. Thankfully I have all the services limited to IPv4 localhost, but I'll keep one eye over those bots if they insist much.
- and so on.
This does not exist in Linux. Currently it is a Windows users thing, after installing and configuring tools, with exception of the console command filtering and uMatrix UI, that I added because they are also necessary (In windows, HISP's configuring interfaces are just.. very rustic and hidden, they don't have usability in mind, it is like an available legacy feature, unfortunately).Whatever. In Linux, this require kernel custom modifications, and the whole HISP with firewall does not exist, and ironically, when separated one from the another are just useless.
So, humbly but from an selfish way, I would ask to consider design the kernel with this thing in mind. ( I do not mean to design the HISP with firewall application).
As I started saying, feel your self absolutely and totally free to ignore this message.
Re: Maestro: A Linux-compatible kernel in Rust
#97Earlier quoted context omitted.
But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied…
>We must have a GPU hardware programming "standard" first. Isn't that what WebGPU has become?
Re: Maestro: A Linux-compatible kernel in Rust
#98Re: Maestro: A Linux-compatible kernel in Rust
#99Earlier quoted context omitted.
But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied…
What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.
The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel.
clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.
Re: Maestro: A Linux-compatible kernel in Rust
#100I 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?