💾 Archived View for texto-plano.xyz › peron › articulos › pwb.gmi captured on 2023-01-29 at 03:45:54. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Los llamados "Unix de Investigación" constituyeron una serie progresiva de versiones (mas bien "ediciones") de Unix, que fueron moldeando este sistema multiusuario en los Laboratorios Bell. Estos tenÃan precisamente el sentido de operar como plataforma de "incubadora de desarrollo" para el mismo sistema a lo largo de toda la década de 1970.
Sin embargo, como spin off de la Sexta Edición de Unix, en los laboratorios Bell se utilizó el PROGRAMMMER'S WORKBENCH, un Unix especÃficamente concebido para dar servicio a más de mil usuarios. Este fue propuesto por L. Irvin en 1973, y para 1975 muchos de los departamentos de los Laboratorios contaban con este magnÃfico ejemplo de computo a tiempo compartido, loable especialmente en lo que hacÃa a la compilación cruzada.
Mas adelante, cuando salió en 1979 la bastante extendida UNIX Séptima Edición (facilitado por el buen feedback que tuvo el Unix v6), PWB/Unix contó consecuentemente una versión 2.0, comercializada ya por AT&T a partir de 1980.
En Octubre de 1977 uno de los principales "Magos UNIX"; Douglas "Doug" McIlroy expone en el Journal interno para los laboratorios algunos detalles muy exclarecedores del PROGRAMMER'S WORKBENCH PWB/UNIX 1.0 que por entonces ya merecÃa ser historiado internamente. Especialmente interesante es el tamaño y potencia computacional de este CLUSTER UNIX.
El sistema "Programmer's Workbench UNIX" (PWB/UNIX) es una facilidad de cómputo especializada dedicada a dar soporte a grandes proyectos de desarrollos de software. Es un sistema de producción que ha sido utilizado por varios años en el área de Programas de Sistemas de Información de Negocioos (BISP) de los Laboratorios Bell, y da soporte allà a una comunidad de unas 1.100 pesonas. Fue desarrollado principalmente como un intento de mejorar la calidad, confiabilidad, flexibilidad y consistencia del ambiente de programación. Los conceptos detrás del PWB hacen énfasis en varias ideas:
El desarrollo de programa y la ejecución del mismo son dos funciones radicalmente distintas. Pueden obtenerse ventajas de asignar cada función a una computadora mejor provista para cada una de ellas. Por demás, como puede hacerse mucho del desarrollo en una computadora dedicada a la tarea (ej, una que opera como facilidad de desarrollo y provee un ambiente de programación superior). La ejecución del producto desarrollado a menudo sucede en otra computadora, llamada sistema objeto. Para algunos proyectos, un solo sistema puede abarcar ambos roles, pero esto suele ser raro, debido a que los sistemas operativos actuales están diseñados para "correr" programas, pero dan escasa capacidad al proceso del desarrollo del programa en sÃ.
Los sistemas objeto actual para PWB/UNIX incluyen al IBM System/370 y al Univac 1100.
La instalación de PWB/UNIX en el BISP consiste actualmente [oct 1977] de una red de computadoras DEC PDP-11/45 y /70 que corren una versión modificada del sistema Unix. Por lo que sabemos es la instalación más grande de Unix conocida en el mundo.
El sistema está conectado entre sà de modo que cada máquina pueda respaldar a la otra, y que sus ficheros puedan transmitirse eficientemente entre sÃ..
PDP-11 K de RAM MB Disco Puertos Telefónicos Usuari@s
A /45 256 160 15 153
B /70 768 480 48 260
D /70 512 320 48 361
E /45 256 160 20 114
F /70 768 320 48 262
G /70 512 160 48 133
H /70 512 320 48 139
Totales 3.328K 1.920MB 275 1.422
El tiempo total de conexión por dÃa es de 1.342 horas/máquina.
La instalación ofrece un servicio de cómputo a tiempo compartido relativamente barato a un gran número de usuarios. El usuario promedio de PWB/Unix consume 25 horas de tiempo de conexión al mes, y usa 0,5MB de almacenamiento de disco. Se hace gran uso de los recursos disponibles: tÃpicamente se ocupa el 90% del espacio en disco, y entre 75 y 80% del tiempo de conexión disponible. Durante los perÃodos de gran carga de trabajo computacional, el uso de CPU excede el 95%.
El PWB/UNIX ha sido adoptado fuera del BISP, principalmente para labores de centro de cómputo, desarrollo de programas, y servicios de procesamiento de texto. Además de la instalación original de PWB/Unix, existen aproximadamente otras diez instalaciones dentro de los Laboratorios Bell y seis instalaciones en otras partes del Sistema Bell. Algunas de estas instalaciones emplean más de una CPU; dentro del Sistema Bell, existen más de treinta PDP-11 que corren PWB/UNIX, y se trazan planes para instalar más en un futuro cercano.
El concepto que mueve al sistema PWB/Unix fue sugerido a mediados de 1973 y la primera de las PDP11/45 se instaló a finales de ese año. Esta máquina se utilizó en principio para nuestra propia educación y experimentación, mientras que se daba construcción a las primeras versiones de nuestras instalaciones. Al comienzo, el proyecto era experimental y enfrentó considerable indiferencia de la comunidad de usuarios orientada ampliamente a los grandes sistemas de cómputo, y que trabajabaja en dificultosos horarios laborles, un poco enfrentada a lo que por entonces parecÃa una idea radical. Sin embargo, en la medida que se corrÃa la voz del sistema, creció su demanda de servicio rapidamente, casi en todos los casos sobrepasando la existencia. Los usuarios consistentemente subestimaban sus propios requerimientos de servicio, ya que descubrÃan aplicaciones inesperadas para las instalaciones PWB/UNIX. En cuatro años, la instalación PWB original habÃa crecido desde una PDP-11 original que daba servicio a 16 usuarios a una red de trabajo de siete PDP-11 que servÃan a 1.100.
Los requerimientos de los DESARROLLADORES de software divergen a menudo muy marcadamente de aquellos que son los USUARIOS de dicho software. Esto se vio en el BISP y similares (ej, organizaciones que desarrollan sistemas grandes orientados a bases de datos). Las necesidades principales de los desarrolladores incluyen:
Para comienzosd de 1974 se dio mucho pensamiento al diseño general que debÃa tener el sistema PWB/UNIX. Una propuesta consistió en diseñar primero una instalación completamente integrada, luego implementarla, y finalmente obtener usuarios para ella.
Sin embargo, se siguió una ruta menos tradicional, cuyos elementos adotpados fueron:
En la práctica esta visión aparentemente caótica funcionó mejor que diseñar un sistema pretendidadmente perfecto que resulte obsoleto o inútil para el momento en que resulta implementado. A diferencia de otros sistemas, el UNIX permite y fomenta esta visión.
El uso y operación de PWB/UNIX difiere en cierta manera del de Unix.
La mayorÃa de las implementaciones de UNIX son "amistosas" y se usan por una comunidad de usuarios relativamente pequeñas que trabajan cerca. Estos en gran medida suelen contar con permisos de lectoescritura para la mayorÃa (si no todos) de los ficheros del sistema, tienen permisos para agregar comandos en los directorrios públicos, y son capaces de reiniciar el sistema operativo, e incluso conocen cómo reparar ficheros de sistema dañados.
El sistema PWB/Unix, por otro lado, suele encontrarse en un ambiente de centro de cómputo. Grandes números de usuarios hace empleo de él y a menudo representan organizaciones diferentes. Es indeseable que todo9s tengan permisos de lectoescritura general. Aunque los grupos de usuarios pueden DESEAR tener un conjunto de comandos y ficheros para usar y compartir, demasiados deben ser servidos para permitir que cada uno agrega comandos a directorios públicos. Pocos de los usuarios escriben programas en C, e incluso menos se ven interesados en conocer minucias del sistema de archivo. Las máquinas son manejadas por operadores que no son expertos programadores de sistemas. Muchos de los usuarios tienen que dar cuenta de grandes cantidades de código fuente existente, por lo que suelen tener que integrar al sistema PWB/UNIX en su método de trabajo y procedimientos existentes.
El sistema UNIX en general ha sido muy confiable. Sin embargo, aparecieron algunos problemas simplemente porque PWB/UNIX da soporte a una carga compartida más densa que la mayorÃa de las instalaciones UNIX convencionales. Estos operan casi al lÃmite de su recursos la mayorÃa del tiempo. La mayorÃa de las veces los problemas hicieron al tardÃo aviso preventivo de la falta de recursos (por lo que se hicieron gran cantidad de cambios menores para prevenirlo).
La primer mejora mayor se vio en el manejo de los ficheros en disco, previniendo en caso del agotamiento de los medios de almacenamiento. Se consideró la información mecanografiada más importante que la mecánicamente generada, por lo que esta recibe prioridad en el sistema de almacenamiento.
El principal uso de PWB/UNIX se traslada en almacenar y organizar ficheros de texto en lugar de hacer cómputo. Por lo tanto, cada mañana de dÃa laboral, cada fichero de usuario resulta copiado al disco de respaldo, y se almacena por una semana. La copia en cinta semanal se almacena por dos meses, y las copias bimestrales se mantienen "por siempre" (aún conservamos cintas de enero de 1974). Estas copias de respaldo de disco nos permiten una recuperación rápida ante falla de disco duro u otros desastres (raros) y también una recuperación muy rápida cuando los usuarios pierden ficheros.
Se hicieron una cantidad de extensiones al Intérprete de comandos para mejorar su capacidad y dar soporte a la programación interpretada, mientras que se dejaba su interfaz tan fiel como fuese posible. Estos cambios se hicieron sólo lluego de grandes trepidaciones, ya que violaban claramente el principio del sistema UNIX de minimizar la complejidad de los programas "centrales", y porque representaban una desviación del intérprete de comandos del Unix de Investigación.
Durante 1974 y a comienzos de 1975, el Shell de PWB/UNIX fue la misma que el de Unix de Investigación [NdT: el Shell sh de Ken Thompson], y su patrón de uso era similar: intepretar comandos tipeados en un terminal y ocasionalmente utilizarlo para intepretar ficheros simples de comandos embutidos.
Las habilidades de programación se limitaban a un manejo simple de secuencias de argumentos, y el control de flijo se dirigÃa con if, goto y exit, comandos spearados que le daban a los procedimientos de shell una apariencia similar a Fortran. Durante este perÃodo, comenzamos a experimentar con el uso del Shell. Notamos que cualquier cosa que quisiéramos escribir de forma procidemantal, debÃa ser siempre escrita en C, pero lo inverso no siempre podÃa darse. Aunque los programas de C casi siempre se ejecutaban mucho más rçapidos, los usarios preferÃa escribirlos haciendo uso de procedimientos de shell, si era posible, por un número de razones:
1. La programación de shell era fácil de aprender, ya que todos sabÃan algo del shell y algunos comandos para usar con él, de modo que requerÃa poco esfuerzo adicional aprender procedimientos de shell un poco más coplejos.
2. La programación de shell puede hacer el trabajo más rápido y con un bajo más costos en términos de ESFUERZO HUMANO.
3. La programación del shell eviaba derrochar tiempo en optimización del código. Los procedimientos de shell pueden reprogramarse en lenguaje C,esto sólo cobra sentido luego de demostrar que el esfuerzo vale la pena. Como la mayorÃa de estos programas sólo se corren alguna que otra vez cada determinada cantidad de dÃas, el esfuerzo no se justifica.
4. Los procedimientos de shell son pequeños y fáciles de mantener, especialmente porque solo son texto, no requieren programas objeto mantener bibliotecas.
Esta experiencia con el intérprete de comandos nos hizo ver que algunos agregados modestos en sus funcionalidades nos otorgarÃan grandes ganancias en los procedimientos que los usuarios podrÃan llevar a cabo directamente con el Shell. Por ello, a mediados en 1975, realizamos los cambios para dar 26 variables de un caracter, y conjuntos de comandos con valor variable para una cadena existente, o que pudiesen leer de una entrada estándar, asà como expresiones aritméticas y regulares. Estos cambios dieron como resultado una mejora dramática en las posibilidades y uso de la programación del Shell. Con esto se pudo manejar bases de datos pequeñas, y también se automatizaron muchÃsimos pequeños procedimientos manuales.
PWB/MM era tal vez el más utilizado, un paquete de macros para fotocomposicóon documental, utilizado para generar documentos de calidad imprenta en el mismo laboratorio, por cientos de personas no adeptas al UNIX.
RJE o Entrada de Trabajo Remoto es una aplicación de servicio demonio (residente en memoria). Se utilizaba su comando SEND para enviar a compilación al código, este se compilaba cruzado, se ejecutaba en el sistema objeto, y el resultado se devolvÃa al sistema de edición, todo de una sola pasada.
El siguiente era SCSS, un sistema de control de código fuente para PWB/UNIX utilizados para gestionar los cambios en módulos de texto que conformaban el código fuente (incluyendo además datos, documentación integrada). Registra cada cambio realizado y realiza control de versión in situ, incluso en ramas de código concurrente.
Fundamentalmente también se crearon CONTROLADORES, para utilizar todos los tipos de teletipos y videoterminales de la industria, incluyendo a LEAP para el controlador de terminales IBM3270 y de serie UNIVAC 1100
CONCLUSIONES
El PWB/UNIX demuestra que el sistema puede desarrollar la función para dar soporte al desarrollo de software para minicomputadoras y microprocesadores de forma bastante efectiva. Entre sus máquinas objetos se encuentran la máyores de los sistemas de cómputo actualmente disponibles. PWB puede ofrecer una interfaz uniforme e instalación de desarrollo para casi cualqueir proyecto, sin importar su tamaño o tipo.
PWB era considerado fácilmente adaptable sin alterar el tejido básico utilitario, en base al hecho de forzar un continuo ambiente de diálogo electrónico entre el staff de desarrollo y administración del sistema y de los usuarios.
Los principales puntos destacados:
- Ambiente único, uniforme y consistente para programar.
- Herramientas básicas buenas que podÃan combinarse para resolver necesidades especÃficas.
- Protección de datos para liberar a los usuarios de tareas de mantenimiento.
- Disponibilidad y confiabilidad de sistema muy alta.