Importante

Este es un artículo que no es de mi autoría. Fue escrito por Mark Russinovich en 1998 y traducido por mi al español debido a su gran valor historico y cultural. El sitio donde fue escrito no existe más pero una versión original se puede visitar aquí obtenida gracias a web.archive.org

Tengan presente que esta opinión es una opinión de 1998.

NT vs. UNIX: ¿Hay uno sustancialmente mejor?

Por Mark Russinovich

OS pesados cara a cara por el dominio empresarial

A medida que la cuota de mercado de Windows NT en estaciones de trabajo y servidores ha ido erosionando el dominio de UNIX, la discusión sobre cuál sistema operativo (SO) es superior continúa encendida. Mucha gente argumenta, casi con fervor religioso, que el SO con el que trabajaron primero es el mejor. Especialmente algunos integrantes del bando UNIX parecen creer que, si argumentan lo suficientemente fuerte sobre los méritos de UNIX, lograrán frenar el avance de NT. En este contexto, es irónico que tanto NT como UNIX tengan sus raíces en los años setenta y que ambos estén influenciados por conceptos y principios teóricos de SO muy similares (para más sobre la historia de NT, ver “[Windows NT y VMS: El resto de la historia…]”). No debería sorprender a nadie descubrir que NT y UNIX tienen tantas similitudes como diferencias.

En este artículo, pongo lado a lado a NT y UNIX para comparar sus subsistemas arquitectónicos, y repaso las características principales de cada uno, tocando temas como gestión de procesos, planificación, administración de memoria y procesamiento de E/S. Presentaré resultados de benchmarks reconocidos por la industria. Finalmente, abordaré la pregunta que toda comparación genera: “¿Cuál SO es mejor?” Sea cual sea el bando en el que estés, seguro habrá algunas sorpresas.

Breve historia de UNIX

Ken Thompson desarrolló la primera versión del SO UNIX en 1969 en los Laboratorios Bell. Dennis Ritchie se unió pronto al proyecto, inventó el lenguaje C y también contribuyó al diseño de UNIX. Thompson y Ritchie reescribieron UNIX en C, convirtiéndolo desde el ensamblador del PDP-7. Este cambio fue clave para la aceptación posterior de UNIX, permitiendo que distintos equipos recompilaran y ejecutaran el código del SO fácilmente. Algunas estimaciones sostienen que sólo un 3% del código fuente inicial de UNIX dependía del hardware, por lo que era necesario reescribirlo al migrar a nuevas máquinas.

UNIX continuó su desarrollo en Bell Labs y debutó en la comunidad académica en 1974. La primera versión distribuida, UNIX Versión 6 (V6), apareció en 1976. Su uso se extendió rápidamente a universidades y centros de investigación, en parte gracias a su portabilidad. En 1978, Bell Labs lanzó la Séptima Edición, cuyo objetivo explícito era la portabilidad. En ese entonces, UNIX incluía muchas funciones que sólo los SO de mainframes tenían, pero con requerimientos de hardware relativamente bajos. Así, UNIX se volvió ideal para los minicomputadores.

Bell Labs distribuyó UNIX con el código fuente completo. Investigadores modificaron esta versión y desarrollaron variantes experimentales. Esta herencia es una bendición ambivalente para la comunidad UNIX, que aún hoy lidia con las consecuencias. A poco de la distribución del código fuente, surgieron tres o cuatro variantes principales.

A comienzos de los años ochenta, el “árbol” UNIX tuvo tres ramas importantes: UNIX System III de Bell Labs, BSD de la Universidad de California en Berkeley, y una versión para x86 llamada XENIX de Microsoft. ¿Sorprende saber que Microsoft tenía su propio UNIX? Más aún, XENIX llegó a ser la variante UNIX más instalada a principios de los 80. Microsoft vendió XENIX a SCO en 1995, cuando compró parte de SCO. En los 80, el mercado UNIX se fragmentó aún más, surgiendo múltiples variantes y fusiones entre ramas.

Esta fragmentación generó muchas interfaces de SO distintas, complicando la portabilidad de programas. Para combatir esto, un grupo de empresas, a través del IEEE, formuló el estándar POSIX, definiendo en 1988 la interfaz estándar de llamadas al sistema (API UNIX). Más tarde, otros organismos publicaron estándares similares, como la X/OPEN Portability Guide.

Aunque la mayoría de los UNIX actuales cumplen con POSIX o X/OPEN, cada proveedor trata de diferenciarse con interfaces y aplicaciones propias. Hoy existen varias decenas de versiones UNIX, siendo Solaris (Sun), HP/UX (HP) y AIX (IBM) las de mayor cuota comercial. Linux, creado por Linus Torvalds y desarrollado globalmente, es la cara visible del movimiento open source y se descarga libremente desde 1993. Paradójicamente, mientras antes se debatía si NT podría desafiar a UNIX, hoy la discusión es si Linux puede desafiar a NT. Los informes más recientes muestran a Linux como el único SO de servidores, además de NT, que gana cuota de mercado. Se calcula que hay entre 5 y 7 millones de instalaciones de Linux, mientras que NT reporta unas 11 millones, la mayoría en empresas, mientras que Linux todavía está muy presente entre aficionados. Esto podría cambiar con la llegada de Oracle8 y el respaldo de Netscape e Intel a Red Hat.

NT y UNIX

Las raíces de NT se remontan a 1977 con la aparición de VMS 1.0 de Digital Equipment. Varios integrantes clave del equipo de diseño de NT dejaron Digital en 1988 y se unieron a Microsoft, que lanzó Windows NT 3.1 en 1993. Tanto NT como UNIX han evolucionado desde los años setenta, influenciados por la investigación académica y con objetivos comunes: portabilidad, extensibilidad y capacidad de correr en PCs de escritorio y servidores.

Internamente, NT se parece a VMS, pero ¿cuán parecidas son sus capacidades a las de UNIX? Comparar no es sencillo, ya que incluso las tres versiones UNIX líderes (Solaris, HP/UX, AIX) son tan diferentes entre sí como respecto a NT. Por lo tanto, para comparar NT y UNIX tomaré como referencia las características tradicionales o prevalentes de UNIX y algunas variantes: Linux, BSD 4.4 y Digital UNIX.

La arquitectura de la mayoría de los UNIX modernos es similar a la de NT. Ambos tienen dos modos de operación: modo usuario y modo kernel. Las aplicaciones (procesadores de texto, bases de datos, etc.) corren en modo usuario (sin privilegios), y el código principal del SO en modo kernel (con privilegios y acceso total al hardware).

Una diferencia clave es que UNIX no incorpora su sistema de ventanas en modo kernel (como sí lo hace NT 4.0), sino que es una aplicación adicional en modo usuario, típicamente basada en X-Windows. NT, desde la versión 4.0, incorporó el sistema de ventanas en el kernel para mejorar el rendimiento gráfico.

Otra diferencia: en UNIX, las aplicaciones pueden llamar directamente a funciones del kernel (“system calls”). En NT, las aplicaciones llaman a APIs propias del entorno (DOS, Windows, POSIX, etc.), que se traducen al Native API del kernel, en gran parte no documentado. Ambas familias manejan unas 200-300 llamadas al sistema.

En la comparación siguiente, contrasto cómo cada SO nombra recursos internos, implementa procesos e hilos, y gestiona memoria virtual y física, además de seguridad, caching, red y extensibilidad.

Namespace y gestión de objetos

Un “namespace” de SO permite identificar y compartir recursos. El más visible es el del sistema de archivos: en UNIX tenemos rutas como /usr/mark/bin/csh, en NT C:\BIN\CSH.EXE. Otros recursos que requieren nombres son mutexes, semáforos, memoria compartida, etc.

En NT, el subsistema Object Manager implementa el namespace, proporcionando seguimiento, nombrado y seguridad uniforme para recursos. Procesos, archivos, semáforos, etc. son “objetos” del Object Manager. Permite, por ejemplo, que un driver cree objetos especiales (como \Proc para consultar procesos activos).

En UNIX, el mecanismo es menos formal. El namespace se centra en el sistema de archivos y usa “vnodes” o “inodes” (según la variante) como estructuras equivalentes a los objetos de NT. Tradicionalmente, el directorio /dev actúa como puerta de entrada a recursos especiales (por ejemplo, /dev/proc para información de procesos).

Ambos diseños son jerárquicos y usan mecanismos de notificación y conteo de referencias. El objetivo común es proveer infraestructura de seguimiento de recursos integrada al namespace.

Gestión de procesos

La gestión de procesos incluye cómo el SO define aplicaciones y cómo divide el uso de CPU entre ellas. NT y UNIX son SOs “time-sharing” que intentan repartir la CPU equitativamente. Ambos definen modos de ejecución más responsivos (“soft realtime”). La implementación impacta directamente en la escalabilidad para multiprocesadores.

En NT, una aplicación es un objeto proceso, conteniendo su espacio de memoria, recursos, estadísticas, usuario y uno o más hilos. El scheduler reparte tiempo entre hilos (no procesos). El scheduler define dos clases: dinámica y tiempo real, con prioridades del 1 al 31. Las prioridades pueden subir o bajar según eventos (teclado, etc.) para hilos dinámicos, pero son fijas en tiempo real.

NT soporta multiprocesamiento simétrico (SMP) y, aunque puede usar hasta 32 CPUs por limitación interna (usualmente hasta 8 por licencia), rara vez corre en sistemas con más de 8 CPUs. Un detalle clave: el kernel es totalmente preemptible, permitiendo que el scheduler interrumpa incluso código en modo kernel.

En UNIX moderno, la gestión de procesos es similar: estructura de proceso con espacio de direcciones, recursos y estadísticas, con soporte para hilos kernel. El scheduler suele tener tres clases de prioridad (tiempo real, sistema y dinámica), abarcando números del 0 al 100 (prioridad más alta = número más bajo). La longitud del “quantum” (turno) es similar a NT.

El soporte multiprocesador de UNIX es más avanzado: HP/UX, Solaris y AIX corren en SMPs grandes (32 CPUs o más) y algunos en multiprocesadores asimétricos. Los kernels suelen ser totalmente preemptibles y ejecutables en distintos CPUs a la vez.

En resumen, ambos definen aplicaciones como procesos con uno o más hilos kernel, y las diferencias principales están en las prioridades y detalles del scheduler. NT aumenta la prioridad de hilos dinámicos ante eventos; UNIX baja la prioridad de los hilos que consumen CPU sin soltarla. Ambos buscan ser justos con hilos orientados a CPU e I/O.

Administración de memoria

El gestor de memoria define espacios de direcciones virtuales y reparte la memoria física entre aplicaciones. Su implementación determina cuán bien el SO soporta múltiples aplicaciones simultáneas.

En NT, el Memory Manager define un espacio de direcciones virtuales de 32 bits (de 0 a 4GB): típicamente 2GB para modo usuario y 2GB para modo kernel (algunas versiones permiten 3GB usuario/1GB kernel). El kernel y drivers siempre están mapeados en el espacio kernel, y el espacio usuario cambia según el proceso activo.

NT implementa memoria virtual “demand-paged”: el SO trae código y datos a memoria física sólo cuando son requeridos. Permite memoria compartida, copy-on-write y archivos mapeados en memoria (memory-mapped files). El manejo físico asigna a cada proceso un “working set” (cantidad de memoria), y usa el algoritmo LRU (clock) para reemplazar datos antiguos. Puede “clusterizar” la lectura para optimizar el rendimiento.

En UNIX, el gestor de memoria es similar: espacio virtual dividido entre usuario y kernel, demanda paginada, memoria compartida, copy-on-write y archivos mapeados. Sin embargo, en UNIX la gestión es global (no por proceso): el SO puede reemplazar datos de cualquier aplicación, permitiendo que una aplicación intensiva en memoria cause “thrashing” (bajada de rendimiento). Para mitigar esto, suelen usar un proceso “swapper” que saca aplicaciones de memoria. Además, varios UNIX (Solaris, HP/UX, Digital UNIX) soportan espacios de 64 bits, mejorando el rendimiento en servidores de datos.

Ambos sistemas son similares, pero NT gestiona memoria por proceso y UNIX de forma global, y sólo UNIX recurre al swapping masivo para evitar el thrashing.

Seguridad

Un SO moderno debe proteger los datos sensibles de los usuarios. NT ha alcanzado la certificación C2 (como sistema autónomo no conectado), considerada el mínimo estándar actual. Su modelo de seguridad se basa en usuarios y grupos, con privilegios asignables (apagar el sistema, respaldar archivos, cargar drivers, etc.). El Object Manager centraliza la seguridad y la aplica a cualquier objeto.

NT define la seguridad de un objeto usando listas de control de acceso (ACL), compuestas por “entradas” (ACE) que especifican qué usuario o grupo puede realizar qué acciones. Además, puede auditar intentos de acceso exitosos y fallidos (requisito C2), y permite que aplicaciones servidoras mantengan su propia seguridad.

En UNIX tradicional, el modelo de seguridad es mucho menos robusto: hay usuarios y grupos, pero sólo el usuario “root” puede saltar cualquier restricción. La seguridad se limita a archivos, definidos por usuario y grupo propietarios, y permisos de lectura, escritura y ejecución.

La ausencia de ACLs y auditoría impide que UNIX tradicional alcance la certificación C2, por lo que muchos proveedores han desarrollado versiones propietarias que sí la cumplen, como Trusted Digital UNIX y Trusted Solaris.

En conclusión, el modelo de seguridad de NT es superior al UNIX tradicional, pero las implementaciones modernas de UNIX igualan a NT en robustez y clasificación (con la excepción de Linux, que no cumple varios requisitos C2).

Entrada/Salida (E/S)

La arquitectura de E/S define la escalabilidad y rendimiento del SO. En NT, el modelo se basa en “objetos archivo”: las aplicaciones hacen pedidos a estos objetos, y el I/O Manager pasa el pedido al driver correspondiente. Los drivers pueden apilarse (“layering”), permitiendo procesar pedidos a distintos niveles de abstracción.

NT describe los pedidos de E/S en “I/O request packets” (IRPs) y soporta E/S asíncrona, esencial para aplicaciones intensivas. La arquitectura de interrupciones divide el procesamiento en dos fases: una rutina rápida (ISR) y una fase posterior con la mayor parte del procesamiento.

En UNIX, la E/S se centra en los vnodes, y las peticiones se dirigen al driver asociado. Tradicionalmente, UNIX sólo soportaba E/S sincrónica, pero los UNIX modernos han extendido esto a la E/S asíncrona y al procesamiento en dos fases, igual que NT. La diferencia está en que el modelo de E/S de NT es más extensible y uniforme para distintos tipos de dispositivos.

Comparaciones varias

En sistemas de archivos, red y portabilidad, NT y UNIX tienen arquitecturas muy parecidas. Ambos implementan caches virtuales de archivos y soporte para “zero-copy” en el servicio de archivos. En drivers de red, ambos dividen el trabajo entre drivers de adaptadores, protocolos y una capa API.

La portabilidad real varía: NT soporta Alpha y x86, pero las principales versiones UNIX comerciales son menos portables, corriendo sólo en el CPU propietario del vendedor (a veces x86). Por ejemplo, Solaris se desarrolló para SPARC pero se portó a x86; AIX sólo corre en PowerPC.

¿Cuál SO es mejor?

Probablemente cada lector pueda proclamar cuál SO es mejor, pero la única medida objetiva son los benchmarks aceptados. Aquí los resultados de NT y UNIX en dos pruebas reconocidas: SpecWeb (de SPEC) y TPC-C (de TPC). Ambos organismos fueron fundados en los 80 para establecer benchmarks imparciales. Los resultados presentados son los mejores registrados hasta mediados de octubre de 1998.

• NT ostenta el récord SpecWeb en sistemas uniprocesador.
• UNIX lidera en sistemas de 2 y 4 procesadores, y ostenta el récord absoluto: 13.811 peticiones/segundo en un HP/UX de 16 vías.
• En TPC-C, NT lleva la delantera en sistemas de 2 y 4 procesadores, pero UNIX domina en 8 vías y ostenta el récord absoluto: 102.541 transacciones por minuto en un Digital UNIX de 96 vías (el mejor NT es de 16.257 en 8 vías). Sin embargo, el costo por transacción en NT es consistentemente la mitad que en UNIX.

En resumen, NT puede competir cara a cara con UNIX en servidores de alto nivel, escalando bien hasta cuatro procesadores. Más allá de eso, UNIX y sus soluciones de clustering están por delante. Pero NT es un “recién llegado” al terreno de multiprocesamiento y clustering, y Microsoft ya está enfocada en esto. No falta mucho para que UNIX sienta la presión.

Entonces… ¿Cuál es realmente mejor?

El hecho de que un SO implemente cierta característica o alcance un número en un benchmark no lo hace mejor o peor. Muchos factores entran en juego: disponibilidad de aplicaciones, costo inicial, soporte y mantenimiento, compatibilidad, facilidad de uso. Lo que es bueno para una persona o empresa puede no serlo para otra. Lo que sí está claro es que NT llegó para quedarse y se está convirtiendo en la opción de una nueva generación de profesionales IT.