La razón por la que la SPARC4 del profesor se volvió lenta era un xroach que llenaba el espacio bajo xterm

• Un encargado de soporte de TI del departamento de CS fue a la oficina de un profesor por una queja sobre la degradación del rendimiento de una Sparc4 y descubrió xroach escondido detrás de una ventana
• Al minimizar una ventana, la parte inferior de la pantalla parecía un rectángulo negro, y dentro de él las cucarachas se movían muy lentamente
• El movimiento era de alrededor de 0.5 fps, y había tantas cucarachas de xroach debajo de xterm que se veían como una sola masa negra
• El punto central del problema no era tanto el hardware en sí, sino el hecho de que xroach seguía mostrándose en un lugar que el usuario no veía
• En entornos de escritorio X11 antiguos, incluso los programas de broma pueden parecer problemas reales de rendimiento, por lo que es importante revisar ventanas ocultas y estados en segundo plano

---

Síntomas revisados en la oficina del profesor

• Paco Hope recuerda que, cuando trabajaba como encargado de soporte de TI del departamento de CS, un profesor se quejó de que su Sparc4 estaba lenta y lo llamaron a su oficina
• Lo primero que hizo fue minimizar una ventana, y debajo apareció un inesperado rectángulo negro
  • Dentro del área negra, las cucarachas de xroach se movían poco a poco
  • El movimiento era tan lento que parecía de alrededor de 0.5 fps

xroach llenando el espacio bajo xterm

• Había tantas instancias de xroach acumuladas debajo de xterm que no se veían como cucarachas individuales, sino casi como un rectángulo negro de un solo color
• El profesor no había visto lo que había debajo hasta minimizar la ventana, y la pista sobre la queja de bajo rendimiento apareció al revisar ese estado oculto de la pantalla

Breve recuerdo y reacciones

• Esta anécdota es un breve recuerdo que Paco Hope publicó en Mastodon el 25 de julio de 2023
• La publicación muestra 202 boosts y 389 favoritos, y generó empatía entre usuarios que recuerdan los entornos de escritorio antiguos y los programas de broma

[GN⁺]

Opiniones en Hacker News

• Cuando trabajaba en soporte técnico en un hospital local, una enfermera llamó diciendo que en la pantalla había aparecido “una ventana como de pronóstico del tiempo” y que no podía cerrarla porque el mouse se metía por debajo
  Me dio curiosidad, así que le dije que no tocara la computadora y, tras caminar unos 10 minutos hasta llegar, me dijo: “Se cerró sola hace un minuto. Estuvo abierta como 30 minutos”
  Por la distribución del escritorio y la descripción de la ventana, presioné un botón del monitor y apareció el menú OSD del monitor, que se había activado por accidente con una esquina del teclado, y mostraba el brillo al 100% con un ícono de sol. Era lógico que el mouse pasara por debajo
  Caminé otros 10 minutos de regreso y esperé la siguiente llamada

  • Después de hacer soporte técnico en un hospital, no estoy seguro de que en ese entorno TI aporte tanto valor como cree aportar
    Las enfermeras están ocupadas salvando vidas y atendiendo a personas en el peor día de sus vidas, y encima tienen que lidiar con estaciones de trabajo implementadas y mantenidas pésimamente. Cuando piden ayuda, a veces aparecen las mismas personas que crearon el problema y las tratan con condescendencia
    Las enfermeras no son tontas ni flojas; son personas que tienen cosas más importantes que hacer que dedicar tiempo a problemas menores de TI
    El equipo importante para la atención médica real por lo general lo gestionaban especialistas dedicados, y las computadoras de los equipos de MRI podían no estar unidas a Active Directory ni conectadas a la red. El problema se escalaba a GE, no a la persona que arreglaba impresoras
  • Hace años recibí una llamada de soporte que decía: “La pantalla se sigue distorsionando, creo que tiene un virus”. Era la época en que la película The Net todavía estaba en cartelera
    Al llegar, había una grabadora/boombox con dos bocinas grandes encima del monitor CRT; al quitarla, el problema se solucionó como por arte de magia
  • Parece una versión más avanzada de la historia noventera del “portavasos 4x que se rompió”
    De hecho, la enfermera describió lo que ocurrió con bastante precisión

• En 1989 fui el único encargado del área de TI en un lugar donde execonomistas académicos hacían modelado econométrico en una Digital VAX 11/750
  Esa minicomputadora corría VMS, un sistema operativo multiusuario, y todos los usuarios tenían privilegios de administrador. Cada uno creía que si subía al máximo la prioridad de sus procesos, su modelo correría más rápido, pero eso interfería con los procesos en tiempo real necesarios para operar la computadora y terminaba logrando el efecto contrario
  Después de encontrar la causa, quitarles los privilegios y reiniciar el sistema, todo volvió a la normalidad, y me agradecieron por hacer que el sistema fuera más rápido

  • Había un sistema administrado por estudiantes, y yo era uno de ellos. Solíamos hacernos bromas, y uno estaba ejecutando emacs en una estación de trabajo DEC con poca memoria
    Otro escribió un programa que hacía fork de sí mismo 1000 veces, bajaba su valor nice a 19, luego hacía sleep(0) y terminaba. Si recibía aunque fuera un poco de tiempo de CPU, acababa de inmediato, pero mientras emacs estuviera corriendo no conseguía esa oportunidad. Mientras tanto, la carga que mostraba xload se convertía en un cuadro totalmente negro
    Quien usaba emacs ejecutó como root ps -ef | grep procname | xargs kill, pero para procesar los kill hacía falta tiempo de CPU, eso tardaba más que sleep(0) y no tuvo mucho efecto
    En la segunda broma, el nombre del proceso fue ema, y como resultado también murieron todas las instancias de emacs
    En la tercera, el nombre del proceso fue et, pero por casualidad también coincidió con /etc/initd, y la máquina se reinició de golpe
  • En 1993, la clase introductoria de Ciencias de la Computación para alumnos de primer año se daba en Scheme, y las tareas tenían que desarrollarse y probarse en una máquina Digital compartida que corría Ultrix
    El intérprete de Scheme tardaba en arrancar, especialmente cuando había más de 20 personas conectadas. El ayudante de cátedra nos enseñó a pausar el intérprete con ctrl-z, editar con vi y volver con fg
    El problema fue que no la mitad, sino dos tercios de la clase, olvidaban usar fg y, después de editar, abrían otra instancia de Scheme. Recuerdo que la noche de entrega, en la sala de terminales, el sistema se arrastraba por completo
    Después aprendí a buscar compañeros que estuvieran ejecutando dos o más instancias de Scheme y recordarles fg, y las “soluciones” al problema de las 8 reinas con recursión infinita tampoco ayudaban nada con la carga. La verdadera lección fue no iniciar sesión la noche de entrega de una tarea de CS 401
  • En 1991 usé Internet por primera vez en la universidad a través de ese tipo de equipo. Encontré una vulnerabilidad genial que permitía enviar mensajes de broadcast de forma anónima a cualquiera, y asusté a mucha gente
    Como las terminales compartidas estaban juntas en la misma sala, era divertido ver en tiempo real el efecto de lo que hacía
  • Es un buen ejemplo del principio económico de la tragedia de los comunes: https://en.m.wikipedia.org/wiki/Tragedy_of_the_commons
  • Me recuerda una historia que me contó alguien con quien trabajé
    En cierto entorno donde la gente hacía fila, alguien preguntó si podían ver su problema antes que el de los demás. Es decir, pedía que lo mandaran al principio de la fila
    Él le dijo: “¡Claro!” y, cuando la otra persona se sorprendió, agregó: “Pero sabe que haré lo mismo con cualquier otra persona que haga la misma petición, ¿verdad?”
    Al final, esa persona decidió seguir esperando en su lugar

• Me recordó mis viejos años dorados de estudiante
  En mi caso fue a principios de los 2000, y como las computadoras del laboratorio de la universidad no eran muy potentes, la gente solía trabajar en la consola de Linux en vez de abrir una sesión X pesada
  Alrededor de 2001, mientras leía la página de manual de console_ioctl(4), descubrí que estaba llena de material para hacer bromas. Hice pequeños programas para manipular la fuente de la consola y poner todos los caracteres al revés, intercambiar mayúsculas y minúsculas, hacer parpadear patrones en los LED del teclado, o cambiar la paleta para hacer que la pantalla se desvaneciera a negro y luego volviera
  A eso le añadí un componente de servidor, lo dejaba corriendo en una terminal de apariencia normal, esperaba a que llegara la víctima y luego activaba los efectos remotamente desde otra máquina en la misma sala para ver su reacción. Por suerte, pronto me di cuenta de que programar en sí era más divertido que ver a la gente confundida, y dejé esto último
  Otra broma era escribir manualmente en el prompt de login de getty lo que parecería la salida de un inicio de sesión root exitoso. Incluía hasta el motd, imitaba los saltos de línea con tabulaciones y espacios, sin presionar nunca RET, y terminaba con [root@mailhost root]#
  Algunas personas, por curiosidad, escribían whoami y se quedaban desconcertadas al ver que aparecía un prompt de contraseña; otras no se atrevían a tocar nada y se retiraban asustadas para escribirle al administrador del sistema desde otra terminal

  • Ojalá hubiéramos tenido sistemas Linux. En una red Windows hacíamos cosas parecidas
    Con que el usuario estuviera logueado, podías ejecutar prácticamente cualquier programa con los permisos de ese usuario mediante el Programador de tareas; y combinado con Active Directory, también podías obtener información del usuario. Sabíamos quién estaba dónde y abríamos iexplorer en un sitio específico, o mostrábamos un documento de Word inofensivo. El caso más malicioso fue un script batch de cierre de sesión automático
    Más tarde la gente descubrió cómo se hacía e intentó imitar la ejecución remota, pero terminaban ejecutándolo con sus propios permisos en vez de los del usuario objetivo, así que cuando llegaba el administrador de TI quedaba demasiado claro quién lo había ejecutado
    Yo dejé las bromas y, al final, pasé por TI y terminé trabajando como ingeniero de software. A veces me pregunto qué habría pasado si me hubieran sancionado en ese entonces
  • Suena realmente divertido. Es una forma de darte cuenta de que programar es tremendamente divertido e influyente cuando te involucras directamente en el resultado

• Teníamos más de 80 programadores en un mainframe IBM 370, y VM/370 creaba una máquina virtual para cada programador. Yo era uno de los dos programadores de sistemas con permisos de “superusuario”
  Dentro de la máquina virtual normalmente corríamos CMS, pero también se podían ejecutar otras cosas, y algunas máquinas corrían MVS
  Para enviar un comando a la propia máquina virtual, anteponías un carácter especial cuyo valor predeterminado era #. Por ejemplo, #cp ... era un comando dirigido a la máquina virtual, y ese prefijo mágico podía cambiarse por el carácter que quisieras
  Un día, por aburrimiento, me pregunté si podría volver a correr VM dentro de una máquina virtual. Arranqué VM en un “segundo nivel”, cambié el carácter de prefijo a !, y dentro de eso pude crear nuevas máquinas virtuales
  Luego arranqué VM otra vez en una máquina virtual de “tercer nivel” y cambié el prefijo a @. Al final llegué hasta 8 niveles de anidamiento, y confirmé que VM podía correr VM, que a su vez podía correr VM, y así sucesivamente
  Cuando quise terminar y cerrar los niveles anidados, por costumbre escribí #cp shutdown, pero eso apagó la VM real de la máquina real. Entré en pánico, corrí a la sala de máquinas y presioné el botón de inicio de la consola
  Por supuesto quedó registrado en los logs del sistema, y el otro programador de sistemas vino a mi oficina y me dijo: “No vuelvas a hacerlo”. Eran tiempos divertidos

  • Hice esto para abusar de la ejecución anidada de qemu de la misma forma: http://git.annexia.org/?p=supernested.git;a=summary
  • No lo entiendo. Pensé que # era el prefijo de la VM de nivel 1, no del sistema operativo de nivel 0, es decir, el host
    Si con # enviaste un comando al nivel 0, me pregunto cuál era el prefijo del nivel 1
  • Suena como nosotros trabajando en Solaris estando acostumbrados a Linux. Un proceso se quedó colgado y, como nos daba flojera buscar el PID, simplemente llamamos killall procname. La máquina murió de inmediato
    Solo cuando llegó el administrador del sistema aprendimos que en Solaris killall hace otra cosa, y nos dijeron que no volviéramos a usarlo

• En la universidad, en los 80, cuando era estudiante, tenía acceso a una VAX 11/750 —más exactamente, un clon Systime 8750— para hacer tareas de programación.
  Las terminales para estudiantes estaban en la mitad de una sala grande, y la otra mitad la usaba el personal de TI de la universidad. Si no había terminales libres del lado de los administradores de TI, uno o dos empleados solían usar las terminales de estudiantes justo del otro lado del biombo.
  Un día, mientras esperaba a que compilara un proyecto en COBOL, me aburrí tanto que me pregunté si podría capturar el nombre de usuario y la contraseña del administrador del sistema. Escribí un script que imitaba perfectamente en la CLI el prompt de inicio de sesión, incluido el pitido y el mensaje.
  El script limpiaba la pantalla y esperaba a que se ingresaran el nombre de usuario y la contraseña; cuando se ingresaban, me los enviaba por correo, mostraba un error de usuario/contraseña y luego cerraba la sesión para pasar al proceso real de login.
  Después de probarlo con algunos compañeros despistados y hacer un poco de bromas anónimas, decidí intentarlo de verdad con los administradores del sistema. Inicié sesión en las dos terminales que normalmente usaba el personal de TI y dejé corriendo el script; unas horas después volví y, para mi sorpresa y con algo de inquietud, había conseguido la contraseña de login de SYSTEM.
  Durante más o menos un mes tuve control total de esa máquina, y de vez en cuando volvía a ejecutar el script cada vez que cambiaban la contraseña de SYSTEM. No se lo dije a nadie, y el último día antes de graduarme inicié sesión por si acaso y borré el script. En ese entonces, en el Reino Unido se estaban endureciendo las leyes sobre acceso no autorizado a computadoras.
  Pasé mucho tiempo explorando y aprendiendo VMS con los enormes manuales de esa máquina, pero nadie se dio cuenta.

  • Por este tipo de spoofing de login, desde Windows NT el usuario tenía que entrar primero a un contexto seguro con Ctrl+Alt+Del.
    https://en.wikipedia.org/wiki/Control-Alt-Delete
  • Esto también parece una especie de rito de iniciación. Hice lo mismo en la VAX de la escuela, pero al día siguiente le entregué al administrador del sistema todas las contraseñas que había recopilado y le confesé todo. Había incluso algunas cuentas con privilegios de SYSTEM.
    Me dieron mi primer trabajo :-) Además, dejé previamente asignados los permisos necesarios a una o dos cuentas poco conocidas, para poder recuperarlos aunque me quitaran los privilegios de SYSTEM de la cuenta “oficial”.
    Eran tiempos divertidos, y también ingenuos. No hice un desastre con los privilegios.
  • Excelente. Me acuerdo de haber escrito un programa en BASIC para la Ti-83 para imitar el procedimiento de borrado de memoria que el profesor hacía personalmente mientras caminaba por el salón durante un examen de álgebra.
    Ahora no sorprende mucho que me gane la vida programando.
  • Me parece interesante que usar un reemplazo del programa de inicio de sesión haya sido algo bastante común entre futuros hackers.
    El mío fue en Visual Basic 5 para Windows de la escuela, probablemente en una red Novell. Era muy fácil modificar win.ini para que se ejecutara antes de la pantalla real de login.
    Guardaba el nombre de usuario y la contraseña en una unidad de red compartida o en un archivo local, mostraba “contraseña incorrecta” y luego salía al prompt real de inicio de sesión.
    Al final el problema surgió cuando un “amigo” usó la misma técnica para copiar a su propia cuenta archivos de las cuentas de red de otras personas. Supongo que cuando llenó su cuota, el sistema alertó al administrador de red. Al revisar por encima, quedó en evidencia que incluso había copiado archivos de trabajos académicos de los profesores, y eso sí que era un gran tabú.
    Gracias a ese incidente terminé consiguiendo mi primer trabajo relacionado con computadoras, como soporte técnico junior/administrador de red.
  • Recuerdo que alrededor de 1985, en CMU, un estudiante hizo algo así y se metió en un gran problema.

• En 1988, en la secundaria, un amigo y yo descubrimos una vulnerabilidad en NetWare, desplegado en 30 IBM PS/2 Model 30-286 del nuevo laboratorio de computación, que permitía insertar un programa en la secuencia de arranque de red de autoexec.
  Antes de eso, jugando con los registros VGA, que en ese entonces eran nuevos, había descubierto cómo cambiar del modo de texto 80x25 al modo gráfico 320x200 de 256 colores sin parpadeos ni glitches. Era porque ambos modos tenían una tasa de refresco de 70 Hz.
  Mi amigo hizo un TSR que precargaba una imagen digital de una cara de payaso en A000:0000, y unos 4 minutos después mostraba la cara del payaso durante unos cuantos frames para luego devolver de inmediato al usuario a la pantalla en la que estaba trabajando.
  Nos descubrieron porque, desde una esquina del salón, no pudimos contener la risa al ver las caras de confusión y susto de los estudiantes. El mejor momento fue cuando un alumno llamó al profesor y lo hizo mirar la pantalla durante más de 3 minutos, y justo cuando el profesor se dio la vuelta apareció de golpe la cara del payaso.
  Mi amigo se llamaba Brian, y fue una de las personas más inteligentes que he conocido. Diez años después creamos mobygames.com.

  • Mi broma era hacer que de vez en cuando sonara como un pájaro. Normalmente cantaba cada pocos minutos, y mezclaba varios números aleatorios para que sonara distinto cada vez.
    La frecuencia del sonido cambiaba constantemente, así que no había ni un instante con una nota fija. En esa época los parlantes normalmente solo hacían pitidos, y solía dejarlo encendido en máquinas que no se estaban usando.

• A principios de los 90 era estudiante de primer año de licenciatura en informática en una universidad estatal. El laboratorio de computación estaba lleno de Sun SPARCstation IPC con SunOS, y había un sistema básico de correo electrónico que usaba la gente del departamento para comunicarse.
  La gente más metida en la tecnología ya estaba explorando Usenet, pero para la mayoría el correo electrónico era todo el mundo digital.
  Un día decidimos hacer una broma con unos amigos, inspirados por el famoso comando fortune, que imprime máximas aleatorias. Creamos un script de shell simple que elegía una línea al azar de un archivo de texto con frases graciosas y absurdas que habíamos escrito, y la enviaba por correo a un usuario aleatorio del departamento de informática; luego lo registramos como una tarea cron para que mandara una cada hora.
  Al principio era una broma inofensiva. A la gente le divertían los mensajes y los compartían en el laboratorio. El origen de los mensajes se volvió tema de conversación en el departamento, pero nadie sabía de dónde venían, y nosotros disfrutábamos viendo a compañeros y profesores adivinar quién era el remitente misterioso.
  Pero la cosa escaló cuando el decano recibió un mensaje especialmente absurdo: “¿Por qué los informáticos confunden Navidad con Halloween? Porque Oct 31 == Dec 25”. No entendió el chiste y pensó que era algún mensaje cifrado o una posible amenaza.
  El equipo de TI del campus se puso a investigar, y se armó un alboroto de una semana intentando rastrear el origen de los correos. Mis amigos y yo mirábamos nerviosos, preguntándonos si nos descubrirían y nos expulsarían.
  Al final, después de varias noches sin dormir, decidimos entregarnos. Fuimos con el decano y confesamos; tras un largo silencio, empezó a reírse. Resultó que uno de los profesores de informática le había explicado el chiste, y estaba esperando a ver cuándo nos presentábamos.
  Se tomó la broma con benevolencia y consideró creativa nuestra iniciativa, pero nos advirtió sobre las consecuencias no intencionales de ese tipo de bromas.
  Visto en retrospectiva, fue una broma divertida y memorable, y nos dejó una valiosa lección sobre la ética en el uso de la tecnología. Es una historia que suelo contarles a mis estudiantes de informática cuando les enseño la importancia de actuar éticamente en el mundo digital.

• Una vez tuve que revisar el problema de la PC del jefe del departamento de matemáticas, que estaba comportándose raro.
  Resultó que había dejado Prime95 usando todos los ciclos sobrantes en un núcleo de un Core 2 Duo durante 10 años, y esa máquina solo arrancaba si se enfriaba hasta temperatura ambiente.

  • Me tomó demasiado tiempo recordar que Prime95 sirve para algo más que pruebas de estrés.
  • Los ciclos sin usar son ciclos desperdiciados /s

• Una broma que un amigo le hizo a otro en la época de posgrado.
  Mientras la víctima había dejado la terminal un momento con la sesión iniciada, el bromista agregó echo sleep -1 >> .login al archivo .login.
  Unos días después, cuando ya se habían acumulado más de 20 sentencias sleep, se volvió evidente que algo estaba particularmente mal con el inicio de sesión de ese estudiante. Cada día tardaba más desde el login inicial hasta llegar a una terminal activa, la víctima se iba irritando cada vez más, y cuando finalmente se volvió insoportable, descubrieron la broma.

  • Vine a recordar la misma broma :)
    Después de un tiempo decidí que sumar 1 segundo en cada login era demasiado sutil.
    echo "echo sleep 1 >> ~/.login" >> ~/.login

• Es curioso que muchas de estas historias antiguas al final se reduzcan a “no era con mala intención, era para hacer reír, pero no imaginé que se multiplicaría tanto ni que consumiría tantos recursos”.
  El Morris worm fue parecido. Aunque es debatible, se puede considerar que fue diseñado como malware y, al menos según se cuenta, no había intención de que llegara a ser tan grave.