Distinguishing Features

Lethe is built around the Dhar programming language and the Sidestep window toolkit. It is the first desktop operating system project in decades designed with the intent of building a full-stack system, from kernel to WYSIWYG office suite, under a single consistent vision.

User Model and Security

User accounts are secured by a case-insensitive username, and a multi-word passphrase of at least 16 characters.

A user group is a user account with logins disabled—users are hierarchical and inherit the permissions of their ancestors by default. Typical user accounts are descended from common, which grants execute access to local applications and read access to local files.

Under CHASM, each page of memory has its own read, write, and executable flags for each process, allowing the CPU to enforce policies like one-directional channels with no buffer copying, and to prevent execution exploits entirely.

Programs are designed around capabilities-based security: although the user may type the name of a resource (such as a filename) at the shell, all programs have statically-typed arguments, so the name is converted into a handle to an object owned by the kernel before it is passed to the target program. This eliminates the confused deputy problem (where a server fails to check a client's rights before carrying out a task on the client's behalf.)

The Lethe System Layout

The standard UNIX directory namespace has been around for fifty years, and has been a trainwreck for at least forty. Lethe's layout will feature:

Unix-like names are expanded to full words, but chosen so that the first two letters are unique for easy tab completion
Plurals are avoided in most cases, except for mass nouns like "Settings"
Heavy use of virtual filesystems providing directory unions and translated filesystems

Concrete Layout

The Lethe filesystem mounts at the path /local/, equivalent to / on Unix or C:\ on Windows. It contains the following real directories:

common/
common/application/
common/command/
common/config/
common/framework/
common/package/
common/system/
common/service/
common/share/
common/type/
user/
user/application/
user/command/
user/config/
user/framework/
user/package/
user/share/
user/type/
user/work/

Consequently, the username common is reserved. (Remember that user groups are a special type of user account.)

Virtual Layout

/local/ also contains a number of virtual directories, which are comprised of unions of directories from other sources:

common/documentation/ contains links to:
- ../application/*/documentation/
- ../command/*/documentation/
- ../framework/*/documentation/
- ../package/*/documentation/
- ../service/documentation/
- ../system/documentation/
common/reference/ contains links to:
- ../application/*/reference/
- ../command/*/reference/
- ../framework/*/reference/
- ../package/*/reference/
- ../service/reference/
- ../system/reference/
common/source/ contains links to:
- ../application/*/source/
- ../command/*/source/
- ../framework/*/source/
- ../package/*/source/
- ../service/source/
- ../system/source/
user/documentation/ contains links to:
- ../application/*/documentation/
- ../command/*/documentation/
- ../framework/*/documentation/
- ../package/*/documentation/
user/reference/ contains links to:
- ../application/*/reference/
- ../command/*/reference/
- ../framework/*/reference/
- ../package/*/reference/
user/source/ contains:
- ../application/*/source/
- ../command/*/source/
- ../framework/*/source/
- ../package/*/source/

This allows for both self-contained applications that bundle all their files together and the Unix-like practice of distributing files throughout the system by type for easy indexing. Removing most programs is as simple as deleting them from the application/ directory.

Special Filesystems

These virtual directories are managed by special handlers:

Removable media appears automatically mounted within /local/.
/local/device/ contains devices representing all the drivers that the user is allowed to access directly on the current machine. These are similar to Unix device files but expose object-oriented message-passing interfaces rather than primitive text streams.
/session/device/ contains just the devices in use by the current session, like Plan 9.
/session/temp/ is deleted on logout or reboot.
/session/ram/ allows storing files in the RAMdisk.
/local/common/data and /local/user/data access objects in the Hekarti hierarchical document database.
/local/object/ and /local/user/object/ contain the software counterpart of device files: objects like semaphores, sockets, and pipes for various running programs. These can be opened for RPC by local or remote programs, similar to pipes in 9P, but again with structured data.
/remote/ contains protocol translators for filesystems:
- /remote/ftp/host/file (FTP)
- /remote/http/host/directory (HTTP/1.1 GET)
- /remote/lethe/host/directory (Lethe 9P-like protocol)
- /remote/nfs/host/directory (Sun NFS)
- /remote/smb/host/directory (Microsoft CIFS)
- /remote/styx/host/file (Plan9 9P)
Host-protocol pairs in /remote/ are added with a suitable connect command that also includes login information. /remote/lethe/ is an exception and will attempt auto-discovery via COVEN (a domain service) to discover machines willing to show files to your user account.

Network Neighbors

If a machine on the LAN has files to share with your user account via the lethe protocol, it is automatically mounted on login as well, at /host/, with the same structure found in /local/ on that machine. This can also be accessed via /remote/lethe/host/, as described above.

Contexts

The root directory is a view into the filesystem rather than a concrete directory. It is comprised of the following, in descending order of importance, from the perspective of user:

Special mounted directories
/local/common/
/local/user/
/local/*/share/
/local/group/ (for all groups that user is a member of)
/host/common/ (for all hosts that user can log into)
/host/user/user/ (for all hosts that user can log into)
/host/*/share/ (for all hosts that user can log into)
/host/group/ (for all groups that user is a member of, on all hosts that user can log into)

Where * in this case is the union of all user and group names. A group is actually just a 'parent' user account with login disabled.

If the user has a directory on the local machine called foo/, and there are no other directories by that name in any of the other places listed above, then the following paths are equivalent:

/foo/
/local/foo/
/local/user/user/foo/
/user/foo/
/remote/lethe/localhost/user/foo/

If, say, both /local/common/foo/ and /local/user/foo/ existed, then /foo/ would combine the contents of both, preferring files with higher precedence (/local/common/foo/bar would shadow /local/user/foo/bar). Creating new files works the same way, with the caveat that

There are also views at /local/ and /host/ with similar properties.

/	root directory
/base	userland for single-user mode (like POSIX /bin)
/config	global system configuration files (like POSIX /etc)
/data	Hekarti hierarchical object database (virtual)
/data/type	file type handlers, named by MIME type
/data/http	pages used by the Hekarti web CMS, organized by domain
/device	device files (virtual, like POSIX /dev)
/local	user data and desktop applications
/local/Application	application bundles
/local/Documentation	directory union including */local/Application//Documentation**
/local/Documentation/System	system documentation (non-virtual)
/local/Framework	installed libraries accessible by all desktop applications
/local/Framework/Font	font files accessible by all desktop applications
/local/Framework/Type	file type handlers owned by shared desktop applications
/local/Project	user projects with no single owner
/local/User	user home directories
/local/User/name/Application	private applications owned by the user
/local/User/name/Documentation	virtual union of */local/User/name/Application//Documentation**
/local/User/name/Framework/Font	private font files
/local/User/name/Framework/Type	private file type handlers
/local/User/name/Personal	private files
/local/User/name/Project	projects owned by name
/local/User/name/Public	public files; by default, allows read-only mounting by others
/local/User/name/Settings	configuration options for applications
/local/User/name/Trash	files awaiting final deletion
/local/User/name/Workspace	default directory for downloads and new files
/local/User/name/label	saved mounts automatically appear in home, e.g. NFS or FTP
/local/label	removable storage disks are automatically mounted under /local
/object	system libraries
/object/remote	mounted RPC objects from other systems
/pack	package manager cache
/process	objects for each running process (virtual, like /proc)
/process/pid/window/wid	window wid for process pid
/remote	remote protocols exposed by daemons (virtual)
/remote/styx	9P
/remote/data	/remote/data/localhost == /data
/remote/ftp	File Transfer Protocol
/remote/http	Hypertext Transfer Protocol
/remote/object	/remote/object/localhost == /object
/remote/scp	Secure Copy
/remote/sftp	Secure File Transfer Protocol
/remote/nfs	Network File System
/service	daemons, drivers, servers
/service/device	programs that auto-start when a compatible /device entry appears
/service/remote	translators for remote filesystems
/service/local	translators for local filesystems
/source	uncompiled
/source/Application	virtual union of */local/Application//source**
/source/base	source code for /base
/source/Framework	virtual union of */local/Framework//source**
/source/object	source code for /object
/source/private/Application	virtual union of */local/User/name/Application//source** for current user
/source/private/Framework	virtual union of */local/User/name/Framework//source** for current user
/source/service	source code for /service
/source/system	source code for /system
/system	kernel and bootloader
/type	file type handlers (template dhar)

In the case of Documentation and source unions, the directories are renamed according to their bundles; e.g. /source/Application/PasteUp is backed by /local/Application/PasteUp/source.

PetraFS, the Lethe Filesystem

Lethe makes heavy use of virtual filesystem unions that are beyond the scope of typical POSIX systems. The Petra Filesystem is proposed as a naive but well-intentioned solution to this problem. The Petra spec supports versioning, reference counting, symbolic links, granular permissions, ACLs, and origin tracking, and provides containers for OS-defined encryption, compression, data deduplication, and B-tree sector hierarchies.

Petra also provides basic tools for error detection and data recovery, although it lacks error correction, self-healing, or automatic defragmentation.