OpenBSD Innovations
Pledge/Unveil and Sandboxing
- Many felt pledge/unveil deserved more prominence, calling them standout innovations.
- Clarified threat model: not distrusting the program itself, but limiting damage if it’s compromised mid-run by tightening syscalls and filesystem access after startup.
- Some argued sandboxing should be configured externally (like Docker) rather than in-app; others countered that developers understand their program’s lifecycle better than admins.
- Linux analogues (seccomp, Landlock) and unikernel ports were discussed; there was some confusion then correction about who inspired whom.
Security Mitigations and External Assessments
- The isopenbsdsecu.re site was cited as a detailed, if harsh, assessment: critical in tone but explicitly praising malloc, atexit hardening, and pledge.
- Concerns raised there about outdated packages (e.g., Firefox, Tor) were rebutted as outdated FUD, with references to active maintenance.
- Newer mitigations mentioned: mimmutable/mseal, execute‑only memory, BTI/IBT, and random-data sections (e.g., for RETGUARD).
- Some worry execute‑only on ARM conflicts with PAN; others argue OpenBSD’s priorities differ and EPAN support is coming.
Daily Use, Performance, and Hardware Support
- Several run OpenBSD daily on ThinkPads and some Dells, reporting solid stability but weaker power management and battery life than Linux.
- Performance views differ: some call it “incredibly slow”, others say only disk I/O and browsers (without GPU accel) are notably slower; SMT is disabled by default for security.
- Major limitations noted: no Bluetooth stack (removed for quality/security reasons), no HDMI audio, fewer ports. For some, that disqualifies it as a laptop OS; others accept wired peripherals and see this as a deliberate trade-off.
- Used successfully as a home router/firewall (pf, CARP, HAProxy), with console-based administration; a few GUI frontends exist but are niche.
Funding, Licensing, and Open Source Economics
- Debate over whether large companies using OpenSSH “owe” OpenBSD funding: permissive licensing grants total freedom, but many see an ethical duty to contribute to a shared commons.
- Some argue capitalism structurally favors taking without giving; others say reciprocity should be encoded via copyleft or commercial licensing, not moral appeals.
- Broader argument: open source both depresses some categories of paid work (no one paid to re‑implement JPEG, kernels, databases) and enables higher-level work and new products.
- Burnout and underfunding (e.g., XZ, OpenSSL/Heartbleed) used as evidence that relying on volunteer labor has real security costs.
Languages, Implementation, and Kernel Architecture
- Critique: a “security-obsessed” OS still written in C inherits avoidable memory bugs; suggestion to move userland or more components to safer languages.
- Pushback centers on: Rust’s heavy toolchain, POSIX compatibility gaps, incomplete 1:1 replacements for core utilities, and OpenBSD’s “base builds base” rule; also portability to obscure architectures.
- Alternatives like Zig or OCaml were mentioned but seen as immature or unsuitable (e.g., GC in kernels).
- Kernel locking: the historic “giant lock” is being steadily removed; network stack still has work in progress but performance has improved notably.
Choosing and Using OpenBSD vs Other BSDs
- For newcomers, FreeBSD is described as closer to Linux, with broader hardware support, ZFS, better performance, and more ports.
- OpenBSD is framed as the “correctness and security first” BSD, with excellent man pages and a tightly integrated base system, but with deliberate feature omissions and rougher edges for desktop use.