Remove Firefox from the shared preferences module; keep it on nexus #5

New issue

Open

opened 2026-07-29 20:57:14 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-29 20:57:14 +01:00

Collaborator

Remove Firefox from the shared private preferences module so dev VMs are terminal-only, keeping it on nexus where it is actually used.

Primary goals:

Dev VMs stop shipping a browser — the owner does not use Firefox in a dev VM; these machines are terminal-only in practice, so a browser, its extensions, and its GTK/GL stack are unused closure on every dev VM.
nexus keeps working — its mime handlers already name firefox.desktop, so Firefox moves to the host profile rather than being deleted outright.
Restore the minimality premise — dev-VM minimality is currently a belief the configuration contradicts, which has already misled at least one design discussion.

Current state and specifics

modules/preferences.nix:52 enables programs.firefox with a default profile, ublock-origin, multi-account-containers, and a block of privacy prefs. That module is this repo's homeModules.preferences.

Its consumers:

Machine	Preferences module	Gets Firefox
nix-dev, rust-dev, svelte-dev	this repo's, via `mkDevVm` default	yes
allod-dev	public `allod-profiles.homeModules.preferences` (`flake.nix:100`)	no
nexus (hypervisor)	this repo's, via `allod/archetypes/flake.nix:288`	yes

So allod-dev already demonstrates the per-machine opt-out mechanism — profileData.<machine>.preferencesModule — and already runs without Firefox.

The load-bearing constraint is nexus. hosts/hypervisor/nexus/home.nix:10-19 sets firefox.desktop as the default application for x-scheme-handler/http, .../https, .../chrome, text/html, and six x-extension-* types. Deleting the block from the shared module alone would leave those handlers pointing at a desktop file no longer in the closure.

Default approach: move the programs.firefox block from modules/preferences.nix into hosts/hypervisor/nexus/home.nix, alongside the mime handlers that depend on it. Dev VMs then inherit a browser-free preferences module and need no per-machine override. The alternative — leaving the block where it is and adding a preferencesModule override for each dev VM — is worse: it repeats the opt-out three times and keeps the default wrong.

On provenance: the owner's recollection is that this is a holdover from the hashpool rust-dev machine. History does not confirm that. The Firefox block arrived in 50c893d ("Add private machine profile definitions", 2026-07-18, Refs vnprc/notes#62) as part of the initial private profile import, with no rust-dev-specific commit touching it since. Recording this so the next reader does not go looking for a change that is not there.

Validation

Confirm programs.firefox no longer evaluates for any dev machine, and that firefox is absent from a built dev VM's home-manager-path closure. Confirm nexus still has firefox in its closure and still resolves x-scheme-handler/https. Measure the dev-VM closure delta — worth recording, since the whole point is footprint.

Scope

In scope: this repo's modules/preferences.nix and hosts/hypervisor/nexus/home.nix.

Out of scope: the public allod/profiles preferences module, which never had Firefox. The nostr privacy VM's own Firefox with the nos2x extension (hosts/privacy/nostr/configuration.nix:4) is unaffected — privacy VMs do not import the preferences module at all.

One downstream note. vnprc/notes issue #75 measured hardware.graphics.enable as a ~229 MiB closure delta on a dev VM, and that figure assumed Firefox was present: nix why-depends traced the already-installed libglvnd to firefox-152.0.4. After this change that delta grows, because the GL userspace it was sharing leaves with the browser. Not a reason to keep Firefox — just a stale number to re-measure if anyone revisits that ticket.

Remove Firefox from the shared private preferences module so dev VMs are terminal-only, keeping it on `nexus` where it is actually used. Primary goals: - **Dev VMs stop shipping a browser** — the owner does not use Firefox in a dev VM; these machines are terminal-only in practice, so a browser, its extensions, and its GTK/GL stack are unused closure on every dev VM. - **`nexus` keeps working** — its mime handlers already name `firefox.desktop`, so Firefox moves to the host profile rather than being deleted outright. - **Restore the minimality premise** — dev-VM minimality is currently a belief the configuration contradicts, which has already misled at least one design discussion. ### Current state and specifics `modules/preferences.nix:52` enables `programs.firefox` with a default profile, `ublock-origin`, `multi-account-containers`, and a block of privacy prefs. That module is this repo's `homeModules.preferences`. Its consumers: | Machine | Preferences module | Gets Firefox | | --- | --- | --- | | nix-dev, rust-dev, svelte-dev | this repo's, via `mkDevVm` default | yes | | allod-dev | public `allod-profiles.homeModules.preferences` (`flake.nix:100`) | no | | nexus (hypervisor) | this repo's, via `allod/archetypes/flake.nix:288` | yes | So `allod-dev` already demonstrates the per-machine opt-out mechanism — `profileData.<machine>.preferencesModule` — and already runs without Firefox. The load-bearing constraint is `nexus`. `hosts/hypervisor/nexus/home.nix:10-19` sets `firefox.desktop` as the default application for `x-scheme-handler/http`, `.../https`, `.../chrome`, `text/html`, and six `x-extension-*` types. Deleting the block from the shared module alone would leave those handlers pointing at a desktop file no longer in the closure. Default approach: move the `programs.firefox` block from `modules/preferences.nix` into `hosts/hypervisor/nexus/home.nix`, alongside the mime handlers that depend on it. Dev VMs then inherit a browser-free preferences module and need no per-machine override. The alternative — leaving the block where it is and adding a `preferencesModule` override for each dev VM — is worse: it repeats the opt-out three times and keeps the default wrong. On provenance: the owner's recollection is that this is a holdover from the hashpool `rust-dev` machine. History does not confirm that. The Firefox block arrived in `50c893d` ("Add private machine profile definitions", 2026-07-18, `Refs vnprc/notes#62`) as part of the initial private profile import, with no `rust-dev`-specific commit touching it since. Recording this so the next reader does not go looking for a change that is not there. ### Validation Confirm `programs.firefox` no longer evaluates for any dev machine, and that `firefox` is absent from a built dev VM's `home-manager-path` closure. Confirm `nexus` still has `firefox` in its closure and still resolves `x-scheme-handler/https`. Measure the dev-VM closure delta — worth recording, since the whole point is footprint. ### Scope In scope: this repo's `modules/preferences.nix` and `hosts/hypervisor/nexus/home.nix`. Out of scope: the public `allod/profiles` preferences module, which never had Firefox. The `nostr` privacy VM's own Firefox with the `nos2x` extension (`hosts/privacy/nostr/configuration.nix:4`) is unaffected — privacy VMs do not import the preferences module at all. One downstream note. `vnprc/notes` issue #75 measured `hardware.graphics.enable` as a ~229 MiB closure delta on a dev VM, and that figure assumed Firefox was present: `nix why-depends` traced the already-installed `libglvnd` to `firefox-152.0.4`. After this change that delta grows, because the GL userspace it was sharing leaves with the browser. Not a reason to keep Firefox — just a stale number to re-measure if anyone revisits that ticket.