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.