Unix, Linux, Windows y macOS

1. Dos linajes

En el tema 3 recorrimos la historia de los sistemas operativos como una sucesión de problemas y soluciones. Aquí la miramos como una genealogía, porque explica el presente con muy pocos trazos. De los muchos sistemas que existieron, los que hoy se usan descienden casi todos de dos: Unix, de 1969, y Windows NT, de 1993, que a su vez heredó ideas de un sistema anterior llamado VMS.

El dibujo adelanta las tres ideas del tema. La rama superior es una familia en sentido estricto, con código que pasó de un sistema a otro. Linux pertenece a ella por adopción: se comporta como Unix sin contener una línea suya. Y la rama inferior es un diseño independiente, que resolvió los mismos problemas con otras decisiones.

2. Unix: una palabra, tres significados

Buena parte de la confusión en este terreno proviene de que «Unix» se usa con tres sentidos distintos, y un mismo sistema puede cumplir uno y no otro:

El tercer sentido es el que importa a quien programa, y es el que usamos en este curso. Un sistema tipo Unix es aquel donde copiar.c se compila sin cambios, donde ls | wc -l hace lo esperado y donde los conceptos de los temas anteriores se aplican tal cual.

Linux es el caso más ilustrativo. Torvalds lo escribió desde cero, sin código de Unix, y nadie pagó nunca la certificación. No es Unix en el primer sentido ni en el segundo. Lo es por completo en el tercero, hasta el punto de ser hoy el sistema tipo Unix más usado, con mucha diferencia.

3. Los descendientes directos

La rama histórica sigue viva, aunque con menos presencia que hace treinta años:

Los sistemas BSD se diferencian de Linux en algo que la tabla del tema 10 permite precisar. En Linux, el kernel, la biblioteca de C, la shell y las utilidades son proyectos independientes que una distribución reúne. En un BSD, todo eso lo desarrolla un mismo equipo, en un único repositorio, y se publica junto: FreeBSD es un sistema operativo completo, no un kernel. La otra diferencia es la licencia. La de BSD permite incorporar el código a productos cerrados sin publicar los cambios, y por eso aparece dentro de sistemas comerciales, macOS entre ellos.

4. Linux: un kernel, muchas distribuciones

En el tema 1 distinguimos el kernel de la distribución, y en el tema 10 vimos que una distribución reúne componentes de proyectos distintos. Falta explicar por qué hay cientos y en qué difieren realmente.

Que existan tantas es consecuencia directa de ese modelo. Si las piezas son libres e independientes, cualquiera puede combinarlas a su manera, y cada combinación responde a una prioridad: estabilidad para servidores, software reciente para desarrolladores, tamaño mínimo para contenedores. Las decisiones que distinguen a una distribución de otra son estas:

Las distribuciones se agrupan en familias, según de cuál derivan y qué gestor de paquetes comparten:

A lo largo del curso fuimos anotando las diferencias al pasar: apt o dnf, update-grub o grub2-mkconfig, /lib/x86_64-linux-gnu o /lib64. Todas son de este orden. Lo que no cambia de una distribución a otra es lo que estudiamos: el kernel, sus llamadas al sistema, la interfaz POSIX, /proc, el formato ELF. Un programa en C de este curso se compila igual en todas.

Hay una excepción, que ya conocemos del tema 15: la biblioteca de C. Un ejecutable compilado en Ubuntu, contra glibc, no funciona en Alpine, que usa musl. Y Android, que comparte el kernel, está todavía más lejos: como vimos en el tema 10, reemplaza casi todo el espacio de usuario, y no se lo considera una distribución en el sentido habitual.

5. Identificar un sistema

Todas las distribuciones actuales se describen a sí mismas en un archivo de formato común, /etc/os-release, del que vimos dos líneas en el tema 1:

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
…

Las dos líneas resaltadas son las útiles para un programa. ID identifica la distribución, y ID_LIKE, la familia de la que deriva: un script que sabe trabajar con Debian puede reconocer que también sirve para Ubuntu, o para una derivada que nunca oyó nombrar. El archivo tiene además una propiedad conveniente: sus líneas son asignaciones válidas de Bash, de modo que un script puede incorporarlo directamente.

#!/bin/bash
# Informa la distribución, su familia y su gestor de paquetes.

. /etc/os-release                   # define NAME, VERSION_ID, ID, ID_LIKE...

echo "Distribucion: $NAME $VERSION_ID"
echo "Kernel:       $(uname -sr)"

case " $ID $ID_LIKE " in
    *" debian "*)             echo "Familia:      Debian (paquetes .deb, gestor apt)" ;;
    *" fedora "*|*" rhel "*)  echo "Familia:      Red Hat (paquetes .rpm, gestor dnf)" ;;
    *" suse "*)               echo "Familia:      SUSE (paquetes .rpm, gestor zypper)" ;;
    *" arch "*)               echo "Familia:      Arch (gestor pacman)" ;;
    *" alpine "*)             echo "Familia:      Alpine (gestor apk, biblioteca musl)" ;;
    *)                        echo "Familia:      no reconocida ($ID)" ;;
esac

$ chmod +x familia.sh
$ ./familia.sh
Distribucion: Ubuntu 24.04
Kernel:       Linux 6.8.0-45-generic
Familia:      Debian (paquetes .deb, gestor apt)

La salida tiene dos versiones, y son las dos caras del sistema: la de la distribución, 24.04, y la del kernel, 6.8. Se actualizan por separado. El script reconoce a Ubuntu como miembro de la familia Debian sin que «ubuntu» figure en ninguna de sus comparaciones: lo hace por ID_LIKE.

6. Windows: el otro linaje

Windows NT no desciende de Unix ni intenta parecérsele. Su arquitecto principal, Dave Cutler, había dirigido antes el diseño de VMS, el sistema de las minicomputadoras de Digital, y llevó consigo sus ideas. El resultado es un sistema que resuelve los mismos problemas —procesos, memoria virtual, archivos, protección— con un vocabulario y unas decisiones propias.

La segunda fila explica una observación del tema 13. En Linux pudimos escribir hola.s, un programa que habla con el kernel por número de llamada, porque esos números son un compromiso público. En Windows, un programa así dejaría de funcionar con la siguiente actualización. Allí el contrato está un nivel más arriba, en las bibliotecas, y es el que Microsoft mantiene compatible desde hace treinta años con un cuidado notable: programas de los años noventa siguen ejecutándose.

La tercera fila la veremos con detalle en el tema 26. En el tema 16 observamos con strace la secuencia de Unix: clone para duplicar el proceso y execve para cargar el programa. Windows no tiene un equivalente del primer paso, y es una de las diferencias que más trabajo dan al llevar programas de un sistema a otro.

NT fue diseñado, además, con la idea de admitir varias «personalidades»: subsistemas que ofrecieran a los programas la interfaz de otros sistemas operativos. De esa idea salió, mucho después, el subsistema de Windows para Linux que presentamos en el tema 4.

7. macOS: un Unix con otra cara

La apariencia de macOS no lo sugiere, pero debajo hay un sistema Unix en los tres sentidos de la sección 2. Su base se llama Darwin, y está formada por el kernel XNU, que estudiamos en el tema 24, y un espacio de usuario tomado en buena parte de FreeBSD. Sobre esa base, Apple construye lo que el usuario reconoce: el entorno gráfico y las bibliotecas con que se escriben las aplicaciones. iOS y los demás sistemas de la empresa comparten el mismo fundamento.

Para quien llega desde Linux, la terminal de macOS resulta familiar: la misma shell, los mismos comandos, gcc y make disponibles. Los programas de este curso que usan solo POSIX se compilan sin cambios. Las diferencias aparecen al salir de ese terreno común:

La cuarta fila es una fuente clásica de sorpresas. Un script que usa una opción de sed o de date propia de las versiones de GNU funciona en Linux y falla en una Mac, aunque el comando exista en los dos. Es el mismo problema de portabilidad del tema 15, trasladado de las funciones de C a los comandos: lo que garantiza el estándar es un subconjunto, y las extensiones de cada familia no coinciden.

8. POSIX, en la práctica

En el tema 15 vimos qué es POSIX y qué define. Ahora podemos decir qué significa en concreto para lo que hicimos en este curso. La tabla clasifica lo que usamos según dónde funciona:

La tabla se lee de dos maneras. Para escribir programas, marca tres niveles de portabilidad: lo que funciona en todas partes, lo que funciona en la familia Unix y lo que es exclusivo de Linux. Para aprender, explica la elección del curso: las filas inferiores, las menos portables, son justamente las que permiten ver el sistema operativo trabajando. Ningún otro sistema de uso general expone tanto de sí mismo.

Y hay que separar las herramientas de los conceptos. /proc/interrupts no existe en una Mac, pero las interrupciones sí, y funcionan como describimos. Lo que aprendiste mirando Linux vale para los demás; lo que cambia es dónde mirar.

9. Qué cambia para quien programa

Esta es la tabla de consulta del tema. Reúne las diferencias con que se encuentra, tarde o temprano, quien escribe un programa que debe funcionar en más de un sistema:

Varias filas tienen consecuencias que no se adivinan a primera vista:

• El formato de ejecutable es la razón más inmediata por la que un programa compilado no pasa de un sistema a otro, aunque el procesador sea el mismo. El kernel de cada uno solo sabe cargar el suyo, como vimos en el tema 9.
• El fin de línea afecta a la biblioteca de C. En Windows, un archivo abierto en modo texto se traduce al leer y al escribir: cada \n del programa se guarda como dos bytes. Por eso fopen tiene un modo binario, que en Linux no produce ninguna diferencia y que conviene escribir siempre que se manejen datos que no son texto.
• El tamaño de long es una trampa clásica. Un programa que guarda un puntero o el tamaño de un archivo grande en un long funciona en Linux y falla en Windows. Para eso existen los tipos de tamaño explícito, como int64_t, y los que usamos en el tema 14: size_t y ssize_t.
• Borrar un archivo abierto explica una diferencia visible para cualquier usuario. Linux puede reemplazar una biblioteca mientras hay programas usándola, porque los archivos abiertos siguen existiendo hasta que se cierran; por eso se actualiza casi todo sin reiniciar. Windows no lo permite, y de ahí vienen los reinicios al instalar actualizaciones.

10. Experimento: el mismo código, otro sistema

El compilador define unas macros que indican para qué sistema está compilando. Con ellas, un mismo archivo fuente puede adaptarse en el momento de compilar:

#include <stdio.h>

#if defined(_WIN32)
#  define SISTEMA "Windows"
#elif defined(__APPLE__)
#  define SISTEMA "macOS"
#elif defined(__linux__)
#  define SISTEMA "Linux"
#else
#  define SISTEMA "otro"
#endif

#if defined(__unix__) || defined(__APPLE__)
#  include <unistd.h>                  /* existe solo en los sistemas tipo Unix */
#  define HAY_POSIX 1
#else
#  define HAY_POSIX 0
#endif

int main(void)
{
    printf("Sistema:           %s\n", SISTEMA);
    printf("Tamano de long:    %d bytes\n", (int)sizeof(long));
    printf("Tamano de puntero: %d bytes\n", (int)sizeof(void *));

#if HAY_POSIX
    printf("POSIX:             version %ld, PID %d\n", (long)_POSIX_VERSION, (int)getpid());
#else
    printf("POSIX:             no disponible\n");
#endif
    return 0;
}

Para obtener un ejecutable de Windows no hace falta Windows. Un compilador cruzado se ejecuta en un sistema y produce programas para otro; el paquete gcc-mingw-w64-x86-64 instala uno. Compilamos el mismo archivo dos veces:

$ gcc -Wall -Wextra -g plataforma.c -o plataforma
$ ./plataforma
Sistema:           Linux
Tamano de long:    8 bytes
Tamano de puntero: 8 bytes
POSIX:             version 200809, PID 7412

$ sudo apt install gcc-mingw-w64-x86-64
$ x86_64-w64-mingw32-gcc -Wall -Wextra plataforma.c -o plataforma.exe
$ file plataforma plataforma.exe
plataforma:     ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, …
plataforma.exe: PE32+ executable (console) x86-64, for MS Windows

$ ./plataforma.exe
bash: ./plataforma.exe: cannot execute binary file: Exec format error

Los dos archivos contienen instrucciones para el mismo procesador, traducidas del mismo código fuente. El kernel de Linux rechaza el segundo en la llamada execve: lee sus primeros bytes, no encuentra el número mágico de ELF que conocimos en el tema 9, y devuelve un error. No llega a ejecutar una sola instrucción. Copiado a un equipo con Windows, ese archivo produce esto:

Sistema:           Windows
Tamano de long:    4 bytes
Tamano de puntero: 8 bytes
POSIX:             no disponible

Tres de las cuatro líneas cambiaron, y cada una corresponde a una fila de la tabla anterior: el sistema, el tamaño de long y la ausencia de unistd.h. El código fuente es portable porque prevé las diferencias; el ejecutable no lo es en ningún caso.

11. Capas de compatibilidad

Existen muchas herramientas para usar los programas de un sistema en otro. Parecen un conjunto heterogéneo, y se ordenan con una sola pregunta: ¿qué interfaz reemplazan? En el tema 10 distinguimos tres, y hay técnicas para cada una, además de la del hardware.

La historia de WSL recorre dos filas de la tabla, y enseña algo. La primera versión traducía llamadas al sistema: era liviana, y nunca logró reproducir con fidelidad todos los comportamientos del kernel de Linux. La segunda abandonó ese camino y ejecuta un kernel de Linux real en una máquina virtual. Imitar una interfaz tan amplia resultó más difícil que ejecutar el original.

La última fila resuelve un problema distinto de los otros tres, y se confunde con ellos a menudo. Rosetta no cambia de sistema operativo, sino de procesador: el programa sigue siendo de macOS. Las dos barreras son independientes, y un ejecutable solo funciona donde coinciden ambas, el sistema y la arquitectura.

12. Dónde se usa cada uno

La pregunta por «el sistema operativo más usado» no tiene una respuesta única, porque depende del tipo de equipo. Cada ámbito tiene su reparto, y son muy distintos entre sí:

Contando todos los equipos, el kernel más extendido del mundo es Linux, por los teléfonos y los servidores, aunque su presencia en los escritorios sea pequeña. Y si se agrupa por linaje, la familia de Unix —con Linux, Android, macOS e iOS— abarca la gran mayoría de las computadoras en uso. El sistema que Thompson y Ritchie escribieron para una máquina que nadie quería dejó la descendencia más numerosa de la historia del software.

13. Lo que no cambia

Este tema estuvo dedicado a las diferencias, y conviene cerrarlo con la proporción correcta. Las diferencias están en la superficie: en los nombres, los formatos y las interfaces. Por debajo, los cuatro sistemas del título son el mismo tipo de objeto.

No es una coincidencia. Todos se ejecutan sobre los mismos procesadores, que ofrecen los mismos mecanismos, y todos heredaron las ideas de los mismos sistemas de los años sesenta y setenta. Quien entiende uno a fondo tiene hecho la mayor parte del camino para entender los otros: le falta aprender los nombres.

Con esto termina el bloque sobre tipos y diseños. El siguiente, el último antes de la integración final, recorre uno por uno los servicios que todo sistema operativo ofrece, empezando por el que apareció en casi todos los temas sin que lo definiéramos del todo: el proceso.

14. Resumen

• Casi todos los sistemas actuales descienden de dos linajes: Unix y Windows NT.
• «Unix» designa el sistema original y sus derivados, una marca registrada con certificación, y un estilo de diseño. Linux solo es Unix en el tercer sentido, y es el sistema tipo Unix más usado.
• Los sistemas BSD son descendientes directos, y se desarrollan como un sistema completo, no como piezas separadas.
• Una distribución de Linux combina el kernel con un espacio de usuario. Se diferencian en el gestor de paquetes, el ritmo de publicación y las versiones; comparten el kernel, sus llamadas y la interfaz POSIX.
• /etc/os-release identifica la distribución y, con ID_LIKE, su familia.
• Windows NT es un diseño independiente: objetos y handles en lugar de archivos y descriptores, la API Win32 como interfaz estable y creación de procesos en un solo paso.
• macOS es un Unix certificado: el kernel XNU y un espacio de usuario de origen BSD, bajo un entorno gráfico propio.
• Lo que usa solo el estándar de C funciona en todas partes; lo que usa POSIX, en la familia Unix; /proc, strace y las llamadas por número son exclusivos de Linux.
• Entre sistemas cambian el formato de ejecutable, las bibliotecas, las rutas, el fin de línea, la codificación y hasta el tamaño de long.
• Un ejecutable solo funciona donde coinciden el sistema operativo y la arquitectura. El código fuente puede ser portable; el ejecutable, no.
• Las capas de compatibilidad se distinguen por la interfaz que reimplementan: la de programación, las llamadas al sistema, el hardware o el procesador.
• Bajo las diferencias, todos comparten los mismos fundamentos.

15. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Ejecuta familia.sh en tu sistema. Si tienes acceso a otra distribución —una máquina virtual o un contenedor—, ejecútalo allí y compara.
2. Amplía familia.sh para que informe también la biblioteca de C, con getconf GNU_LIBC_VERSION, y trate el caso en que ese comando falle.
3. Averigua a qué paquete pertenecen /bin/ls, /bin/bash y /usr/bin/gcc con el gestor de tu distribución, como hicimos en el tema 10.
4. Compila plataforma.c con la opción -m32, si tu sistema lo permite, y compara los tamaños. Después añade al programa sizeof(int) y sizeof(long long).
5. Crea un archivo de texto con dos líneas y examínalo con xxd. Conviértelo con unix2dos, o con sed 's/$/\r/', y vuelve a mirarlo. ¿Cuántos bytes ganó, y cuáles son?
6. Prueba la última observación de la sección 9: abre un archivo con less en una terminal, bórralo desde otra con rm y comprueba que less sigue mostrándolo. Busca el archivo en ls -l /proc/PID/fd.
7. Crea dos archivos llamados Datos.txt y datos.txt en un mismo directorio. ¿Lo permite tu sistema? ¿Qué pasaría al copiar ese directorio a una memoria USB con formato FAT?
8. Para cada elemento de esta lista, indica en cuál de los tres niveles de portabilidad de la sección 8 está: fork, qsort, /sys/firmware/efi, sysconf, fprintf, efibootmgr.
9. Elige un programa que uses a diario y que exista para varios sistemas. Averigua si se distribuye como código fuente, como un ejecutable distinto por sistema, o sobre una máquina virtual o un intérprete.