Skip to main content

What is not done

  • Slovak eID beyond signing in. The eID klient runs in a machine and signs in to slovensko.sk (the Slovak eID), but D.Signer, which the same download carries for qualified signatures on documents, is not set up anywhere, and the eID klient is x86_64 only, so an arm64 PC has neither. Nobody has signed in with a real card through a machine yet, or to the computer itself (signing in with the eID), and Settings has no row for eID sign-in: losos-eid-signin sets it up.

  • arm64 macOS. qemu-vmapple runs vmapple under TCG with an M1 CPU on a PC, or under KVM on an arm64 host, with a GPU from Reims. Nobody has booted macOS on it yet, no guest has drawn through Reims, and nothing in derisk starts it. arm64 macOS machines lists the rest.

  • Peripherals in their machines. Peripherals moves USB devices and Bluetooth radios into machines of their own. Some of it is not finished:

    • Bluetooth headphones pair and connect in sys-bluetooth, but there is no PipeWire there and no path for their sound to the host's.
    • A camera reaches apps on the host as one size, 1280x720, whatever the camera can do, and its own microphone goes to its machine with it, where nothing carries its sound to the host. Sound cards play and record through the host's PipeWire, printers print from the host's CUPS, and cameras film through a v4l2loopback device.
    • A printer's scanner goes to its machine with it, and nothing there scans. A printer Gutenprint and CUPS have no driver for, and that speaks neither IPP over USB, PostScript nor PCL, gets no queue.
    • A keyboard or mouse plugged into a port sys-usb holds comes to the host over USB/IP, so the host parses its HID descriptors. Qubes's input proxy, which passes only key and pointer events, is not done.
    • A Bluetooth radio that is not on USB, on a UART or SDIO as on some Arm laptops, stays the host's, and Settings does not see it.
    • Every part has run only in virtual machines: the router, sys-usb and a receiving machine nested in QEMU, and controller passthrough through QEMU's emulated IOMMU (nixos/tests/peripherals.nix). None of it has met a PC's own USB controllers or a real Bluetooth radio.

  • The gaming machine. The gaming machine needs a second graphics card. Some of it is not finished:

    • A PC with one card cannot hand it to the machine and take it back while the desktop waits on the processor.
    • Settings has no page for it yet; losos-gaming and pm system start losos-gaming-reserve@<address> do it.
    • It has not run with a real card yet: the VM test defines the machine in libvirt and checks the boot unit, without a card to move.
    • Disks and other devices still carry QEMU's names, which some anti-cheats look for.

  • Focus mode. Focus mode pauses background work, but the desktop's own bar and dock stay on screen: a full-screen request from a program does not yet hide them.

  • The network and files machines. The network machine and the files machine have gaps:

    • Handing a network card over by VFIO has only run in QEMU. The VM test runs the fallback for a PC without an IOMMU.
    • sys-net forwards IPv4 only. The host has no IPv6 while it routes through it.
    • The keyboard's Wi-Fi and airplane keys reach the host's rfkill, not the machine's. Settings' Wi-Fi switch works.
    • The edge as a way out has a command, losos-edge, and no row in Settings yet. sys-net checks no gateway's passport, so an edge on the network counts as a gateway by its own word; it is only ever the way to the official edges it lists, never the exit.
    • The edge's tunnel carries IPv4 only, like the rest of sys-net.
    • The VPN has a command, losos-vpn, and no row in Settings yet, and the host learns only whether sys-vpn runs, not whether its tunnel is up.
    • In schizo mode with a VPN, a provider's endpoint must be an address in its file, not a name: sys-vpn would ask Tor for the name, and Tor goes out through sys-vpn. Windscribe's files name their endpoints.
    • Without an IOMMU, NetworkManager on the host keeps the networks the host has saved, and sys-net keeps none of its own.
    • Network shares have a command, losos-shares, and no page in Settings or Files. WebDAV shares have not been tried against a server.
    • OpenSSH's sftp-server in sys-files is not chrooted to the volume it serves. The host is the only one that can ask for one.

  • The portal machine. The portal machine has gaps:

    • Its dialogs are not attached to the app's window, which is on another machine's display, so they open as windows of their own.
    • What a machine may write back is kept until the host restarts. After that, saving a copy a machine was given before changes only the copy.
    • A folder picked for an app in a machine goes back file by file. An empty folder made in the copy reaches the host only once a file is put in it, and a link made in the copy stays in the machine.
    • Changes made to a picked folder on the host after it was copied do not reach the machine's copy.
    • Only the files and screenshot portals copy files. A portal that hands an app a file in another way, such as the Account portal's picture, hands a machine's app a path it cannot open.

  • pm on a NixOS host. pm's jail mirrors the host's /bin, /lib and /usr, and also mounts /nix/store and the store-backed PATH directories read-only. So a step whose tools come from the store runs. A losos-nix step running nix eval and nix hash worked that way in pm's jail on a Nix-provisioned host. A recipe that names FHS paths, such as /bin/cat or a compiler under /usr, still finds nothing, and every recipe in the old pm tree did that. In this image /usr is the Nix store's partition and /bin holds only sh. So pm itself runs here, including pm --help, pm source-path, signing and explain, and the boot test checks it is installed. A recipe written for an FHS host does not build on it, though. For the same reason, seven of pm's test targets are skipped in the Nix build, and nixos/pkgs/pm.nix lists them.

  • The Agent's tools. The image carries neither Claude Code, which nixpkgs marks unfree, nor the Rust toolchain that the Agent's previews build with. A chat needs claude, and a preview needs cargo with the wasm32-wasip2 target, both installed by the person first.

  • Searching what is in every file. derisk-index reads plain text, PDFs and OpenDocument and Office Open XML files, but not the text in pictures or scanned PDFs, which would take OCR, nor the older binary .doc, .xls and .ppt formats. Those are found by name alone. Only the first MiB of a file's text is indexed. Hidden files and anything .gitignore leaves out are not indexed unless Settings names their folder.

  • The Agent's machine. The Agent works on a copy of the folder the person picks, so a file changed on the host while the copy is open is not seen in the machine until the folder is picked again. The machine has no Nix and no pm, so the Agent's nix_build and pm_build tools fail there. Files the Agent asks to open, such as an artifact, stay in the machine, because only web links open on the desktop. The machine draws in software, with no GPU. Nothing on the desktop shows that the machine is running or stops it, other than closing the Agent and waiting ten minutes.

  • A default for text files. Since Sonne left, nothing claims text and source files as their default for xdg-open. Files opens them in whatever app happens to list their type, if any. derisk's Text Editor cannot be handed a file, because its desktop entry lives inside the derisk binary with no file argument and no types.

  • The guest template in full. Only a reduced build of the guest, without Danube, Flatpak and the Calculator, has booted, and no machine's window has reached a desktop through it yet. It is a whole second NixOS in /usr, so it carries its own copy of store paths the host also has, such as Mesa, Danube and fonts, and takes that room from the 8 GiB /usr slot. Giving machines the host's store over virtiofs would save it. A machine's disk grows once, to the size it was made with, and nothing makes an existing machine's disk larger. Portal dialogs in a machine, such as a Flatpak's file chooser, are the portal machine's now, and nobody has tried them with a real app in a machine.

  • The Flatpak machine's loose ends. Flatpak's files move off the host only for administrators, because anyone else would get a password dialog they did not ask for. Other users copy their ~/.var/app into the machine by hand. The host's copy of ~/.var/app stays after the copy, until its owner deletes it. Flatpak apps inside the machine draw in software, like the rest of its apps, so a game from Flathub runs slower than it did on the host.

  • Windows and other distributions in machines. No Windows has been installed from the Windows tools CD yet, so its answer file, its drivers and its first sign-in have only been read, not run. The Linux tools CD's setup.sh has not run in any distribution either. The desktop does not yet show a machine's own screen by itself, though virt-viewer --attach does. Machines from an installer CD describes both CDs.

  • Windows app support. Windows app support has not set up Windows on a real PC yet. The setup, pm container and rootless Podman ran here, but dockur's Windows needs KVM, which the sessions this was built in lack. Its windows are FreeRDP's X11 windows, drawn through the session's one xwayland-satellite, so the desktop does not frame them in a colour of their own. It has no GPU, so Windows draws its apps and encodes their H.264 in software. USB passthrough, which WinBoat does only with Docker, is not offered. Windows is not activated.

  • App windows. App windows has run on GitHub's Macs, driven by scripts and from LosOS booted in a VM on them. Pictures go to the compositor through shared memory rather than the GPU's own buffers. The pointer is always the arrow, only text crosses the clipboard, and drag and drop and sound stay in the guest. A Mac package downloaded in another machine stays there; only this desktop's own hand packages to macOS.

  • macOS app support. macOS app support has not set up macOS yet. That needs a Mac running LosOS, because Apple's licence lets macOS run only on Apple hardware, and CI's Macs run macOS rather than LosOS. The installer inside macOS builds the app server with Rust and Apple's command line tools, which macOS downloads, rather than installing a built one. Reims vGPU has not drawn macOS here.

  • No hosted proxy. GitHub Pages serves files only. Of what proxy/ did, updates moved to GitHub Releases, through an index on the documentation site and a service on each machine (Releases). CI reads the Nix cache through the proxy's own code on its runner. Three things still need a deployment that runs code, set as LOSOS_PROXY_URL:

    • the daily /ping and the choice screens it turns on, which stay off without one;
    • the web flasher's own downloads, so without one it sends the person to the release page (Web flasher);
    • a public cache URL for a builder outside CI, though proxy/serve.ts runs the same cache locally.

    Systems installed from an image built with a proxy URL keep asking that proxy for updates until they are reinstalled, or until the proxy serves them one more update.

  • A cadence picked on a machine that updates from a proxy. An image built with LOSOS_PROXY_URL names the proxy's /updates/<cadence>/<arch>/ for its own cadence in its sysupdate transfers, which are part of /usr. Settings still lists the cadences there. But losos-update-channel only exists where updates come from GitHub Releases, so the page says the choice is not available.

  • A complete image build. CI builds release images within its runner time budget. Local image builds may take longer.

  • Hibernation. No machine hibernates. The locked-down kernel refuses to, and nothing in mainline Linux authenticates a hibernation image well enough to let it. Hibernation has the details.

  • Signing. There is no key rotation. A new key needs an update signed by the old one that carries both. As in the pm tree, a key belongs to whoever owns the machine.

  • A shim of LosOS's own. Secure Boot uses Fedora's Microsoft-signed shim, because LosOS's has not been through shim-review. So each PC enrolls LosOS's key in MokManager once, instead of the firmware trusting LosOS's shim as it comes. The arm64 shim is signed only by Microsoft's 2023 CA, which arm64 firmware from before it may not trust. Releases are signed only once the repository's SECURE_BOOT_KEY secret and nixos/keys/secure-boot.crt are both in place.

  • The Windows installer has not run on Windows. Its install was checked against a disk image laid out like Windows', which then booted. The half that talks to Windows has only been compiled. That half shrinks C:, issues the partition table IOCTLs, mounts the ESP, and handles firmware variables and BitLocker. Beyond that:

    • Secure Boot must be off. The installer registers GRUB itself with the firmware, not shim, and has not been taught to put shim, MokManager and the certificate beside it (Secure Boot).
    • SmartScreen. The .exe has no Authenticode signature, so Windows warns before running it.
    • Windows' recovery partition. Updates that grow it, as KB5034441 did, shrink C: to make room behind it. With LosOS behind C: they cannot, and they fail as they do on any disk with no free space after C:.
    • The boot order. Some firmware, and some Windows updates, put Windows Boot Manager first again. LosOS puts its own entry back in front each time it starts. Until it next does, Windows starts by itself, and LosOS is one pick away in the firmware's boot menu.
    • arm64. The installer is built for x86_64 only, because Windows on arm64 runs on laptops this OS has no kernel configuration for.

  • Installer reports cover a failed install only. The backend writes them, so nothing is reported when the backend itself stops, or when derisk crashes. A report needs a GitHub account and a second device, or a browser, to approve the sign-in. The GitHub App and LOSOS_REPORT_CLIENT_ID are set up, but no report has reached the real GitHub yet: the tests sign in to a stand-in.

  • Desktop reports see only some problems. A window is noticed only when its app misses the ping that a click or a key into it sends, so a hung window nobody touches is not. Settings is the only app that reports an action that never finished, and only for Bluetooth pairing, a backup and asking for a factory reset. Nothing is reported when derisk itself crashes.

  • The two gnome-control-center patches in nixos/pkgs/patches/. Nothing upstream has them, so they stay. They are written against gnome-control-center 51.0, and nixpkgs carries 50.4, which moved the System panel to Blueprint. Neither patch applies, and gnome-control-center is no longer in the image for them to go into. What they added is on derisk Settings' System page instead: the security report, and the factory reset. Only a UEFI machine offers the factory reset, because systemd's request to reset needs UEFI. Neither has been tried on hardware.

  • NVIDIA on real hardware. The driver choice was tested in a VM with a report that names an RTX 4090. No NVIDIA card has run the image. The open module taking a card, derisk's compositor on it, explicit sync, suspend, VA-API, hardened_malloc under NVIDIA's libraries, and laptops with two GPUs are all untested. A machine with an NVIDIA card and another GPU draws on whichever is the boot display, and nothing offloads an app to the other.

  • derisk drives one display. derisk display-manager starts derisk greeter, derisk's lock screen used as the login screen, and after a login, derisk session --execute. Each takes the seat from logind and scans out through DRM/KMS on the first connected display, at its preferred mode, as set up in nixos/modules/desktop.nix. A second display stays dark, and hotplug is not handled. X11 apps run through xwayland-satellite, a user unit that starts with the session, also in desktop.nix. It has been seen serving an X11 client under a headless weston, but not yet under derisk's compositor.

  • derisk's portal has gaps. Screen sharing through xdg-desktop-portal-wlr copies frames into shared memory, not dma-bufs. A shared window is cut out of the screen, so anything covering it is shared too. The colour and area pickers show a screenshot frozen across the screen. They were tried under X11, not yet in a derisk session, and the lock screen's picture has not been tried in one either.

  • The Halium GSI has not run on a device. It evaluates for aarch64, and an x86_64 build of the same boot path booted under QEMU, as the pull request that made it the one target shows. No arm64 build has been flashed, no bootloader has loaded its init_boot, and the web flasher has only talked to a simulated fastboot device. Only a phone can confirm three things: that a generic kernel's configuration has everything systemd and the desktop use, CONFIG_USER_NS for Flatpak's sandbox above all; that vendor_boot's ramdisk and this one unpack together as intended; and that Halium's Android 14 system image starts each vendor's HALs. Beyond that:

    • The display. derisk drives the display itself through DRM/KMS. A device whose kernel has a DRM driver, such as msm, mediatek or panfrost, can show the desktop with Mesa. A device that only has Android's hwcomposer cannot, because nothing here drives hwcomposer. That needs a hwcomposer backend in derisk or a compositor in front of it.
    • Updates. sysupdate is not wired up. The flasher writes userdata whole, so installing a newer release erases the phone. There is no verity on the root either, and the bootloader stays unlocked.
    • Phones without init_boot. The flasher writes their own boot image back with this ramdisk after theirs. Its repacking matches AOSP's mkbootimg byte for byte for header versions 0 to 4, and it was run against a simulated phone in fastbootd. No real bootloader has booted such an image yet, and a phone whose ramdisk links /etc or /lib elsewhere would merge badly with this one.
    • Kernels older than 5.10. Phones that launched with Android 11 or earlier run 4.x or 5.4 kernels, which systemd does not support at all. The flasher reads the kernel's version and refuses them. Supporting them would need an older systemd or a kernel built per device.
    • hardened_malloc. The GSI's allocator is built for a 39-bit address space and tried by the initrd before it is preloaded, but no phone's kernel has run that trial yet. A phone with 16 KiB pages fails it, and its processes keep glibc's malloc. derisk gets it only through the preload there, without the length check on Rust's frees that a PC's derisk has.
    • Telephony, audio, sensors, camera. There is no ofono, no PulseAudio or PipeWire droid modules, and no sensorfw. Android's init starts the HALs, but nothing on the Linux side talks to them yet beyond EGL.

  • Wi-Fi, Bluetooth and power modes in Settings. derisk Settings' Network page lists, joins and forgets networks through NetworkManager, which lets the networkmanager group change them. First-boot setup puts the account it creates in that group. An account made before setup did that is not in it, and its Network page says so until homectl update --member-of=wheel,networkmanager <user> adds it. The Bluetooth page pairs without asking anything, so a device that wants a passkey typed or compared does not pair. None of the three pages has run against a real adapter or against power-profiles-daemon on hardware. The command palette's Power Mode rows ran against the daemon's placeholder driver on a private bus, which offers no Performance profile. The Halium GSI has no Bluetooth, because the phone's controller sits behind its vendor HAL and nothing here bridges that to BlueZ.

  • A recovery shell on an aarch64 PC. The boot menu's root shell for a machine nobody can administer, described in When something goes wrong, starts the kernel kept beside the UKI for a BIOS boot. Only x86_64 images carry that kernel. An aarch64 PC's GRUB can only chainload its UKI, and a UKI takes kernel arguments only as a replacement for its whole command line.

  • A PIN at startup is the installer's only. The installer encrypts root with a TPM and a PIN when asked, but a PC set up from a written image, first-boot setup and the Windows installer leave root plain. A factory reset recreates root from disk.nix, which has no encryption, so it comes back plain too. The TPM slot is bound to no PCRs until the UKIs are signed. The VM test unlocks the installed root with systemd-cryptsetup beside the installer; no test yet boots an installed system through the PIN prompt, since that needs a release to install. There is no way to change the PIN from Settings; systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-with-pin=yes --tpm2-pcrs= with the recovery key does it.

  • sysext. Extensions merge into /usr, which here holds little but the Nix store, so an extension can add a program but cannot replace one.

  • Android app support. Android app support boots its Pixel and opens an app's display in CI, on a runner with KVM and no GPU. CI's Pixel draws with -gpu host through Mesa's llvmpipe, the same path a GPU's driver takes, but no CI run has had a real GPU, and Vulkan through gfxstream is only on with one (The GPU). Google Play needs a person to sign in to a Google account on the Pixel before it installs anything. The Pixel has no camera, and no USB passthrough. Its windows have no colour of their own, since they come from scrcpy on the desktop rather than from a machine. Google builds no emulator for Linux on ARM, so aarch64 PCs and the GSI have no Android app support.

  • Booted under QEMU only. Every CI run boots the x86_64 image in QEMU with nix flake check, under UEFI and under SeaBIOS, as "Tested" in Boot loader describes. First boot lays out the disk with systemd-repart. Root is found, by gpt-auto on UEFI and on the disk GRUB names on a BIOS. /usr is dm-verity, and a new UKI is counted down and blessed. A laptop with a TPM hibernates and resumes. The installer ISO starts under both firmwares. An install from a nightly's files was run in QEMU through to the installed disk's first boot, so sysupdate has written a disk other than the running one. Three things have not been seen yet. A running system has not taken an update from the channel and booted it; the tests rename a UKI to stand in for a new one. The aarch64 image has not started at all, since the arm64 runner has no KVM and the aarch64 VM under emulation times out waiting for its disk. And none of it has run on a PC instead of in QEMU.

  • Danube is unfinished in places. Danube's extensions cannot see requests through webRequest, talk to a native program, or use cookies, context menus, history, bookmarks or the side panel, as its "Extensions" section lists. A download that stopped cannot be resumed. Its sandboxes need unprivileged user namespaces, and a phone's own kernel may refuse them. Danube then stops instead of running a page outside a sandbox, so on such a phone it does not open at all. --no-sandbox skips only the outer sandbox. Danube has run with derisk on the desktop, in a VM, but not yet on a phone.

  • Ad blocking is DNS-wide only for names. A filter list's URL and element rules apply in Danube alone. Other browsers and apps get only whole blocked domains, and a program with its own DNS over HTTPS skips it entirely.

  • Labels on the network cover virbr0 only. A machine on a network someone made in virt-manager is not filtered by its label. Neither is a red machine kept from the host's public address, on a PC that has one rather than a LAN address. A machine's new label takes effect when it next starts (labels on the network).

  • Encrypted DNS moves trust rather than removing it. With encrypted DNS on, the network no longer sees the names, but the resolver does, Quad9 or Mullvad by default. Queries are not padded (RFC 8467), so their sizes still hint at the names, and the TLS connection's fingerprint is rustls', not a browser's. Only Tor hides the names from both.

  • The LosOS boxes machine passes on names, not everything. It routes the other machines' connections to a box only on ports 80 and 443, by the name they ask for. An app's own port on a box is reached directly, and nothing stops a machine that knows a box's address from reaching it without the LosOS boxes machine. The machine's keyring has no sign-in to unlock it, so the first losos command that stores a key or token asks for a keyring password in a window of the machine. Nothing makes the machine automatically either, and its owner makes it from the template. The machine itself has not met a real box on a real LAN yet: the machines test boots a stand-in box beside the host, and the real box in nixos/tests/losos-box.nix is found by a desktop with no machine. Away from home only losos, the palette's search and LosOS Cloud's link reach a box, through its edge; backups and the other machines' connections still need the box's own network.

  • Backups to a LosOS box keep one copy. LosOS cloud keeps old versions and the trash, but LosOS Git keeps only the latest state of each branch, and only the configs' repository has a history. A repository deleted at home stays on the box. Symbolic links are recorded for restore, and Git LFS objects are uploaded. A box with HTTPS turned off through losos.tls.enable cannot be backed up to. Only an administrator's run can start a stopped LosOS boxes machine. A box older than LosOS Login's sign-in for backups offers the password sign-in to LosOS cloud; without a LosOS Git token, repositories go to LosOS cloud as files. The test uses both a stand-in and a real box. See Backups to a LosOS box.