I love capturing wooden bridges where I ride. This one is on Maple Mountain, near Duncan on a trail called Phloem. Lush, shady, and beautiful #naturephotography #trails #maplemountain #cowichanvalley #cowichantrails #CTSS
#CTSS
Why CTSS was called the "Compatible" Time-Sharing System. From the #CTSS Programmer's Guide (1963): http://www.bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf
Tom Van Vleck Analiza el uso de las #terminales de computadora en los primigenios ambientes de programación de los sistemas operativos de tiempo compartido.
#Multics #CTSS #gopher
gopher://texto-plano.xyz/0/~peron/docs/terminales.txt
@smonff @Perl Y’all know I’m the first to crow about unique #Perl features, but #RegularExpressions’ syntax of ^ for the start of a line or string and $ for the end dates back at least to #Unix co-author Ken Thompson’s rewrite of the `qed` text editor for the #CTSS operating system on the IBM 7090 #mainframe at #BellLabs around 1970. (Perl creator Larry Wall was a teenager at the time.)
En el otoño boreal de 1965, el Centro de Cómputación del #MIT se hallaba abocado en hacer funcionar #CTSS, el Sistema de Tiempo Compartido Compatible, en la nueva "máquina azul", la IBM 7094. Para ello solicitaba ayuda de los anteriores desarrolladores de CTSS que se desempeñaban por entonces en el Proyecto MAC. Cuando se estrellaban con algún tipo de problemas, acudían a quienes estaban ya en el desarrollo del más avanzado MULTICS.
La máquina azul seguía colgándose con su software de respaldo a disco, y lo hacía de una manera que nunca habían visto, y los volcados de núcleo no tenían sentido.
El diagnóstico de hardware no demostraba problema alguno; los ingenieros de clientes de IBM insistían que la máquina estaba bien.
En particular, decidieron llamar a Bob Daley y Stan Dunten, quienes acudieron en repetidas ocasiones para intentar comprender qué era lo que estaba sucediendo.
Fernando "Corby" Corbató - alma de CTSS - se involucró en persona, conjeturando un "transiente de hardware" que afectaba alguno de los registros del banco de memoria. Finalmente Mike Padlipsky y Charlie Garman se hicieron cargo de la máquina azul en el medio del día, y cargaron un programa de una sola tarjeta perforada que contenía un bucle de prueba simple, y lo dejaron corriendo. Luego de aproximadamente diez minutos de ejecución, el contador de fallas en el registro de índice comenzó a avanzar el su conteo: ¡habían encontrado el bug!
Se descubrió que los nemónicos TXL y TXH en ocasiones invertían sus roles, en solo uno de los dos bancos de memoria núcleo. Tardaron un poco más en descubrir la verdadera causa: si un camión lo suficientemente grande atravesaba la calle Vassar, donde se hayaba el Centro de Computación, la interferencia elctromagnética de su sistema eléctrico provocaba la gaffe en la memoria electrónica.
Los programadores lanzaron un suspiro de alivio, entregaron las conclusiones a los ingenieros de asistencia al cliente de IBM, y se dirigieron a Tech Square House para celebrar.
Fueron varios los que aparecieron en el bar a tomar un trago, cuando repentinamente las luces se apagaron. Uno de los programadores subió nueve escaleras para ayudar a extraer los carretes de cinta magnética a mano, ya que estas cintas podrían dañarse si se encontraban en la lectora motorizada cuando retronase el suministro de energía eléctrica.
No debería haber corrido: se trataba del 9 de noviembre de 1965, se había producido el Gran Apagón de Nueva York, que afectó a más de 35 millones de personas en toda la costa este estadounidense, y se mantuvo de esa forma hasta el día siguiente por la mañana.
La máquina azul seguía colgándose con su software de respaldo a disco, y lo hacía de una manera que nunca habían visto, y los volcados de núcleo no tenían sentido.
El diagnóstico de hardware no demostraba problema alguno; los ingenieros de clientes de IBM insistían que la máquina estaba bien.
En particular, decidieron llamar a Bob Daley y Stan Dunten, quienes acudieron en repetidas ocasiones para intentar comprender qué era lo que estaba sucediendo.
Fernando "Corby" Corbató - alma de CTSS - se involucró en persona, conjeturando un "transiente de hardware" que afectaba alguno de los registros del banco de memoria. Finalmente Mike Padlipsky y Charlie Garman se hicieron cargo de la máquina azul en el medio del día, y cargaron un programa de una sola tarjeta perforada que contenía un bucle de prueba simple, y lo dejaron corriendo. Luego de aproximadamente diez minutos de ejecución, el contador de fallas en el registro de índice comenzó a avanzar el su conteo: ¡habían encontrado el bug!
Se descubrió que los nemónicos TXL y TXH en ocasiones invertían sus roles, en solo uno de los dos bancos de memoria núcleo. Tardaron un poco más en descubrir la verdadera causa: si un camión lo suficientemente grande atravesaba la calle Vassar, donde se hayaba el Centro de Computación, la interferencia elctromagnética de su sistema eléctrico provocaba la gaffe en la memoria electrónica.
Los programadores lanzaron un suspiro de alivio, entregaron las conclusiones a los ingenieros de asistencia al cliente de IBM, y se dirigieron a Tech Square House para celebrar.
Fueron varios los que aparecieron en el bar a tomar un trago, cuando repentinamente las luces se apagaron. Uno de los programadores subió nueve escaleras para ayudar a extraer los carretes de cinta magnética a mano, ya que estas cintas podrían dañarse si se encontraban en la lectora motorizada cuando retronase el suministro de energía eléctrica.
No debería haber corrido: se trataba del 9 de noviembre de 1965, se había producido el Gran Apagón de Nueva York, que afectó a más de 35 millones de personas en toda la costa este estadounidense, y se mantuvo de esa forma hasta el día siguiente por la mañana.
El tiempo de cómputo compartido consiste en una modalidad de trabajo para un sistema informático según el cual este puede afrontar las necesidades de uso de vari@s usuari@s en un mismo sistema de forma concurrente.
El sistema asigna tiempo de cómputo momentáneo a los usuari@s, de forma que tod@s puedan obtener resultados de sus tareas computacionales.
Antecedentes
Desde inicios de la década de 1950, los sistemas de computación no eran personales, sino que su alto costo y tamaño los convertía en equipamiento de grandes instituciones. Los equipos de tipo mainframe no solían estar disponibles para su uso exclusivo, sino que operaban en un proceso de cómputo por lotes. In@ operador@ responsable recibía encargos de programación o ejecución por medio de tarjetas o cintas de papel perforado para devolver posteriormente los resultados impresos de las órdenes. Este método era sumamente engorroso, pero hacía caso a las posibilidades de la tecnología del momento y su alto costo.
Este uso indirecto de computadora se cobraba entonces según el concepto de alquiler de segundos de procesamiento utilizados por un programa dado, a tiempo medido.
A finales de 1957 se planteó a través de la UNESCO un modelo teórico de cómputo de uso compartido, mediante un programa capaz de arbitrar el uso de un usuari@ activo entre múltiples posibles, siguiendo un bucle secuencial de acceso lo suficientemente veloz como para hacer parecer a cada usuari@ de la cola contase con la disponibilidad completa del ordenador.
Para inicios de la década de 1960 se inició la programación de distintos métodos y el diseño de grandes computadoras capaces de operar al unísono siguiendo esta teoría, en lugar de hacerlo de forma desatendida o por lista de espera, como sucedía anteriormente.
Los sistemas operativos de tiempo compartido comenzaron a experimentarse, inicialmente bajo la forma de #CTSS, o “Sistema de Tiempo Compartido Compatible”.
Durante la década de 1970 con el advenimiento de minicomputadoras de menor coste, así como la interconexión de las mismas a través de redes de datos de base telefónica o de télex, se hizo posibles un novedoso despliegue telemático, que acarreaban mayor comodidad de trabajo. Las minicomputadoras así provistas podían funcionar con varios usuari@s conectados a través de terminales de computadora tanto localmente en el centro de cómputo, como de manera remota a través del uso de módems telefónicos.
Sistemas Operativos Multiusuario
Los sistemas operativos multitarea y multiusuari@, de funcionamiento concurrente asignan la potencia del o los procesadores centrales de acuerdo a las necesidades específicas.
En aproximado orden cronológico, algunos de ellos fueron: CTSS, DTSS #MULTICS, TOPS-10, #TENEX, TSS/360, WAITS, ITS, #TWENEX, #Unix, #VMS, #BSD, y
La conectividad actual permite el uso compartido de infraestructura de cómputo. Sin embargo, debes prever que tal infraestructura siga tus anhelos y haga realidad los de tu comunidad.
Este cuento dice mucho del ethos en ITS.
El #ITS era el "Sistema de Cómputo de Tiempo Compartido Incompatible". Los hackers del Instituto Tecnológico de Massachussets lo habían llamado así en joda por el #CTSS, el Sistema de tiempo compartido compatible.
Dentro de la ecléctica y potente suite de programas de ITS había un programa que permitía ver qué era lo que salía en la terminal de otro usuario. Espiaba la salida del otro tipo examinando la interna del sistema de monitoreo. Este programa de espía de salidas se llamaba OS. En el resto del mundo de los cientístas del cçomputo (y en IBM también) OS significa "Sistema Operativo", pero entre los hackers de ITS significaba "espía de salida" ("Output Spy").
OS podía funcionar porque ITS tenía - a propósito - poca "protección" que impidiera a un usuario traspasar las áreas de otro. Lo justo es lo justo: había otro programa que podía notificarte automáticamente si alguien comenzaba a espiar tu salida de teletipo. Funcionaba de la misma manera, fisgoneando el proceso del sistema operativo para ver si alguien estaba observando dentro del proceso que daba cuenta de la salida de teletipo. Este programa de "contraespionaje" se llamab JEDGAR (pronunciado "jed-gr" en honor al oscuro ex-dirigente del FBI.
Pero hay más. El JEDGAR pediría al usuario una "licencia para matar". Si el usuario tipeaba "si", JEDGAR tiroteaba (con comando ":GUN") el proceso del "luser" espía (usuario perdedor, todo en la ácida jerga del MIT). Desafortunadamente, los #hackers del laboratorio descubrieron que esto hacía la vida académica demasiado violenta, especialmente cuando los "turistas" del sistema lo aprendieron. Uno de los hackers del sistema resolvió el problema reemplazando a JEDGAR con otro programa que sólo pretendía hacer este trabajo. Le tomó un largo tiempo hacer esto, porque debió emparchar cada copia de JEDGAR. No se sabe aún a ciencia cierta cuántos programadores del MIT comprendieron que JEDGAR estaba en realidad con un revólver sin balas y un pantalón sin bolas.
Aún así, JEDGAR tuvo hijos. El sistema operativo multiusuario Unisys #MCP (pensado para grandes supercomputadoras de mediados de los 90s) contaba aún con un programa de nombre similar, y sigue vivo en tal sistema. Tal vez sea un tributo, o una invención independiente. Quien sabe.
El #ITS era el "Sistema de Cómputo de Tiempo Compartido Incompatible". Los hackers del Instituto Tecnológico de Massachussets lo habían llamado así en joda por el #CTSS, el Sistema de tiempo compartido compatible.
Dentro de la ecléctica y potente suite de programas de ITS había un programa que permitía ver qué era lo que salía en la terminal de otro usuario. Espiaba la salida del otro tipo examinando la interna del sistema de monitoreo. Este programa de espía de salidas se llamaba OS. En el resto del mundo de los cientístas del cçomputo (y en IBM también) OS significa "Sistema Operativo", pero entre los hackers de ITS significaba "espía de salida" ("Output Spy").
OS podía funcionar porque ITS tenía - a propósito - poca "protección" que impidiera a un usuario traspasar las áreas de otro. Lo justo es lo justo: había otro programa que podía notificarte automáticamente si alguien comenzaba a espiar tu salida de teletipo. Funcionaba de la misma manera, fisgoneando el proceso del sistema operativo para ver si alguien estaba observando dentro del proceso que daba cuenta de la salida de teletipo. Este programa de "contraespionaje" se llamab JEDGAR (pronunciado "jed-gr" en honor al oscuro ex-dirigente del FBI.
Pero hay más. El JEDGAR pediría al usuario una "licencia para matar". Si el usuario tipeaba "si", JEDGAR tiroteaba (con comando ":GUN") el proceso del "luser" espía (usuario perdedor, todo en la ácida jerga del MIT). Desafortunadamente, los #hackers del laboratorio descubrieron que esto hacía la vida académica demasiado violenta, especialmente cuando los "turistas" del sistema lo aprendieron. Uno de los hackers del sistema resolvió el problema reemplazando a JEDGAR con otro programa que sólo pretendía hacer este trabajo. Le tomó un largo tiempo hacer esto, porque debió emparchar cada copia de JEDGAR. No se sabe aún a ciencia cierta cuántos programadores del MIT comprendieron que JEDGAR estaba en realidad con un revólver sin balas y un pantalón sin bolas.
Aún así, JEDGAR tuvo hijos. El sistema operativo multiusuario Unisys #MCP (pensado para grandes supercomputadoras de mediados de los 90s) contaba aún con un programa de nombre similar, y sigue vivo en tal sistema. Tal vez sea un tributo, o una invención independiente. Quien sabe.
#INFENES, #ASSAE, #CTSS : #JeVoteSud
Les mises en réseaux d’établ. gèrent la pénurie au détriment du service public et des conditions de travail. @SUD_education réclame des recrutements et l’augmentation immédiate des salaires.
https://www.sudeducation69.org/infenes-assae-ctss-je-vote-sud-education/
Infirmier.e de l'EN, Assistant.e de service social : #JeVoteSud ! #INFENES #ASSAE #CTSS
https://www.sudeducation69.org/infenes-assae-ctss-je-vote-sud-education/
Feliz cumpleaños Fernando J. Corbató (1927-1919)!
Padre de #CTSS, #Multics y ¡el Matusalén del tiempo de cómputo compartido! ✌️
Ganó el Premio Turing de 1990 por su trabajo pionero en la organización de los conceptos y liderazgo en el desarrollo de sistemas de cómputo de tiempo compartido de propósito general a gran scala. CTSS y Multics permitían compartir recursos informáticos en línea.
Padre de #CTSS, #Multics y ¡el Matusalén del tiempo de cómputo compartido! ✌️
Ganó el Premio Turing de 1990 por su trabajo pionero en la organización de los conceptos y liderazgo en el desarrollo de sistemas de cómputo de tiempo compartido de propósito general a gran scala. CTSS y Multics permitían compartir recursos informáticos en línea.
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst