One-screen comparison
LamBoot is designed for a specific audience. Many of the differences below are about what’s inside, not polish.
| LamBoot | GRUB | systemd-boot | rEFInd | Clover | sd-boot-rs | |
|---|---|---|---|---|---|---|
| Language | Rust | C | C | C++ | C++ | Rust |
| Binary size | 215 KB | 4 MB | 300 KB | 1 MB | 2 MB | 200 KB |
| Memory-safe | Yes | No | No | No | No | Yes |
| Graphical menu | Yes + mouse | No | Text | Yes + icons | Yes | No |
| BLS Type 1 | Full | Partial | Full | None | None | Partial |
| UKI first-class | Yes | Wrapper | Yes | No | No | No |
| Crash-loop recovery | NVRAM state machine | None | Boot counting | None | None | None |
| Trust-evidence log | Yes (JSON) | None | None | None | None | None |
| Secure Boot | DB + shim + MOK + SecurityOverride | Shim | Shim | Shim | No | Shim |
| TPM measured boot | PCR 4/5/12 | None | PCR 4/5/8/12 | None | None | Roadmap |
| Loadable FS drivers | Yes | Built-in | FAT only | Yes | Yes | Yes |
| Hypervisor integration | Proxmox first-class | Generic | Generic | Generic | None | Cloud |
| x86_64 + aarch64 | Both | Both | Both | x86_64 only | x86_64 only | Both |
| License | MIT OR Apache-2.0 | GPLv3 | LGPL-2.1+ | GPLv3 | CDDL | MIT |
Head-to-head
LamBoot vs. GRUB
GRUB is the default almost everywhere and will be for years. It’s also 40,000+ lines of C with a colorful CVE history, a binary 20× LamBoot’s size, and a configuration language (grub.cfg generation, os-prober, update-grub) that is infamous for breaking silently on kernel upgrades. LamBoot is not trying to replicate GRUB’s universal-hardware theatre; it is the right tool for people running modern BLS-compliant Linux, VMs, or UKIs, who want a bootloader they can read in a weekend and audit on every boot.
If you need legacy-BIOS support, PXE chainloading, Btrfs snapshot menu, or 40 filesystem drivers built in — stay on GRUB. If you’re running UEFI, BLS, and kernel-install — LamBoot gives you the same power in 215 KB of Rust.
LamBoot vs. systemd-boot
The closest philosophical cousin. Tiny, BLS-native, UEFI-only, minimal feature surface. Differences:
- Language: systemd-boot is still C. LamBoot is Rust — fewer memory-safety footguns, easier to reason about.
- GUI: systemd-boot is text-mode only. LamBoot ships a proper graphical menu with mouse support for people who want it (serial fallback for people who don’t).
- Trust-evidence log: LamBoot writes structured audit evidence. systemd-boot does not.
- Crash-loop recovery: LamBoot’s state machine is explicit and NVRAM-exposed (useful in hypervisor contexts). systemd-boot has
+N[-M]boot counting but no persistent cross-boot state model. - SecurityOverride for driver loading: Same mechanism both use; LamBoot’s is documented and inspectable; systemd-boot treats it as internal plumbing.
- Proxmox/hypervisor integration: First-class in LamBoot; absent in systemd-boot.
If you already love systemd-boot and don’t need a GUI or audit log — stay on it. If you want the same minimal surface in a memory-safe language plus the hypervisor/audit story — come to LamBoot.
LamBoot vs. rEFInd
rEFInd is the go-to “pretty graphical bootloader” for UEFI. Written in C++, ~4× LamBoot’s size, has been unmaintained-ish for stretches. Security model is “sign the binary, enroll via MokManager, hope for the best.” Does not write an audit log. Does not do BLS. Its filesystem driver collection is excellent (LamBoot borrows from it — rEFInd’s ext4/btrfs drivers ship with LamBoot under GPL-2.0 as separate binaries).
If rEFInd’s visuals and icon themes matter to you — stay there. If you want an auditable, BLS-native, memory-safe loader — switch.
LamBoot vs. sd-boot-rs / Sprout
Other Rust UEFI bootloaders exist. Sprout is cloud-focused and small; sd-boot-rs is a straight Rust port of systemd-boot. Neither ships a trust-evidence log, a full GUI, a crash-loop state machine, or Proxmox integration. Community is small across all three; pick based on the features that matter to you.
LamBoot vs. Clover / OpenCore
Target a specific ecosystem (Hackintosh) and aren’t really comparable. Listed in the matrix for completeness.
When not to choose LamBoot
Worth saying clearly: some users should stay where they are.
- —You need legacy BIOS support. LamBoot is UEFI-only.
- —You depend on GRUB’s os-prober Windows/Mac detection and menu. LamBoot detects Windows but not arbitrary
EFI/*vendors the way os-prober does. - —You need a rescue shell with a command line. LamBoot is menu-only by design.
- —You run a fleet already managed by shim-review-approved binaries. LamBoot is not in the shim-review database yet. (Roadmap: v1.0.)
- —Your platform is not UEFI. LamBoot does not implement coreboot or U-Boot handoff.