91–100 of 133 posts
>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.
Earlier quoted context omitted.
What's Rust like in ... Isn't that less a question of Rust (which due to its affine types, should be usable for generating code with predictable performance) but of compilers? It should be possible to write a Rust compiler that optimises for predictable performance at the cost of speed.
That's a fair point. I don't quite follow why speed needs to be sacrificed to get predictable performance though. And I don't know about writing a (whole new?!) Rust compiler (!) - if the current Rust compiler wouldn't be a good fit for this purpose, well, I definitely don't have the resources to anything about that, considering the unbelievable amount of attention to detail and wrangling that's gone into getting rus…
>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.
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 switching from 32-bit to 64-bit platforms.
Oh, and int32_t was introduced in C99, which is not exactly "decades" ago, but admittedly that was 18 years ago. However, I wouldn't bet on portability of any code older than that, unless the authors of that C code were extremely careful and anticipatory. But then, with enough effort (and perhaps code generation), you can create portable code in any language.
Rust skips all that mess, by having a clear experimental phase in the 0.x versions. It became stable with a clear commitment to backwards compatibility since 1.0, which was released in 2015.
Earlier quoted context omitted.
This does raise the question: which languages other than AT&T assembly put the value first?
AT&T syntax puts the operator first, not the value. AT&T is Verb Subject Object. Intel is alien Verb Object Subject. Many kinds of S expressions result in similar code. That would mean Lisp derivatives.
It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it? Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel i…
Please refrain from using strawman arguments. Nobody proposed to rewrite everything at once. This is what TFA actually wrote:
| So the idea would rather be to rewrite pieces of the Linux kernel in Rust, so the change can be incremental and one doesn’t need to rewrite the whole OS
See also: https://news.ycombinator.com/item?id=14479559
(It puzzles me what this strawman was good for, given that the remaining arguments are independent from the "too big" argument anyway.)
>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.
Rust has had backward compatibility since 1.0: https://blog.rust-lang.org/2014/10/30/Stability.html
Earlier quoted context omitted.
Rust has had backward compatibility since 1.0: https://blog.rust-lang.org/2014/10/30/Stability.html
Servo and most projects use nightly which breaks it all the time.
Earlier quoted context omitted.
You're referring to microkernel/nanokernel architectures. Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring. Linus is also noted in this thread as not being interested in security issues. I do agree with you…
Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust. I still think that QubesOS is taking the right approach. Initially assume hardware…
QNX did this quite successfully; you could kill and reload e.g. a buggy network or disk driver. All that on top of being a realtime OS.
Earlier quoted context omitted.
Servo and most projects use nightly which breaks it all the time.
But you wrote "Rust has no backward compatibility" who cares what libraries/projects do?
Earlier quoted context omitted.
Makes you wonder why not write it as e.g. "eax mov 5" or even "eax = 5".
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…
Looks absolutely horrible to me, why not simply
eax = ebx + ecx
?