71–80 of 107 posts
They let you in, you take a shit on the floor and leave. Who is to blame? I don't blame this guy. It's the people who let the Barbarians in, because politics. Sometimes gates need to be kept.
> I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix. This is why I want to work on multi-kernel NixOS — I want to make this threat as credible as possible. If ever new kennel requires one to switch to an entirely different user land arbitrarily, they're just imposing stupid switch…
Is this something people have been working on, or is this "just" something on your personal todo list?
Maybe only tangentially related, but I have been pretty excited about https://spectrum-os.org/
I have no dog in this race, but basic logic says if the linux kernel contains rust code, then a linux kernel dev will either need to learn rust or avoid doing things that require changes to those parts of the code.
I don’t know how you can wave this away as “technical nonsense”.
> and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code I have no dog in this race, but basic logic says if the linux kernel contains rust code, then a linux kernel dev will either need to learn rust or avoid doing things that require changes to those parts of the code. I don’t know how you can wave this away as “technical nonsense”.
> and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code I have no dog in this race, but basic logic says if the linux kernel contains rust code, then a linux kernel dev will either need to learn rust or avoid doing things that require changes to those parts of the code. I don’t know how you can wave this away as “technical nonsense”.
Because if they do something that requires changes to the Rust code, the Rust for Linux folks will take care of it for them. This has been explained repeatedly.
Now, if rust is only in a few corners of linux, then there isn’t much distinction between a linux C dev and a full linux dev, and it’s no big deal. But the goal appears to be to use it more extensively than that.
To me, the entire approach to this is backwards. Rather than trying to force a preconceived solution, turn it around and say to linux devs “Look, memory safety is an issue in linux. What can be done about it?” Let them determine the solution. That’s when you can make the case for rust. (Though you probably won’t be successful if you keep blowing off the concerns of linux devs.)
> I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix. This is why I want to work on multi-kernel NixOS — I want to make this threat as credible as possible. If ever new kennel requires one to switch to an entirely different user land arbitrarily, they're just imposing stupid switch…
> on multi-kernel NixOS Is this something people have been working on, or is this "just" something on your personal todo list? Maybe only tangentially related, but I have been pretty excited about https://spectrum-os.org/
https://spectrum-os.org/ is very cool too!
> Spectrum will, for now, be a Linux-based system, with packages from Nixpkgs but not derived from NixOS.
This is because NixOS is not actually so flexible/extensible. I hope multi-kernel NixOS helps with that in general
Earlier quoted context omitted.
Because if they do something that requires changes to the Rust code, the Rust for Linux folks will take care of it for them. This has been explained repeatedly.
Sure. But then that linux dev is no longer a linux dev. They are a linux C dev who needs to find a full linux dev, explain the issue, and get them to handle it. Now, if rust is only in a few corners of linux, then there isn’t much distinction between a linux C dev and a full linux dev, and it’s no big deal. But the goal appears to be to use it more extensively than that. To me, the entire approach to this is backward…
Earlier quoted context omitted.
Because if they do something that requires changes to the Rust code, the Rust for Linux folks will take care of it for them. This has been explained repeatedly.
Sure. But then that linux dev is no longer a linux dev. They are a linux C dev who needs to find a full linux dev, explain the issue, and get them to handle it. Now, if rust is only in a few corners of linux, then there isn’t much distinction between a linux C dev and a full linux dev, and it’s no big deal. But the goal appears to be to use it more extensively than that. To me, the entire approach to this is backward…