Openbsd defaults


Unix

Shell

  • El shell por defecto para root y usuarios nuevos es ksh (la versión OpenBSD de pdksh, no bash). Bash/zsh/fish están disponibles como paquetes pero no vienen instalados.

Sistema X / display manager

  • OpenBSD trae su propio fork de X.org llamado Xenocara (basado en Xorg server, en 7.9 sobre Xserver 21.1.21).
  • El display manager recomendado y que se instala si activás X en la instalación es xenodm (su propio fork de XDM, simple, sin temas bonitos).
  • No hay soporte fuerte de Wayland por defecto; el ecosistema sigue centrado en X11. Hay quien corre sway/labwc a mano, pero no es el camino estándar.

Window manager (la parte que sorprende a la gente)

  • Si instalás los sets de X y no configurás nada en ~/.xsession o ~/.xinitrc, lo que arranca es fvwm (versión 2.2.5, vieja) más un xterm. Literalmente es el default técnico.
  • Sin embargo, en la comunidad casi nadie usa fvwm a propósito. El window manager “de facto” preferido por usuarios de OpenBSD es cwm (Calm Window Manager), que también viene en el sistema base — es minimalista, manejado por teclado, con tiling básico, y es obra de los propios desarrolladores de OpenBSD. Es lo más parecido a un “estándar no oficial”.
  • También viene twm en el set base, pero casi nadie lo usa a diario.
  • No hay GNOME, KDE, Xfce, MATE ni LXQt instalados por defecto — son paquetes que instalás aparte (pkg_add gnome, etc.). En la 7.9 están disponibles GNOME 49, KDE Plasma 6.6, MATE 1.28, Xfce 4.20 y LXQt 2.2, pero ninguno es “el” entorno oficial.

Resumen de lo que verías recién instalado

xenodm (login) → fvwm + xterm (sesión). Eso es todo. Sin barra de tareas, sin iconos, sin nada.

Lo que realmente usa la gente que hace de OpenBSD su escritorio diario

Un patrón muy típico en foros/blogs es: xenodm + cwm + xterm (o un terminal de paquete) + tmux, todo configurado a mano vía dotfiles. Es la combinación “espíritu OpenBSD”: ligero, sin daemons de sesión, sin D-Bus si se puede evitar.

Audio: ni PulseAudio ni PipeWire

Esto es clave y diferente de Linux: OpenBSD tiene su propio sistema de sonido nativo llamado sndio (demonio sndiod), creado por los propios desarrolladores de OpenBSD (Alexandre Ratchov). Es minimalista, mezcla audio de varias apps, controla volumen por programa, etc. — cumple el rol de Pulse/Pipewire pero con una fracción del código y las dependencias.

  • Firefox, Chromium y la mayoría de paquetes de audio en OpenBSD se compilan con backend sndio por defecto.
  • PulseAudio existe como paquete (para casos de compatibilidad), pero no es el sistema usado normalmente.
  • PipeWire prácticamente no se usa en OpenBSD; el ecosistema no lo necesita porque sndio ya resuelve ese problema desde hace casi 15 años.

No viene ningún navegador gráfico en el sistema base — tenés que instalarlo. Los más usados en la comunidad son:

  • Firefox (el más común, paquete oficial, compilado con sndio)
  • Chromium (también muy usado, igual con sndio) No hay un navegador “oficial por defecto” como tal.

Otros detalles relevantes

  • Sistema de archivos: FFS2 (heredero del Berkeley FFS), no hay journaling — OpenBSD se la juega con fsck al boot en vez de un FS con journal.
  • Init: su propio /etc/rc, nada de systemd, nada de D-Bus salvo que un entorno gráfico pesado (GNOME/KDE) lo necesite como dependencia.
  • Paquetes: pkg_add, pkg_info, pkg_delete para binarios precompilados; el árbol de “ports” es para compilar desde fuente si querés.
  • Terminal multiplexer: tmux viene en el sistema base (OpenBSD es upstream de tmux), así que muchos usuarios ni instalan otro terminal “bonito”, solo usan xterm + tmux.
  • Compositor/efectos: nada de esto por defecto, es un sistema pensado para servidores/firewalls/routers primero, escritorio después.

La versión actual es OpenBSD 7.9 (mayo 2026), así que si instalás ahora es lo que vas a tener de base.

Si querés, te puedo armar una guía de configuración típica post-instalación (xenodm + cwm + sndio + Firefox) con los archivos de dotfiles más comunes que usa la gente.

Streaming from OpenBSD works, but the path is different than on Linux — there’s no PulseAudio/ALSA and no out-of-the-box OBS Studio. The reliable route is ffmpeg talking directly to OpenBSD’s native audio/video layers (sndio and video(4)). Here’s the practical setup.

1. Enable capture (disabled by default for privacy)

OpenBSD disables video recording by default for privacy reasons, and you enable it via the kern.video.record sysctl. The same applies to audio capture — it’s disabled by default and enabled with kern.audio.record=1.

doas sysctl kern.video.record=1
doas sysctl kern.audio.record=1
echo "kern.video.record=1" | doas tee -a /etc/sysctl.conf
echo "kern.audio.record=1" | doas tee -a /etc/sysctl.conf

2. Check your devices

  • Webcam: USB webcams following the UVC spec are handled by the uvideo(4) driver and exposed through the video(4) layer, showing up in dmesg and becoming accessible as /dev/video0. Run dmesg | grep video to confirm, and you may need chown $USER /dev/video0.
  • Microphone/audio: managed by sndiod(8). Run sndioctl to see controls, and check dmesg | grep audio — devices appear as snd/0, snd/1, etc.

3. Install ffmpeg

doas pkg_add ffmpeg

4. Stream to Twitch/YouTube

A typical setup grabs your desktop with x11grab, your mic with sndio, encodes with libx264, and pushes RTMP:

ffmpeg \
  -f x11grab -framerate 30 -s 1920x1080 -i :0.0 \
  -f sndio -i snd/0 \
  -c:v libx264 -preset veryfast -b:v 3000k -pix_fmt yuv420p \
  -c:a aac -b:a 160k \
  -f flv rtmp://live.twitch.tv/app/YOUR_STREAM_KEY

For YouTube, swap the URL for rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY.

To pull in a webcam instead of/alongside the desktop, point at the device — on a recent OpenBSD build that’s -f v4l2 -i /dev/video0, similar to Linux despite there being no actual V4L2 subsystem under the hood.

5. About OBS Studio

Worth knowing up front: OBS doesn’t have an official OpenBSD package. A developer added preliminary OpenBSD support to OBS Studio starting around release 26.1.0, including a native sndio plugin for lower-latency audio, but as of that work it hadn’t been submitted to the ports tree — it’s still sitting in a WIP ports overlay rather than something you can pkg_add. So ffmpeg is the realistic default tool right now.

6. Skip the raw command-line if you want

A couple of community wrapper scripts exist specifically to smooth over OpenBSD’s quirks (no built-in screencast tool, ffmpeg threading limits, syncing audio/video):

  • fauxstream — runs parallel ffmpeg pipes to work around single-threaded bottlenecks, handles mixing mic + monitor audio.
  • ffmpeg_openbsd — scripts geared specifically at YouTube live streaming, reads your stream key from a file.

Both are just convenience layers over the same ffmpeg + sndio + x11grab approach above.

One gotcha to know about going in: capturing desktop audio (not just mic) requires setting up a sndio “monitor” sub-device (rcctl set sndiod flags -s default -m play,mon -s mon) since OpenBSD doesn’t expose a loopback device the way PulseAudio does — happy to walk through that if you want to stream game/system audio rather than just your voice.