⏱️ Lectura: 13 min
En septiembre de 2005, un administrador de redes del Reino Unido escribió a la lista de correo netbsd-advocacy para contar algo simple: la estabilidad de NetBSD le permitió migrar 29 servidores de producción desde Windows y casi eliminar las llamadas de madrugada por caídas del sistema.
📑 En este artículo
El autor, Gary Rolland, formaba parte de un equipo de cuatro administradores que sostenía una red crítica para una empresa británica que no pudo nombrar. Su correo, informal y sin filtro corporativo, terminó siendo una de las anécdotas más citadas en la comunidad NetBSD sobre por qué un sysadmin cambia de sistema operativo en medio de la operación.
TL;DR
- En 2005, un admin de red del Reino Unido migró 29 servidores de Windows a NetBSD 2.0.2 en producción.
- La infraestructura NetBSD atendía a más de 4.800 usuarios y movía en promedio 870 GB de datos por día.
- Los servidores corrían MySQL, Apache, Postfix y Samba sobre NetBSD, con file servers Linux detrás.
- El equipo procesaba unos 1.200 correos diarios y hasta 35 solicitudes HTTP por minuto en horas pico.
- Tras el cambio, las caídas nocturnas que motivaban llamadas de guardia se redujeron drásticamente.
- La historia fue publicada como testimonio en la lista de correo [email protected] el 10 de septiembre de 2005.
- Hoy, NetBSD 11.0 mantiene el mismo enfoque de portabilidad y pkgsrc que atrajo a ese equipo hace más de dos décadas.
Qué pasó: el correo de Gary Rolland
Rolland trabajaba en un equipo de cuatro administradores de red que operaba en turnos rotativos, con guardias nocturnas incluidas. La red era, en sus palabras, mission critical: cualquier caída le costaba dinero a la empresa. El equipo no gestionaba las máquinas cliente de los edificios, solo la infraestructura de servidores.
Antes de NetBSD, esa infraestructura corría sobre Windows en hardware más viejo del que tenían al momento de escribir el correo. Según el propio texto, publicado en la lista netbsd-advocacy el 10 de septiembre de 2005, las caídas eran tan frecuentes que Rolland vivía pendiente del teléfono, incluso durante salidas familiares.
El quiebre llegó una noche en la que había prometido llevar a su hija y a una amiga de ella a un parque de diversiones. El teléfono de guardia sonó a mitad del paseo: los servidores habían caído de rodillas, en palabras de su jefe. Rolland tuvo que abandonar la salida para resolver el incidente, algo que ya se había repetido varias veces.
Esa noche, según relata, decidió que algo tenía que cambiar. Convenció a su jefe de dejarlo probar NetBSD en dos servidores: uno de MySQL y uno de Apache, sin avisar en detalle qué sistema operativo iba a usar. La condición fue simple: si algo salía mal, la responsabilidad era suya.
Rolland pasó la noche instalando y configurando esos dos servidores, usando paquetes de pkgsrc para no compilar todo desde cero. A la mañana siguiente los integró a la red de producción y esperó: bastó con que, ese mismo día, varias máquinas MySQL con Windows fallaran y se reiniciaran solas por consultas lentas para que su jefe autorizara expandir la prueba a más servidores.
La migración completa no fue inmediata. Los otros tres administradores del equipo no conocían NetBSD, así que Rolland les enseñó a compilar kernels y a usar pkgsrc mientras el tiempo libre que les dejaba la nueva estabilidad se lo permitía. Según cuenta, llegó a imprimir el manual completo de NetBSD para el equipo. Con el tiempo, toda la red pasó a correr sobre NetBSD.
La estabilidad de NetBSD en números
El correo detalla con precisión inusual la carga que sostenía la infraestructura. Según Rolland, la estabilidad de NetBSD se puso a prueba con 29 servidores de alta gama corriendo NetBSD 2.0.2, que movían en promedio 870 GB de datos por día y procesaban unos 1.200 correos diarios a través de Postfix, tanto internos como externos.
Durante las horas pico, los servidores Apache (usados para tráfico interno y externo) atendían hasta 35 solicitudes HTTP por minuto, sirviendo un sitio interno escrito en PHP que el propio Rolland describe, con humor, como bastante pesado y bastante malo. Samba conectaba a los 4.800 usuarios de la empresa con los servidores de archivos, que corrían Linux por decisión ajena al equipo de Rolland: él no tenía permiso para tocarlos.
MySQL, según el correo, representaba la mayor parte del tráfico y consumo de recursos de toda la infraestructura. La combinación de MySQL, Apache, Postfix y Samba sobre NetBSD es, en esencia, un stack LAMP con NetBSD en lugar de Linux, algo poco común de ver documentado con esa cantidad de detalle operativo para la época.
Contexto e historia: de dónde viene NetBSD
NetBSD nació en 1993 como uno de los primeros derivados de 386BSD, junto con FreeBSD, cuando un grupo de desarrolladores decidió mantener y depurar el código de Berkeley por su cuenta. Desde el principio, el proyecto se organizó alrededor de un objetivo distinto al de sus primos: correr en la mayor cantidad posible de arquitecturas de hardware, del VAX al Raspberry Pi.
Ese mismo año, un litigio legal entre USL y BSDi frenó temporalmente la distribución del código BSD, lo que aceleró la necesidad de reescribir partes del sistema y consolidó a NetBSD, FreeBSD y, más tarde en 1995, OpenBSD como proyectos separados con énfasis distintos: NetBSD en portabilidad, FreeBSD en rendimiento sobre x86 y OpenBSD en seguridad por defecto.
Ese objetivo de portabilidad quedó resumido en el lema informal del proyecto, of course it runs NetBSD, una broma recurrente en la comunidad sobre instalar el sistema en dispositivos inesperados. Para un equipo de sysadmins como el de Rolland, esa portabilidad no era una curiosidad: significaba que el mismo sistema operativo podía correr, sin sorpresas, tanto en servidores de alta gama como en hardware más modesto.
En 1997 apareció pkgsrc, el sistema de gestión de paquetes de NetBSD, con una particularidad que lo distingue hasta hoy: funciona también en Linux, macOS, Solaris y otros Unix, no solo en NetBSD. El correo de Rolland menciona que instaló la mayoría del software requerido desde pkgsrc, lo que a mediados de la década de 2000 ya era una ventaja frente a compilar todo a mano.
Arquitectura de los 29 servidores
La arquitectura que describe el correo separa con claridad las capas de la infraestructura. Los usuarios se conectaban a los servidores NetBSD corriendo Samba, que a su vez hablaban con servidores de archivos NFS corriendo Linux, fuera del control directo del equipo de Rolland. En paralelo, otro grupo de servidores NetBSD manejaba MySQL, Apache y Postfix.
flowchart TD
U["4.800 usuarios"] --> S["Servidores NetBSD (Samba)"]
S --> F["Servidores de archivos (Linux)"]
U --> A["Servidores NetBSD (Apache + PHP)"]
U --> M["Servidores NetBSD (Postfix)"]
A --> D[("MySQL")]
subgraph Infraestructura NetBSD
S
A
M
D
endEsta separación explica por qué el correo aclara, casi con orgullo, que los servidores de archivos se caen más que los nuestros: la parte que corría NetBSD 2.0.2 resultó más estable que la capa Linux que el equipo no gestionaba.
📌 Nota: El propio Rolland admite en su correo que el sitio interno de la empresa estaba escrito en bastante pesado y bastante malo PHP, una autocrítica poco común en este tipo de testimonios técnicos.
Cómo probar NetBSD hoy (Windows, macOS y Linux)
Dos décadas después de ese correo, NetBSD sigue activo y en su versión 11.0. Probarlo hoy no requiere reemplazar servidores de producción: alcanza con una máquina virtual en cualquier sistema operativo de escritorio.
| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| QEMU/KVM (Linux) | Tenés Linux como host y querés aceleración nativa | Rendimiento cercano al metal con -enable-kvm | Requiere virtualización habilitada en el kernel |
| UTM/QEMU (macOS) | Mac con Apple Silicon o Intel | Interfaz gráfica simple sobre QEMU | Apple Silicon corre NetBSD solo emulado, no nativo arm64 de Apple |
| VirtualBox | Windows, macOS o Linux, sin preferencia por CLI | Multiplataforma y con GUI para configurar todo | Más lento que KVM nativo en Linux |
| Bare metal | Servidor dedicado o laptop vieja, como hizo Rolland | Rendimiento real, sin capa de virtualización | Requiere hardware compatible con los drivers de NetBSD |
En Linux, con QEMU y KVM instalados:
sudo apt install qemu-system-x86 -y
qemu-img create -f qcow2 netbsd.qcow2 20G
qemu-system-x86_64 -m 2048 -smp 2 -hda netbsd.qcow2 \
-cdrom NetBSD-11.0-amd64.iso -boot d -enable-kvmEsto crea un disco virtual de 20 GB y arranca el instalador de NetBSD 11.0 con 2 GB de RAM y 2 núcleos, usando la aceleración de KVM del host.
En macOS, con QEMU instalado vía Homebrew:
brew install qemu
qemu-img create -f qcow2 netbsd.qcow2 20G
qemu-system-x86_64 -m 2048 -smp 2 -hda netbsd.qcow2 \
-cdrom NetBSD-11.0-amd64.iso -boot d -accel hvfEl flag -accel hvf usa el Hypervisor Framework de macOS en lugar de KVM, que es exclusivo de Linux.
En Windows, con VirtualBox instalado, desde PowerShell:
VBoxManage createvm --name "NetBSD-Lab" --ostype "NetBSD_64" --register
VBoxManage modifyvm "NetBSD-Lab" --memory 2048 --cpus 2
VBoxManage createhd --filename NetBSD-Lab.vdi --size 20480
VBoxManage storagectl "NetBSD-Lab" --name "IDE" --add ide
VBoxManage storageattach "NetBSD-Lab" --storagectl "IDE" \
--port 1 --device 0 --type dvddrive --medium NetBSD-11.0-amd64.isoUna vez instalado, en cualquiera de los tres casos, se puede confirmar la versión y el estado del sistema con dos comandos dentro de la máquina virtual:
$ uname -a
NetBSD netbsd-lab 11.0 NetBSD 11.0 (GENERIC) amd64
$ pkg_info | head -5uname -a confirma la versión exacta del kernel, y pkg_info lista los paquetes instalados vía pkgsrc, el mismo sistema que Rolland usó en 2005 para levantar MySQL, Apache, Postfix y Samba.
Para instalar ese mismo stack hoy, con pkgsrc ya bootstrapeado:
pkgin install apache24 postfix mysql-server samba
Impacto y por qué esta historia importa en 2026
La anécdota de Rolland circula desde hace más de veinte años en foros y listas de BSD como ejemplo de un patrón que se repite: equipos que migran servicios críticos a NetBSD u OpenBSD no por moda, sino porque necesitan previsibilidad. La estabilidad de NetBSD, en ese caso puntual, se tradujo en menos incidentes fuera de horario y menos desgaste para un equipo de guardia.
Ese tipo de testimonio también explica por qué NetBSD mantiene, todavía hoy, una cultura de transparencia poco común: el equipo de seguridad del proyecto publica fallos conocidos incluso en sus lanzamientos mayores en lugar de ocultarlos hasta el parche siguiente. Es una práctica que refuerza la misma idea de confiabilidad operativa que describe el correo de 2005.
⚠️ Ojo: NetBSD prioriza portabilidad y limpieza de código sobre soporte masivo de hardware moderno. Para servidores con GPUs recientes o laptops con hardware muy nuevo, el soporte de drivers suele ir por detrás de Linux, y conviene verificar la lista de hardware soportado antes de migrar producción.
Ese es el trade-off real: la misma disciplina que le dio a Rolland 29 servidores estables es la que hace que NetBSD no sea la opción por defecto para hardware de escritorio de última generación. Elegir NetBSD hoy sigue siendo una decisión consciente, no un reemplazo automático de Linux.
Para un lector técnico en 2026, la lección no es usar NetBSD en vez de Linux, sino algo más simple: medir antes de migrar. Rolland no cambió el sistema operativo de toda la red de una sola vez; primero probó dos servidores, esperó una falla real de la competencia y recién después escaló la migración con datos concretos, no con una corazonada.
Qué sigue
NetBSD continúa su desarrollo con lanzamientos regulares, el más reciente siendo la serie 11.0, y sigue apoyándose en pkgsrc como su mecanismo principal de distribución de software, ahora usado también fuera del propio NetBSD. La filosofía que describe el correo de 2005 (portabilidad, simplicidad y previsibilidad) sigue siendo el argumento central del proyecto más de tres décadas después de su fundación.
Para equipos de infraestructura en LATAM que evalúan alternativas a Linux para cargas específicas (firewalls, appliances de red, servidores de correo dedicados), historias como la de Rolland siguen siendo un punto de partida útil: no como benchmark, sino como recordatorio de que la estabilidad percibida por un equipo de operaciones importa tanto como cualquier métrica de rendimiento.
📖 Resumen en Telegram: Ver resumen
Probalo vos: instalá NetBSD 11.0 en una máquina virtual con QEMU o VirtualBox hoy mismo y corré uname -a para confirmar la versión antes de decidir si migra algo real.
Preguntas frecuentes
¿Qué es NetBSD?
Es un sistema operativo Unix de código abierto, derivado de BSD, con foco histórico en portabilidad entre arquitecturas de hardware distintas.
¿NetBSD 2.0.2 sigue siendo la versión recomendada?
No. NetBSD 2.0.2 es de 2005; la serie activa hoy es NetBSD 11.0, con mejoras de seguridad, drivers y soporte de arquitecturas que la versión original del correo no tenía.
¿pkgsrc solo funciona en NetBSD?
No. pkgsrc también corre en Linux, macOS, Solaris y otros sistemas Unix, aunque nació como el gestor de paquetes nativo de NetBSD.
¿Sirve NetBSD para reemplazar un servidor Linux en producción?
Depende de la carga y el hardware. Para servicios como MySQL, Apache, Postfix o Samba, como en el caso de Rolland, es una opción viable; para hardware muy nuevo o cargas que dependen de drivers específicos de Linux, conviene evaluar con cuidado.
¿Dónde se puede leer el correo original de Gary Rolland?
Está archivado públicamente en la lista de correo netbsd-advocacy, con fecha del 10 de septiembre de 2005.
Referencias
- Mail-index NetBSD Advocacy: correo original de Gary Rolland del 10 de septiembre de 2005.
- NetBSD.org: sitio oficial del proyecto y descargas de las versiones actuales.
- pkgsrc.org: documentación del sistema de paquetes multiplataforma de NetBSD.
- Wikipedia: NetBSD: historia y línea de tiempo del proyecto desde 1993.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Taylor Vick en Unsplash
0 Comentarios