Der Grund, warum der SPARC4 des Professors langsam wurde: xroach stapelte sich unter xterm

• Ein IT-Support-Mitarbeiter der CS-Fakultät ging wegen der Beschwerde eines Professors über die schlechte Leistung seines Sparc4 ins Büro und entdeckte dabei xroach, das sich hinter einem Fenster versteckt hatte
• Als er ein Fenster minimierte, sah der Bereich darunter wie ein schwarzes Rechteck aus, in dem sich Kakerlaken sehr langsam bewegten
• Die Bewegung lag bei etwa 0,5 fps, und unter xterm waren so viele xroach-Kakerlaken, dass sie wie ein einziger schwarzer Klumpen wirkten
• Der Kern des Problems war weniger die Hardware selbst, sondern dass xroach in einem für den Nutzer unsichtbaren Bereich weiter dargestellt wurde
• In alten X11-Desktop-Umgebungen können auch Scherzprogramme wie echte Leistungsprobleme wirken; deshalb ist es wichtig, versteckte Fenster und Hintergrundzustände zu prüfen

---

Die im Professorenbüro festgestellten Symptome

• Paco Hope arbeitete früher als IT-Support-Mitarbeiter der CS-Fakultät, als ein Professor sich beschwerte, sein Sparc4 sei langsam, und er deshalb ins Büro gerufen wurde
• Das Erste, was er tat, war, ein Fenster zu minimieren, und darunter erschien unerwartet ein schwarzes Rechteck
  • In diesem schwarzen Bereich bewegten sich xroach-Kakerlaken langsam hin und her
  • Die Bewegung war so langsam, dass sie wie etwa 0,5 fps wirkte

Unter xterm vollständig mit xroach gefüllt

• Unter xterm lagen so viele xroach, dass sie nicht mehr wie einzelne Kakerlaken, sondern fast wie ein einfarbig schwarzes Rechteck aussahen
• Der Professor hatte den Zustand darunter vor dem Minimieren des Fensters nicht gesehen, und die Beschwerde über die schlechte Leistung bekam erst durch die Untersuchung dieses verborgenen Bildschirmzustands eine Spur

Kurze Rückschau und Reaktionen

• Diese Anekdote ist eine kurze Rückschau, die Paco Hope am 25. Juli 2023 auf Mastodon veröffentlichte
• Beim Beitrag waren 202 Boosts und 389 Favoriten angezeigt, was bei Nutzern Anklang fand, die sich an alte Desktop-Umgebungen und scherzhafte Programme erinnern

[GN⁺]

Hacker-News-Kommentare

• Als ich technischen Support in einem lokalen Krankenhaus machte, rief eine Pflegekraft an: Auf dem Bildschirm sei „so ein Fenster wie eine Wettervorhersage“, und die Maus verschwinde darunter, sodass sie es nicht schließen könne.
  Ich wurde neugierig, bat sie, den Computer nicht anzufassen, und kam nach etwa 10 Minuten an. Da sagte sie: „Vor einer Minute hat es sich von selbst geschlossen. Es war 30 Minuten lang da.“
  Anhand der Schreibtischanordnung und der Beschreibung des Fensters drückte ich auf die Monitortasten, und es erschien das OSD-Menü des Monitors, das durch eine versehentlich mit der Tastaturecke gedrückte Taste ausgelöst worden war und die Helligkeit 100 % mit einem Sonnensymbol anzeigte. Dass die Maus darunter verschwand, war also völlig logisch.
  Ich ging die 10 Minuten zurück und wartete auf den nächsten Anruf.

  • Nachdem ich in einem Krankenhaus technischen Support gemacht hatte, bin ich mir nicht sicher, ob IT in dieser Umgebung wirklich so viel Mehrwert schafft, wie sie selbst glaubt.
    Pflegekräfte retten Leben und kümmern sich um Menschen am schlimmsten Tag ihres Lebens; zusätzlich müssen sie noch mit Workstations zurechtkommen, deren Implementierung und Wartung miserabel sind. Wenn sie um Hilfe bitten, kommen mitunter genau die Leute, die das Problem verursacht haben, und schauen auf sie herab.
    Pflegekräfte sind nicht dumm oder faul; sie haben einfach Wichtigeres zu tun, als Zeit mit Kleinigkeiten der IT zu verbringen.
    Für die tatsächlich behandlungsrelevanten Geräte gab es meist eigene Fachleute, und der Computer des MRT-Geräts war womöglich weder in Active Directory eingebunden noch überhaupt im Netzwerk. Probleme gingen nicht an jemanden, der Drucker repariert, sondern wurden an GE weitergereicht.
  • Ich bekam früher einmal einen Support-Anruf: „Der Bildschirm ist ständig verzerrt, ich glaube, ich habe einen Virus.“ Das war zu der Zeit, als der Film The Net noch im Kino lief.
    Als ich hinkam, stand auf dem CRT-Monitor ein Ghettoblaster mit zwei großen Lautsprechern. Als ich ihn wegnahm, war das Problem wie durch Zauberhand behoben.
  • Das klingt wie eine weiterentwickelte Version der 90er-Jahre-Geschichte vom kaputten „4x-CD-ROM-Becherhalter“.
    Eigentlich hat die Pflegekraft ziemlich genau beschrieben, was passiert war.

• 1989 leitete ich allein die IT-Abteilung an einem Ort, an dem ehemalige akademische Ökonomen auf einer Digital VAX 11/750 ökonometrische Modellierung betrieben.
  Dieser Minicomputer lief mit VMS, einem Mehrbenutzerbetriebssystem, und alle Nutzer hatten Administratorrechte. Jeder dachte, sein Modell laufe schneller, wenn er die eigene Prozesspriorität maximal erhöhe; tatsächlich behinderte das aber die für den Computerbetrieb nötigen Echtzeitprozesse und bewirkte das Gegenteil.
  Nachdem ich die Ursache gefunden, die Rechte entzogen und das System neu gestartet hatte, lief alles wieder normal, und man bedankte sich bei mir dafür, das System schneller gemacht zu haben.

  • Es gab ein von Studierenden verwaltetes System, und ich war einer von ihnen. Wir spielten einander gern Streiche; auf einer DEC-Workstation mit wenig Speicher lief bei einem von uns emacs.
    Jemand anders schrieb ein Programm, das sich selbst 1000-mal forkte, den nice-Wert auf 19 senkte, dann sleep(0) ausführte und beendete. Sobald es auch nur ein bisschen CPU-Zeit bekam, war es sofort fertig, aber solange emacs lief, bekam es diese Gelegenheit nicht. Währenddessen wurde die von xload angezeigte Last zu einem komplett schwarzen Kasten.
    Der emacs-Nutzer führte als root ps -ef | grep procname | xargs kill aus, aber um die kills zu verarbeiten, brauchte es CPU-Zeit, und das dauerte länger als sleep(0), sodass es kaum Wirkung zeigte.
    Beim zweiten Streich nannten wir den Prozess ema, woraufhin auch alle emacs-Instanzen beendet wurden.
    Beim dritten nannten wir den Prozess et; zufällig passte das auch auf /etc/initd, und die Maschine rebootete plötzlich.
  • 1993 wurde der Informatik-Einführungskurs für Erstsemester in Scheme gehalten, und die Aufgaben mussten auf einer gemeinsam genutzten Digital-Maschine unter Ultrix entwickelt und getestet werden.
    Der Scheme-Interpreter startete langsam, besonders wenn mehr als 20 Leute eingeloggt waren. Der Tutor zeigte uns, wie man den Interpreter mit ctrl-z pausiert, mit vi editiert und dann mit fg zurückkehrt.
    Das Problem war, dass nicht etwa die Hälfte, sondern zwei Drittel des Kurses nach dem Editieren fg vergaßen und stattdessen eine neue Scheme-Instanz starteten. Ich erinnere mich, wie das System am Abgabeabend im Terminalraum komplett kroch.
    Später lernte ich, Kommilitonen mit zwei oder mehr laufenden Scheme-Instanzen aufzuspüren und sie an fg zu erinnern; auch „Lösungen“ des Acht-Damen-Problems mit unendlicher Rekursion halfen der Last überhaupt nicht. Die eigentliche Lektion war: In späteren Semestern am Abgabeabend der CS-401-Aufgabe nicht einloggen.
  • 1991 nutzte ich an der Uni zum ersten Mal das Internet über solche Geräte. Ich fand eine nette Schwachstelle, mit der man anonym Nachrichten an alle broadcasten konnte, und erschreckte damit viele Leute.
    Weil die gemeinsam genutzten Terminals im selben Raum standen, konnte ich die Wirkung meines Tuns in Echtzeit sehen; das machte Spaß.
  • Ein gutes Beispiel für das ökonomische Prinzip der Tragik der Allmende: https://en.m.wikipedia.org/wiki/Tragedy_of_the_commons
  • Das erinnert mich an eine Geschichte, die mir ein früherer Kollege erzählt hat.
    In einer Umgebung, in der Leute Schlange standen, fragte jemand, ob man sich sein Problem vor dem der anderen ansehen könne. Er bat also darum, ganz nach vorn in die Warteschlange zu kommen.
    Er sagte: „Natürlich!“, und als der andere überrascht war, fügte er hinzu: „Aber Ihnen ist klar, dass ich dasselbe auch für jeden anderen tun werde, der die gleiche Bitte äußert?“
    Am Ende wartete die Person weiter an ihrem Platz.

• Erinnert mich an die goldene Studentenzeit von früher
  Bei mir war es Anfang der 2000er, und weil die Rechner im Uni-Labor nicht besonders leistungsfähig waren, arbeiteten die Leute oft in der Linux-Konsole, statt eine schwere X-Session zu starten.
  Um 2001 herum las ich die Manpage zu console_ioctl(4) und entdeckte, dass sie voller Möglichkeiten für Streiche steckte. Ich schrieb kleine Programme, die die Konsolenschrift manipulierten, um alle Zeichen auf den Kopf zu stellen, Groß- und Kleinbuchstaben zu vertauschen, die LED-Muster der Tastatur blinken zu lassen oder die Palette so zu ändern, dass der Bildschirm schwarz ausblendete und dann wieder zurückkam.
  Daran hängte ich eine Server-Komponente, ließ sie auf einem harmlos wirkenden Terminal laufen, wartete auf ein Opfer und schaltete die Effekte dann von einer anderen Maschine im selben Raum aus der Ferne ein, um die Reaktion zu beobachten. Zum Glück merkte ich bald, dass das Programmieren selbst mehr Spaß machte, als Leute in Panik zu sehen, und ließ Letzteres sein.
  Ein anderer Streich bestand darin, am getty-Login-Prompt den Text einzutippen, der so aussah, als wäre ein Root-Login erfolgreich gewesen. Einschließlich motd, mit Zeilenumbrüchen durch Tabs und Leerzeichen imitiert, ohne jemals RET zu drücken, und am Ende mit [root@mailhost root]# .
  Manche gaben aus Neugier whoami ein und waren verwirrt, warum plötzlich ein Passwort-Prompt erschien; andere trauten sich nichts anzufassen, zogen sich verängstigt zurück und mailten von einem anderen Terminal aus dem Systemadministrator.

  • Ich wünschte, wir hätten Linux-Systeme gehabt. In Windows-Netzwerken haben wir Ähnliches gemacht.
    Sobald ein Nutzer eingeloggt war, konnte man über den Task Scheduler praktisch jedes Programm mit den Rechten dieses Nutzers ausführen, und in Kombination mit Active Directory ließen sich auch Nutzerdaten herausfinden. Man wusste, wer wo saß, und öffnete etwa iexplorer auf einer bestimmten Site oder zeigte ein harmloses Word-Dokument an. Der bösartigste Fall war ein Batch-Skript zum automatischen Ausloggen.
    Später merkten die Leute, wie es ging, und versuchten, die Remote-Ausführung nachzumachen, führten es aber mit ihren eigenen Rechten statt denen des Zielnutzers aus. Als die IT-Administration kam, waren die Spuren, wer es gestartet hatte, viel zu eindeutig.
    Ich hörte mit den Streichen auf und landete schließlich über die IT als Software Engineer im Beruf. Manchmal frage ich mich, was passiert wäre, wenn ich damals eine Disziplinarstrafe bekommen hätte.
  • Klingt wirklich nach Spaß. Wenn man direkt am Ergebnis beteiligt ist, merkt man auf diese Weise, dass Coden unglaublich viel Spaß macht und wirkungsvoll ist.

• Auf einem IBM-370-Mainframe gab es über 80 Programmierer, und VM/370 stellte jedem Programmierer eine eigene virtuelle Maschine bereit. Ich war einer von zwei Systemprogrammierern mit „Superuser“-Rechten.
  In der virtuellen Maschine lief normalerweise CMS, aber man konnte auch anderes ausführen, und einige Maschinen liefen mit MVS.
  Um Befehle an die virtuelle Maschine selbst zu schicken, stellte man dem Befehl ein Sonderzeichen voran, standardmäßig #. Zum Beispiel war #cp ... ein Befehl an die virtuelle Maschine, und dieses magische Präfix konnte man in ein beliebiges Zeichen ändern.
  Eines Tages langweilte ich mich und fragte mich, ob man innerhalb einer virtuellen Maschine wieder VM laufen lassen könnte. Ich bootete VM auf der „zweiten Ebene“, änderte das Präfix auf ! und konnte darin neue virtuelle Maschinen anlegen.
  Dann bootete ich in einer virtuellen Maschine der „dritten Ebene“ erneut VM und änderte das Präfix auf @. Am Ende war ich bei 8 Ebenen Verschachtelung angekommen und hatte bestätigt, dass VM VM ausführen kann, das wiederum VM ausführt.
  Als ich fertig war und die verschachtelten Ebenen herunterfahren wollte, tippte ich aus Gewohnheit #cp shutdown ein, woraufhin das echte VM auf der echten Maschine herunterfuhr. In Panik rannte ich in den Maschinenraum und drückte den Startknopf an der Konsole.
  Natürlich gab es Systemlogs, und der andere Systemprogrammierer kam in mein Büro und sagte: „Mach das nie wieder.“ Das waren lustige Zeiten.

  • Um auf dieselbe Weise verschachtelte qemu-Ausführungen zu missbrauchen, habe ich das hier gebaut: http://git.annexia.org/?p=supernested.git;a=summary
  • Ich verstehe es nicht. Ich dachte, # sei das Präfix der VM auf Ebene 1, nicht des Betriebssystems auf Ebene 0, also des Hosts.
    Wenn mit # Befehle an Ebene 0 gingen, frage ich mich, welches Präfix dann Ebene 1 hatte.
  • Das erinnert an uns, als wir mit Linux-Erfahrung auf Solaris arbeiteten. Ein Prozess hing, und weil wir zu faul waren, die PID zu suchen, riefen wir einfach killall procname auf. Die Maschine starb sofort.
    Erst als der Systemadministrator kam, lernten wir, dass killall unter Solaris etwas anderes macht, und uns wurde gesagt, wir sollten es nie wieder benutzen.

• In den 80ern hatte ich als Student an der Uni Zugriff auf eine VAX 11/750, genauer gesagt einen 8750-Systime-Klon, und erledigte darauf Programmieraufgaben.
  Die Terminals für Studierende standen in einer Hälfte eines großen Raums, die andere Hälfte nutzten die IT-Mitarbeiter der Uni. Wenn auf der Seite der IT-Admins kein Terminal frei war, setzten sich ein oder zwei Mitarbeiter gelegentlich an die Studierenden-Terminals direkt hinter der Trennwand.
  Eines Tages wartete ich auf die Kompilierung eines COBOL-Projekts und langweilte mich so sehr, dass ich mich fragte, ob ich wohl Benutzername und Passwort eines Systemadministrators abfangen könnte. Ich schrieb ein Skript, das auf der CLI den Login-Prompt samt Piepton und Meldung perfekt nachahmte.
  Das Skript löschte den Bildschirm, wartete auf die Eingabe von Benutzername und Passwort, schickte sie mir dann per Mail, zeigte einen Fehler bei Benutzername/Passwort an und loggte sich aus, sodass der echte Login-Prozess übernahm.
  Nachdem ich es bei ein paar ahnungslosen Kommilitonen getestet und ein paar anonyme Streiche gespielt hatte, beschloss ich, es wirklich bei den Systemadministratoren zu versuchen. Ich loggte mich an den zwei Terminals ein, die die IT-Mitarbeiter normalerweise nutzten, und ließ dort das Skript laufen. Als ich einige Stunden später zurückkam, hatte ich zu meiner Überraschung und mit leichtem Unbehagen das SYSTEM-Login-Passwort erbeutet.
  Etwa einen Monat lang hatte ich die vollständige Kontrolle über diese Maschine, und jedes Mal, wenn das SYSTEM-Passwort geändert wurde, ließ ich gelegentlich das Skript erneut laufen. Ich sagte niemandem etwas und loggte mich am letzten Tag vor dem Abschluss vorsichtshalber noch einmal ein, um das Skript zu löschen. Damals wurden in Großbritannien die Gesetze gegen unbefugten Computerzugriff verschärft.
  Ich verbrachte viel Zeit mit den umfangreichen Handbüchern dieser Maschine, erforschte und lernte VMS, aber niemand bemerkte etwas.

  • Wegen solchem Login-Spoofing musste der Benutzer ab Windows NT zuerst mit Ctrl+Alt+Del in einen Sicherheitskontext wechseln.
    https://en.wikipedia.org/wiki/Control-Alt-Delete
  • Das wirkt auch wie eine Art Initiationsritus. Ich habe auf der VAX der Schule dasselbe gemacht, aber einen Tag später alle gesammelten Passwörter dem Systemadministrator übergeben und alles gestanden. Darunter waren auch ein paar Konten mit SYSTEM-Rechten.
    Sie gaben mir meinen ersten Job :-) Außerdem hatte ich vorsorglich ein oder zwei wenig bekannte Accounts mit den nötigen Rechten ausgestattet, damit ich sie zurückholen konnte, falls den „offiziellen“ Accounts die SYSTEM-Rechte entzogen würden.
    Das waren lustige Zeiten, und auch naive. Ich habe mit den Rechten kein Chaos angerichtet.
  • Großartig. Ich erinnere mich, dass ich für meinen Ti-83 ein BASIC-Programm geschrieben habe, um bei einer Algebra-Prüfung die Speicher-Initialisierungsprozedur nachzuahmen, die der Lehrer beim Herumlaufen persönlich ausführte.
    Dass ich heute mit Programmieren mein Geld verdiene, ist nicht allzu überraschend.
  • Ich finde es interessant, dass das Schreiben von Ersatzprogrammen für den Benutzer-Login unter angehenden Hackern ziemlich verbreitet zu sein scheint.
    Meines war für Schul-Windows, vermutlich ein Novell-Netzwerk, in Visual Basic 5. Es war sehr einfach, win.ini so zu ändern, dass es vor dem echten Login-Bildschirm ausgeführt wurde.
    Es speicherte Benutzernamen und Passwörter auf einem freigegebenen Netzlaufwerk oder in einer lokalen Datei, zeigte dann „Passwortfehler“ an und sprang anschließend zum echten Login-Prompt.
    Am Ende entstand das Problem, als ein „Freund“ mit derselben Technik die Netzwerk-Account-Dateien anderer Leute in sein eigenes Konto kopierte. Ich vermute, das System warnte den Netzwerkadministrator, als sein Kontingent voll war. Bei einer groben Durchsicht stellte sich heraus, dass er sogar die Aufsatzdateien eines Lehrers kopiert hatte, und das war ein absolutes Tabu.
    Durch diesen Vorfall bekam ich letztlich meinen ersten computerbezogenen Job als Junior-Techniksupport/Netzwerkadministrator.
  • Ich erinnere mich, dass um 1985 an der CMU ein Student so etwas gemacht hat und deswegen großen Ärger bekam.

• 1988 entdeckten ein Freund und ich in der Highschool im NetWare der 30 IBM PS/2 Model 30-286 im neuen Computerraum eine Schwachstelle, mit der man ein Programm in die autoexec-Netzwerk-Bootsequenz einschleusen konnte.
  Davor hatten wir mit den damals neuen VGA-Registern herumgespielt und herausgefunden, wie man im 80x25-Textmodus ohne Flackern oder Artefakte in den 320x200-Grafikmodus mit 256 Farben wechseln konnte. Der Grund war, dass beide Modi eine Bildwiederholrate von 70 Hz hatten.
  Mein Freund schrieb ein TSR, das ein digitales Bild eines Clownsgesichts vorab nach A000:0000 lud, nach etwa vier Minuten für ein paar Frames das Clownsgesicht zeigte und danach sofort zum Bildschirm zurückkehrte, an dem der Benutzer gearbeitet hatte.
  Wir flogen auf, weil wir in der Ecke des Klassenzimmers nicht aufhören konnten zu lachen, als wir die verwirrten und verängstigten Gesichter der Schüler sahen. Besonders großartig war der Moment, als ein Schüler den Lehrer holte und ihn über drei Minuten lang auf den Bildschirm schauen ließ — genau in dem Moment, als der Lehrer sich umdrehte, blitzte das Clownsgesicht auf.
  Mein Freund hieß Brian und war einer der klügsten Menschen, die ich je kennengelernt habe. Zehn Jahre später gründeten wir mobygames.com.

  • Mein Streich bestand darin, ab und zu Vogelgezwitscher abzuspielen. Es ertönte normalerweise alle paar Minuten, und ich mischte mehrere Zufallszahlen hinein, sodass es jedes Mal anders klang.
    Die Frequenz des Tons änderte sich ständig, sodass es keinen einzigen Moment einen festen Ton gab. Damals konnten Lautsprecher normalerweise nur piepen, und ich ließ es auf unbenutzten Maschinen laufen.

• Anfang der 90er war ich Studienanfänger im Fach Informatik an einer State University. Die Computerräume waren voller Sun SPARCstation IPCs mit SunOS, und es gab ein grundlegendes E-Mail-System, über das die Leute im Fachbereich kommunizierten.
  Die Technikaffinen erkundeten bereits Usenet, aber für die meisten war E-Mail die gesamte digitale Welt.
  Eines Tages beschlossen ein paar Freunde und ich, einen Streich zu spielen, und ließen uns von dem bekannten fortune-Befehl inspirieren, der zufällige Sinnsprüche ausgibt. Wir bauten ein einfaches Shell-Skript, das aus einer Textdatei mit lustigen und absurden Sätzen von uns eine zufällige Zeile auswählte und sie per Mail an einen zufälligen Nutzer des Informatik-Fachbereichs schickte. Das registrierten wir als cron-Job, sodass jede Stunde eine Nachricht verschickt wurde.
  Anfangs war es ein harmloser Streich. Die Leute fanden die Nachrichten witzig und teilten sie im Praktikumsraum. Die Herkunft der Nachrichten wurde im Fachbereich zum Gesprächsthema, aber niemand wusste, woher sie kamen, und wir hatten unseren Spaß daran, wie Kommilitonen und Professoren über den mysteriösen Absender rätselten.
  Dann eskalierte die Sache, als der Dekan eine besonders absurde Nachricht bekam: „Warum verwechseln Informatiker Weihnachten und Halloween? Weil Oct 31 == Dec 25 ist.“ Er verstand den Witz nicht und hielt sie für eine verschlüsselte Botschaft oder eine mögliche Drohung.
  Das Campus-IT-Team wurde zur Untersuchung hinzugezogen, und es entstand ein einwöchiger Aufruhr, bei dem versucht wurde, die Quelle der E-Mails zurückzuverfolgen. Meine Freunde und ich sahen nervös zu und fragten uns, ob wir erwischt und exmatrikuliert würden.
  Nach ein paar schlaflosen Tagen beschlossen wir schließlich, uns zu stellen. Wir gingen zum Dekan und gestanden alles. Nach einem langen Schweigen fing er an zu lachen. Wie sich herausstellte, hatte ihm einer der Informatikprofessoren den Witz erklärt, und er hatte nur darauf gewartet, wann wir uns melden würden.
  Er nahm uns den Streich nicht übel und fand unseren Unternehmungsgeist kreativ, warnte uns aber vor den unbeabsichtigten Folgen solcher Streiche.
  Rückblickend war es ein lustiger und unvergesslicher Streich, der uns eine wertvolle Lektion über Ethik bei der Nutzung von Technologie erteilte. Diese Geschichte erzähle ich heute oft meinen Informatikstudierenden, wenn ich ihnen die Bedeutung ethischen Handelns in der digitalen Welt vermittle.

• Ich musste einmal nachsehen, warum sich der PC des Mathematik-Fachbereichsleiters seltsam verhielt.
  Wie sich herausstellte, hatte er Prime95 zehn Jahre lang alle freien Zyklen auf einem Core eines Core 2 Duo nutzen lassen, und die Maschine bootete erst wieder, wenn sie auf Raumtemperatur abgekühlt war.

  • Ich brauchte viel zu lange, um mich daran zu erinnern, dass Prime95 außer für Stresstests noch einen anderen Zweck hat.
  • Ungenutzte Zyklen sind verschwendete Zyklen /s

• Ein Streich, den ein Freund in der Graduiertenzeit einem anderen Freund gespielt hat.
  Während das Opfer eingeloggt war und kurz sein Terminal verlassen hatte, fügte der Übeltäter der Datei .login die Zeile echo sleep -1 >> .login hinzu.
  Ein paar Tage später, nachdem mehr als 20 sleep-Anweisungen hinzugekommen waren, wurde klar, dass mit dem Login dieses Studenten etwas besonders im Argen lag. Von Tag zu Tag dauerte es vom ersten Login bis zum aktiven Terminal länger, das Opfer wurde immer genervter, und als es schließlich unerträglich wurde, flog der Streich auf.

  • Ich bin hierhergekommen, um genau denselben Streich in Erinnerung zu rufen :)
    Nach einer Weile fand ich, dass eine zusätzliche Sekunde pro Login zu subtil war.
    echo "echo sleep 1 >> ~/.login" >> ~/.login

• Interessant ist, dass viele dieser alten Geschichten am Ende auf „Es sollte nicht bösartig sein, sondern lustig, und wir hatten keine Ahnung, dass es sich so stark vermehren oder so viele Ressourcen verbrauchen würde“ hinauslaufen.
  Beim Morris worm war es ähnlich. Man kann darüber streiten, aber man kann ihn durchaus als Malware betrachten; zumindest heißt es, dass er wohl nicht so gravierend werden sollte.