A BSD person tries Alpine Linux

BSD users experimenting with Alpine Linux describe it as a surprisingly clean, fast, and minimal Linux distribution, especially attractive for servers and containers thanks to BusyBox, musl, and OpenRC. Much of the exchange contrasts Alpine’s simplicity and cohesive feel with the perceived fragmentation and complexity of mainstream GNU/Linux ecosystems (systemd, multiple firewall and networking stacks), while also weighing trade-offs such as weaker heap hardening in musl, occasional performance penalties, and rough edges on the desktop. Alternatives like Void, Chimera, and FreeBSD are frequently mentioned, with ZFS support, init systems, and supply-chain security practices emerging as key points in choosing a platform.

Overall view of Alpine vs BSD and other Linux distros

  • Several BSD users say Alpine is the first Linux in a long time that “feels sane”: small, coherent, fast to boot, easy to understand.
  • They contrast this with Linux fragmentation: multiple firewalls, network stacks, init systems, and changing tools (ifconfig vs ip, netstat vs ss), plus distro-specific churn.
  • Others push back that many Linux inconsistencies are distro choices, and that BSDs also differ substantially from each other.

ZFS and storage tooling

  • Alpine ships a binary ZFS kernel module; apk add zfs is enough for data pools.
  • Root-on-ZFS is documented and works but is not installer-integrated and requires many manual steps, unlike FreeBSD’s “Auto (ZFS)” option.
  • Advocates argue ZFS-on-root is very useful for snapshots, rollbacks, corruption detection, and flexible datasets; others question whether root specifically needs ZFS.
  • ZFSBootMenu on Linux is praised as more powerful than FreeBSD’s boot environments, though no mainstream Linux distro fully integrates “root on ZFS + ZFSBootMenu” out of the box.

Init systems: OpenRC vs systemd and supervision suites

  • Some find OpenRC refreshing and “fun” compared to systemd; others criticize PID files and syslog dependence, calling process supervision (runit, s6, daemontools, dinit) superior.
  • systemd is defended as a major step forward for admin tooling and parallel boot; critics argue it centralizes too much in PID 1, increases attack surface, and is architecturally fragile.
  • Alpine itself is exploring alternatives to OpenRC and init-agnostic designs; s6-based efforts exist but are slow-moving.

musl vs glibc: security and performance

  • glibc is described as having a more hardened heap and better mitigations; musl is smaller and easier to reason about but historically less hardened and with weaker allocator performance, especially in multithreaded workloads.
  • Some report noticeable slowdowns when switching CI/container workloads from Debian+glibc to Alpine+musl; others note musl and ecosystem support (e.g., wheels, DNS issues) have improved.
  • musl lacks some APIs (e.g., pthread_attr_setaffinity_np), breaking software like PyTorch.

Package management, docs, and desktop experience

  • Alpine’s apk plus editing /etc/apk/world gives a quasi-declarative setup; compared to Gentoo’s world/sets mechanism.
  • Docs/man pages are not installed by default, but a docs meta-package can pull in *-doc packages automatically.
  • As a desktop OS, users praise snappiness and simplicity but mention: tricky GUI setup, Bluetooth/audio issues, musl incompatibilities, and package upgrades occasionally removing needed components.

Security and supply-chain discussions

  • One external critique (quoted in the thread) claims Alpine lacks full-source bootstrap, signed commits/reviews, and reproducibility; others counter that Alpine does sign packages and that most distros are similar regarding bootstrap and reproducibility.
  • Contributors note that stronger supply-chain assurances require significant funding and infrastructure, which small projects often lack.