|
Okay, so here's a slightly delayed summary (had to fix some prod issues): - a discussion that the parent commenter took an issue with: "What's software? What's hardware? It's hard to answer that."
- essentially, an OS is a program that abstracts away hardware
- kernel: a piece of the OS that runs with the highest level of privileges, but only a part of the OS
- the OS as a whole includes libraries, daemons etc.
- expansion on the history of OSes and how we got to where we are now
- developing OSes isn't always lucrative, you don't hear about the innovative companies that didn't survive
- mentions of https://en.wikipedia.org/wiki/Second-system_effect
- a brief story about how trying to outsource the PL/I compiler wasn't a good idea
- the Unix approach was way more organic in comparison to PL/I, less of a waterfall
- a little bit about programming languages
- a little bit about the history of C and how it wasn't created the exact time as Unix
- some words about languages that now seem esoteric, like https://en.wikipedia.org/wiki/Language_H
- thoughts on the imporance of macros and the C preprocessor
- more about OSes in the 1990s
- languages like C++ and Java got more popular
- many of the OSes of the time suffered from the aforementioned second system effort, were overcomplicated
- oftentimes overcomplication also lead to great resource usage with little tangible benefit
- with the arrival of Linux, the C based OSes became more entrenched
- at the same time, the actual languages that focused on the ease of development (Java, Python, Ruby) also gained popularity, though in a different context
- software systems in 2010s
- without a doubt, it's nice to be able to use higher level abstractions
- Node.js got surprisingly popular due to a high-performance runtime with the aforementioned benefits
- Go was also developed, though its garbage collector is mentioned as a problem here, because it makes C interop harder
- a bit of elaboration about GC and the problems with it, how easy it is to have a reference into a huge graph
- essentially, it has its use cases, but at the same time there are problems it's just not suited for (a certain class of software)
- how Bryan got started with Rust and a bit about it
- initially he didn't want to go back to C++, because of a variety of past issues
- he got increasingly interested in Rust and its potential benefits
- curiously, there is a category of people who are curious about Rust, but haven't actually written any
- it's nice to have a language that's built around safety, parallelism and speed
- more about Rust
- its ownership system allows for the power of garbage collection, but the performance of manual memory management
- being able to determine when a memory object is no longer in use and being able to do so statically is like a super power
- the compiler itself just feels really *friendly* by pointing you to directly where the problems are
- composing software becomes easier all of the sudden, when compared to C, since it's hard to get it right there
- going back to C or porting C software can actually be somewhat difficult because of unclear ownership
- some of the Rust performance gains are actually from good implementation of language internals, like them using b-trees
- algebraic types are also nice to have and the FFI in Rust is really well thought out
- there's also the "unsafe" keyword which allows loosening the security guarantees when necessary
- about OS development and Rust
- no-one cares about how easy OS components were to develop or how long they took to develop, everyone just wants things to work
- a bit of information about having to deal with failed memory allocations, design discussions, language features etc.
- lots of OS projects out there in Rust
- however, writing your own OS essentially forsakes Linux binary compatibility, so a lot of software won't run anymore
- you have to consider what is the actual advantage of rewriting existing software in Rust, safety alone might not be enough
- a callback to the fact that an OS is more than just the kernel! you could rewrite systemd in Rust and other pieces of software, however not all software is a good candidate for being rewritten
- firmware in user space (e.g. OpenBMC) could probably benefit greatly from Rust as well, in addition to just having open software in the first place
tl;dr - Rust is promising, yet isn't a silver bullet. That said, there are certainly domains and perhaps particular OS components which could benefit from the safety that Rust provides, especially because its performance is also good! |
After watching his talk, I wanted to figure out how a computer, say a Raspberry PI, _really_ works. And build an operating system for it. Maybe in Rust?
[0] https://www.usenix.org/conference/osdi21/presentation/fri-ke...