~vdupras/duskos

32-bit Forth OS mixed with C

3a312bd Add lib/io, which defines stdin

~vdupras pushed to ~vdupras/duskos git

9 hours ago

ab600cc Move a few words from boot.fs to lib/core

~vdupras pushed to ~vdupras/duskos git

15 hours ago

#Dusk OS

Dusk OS is a 32-bit Forth and big brother to Collapse OS. It does everything Collapse OS does, has the same laser sharp focus on simplicity, but has a widened scope:

  • Runs on as many modern devices as possible.
  • Access a wide variety of filesystems.
  • Access a wide variety of storage devices, including modern ones.
  • Access, visualize and print images and PDFs.
  • Compress and decompress files.
  • Edit and compile C code. Possibly other languages too.
  • No focus on binary size (unlike Collapse OS, we have plenty here).

Additionally, it's worth mentioning that as a consequence of its laser sharp focus on simplicity, Dusk OS is also defined by what it doesn't do:

  • Not POSIX
  • No security (single user)
  • No focus on speed

Depending on the simplicity tradeoffs, it's also possible that it has:

  • No concurrency
  • No networking

#Why build this OS?

This operating system's goal is to allow its users to maximally operate the machines they have during the first stage of civilizational collapse.

Most modern operating systems can do all of the above and are self-contained, self-hosting. Why do we need another one? Simplicity.

It's difficult to predict post-collapse conditions, but we can suppose that many users will need to use their machines in novel and creative ways. Hackability of the operating system then becomes paramount. Open source modern operating systems all can be modified to fit its user's needs, but their complexity limits the likelihood that the user is able to do so. A simpler OS increases this likelihood.

But we can't have our cake and eat it too, right? Either you have a simple toy OS or a complex one. Well, maybe not?

Its authors believe that in the history of computing, Forth has been under-explored. Its approach to simplicity is, we think, revolutionary. It has significant shortcomings when system specifications become more complex (Forth hates complexity and doesn't manage it well), but we believe it possible to elegantly marry it with languages that like complexity better.

This mix, we believe, could provide a creative user with computing powers rarely seen with other approaches. We've got to try it.

To be clear: this is a research project, we don't know what it will yield beforehand. We have the intuition that it might lead to a big "ah ah!" moment and reveal a breathtaking combination of power and simplicity.

#A whole OS built from source on boot

One thing that makes Dusk OS special is that it boots from a very tiny core (900 lines of x86 assembly). From this tiny core, on boot, it builds its way up to a system that has a functional C compiler, which then allows it to bootstrap itself some more.

With regards to "source bootstrapping", it's even more extreme than Collapse OS because modern machines allows this process to run very fast and the whole process is not much slower than a regular Linux boot. On Collapse OS target machines, this process would be prohibitive, so a bigger part of the OS is cross-compiled into the kernel.

This peculiarity of Dusk OS has interesting properties. The nicest one, in my humble opinion, is that this allows us to sidestep the entire problems of binary compatibility and relocation and only deal with source compatibility. So, no ELF, not binutils, only code that is designed to run from where it was written in the first place. This is so much simpler!

Object files? Global symbols? Nah. C functions that don't have a static storage type are simple Forth words.

#Roadmap

Here's the plan so far:

  1. Have a 32-bit Forth written in x86 run on top of of a Linux system.
  2. Create a pseudo C compiler that is partly written in Forth and has the peculiarity of bootstrapping itself from it. No binary except Dusk's core.
  3. Target a machine (probably legacy PC) and have it run bare metal on it.
  4. Self-host.
  5. Steal drivers from Linux and/or BSD kernels to widen hardware support.
  6. Port exiting POSIX applications so that Dusk OS fulfills its stated goals.
  7. Add support for more machines.

#Status

Currently working on step 2 of the roadmap. The C compiler has a fair chunk of the language implemented already. You can see a sample of what it compiles in fs/tests/cc/test.c. Its technical documentation is at fs/doc/cc.txt. What's missing currently is:

  • ops width depending on type (everything is dword)
  • struct, union
  • typedefs
  • global variables
  • for, while, switch, goto
  • string literals
  • floats
  • a few ops here and there
  • preprocessing
  • the check phase (anything that is currently understood by the parser is compiled no matter how nonsensical).
  • the stdlib (but it's going to be significantly different than a regular C stdlib, see fs/doc/cc.txt)
  • probably countless bugs

So, there's a fair chunk of work left, but there's also a lot that's already done.

Development happens on sourcehut.

Unlike Collapse OS which is a personal effort and doesn't lend itself well to collaboration, Dusk OS' wider scope makes it fitting for a collaborative effort. Let's discuss this on its public mailing list.

#Build and run

To build Dusk OS, you need:

  • GNU Make
  • GNU binutils
  • nasm
  • A x86-compatible Linux kernel to run this on

Run make and then run ./dusk. You'll get a prompt. Documentation is lacking for now, you'll have to look at the source to have an idea of available vocabulary. Type bye to quit.

There is some documentation in /fs/doc.

Dusk OS expects a raw input. With a regular TTY, your input will be buffered and echoed twice. To avoid that, you can invoke it like this:

(stty -icanon -echo; ./dusk; stty icanon echo)

make run does this for you.

#Running OpenBSD?

You might be interested in this thread from the mailing list.