Sistemas operativos modernos

tiera en un estándar defacto en el mundo UNIX y después en Internet, donde dominan los ser­ vidores basados en UNIX. Berkeley también añadió numerosos programas utilitarios a UNIX que incluyeron un nue­ vo editor (vi), un nuevo shell (csh), compiladores de Pascal y Lisp, y muchos más. Todas estas mejoras hicieron que Sun Microsystems, DEC y otros fabricantes de computadoras basaran sus versiones de UNIX en Berkeley UNIX, no en la versión “oficial” de AT&T, System V. Como consecuencia de esto, Berkeley UNIX se estableció con firmeza en los ámbitos académico, de investigación y de la defensa. Si el lector desea más información acerca de Berkeley UNIX, puede consultar McKusick et al. (1996). 10.1.5 UNIX estándar A fines de la década de 1980 se usaban en forma amplia dos versiones distintas y hasta cierto punto incompatibles de UNIX: 4.3BSD y System V Release 3. Además, casi cada fabricante añadía sus propias mejoras no estándares. Esta división en el mundo UNIX, junto con el he­ cho de que no había estándares para los formatos de programas binarios, inhibió de manera considerable el éxito comercial de UNIX porque era imposible para los productores de soft­ ware escribir programas en UNIX e incluirlos en paquetes con la expectativa de que se ejecu­ taran en cualquier sistema UNIX (como se hacía todos los días con MS-DOS). En un principio fracasaron varios intentos por estandarizar UNIX. Por ejemplo, AT&T publicó la Definición de Interfaz de System V (SVID; System V Interface Definition), que definía todas las llama­ das al sistema, formatos de archivos y demás. Este documento fue un intento por controlar a todos los fabricantes de System V, pero no surtió efecto sobre el campo enemigo (BSD), que simplemente lo ignoró. El primer intento serio por conciliar los dos “sabores” de UNIX se inició bajo los auspi­ cios de la IEEE Standards Board, un organismo muy respetado y, lo que era más importante, neutral. Cientos de personas de la industria, las universidades y el gobierno participaron en estos trabajos. El nombre colectivo de este proyecto fue POSIX. Las tres primeras letras se re­ fieren a “Sistema Operativo Portátil” {Portable Operating System)\ lo de IX se agregó para que el nombre sonara parecido a UNIX. Después de muchos argumentos y contraargumentos, refutaciones y contrarrefutaciones, el comité POSIX produjo un estándar conocido como 1003.1 que define un conjunto de procedi­ mientos de biblioteca que debe proporcionar todo sistema UNIX que cumpla con la norma. Ca­ si todos estos procedimientos invocan una llamada al sistema, pero unos cuantos pueden implementarse fuera del kemel. Ejemplos típicos de procedimientos son open, read y fork. La idea en que se basa POSIX es que si un productor de software escribe un programa que sólo usa los procedimientos definidos por 1003.1, sabe que su programa se ejecutará en todos los sistemas UNIX que cumplen con la norma. Si bien es verdad que la mayoría de los organismos de estándares tiende a producir una ho­ rrible mezcla con unas cuantas de las funciones favoritas de cada quien, 1003.1 es extraordina­ riamente bueno, considerando el gran número de partes que intervinieron y sus respectivos intereses creados. En lugar de partir de la unión de todas las funciones de System V y BSD (co-