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.
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.
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.
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.
https://www.amazon.com/Developing-32-Bit-Operating-System-Cd...
reply