Definición

Un sistema operativo es un programa que administra los recursos de un sistema. Provee un conjunto de abstraciones que facilitan el acceso a estos recursos a las aplicaciones y, en lo posible, se independizan del hardware.
La abstración debe ser lo suficientemente general para independizarse del hardware, pero la implemención debe ser lo suficientemente particular para aprovechar de forma eficiente el hardware.
Algunos compromisos de diseño:
- Performance vs. Independencia de Hardware (nivel de abstracción)
- Simplicidad de uso vs. Flexibilidad
La definición y las tareas que un SO debe realizar cambian a través del tiempo, y según factores económicos.

 /=======================/
 |     Aplicaciones      |
 /=======================/
 |    Sistema Operativo  |
 /=======================/
 |       Hardware        /
 /=======================/

¿Por qué estudiar SO?

Los sistemas operativos son sistemas de software complejos. El entendimiento de los conceptos utilizados y la implementación de estos programas proporciona desafíos y ejemplos al estudiante.
El conocimiento de los sitemas operativos permite realizar aplicaciones que aprovechen los recursos eficientemente.
Diseño de sistemas operativos.

Historia de Sistemas Operativos

El desarrollo de los SO está marcado por los costos relativos entre el hardware y el trabajo de las personas. Al principio el hardware era extraodinariamente caro de comprar y mantener, y por lo tanto el acceso a este estaba reservado a grandes universidades y compañias.
'Primera computadora': 'ENIAC' 1946. Programada por interruptores. Salida mediante paneles de luces. 5000 operaciones por segundo (0.005 Mhz). 92 m2.

Etapa 1: Hardware muy caro.

Sistema monousuario e interactivo [<1955]

El operador interactuaba directamente con el hardware (interruptores para programación -> tarjetas perforadas)
El mayor desafio de programación muchas veces no es el objetivo en particular de los programas, sino las rutinas de manejo del hardware
- - Nacen entonces las librerías de manejo de hardware (drivers). Estas se leían al inicio del sistema y se dejaban en una porción de la memoria.
Para debuguear los programas, el operador debía estar en la consola.
Considerando que las computadoras eran tan caras, era necesario utilizarlas todo el tiempo, para maximizar la eficiencia.

Eventos

w:en:John_von_Neumann => Idea de programas guardados en memoria electrónica, en 1945.
En el mismo año es inventa el Transistor. w:en:Bell_labs.
Pilot ACE 1950. Mem: 352x4bytes= 1408 bytes, tiempo de suma: 1.8micro segundos -> 0.5MHz, 800 válculas.
Computadoras militares de hasta 150000 válvulas, 1MW de consumo.

w:en:Batch processing [1955-1965]

Procesar un programas después de otro, sin intervención del operador. Los resultados y errores se imprimian. La evaluación y correción del programa se hacían offline. => Mejor uso del hardware, pero mas difícil de corregir el software.
Un pequeño programa, llamado Monitor se cargaba en memoria al iniciar el sistema. Este programa era el encargado de interpretar la lista de procesos a ejecutar. Además, en esta porción de memoria de alojaban los device drivers.
Para evitar que algún programa corrompa el monitor, se agrega protección a la memoria de este. El hardware se adapta para correr en dos modos: modo monitor, con acceso a la totalidad de memoria, y modo usuario, dónde sólo se pude acceder a la memoria destinada a los programas.
Para evitar que un programa entre en un loop infinito e interrupta la ejecución del batch, se programa un interrupción de tiempo, que devuelve el control al monitor pasado cierto tiempo determinado.
El hardware es utilizado más eficientemente, sin embargo, cuando el sistema necesita acceder a dispositivos de E/S el sistema espera a los dispositivos, y el CPU no se utiliza. Entonces...
Se agregan buffers e interrupciones a las librerías de control de dispositivos. De esta forma el CPU puede seguir procesando información mientras los dispositivos realizan otras tareas. Resultados del proceso anterior pueden ser escritos mientras se ejecuta el próximo proceso.
La ejecución un progama puede depender de un dispositivo, y en este caso, deberá esperar el acceso a estos.

Herencias: Comando de UNIX at y cron; Colas de impresión.

Eventos

Bardeen, Brattain, Shockley. Premio nobel 1956. En 1955 comienza la producción en masa.
En el '56 se crea la TX0 [MIT] la primera computadora a transistores.
En el '60 nace el COBOL y el LISP, en el '64 el BASIC.
SSEC [IBM] 50 mul/seg. utilizada para predecir la orbita del vuelo Apolo a la luna en 1969.

Multiprograma [>1960-1980]

Capacidad de un sistema operativo de ejecutar varios procesos 'simultaneamente'. Cada programa corre hasta que accede a un dispositivo de E/S. Luego se ejecuta otro programa. Esto es posible a que los sistemas comenzaron a tener más memoria, y era posible cargar varios programas en memoria.
El SO debe: Decidir cual proceso correr entre los que se encuentran en la lista, proteger la memoria de cada programa.
Proceso: Un programa + su memoria
El SO se se vuelve una parte imporante de software, y su funcionamente cada vez más imporante en la performance de las aplicaciones.

Ejemplos

w:en:Multics [MIT, Bell, GE] , y w:en:OS/360 [IBM].
Hardware:
- IBM OS/360 -> 6 computadoras compatibles, con mas de 40 periféricos diferentes. Se vendieron hasta 1000 por mes. ~$120000u$s,
- CRAY CDC 6600 (~166MHz). 3 veces mas rápida que su rival más cercano.
- DEC PDP-8 -$18000, la primer minicomputadora.

Time Sharing Systems [>1980-Presente]

La idea de multiprograma (o multiproceso) se extiende a manejar varios procesos interectivo a la vez. Así, varias terminales se conectan una computadora (mainframe). Cada terminal es manejado por un proceso diferente y el sistema operativo cambia de procesos rápidamente.
La información comienza a guardarse en disco y se puede acceder 'random' -> Computadoras como repositorios de datos. Para mejorar la interacción se mayor prioridad a ciertos procesos.
En sistemas reales, se termina siempre con el procesador sobrecargado durante el día, y por ello se produce una generación de programadores que vive de noche...

Ejemplos

w:en:UNIX [Bell 1970, y luego AT&T y MIT]
w:en:VMS de [VAX/DEC].

Etapa 2: Computadoras baratas

Como son baratas, se pone una computadora (lenta y poca memoria, al menos originalmente) por terminal. Workstations, micro computers.
Idea se hacer un sistema simple, se descartan las ideas de protección, multiprograma, concurrencia, etc.
El foco luego se pone en la interacción con la usuario: entorno gráfico, mouse, etc.
El uso de la computador pasa a ser, en general, menos number crunching y más para guardar, tranferir y manipular información.
Networking pasa a ser un tema principal.
A medida que el hardware evoluciona, se mantiene el precio (barato) y se incorporan las ideas de los mainframes.

Ejemplos

Hardware: Intel 8080, 8088. IBM PC. Apple.
MS-DOS, Apple, Windows, NexT, FreeBSD, GNU/Linux.

Otros conceptos

Sistemas Operativos Real-time
Sistemas Operativos Embebidos
Computadores multiprocesadores: Memoria compatida o distribuida.

 * Simétricas (SMP) y Asimétricas.

Kernels Monolíticos y Microkernels.

Sistema Operativo Moderno

Provee abstración. Simplifica el acceso a los recursos de los complicados manejos de bajo nivel de hardware, facilitando el manejo de la computadora. Ejemplos: Procesos, Archivos, Mecanismos de sincronización y comunicación.
Provee una interface estandar. El sistema operativo puede correr en arquitecturas diferentes, y la aplicación puede ser portada sin mayor efuerzos.
Administra los recursos. Permite el acceso a los recursos a múltiples procesos de forma eficiente, segura, y justa.
- Procesos
- Memoria
- Archivos
- Redes
- Seguridad
- Interfases de usuarios
- Otros Dispositivos
Consume recursos. CPU, memoria, etc.
Los sistemas operativos son actualmente los sistemas de software más complicados. Nadie los comprende en su totalidad, sino que los desarrolladores trabajan sobre subsistemas.

Referencias

Algunas secciones de esta clase fueron adaptadas de los apuntes de clase del Prof. Martin Rinard (MIT). [Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard]
Algunas secciones de esta clase fueron adaptadas de los apuntes de clase de Prof. Andrew H. Fagg (UMASS)
Aviso de Apple vs. IBM