"When Sensory Publishing gained the rights, they changed the name and they printed another run of a thousand to keep it available in print. They are down to 200 copies or so and no longer sell it. The book is now in the public domain and any books will be kept for the Great Alexandria Library."
To anyone who's interested in such projects: also check MenuetOS and KolibriOS (which is a fork of Menuet that diverged a looong time ago). MenuetOS also has a x64 version with SMP which is closed source.
I am interested in learning assembly language. I searched in Coursera but didn't find anything suitable for a total beginner (I have experience in Java and am doing some C/C++ courses to get closer to metal).
This might interest you: Writing a C Compiler by Nora Sandler (No Starch Press). You create a working C compiler that outputs x64 assembly language in the first chapter (as long as the program only returns an integer from main) and then you keep adding features one by one for the rest of the book. You can write the compiler in any language you like (I’m using Python) and you only write the compiler while using your system’s precompiler (the step that handles #include and #define etc and removes comments), linker, and assembler. You just read preprocessed C as text and output assembly as text.
The thing that makes it relevant for learning assembly is that’s what you’re outputting so you’ll be learning that as well as what’s going on with the stack when calling and returning from functions and using local variables and basically everything that corresponds to C. (I’m only on chapter 2.)
Some other reasons it might work out for you is that you are getting into C as well already, and you have a familiar language you could use for the compiler if you wanted: java (assuming it doesn’t take too long to compile and run a java program repeatedly)
I was coming to the comments to write this reminds me of Terry Davis, may be rest in peace. It might sound strange but Terry provided me with inspiration and a reminder that anything can be created or “Willed into existence”.
fun fact, last year I had a contractor come to my house. He was a very nice guy. After he was done we were talking and it turned out he was terry’s brother… He told me a lot of stories about him and his life, mental health and death. Pretty sad and interesting..
Given an infinite multitude of parallel universes, perhaps one exists where TempleOS was in fact the sole and exclusive conduit to divinity and Terry was it's prophet. I hope that is the case.
Well yes and in that timeline and shall we say warped logic, Terry stated that the random number generator is the direct connection to god in his TempleOS.
I watched a few Terry's streams and TempleOS seems to be something pretty fluid to use. You literally navigate in the console, or whatever it is called, and can open any file the current cursor points to.
It's not like someone had a bad day and the other side isn't over it. The schism of 1054 was centuries in the making, and even at the time it was largely not in any way impacting lives of average Christians. In the centuries that followed, there were brief periods of reconciliation and further rises in tension.
The sacking of Constantinople in 1204 and its later fall a few decades later made reconciliation far harder, and the ultimate shift of power to Moscow made it practically impossible. The final separation of the churches was formalized in the 1700s.
In all the intervening years, the Roman Catholic Church has doubled down on Papal supremacy and infallibility, something that is anathema to Orthodoxy. Beyond that, centuries of diverging traditions have further entrenched theological differences.
There really isn't any separating the ecclesiastical and theological differences at this point. Even the Protestants, who at first largely opposed the Pope rather than the Roman Catholic Church itself, sought to unify with the Orthodox Church in Moscow and found it to be too different to their liking.
It's a user-less, capability-less microkernel design that enforces access control via the kernel's entity hierarchy. Shared memory ports with various levels of safety are the primary form of IPC, typed at the kernel level.
Currently undergoing later stages of the kernel efficacy stage; if I can prove the design I'll do a more formal writeup. It's been a project in my head for about 8 years and in the editor for about 4 now.
It's surprisingly hard to use 9P and get good performance because the design sort of inherently forbids caching for "real" file data. Trying to add that on top pretty much sacrifices the simplicity and starts looking a lot more like NFSv4.
Fuchsia has a crap load of wild ideas. Microkernel, capabilities, weird app installation system (I think they're trying to make apps more like websites).
https://rtic.rs/ is a pretty cool idea for an embedded RTOS (sort of).
> Most system components run in user-space on a microkernel system. Because of this, bugs in most system components won’t crash the system/kernel.
It's funny because I want this when I write applications. Each library should run in its own sandbox, and by default they shouldn't be able to touch each other's data.
This is something the CHERI architecture[0] (an extension to ARM and RISC-V that implements a capability memory model) can allow this performantly with compiled code (without needing to context switch). This PhD dissertation from Cambridge[1] implements this for C/C++ under CheriBSD (their fork of FreeBSD that supports CHERI).
illumos on RISC-V with CHERI would be the ultimate. There is another variant of RISC-V that is spectre immune. I have also recently heard of approaches at compile-time, such as RESPECTRE, that remove the spectre problem.
Something stupid I always wanted to do was to make an object-oriented language where literally every single object was a separate UNIX process. The naive implementation would have horrendous context switching overhead from the IPC, but maybe there's a clever and elegant way to use shared memory...
The original idea of Smalltalk was very much that :) Sadly, hardware limitations of the time did not allow Smalltalk to be implemented this way. Erlang was likely the first generally available implementation if the idea. (Now you write in Elixir for the same VM.)
It seems like the reduced overhead of cooperative multitasking (vs OS threads or even greenthreads) is so important that people are writing code entirely differently because of it. Like all those promise/future frameworks in Java etc, or NodeJS which works this way natively.
Sorta, but while Erlang/Elixir isolates actors in normal APIs, a erlang process can access most anything using “system calls”. Same for RPCs to other nodes. You can do almost anything a local process can for better or worse.
Some of us are "spoiled" by Rust. About ten years ago the Erlang argument may have been somewhat compelling. Now we use software libraries that don't crash in the first place. Not every Rust library meets that metric, but using Rust as a baseline and a small handful of other patterns/practices it's not hard to meet these days.
Yeah, you're right, Redox using a micro-kernel architecture taking inspiration from Plan9 and seL4 is not new ideas. What Redox is doing differently than the others that is new is successfully delivering these ideas.
Redox has delivered these existing ideas in a manner that will soon enough be (if not already) suitable for production use and available to package for casual non-hacker users. If there is another project that has also done this in a non-academic way, I'd like to see it.
"x86" and "RTOS" don't really work together, given SMM, complex caches, and so on. If you have any sort of high-performance task, you'll likely want to have an separate embedded MCU (or a dozen of them) to control it.
And embedded stuff has a ton of OS'es, such as FreeRTOS, Zephyr, ThreadX... And there are plenty of proprietary solutions, like Nvidia DriveOS.
The embedded OSes are quite limited compared to regular ones like Linux - the task scheduler is present, but everything else (like processes, filesystem, dynamic file loading, binary tools, etc...) is either missing or optional.
I am aware that FreeRTOS and Zephyr are popular but in your opinion, do these form a comprehensive ecosystem and foundation for engineers build robots? I am not aware of any major robotics projects using these MCU OSes as a paradigm (as opposed to an auxiliary component connected to a main OS). I had a robotics colleague at a high profile lab saying that Windows is the de facto standard.
I mostly work with mobile robotics, and using Windows sounds like an absolute craziness to me. The main PC runs some sort of Linux, often with disk in read-only mode.
I've heard this is not the case in all industries, and that many industrial projects (as in factory automation) use Windows, however crazy it may sound. But I don't have a first-hand knowledge of this.
All software I've worked with was built from scratch. We've used plenty of libraries, but this was all generic stuff, all the "comprehensive ecosystem and foundation" was our own. But compared to the actual business logic, that foundation is pretty simple - you need math libraries, some sort of RPC, logging, process management, replay/sim. This does not include device drivers - there is a very good chance you'll need to write them scratch anyway. And none of this is even close in complexity to things like path optimizer.
Thanks for your detailed response. Your observations match my own as well. I do think that the foundation is more complex than your quick comment suggests though (kudos to your team and its foundational work for making it seem trivial. that's exactly what a good framework should do.)
- Industrial for heavy lifting and dangerous tasks beyond human standards (welding, heat, radiation)
- Autonomous vehicles for manufacturing, mining, agriculture, logistics, transport
- Quad- and octa- rotors as well as swarms of such (similar tasks as autonomous vehicles)
- Health care with repetitive chemical mixing where human error can make a dangerous batch
- Food packaging for sanitation and highly repetitive tasks prone to error, stress, and accidents.
- Mining for areas where human interaction is dangerous or prohibitive (depth)
- Military for attacks, surveillance, EM warfare, and long term loitering / denial.
- Supermarkets and malls for restocking, cleaning, and shopping assistance.
- Warehouses and factories for moving and selecting parts
- Toys and educational consumer purchases
- Home cleaning and maintenance (most of what "robot" brings back on shopping, other than toys)
- Automated cooking for condition specific foods (rice, difficult indian meals)
That's an impressive collection of tools and apps they've built there. And yet, it doesn't seem like they succumbed to the temptation of making it self hosting! I guess the assembler would need some work to bring it to parity with nasm... or bring the whole source code closer to Snowdrop ASM!
I’d love to see
Something like this ported to the esp32, maybe on the ttgo vga32 board or something. A basic GUI and shell type OS with SDcard, vga, sound, kb/mouse, wifi, Bluetooth. A modern Commodore-ish 64 experience, with WiFi printing (text only?), a lynx type browser, email, IRC, gopher, etc.
I did the same in the mid-90s but for a 32-bit hobby GUI OS. This book was absolutely essential reading:
https://www.amazon.com/Developing-32-Bit-Operating-System-Cd...
Read it for free: https://web.archive.org/web/20140704223135/https://www.ipdat...
"When Sensory Publishing gained the rights, they changed the name and they printed another run of a thousand to keep it available in print. They are down to 200 copies or so and no longer sell it. The book is now in the public domain and any books will be kept for the Great Alexandria Library."
To anyone who's interested in such projects: also check MenuetOS and KolibriOS (which is a fork of Menuet that diverged a looong time ago). MenuetOS also has a x64 version with SMP which is closed source.
I am interested in learning assembly language. I searched in Coursera but didn't find anything suitable for a total beginner (I have experience in Java and am doing some C/C++ courses to get closer to metal).
This might interest you: Writing a C Compiler by Nora Sandler (No Starch Press). You create a working C compiler that outputs x64 assembly language in the first chapter (as long as the program only returns an integer from main) and then you keep adding features one by one for the rest of the book. You can write the compiler in any language you like (I’m using Python) and you only write the compiler while using your system’s precompiler (the step that handles #include and #define etc and removes comments), linker, and assembler. You just read preprocessed C as text and output assembly as text.
The thing that makes it relevant for learning assembly is that’s what you’re outputting so you’ll be learning that as well as what’s going on with the stack when calling and returning from functions and using local variables and basically everything that corresponds to C. (I’m only on chapter 2.)
Some other reasons it might work out for you is that you are getting into C as well already, and you have a familiar language you could use for the compiler if you wanted: java (assuming it doesn’t take too long to compile and run a java program repeatedly)
>precompiler
s/precompiler/preprocessor/g
, i guess.
Oops. Yes, you're correct.
I highly recomment this NASM tutorial for an introduction to x86-64 https://cs.lmu.edu/~ray/notes/nasmtutorial/
Check out assembly language books by Randall Hyde and Paul Carter, two authors of two different books on the topic.
Search for:
The Art of Assembly Language by Randall Hyde
Carter book:
http://pacman128.github.io/pcasm/
CodeAcademy: https://www.codecademy.com/learn/computer-architecture-assem...
MIT open courseware: https://ocw.mit.edu/courses/6-004-computation-structures-spr...
[dead]
> MenuetOS also has a x64 version with SMP which is closed source.
What's the point of making something like that closed source in 2025?
Would anybody actually use such a thing except for as a hobby OS, on a multi-core X64 machine no less?
It's available for download for free, if that's the concern.
I really doubt that this is the concern.
also TempleOS if you'd prefer something more insane
I was coming to the comments to write this reminds me of Terry Davis, may be rest in peace. It might sound strange but Terry provided me with inspiration and a reminder that anything can be created or “Willed into existence”.
fun fact, last year I had a contractor come to my house. He was a very nice guy. After he was done we were talking and it turned out he was terry’s brother… He told me a lot of stories about him and his life, mental health and death. Pretty sad and interesting..
Amazing, if you would at all be interested in sharing any I am all ears.
Just out of curiosity, how did that get brought up?
Given an infinite multitude of parallel universes, perhaps one exists where TempleOS was in fact the sole and exclusive conduit to divinity and Terry was it's prophet. I hope that is the case.
This instance was that timeline.
Well yes and in that timeline and shall we say warped logic, Terry stated that the random number generator is the direct connection to god in his TempleOS.
Holy C, no less
Holy C is hard to code without crashing Adam. If you type the wrong kind of indirection, the whole OS freezes.
Yes there was no memory protection or anything. All ring 0!
I watched a few Terry's streams and TempleOS seems to be something pretty fluid to use. You literally navigate in the console, or whatever it is called, and can open any file the current cursor points to.
It even has games
This is the best rabbit hole I’ve gone down in awesome. Thanks for sharing!
ZealOS is TempleOS but with support for some modern functionality, however this detracts from the proper TempleOS experience
Be careful, you don't want to start a religious war about ZealOS' use of 32-bit colour.
I mean, look at the East-West schism. The stated reasons for the split are just as stupid.
That's a rather odd take. The ecclesiastical differences alone are irreconcilable, not to mention the theological disputes.
They worked together for a thousand years. Ecclesiastically, the only problem is everybody's refusal to share power again.
It's not like someone had a bad day and the other side isn't over it. The schism of 1054 was centuries in the making, and even at the time it was largely not in any way impacting lives of average Christians. In the centuries that followed, there were brief periods of reconciliation and further rises in tension.
The sacking of Constantinople in 1204 and its later fall a few decades later made reconciliation far harder, and the ultimate shift of power to Moscow made it practically impossible. The final separation of the churches was formalized in the 1700s.
In all the intervening years, the Roman Catholic Church has doubled down on Papal supremacy and infallibility, something that is anathema to Orthodoxy. Beyond that, centuries of diverging traditions have further entrenched theological differences.
There really isn't any separating the ecclesiastical and theological differences at this point. Even the Protestants, who at first largely opposed the Pope rather than the Roman Catholic Church itself, sought to unify with the Orthodox Church in Moscow and found it to be too different to their liking.
This is the kind of quality comment I've come to expect from HackerNews! Well done.
I'm a cradle-Catholic-turned-Atheist, and I still find all of early church history fascinating.
What are the latest cool ideas in OS design, both from a user's viewpoint and from an OS hacker's viewpoint?
It's "quietly public" but I've been working on a novel kernel design, this (12th, and final) rewrite undergoing development for about a year now.
https://github.com/oro-os/kernel
It's a user-less, capability-less microkernel design that enforces access control via the kernel's entity hierarchy. Shared memory ports with various levels of safety are the primary form of IPC, typed at the kernel level.
Currently undergoing later stages of the kernel efficacy stage; if I can prove the design I'll do a more formal writeup. It's been a project in my head for about 8 years and in the editor for about 4 now.
In OSes like these, I always enjoy reading about how the bootloader is kickstarted and how the OS is loaded. I don't know why :)
I find that part interesting too. There are a lot of chicken-and-egg situations you have to solve with them. Interesting breed of challenge.
Plan 9's cool ideas largely still haven't been surpassed or reimplemented.
https://doc.cat-v.org/plan_9/3rd_edition/rio/rio_slides.pdf
It's surprisingly hard to use 9P and get good performance because the design sort of inherently forbids caching for "real" file data. Trying to add that on top pretty much sacrifices the simplicity and starts looking a lot more like NFSv4.
Fuchsia has a crap load of wild ideas. Microkernel, capabilities, weird app installation system (I think they're trying to make apps more like websites).
https://rtic.rs/ is a pretty cool idea for an embedded RTOS (sort of).
Honestly though there's still stuff in Plan 9 that is way more advanced than what Linux does, e.g. https://9p.io/sys/doc/lexnames.html
Genode [1] has an interesting approach to OS design as it is a framework, but how much is assembly I don't know.
[1] https://genode.org
The best answer, given the specific opposite edges you have broadly specified, is
> Most system components run in user-space on a microkernel system. Because of this, bugs in most system components won’t crash the system/kernel.
It's funny because I want this when I write applications. Each library should run in its own sandbox, and by default they shouldn't be able to touch each other's data.
This is something the CHERI architecture[0] (an extension to ARM and RISC-V that implements a capability memory model) can allow this performantly with compiled code (without needing to context switch). This PhD dissertation from Cambridge[1] implements this for C/C++ under CheriBSD (their fork of FreeBSD that supports CHERI).
[0]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[1]: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-949.pdf
illumos on RISC-V with CHERI would be the ultimate. There is another variant of RISC-V that is spectre immune. I have also recently heard of approaches at compile-time, such as RESPECTRE, that remove the spectre problem.
Something stupid I always wanted to do was to make an object-oriented language where literally every single object was a separate UNIX process. The naive implementation would have horrendous context switching overhead from the IPC, but maybe there's a clever and elegant way to use shared memory...
The original idea of Smalltalk was very much that :) Sadly, hardware limitations of the time did not allow Smalltalk to be implemented this way. Erlang was likely the first generally available implementation if the idea. (Now you write in Elixir for the same VM.)
It seems like the reduced overhead of cooperative multitasking (vs OS threads or even greenthreads) is so important that people are writing code entirely differently because of it. Like all those promise/future frameworks in Java etc, or NodeJS which works this way natively.
Practically Erlang
You're describing Elixir/Erlang?
Sorta, but while Erlang/Elixir isolates actors in normal APIs, a erlang process can access most anything using “system calls”. Same for RPCs to other nodes. You can do almost anything a local process can for better or worse.
Some of us are "spoiled" by Rust. About ten years ago the Erlang argument may have been somewhat compelling. Now we use software libraries that don't crash in the first place. Not every Rust library meets that metric, but using Rust as a baseline and a small handful of other patterns/practices it's not hard to meet these days.
Redox is Unix-like. It's not going to contain any significantly new ideas.
Yeah, you're right, Redox using a micro-kernel architecture taking inspiration from Plan9 and seL4 is not new ideas. What Redox is doing differently than the others that is new is successfully delivering these ideas.
Redox has delivered these existing ideas in a manner that will soon enough be (if not already) suitable for production use and available to package for casual non-hacker users. If there is another project that has also done this in a non-academic way, I'd like to see it.
In a similar spirit, what are some progresses in performant RTOSes for robotics? There seems to be relatively less interest in that field.
No, ROS/ROS2 is not an operating system and is not what most people call performant software.
"x86" and "RTOS" don't really work together, given SMM, complex caches, and so on. If you have any sort of high-performance task, you'll likely want to have an separate embedded MCU (or a dozen of them) to control it.
And embedded stuff has a ton of OS'es, such as FreeRTOS, Zephyr, ThreadX... And there are plenty of proprietary solutions, like Nvidia DriveOS.
The embedded OSes are quite limited compared to regular ones like Linux - the task scheduler is present, but everything else (like processes, filesystem, dynamic file loading, binary tools, etc...) is either missing or optional.
I am aware that FreeRTOS and Zephyr are popular but in your opinion, do these form a comprehensive ecosystem and foundation for engineers build robots? I am not aware of any major robotics projects using these MCU OSes as a paradigm (as opposed to an auxiliary component connected to a main OS). I had a robotics colleague at a high profile lab saying that Windows is the de facto standard.
I mostly work with mobile robotics, and using Windows sounds like an absolute craziness to me. The main PC runs some sort of Linux, often with disk in read-only mode.
I've heard this is not the case in all industries, and that many industrial projects (as in factory automation) use Windows, however crazy it may sound. But I don't have a first-hand knowledge of this.
All software I've worked with was built from scratch. We've used plenty of libraries, but this was all generic stuff, all the "comprehensive ecosystem and foundation" was our own. But compared to the actual business logic, that foundation is pretty simple - you need math libraries, some sort of RPC, logging, process management, replay/sim. This does not include device drivers - there is a very good chance you'll need to write them scratch anyway. And none of this is even close in complexity to things like path optimizer.
Thanks for your detailed response. Your observations match my own as well. I do think that the foundation is more complex than your quick comment suggests though (kudos to your team and its foundational work for making it seem trivial. that's exactly what a good framework should do.)
I think people who are serious about it run QNX or VxWorks. Most robotics projects aren't serious and run Ubuntu unfortunately.
I don't think you're familiar with modern robotics.
The central control plane is Ubuntu, but the boards for actuators and sensors are all microcontrollers on some kind of RTOS or FPGAs.
Not being familiar with the field, what counts as modern robotics?
Performing a quick survey of available recent papers in the field, came back with these summary works:
Robotics and Industry 4.0, https://www.researchgate.net/profile/Sudeep-Tanwar/publicati...
Elements of Robotics (book), https://library.oapen.org/bitstream/handle/20.500.12657/2782...
Modern Robotics (limited pages), https://www.google.com/books/edition/Modern_Robotics/5NzFDgA...
Looks like:
I'm not sure what you're asking here. This just looks like a chatgpt dump.
Can confirm. $DAYJOB makes robots subject to hard worst-case latency constraints. The product runs on QNX.
Not an RTOS as is commonly understood but RTIC is nice. I think originally developed for robotics.
https://rtic.rs
Related. Others?
Homebrew an OS from Scratch? Snowdrop Shows How It's Done - https://news.ycombinator.com/item?id=39005640 - Jan 2024 (1 comment)
Snowdrop OS – a homebrew operating system from scratch, in assembly language - https://news.ycombinator.com/item?id=28090574 - Aug 2021 (3 comments)
To be clear: x86 assembly.
To be even clearer, 16-bit real mode x86 assembly.
That's an impressive collection of tools and apps they've built there. And yet, it doesn't seem like they succumbed to the temptation of making it self hosting! I guess the assembler would need some work to bring it to parity with nasm... or bring the whole source code closer to Snowdrop ASM!
Kudos, quite an impressive work.
V32, BASIC compiler. :)
Well we can make feature requests, I guess.
I’d love to see Something like this ported to the esp32, maybe on the ttgo vga32 board or something. A basic GUI and shell type OS with SDcard, vga, sound, kb/mouse, wifi, Bluetooth. A modern Commodore-ish 64 experience, with WiFi printing (text only?), a lynx type browser, email, IRC, gopher, etc.
"Requirements for building Snowdrop OS
Works on: Windows XP 32bit, Windows 98, Windows 95"
At least they provide an ISO/IMG. I still wish SerenityOS would do this.
Serenity has nightly build images https://serenity-builds.halves.dev/
But Serenity does not provide them.
This does run on the MiSTer!
Looks like menuetos, but 16 bit.
Does it run Black Ops 6?
Reminds me of TempleOS.
[dead]
Totally RAD!