drv/usb/struct: remove usage of value{}
drv/usb/uhci: struct-ify
mem/cons: struct-ify
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.
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.
None of the files in the Dusk OS distribution contain any binary file, that is, any file that contain a ASCII control character.
A handful of files, that is, files under the fs/data directory, actually
need to contain such characters, but these files are distributed under the
encodedbin directory, encoded as base64. The corresponding binary files are
generated by the makefile.
The reason for doing so is to prepare the field to eventually ditch git as a VCS and publish Dusk as a series of release tar bundles along with a series of patches leading to the next release bundle.
diff doesn't like binary contents.
Why bother with all this? For dogfooding reasons. Dusk OS might eventually
contain tools to explore git repositories, but it's never going to include
git as a full VCS tool. Way too complex. It might, however, contain
equivalents to patch and diff.
Considering this, we might as well develop Dusk in a manner that is already consistent with this design goal.
Tools to facilitate working with such publishing scheme are already under development. One such tool is PVC.
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 -