Userspace

Userspace programs are ordinary std Rust binaries with a main(). They target x86_64-unknown-edos and link a forked Rust std, so String, Vec, std::fs, std::thread and std::net are all there and mean what you expect.

That is the point of the fork: no #![no_std], no custom C library, no bespoke entry macro.

What ships

128 binaries land in /bin. The shell and the modal editor install under their short names, sh and vi, though their crates are edos-sh and edos-vi:

Session: edos-init, svc, edos-wm, edos-taskbar, edos-terminal, edos-files, sh, vi, edos-procview

Coreutils: cat, cp, mv, rm, mkdir, rmdir, ls, ln, touch, stat, file, head, tail, wc, cut, tr, sort, uniq, tee, grep, sed, diff, find, du, df, dd, xargs, seq, yes, true, false, echo, env, printenv, basename, dirname, which, sha256sum, hexdump, cal, date, sleep, sync, tar, gzip, gunzip, less, id, whoami, mkfifo, hello

System: ps, pstree, top, kill, free, uname, nproc, dmesg, mount, lsof, pmap, watch, strace, write, shutdown, keymap, efs-mkfs, fsck, edos-install

Network: ping, dns, dnsprobe, http, wget, nc, netstat, httpd, tcpecho, sntp, sshd, lookupd, a caching name lookup daemon that every program reaches without being rebuilt, and edos-web, a browser: an address bar, history, links and fragments, CSS, images and tables, laid out in a window

Media: play, which pushes WAV data at /dev/dsp, and imgview, which reads PNG, WebP, JPEG, BMP and SVG

Packages: grab, the package manager, and edos-grab, its graphical front end. The graphical editor edos-edit is the first program that ships through them rather than in the image: it is built in this tree like everything else, but published to the repository instead of installed to /bin.

Screen: screenshot, which writes the framebuffer to a BMP. A pointer the display holds on its own cursor plane is not in the framebuffer, so a capture says which kind of pointer is on screen.

Profiling: profile, which samples every CPU from the timer tick and writes the addresses out for the host to resolve. It cannot see code running with interrupts disabled, which is the whole kernel heap and the frame allocator, so it is one of two instruments rather than the instrument.

Games: snake

Tests: alloctest, forktest, exectest, killtest, threadtest, iotest, mmaptest, evicttest, inflighttest, lockordertest, lookuptest, pitest, tcptest, vectest, wintest, fstest, sigtest, socktest, stdtest, orphantest, syscallfuzz, auxvtest, fputest, texttest, fbtest, filetest

Three of those exist because a program that compiles is indistinguishable from a program that works until something runs it. texttest pipes fixture input through the nine text coreutils and diffs each against an expected string; filetest does round trips through tar, gzip, gunzip, ln and tee, since an archive that lists and extracts to the bytes that went in is what catches an option read as a filename; fbtest asks the /dev/fb ioctls for more bytes than they were given, which they used to answer.

Benchmarks: fsbench for the filesystem, switchbench, latbench, balancebench and pollbench for the scheduler and poll paths, allocbench for the userspace heap, termbench for the terminal widget with no window and no compositor behind it

The test programs are the regression suite, not demos. syscallfuzz reads the call table out of /proc/syscalls and drives every entry in it with poisoned arguments, so it covers a syscall added after it was written without being touched; it found two kernel panics the day it was written.

The shell

edos-sh is a scripting language, not a command dispatcher: functions, control flow, $(( )) arithmetic, globbing, heredocs and job control. Blocks end with end, so there is no fi, done or esac.

#!/bin/sh
for file in $(ls /bin)
    if [ -f /bin/$file ]
        echo "program: $file"
    end
end

Job control is real. Each pipeline gets its own process group and the terminal goes to whichever is in the foreground, so Ctrl+C on sleep 30 | cat kills both stages.

Full reference: Shell scripting.

The file manager

edos-files makes the desktop usable without a shell: browse, open, rename, delete, make a folder. A .bmp or .svg opens in imgview, text in the editor.

The places rail is the kernel’s mount table, not a favourites list, so it can only offer somewhere that exists. The meter under it describes the volume you are standing in: efs on /, 4.9G free, or memfs on /tmp, in memory, forgotten on reboot.

Every size carries a bar, scaled across the sizes in view rather than from zero. From zero, a directory of binaries that all sit between 66K and 157K is a column of identical bars. Scaled to what is on screen, it ranks them.

The editors

Two, split by transport. edos-edit owns the window. edos-vi owns the terminal, and is the only one that works over SSH.

edos-edit is graphical and non-modal: a file tree, a tab per open file, Ctrl+S. Find, go to line, undo that takes back a word rather than a letter, and syntax colouring for Rust, C, TOML, JSON, shell and Markdown.

The bars in the gutter mark every line that differs from the file on disk. There is no version control on this machine, so that is the only diff you get: it shows what you have changed, before you save it.

Colours come from Ayu, the theme the rest of the desktop already uses, so a directory in the file manager and a type name in the code are the same blue.

edos-vi is a vi-like modal editor: normal and insert modes, the usual motions, and :w, :q, :q!.

Libraries

Crate	What it gives you
edos_lib	syscall wrappers the fork does not surface through std: networking extras, shared memory, process control, timing, keymaps
edos_render	textures, a widget toolkit with layout, and the window syscalls
edos_http	HTTP/1.1 with TLS through rustls, and RFC 3986 URL parsing and joining
edos_rt	the runtime the std fork is built on, published to crates.io

Writing one

See Writing a program.