Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
(5-10x More Speed on HHD) Cache Omarchy Scripts (200+ keybinds/app lauch/desktop related scripts) in ONLY 1MB RAM and Turn 7-8s Launcher Waits into 0-4s (Revive Old Hardware) This also avoids these scripts from being swapped in zram or even worse; HHD which makes the Omarchy desktop experience feel like hell on a hhd
Reported by isbafatima90-arch · filed Apr 9, 2026Closed upstream on 2026-04-19. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
Intel(R) Pentium(R) B950 (2) @ 2.10 GHz, Intel 2nd Generation Core Processor Family Integrate, 1920x1080 in 24", 60 Hz [External], 55.72 GiB / 296.07 GiB (19%) - btrfs, 2.43 GiB / 3.71 GiB (66%)
What's wrong?
The Problem
On a 15-year-old HDD with only 4GB RAM, running Btrfs + LUKS encryption + Hyprland desktop, the system is already in a swap
storm.
Every time you hit a launcher binding, the OS has to:
1. Read the script from disk
2. Resolve the interpreter path
3. Load bash + all sourced files
4. Execute
On a thrashing HDD system with encryption and copy-on-write overhead, you wait 7-8 seconds for a simple script to launch.
That is unbearable.
The Idea
Create a RAM bin system — a tiny tmpfs mount (1MB RAM) that mirrors ~/.local/share/omarchy/bin/ and stays in sync with the
source scripts.
Results on my 4GB RAM, 15-year-old HDD, Btrfs + LUKS laptop:
* Before: 7-8 seconds per launcher (swap storm + HDD seek + encryption overhead)
* After: 0-1 seconds (instant RAM execution)
* 10x speed boost on every single keybinding
* 1MB RAM total usage — 209 scripts (876KB) sitting in pure RAM
* Zero disk I/O for script execution
* The entire desktop feels alive again — no more waiting for basic shortcuts
How It Works
- Setup (runs once at login)
1 sudo mkdir -p /run/omarchy-bin
2 sudo mount -t tmpfs -o size=1M tmpfs /run/omarchy-bin
3 cp -a ~/.local/share/omarchy/bin/* /run/omarchy-bin/
4 # Prepend to PATH in ~/.bashrc
5 export PATH="/run/omarchy-bin:$PATH"
- Sync Watcher (background daemon)
A lightweight polling script that keeps the RAM copy in sync with disk:
1 #!/bin/bash
2 SOURCE="$HOME/.local/share/omarchy/bin"
3 TARGET="/run/omarchy-bin"
4
5 cp -a "$SOURCE"/* "$TARGET"/ 2>/dev/null
6
7 LAST_MOD=0
8 while true; do
9 NEW_MOD=$(stat -c %Y "$SOURCE" 2>/dev/null || echo 0)
10 if [ "$NEW_MOD" != "$LAST_MOD" ]; then
11 cp -a "$SOURCE"/* "$TARGET"/ 2>/dev/null
12 LAST_MOD="$NEW_MOD"
13 fi
14 sleep 3
15 done
- Auto-start via Hyprland
1 # ~/.config/hypr/autostart.conf
2 exec-once = ~/.local/bin/omarchy-bin-watcher
Why Omarchy Should Ship This
- Revives ancient hardware — 15-year-old HDD + 4GB RAM + Btrfs + LUKS becomes usable
- 1MB RAM. That's it. — Even a Raspberry Pi can spare 1MB
- Solves the swap death spiral — When RAM is full and everything's swapped, even a 50KB script takes seconds to load. This
eliminates that entirely
4. Survives updates — watcher auto-syncs when omarchy-update changes source scripts
5. No external deps — pure bash, tmpfs, and cron-style polling
Suggested Implementation
I'd suggest Omarchy ship this as:
1. A first-run setup: omarchy-setup-ram-cache
2. The watcher as ~/.local/share/omarchy/bin/omarchy-ram-cache-daemon
3. Auto-start entry in default autostart.conf
4. PATH prepended in the default .bashrc template
This single change gave me the biggest "wow" factor — every keybinding feels instant, every launcher fires in under a
second, and the desktop feels 10x more responsive. For a distro built on Hyprland (which is beautiful but heavy), this
optimization makes it feel truly polished on any hardware.
View raw text
### System details
Intel(R) Pentium(R) B950 (2) @ 2.10 GHz, Intel 2nd Generation Core Processor Family Integrate, 1920x1080 in 24", 60 Hz [External], 55.72 GiB / 296.07 GiB (19%) - btrfs, 2.43 GiB / 3.71 GiB (66%)
### What's wrong?
The Problem
On a 15-year-old HDD with only 4GB RAM, running Btrfs + LUKS encryption + Hyprland desktop, the system is already in a swap
storm.
Every time you hit a launcher binding, the OS has to:
1. Read the script from disk
2. Resolve the interpreter path
3. Load bash + all sourced files
4. Execute
On a thrashing HDD system with encryption and copy-on-write overhead, you wait 7-8 seconds for a simple script to launch.
That is unbearable.
The Idea
Create a RAM bin system — a tiny tmpfs mount (1MB RAM) that mirrors ~/.local/share/omarchy/bin/ and stays in sync with the
source scripts.
Results on my 4GB RAM, 15-year-old HDD, Btrfs + LUKS laptop:
* Before: 7-8 seconds per launcher (swap storm + HDD seek + encryption overhead)
* After: 0-1 seconds (instant RAM execution)
* 10x speed boost on every single keybinding
* 1MB RAM total usage — 209 scripts (876KB) sitting in pure RAM
* Zero disk I/O for script execution
* The entire desktop feels alive again — no more waiting for basic shortcuts
How It Works
1. Setup (runs once at login)
1 sudo mkdir -p /run/omarchy-bin
2 sudo mount -t tmpfs -o size=1M tmpfs /run/omarchy-bin
3 cp -a ~/.local/share/omarchy/bin/* /run/omarchy-bin/
4 # Prepend to PATH in ~/.bashrc
5 export PATH="/run/omarchy-bin:$PATH"
2. Sync Watcher (background daemon)
A lightweight polling script that keeps the RAM copy in sync with disk:
1 #!/bin/bash
2 SOURCE="$HOME/.local/share/omarchy/bin"
3 TARGET="/run/omarchy-bin"
4
5 cp -a "$SOURCE"/* "$TARGET"/ 2>/dev/null
6
7 LAST_MOD=0
8 while true; do
9 NEW_MOD=$(stat -c %Y "$SOURCE" 2>/dev/null || echo 0)
10 if [ "$NEW_MOD" != "$LAST_MOD" ]; then
11 cp -a "$SOURCE"/* "$TARGET"/ 2>/dev/null
12 LAST_MOD="$NEW_MOD"
13 fi
14 sleep 3
15 done
3. Auto-start via Hyprland
1 # ~/.config/hypr/autostart.conf
2 exec-once = ~/.local/bin/omarchy-bin-watcher
Why Omarchy Should Ship This
1. Revives ancient hardware — 15-year-old HDD + 4GB RAM + Btrfs + LUKS becomes usable
2. 1MB RAM. That's it. — Even a Raspberry Pi can spare 1MB
3. Solves the swap death spiral — When RAM is full and everything's swapped, even a 50KB script takes seconds to load. This
eliminates that entirely
4. Survives updates — watcher auto-syncs when omarchy-update changes source scripts
5. No external deps — pure bash, tmpfs, and cron-style polling
Suggested Implementation
I'd suggest Omarchy ship this as:
1. A first-run setup: omarchy-setup-ram-cache
2. The watcher as ~/.local/share/omarchy/bin/omarchy-ram-cache-daemon
3. Auto-start entry in default autostart.conf
4. PATH prepended in the default .bashrc template
This single change gave me the biggest "wow" factor — every keybinding feels instant, every launcher fires in under a
second, and the desktop feels 10x more responsive. For a distro built on Hyprland (which is beautiful but heavy), this
optimization makes it feel truly polished on any hardware.Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.