[HN Gopher] Snowdrop OS - a homebrew operating system from scrat...
___________________________________________________________________
Snowdrop OS - a homebrew operating system from scratch, in assembly
language
Author : ksec
Score : 294 points
Date : 2025-01-24 16:40 UTC (1 days ago)
(HTM) web link (sebastianmihai.com)
(TXT) w3m dump (sebastianmihai.com)
| hsnewman wrote:
| This does run on the MiSTer!
| thebeardisred wrote:
| To be clear: x86 assembly.
| Narishma wrote:
| To be even clearer, 16-bit real mode x86 assembly.
| vdupras wrote:
| 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!
| DustinBrett wrote:
| At least they provide an ISO/IMG. I still wish SerenityOS would
| do this.
| haunter wrote:
| Serenity has nightly build images https://serenity-
| builds.halves.dev/
| mouse_ wrote:
| But Serenity does not provide them.
| pjmlp wrote:
| Kudos, quite an impressive work.
|
| V32, BASIC compiler. :)
|
| Well we can make feature requests, I guess.
| Tiberium wrote:
| 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.
| spogbiper wrote:
| also TempleOS if you'd prefer something more insane
| mihular wrote:
| Holy C, no less
| nurettin wrote:
| Holy C is hard to code without crashing Adam. If you type
| the wrong kind of indirection, the whole OS freezes.
| unixhero wrote:
| Yes there was no memory protection or anything. All ring
| 0!
| meifun wrote:
| 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".
| idiotsecant wrote:
| 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.
| Not4Hire wrote:
| This instance was that timeline.
| unixhero wrote:
| 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.
| tiagobraw wrote:
| 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..
| cmt8 wrote:
| Just out of curiosity, how did that get brought up?
| meifun wrote:
| Amazing, if you would at all be interested in sharing any
| I am all ears.
| ksp-atlas wrote:
| ZealOS is TempleOS but with support for some modern
| functionality, however this detracts from the proper TempleOS
| experience
| philistine wrote:
| 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.
| zdragnar wrote:
| That's a rather odd take. The ecclesiastical differences
| alone are irreconcilable, not to mention the theological
| disputes.
| philistine wrote:
| They worked together for a thousand years.
| Ecclesiastically, the only problem is everybody's refusal
| to share power again.
| zdragnar wrote:
| 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.
| TheAmazingRace wrote:
| 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.
| markus_zhang wrote:
| 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.
| unixhero wrote:
| It even has games
| theoreticalmal wrote:
| This is the best rabbit hole I've gone down in awesome.
| Thanks for sharing!
| noisy_boy wrote:
| 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).
| asalahli wrote:
| I highly recomment this NASM tutorial for an introduction to
| x86-64 https://cs.lmu.edu/~ray/notes/nasmtutorial/
| fuzztester wrote:
| 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/
| drivers99 wrote:
| 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)
| thinkling wrote:
| CodeAcademy: https://www.codecademy.com/learn/computer-
| architecture-assem...
|
| MIT open courseware:
| https://ocw.mit.edu/courses/6-004-computation-structures-
| spr...
| miki123211 wrote:
| > 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?
| spookie wrote:
| It's available for download for free, if that's the concern.
| seethedeaduu wrote:
| I really doubt that this is the concern.
| amelius wrote:
| What are the latest cool ideas in OS design, both from a user's
| viewpoint and from an OS hacker's viewpoint?
| honestSysAdmin wrote:
| The best answer, given the specific opposite edges you have
| broadly specified, is https://redox-os.org/
| amelius wrote:
| > 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.
| guerrilla wrote:
| 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...
| drekipus wrote:
| Practically Erlang
| nine_k wrote:
| 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.)
| iforgot22 wrote:
| 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.
| honestSysAdmin wrote:
| https://learning-0mq-with-
| pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pair.html
| bboygravity wrote:
| You're describing Elixir/Erlang?
| elcritch wrote:
| 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.
| Aaron2222 wrote:
| 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
| honestSysAdmin wrote:
| 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.
| IshKebab wrote:
| Redox is Unix-like. It's not going to contain any
| significantly new ideas.
| honestSysAdmin wrote:
| 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.
| IshKebab wrote:
| 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
| mycall wrote:
| 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
| machinestops wrote:
| 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
| yencabulator wrote:
| 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.
| junon wrote:
| 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.
| unixhero wrote:
| 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 :)
| junon wrote:
| 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.
| quanto wrote:
| 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.
| doelie_ wrote:
| Not an RTOS as is commonly understood but RTIC is nice. I think
| originally developed for robotics.
|
| https://rtic.rs
| bigfishrunning wrote:
| I think people who are serious about it run QNX or VxWorks.
| Most robotics projects aren't serious and run Ubuntu
| unfortunately.
| m00x wrote:
| 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.
| araes wrote:
| 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/bits
| tream/handle/20.500.12657/2782...
|
| Modern Robotics (limited pages), https://www.google.com/boo
| ks/edition/Modern_Robotics/5NzFDgA...
|
| Looks like: - 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)
| rubicks wrote:
| Can confirm. $DAYJOB makes robots subject to hard worst-case
| latency constraints. The product runs on QNX.
| theamk wrote:
| "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.
| quanto wrote:
| 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.
| theamk wrote:
| 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.
| Jotalea wrote:
| Reminds me of TempleOS.
| notorandit wrote:
| Looks like menuetos, but 16 bit.
| qingcharles wrote:
| 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...
| dang wrote:
| 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)
| xiaodai wrote:
| Totally RAD!
| K0balt wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-25 23:01 UTC)