18 ms·
Redox – A Unix-Like Operating System Written in Rust
- adamnemecek 8y agoRedox is cool but I'm pumped for the OS' that really take advantage of Rust to create new architectures.
- k__ 8y agoLike?
- sam0x17 8y agoAs in something different from unix I take it
- stcredzero 8y agoIf an operating system was built to run lambdas instead of processes, what would that look like?
- ASipos 8y agoIf K-A-T doesn't spell 'cat', what does it spell?
- Crespyl 8y ago'kat'
- nixpulvis 8y agoWhat is a lambda to you in this case? That lambda will need to be scheduled, it will need to maintain it's scope... All the same general issues could exist. There have been plenty of machines that simply run functions, in fact before there was things we call OSes today, the machines that ran the code would typically not have an notion of time sharing, and would map even more closely to a pure lambda evaluator. Without specifics about what differences you mean, lambda = function = process = thread = fiber = service = worker = ...
- stcredzero 8y agoWhat is a lambda to you in this case? Pure functions. That lambda will need to be scheduled, it will need to maintain it's scope... All the same general issues could exist. But no users would have to be able to start processes. Instead, lambdas could be associated with persistent storage of state, and processes would be started by the OS to apply the lambdas in a simulation loop, but users wouldn't directly start processes. Perhaps thinking of those as processes isn't quite right either.
- nixpulvis 8y agoThe only truly pure functions exist in the imaginary world of mathematics, if you even believe that. But I think I kinda get your point, but would challenge you to think about this issue with the frame of mind of access control and permissions a bit. I think you'll find the need for some kind of process like task. Maybe not...
- stcredzero 8y agoThe only truly pure functions exist in the imaginary world of mathematics, if you even believe that. Note I already mentioned persistent stores of state. I think you'll find the need for some kind of process like task. Maybe not... Maybe re-read. I've already said that there would be a process like task. Lambdas will need to be associated with state. Users won't have to start processes. Instead, processes will be more like processors.
- macintux 8y agoThis sounds like the Erlang VM.
- stcredzero 8y agoI'll take that as positive feedback.
- chc4 8y ago
- someguydave 8y agoIt would look like a LISP machine from Symbolics...
- abecedarius 8y ago"A security kernel based on the lambda calculus" http://mumble.net/~jar/pubs/secureos/ http://mumble.net/~jar/pubs/secureos/ http://cap-lore.com/CapTheory/upenn/ http://cap-lore.com/CapTheory/upenn/
- nixpulvis 8y agoI feel like a new fresh look at what UNIX is today could be valuable. I wouldn't want to give up a lot of the philosophy around it. Redox does in fact do this in a number of places, for example I think the expansion on "everything is a file" [1] is a pretty awesome idea. [1]: https://doc.redox-os.org/book/design/url_scheme_resource/everything_is_a_url.html https://doc.redox-os.org/book/design/url_scheme_resource/eve...
- sam0x17 8y agoI'd love to see a "there are no paths, file system is a db" like it was originally rumored Vista was going to be. I'd also love to see more opinionated OS integration e.g. per-application volume sliders, better file system search indexing, real-time built-in file and directory watching API that can be blocking or non-blocking, standardized storage of program files instead of installed app locations being ambiguous, standardized system and app settings via a neat API, etc., etc., an easy and sane git-based package manager, etc
- GordonS 8y agoWindows 10 does per-application volume control. Chrome OS has a fixed app install location, as does Windows 10 in 'S' mode (since you can only install store apps). I remember being intrigued by the database-as-filesystem idea when it was first touted - has any OS actually implemented this? I'd be interested to see how it works in practice.
- TickleSteve 8y ago"pick" https://en.wikipedia.org/wiki/Pick_operating_system https://en.wikipedia.org/wiki/Pick_operating_system Everything old is new again... this was from the mid-60s and was relatively popular for its time.
- gvx 8y agoVery interesting. The one thing that stood out to me was this, though: > It is named after one of its developers, Dick Pick. What an unfortunate name.
- dralley 8y agoThat only makes things more confusing because Redox is explicitly not a traditional Unix. It's more like Plan9, except it goes even further than Plan9 in few places, and things like the Ion shell in Redox don't attempt to be Posix compatible.
- pjmlp 8y agoWhat about comparing Redox with Inferno instead? The actual end of the line for UNIX improvements done by the original designers. I never get the mistic around the middle stop instead of the end of the line.
- adamnemecek 8y ago* entirely async api * more light weight memory manager (possible thanks to borrow checker) * GPU first OS * a better shell. I know I can run whatever shell I want on unix but a better shell being native would go far.
- nixpulvis 8y agoI agree with the first two points, not sure how Rust and GPUs are really related yet. I mean I know you can bind into GL/etc libs, but there's something more profound about Rust's type system, and the parallelism / memory model of a GPU (or CPU/heterogeneous computation in general). AFAIK, there's no way to write GPU shader code that shares the static analysis from the Rust CPU code. It would be very interesting to be able to talk about the move semantics across the full modern computing architecture. If anyone knows work being done in this area I'd be curious to read more personally. As for a better shell, I also completely agree, but I'm not sure it needs to break POSIX. Shameless little plug, I recently started a shell in Rust myself: https://github.com/nixpulvis/oursh https://github.com/nixpulvis/oursh
- eridius 8y agoAs a fish user myself, I would love to see a new shell that retains many of the UI features of fish (like the excellent autocompletion behavior while typing) but with an actual usable modern fast scripting language. POSIX compatibility at the scripting layer is beneficial for being able to run existing shell scripts, but the sh scripting language sucks in many ways. What I'd really like to have is a shell that supports both a POSIX compatibility mode for running existing scripts, alongside a more powerful and modern scripting language for use in writing scripts targeting the new shell directly. I'm not sure how to identify which mode an arbitrary script should run in though, or which mode should be used at the command line.
- nixpulvis 8y agoI've started allowing just that `{#! }` also as a means to write other languages inside the shell syntax. Take a look at: https://nixpulvis.com/oursh/oursh/program/index.html https://nixpulvis.com/oursh/oursh/program/index.html
- protomyth 8y agoMy guess is someone will try to have an OS based on containers of Web Assembly apps. There are quite a few APIs that have been built over the years that are familiar to programmers. I do believe this will cut down on the pain of having to new develop system level tools to manage such a beast.
- bluejekyll 8y agohttps://github.com/nebulet/nebulet https://github.com/nebulet/nebulet "Nebulet is a microkernel that executes WebAssembly modules in ring 0 and a single address space to increase performance. This allows for low context-switch overhead, syscalls just being function calls, and exotic optimizations that simply would not be possible on conventional operating systems. The WebAssembly is verified, and due to a trick used to optimize out bounds-checking, unable to even represent the act of writing or reading outside its assigned linear memory."
- zaarn 8y agoWebAssembly has a few more advantages when deployed as part of the kernel; you can run things in ring 0. Even better, you can transparently remap things in memory. And even better than, you can realize IPC as a simple function pointer. Safely. Of course, you can't have everything as WebAssembly, some core drivers will need to run some critical machine code, but those could be tightly enough integrated that the overhead is almost zero (ie, by using WA imports you can turn this into a function call overhead)
- johannes1234321 8y agoThe issue with such an OS is that there aren't won't be any libraries and tools. So the OS vendor might need a custom shell, custom utilities, custom libraries for everything ... or they offer POSIX-like APIs. One area where one can see this is IncludeOS - they had their custom APIs for a long time to leverage their architecture, but are now focussed on providing POSIX compatibility ... and that's only for single purpose unikernel systems. If the OS should also be universal this is even more of a problem. (Especially if you also want a graphical desktop ...)
- nixpulvis 8y agoDon't even need to implement POSIX if you just emulate another OS inside, this seems to be a pretty viable solution for some of the cases. I'm more concerned with drivers/firmware, which could be handled the same way, but seems less appropriate.
- adamnemecek 8y ago> The issue with such an OS is that there aren't won't be any libraries and tools. This might not be as big of a deal. Rust increases your productivity quite a bit and I'm really impressed with the pace of progress in the community. I can imagine that new, better & more integrated tools will be made.
- AnIdiotOnTheNet 8y agoWith that attitude you'll never be able to ditch legacy cruft, and there's quite a lot of it in POSIX. I agree with the other poster that a compatibility layer in the form of virtualization and/or emulation should be sufficient, as long as your new OS brings something to the table that's desirable. Shunt the legacy crap off into its own contained environment and build a nice new clean one for new stuff to use.
- nixpulvis 8y agoI still think there are a plenty of reasons to support POSIX in many places. As someone who's been running fish for a while, I can appreciate the common ground it provides across the current UNIX ecosystem, but it's not like translating a bash script to fish is impossible. There should always be a supported standard, but there should be nothing forcing you too it. This is the freedom we need to demand of our OSes.
- empath75 8y agoNot really relevant to rust, but if you squint, Kubernetes is basically an operating system.
- paavoova 8y agoRedox is still very much a prototype and shows you can't simply slap "safe" Rust together and magically conjure up a kernel and OS: https://gitlab.redox-os.org/redox-os/redox/issues/1136 https://gitlab.redox-os.org/redox-os/redox/issues/1136
- gpm 8y agoSo, no one anywhere is claiming you can write a kernel in purely safe code. It fundamentally needs to access arbitrary memory locations which is unsafe. That said, I don't think any of the issues in that thread are related to unsafety. It's perfectly safe to panic. None of those bugs are memory corruption, arbitrary code execution, or so on, which is what safety tries to protect against.
- paavoova 8y agoBut people are claiming you can't write a safe kernel in C, and point out safe languages which should be adopted in its place. This misses the point that, just like the theoretical safety of C is 100% safe, the theoretical safety of Rust as a low-level language is zero. Those are all bugs produced essentially on request. That doesn't bode well for the security and robustness of the project. The end user doesn't care whether the class of bug is memory related or whatever else if the end consequences are the same. Despite having the benefit of safety and the decreased burden on the programmer this offers, bugs still abound in Redox, which points to it being written in Rust as incidental at best.
- empath75 8y agoNobody has ever said that it is impossible to write buggy code in Rust. It merely makes security guarantees about certain classes of bugs, and the use of unsafe code blocks makes it easier to isolate cases where those classes of bugs can occur.
- roca 8y agoDon't gloss over the distinction between security and robustness. The consequences of panics and memory corruption are very much NOT the same. The former means a reboot, which is annoying; the latter means corrupted or exfiltrated data or a hostile takeover of the system.
- nixpulvis 8y agoRedox is a really cool project. I haven't tried running it in a while though. Last time I tried it I couldn't get it running on real hardware, maybe things have gotten better there. Either way, if you find Redox interesting, I bet you'll find https://os.phil-opp.com/ https://os.phil-opp.com/ interesting too. It's a much less full fledged project, but the blog posts are a great way to learn about Rust and OSes at the same time.
- robertsd247 8y agoI think this is awesome but how many more Linux OS' do we need? The community needs to come together and hammer out the end user desktop issues and get a unified Linux out to the unwashed masses. Windows 10 can't be the only future.
- snazz 8y agoRedox isn’t Linux. It has its own kernel that you can read about in the docs.
- AnIdiotOnTheNet 8y agoI get where the post is coming from though. Redox decides to write a brand new kernel with some interesting ideas, but then basically just slaps a UNIX-like userland on top of it.
- empath75 8y agoPath of least resistance -- but it seems like you can write a non-unix-like userland on top of it if you want to.
- weberc2 8y agoWhat's wrong with changing a few things at a time? Why should this project attempt to solve every problem at once? I can't imagine that resulting in a usable system, at least not in the next decade.
- AnIdiotOnTheNet 8y agoNothing wrong with it really, especially since Redox bills itself as a research OS (at least it did last I checked) and not a contender for replacing desktops. But I still share the original poster's disappointment in yet another UNIX-like system, especially at a time when, in my opinion, Personal Computing and the Desktop in particular are being driven towards extinction.
- 8y ago
- qwerty456127 8y agoWhere can one find lists of hardware and software supported to the date?
- sajattack 8y agoHardware is pretty much just try it and see if it works. Drivers supported are pretty much just what virtualbox/qemu use. https://gitlab.redox-os.org/redox-os/drivers https://gitlab.redox-os.org/redox-os/drivers Things like e1000. Many Thinkpads work. Software list is here https://static.redox-os.org/pkg/x86_64-unknown-redox/ https://static.redox-os.org/pkg/x86_64-unknown-redox/
- Koshkin 8y ago> Unix-Like It has been my impression that one of the advantages of Unix is not having to rewrite the userland each time you write a new kernel or port an existing one to a new platform.
- coliveira 8y agoExactly, there is no sense in trying to write UNIX in another language because it defeats the original goal of the system.
- karr0n 8y agoi guess, that's why it's called unix-LIKE. it's something, people are familiar with and a design that works. good enough, i would say
- chc4 8y agoIt's Unix-like, not a Unix clone. In particular they settled on a "everything is a URL" instead of "everything is a file", with different URIs being delegated to userspace services. It still draws quite a bit from Unix though, and provides a shim translating `/dev/proc` to `proc:` or whatever.
- ori_b 8y agoWell, that's a major imstake -- now I need to know what service I'm talking to, which means that I can't transparently replace my /dev/net with a userspace proxy. Unix half screwed this up, and they took the mistake and perfected it.
- matachuan 8y agoReally cool project! It reminds me of TockOS from SOSP'17 which is also written in Rust but designed for extremely resource-constrained devices.
- moosingin3space 8y agoSerious question: how is this similar to TockOS, other than being written in Rust? TockOS doesn't use an MMU since it's designed for single-address-space applications on microcontrollers.
- imjustsaying 8y agoHas Redox adopted or has plans to adopt a Code of Conduct similar to what the Linux kernel did recently?
- chimpburger 8y agoI hope not
- winklock 8y agoIt adopted the same CoC as the Rust community.
- Animats 8y agoInteresting. Not clear if they got the big lesson of QNX vs. Mach - scheduler and interprocess message coordination is crucial to microkernel performance. The relevant pages of their "book" are blank. I'm trying to find the interprocess communication primitives and can't. Anyone know where that's documented? I notice they put an ELF loader for executables in the kernel. It's better to have the loader outside the kernel. See this Linux vulnerability.[1] They may get there; they don't have shared objects yet. QNX starts up new processes with a canned startup which links to a shared object to do the loading of the executable. So loading runs with the privileges of the thing being loaded, which is safe. They put very few drivers in the kernel - just a serial console. That's good. Like QNX, the boot image contains user-level processes you want run at startup. So you don't need drivers in the kernel to get going. This is good for embedded applications. QNX comes with a boot image builder into which you put what's needed at startup. There's a set of services for disk-based systems which get you a UNIX desktop like environment. But for embedded use, you can build a diskless QNX image with much less. One advantage of a small unchanging kernel is that it can be put in a boot ROM for the life of the machine. This is a win in embedded devices. Any updating is done by loading new processes in userland, not with some super-powerful low level thing that nobody understands and probably relies on security through obscurity. [1] https://nvd.nist.gov/vuln/detail/CVE-2018-6924 https://nvd.nist.gov/vuln/detail/CVE-2018-6924
- saghm 8y ago> They may get there; they don't have shared objects yet. I'm a bit of a novice when it comes to operating system implementation, so I'm not sure if this is a naive question, but how big of a priority is this for an OS written in Rust? By default, Rust statically links everything besides things written in C/C++ (e.g. libc), so would static linking be sufficient for an OS designed to implement everything in Rust?
- nine_k 8y agoSo do you suggest that every executable on the system should be statically linked? (Early Unix was like this, too.) Rust is apparently capable of producing shared libraries: https://doc.rust-lang.org/cargo/reference/manifest.html#building-dynamic-or-static-libraries https://doc.rust-lang.org/cargo/reference/manifest.html#buil...
- marsrover 8y agoI think Redox is cool but I wonder if it not being POSIX compliant is going to cause adoption issues.
- jackpot51 8y agoI am the creator of Redox. We have a somewhat POSIX compliant C library called relibc that supports existing Unix applications.
- rubyn00bie 8y agoIs there like... a joke to the screenshots page being literal pictures of screens? Because I'm dying on the inside.
- steveklabnik 8y agoRunning your own OS on real hardware is an accomplishment.
- rubyn00bie 8y agoI no way am implying or saying it’s not an accomplishment. It’s just the fact they’re literally screenshots I found hilarious/brilliant.
- jayalpha 8y agoSaw it before but did not try it out yet. On a first look I mistook it for Harvey https://harvey-os.org/ https://harvey-os.org/
- snvzz 8y ago>unix-like >microkernel based Aren't these two contradictory? Unix-like would be a classic monolithic design.