11 ms·

Octox: Unix-like OS in Rust inspired by xv6-riscv

190 points by o8vm 3y ago

deleted 3y ago
[deleted]
Santosh83 3y ago
Why does it seem like 80 to 90% of hobby OS projects that are started are "Unix-like?" Don't we already have a huge variety of Unix-like OSes out there? Why not explore new models?
- packetlost 3y ago
  We need more Plan 9-likes! But more seriously, the Unix/POSIX-like OS is a pretty good model, but IMO we could do better, especially in the microkernel front.
  - o8vm 3y ago
    I would like to implement a plan9-like OS someday!
  - bakul 3y ago
    I'd love to see an OS with a Unix API but plan9 like kernel! I will never get around to writing one myself though!
    - jacquesm 3y ago
      I got very close to that.
      - bakul 3y ago
        Which part? Designing or implementing or something else?
        jacquesm 3y ago
        Implementing. I wrote a QnX clone and it has a lot of parallels with plan9.
        sillywalk 3y ago
        Well show it to us :) For a curious OS nerd that sounds cool. Hacker News Cool.
  - boricj 3y ago
    There are a lot of things wrong with plain standard POSIX: - it's hopelessly out of date and incomplete w.r.t. modern expectations - fork() is very problematic for multiple reasons, especially in a modern environment (https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0...) - process management functions take PIDs and not capabilities, which can cause race conditions - POSIX hasn't standardized anything better than poll(), yes it works fine in a hobby context but it's not 1987 anymore (and don't get me started on select(): https://github.com/SerenityOS/serenity/pull/11229 https://github.com/SerenityOS/serenity/pull/11229) - signals are a mess - Unix processes have a huge amount of ambient authority, which is problematic when trying to isolate them (chroot(), https://fuchsia.dev/fuchsia-src/concepts/filesystems/dotdot https://fuchsia.dev/fuchsia-src/concepts/filesystems/dotdot, ...) - the C POSIX library has a lot of cruft while also missing stuff what programmers actually need (for example, POSIX took nearly 6 years to standardize strlcat()/strlcpy(), the process itself starting 17 years after OpenBSD introduced those functions: https://www.austingroupbugs.net/view.php?id=986 https://www.austingroupbugs.net/view.php?id=986) - ... Granted, modern production-grade Unix-like operating systems have extensions to deal with most of these issues (posix_spawn, kqueue, pidfd_open...), but they are often non-standard and can be quite janky at times (dnotify, SIGIO...). It also doesn't fix the huge amount of code out there using the legacy facilities like it's still the 1980s. There are other models out there (Plan 9, Windows, Fuchsia...), but what we really need is to stop putting Unix/POSIX on a pedestal like some holy scripture that shall not be questioned. It's the pinnacle of 1970s operating system designs and it has fossilized so much it's actively turning into oil. Or at the very least, please stop teaching the next generation that fork() is the greatest thing ever. It's a 50 year old hack kept alive through gratuitous amounts of copy-on-write that should've been scrapped the day Unix was ported to computers with virtual memory and paging.
    - yjftsjthsd-h 3y ago
      This feels contradictory; unix isn't good enough, so nobody implements standard unix, but people need to stop putting unix on a pedestal?
      - 3y ago
  - pkphilip 3y ago
    Redox OS implemented in Rust aims to be Plan-9-like: https://www.redox-os.org/faq/#how-redox-is-inspired-by-other-systems https://www.redox-os.org/faq/#how-redox-is-inspired-by-other...
- crickey 3y ago
  What is even Unix-like ? I usually associate it with POSIX but maybe thats naive
  - OJFord 3y ago
    The general design of users, processes, files, etc. It's obviously not that well-defined since it's implicitly 'not Unix', so can diverge. Just anything that's subjectively similar to that OS design.
- nextaccountic 3y ago
  What is an OS good for if not to run programs? You either port existing programs to your API (lots of work) or design the OS with an existing API in mind. Or forget about existing programs and write entirely new programs "Unix-like" describes the second approach, you provide a POSIX API but can have different internals Now, maybe you wanted to have two APIs: one native API for the apps you write, and a translator from another, more popular API to your native API. Sounds like a lot of work when almost all software that will ever run on your OS will the translator
  - vilunov 3y ago
    Often the user-space API limits the design of internals and available features. I for one would like to see the classical hierarchical filesystem gone, but POSIX (and UNIX) at its core is about the filesystem. If you need to run the existing programs, feel free to develop a translation layer, at the same time allowing a new type of OS paradigm to emerge.
    - yjftsjthsd-h 3y ago
      Nobody's stopping you from slapping on a compat layer, and ex. Haiku does that, but it's more work than just being unixy to start with.
    - huhlig 3y ago
      Curious, what would you replace the classic Hierarchical File System with? A flat key value store? We’ve tried that and it’s a nightmare.
      - mike_hearn 3y ago
        Here's a few ideas I've been stockpiling for the day I retire and my wife will hopefully let me just fiddle with operating systems all day. None of these necessarily would work well or make sense, they're just stuff that would be satisfying to explore. NB: All this can be done in userspace with enough hacks. 1. Make strong file typing work well. Filesystems ignore the question of type, leaving it to ad-hoc conventions like extensions. Figuring out what a file really is takes a lot of effort, is often duplicated by apps and the OS and has a long history of introducing security vulnerabilities. There's also no first class notion of "type casting". Format conversion is delegated to an ad-hoc and inconsistent set of tools which you have to learn about and obtain yourself, even though it's a very common need. 2. Unify files and directories. Make open() and read() work on directories. You need (1) for this. A lot of cruft and complexity in computing comes from the fact that most things only understand byte arrays (e.g. http, email attachments...), not directories. Directories have no native serialization in any OS, unless you want to stretch and call DMG a fundamental part of macOS. Instead it's delegated to an ancient set of utilities and "archive" formats. As a consequence a big part of app development has historically been about coming up with use-case specific file formats, many of which are ad hoc pseudo-filesystems. This task is hard and tedious! There are lots of badly designed file formats out there, and my experience is that these days very few devs actually know how to design file formats, which is part of why so much computing has migrated to cloud SaaS (where you ignore files and work only with databases). Many new file formats are just ZIPs. An operating system (or userspace "operating environment") could fix this by redefining some cases that are errors in POSIX today to be well defined operations. For example given a file that has some sort of hierarchical inner structure like a .zip (.jar, .docx), .csv, .json, .java, .css and so on, allow it to be both read as a byte array but also allow you to list it like a directory. Plugins would implement a lossless two-way conversion, and the OS would convert back and forth behind the scenes. So for example you could write: echo red > styles.css/.main-content/background-color and the CSS file would be updated. Likewise, you could do: mkdir "Fun Project" curl --post -d "Fun Project" https://whatever.com/cgi-bin/receive-directory The trick here is to try and retain compatibility with as much software as possible whilst meaningfully upgrading it with new functionality. Redefining error cases is one way to do this (because you have some confidence they won't be important to existing programs). There are UI issues to solve. You'd probably want some notion of an item having "bias", so explorers can decide whether it makes more sense to e.g. open a clicked icon in an app or explore inside it. You'd need to find ways to express the duality in a GUI nicely and so on. But if you get it right it would allow app devs to think of their data in terms of tiny files and then let the OS handle the annoying aspects like what happens when you drag such a directory onto an email. Apple/NeXT tried to do this with their bundles but it never really worked because it wasn't integrated into the core OS in any way, it was just a UI hack in the Finder. For example early iLife apps represented documents as bundles, but eventually they gave up and did a file format because moving iLife documents around was just too difficult in a world of protocols that don't understand directories. 3. Ghost files. There's an obvious question here of how to handle data that can be worked with in many formats. For example, images often need to be converted back and forth and the conversion may not be lossless. I want to find a syntax that lets you "cast" using just names. The obvious and most compatible approach is that every format the system understands is always present, and filled out on demand. Example: $ take /tmp/foo $ wget https://www.example.com/face.jpg $ ls face.jpg $ imgcat face.webp <now you see the face> In this case, the OS has a notion of files that could exist but currently don't, and which don't appear in directory listings. Instead they are summoned on demand by the act of trying to open them for reading. You could imagine a few different UXs for handling divergence here, i.e. what if you edit the JPG after you accessed the WEBP version. 4. Unify KV stores and the filesystem Transactional sorted KV stores are a very general and powerful primitive. A few things make filesystems not a perfect replacement for RocksDB. One is that a file is a heavyweight thing. Not only must you go to kernel mode to get it, but every file has things like permissions, mtimes, ctimes and so on, which for lightweight key/value pairs is overkill. So I'd like a way to mark a directory as "lite". Inside a lite directory files don't have stored metadata (attempting to querying them always returns dummy values or errors), and you can't create subdirectories either. Instead it's basically a KV store and the FS implementation uses an efficient KV store approach, like an LSM tree. Reading such a directory as a byte stream gives you an SSTable. Also, contemporary kernels don't have any notion of range scans. If you write `ls foo*` then that's expanded by the shell, not filtered out by doing an efficient partial scan inside the kernel, so you can get nonsense like running out of command line space (especially easy on Windows). But to unify FS and KV stores you need efficient range scans. There have been attempts at transactional filing systems - NTFS does this. But it's never worked well and is deprecated. Part of the reason UNIX doesn't have this is because the filesystem is a composite of different underlying storage engines, so to do transactionality at the level of the whole FS view you'd need 2PC between very different pieces of code and maybe even machines, which is quite hard. Lite directories, being as they are fixed in one place, would support transactions within them. 5. Transient directories Free disk space management is a constant PITA in most operating systems. Disk space fills up and then you're kicked to a variety of third party cleaner tools. It sucks, especially as most of your storage is probably just a local cache of stuff generated or obtained from elsewhere. In my research OS/OE, "filectories" or whatever they're called can be tagged with expiry times, notions of priority, and URLs+hashes. The OS indexes these and when free disk space runs out the OS will do start deleting the lowest priority files to free up space. Temporary files go first, then files that were downloaded but weren't used for a while (re-downloaded on demand), and so on. In such an OS you wouldn't have a clear notion of free disk space. Instead as you ran out of disk space, rare operations would just get slower. You could also arrange for stuff to be evicted to remote caches or external drives instead of being deleted.
- jijji 3y ago
  its better than being OS400-like, isnt it?
  - kjs3 3y ago
    OS/400 is actually really interesting and very well thought out, particularly as an example of "Not Unix". I wouldn't want to make my living there, but lots of people do.
- kjs3 3y ago
  Why does it seem like 80 to 90% of hobby OS projects that are announced here as "Unix-like" invariably get someone who replies with "that thing you're doing as a hobby, for fun...you're doing it wrong and I don't approve". Zero content, zero insight posts about someones else's toy aren't useful. You want a 'new model', start coding.
- sneed_chucker 3y ago
  Because we effectively live in a Unix monoculture world, in terms of operating systems that you can actually use and study the inner workings of. It was a legal anomaly that resulted in early Unix (aka Research Unix) being distributed with its source code for free to universities, which was enough to get the ball rolling on stuff like BSD and Lion's annotated V6 source code, that by the time AT&T decided that closed source commercial Unix was the game it wanted to play, the cat was already out of the bag. By the time the free software and open source movements had gained some ground, enough people had studied or worked on some kind of Unix kernel and Userland source code that projects like Linux, Minix, and Free/Net/Open BSD were feasible. The fact that Linux running on x86 subsequently ate the world was probably something few people saw coming. The other lineages of operating systems, e.g. Windows NT, OpenVMS, IBM's various offerings, either never have their source released or only have their source released long after they're obsolete.
- linguae 3y ago
  Through various market forces, Unix (and its descendants/clones) and Windows killed most of the rest of the OS ecosystem over 20 years ago. There are generations of software engineers and computer scientists who’ve never studied operating systems that weren’t Unix- or Windows-based. Most leading OS textbooks (Tanenbaum’s books, the dinosaur book, Three Easy Pieces) have a Unix slant. Even the systems software research community is heavily Unix-centric; I say that as someone who used to be immersed in the research storage systems community. The only non-Unix or Windows operating systems many practitioners and even researchers may have used in their lives are MS-DOS and the classic Mac OS, and there’s a growing number of people who weren’t even born yet by the time these systems fell out of common use. However, the history of computing contains examples of other operating systems that didn’t survive the marketplace but have interesting lessons that can apply to improving today’s operating systems. The Unix Hater’s Handbook is a nice example of alternative worlds of computing that were still alive in the 1980s and early 1990s. VMS, IBM mainframe systems, Smalltalk, Symbolics Genera, Xerox Mesa and Cedar, Xerox Interlisp-D, and the Apple Newton were all real-world systems that demonstrate alternatives to the Unix and Windows ways of thinking. Project Oberon is an entire system developed by Wirth (of Pascal fame) whose design goal is to build a complete OS and development environment that is small enough to be understood for pedagogical purposes, similar to MINIX but without any Unix compatibility. Reading the history of failed Apple projects such as the planned Lisp OS for the Newton and the ill-fated Pink/Taligent project are also instructive. Microsoft Research did a lot of interesting research in the 2000s on operating systems implemented in memory-safe languages, notably Singularity and Midori. From learning about these past projects, we can then imagine future directions for OS design.
  - lproven 3y ago
    Beautifully put. I couldn't have said it better myself.
  - amedvednikov 3y ago
    Project Oberon is amazing. Shame it isn't more popular.
  - mananaysiempre 3y ago
    How would one go about exploring “other” real-world systems? I’ve read some old OS textbooks, poked at Symbian and OS/2 books some, and have texts on Oberon and Symbolics in my queue, but the docs for RSX-11 and VMS seem to bury me in operational minutiae without really explaining the design choices, and the Multics docs look like a huge pile of research notes, which is going a bit too far in the other direction. The current bytecode on IBM i is apparentily outright NDA’d, and the RPG docs are eager to presume I know how to operate the original punch-card tabulators. Any pointers?
- guerrilla 3y ago
  If it ain't broke, don't fix it. All kinds of new OS ideas can be implemented on UNIX like Mach[1], FLASK[2] and 9P[3] while internally a UNIX-like system doesn't need to be anything like a UNIX[4]... So who cares? What are you worried about losing? What can't be implemented on a UNIX-like system? 1. see MacOS 2. see SELinux 3. see v9fs 4. see Windows and BeOS which both have POSIX APIs
  - LoganDark 3y ago
    Didn't Windows drop the POSIX APIs and then eventually introduce WSL instead?
  - josephg 3y ago
    The problem is that anything you build on top of Unix will always be a second class citizen in the Unix world. For example, suppose you want a database-like filesystem. Either you implement it in the kernel, and now your special apps barely work on anyone’s computers. Or you implement it in userspace - preferably as a library. And now your apps can run anywhere without special kernel features but the terminal, and all the other applications on the computer can’t / won’t understand your new abstraction. And you’ll be fighting an uphill battle to get anyone to care about your new thing, let alone integrate it. It’s like saying - why rust? Why not just add a borrow checker to C? Why didn’t C# just add a garbage collector to C++? Sometimes starting fresh and establishing a clear, clean environment with different norms is the most effective way to make something new. You don’t have to fight as many battles. You can remove obsolete things. You don’t have to fight with the platform conventions, or fight the old guard who like things as they are. It’s a shame with operating systems that modern device drivers are so complicated. Hobbyist operating systems seem inordinately difficult to make these days as a result, and that’s a pity. There’s all sorts of good ideas out there that I’d love to see explored.
    - guerrilla 3y ago
      Nobody's stopping you from doing that but apparently none of OP's ideas required that, nor has it been worth it for anyone else's yet either. If it ain't broke, don't fix it. Let me know when it's actually broke in this actual reality. Then we can start over*. Also all those languages are Cs in the same way BSD and Linux are UNIXs. Same family. You should have mentioned Haskell or APL instead. * Note that many experiments did start over, e.g. Plan9, but were then integrated into a UNIX.
- im_down_w_otp 3y ago
  We created a funky little OS on top of seL4 & Rust that's most certainly not Unix-like, and is more akin to an RTOS-like approach to building & bundling software. More for purpose-built appliances than a general purpose OS.
  - cmrdporcupine 3y ago
    Tell us more. Who is we?
    - im_down_w_otp 3y ago
      My company, https://www.auxon.io https://www.auxon.io. We created https://github.com/auxoncorp/ferros https://github.com/auxoncorp/ferros originally to enable a customer project early in the company's life cycle. Some time later we had another customer interested in using it and having us add some features to it (e.g. some device drivers and a persistence layer utilizing https://docs.rs/tickv/latest/tickv/ https://docs.rs/tickv/latest/tickv/). It was becoming a massive pain in the neck to work out source code sharing agreements with them, so we decided to just open source it. There are quite a number of things that we would do differently if we had to build it again, and at some point will likely do that work to revise it. The biggest one of those is root task synthesis. The other is to build and bring in facilities for running tasks that are compiled to WASM. Somewhat humorously, the fact that doing system & integration testing was irritatingly challenging with a combination of FerrOS (which locks down as much as possible at runtime), and black-box binaries that couldn't be changed, played a role in us leaning pretty hard into using trace-based testing & verification techniques for our distributed systems & robotics testing products.
      - cmrdporcupine 3y ago
        Nice. I like.
- chaxor 3y ago
  I think the main selling point for Unix-like OS, but in Rust, is focused on Rust. It's to ensure that the memory related errors are less likely, and hopefully with enough work, the system can be essentially what we have today, but with less CVEs. It's honestly a decent goal and I'm in support of it. I know that there will inevitably be many now that come to state the obvious "well it doesn't guarantee safety" and "there are other reasons for CVE", etc. Nonetheless, it's not a bad idea.
  - deleted 3y ago
    [deleted]
- zvmaz 3y ago
  There's XINU (Xinu's Not Unix). There's a book that walks you through the complete implementation of the OS in C [1]. [1] https://xinu.cs.purdue.edu/ https://xinu.cs.purdue.edu/
- bsder 3y ago
  Because the only large, available, free ecosystem of software (both applications and hardware drivers) is completely built around the Unix abstractions. If you don't want to do Unix, you have to reduplicate ALL of it. And that's like trying to boil the ocean.
- smasher164 3y ago
  It’s hard enough to learn osdev. If you have a concrete design to fall back on, you can focus on implementation. Coming up with an original design for OSes is like a 3rd project thing.
- lmm 3y ago
  Unix is a lot more amenable than most older OSes to being implemented by a disparate group of people with limited communication, hence why GNU was originally set up as a reimplementation of unix.
- jacquesm 3y ago
  Because if you manage to get to some level of POSIX compatibility you can leverage that into having a whole toolchain and lots of other goodies up and running in a relatively short time. This limits the amount of effort required to get to 'first base', a self hosting environment.
- OJFord 3y ago
  Is it perhaps interoperability? If you're not that serious about it, it's a way to get a bit more for free? Contrast Redux, which is quite a serious (not in the 'we compete with Windows' sense, but still) project I gather, which... I don't know how they describe it, but it's sort of Unix-ish, Unix-rethought? I've never actually played with it, but loved the idea of 'everything is a url' (not file) when I heard it described & explained on The Bike Shed podcast I think.
- inkyoto 3y ago
  Because of the availability of the source code under a permissive licence that UNIX has been distributed under for a long time. Other operating systems source code still remains unavailable, sometimes decades after the hardware they used to run on had disappeared. The second reason is the simplicity of abstractions and the ease of their implementation. In the original DEC documentation on RSX-11M (the predecessor of VAX VMS), for example, there is a whole chapter describing how to create and fill in a file descriptor block (a complex record data structure) required just to open a file where the user has to decide beforehand where to locate the file, whether they want to access the data [blocks] randomly or sequentially, whether the file is being opened merely for updating the data but not extending the file size or for updating the data and extending the file, whether allow or not other processes to access the same file whilst it is open, the number of in-memory buffers for the kernel to allocate for file access etc etc. Many complex decisions have to be made before a file can be opened. In UNIX, on the other hand, it is a mere «int fd = open ("myfile", O_RDONLY);», the end. Granted, not every OS has had such complexities (the opposite is also true, tho). Yet, the simplified (one can argue that it has been oversimplified) UNIX abstractions have been influential for a reason.
- Brian_K_White 3y ago
  At both extreme opposite ends of the scale/funding/people spectrum we already have TempleOS and Fuscia, and probably countless in between. You tell me why they aren't going anywhere even though any properties you might say about one, the other has the opposite quality and is also going nowhere. Maybe "unix-like" is really just a principle that has no expiration date, like "murder is wrong". Depending on how slavishly you define "unix-like", for instance, I would not say that the principle philosophy dictates there shall always be a command named "rm" that takes these options and does this task a la posix specs. But for today and certainly any forseeable time, it's perfectly useful to "merely" reimplement posix.
- hulitu 3y ago
  It is only marketing. It does not seem to implement anything from POSIX or SUS.
- pjmlp 3y ago
  Because it is less effort to copy already existing stacks, than be creative in trailing not yet discovered paths.
mysterydip 3y ago
What does "written in safe Rust as much as possible" mean? Are there functions with no equivalent in rust?
- OtomotO 3y ago
  Interfacing with hardware means you have to drop to "unsafe" rust at some (few) points. "Unsafe" rust isn't named good, because it's still safer than e.g. C. Some invariants you cannot break in rust, no matter if "safe" or "unsafe"
  - xeonmc 3y ago
    Would it be more aptly named “risky rust”?
    - kzrdude 3y ago
      Yes! Another apt name would be "trustme". (The normal case in Rust is trust the compiler - and all the people who wrote "trustme" code that you depend on!)
  - tialaramex 3y ago
    > it's still safer than e.g. C. This is arguable and I think overall it's actually harder to correctly write unsafe Rust, even if sometimes maybe in some sense safer than C when you screw up. In Rust everything has to obey Rust's semantic constraints. For safe Rust that's fine because the language itself promises you're obeying. You can't introduce anything which would be a problem, so you needn't even care what those problems are. But in unsafe Rust you are responsible for the same guarantees that safe Rust gave everybody. And the rules you're responsible for obeying are truly difficult so that you may not properly understand them. If you screw up, that's instantly Undefined Behaviour. Let's take a fairly old but brutal real example from Rust's standard library. core::mem::uninitialized<T>(). This function is labelled deprecated (as well as unsafe) in your Rust, but once upon a time it was the usual way to make some uninitialized buffer in which to construct something. But it was actually UB almost always†. Because what it says is, OK, I know I didn't initialize a T, but trust me, I'll sort that out later, lets say this is a T anyway. And for a time people persuaded themselves that this is OK for at least some types. After all, if T was u8 (a byte) then who cares what its value is, any value is valid, isn't it? Well, yes, but "uninitialized" isn't a value, it's a 257th possible state, the compiler knows we didn't initialize this, and therefore all optimisations are valid even if they wouldn't be valid for any possible initialized state of the memory - we didn't initialize it so we're not entitled to assume it had any of those values. In C you will get away with this but in Rust you've created Undefined Behaviour, which is not OK. Today you would use the MaybeUninit<T> type so that you can explicitly initialize it (once you have something to initialize it with) and then MaybeUninit::assume_init() to get your T instead now that it's initialized, and (if you did it correctly) that is safe. † If T is a Zero Size Type then this function isn't dangerous, because it makes nothing and then says this nothing is actually a T, and the compiler says well, thanks for telling me, I don't really care but whatever. No UB. Likely this only happens in generic code, but it's safe.
cnuts 3y ago
That's really cool, great job!
prydt 3y ago
Awesome! What are some good resources on making a simple UNIX like operating system? I know osdev wiki exists, anything else?
- o8vm 3y ago
  Thanks！For me https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.pdf https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.p... was quite helpful! but Someday I will write a book on how to implement this OS step by step in Japanese.
bakul 3y ago
How does this compare with https://github.com/dancrossnyc/rxv64 https://github.com/dancrossnyc/rxv64 ? From its README.md: rxv64 is a pedagogical operating system written in Rust that targets multiprocessor x86_64 machines. It is a reimplementation of the xv6 operating system from MIT.
- snvzz 3y ago
  I immediately notice that o8vm targets RISC-V, whereas rxv64 targets a legacy ISA.
  - yjftsjthsd-h 3y ago
    Is it really a "legacy" ISA if it's actively developed by two different companies (and will be for a long time to come) and is utterly dominant in servers, desktops, and laptops today?
    - snvzz 3y ago
      You're right in that it is still actively developed by two different companies, and that it is still utterly dominant in servers, desktops, and laptops... today. Perhaps you would prefer "incumbent ISA"? But that would be a pointless exercise, because RISC-V is inevitable, and the new industry standard. The intent was to express "not RISC-V" anyway. The parent already specifies which.
      - yjftsjthsd-h 3y ago
        > Perhaps you would prefer "incumbent ISA"? I wouldn't mind that. > But that would be a pointless exercise, because RISC-V is inevitable, and the new industry standard. Er. So even if the second part of the sentence were true, calling out the current leader isn't pointless. And the second part of your claim is very much not a foregone conclusion; RISC-V is a standard, and used by the industry, but it's not in anything like a dominant enough position to call it "the industry standard", and its success is certainly not inevitable - RISC-V is today where MIPS was a decade ago (cheap, modestly popular in embedded, lacking in high-end parts, not popular outside of embedded). Now, its trajectory is upwards, it has enough going for it that it could become extremely popular, and certainly I'd like an Open Source option to win - but that's just one possibility, and history is littered with ISAs that were supposed to be the Next Big Thing.
xolve 3y ago
OP, would be nice if you add a license to the repo.
- o8vm 3y ago
  Thanks! Is this notation in the README not enough: https://github.com/o8vm/octox#license https://github.com/o8vm/octox#license ?
  - Arnavion 3y ago
    Both those licenses require you to add the license text as a file to the codebase. Eg see the "How to apply the Apache License to your work" section in the Apache license link that you have there. Since it's dual-licensed you can add one as LICENSE-MIT and the other as LICENSE-APACHE.
    - o8vm 3y ago
      Oh, I see! Thank you very much. I'll add both later!
  - tbillington 3y ago
    If you like you can copy what I did: https://github.com/tbillington/bevy_toon_shader https://github.com/tbillington/bevy_toon_shader, which I copied from https://github.com/bevyengine/bevy/ https://github.com/bevyengine/bevy/ (just that my repo has was less stuff, so might be easier to copy from).
freecodyx 3y ago
Not related to the project. Most of the code is unsafe. I really find rust counterintuitive. This is just a note to myself. * rust uses llvm as a backend * rust tries to solve the memory issues commonly found in C bu enforcing a programming paradigm which allow the compiler to detect them at compile time. * it tries to provide 0 cost abstractions It works but the code is ugly
- segfaltnh 3y ago
  Wait, most of _what_ code is unsafe? Aside from this one comment it sounds like you just came here to shit on Rust, lol.
stevefan1999 3y ago
Oh you have did what I did in the shadow...I wonder if I later GPL'd it the license won't be compatible to take the code in...But I runs in x86_64 with custom QEMU UEFI loader anyway
yasuoyamasaki 3y ago
Just one hacker developed this OS, ya know!

190 points by o8vm 3y ago

deleted 3y ago

[deleted]

Why does it seem like 80 to 90% of hobby OS projects that are started are "Unix-like?" Don't we already have a huge variety of Unix-like OSes out there? Why not explore new models?

packetlost 3y ago
We need more Plan 9-likes! But more seriously, the Unix/POSIX-like OS is a pretty good model, but IMO we could do better, especially in the microkernel front.
- o8vm 3y ago
  I would like to implement a plan9-like OS someday!
- bakul 3y ago
  I'd love to see an OS with a Unix API but plan9 like kernel! I will never get around to writing one myself though!
  - jacquesm 3y ago
    I got very close to that.
    - bakul 3y ago
      Which part? Designing or implementing or something else?
      - jacquesm 3y ago
        Implementing. I wrote a QnX clone and it has a lot of parallels with plan9.
        sillywalk 3y ago
        Well show it to us :) For a curious OS nerd that sounds cool. Hacker News Cool.
- boricj 3y ago
  There are a lot of things wrong with plain standard POSIX: - it's hopelessly out of date and incomplete w.r.t. modern expectations - fork() is very problematic for multiple reasons, especially in a modern environment (https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0...) - process management functions take PIDs and not capabilities, which can cause race conditions - POSIX hasn't standardized anything better than poll(), yes it works fine in a hobby context but it's not 1987 anymore (and don't get me started on select(): https://github.com/SerenityOS/serenity/pull/11229 https://github.com/SerenityOS/serenity/pull/11229) - signals are a mess - Unix processes have a huge amount of ambient authority, which is problematic when trying to isolate them (chroot(), https://fuchsia.dev/fuchsia-src/concepts/filesystems/dotdot https://fuchsia.dev/fuchsia-src/concepts/filesystems/dotdot, ...) - the C POSIX library has a lot of cruft while also missing stuff what programmers actually need (for example, POSIX took nearly 6 years to standardize strlcat()/strlcpy(), the process itself starting 17 years after OpenBSD introduced those functions: https://www.austingroupbugs.net/view.php?id=986 https://www.austingroupbugs.net/view.php?id=986) - ... Granted, modern production-grade Unix-like operating systems have extensions to deal with most of these issues (posix_spawn, kqueue, pidfd_open...), but they are often non-standard and can be quite janky at times (dnotify, SIGIO...). It also doesn't fix the huge amount of code out there using the legacy facilities like it's still the 1980s. There are other models out there (Plan 9, Windows, Fuchsia...), but what we really need is to stop putting Unix/POSIX on a pedestal like some holy scripture that shall not be questioned. It's the pinnacle of 1970s operating system designs and it has fossilized so much it's actively turning into oil. Or at the very least, please stop teaching the next generation that fork() is the greatest thing ever. It's a 50 year old hack kept alive through gratuitous amounts of copy-on-write that should've been scrapped the day Unix was ported to computers with virtual memory and paging.
  - yjftsjthsd-h 3y ago
    This feels contradictory; unix isn't good enough, so nobody implements standard unix, but people need to stop putting unix on a pedestal?
    - 3y ago
- pkphilip 3y ago
  Redox OS implemented in Rust aims to be Plan-9-like: https://www.redox-os.org/faq/#how-redox-is-inspired-by-other-systems https://www.redox-os.org/faq/#how-redox-is-inspired-by-other...
crickey 3y ago
What is even Unix-like ? I usually associate it with POSIX but maybe thats naive
- OJFord 3y ago
  The general design of users, processes, files, etc. It's obviously not that well-defined since it's implicitly 'not Unix', so can diverge. Just anything that's subjectively similar to that OS design.
nextaccountic 3y ago
What is an OS good for if not to run programs? You either port existing programs to your API (lots of work) or design the OS with an existing API in mind. Or forget about existing programs and write entirely new programs "Unix-like" describes the second approach, you provide a POSIX API but can have different internals Now, maybe you wanted to have two APIs: one native API for the apps you write, and a translator from another, more popular API to your native API. Sounds like a lot of work when almost all software that will ever run on your OS will the translator
- vilunov 3y ago
  Often the user-space API limits the design of internals and available features. I for one would like to see the classical hierarchical filesystem gone, but POSIX (and UNIX) at its core is about the filesystem. If you need to run the existing programs, feel free to develop a translation layer, at the same time allowing a new type of OS paradigm to emerge.
  - yjftsjthsd-h 3y ago
    Nobody's stopping you from slapping on a compat layer, and ex. Haiku does that, but it's more work than just being unixy to start with.
  - huhlig 3y ago
    Curious, what would you replace the classic Hierarchical File System with? A flat key value store? We’ve tried that and it’s a nightmare.
    - mike_hearn 3y ago
      Here's a few ideas I've been stockpiling for the day I retire and my wife will hopefully let me just fiddle with operating systems all day. None of these necessarily would work well or make sense, they're just stuff that would be satisfying to explore. NB: All this can be done in userspace with enough hacks. 1. Make strong file typing work well. Filesystems ignore the question of type, leaving it to ad-hoc conventions like extensions. Figuring out what a file really is takes a lot of effort, is often duplicated by apps and the OS and has a long history of introducing security vulnerabilities. There's also no first class notion of "type casting". Format conversion is delegated to an ad-hoc and inconsistent set of tools which you have to learn about and obtain yourself, even though it's a very common need. 2. Unify files and directories. Make open() and read() work on directories. You need (1) for this. A lot of cruft and complexity in computing comes from the fact that most things only understand byte arrays (e.g. http, email attachments...), not directories. Directories have no native serialization in any OS, unless you want to stretch and call DMG a fundamental part of macOS. Instead it's delegated to an ancient set of utilities and "archive" formats. As a consequence a big part of app development has historically been about coming up with use-case specific file formats, many of which are ad hoc pseudo-filesystems. This task is hard and tedious! There are lots of badly designed file formats out there, and my experience is that these days very few devs actually know how to design file formats, which is part of why so much computing has migrated to cloud SaaS (where you ignore files and work only with databases). Many new file formats are just ZIPs. An operating system (or userspace "operating environment") could fix this by redefining some cases that are errors in POSIX today to be well defined operations. For example given a file that has some sort of hierarchical inner structure like a .zip (.jar, .docx), .csv, .json, .java, .css and so on, allow it to be both read as a byte array but also allow you to list it like a directory. Plugins would implement a lossless two-way conversion, and the OS would convert back and forth behind the scenes. So for example you could write: echo red > styles.css/.main-content/background-color and the CSS file would be updated. Likewise, you could do: mkdir "Fun Project" curl --post -d "Fun Project" https://whatever.com/cgi-bin/receive-directory The trick here is to try and retain compatibility with as much software as possible whilst meaningfully upgrading it with new functionality. Redefining error cases is one way to do this (because you have some confidence they won't be important to existing programs). There are UI issues to solve. You'd probably want some notion of an item having "bias", so explorers can decide whether it makes more sense to e.g. open a clicked icon in an app or explore inside it. You'd need to find ways to express the duality in a GUI nicely and so on. But if you get it right it would allow app devs to think of their data in terms of tiny files and then let the OS handle the annoying aspects like what happens when you drag such a directory onto an email. Apple/NeXT tried to do this with their bundles but it never really worked because it wasn't integrated into the core OS in any way, it was just a UI hack in the Finder. For example early iLife apps represented documents as bundles, but eventually they gave up and did a file format because moving iLife documents around was just too difficult in a world of protocols that don't understand directories. 3. Ghost files. There's an obvious question here of how to handle data that can be worked with in many formats. For example, images often need to be converted back and forth and the conversion may not be lossless. I want to find a syntax that lets you "cast" using just names. The obvious and most compatible approach is that every format the system understands is always present, and filled out on demand. Example: $ take /tmp/foo $ wget https://www.example.com/face.jpg $ ls face.jpg $ imgcat face.webp <now you see the face> In this case, the OS has a notion of files that could exist but currently don't, and which don't appear in directory listings. Instead they are summoned on demand by the act of trying to open them for reading. You could imagine a few different UXs for handling divergence here, i.e. what if you edit the JPG after you accessed the WEBP version. 4. Unify KV stores and the filesystem Transactional sorted KV stores are a very general and powerful primitive. A few things make filesystems not a perfect replacement for RocksDB. One is that a file is a heavyweight thing. Not only must you go to kernel mode to get it, but every file has things like permissions, mtimes, ctimes and so on, which for lightweight key/value pairs is overkill. So I'd like a way to mark a directory as "lite". Inside a lite directory files don't have stored metadata (attempting to querying them always returns dummy values or errors), and you can't create subdirectories either. Instead it's basically a KV store and the FS implementation uses an efficient KV store approach, like an LSM tree. Reading such a directory as a byte stream gives you an SSTable. Also, contemporary kernels don't have any notion of range scans. If you write `ls foo*` then that's expanded by the shell, not filtered out by doing an efficient partial scan inside the kernel, so you can get nonsense like running out of command line space (especially easy on Windows). But to unify FS and KV stores you need efficient range scans. There have been attempts at transactional filing systems - NTFS does this. But it's never worked well and is deprecated. Part of the reason UNIX doesn't have this is because the filesystem is a composite of different underlying storage engines, so to do transactionality at the level of the whole FS view you'd need 2PC between very different pieces of code and maybe even machines, which is quite hard. Lite directories, being as they are fixed in one place, would support transactions within them. 5. Transient directories Free disk space management is a constant PITA in most operating systems. Disk space fills up and then you're kicked to a variety of third party cleaner tools. It sucks, especially as most of your storage is probably just a local cache of stuff generated or obtained from elsewhere. In my research OS/OE, "filectories" or whatever they're called can be tagged with expiry times, notions of priority, and URLs+hashes. The OS indexes these and when free disk space runs out the OS will do start deleting the lowest priority files to free up space. Temporary files go first, then files that were downloaded but weren't used for a while (re-downloaded on demand), and so on. In such an OS you wouldn't have a clear notion of free disk space. Instead as you ran out of disk space, rare operations would just get slower. You could also arrange for stuff to be evicted to remote caches or external drives instead of being deleted.
jijji 3y ago
its better than being OS400-like, isnt it?
- kjs3 3y ago
  OS/400 is actually really interesting and very well thought out, particularly as an example of "Not Unix". I wouldn't want to make my living there, but lots of people do.
kjs3 3y ago
Why does it seem like 80 to 90% of hobby OS projects that are announced here as "Unix-like" invariably get someone who replies with "that thing you're doing as a hobby, for fun...you're doing it wrong and I don't approve". Zero content, zero insight posts about someones else's toy aren't useful. You want a 'new model', start coding.
sneed_chucker 3y ago
Because we effectively live in a Unix monoculture world, in terms of operating systems that you can actually use and study the inner workings of. It was a legal anomaly that resulted in early Unix (aka Research Unix) being distributed with its source code for free to universities, which was enough to get the ball rolling on stuff like BSD and Lion's annotated V6 source code, that by the time AT&T decided that closed source commercial Unix was the game it wanted to play, the cat was already out of the bag. By the time the free software and open source movements had gained some ground, enough people had studied or worked on some kind of Unix kernel and Userland source code that projects like Linux, Minix, and Free/Net/Open BSD were feasible. The fact that Linux running on x86 subsequently ate the world was probably something few people saw coming. The other lineages of operating systems, e.g. Windows NT, OpenVMS, IBM's various offerings, either never have their source released or only have their source released long after they're obsolete.
linguae 3y ago
Through various market forces, Unix (and its descendants/clones) and Windows killed most of the rest of the OS ecosystem over 20 years ago. There are generations of software engineers and computer scientists who’ve never studied operating systems that weren’t Unix- or Windows-based. Most leading OS textbooks (Tanenbaum’s books, the dinosaur book, Three Easy Pieces) have a Unix slant. Even the systems software research community is heavily Unix-centric; I say that as someone who used to be immersed in the research storage systems community. The only non-Unix or Windows operating systems many practitioners and even researchers may have used in their lives are MS-DOS and the classic Mac OS, and there’s a growing number of people who weren’t even born yet by the time these systems fell out of common use. However, the history of computing contains examples of other operating systems that didn’t survive the marketplace but have interesting lessons that can apply to improving today’s operating systems. The Unix Hater’s Handbook is a nice example of alternative worlds of computing that were still alive in the 1980s and early 1990s. VMS, IBM mainframe systems, Smalltalk, Symbolics Genera, Xerox Mesa and Cedar, Xerox Interlisp-D, and the Apple Newton were all real-world systems that demonstrate alternatives to the Unix and Windows ways of thinking. Project Oberon is an entire system developed by Wirth (of Pascal fame) whose design goal is to build a complete OS and development environment that is small enough to be understood for pedagogical purposes, similar to MINIX but without any Unix compatibility. Reading the history of failed Apple projects such as the planned Lisp OS for the Newton and the ill-fated Pink/Taligent project are also instructive. Microsoft Research did a lot of interesting research in the 2000s on operating systems implemented in memory-safe languages, notably Singularity and Midori. From learning about these past projects, we can then imagine future directions for OS design.
- lproven 3y ago
  Beautifully put. I couldn't have said it better myself.
- amedvednikov 3y ago
  Project Oberon is amazing. Shame it isn't more popular.
- mananaysiempre 3y ago
  How would one go about exploring “other” real-world systems? I’ve read some old OS textbooks, poked at Symbian and OS/2 books some, and have texts on Oberon and Symbolics in my queue, but the docs for RSX-11 and VMS seem to bury me in operational minutiae without really explaining the design choices, and the Multics docs look like a huge pile of research notes, which is going a bit too far in the other direction. The current bytecode on IBM i is apparentily outright NDA’d, and the RPG docs are eager to presume I know how to operate the original punch-card tabulators. Any pointers?
guerrilla 3y ago
If it ain't broke, don't fix it. All kinds of new OS ideas can be implemented on UNIX like Mach[1], FLASK[2] and 9P[3] while internally a UNIX-like system doesn't need to be anything like a UNIX[4]... So who cares? What are you worried about losing? What can't be implemented on a UNIX-like system? 1. see MacOS 2. see SELinux 3. see v9fs 4. see Windows and BeOS which both have POSIX APIs
- LoganDark 3y ago
  Didn't Windows drop the POSIX APIs and then eventually introduce WSL instead?
- josephg 3y ago
  The problem is that anything you build on top of Unix will always be a second class citizen in the Unix world. For example, suppose you want a database-like filesystem. Either you implement it in the kernel, and now your special apps barely work on anyone’s computers. Or you implement it in userspace - preferably as a library. And now your apps can run anywhere without special kernel features but the terminal, and all the other applications on the computer can’t / won’t understand your new abstraction. And you’ll be fighting an uphill battle to get anyone to care about your new thing, let alone integrate it. It’s like saying - why rust? Why not just add a borrow checker to C? Why didn’t C# just add a garbage collector to C++? Sometimes starting fresh and establishing a clear, clean environment with different norms is the most effective way to make something new. You don’t have to fight as many battles. You can remove obsolete things. You don’t have to fight with the platform conventions, or fight the old guard who like things as they are. It’s a shame with operating systems that modern device drivers are so complicated. Hobbyist operating systems seem inordinately difficult to make these days as a result, and that’s a pity. There’s all sorts of good ideas out there that I’d love to see explored.
  - guerrilla 3y ago
    Nobody's stopping you from doing that but apparently none of OP's ideas required that, nor has it been worth it for anyone else's yet either. If it ain't broke, don't fix it. Let me know when it's actually broke in this actual reality. Then we can start over*. Also all those languages are Cs in the same way BSD and Linux are UNIXs. Same family. You should have mentioned Haskell or APL instead. * Note that many experiments did start over, e.g. Plan9, but were then integrated into a UNIX.
im_down_w_otp 3y ago
We created a funky little OS on top of seL4 & Rust that's most certainly not Unix-like, and is more akin to an RTOS-like approach to building & bundling software. More for purpose-built appliances than a general purpose OS.
- cmrdporcupine 3y ago
  Tell us more. Who is we?
  - im_down_w_otp 3y ago
    My company, https://www.auxon.io https://www.auxon.io. We created https://github.com/auxoncorp/ferros https://github.com/auxoncorp/ferros originally to enable a customer project early in the company's life cycle. Some time later we had another customer interested in using it and having us add some features to it (e.g. some device drivers and a persistence layer utilizing https://docs.rs/tickv/latest/tickv/ https://docs.rs/tickv/latest/tickv/). It was becoming a massive pain in the neck to work out source code sharing agreements with them, so we decided to just open source it. There are quite a number of things that we would do differently if we had to build it again, and at some point will likely do that work to revise it. The biggest one of those is root task synthesis. The other is to build and bring in facilities for running tasks that are compiled to WASM. Somewhat humorously, the fact that doing system & integration testing was irritatingly challenging with a combination of FerrOS (which locks down as much as possible at runtime), and black-box binaries that couldn't be changed, played a role in us leaning pretty hard into using trace-based testing & verification techniques for our distributed systems & robotics testing products.
    - cmrdporcupine 3y ago
      Nice. I like.
chaxor 3y ago
I think the main selling point for Unix-like OS, but in Rust, is focused on Rust. It's to ensure that the memory related errors are less likely, and hopefully with enough work, the system can be essentially what we have today, but with less CVEs. It's honestly a decent goal and I'm in support of it. I know that there will inevitably be many now that come to state the obvious "well it doesn't guarantee safety" and "there are other reasons for CVE", etc. Nonetheless, it's not a bad idea.
- deleted 3y ago
  [deleted]
zvmaz 3y ago
There's XINU (Xinu's Not Unix). There's a book that walks you through the complete implementation of the OS in C [1]. [1] https://xinu.cs.purdue.edu/ https://xinu.cs.purdue.edu/
bsder 3y ago
Because the only large, available, free ecosystem of software (both applications and hardware drivers) is completely built around the Unix abstractions. If you don't want to do Unix, you have to reduplicate ALL of it. And that's like trying to boil the ocean.
smasher164 3y ago
It’s hard enough to learn osdev. If you have a concrete design to fall back on, you can focus on implementation. Coming up with an original design for OSes is like a 3rd project thing.
lmm 3y ago
Unix is a lot more amenable than most older OSes to being implemented by a disparate group of people with limited communication, hence why GNU was originally set up as a reimplementation of unix.
jacquesm 3y ago
Because if you manage to get to some level of POSIX compatibility you can leverage that into having a whole toolchain and lots of other goodies up and running in a relatively short time. This limits the amount of effort required to get to 'first base', a self hosting environment.
OJFord 3y ago
Is it perhaps interoperability? If you're not that serious about it, it's a way to get a bit more for free? Contrast Redux, which is quite a serious (not in the 'we compete with Windows' sense, but still) project I gather, which... I don't know how they describe it, but it's sort of Unix-ish, Unix-rethought? I've never actually played with it, but loved the idea of 'everything is a url' (not file) when I heard it described & explained on The Bike Shed podcast I think.
inkyoto 3y ago
Because of the availability of the source code under a permissive licence that UNIX has been distributed under for a long time. Other operating systems source code still remains unavailable, sometimes decades after the hardware they used to run on had disappeared. The second reason is the simplicity of abstractions and the ease of their implementation. In the original DEC documentation on RSX-11M (the predecessor of VAX VMS), for example, there is a whole chapter describing how to create and fill in a file descriptor block (a complex record data structure) required just to open a file where the user has to decide beforehand where to locate the file, whether they want to access the data [blocks] randomly or sequentially, whether the file is being opened merely for updating the data but not extending the file size or for updating the data and extending the file, whether allow or not other processes to access the same file whilst it is open, the number of in-memory buffers for the kernel to allocate for file access etc etc. Many complex decisions have to be made before a file can be opened. In UNIX, on the other hand, it is a mere «int fd = open ("myfile", O_RDONLY);», the end. Granted, not every OS has had such complexities (the opposite is also true, tho). Yet, the simplified (one can argue that it has been oversimplified) UNIX abstractions have been influential for a reason.
Brian_K_White 3y ago
At both extreme opposite ends of the scale/funding/people spectrum we already have TempleOS and Fuscia, and probably countless in between. You tell me why they aren't going anywhere even though any properties you might say about one, the other has the opposite quality and is also going nowhere. Maybe "unix-like" is really just a principle that has no expiration date, like "murder is wrong". Depending on how slavishly you define "unix-like", for instance, I would not say that the principle philosophy dictates there shall always be a command named "rm" that takes these options and does this task a la posix specs. But for today and certainly any forseeable time, it's perfectly useful to "merely" reimplement posix.
hulitu 3y ago
It is only marketing. It does not seem to implement anything from POSIX or SUS.
pjmlp 3y ago
Because it is less effort to copy already existing stacks, than be creative in trailing not yet discovered paths.

mysterydip 3y ago

What does "written in safe Rust as much as possible" mean? Are there functions with no equivalent in rust?

OtomotO 3y ago
Interfacing with hardware means you have to drop to "unsafe" rust at some (few) points. "Unsafe" rust isn't named good, because it's still safer than e.g. C. Some invariants you cannot break in rust, no matter if "safe" or "unsafe"
- xeonmc 3y ago
  Would it be more aptly named “risky rust”?
  - kzrdude 3y ago
    Yes! Another apt name would be "trustme". (The normal case in Rust is trust the compiler - and all the people who wrote "trustme" code that you depend on!)
- tialaramex 3y ago
  > it's still safer than e.g. C. This is arguable and I think overall it's actually harder to correctly write unsafe Rust, even if sometimes maybe in some sense safer than C when you screw up. In Rust everything has to obey Rust's semantic constraints. For safe Rust that's fine because the language itself promises you're obeying. You can't introduce anything which would be a problem, so you needn't even care what those problems are. But in unsafe Rust you are responsible for the same guarantees that safe Rust gave everybody. And the rules you're responsible for obeying are truly difficult so that you may not properly understand them. If you screw up, that's instantly Undefined Behaviour. Let's take a fairly old but brutal real example from Rust's standard library. core::mem::uninitialized<T>(). This function is labelled deprecated (as well as unsafe) in your Rust, but once upon a time it was the usual way to make some uninitialized buffer in which to construct something. But it was actually UB almost always†. Because what it says is, OK, I know I didn't initialize a T, but trust me, I'll sort that out later, lets say this is a T anyway. And for a time people persuaded themselves that this is OK for at least some types. After all, if T was u8 (a byte) then who cares what its value is, any value is valid, isn't it? Well, yes, but "uninitialized" isn't a value, it's a 257th possible state, the compiler knows we didn't initialize this, and therefore all optimisations are valid even if they wouldn't be valid for any possible initialized state of the memory - we didn't initialize it so we're not entitled to assume it had any of those values. In C you will get away with this but in Rust you've created Undefined Behaviour, which is not OK. Today you would use the MaybeUninit<T> type so that you can explicitly initialize it (once you have something to initialize it with) and then MaybeUninit::assume_init() to get your T instead now that it's initialized, and (if you did it correctly) that is safe. † If T is a Zero Size Type then this function isn't dangerous, because it makes nothing and then says this nothing is actually a T, and the compiler says well, thanks for telling me, I don't really care but whatever. No UB. Likely this only happens in generic code, but it's safe.

cnuts 3y ago

That's really cool, great job!

prydt 3y ago

Awesome! What are some good resources on making a simple UNIX like operating system? I know osdev wiki exists, anything else?

o8vm 3y ago
Thanks！For me https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.pdf https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.p... was quite helpful! but Someday I will write a book on how to implement this OS step by step in Japanese.

bakul 3y ago

How does this compare with https://github.com/dancrossnyc/rxv64 https://github.com/dancrossnyc/rxv64 ? From its README.md: rxv64 is a pedagogical operating system written in Rust that targets multiprocessor x86_64 machines. It is a reimplementation of the xv6 operating system from MIT.

snvzz 3y ago
I immediately notice that o8vm targets RISC-V, whereas rxv64 targets a legacy ISA.
- yjftsjthsd-h 3y ago
  Is it really a "legacy" ISA if it's actively developed by two different companies (and will be for a long time to come) and is utterly dominant in servers, desktops, and laptops today?
  - snvzz 3y ago
    You're right in that it is still actively developed by two different companies, and that it is still utterly dominant in servers, desktops, and laptops... today. Perhaps you would prefer "incumbent ISA"? But that would be a pointless exercise, because RISC-V is inevitable, and the new industry standard. The intent was to express "not RISC-V" anyway. The parent already specifies which.
    - yjftsjthsd-h 3y ago
      > Perhaps you would prefer "incumbent ISA"? I wouldn't mind that. > But that would be a pointless exercise, because RISC-V is inevitable, and the new industry standard. Er. So even if the second part of the sentence were true, calling out the current leader isn't pointless. And the second part of your claim is very much not a foregone conclusion; RISC-V is a standard, and used by the industry, but it's not in anything like a dominant enough position to call it "the industry standard", and its success is certainly not inevitable - RISC-V is today where MIPS was a decade ago (cheap, modestly popular in embedded, lacking in high-end parts, not popular outside of embedded). Now, its trajectory is upwards, it has enough going for it that it could become extremely popular, and certainly I'd like an Open Source option to win - but that's just one possibility, and history is littered with ISAs that were supposed to be the Next Big Thing.

xolve 3y ago

OP, would be nice if you add a license to the repo.

o8vm 3y ago
Thanks! Is this notation in the README not enough: https://github.com/o8vm/octox#license https://github.com/o8vm/octox#license ?
- Arnavion 3y ago
  Both those licenses require you to add the license text as a file to the codebase. Eg see the "How to apply the Apache License to your work" section in the Apache license link that you have there. Since it's dual-licensed you can add one as LICENSE-MIT and the other as LICENSE-APACHE.
  - o8vm 3y ago
    Oh, I see! Thank you very much. I'll add both later!
- tbillington 3y ago
  If you like you can copy what I did: https://github.com/tbillington/bevy_toon_shader https://github.com/tbillington/bevy_toon_shader, which I copied from https://github.com/bevyengine/bevy/ https://github.com/bevyengine/bevy/ (just that my repo has was less stuff, so might be easier to copy from).

freecodyx 3y ago

Not related to the project. Most of the code is unsafe. I really find rust counterintuitive. This is just a note to myself. * rust uses llvm as a backend * rust tries to solve the memory issues commonly found in C bu enforcing a programming paradigm which allow the compiler to detect them at compile time. * it tries to provide 0 cost abstractions It works but the code is ugly

segfaltnh 3y ago
Wait, most of _what_ code is unsafe? Aside from this one comment it sounds like you just came here to shit on Rust, lol.

stevefan1999 3y ago

Oh you have did what I did in the shadow...I wonder if I later GPL'd it the license won't be compatible to take the code in...But I runs in x86_64 with custom QEMU UEFI loader anyway

yasuoyamasaki 3y ago

Just one hacker developed this OS, ya know!