Andrew s. Tanenbaum



Descargar 4,35 Mb.
Ver original pdf
Página4/134
Fecha de conversión12.11.2019
Tamaño4,35 Mb.
1   2   3   4   5   6   7   8   9   ...   134

7

El otro tipo de multiplexaje es en el espacio. En vez de que los clientes tomen turnos, cada uno

obtiene una parte del recurso. Por ejemplo, normalmente la memoria principal se divide entre va-

rios programas en ejecución para que cada uno pueda estar residente al mismo tiempo (por ejem-

plo, para poder tomar turnos al utilizar la CPU). Suponiendo que hay suficiente memoria como para

contener varios programas, es más eficiente contener varios programas en memoria a la vez, en vez

de proporcionar a un solo programa toda la memoria, en especial si sólo necesita una pequeña frac-

ción. Desde luego que esto genera problemas de equidad y protección, por ejemplo, y corresponde

al sistema operativo resolverlos. Otro recurso que se multiplexa en espacio es el disco duro. En mu-

chos sistemas, un solo disco puede contener archivos de muchos usuarios al mismo tiempo. Asig-

nar espacio en disco y llevar el registro de quién está utilizando cuáles bloques de disco es una tarea

típica de administración de recursos común del sistema operativo.



1.2 HISTORIA DE LOS SISTEMAS OPERATIVOS

Los sistemas operativos han ido evolucionando a través de los años. En las siguientes secciones

analizaremos brevemente algunos de los hitos más importantes. Como los sistemas operativos han

estado estrechamente relacionados a través de la historia con la arquitectura de las computadoras en

las que se ejecutan, analizaremos generaciones sucesivas de computadoras para ver cómo eran sus

sistemas operativos. Esta vinculación de generaciones de sistemas operativos con generaciones de

computadoras es un poco burda, pero proporciona cierta estructura donde de cualquier otra forma

no habría.

La progresión que se muestra a continuación es en gran parte cronológica, aunque el desarro-

llo ha sido un tanto accidentado. Cada fase surgió sin esperar a que la anterior terminara completa-

mente. Hubo muchos traslapes, sin mencionar muchos falsos inicios y callejones sin salida. El

lector debe tomar esto como guía, no como la última palabra.

La primera computadora digital verdadera fue diseñada por el matemático inglés Charles Bab-

bage (de 1792 a 1871). Aunque Babbage gastó la mayor parte de su vida y fortuna tratando de cons-

truir su “máquina analítica”, nunca logró hacer que funcionara de manera apropiada, debido a que

era puramente mecánica y la tecnología de su era no podía producir las ruedas, engranes y dientes

con la alta precisión que requería. Por supuesto, la máquina analítica no tenía un sistema operativo.

Como nota histórica interesante, Babbage se dio cuenta de que necesitaba software para su má-

quina analítica, por lo cual contrató a una joven llamada Ada Lovelace, hija del afamado poeta bri-

tánico Lord Byron, como la primera programadora del mundo. El lenguaje de programación Ada

®

lleva su nombre.



1.2.1 La primera generación (1945 a 1955): tubos al vacío

Después de los esfuerzos infructuosos de Babbage, no hubo muchos progresos en la construcción

de computadoras digitales sino hasta la Segunda Guerra Mundial, que estimuló una explosión de

esta actividad. El profesor John Atanasoff y su estudiante graduado Clifford Berry construyeron lo

que ahora se conoce como la primera computadora digital funcional en Iowa State University. Uti-

lizaba 300 tubos de vacío (bulbos). Aproximadamente al mismo tiempo, Konrad Zuse en Berlín



construyó la computadora Z3 a partir de relevadores. En 1944, la máquina Colossus fue construida

por un equipo de trabajo en Bletchley Park, Inglaterra; la Mark I, por Howard Aiken en Harvard, y

la ENIAC, por William Mauchley y su estudiante graduado J. Presper Eckert en la Universidad de

Pennsylvania. Algunas fueron binarias, otras utilizaron bulbos, algunas eran programables, pero to-

das eran muy primitivas y tardaban segundos en realizar incluso hasta el cálculo más simple.

En estos primeros días, un solo grupo de personas (generalmente ingenieros) diseñaban, cons-

truían, programaban, operaban y daban mantenimiento a cada máquina. Toda la programación se

realizaba exclusivamente en lenguaje máquina o, peor aún, creando circuitos eléctricos mediante

la conexión de miles de cables a tableros de conexiones (plugboards) para controlar las funciones

básicas de la máquina. Los lenguajes de programación eran desconocidos (incluso se desconocía

el lenguaje ensamblador). Los sistemas operativos también se desconocían. El modo usual de ope-

ración consistía en que el programador trabajaba un periodo dado, registrándose en una hoja de

firmas, y después entraba al cuarto de máquinas, insertaba su tablero de conexiones  en la compu-

tadora e invertía varias horas esperando que ninguno de los cerca de 20,000 bulbos se quemara du-

rante la ejecución. Prácticamente todos los problemas eran cálculos numéricos bastante simples,

como obtener tablas de senos, cosenos y logaritmos.

A principios de la década de 1950, la rutina había mejorado un poco con la introducción de las

tarjetas perforadas. Entonces fue posible escribir programas en tarjetas y leerlas en vez de usar ta-

bleros de conexiones; aparte de esto, el procedimiento era el mismo.

1.2.2 La segunda generación (1955 a 1965): transistores 

y sistemas de procesamiento por lotes

La introducción del transistor a mediados de la década de 1950 cambió radicalmente el panora-

ma. Las computadoras se volvieron lo bastante confiables como para poder fabricarlas y vender-

las a clientes dispuestos a pagar por ellas, con la expectativa de que seguirían funcionando el

tiempo suficiente como para poder llevar a cabo una cantidad útil de trabajo. Por primera vez ha-

bía una clara separación entre los diseñadores, constructores, operadores, programadores y el per-

sonal de mantenimiento.

Estas máquinas, ahora conocidas como mainframes, estaban encerradas en cuartos especiales

con aire acondicionado y grupos de operadores profesionales para manejarlas. Sólo las empresas

grandes, universidades o agencias gubernamentales importantes podían financiar el costo multimi-

llonario de operar estas máquinas. Para ejecutar un trabajo (es decir, un programa o conjunto de

programas), el programador primero escribía el programa en papel (en FORTRAN o en ensambla-

dor) y después lo pasaba a tarjetas perforadas. Luego llevaba el conjunto de tarjetas al cuarto de en-

trada de datos y lo entregaba a uno de los operadores; después se iba a tomar un café a esperar a

que los resultados estuvieran listos.

Cuando la computadora terminaba el trabajo que estaba ejecutando en un momento dado, un

operador iba a la impresora y arrancaba las hojas de resultados para llevarlas al cuarto de salida de

datos, para que el programador pudiera recogerlas posteriormente. Entonces, el operador tomaba

uno de los conjuntos de tarjetas que se habían traído del cuarto de entrada y las introducía en la má-

quina. Si se necesitaba el compilador FORTRAN, el operador tenía que obtenerlo de un gabinete



8

INTRODUCCIÓN

CAPÍTULO 1


SECCIÓN 1.2

HISTORIA DE LOS SISTEMAS OPERATIVOS



9

de archivos e introducirlo a la máquina. Se desperdiciaba mucho tiempo de la computadora mien-

tras los operadores caminaban de un lado a otro del cuarto de la máquina.

Dado el alto costo del equipo, no es sorprendente que las personas buscaran rápidamente formas

de reducir el tiempo desperdiciado. La solución que se adoptó en forma general fue el sistema de pro-

cesamiento por lotes. La idea detrás de este concepto era recolectar una bandeja llena de trabajos en

el cuarto de entrada de datos y luego pasarlos a una cinta magnética mediante el uso de una pequeña

computadora relativamente económica, tal como la IBM 1401, que era muy adecuada para leer las tar-

jetas, copiar cintas e imprimir los resultados, pero no tan buena para los cálculos numéricos. Para lle-

var a cabo los cálculos numéricos se utilizaron otras máquinas mucho más costosas, como la IBM

7094. Este procedimiento se ilustra en la figura 1-3.

1401

7094


1401

(a)


(b)

(c)


(d)

(e)


(f)

Lector de

tarjetas

Unidad


de cinta

Cinta de


entrada

Salida de

cinta

Cinta del



sistema

Impresora



Figura 1-3. Uno de los primeros sistemas de procesamiento por lotes. a) Los programa-

dores llevan las tarjetas a la 1401.  b) La 1401 lee los lotes de trabajos y los coloca en cin-

ta.  c) El operador lleva la cinta de entrada a la 7094.  d) La 7094 realiza los cálculos.  

e) El operador lleva la cinta de salida a la 1401.  f) La 1401 imprime los resultados.

Después de aproximadamente una hora de recolectar un lote de trabajos, las tarjetas se leían y

se colocaban en una cinta magnética, la cual se llevaba al cuarto de máquinas, en donde se monta-

ba en una unidad de cinta. Después, el operador cargaba un programa especial (el ancestro del sis-

tema operativo de hoy en día), el cual leía el primer trabajo de la cinta y lo ejecutaba. Los resultados

se escribían en una segunda cinta, en vez de imprimirlos. Después de que terminaba cada trabajo,

el sistema operativo leía de manera automática el siguiente trabajo de la cinta y empezaba a ejecu-

tarlo. Cuando se terminaba de ejecutar todo el lote, el operador quitaba las cintas de entrada y de

salida, reemplazaba la cinta de entrada con el siguiente lote y llevaba la cinta de salida a una 1401

para imprimir fuera de línea (es decir, sin conexión con la computadora principal). 

En la figura 1-4 se muestra la estructura típica de un trabajo de entrada ordinario. Empieza con

una tarjeta $JOB, especificando el tiempo máximo de ejecución en minutos, el número de cuenta al

que se va a cargar y el nombre del programador. Después se utiliza una tarjeta $FORTRAN, indi-

cando al sistema operativo que debe cargar el compilador FORTRAN de la cinta del sistema. Des-

pués le sigue inmediatamente el programa que se va a compilar y luego una tarjeta $LOAD, que

indica al sistema operativo que debe cargar el programa objeto que acaba de compilar (a menudo,

los programas compilados se escribían en cintas reutilizables y tenían que cargarse en forma explí-

cita). Después se utiliza la tarjeta $RUN, la cual indica al sistema operativo que debe ejecutar el


programa con los datos que le suceden. Por último, la tarjeta $END marca el final del trabajo. Es-

tas tarjetas de control primitivas fueron las precursoras de los shells e intérpretes de línea de coman-

dos modernos.

10

INTRODUCCIÓN

CAPÍTULO 1

$JOB, 10,6610802, MARVIN TANENBAUM

$FORTRAN

$LOAD


$RUN

$END


Programa en Fortran

Datos para el programa



Figura 1-4. Estructura de un trabajo típico de FMS.

Las computadoras grandes de segunda generación se utilizaron principalmente para cálculos

científicos y de ingeniería, tales como resolver ecuaciones diferenciales parciales que surgen a me-

nudo en física e ingeniería. En gran parte se programaron en FORTRAN y lenguaje ensamblador.

Los sistemas operativos típicos eran FMS (Fortran Monitor System) e IBSYS, el sistema operativo

de IBM para la 7094.



1.2.3 La tercera generación (1965 a 1980): circuitos integrados 

y multiprogramación

A principio de la década de 1960, la mayoría de los fabricantes de computadoras tenían dos líneas

de productos distintas e incompatibles. Por una parte estaban las computadoras científicas a gran

escala orientadas a palabras, como la 7094, que se utilizaban para cálculos numéricos en ciencia e

ingeniería. Por otro lado, estaban las computadoras comerciales orientadas a caracteres, como la

1401, que se utilizaban ampliamente para ordenar cintas e imprimir datos en los bancos y las com-

pañías de seguros.

Desarrollar y dar mantenimiento a dos líneas de productos completamente distintos era una

propuesta costosa para los fabricantes. Además, muchos nuevos clientes de computadoras necesita-

ban al principio un equipo pequeño, pero más adelante ya no era suficiente y deseaban una máqui-

na más grande que pudiera ejecutar todos sus programas anteriores, pero con mayor rapidez.


SECCIÓN 1.2

HISTORIA DE LOS SISTEMAS OPERATIVOS



11

IBM intentó resolver ambos problemas de un solo golpe con la introducción de la línea de compu-

tadoras System/360. La 360 era una serie de máquinas compatibles con el software, que variaban

desde un tamaño similar a la 1401 hasta algunas que eran más potentes que la 7094. Las máquinas

sólo diferían en el precio y rendimiento (máxima memoria, velocidad del procesador, número de

dispositivos de E/S permitidos, etcétera). Como todas las máquinas tenían la misma arquitectura y

el mismo conjunto de instrucciones, los programas escritos para una máquina podían ejecutarse en

todas las demás, por lo menos en teoría. Lo que es más, la 360 se diseñó para manejar tanto la compu-

tación científica (es decir, numérica) como comercial. Por ende, una sola familia de máquinas po-

día satisfacer las necesidades de todos los clientes. En los años siguientes, mediante el uso de

tecnología más moderna, IBM ha desarrollado sucesores compatibles con la línea 360, a los cuales

se les conoce como modelos 370, 4300, 3080 y 3090. La serie zSeries es el descendiente más re-

ciente de esta línea, aunque diverge considerablemente del original.

La IBM 360 fue la primera línea importante de computadoras en utilizar circuitos integrados

(ICs) (a pequeña escala), con lo cual se pudo ofrecer una mayor ventaja de precio/rendimiento en

comparación con las máquinas de segunda generación, las cuales fueron construidas a partir de tran-

sistores individuales. Su éxito fue inmediato y la idea de una familia de computadoras compatibles

pronto fue adoptada por todos los demás fabricantes importantes. Los descendientes de estas máqui-

nas se siguen utilizando hoy día en centros de cómputo. En la actualidad se utilizan con frecuencia

para manejar bases de datos enormes (por ejemplo, para sistemas de reservaciones de aerolíneas) 

o como servidores para sitios de World Wide Web que deben procesar miles de solicitudes por se-

gundo.


La mayor fortaleza de la idea de “una sola familia” fue al mismo tiempo su mayor debilidad.

La intención era que todo el software, incluyendo al sistema operativo OS/360, funcionara en to-

dos los modelos. Debía ejecutarse en los sistemas pequeños, que por lo general sólo reemplazaban

a la 1401s, que copiaba tarjetas a cinta, y en los sistemas muy grandes, que a menudo reemplazaban a

la 7094s, que realizaba predicciones del clima y otros cálculos pesados. Tenía que ser bueno en sis-

temas con pocos dispositivos periféricos y en sistemas con muchos. Tenía que funcionar en ambos

entornos comerciales y científicos. Por encima de todo, tenía que ser eficiente para todos estos usos

distintos.

No había forma en que IBM (o cualquier otra) pudiera escribir una pieza de software que cum-

pliera con todos estos requerimientos en conflicto. El resultado fue un enorme y extraordinariamen-

te complejo sistema operativo, tal vez de dos a tres órdenes de magnitud más grande que el FMS.

Consistía en millones de líneas de lenguaje ensamblador escrito por miles de programadores, con

miles de errores, los cuales requerían un flujo continuo de nuevas versiones en un intento por co-

rregirlos. Cada nueva versión corregía algunos errores e introducía otros, por lo que probablemen-

te el número de errores permanecía constante en el tiempo.

Fred Brooks, uno de los diseñadores del OS/360, escribió posteriormente un libro ingenioso e

incisivo (Brooks, 1996) que describía sus experiencias con el OS/360. Aunque sería imposible re-

sumir este libro aquí, basta con decir que la portada muestra una manada de bestias prehistóricas

atrapadas en un pozo de brea. La portada de Silberschatz y coautores (2005) muestra un punto de

vista similar acerca de que los sistemas operativos son como dinosaurios. 

A pesar de su enorme tamaño y sus problemas, el OS/360 y los sistemas operativos similares

de tercera generación producidos por otros fabricantes de computadoras en realidad dejaban razo-



nablemente satisfechos a la mayoría de sus clientes. También popularizaron varias técnicas clave

ausentes en los sistemas operativos de segunda generación. Quizá la más importante de éstas fue la



multiprogramación. En la 7094, cuando el trabajo actual se detenía para esperar a que se comple-

tara una operación con cinta u otro dispositivo de E/S, la CPU simplemente permanecía inactiva

hasta terminar la operación de E/S. Con los cálculos científicos que requieren un uso intensivo de

la CPU, la E/S no es frecuente, por lo que este tiempo desperdiciado no es considerable. Con el pro-

cesamiento de datos comerciales, el tiempo de espera de las operaciones de E/S puede ser a menu-

do de 80 a 90 por ciento del tiempo total, por lo que debía hacerse algo para evitar que la (costosa)

CPU esté inactiva por mucho tiempo.

La solución que surgió fue particionar la memoria en varias piezas, con un trabajo distinto en

cada partición, como se muestra en la figura 1-5. Mientras que un trabajo esperaba a que se com-

pletara una operación de E/S, otro podía estar usando la CPU. Si pudieran contenerse suficientes

trabajos en memoria principal al mismo tiempo, la CPU podía estar ocupada casi 100 por ciento del

tiempo. Para tener varios trabajos de forma segura en memoria a la vez, se requiere hardware espe-

cial para proteger cada trabajo y evitar que los otros se entrometan y lo malogren; el 360 y los de-

más sistemas de tercera generación estaban equipados con este hardware.



12

INTRODUCCIÓN

CAPÍTULO 1

Trabajo 3

Trabajo 2

Trabajo 1

Sistema

operativo



Particiones

de memoria



Figura 1-5. Un sistema de multiprogramación con tres trabajos en memoria.

Otra característica importante de los sistemas operativos de tercera generación fue la capacidad

para leer trabajos en tarjetas y colocarlos en el disco tan pronto como se llevaban al cuarto de compu-

tadoras. Así, cada vez que terminaba un trabajo en ejecución, el sistema operativo podía cargar un nue-

vo trabajo del disco en la partición que entonces estaba vacía y lo ejecutaba. A esta técnica se le conoce

como spooling (de Simultaneous Peripheral Operation On Line, operación periférica simultánea en

línea) y también se utilizó para las operaciones de salida. Con el spooling, las máquinas 1401 no eran

ya necesarias y desapareció la mayor parte del trabajo de transportar las cintas.

Aunque los sistemas operativos de tercera generación eran apropiados para los cálculos cientí-

ficos extensos y las ejecuciones de procesamiento de datos comerciales masivos, seguían siendo en

esencia sistemas de procesamiento por lotes. Muchos programadores añoraban los días de la prime-

ra generación en los que tenían toda la máquina para ellos durante unas cuantas horas, por lo que po-

dían depurar sus programas con rapidez. Con los sistemas de tercera generación, el tiempo que

transcurría entre enviar un trabajo y recibir de vuelta la salida era comúnmente de varias horas, por

lo que una sola coma mal colocada podía ocasionar que fallara la compilación, y el programador des-

perdiciara la mitad del día.

Este deseo de obtener un tiempo rápido de respuesta allanó el camino para el tiempo compar-

tido (timesharing), una variante de la multiprogramación donde cada usuario tenía una terminal en


SECCIÓN 1.2

HISTORIA DE LOS SISTEMAS OPERATIVOS



13

línea. En un sistema de tiempo compartido, si 20 usuarios están conectados y 17 de ellos están pen-

sando en dar un paseo o tomar café, la CPU se puede asignar por turno a los tres trabajos que de-

sean ser atendidos. Como las personas que depuran programas generalmente envían comandos

cortos (por ejemplo, compilar un procedimiento de cinco hojas

) en vez de largos (por ejemplo, or-



denar un archivo con un millón de registros), la computadora puede proporcionar un servicio rápi-

do e interactivo a varios usuarios y, tal vez, también ocuparse en trabajos grandes por lotes en

segundo plano, cuando la CPU estaría inactiva de otra manera. El primer sistema de tiempo com-

partido de propósito general, conocido como CTSS  (Compatible Time Sharing System, Sistema

compatible de tiempo compartido), se desarrolló en el M.I.T. en una 7094 modificada en forma 

especial (Corbató y colaboradores, 1962). Sin embargo, en realidad el tiempo compartido no se po-

pularizó sino hasta que el hardware de protección necesario se empezó a utilizar ampliamente du-

rante la tercera generación.

Después del éxito del sistema CTSS, el M.I.T., Bell Labs y General Electric (que en ese enton-

ces era un importante fabricante de computadoras) decidieron emprender el desarrollo de una “uti-

lería para computadora”, una máquina capaz de servir a varios cientos de usuarios simultáneos de

tiempo compartido. Su modelo fue el sistema de electricidad: cuando se necesita energía, sólo hay

que conectar un contacto a la pared y, dentro de lo razonable, toda la energía que se requiera esta-

rá ahí. Los diseñadores del sistema conocido como MULTICS  (MULTiplexed Information and



Computing Service; Servicio de Información y Cómputo MULTiplexado), imaginaron una enor-

me máquina que proporcionaba poder de cómputo a todos los usuarios en el área de Boston. La idea

de que, sólo 40 años después, se vendieran por millones máquinas 10,000 veces más rápidas que su

mainframe GE-645 (a un precio muy por debajo de los 1000 dólares) era pura ciencia ficción. Al-

go así como la idea de que en estos días existiera un transatlántico supersónico por debajo del agua.

MULTICS fue un éxito parcial. Se diseñó para dar soporte a cientos de usuarios en una máqui-

na que era sólo un poco más potente que una PC basada en el Intel 386, aunque tenía mucho más

capacidad de E/S. Esto no es tan disparatado como parece, ya que las personas sabían cómo escri-

bir programas pequeños y eficientes en esos días, una habilidad que se ha perdido con el tiempo.

Hubo muchas razones por las que MULTICS no acaparó la atención mundial; una de ellas fue el

que estaba escrito en PL/I y el compilador de PL/I se demoró por años, además de que apenas fun-

cionaba cuando por fin llegó. Aparte de eso, MULTICS era un sistema demasiado ambicioso para

su época, algo muy parecido a la máquina analítica de Charles Babbage en el siglo diecinueve.

Para resumir esta larga historia, MULTICS introdujo muchas ideas seminales en la literatura de

las computadoras, pero convertirlas en un producto serio y con éxito comercial importante era algo

mucho más difícil de lo que cualquiera hubiera esperado. Bell Labs se retiró del proyecto y Gene-

ral Electric dejó el negocio de las computadoras por completo. Sin embargo, el M.I.T. persistió y

logró hacer en un momento dado que MULTICS funcionara. Al final, la compañía que compró el

negocio de computadoras de GE (Honeywell) lo vendió como un producto comercial y fue instala-

do por cerca de 80 compañías y universidades importantes a nivel mundial. Aunque en número pe-

queño, los usuarios de MULTICS eran muy leales. Por ejemplo, General Motors, Ford y la Agencia

de Seguridad Nacional de los Estados Unidos desconectaron sus sistemas MULTICS sólo hasta 

En este libro utilizaremos los términos “procedimiento”, “subrutina” y “función” de manera indistinta.



finales de la década de 1990, 30 años después de su presentación en el mercado y de tratar durante

años de hacer que Honeywell actualizara el hardware.

Por ahora, el concepto de una “utilería para computadora” se ha disipado, pero tal vez regrese

en forma de servidores masivos de Internet centralizados a los que se conecten máquinas de usua-

rio relativamente “tontas”, donde la mayoría del trabajo se realice en los servidores grandes. Es pro-

bable que la motivación en este caso sea que la mayoría de las personas no desean administrar un

sistema de cómputo cada vez más complejo y melindroso, y prefieren delegar esa tarea a un equi-

po de profesionales que trabajen para la compañía que opera el servidor. El comercio electrónico ya

está evolucionando en esta dirección, en donde varias compañías operan centros comerciales elec-

trónicos en servidores multiprocesador a los que se conectan las máquinas cliente simples, algo muy

parecido al diseño de MULTICS.

A pesar de la carencia de éxito comercial, MULTICS tuvo una enorme influencia en los siste-

mas operativos subsecuentes. Se describe en varios artículos y en un libro (Corbató y colaboradores,

1972; Corbató y Vyssotsky, 1965; Daley y Dennis, 1968; Organick, 1972; y Staltzer, 1974). También

tuvo (y aún tiene) un sitio Web activo, ubicado en www.multicians.org, con mucha información acer-

ca del sistema, sus diseñadores y sus usuarios.

Otro desarrollo importante durante la tercera generación fue el increíble crecimiento de las mi-

nicomputadoras, empezando con la DEC PDP-1 en 1961. La PDP-1 tenía sólo 4K de palabras de

18 bits, pero a $120,000 por máquina (menos de 5 por ciento del precio de una 7094) se vendió co-

mo pan caliente. Para cierta clase de trabajo no numérico, era casi tan rápida como la 7094 y dio

origen a una nueva industria. A esta minicomputadora le siguió rápidamente una serie de otras PDP

(a diferencia de la familia de IBM, todas eran incompatibles), culminando con la PDP-11.

Posteriormente, Ken Thompson, uno de los científicos de cómputo en Bell Labs que trabajó en

el proyecto MULTICS, encontró una pequeña minicomputadora PDP-7 que nadie estaba usando y

se dispuso a escribir una versión simple de MULTICS para un solo usuario. Más adelante, este tra-

bajo se convirtió en el sistema operativo UNIX

®

, que se hizo popular en el mundo académico, las



agencias gubernamentales y muchas compañías.

La historia de UNIX ya ha sido contada en muchos otros libros (por ejemplo, Salus, 1994). En

el capítulo 10 hablaremos sobre parte de esa historia. Por ahora baste con decir que, debido a que el

código fuente estaba disponible ampliamente, varias organizaciones desarrollaron sus propias 

versiones (incompatibles entre sí), lo cual produjo un caos. Se desarrollaron dos versiones princi-

pales:  System V de AT&T y BSD  (Berkeley Software Distribution, Distribución de Software de

Berkeley) de la Universidad de California en Berkeley. Estas versiones tenían también variantes

menores. Para que fuera posible escribir programas que pudieran ejecutarse en cualquier sistema

UNIX, el IEEE desarrolló un estándar para UNIX conocido como POSIX, con el que la mayoría

de las versiones de UNIX actuales cumplen. POSIX define una interfaz mínima de llamadas al sis-

tema a la que los sistemas UNIX deben conformarse. De hecho, algunos de los otros sistemas ope-

rativos también admiten ahora la interfaz POSIX.

Como agregado, vale la pena mencionar que en 1987 el autor liberó un pequeño clon de UNIX

conocido como MINIX, con fines educativos. En cuanto a su funcionalidad, MINIX es muy simi-

lar a UNIX, incluyendo el soporte para POSIX. Desde esa época, la versión original ha evolucio-

nado en MINIX 3, que es altamente modular y está enfocada a presentar una muy alta confiabilidad.

Tiene la habilidad de detectar y reemplazar módulos con fallas o incluso inutilizables (como los dis-



Compartir con tus amigos:
1   2   3   4   5   6   7   8   9   ...   134


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal