Let's see what Linus thinks about this.
Probably the same as the author of curl. Something along the lines of "Yes, sure, our project is open source so fork it and go ahead".
"And don't call it Linux because I own the trademark".
Rewrite Linux Kernel in Rust?
111–120 of 133 posts
Re: Rewrite Linux Kernel in Rust?
#112Earlier quoted context omitted.
I've seen assembly languages that do separate target and source operands with an = sign. So you would write that something like: mov eax = 5 and use a similar style for other things, like: add eax = ebx, ecx This is very nice and clear. But it only really works for three-address assembly languages, i.e., where the target register may be different from the sources. In classical x86, the target of an add is identical t…
> nice and clear Looks absolutely horrible to me, why not simply eax = ebx + ecx ?
+1. Make it look more like a severely restricted version of C.
Re: Rewrite Linux Kernel in Rust?
#113This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.
If there were a fork and the fork were to gain momentum it might be not be up to Linus. A project like this might attract new developers because it might be less intimidating than joining the Linux kernel proper. There would also be the attraction of learning Rust in a very real world context. edit:s/in/it
"A project like this might attract new developers because it might be less intimidating than joining the Linux kernel proper."
Quite possible, but for the new project to be successful, existing _users_ will have to see clear benefits. The only way I can see those "new developers, using Rust" make a better product than "current developers with sometimes decades of experience, using C" if those experienced developers currently create lots of ownership related bugs.
IMO, _any_ argument claiming the way forward is a (partial) rewrite in Rust should start with some estimate of the number of ownership related bugs in the current code base.
Re: Rewrite Linux Kernel in Rust?
#114Earlier quoted context omitted.
I've seen assembly languages that do separate target and source operands with an = sign. So you would write that something like: mov eax = 5 and use a similar style for other things, like: add eax = ebx, ecx This is very nice and clear. But it only really works for three-address assembly languages, i.e., where the target register may be different from the sources. In classical x86, the target of an add is identical t…
> nice and clear Looks absolutely horrible to me, why not simply eax = ebx + ecx ?
I guess because there's no simple infix operator for every operation implemented by the machine. Also, the addition may be floating-point or 32, 16, or 8 bit, signed or unsigned, possibly vectorized. An opcode is a good place to express these things.
Re: Rewrite Linux Kernel in Rust?
#115>Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when the resulting code has a lifetime of few months until it won't compile and start breaking everywhere.
> C code compiles fine after decades Early C code doesn't compile on modern systems at all. Speaking of early C code, every vendor had their own version. C standardization had to go a long way. Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when…
> Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms.
Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.
Re: Rewrite Linux Kernel in Rust?
#116Earlier quoted context omitted.
> nice and clear Looks absolutely horrible to me, why not simply eax = ebx + ecx ?
I guess because there's no simple infix operator for every operation implemented by the machine. Also, the addition may be floating-point or 32, 16, or 8 bit, signed or unsigned, possibly vectorized. An opcode is a good place to express these things.
Opcodes are fine, no one is saying everything has to be expressed as an operator. I'd like to see more of a C/C++ intrinsics syntax, but with total control over the order of instructions and register allocation. Basically same power as assembly, syntax close to intrinsics, but you tell it which registers to use, and there's one instruction per line, and they're executed exactly as you write them, with no creativity on the part of the compiler.
Re: Rewrite Linux Kernel in Rust?
#117Earlier quoted context omitted.
pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?
It's a common misconception that GC languages must be slower than languages without one. Where that misconception probably comes from is that it's pretty easy to write performant code in C, and hard to write terribly slow code, whereas in languages with GC in some instances you can do as good or better but it's often harder. These days if you're comparing Java and C++, it's not unusual for the Java code to be faster.…
You mentioned the determinism tradeoff, which is one the gamedev community talks about endlessly. I'm no low-level expert, but my understanding is that determinism isn't all you lose.
My understanding is that the big tradeoff is against RAM usage. You can have relatively-low-RAM-usage JVM programs, and you can have fast JVM programs, but you usually cannot have both. Keeping the total cost of GC low is done by amortizing the cost over more run-time, which means running less GC often, which means accumulating more garbage between runs. I mean, compared to the insanity that is an Electron app or something, it's no big deal, but this means that the pre-Rust tradeoff is something like "Memory safety, small memory footprint, fast running time: choose two". (I want to emphasize that I'm repeating hearsay, not reporting from my own knowledge.)
Also, it's probably a minor point, but JVM startup time is terrible compared to a native binary. Many many programs don't care about this, but some do.
Code size (not counting the JVM) might well be improved, but if this is the only JVM code on this machine and you need to pay that cost, that's a tradeoff too.
Re: Rewrite Linux Kernel in Rust?
#118Earlier quoted context omitted.
OT: I really like the word "ensafen", and I'm totally going to borrow it for future use
It's a perfectly cromulent word, and embiggens every sentence and phrase that includes it.
Embiggens? I think the point of the word is to debigulate some sentences. I would say that it embetters phrases that include it; maybe that's what you meant.
Re: Rewrite Linux Kernel in Rust?
#119Earlier quoted context omitted.
The key for such a project being successful would be to set expectations low in defining what success was. Something like "a proof of concept of an experiment to rewrite small amounts of the Linux kernel in Rust". One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux. Linus has stated that he isn't particularly interested in security bugs. Other people tak…
"One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux" That's already hard given how many commits go into Linux. One must always remember it's not just some volunteer project: most of the commits are by paid programmers working at companies. That's where the labor comes from. You'd need a lot of volunteers to keep up with the paid programmers. Even Linux…
So we agree about something at least ;-)
Slight tangent: I started my programming career in 1989.
The product was Parasolid and the language was AGA - a C inspired language that preceded C++.
I vaguely remember the following extensions:
* built in logging with Undo
* overloaded operators leading to vector and interval types that worked better than C++
* a proper module system
Re: Rewrite Linux Kernel in Rust?
#120Earlier quoted context omitted.
The key for such a project being successful would be to set expectations low in defining what success was. Something like "a proof of concept of an experiment to rewrite small amounts of the Linux kernel in Rust". One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux. Linus has stated that he isn't particularly interested in security bugs. Other people tak…
"One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux" That's already hard given how many commits go into Linux. One must always remember it's not just some volunteer project: most of the commits are by paid programmers working at companies. That's where the labor comes from. You'd need a lot of volunteers to keep up with the paid programmers. Even Linux…
>It could be revived and improved if people wanted. It got nowhere with C programmers, though, in the past.
I guess the market will decide.
Ransomware will explode in the next few years.
If a big enough exploit gets pinned on Linux then sentiment could change and there could be a well-funded hard fork.
edit: saw this quoted on Twitter today (but can't recall where):
“Only a crisis - actual or perceived - produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes the politically inevitable.”
Milton Freidman
http://www.goodreads.com/quotes/110844-only-a-crisis---actua...