uefi: we have a filesystem! all tests passing!
drv/uefi/blkio: implement io/drive interface!
io/drive: add the concept of drive buffer alignment
Dusk OS is a 32-bit Forth and big brother to Collapse OS. Its primary purpose is to be maximally useful during the first stage of civilizational collapse, that is, when we can't produce modern computers anymore but that there's still many modern computers around.
It does so by aggressively prioritizing simplicity at the cost of unorthodox constraints, while also aiming to make operators happy.
Dusk OS innovates by having an "almost C" compiler allowing it to piggy-back on UNIX C code, through a modest porting effort, to reach its goals and stay true to its design constraints with a minimal effort.
This is Dusk OS' source code and the rest of the README assumes that you want to run it. To read more about why this OS exists, see its website. To see where it's going, you can look at the roadmap.
Dusk is designed to run on bare metal and to build itself from itself.
However, it's also possible to build Dusk from any POSIX platform using
Dusk's POSIX VM from posix/vm.c. This VM implements a Forth
that can interpret the whole of Dusk's Forth code in a CPU-agnostic manner.
That is enough to generate bare metal images for any of its target platforms, so that's why it exists. To build this VM, you need:
Running make will yield a ./dusk binary which if opened, provides an
interactive prompt.
Documentation lives in fs/doc/. You can begin with doc/index. If
you're running the "grid" or "graphics" flavor of Usermode Dusk, you can type
"help" to invoke the in-system help.
Type bye to quit.
Dusk OS expects a non-canonical raw input. With a regular TTY, your input will be buffered and echoed twice and reads to it will be blocking. We don't want that. To avoid that, you can invoke it like this:
(stty -icanon -echo min 0; ./dusk; stty icanon echo)
make run does this for you.
The basic POSIX Dusk deals with streams only. You can't use the grid or graphics from within there. However, it's possible to build a "curses" version or a "SDL" version of Dusk that has these capabilities. See the POSIX VM README for details.
Graphics from within SDL, cool right? It gets even better: Usermode Dusk allows you to run these things at native speed. See Usermode README for details.
Even if Dusk is super powerful even within the constraints of a POSIX environment, it unleashes its full powers on bare metal.
Deploying Dusk on a real machine is a bit more involving than running the POSIX
VM and you should read doc/deploy.txt. There's a collection of deployment
configurations in the deploy directory to help you get started
on deploying Dusk OS to your machine.
This directory contains a few targets with convenient QEMU launchers, so this can be a good way to quickly see a fully featured Dusk OS in action.
The Collapse OS project lives inside Dusk OS which has a compatibility layer allowing it to run Forth code in "Collapse OS mode", which makes it the simplest way around to bootstrap a seed Collapse OS binary.
To be sure: Collapse OS is fully self-hosting and doesn't need Dusk OS to build itself, but if you don't already have a Collapse OS environment handy, then you need a way to craft your first Collapse OS image. Dusk OS is this way.
Collapse OS itself doesn't contain any machine-specific code so it can't, by itself, build an image for a real machine. That machine-specific code live in different repositories all around. The list of known Collapse OS ports to real machines is available on Collapse OS' website.
As of 2023-12-13, I began signing my commits with my old Gentoo developer key.
This key is present in this repository under the file signkey. Of course, you
can't trust this very text telling you that this key is indeed used by the
author of this project, but at least this simple scheme allows a "trust on first
use" pattern. Once you've made the leap of faith importing this key, you can
trust that the person signing the repo doesn't change.
Moreover, I've used my old Gentoo developer key for a reason: it allows you to make that leap of faith more easily. You can use the same key to verify commits made by me in the Gentoo repository.
To verify commits or release tag, it goes thus:
cd duskos
gpg --import signkey
git verify-commit master
git verify-tag v10
I don't sign 100% of the commits, but the vast majority. All tags are signed.
In peripheral repositories such as dusk-examples, the makefiles automatically download targz bundle from sourcehut. These bundles are not signed, but commits in those repositories are signed and those makefiles have checksums that they match downloaded bundles with. So even if sourcehut was compromised, you can trust the process (if you trust me, of course).
Those targz bundles on sourcehut are not generated by me, but by sourcehut.
Theoretically, if sourcehut is compromised, those generated bundles could
contain malicious code, so one has to check their contents against a verified
git commit. It's a bit tricky to do because of the compression, which produces
system-dependent contents. Normally, you don't have to check for this yourself,
I do. But if you want to do it, here's how you'd do for the tag v10:
git verify-tag v10
curl -O https://git.sr.ht/~vdupras/duskos/archive/v10.tar.gz
gunzip v10.tar.gz
git archive --prefix=duskos-v10/ v10 | cmp v10.tar -