10 ms·
Is It Time to Rewrite the Operating System in Rust? [video]
- Redoubts 8y agoBy Bryan Cantrill, which makes it totally worth it.
- bullen 8y agoHe's the programmer equivalent of a stand-up comedian!
- PhantomBKB 8y agoOh god
- steveklabnik 8y agoYou should watch the talk.
- ncmncm 8y agoSince they started putting Rust in Firefox, it crashes literally hundreds of times a day. (Usually the crashes are in subprocesses. Not always.) Is Rust to blame? I don't know. But I would rather see some attention to the crashes than any new features, or new OSes, right at the moment.
- stouset 8y agoOn the flip side, I switched to Firefox once the first “quantum” version was released (62?) and I haven’t experienced a single crash. Then again, I don’t remember seeing a crash in either Safari or Chrome in ages, but the point being that Firefox seems at least as stable as it’s competition.
- tasty_freeze 8y agoI have three different (windows) machines which use firefox daily, and I get a subprocess crash less than once a month.
- majewsky 8y agoHow does a subprocess crash look like? Not sure if I've ever seen one.
- tialaramex 8y agoFirefox will tell you that the tab you opened or are looking at or whatever has crashed, it will apologise and offer to try loading it again. In my experience that usually works, but in principle of course it might not. I've used Mozilla M-series browsers back at the turn of the century and we crashed those "hundreds of times per day" but that's because we were DOM mangling back when that was new and exciting, not how everything works in every popular web page. Also the M-series weren't finished, hence the milestone number instead of a release version.
- lytedev 8y agoIf you're truly seeing crashes "literally hundreds of times per day", I'm sure the Firefox team would appreciate the information you have! I suspect that the problem is not Firefox itself, which I put through the ringer daily and am extremely happy with it.
- beatgammit 8y agoUsually this is graphics driver related, but there could definitely be some bugs that OP's unique usage triggers.
- tdurden 8y agoI find it hard to believe that you continue using software that crashes "literally hundreds of times a day".
- user5994461 8y agoDon't we all use software that crash every day? Maybe not a hundred times but more than zero.
- xiphias2 8y agoOf course, for me it's the Julia interpreter that crashes all the time. After I fix my program, and write some new code it crashes again, but differently. But for programs that I haven't written: no, they generally don't crash too often.
- zamadatix 8y agoErr... no? That would be ridiculously annoying. If you're having issues every day it's either time to find new software or new hardware.
- tdurden 8y agoI don't, but I can see how one could put up with it for a critical piece of software with no alternatives. In this case though, we are talking about hundreds of crashes a day for software that has multiple alternatives.
- littlestymaar 8y agoFor a “critical piece of software with no alternatives” you could imagine having one to a few crashes a day, but not hundreds of them. Using such a buggy software for “critical” stuff would be close to insanity ;).
- deleted 8y ago[deleted]
- 8y ago
- arghwhat 8y agoRust is not Firefox. Rust does not disallow crashes, it disallows that your code will run in unsafe manners, either with compile-time errors or runtime panics (with some exceptions for `unsafe` code). Browsers are to some extend more complicated than the operating system they run on, so it's no surprise that there are bugs in there. If you experience crashes, please do submit the crash reports, and if you already know what the cause of the crash is, please file a bug on bugzilla. Thanks!
- robin_reala 8y agoit disallows that your code will run in unsafe manners To be picky, it specifically allows unsafe code as long as it’s marked up as such.
- smolder 8y agoIf that's really the case, I think you have a hardware stability problem. Perhaps firefox is using AVX instructions or doing something else your system doesn't like.
- karmakaze 8y agoStart at 29:31 to skip past 'what is an os?' history lesson. > Go, JavaScript and others are garbage collected, making interacting with C either impossible or excruciatingly slow. I don't see why interacting with C is a requirement. Android (SDK) could be considered an OS that doesn't have this either.
- ldng 8y agoHumm, I don't think you can equal an SDK to an OS. Before getting this high level, you really have to start with a kernel to handle/manage device. And this as a lot of constraint that yous simply can not fulfill with a garbage collected language. edit: I wasn't at the point you mentioned yet. Well, IMHO, it is not just the GC, it is not having access to native pointer prevent you to implement algorithm that are keys in term of performance for a kernel. IIUC more savvy dev than me it might not even be possible to implement a kernel in Rust without "unsafe" (which give you access to those raw pointers) Happy to be proven wrong though.
- littlestymaar 8y agoAlso, Android is more than the SDK: almost every game running on this platform uses the NDK.
- ldng 8y agoThe NDK is a wrapper above a slew of C/C++ lib and those are not garbage collected. It make me think of PHP. The language is actually really slow but because most of it's standard library are wrappers around actual C library, a lot of people perceive it as a really fast language. But compared to raw C/C++/Rust, it is still slow.
- pjmlp 8y agoThe NDK is very limited, its sole purpose is for 3D, real time audio, ML and porting ISO C and ISO C++ code into Android, everything else requires JNI, even reading files outside the APK sandbox.
- jeffrallen 8y agoNo. (https://en.m.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.m.wikipedia.org/wiki/Betteridge%27s_law_of_headli...)
- littlestymaar 8y agoIt's literally the first slide after the title!
- jeffrallen 8y agoMy comment was aimed at typical HN readers who cannot be bothered to visit the link...
- Animats 8y agoIs there a summary of this hour-long video?
- steveklabnik 8y agoMy summary (I saw the talk live, this is from memory): Some history of OSes, a bit about Rust. Is it worth re-writing the OS? No, but what about incorporating Rust into OSes, instead of creating a new one from whole cloth? There’s three approaches: in the kernel? Probably not worth it. In userland? Probably worth it. For firmware? Probably worth it.
- drpixie 8y agoThanks - I'm completely over video, when I can read a little text at my own speed, and skim much more effectively. Video is reallyn inefficient, both in bytes and in my time.
- chubot 8y agoHere's my summary from 2 months ago: https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_system_rust#c_gnp1gb https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_syst... Overall I was sort of disappointed in this video. I would rather hear about someone writing their OWN code in Rust. I watched one of Cantrill's previous talks about this which I liked, so I watched this one too. It's not that interesting to hear "well Rust has problems for MY domain (kernels), but OTHER people should write their code in Rust (user services and firmware). There's an obvious asymmetry there, because you know all about the problems in your own domain, but you're less familiar with the problems of other domains (e.g. ones that require a lot of async code, a lot of text parsing, etc.) ----- I just watched this video. I liked the part about failed C++ operating systems from the early 90’s (Apple’s Copland, an effort from Sun, and Taligent). Overall he’s excited by Rust, but points out some problems with using it for kernel development: - Multiply-owned data structures are all over Unix kernels, and Rust’s ownership system doesn’t like those. (i.e. the doubly linked list problem) - Rust doesn’t allow you to handle memory allocation failure. This is being worked on? I didn’t know this about Rust and it seems odd for a low level language. He says that instead of kernel development, Rust could be used for: - user-level services like systemd, or - firmware. This doesn’t seem like anything more than a wish though. I don’t see that Rust really shines in those areas. - I think you could probably write systemd in Go. I don’t see that Rust has any advantage there. Whereas a kernel in Go has some obvious downsides (I know it’s been tried). - Rewriting firmware in Rust sounds nice, but I don’t think vendors will do it. They have enough problems writing decent C, and they don’t write open source code. He is wishing for them to write Rust and release it as open source, but I’m not optimistic about either of those things. I think the kernel and the browser are where Rust is interesting – when you need both performance and memory safety. I’m not really excited about Rust for other applications like web services, i.e. doing the job that Go, Python, or Ruby can do. So it does seem unfortunate that there are still some open problems with using Rust for the kernel. He also points out the many nascent Rust OSes kernels, and the fact that they are “from scratch” systems, i.e. not compatible. I agree that you need a compatible kernel to have any hope of adoption.
- xemoka 8y agoPrior comments: https://news.ycombinator.com/item?id=18405804 https://news.ycombinator.com/item?id=18405804
- deleted 8y ago[deleted]
- Chyzwar 8y agoI disagree with the suggested approach of gradual introductions of rust, this would require kernel developers to master both languages and introduce mismatch anyway. I think before we jump into writing OS in rust we should first understand what wrong with current dominant Linux. I think we could make a major revision on how computers are built and how should be OS architected to last for another few decades.
- adamnemecek 8y ago> I think before we jump into writing OS in rust we should first understand what wrong with current dominant Linux. Lack of an async API. Bad IPC primitives (how many are there? They are all terrible). The whole "everything is a file" idea. Real time audio. Bash. File systems. The process vs thread distinction. Package management. Permissions. Security model. Scheduler. General cruft. X Server. Battery life. OOM killer. I would much rather hack on a Rust kernel than C.
- AnIdiotOnTheNet 8y agoThere is really just so much that could be done better now that we have decades of hindsight. Sadly, I doubt it'll happen because supporting even a reasonable amount of existing hardware has become an exercise in futility. Theoretically one could start with a well defined subset of hardware, but that would make growth extremely difficult unless that hardware was both inexpensive and common enough for anyone to acquire it easily while also being good enough to cover a lot of use cases (and your OS amazing enough that people would willingly sacrifice to use it). A Raspberry Pi fits this requirement pretty well, but you still don't see useful new OSs on it do you?
- adamnemecek 8y agoRaspberry Pi is a bad target because you are unlikely to make money with your OS and fundamentally you need that to turn the OS into anything serious. The advantage of Rust is that you can split things into modular code bases. Redox is split very nicely. I think that one could start a hosting company and write a hypervisor in Rust.
- pornel 8y agoAs someone who's rewritten several things in Rust, and even written C to Rust "transpiler", I totally agree with the approach of keeping working C code as-is, and switching to Rust for new code. Rewrites from scratch are time consuming, and at risk of second system syndrome (especially when you suddenly have all the shiny new language features). Direct 1:1 rewrites are underwhelming. After the initial C to Rust pass you end up with the same program, with a C-like architecture, and all you've done is replaced gcc with a slower rustc. But wrapping a C implementation in a Rust API works great. You can translate C's implied ownership semantics into explicit Rust types. You can wrap all these C structs/handles with their init and free functions into RAII that never leaks. It's something you can do in days, not months to years. You keep a fully working program at all times. You benefit from Rust for new development, and you can gradually refactor C out of it when and where it's sensible to do so.
- scoutt 8y agoWrite from scratch, maybe. Rewrite, I don't think it will happen anytime soon. In fact, the more time it passes, the more code needs to be rewritten. Regarding firmware, if the talk was about bare-metal embedded development, then I think Rust is the solution to a problem that no one has. Since the food on my table comes from firmware development, I passed several days trying to understand the reasons to move to the approach described here: http://blog.japaric.io/brave-new-io/ http://blog.japaric.io/brave-new-io/ (Embedded in Rust blog, great reading BTW). But found little. It's a nice toy but it may be too much. If that is the trend, then I think Rust for Embedded is the answer to a question no one asked, because in my work, if I need to set a bit into a register, I have to be sure it's fking set; not playing around "just because it may be problematic".
- blub 8y agoI hope this idea of taking the complexity of memory management and encoding it in the language syntax is an evolutionary dead end, because that Rust code looks genuinely painful. Otherwise I agree that a rewrite is nonsense. In these kinds of huge projects, only a gradual solution that can co-exist with the existing code base could work, if anything. An example would be tightening the safety of the existing code through static analysis of the kind offered by Frama-C.
- pjmlp 8y agoThe problem with static analysis of the kind offered by Frama-C, is that many developers not even at gunpoint bother to use them.
- deleted 8y ago[deleted]
- xuesj 8y agoFreedom is not free, what people make what ruler.
- OJFord 8y agoRedox (an OS written in rust) has a related page: https://doc.redox-os.org/book/introduction/will_redox_replace_linux.html https://doc.redox-os.org/book/introduction/will_redox_replac...