Unix, portabilidad y código abierto

Dos cocinas pueden seguir recetas parecidas sin tener los mismos equipos ni emplear a los mismos cocineros. Del mismo modo, dos sistemas operativos pueden compartir ideas e interfaces sin compartir cada línea de código. La historia de Unix se entiende mejor separando influencia, ascendencia y compatibilidad.

Un sistema práctico que podía viajar

Unix comenzó en Bell Labs en 1969. Sus primeros pasos respondieron a hardware limitado y necesidades concretas, como programar y procesar textos. El sistema favorecía combinar herramientas mediante interfaces comunes. Así, el entorno resultaba más útil que cualquier comando aislado.

Reescribir gran parte de Unix en C en 1973 cambió el esfuerzo de llevarlo a otro hardware. El ensamblador está muy ligado a un procesador; un lenguaje de mayor nivel expresa más partes del programa sin detallar cada particularidad de la máquina. Pero la portabilidad exige trabajo. Dispositivos, tamaños de datos, compiladores e interfaces pueden necesitar adaptación.

Las historias de Dennis Ritchie presentan esas decisiones como experimentos y respuestas a restricciones reales. Leerlas ayuda a evitar la idea de que los sistemas actuales surgieron de un único plan perfecto.

Familias parecidas, ascendencias diferentes

Unix se difundió mediante investigación, productos comerciales y ramas como BSD. Las licencias, las instituciones y la disponibilidad del código influyeron en esa expansión. Sistemas posteriores adoptaron conceptos familiares de procesos y archivos con motivos e implementaciones diferentes.

El anuncio de GNU de 1983 proponía un sistema compatible con Unix que pudiera compartirse libremente. Linux comenzó en 1991 como un kernel de tipo Unix escrito de forma independiente. No es simplemente la siguiente versión del código original de Unix. Una distribución puede combinar Linux con herramientas GNU y muchos otros proyectos; algunas plataformas basadas en Linux eligen bibliotecas y entornos de aplicaciones muy distintos.

Kernel, distribución y aplicación son capas diferentes. Decir “esto ejecuta Linux” no identifica todos sus programas, políticas de permisos, orígenes de paquetes ni responsables de actualizarlo.

La apertura ofrece posibilidades

Disponer del código puede facilitar aprendizaje, revisión, adaptación y reparaciones independientes. Convertir esas posibilidades en garantías requiere personas y procesos. Un repositorio visible puede recibir pocas revisiones. Una corrección en el código quizá todavía no haya llegado al paquete instalado.

Piensa en una aplicación meteorológica ficticia que usa una biblioteca de imágenes. La pregunta de mantenimiento es concreta: qué versión contiene, quién entrega un paquete corregido y cómo lo recibirá la aplicación. Saber la familia del sistema operativo no responde toda esa cadena.

PrediceDos dispositivos anuncian que usan Linux. ¿Puedes suponer que tienen las mismas utilidades, políticas y fechas de actualización?

No. Pueden compartir familia de kernel y tener versiones, bibliotecas, políticas y responsables distintos. Compara los componentes reales y sus acuerdos de soporte.

Cambiaron las posibilidades de trasladar ideas e implementaciones de software. Persistió la necesidad de saber qué se ejecuta y quién lo mantiene. Por eso importan los inventarios de componentes y las actualizaciones confiables, aunque cualquiera pueda consultar el código.