Should software be updated?

Before this controversial question gets answered let us take a step back and describe the situation from a general perspective. Software development is usually done in the upstream which is technically realized as a git repository. Multiple software developers are commiting changes to the repository frequently. They are solving bugs, clean up the code and introducing new features. Its not possible to reinvent this workflow because the described combination of programmers who are submitting updates to the git repository is the industry standard.

The only open debate is about how frequently the upstream source code gets converted into binary production ready executable code. This question remains unsolved and its the major cause why so many Linux distributions are available. The first distribution in the ecosystem, Gentoo Linux, assumes, that the end user has a need to compile the code by itself, because his needs are individual. The second distribution, Arch Linux, assumes that the user likes to update the software multiple times per week because this will make the system stable. The third distribution, Debian Linux, assumes that the end user runs a production server which is updated once a month and only security updates are desired.

The simple question is: which strategy is recommended? Nobody knows, and because of this unclear situation lots of opposite Linux distributions and Linux users are available. In general there are two conflicting opinions: rolling release vs. stable release. Rolling release means to increase the update frequency. In the maximum case this is equal to install every day new versions of the packages. The opposite ideology, stable release, means in the extrem case to run an oldoldstable Debian system which wasn't updated since months and some major security updates were skipped because of individual reasons.

Even computer scientists are assuming that the world can be described with Yes and no, True and false, its pretty difficult to answer which of the update strategies is more secure and more recommended. What we can say instead is, that in the reality, the stable release principle is applied in the reality more frequently. Most production servers in the internet are running with a stable release Linux distribution but not with a rolling release system like Archlinux or Debian SID.

To understand the conflict we have to describe how an upstream release gets delivered to a downstream software package. Suppose on day 1 a new version of a software gets installed for the first time on a computer. On this single day 1 the upstream and the downstream is synced perfectly. Both layers are running the same software. A few days later, the git repository in the upstream was modified because of different reasons. And one month later, the upstream git repository was improved drastically because the developers have modified the code. Unfortunately, the code on the downstream layer wasn't affected so the layers are running out of sync. The version in the upstream might be v1.05 but the version in the downstream remains v1.00.

Even without doing something, the out of sync situation will become serious over the time axes. After 12 months, the downstream will run still v1.0 but the upstream has improved the code towards v2.0. This will generate a conflict between the parties. The upstream argues, that the downstream is in charge to update to the new version, but the downstream has no reason for doing so and argues, that he can't update because its a production server with no downtime window.

Resolving the conflict isn't easy. In most cases, the downstream will take a decision. He can update the system in a certain frequency, for example, each month, each year or never. Its not clear what the optimal frequency is and most computers are updated in a different interval. The only thing which is for sure is, that a longer duration between two updates increase the out of sync situation between upstream and downstream.

Sind regelmäßige Softwareupdates sinnvoll?

 Moderator: "Herzlich willkommen zu unserer heutigen Diskussion über Software-Updates. Wir haben heute zwei Experten bei uns, die zwei sehr unterschiedliche Meinungen zu diesem Thema vertreten. Auf der einen Seite haben wir Klaus, einen erfahrenen Sicherheitsexperten, der die Notwendigkeit regelmäßiger Updates betont. Auf der anderen Seite ist Tim bei uns, ein Verfechter der 'Never touch a running system'-Philosophie. Beide werden uns ihre Sichtweise auf das Thema näherbringen.

Klaus, beginnen wir mit Ihnen. Warum sind Ihrer Meinung nach regelmäßige Software-Updates so wichtig?"

Klaus: "Vielen Dank für die Einladung. Software-Updates sind in der heutigen digitalen Welt von entscheidender Bedeutung. Stellen Sie sich vor, Ihr Haus hätte ständig offene Türen und Fenster. Ein Einbruch wäre nur eine Frage der Zeit. Genauso verhält es sich mit Software ohne aktuelle Sicherheitsupdates. Cyberkriminelle suchen ständig nach Schwachstellen, um in Systeme einzudringen, Daten zu stehlen oder sogar Unternehmen lahmzulegen. Durch regelmäßige Updates schließen wir diese Sicherheitslücken und machen es Angreifern deutlich schwerer, erfolgreich zu sein."

Moderator: "Das klingt nach einem starken Argument. Tim, können Sie das entkräften? Warum sind Sie der Meinung, dass Updates eher eine Gefahr als ein Nutzen darstellen?"

Gegner von Updates: "Ich verstehe die Sicherheitsbedenken, aber ich glaube, dass die Risiken von Updates oft unterschätzt werden. Jedes Update birgt die Gefahr, dass neue Fehler eingeführt werden, die das System instabil machen oder sogar zum Absturz führen können. Außerdem sind nicht alle Updates wirklich notwendig. Viele enthalten nur kleine Verbesserungen oder neue Funktionen, die für den durchschnittlichen Nutzer keinen Mehrwert bieten. Ich bevorzuge es, ein System zu haben, das zuverlässig funktioniert, anstatt ständig mit neuen Updates experimentieren zu müssen."

Penetration Tester: "Das ist ein weit verbreiteter Irrglaube. Die meisten modernen Updates sind sehr gut getestet und haben nur einen minimalen Einfluss auf die Systemstabilität. Außerdem sind viele dieser 'kleinen Verbesserungen' entscheidend für die Sicherheit des Systems. Nehmen wir zum Beispiel die jüngsten Ransomware-Angriffe. Viele dieser Angriffe nutzen bekannte Schwachstellen aus, die durch einfache Updates hätten geschlossen werden können."

Gegner von Updates: "Aber was ist mit den Fällen, in denen Updates tatsächlich zu Problemen führen? Ich habe selbst erlebt, wie ein wichtiges Programm nach einem Update nicht mehr funktionierte. Das kann für Unternehmen verheerende Folgen haben."

Moderator: "Das ist ein wichtiger Punkt. Es gibt sicherlich Fälle, in denen Updates zu Problemen führen können. Aber ist das Risiko nicht geringer, als das Risiko eines erfolgreichen Cyberangriffs?"

*Penetration Tester: "Absolut. Das Risiko, dass ein System durch veraltete Software kompromittiert wird, ist weitaus höher als das Risiko, dass ein Update zu Problemen führt. Außerdem gibt es Möglichkeiten, das Risiko von Update-Problemen zu minimieren, zum Beispiel durch das Erstellen von Backups oder das Testen von Updates in einer isolierten Umgebung."

Gegner von Updates: "Trotzdem bleibe ich dabei, dass ein funktionierendes System nicht ständig angefasst werden sollte. Wenn es nicht kaputt ist, dann repariere es nicht."

Moderator: "Vielen Dank für Ihre Ausführungen, beide. Wir werden dieses Thema gleich noch weiter vertiefen und auch auf die persönlichen Erfahrungen eingehen, die Sie mit Software-Updates gemacht haben."

----

Moderator: "Vielen Dank für diese klare Darstellung der beiden Seiten. Lassen Sie uns nun etwas persönlicher werden. Klaus, können Sie uns von einem konkreten Fall erzählen, bei dem ein Unternehmen aufgrund veralteter Software einen schweren Cyberangriff erlitten hat?"

Penetration Tester: "Natürlich. Ich erinnere mich noch sehr gut an einen Kunden, ein mittelständisches Unternehmen aus der Fertigungsindustrie. Sie hatten eine extrem veraltete Industriesteuerung im Einsatz, die seit Jahren nicht mehr gepatcht wurde. Ein Cyberangriff legte die gesamte Produktion still. Das Unternehmen musste mehrere Wochen lang schließen und erlitt einen immensen finanziellen Schaden. Die Mitarbeiter waren entlassen, die Kunden verärgert und der Ruf des Unternehmens nachhaltig beschädigt. Das war ein dramatischer Fall, der zeigt, welche verheerenden Folgen veraltete Software haben kann."

Moderator: "Tim, Sie haben ja bereits erwähnt, dass Sie negative Erfahrungen mit Updates gemacht haben. Können Sie uns von einem solchen Fall berichten?"

Gegner von Updates: "Ja, das kann ich. Ich hatte einmal ein sehr stabiles Betriebssystem, das seit Jahren problemlos lief. Dann kam ein großes Update, das versprach, viele neue Funktionen zu bieten. Nach der Installation waren plötzlich viele Programme nicht mehr kompatibel, und das System wurde extrem langsam. Ich habe mehrere Tage damit verbracht, das Problem zu beheben, und konnte in dieser Zeit kaum arbeiten. Solche Erfahrungen machen einen sehr skeptisch gegenüber neuen Updates."

Moderator: "Das sind eindrückliche Beispiele, die die beiden Seiten dieser Medaille sehr gut verdeutlichen. Klaus, wie kann man denn Unternehmen dazu bewegen, die Bedeutung von regelmäßigen Updates ernster zu nehmen?"

Penetration Tester: "Das ist eine komplexe Frage. Es bedarf einer Kombination aus Aufklärung, Beratung und gesetzlichen Vorschriften. Unternehmen müssen verstehen, dass Cyberangriffe keine theoretische Gefahr mehr sind, sondern eine alltägliche Realität. Zudem müssen sie die Kosten eines Cyberangriffs mit den Kosten für regelmäßige Updates vergleichen. Oft ist ein Update deutlich günstiger als die Folgen eines erfolgreichen Angriffs."

Moderator: "Tim, gibt es Ihrer Meinung nach Möglichkeiten, die Risiken von Updates zu minimieren?"

Gegner von Updates: "Ja, auf jeden Fall. Man sollte Updates nicht blindlings installieren, sondern sich vorher genau informieren, welche Änderungen sie mit sich bringen. Es ist auch wichtig, regelmäßige Backups zu erstellen, um im Falle von Problemen schnell wiederherstellen zu können. Und natürlich sollte man sich für ein Betriebssystem entscheiden, das bekannt dafür ist, stabil und zuverlässig zu sein."

Moderator: "Vielen Dank für Ihre offenen Worte, beide. Wir haben heute gesehen, dass das Thema Software-Updates sehr komplex ist und es keine einfachen Antworten gibt. Jeder muss für sich selbst abwägen, welche Risiken er bereit ist einzugehen."

From rolling release to froozen release

 

The archlinux community is convinced that a production server has to be updated once a day. The philosophy behind the rolling release model is to convert new sourcecode from the upstream project into a binary file and use the result on a computer for production ready tasks. The idea is that bugs and critical security issues are fixed always in the upstream and after installing the new version the server will become more stable.

The answer – according to the archlinux project – to every problem in computing is to install the new version as soon as possible. Unfortunately there are some cons available. First problem is that updating the entire operating system every day costs time and bandwidth. Lots of new packages have to downloaded and installed. Another more serious problem is, that from time to time the update procedure fails. That means the newly installed package doesn't work or in the worst case the entire wayland server won't display something on the screen so the user has to debug manually with the help of the forum. These problems are the main reasons why the Arch linux project remains a relative small project. And even Archlinux enthusiasts are shy to use the operating system as a webserver.

The opposite philosophy toward arch linux is of course the debian project which creates a new stable version every two 2 years and then the software version remains the same. Only minor bugfixes and security updates are shipped to the production server. And these patches are mostly delayed so that they can be tested on a virtual machine first. This ensures, that a debian server is always in a stable condition which makes it a great choice as a server and a desktop machine.

There is a third philosophy not discussed frequently in the past which is a froozen release model. Froozen release assumes that even Debian stable isn't reliable enough. The user is forced to install new minor versions every 3 months which includes to reboot the machine for a kernel update. The self understanding of a froozen release model, to not deliver any updates and reduce the amount of updates to zero. Froozen means, that a new operationg system is delivered every 2 years and the duration in between the system never gets rebooted or has to update something.

This implies that at the end of of the 2 years period the user is running outdated and all the CVE vulnerabilites remain unsolved. The open question is, if this model is superior to Debian or not.

From a technical standpoint its the logical improvement over stable releases. The idea is that installing updates is the cause for all problems and only an uptime of 700 days ensures stability.

To make the point more clear we should compare rolling release with froozen release. Rolling release means, that the admin of a server installs updates every day with the pacman tool. In contrast, froozen release means to disable the pacman tool at all and the server works 2 years with the unmodified code. If a security problem was available in the original code, this problem remains open for 2 years.

Its a bit hard or even impossible to verify on a scientific basis which software distribution is more reliable. Even the comparison between arch linux and Debian is highly subjective. Introducing a seldom discussed third distribution into the comparison will make the debate harder not easier.

OpenWRT uptime verbessern

 **1 Die Neuen und der Alte**

Jan war so etwas wie ein Wirbelwind, der ins beschauliche IT-Department geweht war. Gerade frisch von der Uni, sprühte er nur so vor Energie und neuen Ideen. Er hatte sich schon während des Studiums einen Namen als IT-Wunderkind gemacht, hackte sich in Systeme, als wäre es ein Kinderspiel und schwärmte von der unendlichen Macht des Codes. Sein neues Büro, ein kleines, unscheinbares Zimmer am Ende des Ganges, war für ihn eine Bühne, auf der er endlich sein Können unter Beweis stellen konnte.

Sein Mentor, oder besser gesagt, der Mann, der ihn einarbeiten sollte, war da ganz anders. Werner hieß er, und er war schon seit Jahrzehnten in der Firma. Er war ein Typ, der seine Arbeit liebte, aber auch seine Ruhe. Seine grauen Haare waren zu einem kurzen Zopf gebunden, und seine Brille saß etwas schief auf der Nase. Werner war ein Verfechter der alten Schule. Er vertraute auf seine Erfahrung und seine handgeschriebenen Karteikarten, in denen er alles Wichtige über das Firmennetzwerk notiert hatte. Diese Karteikarten waren sein Heiligtum, ein Schatz, den er sorgsam hütete.

Jan war von Werners Methoden zunächst etwas irritiert. „Karteikarten? In der heutigen Zeit?“, hatte er belustigt gefragt. Werner hatte nur geschmunzelt und geantwortet: „Die besten Systeme sind oft die einfachsten.“

In den ersten Tagen versuchte Jan, Werner mit seinen neuen Ideen zu beeindrucken. Er sprach von Cloud-Computing, künstlicher Intelligenz und DevOps. Werner hörte ihm geduldig zu, nickte gelegentlich, aber man merkte ihm an, dass er nicht ganz überzeugt war.

Eines Tages, während Jan durch die Serverräume schlenderte, stieß er auf einen alten Router. Es war ein OpenWRT-Router, der schon seit über einem Jahr ohne Probleme lief. Jan tippte ein paar Befehle in sein Notebook, und schon hatte er herausgefunden, dass der Router eine veraltete Firmware hatte. In seinem Kopf begannen die Alarmglocken zu läuten. Er hatte gerade von einer neuen, kritischen Sicherheitslücke in dieser Firmware gelesen.

Begeistert stürzte er in Werners Büro. „Werner, ich habe etwas gefunden!“, rief er. „Unser Router ist total unsicher!“ Werner legte seine Karteikarten beiseite und sah Jan skeptisch an. „Was ist denn jetzt schon wieder los?“, fragte er müde. Jan erklärte ihm die Situation und übertrieb die Gefahr der Sicherheitslücke. „Wenn wir nichts tun, könnten Hacker in unser Netzwerk eindringen und alle unsere Daten stehlen!“, warnte er. Werner zögerte. Er wusste, dass Updates immer ein Risiko bargen. Aber Jan war so überzeugt, dass er schließlich nachgab.

So begann das Drama um den Router.

**2 Die Entdeckung der Schwachstelle**

Jan war wie ein Hund auf der Fährte. Er hatte sich in den alten Router vergraben und jede Einstellung, jedes Protokoll und jede Konfigurationsdatei unter die Lupe genommen. Und dann war es passiert: Er hatte sie gefunden. Eine kleine, unscheinbare Zeile in einer langen Konfigurationsdatei, die auf eine veraltete Firmwareversion hinwies. Es war die CVE-2023-12345, eine Schwachstelle, die erst vor kurzem entdeckt worden war und es Hackern erlaubte, sich unbemerkt in das System einzuschleichen.

Mit leuchtenden Augen stürzte Jan zurück zu Werner. „Ich hab’s gefunden!“, rief er aufgeregt. „Eine riesige Sicherheitslücke! Hacker könnten jederzeit in unser Netzwerk eindringen und alles kaputtmachen!“ Werner runzelte die Stirn. Er hatte von solchen Schwachstellen schon gehört, aber er war sich nicht sicher, wie ernst die Lage wirklich war. „Das klingt ja nicht gut“, meinte er vorsichtig.

Jan wollte keine Zeit verlieren. Er hatte sich bereits im Internet schlau gemacht und wusste, welche Gefahren von dieser Schwachstelle ausgingen. Er malte Werner ein düsteres Bild von Cyberangriffen, Datendiebstahl und Erpressung. „Stell dir vor, unsere gesamte Kundendatenbank würde geleakt werden! Das wäre ein Desaster für das Unternehmen!“ Werner schluckte schwer. Er wusste, dass Jan Recht haben könnte. Aber er war auch skeptisch. Er hatte schon so viele Horrorgeschichten über Cyberangriffe gehört, und oft stellte sich heraus, dass die Gefahr doch nicht so groß war wie befürchtet.

Um Werner endgültig zu überzeugen, holte Jan seinen Laptop heraus und zeigte ihm einen Artikel aus einer renommierten IT-Zeitschrift. Der Artikel beschrieb im Detail, wie einfach es für Hacker wäre, diese Schwachstelle auszunutzen. Werner las den Artikel aufmerksam durch und musste zugeben, dass die Gefahr real war. „Okay, Jan“, sagte er schließlich. „Du hast Recht. Wir müssen etwas tun.“

Die Entscheidung war gefallen. Der alte Router musste so schnell wie möglich durch ein neues Modell ersetzt werden. Jan war überglücklich. Er hatte nicht nur eine gefährliche Sicherheitslücke entdeckt, sondern auch seinen Kollegen von der Notwendigkeit eines Updates überzeugt. Er fühlte sich wie ein Held.

**3 Die Entscheidung**

Werner war hin und her gerissen. Einerseits wollte er nicht, dass das Firmennetzwerk angegriffen wurde. Andererseits hatte er eine gewisse Skepsis gegenüber den ständigen Updates und Neuerungen. Er erinnerte sich noch gut an das letzte Mal, als ein Update zu einem großen Ausfall geführt hatte. Damals hatte er Tage gebraucht, um alles wieder zum Laufen zu bringen.

Jan merkte, dass Werner zögerte, und legte noch einmal nach. „Stell dir vor, was passieren könnte, wenn ein Hacker unsere Kundendaten stiehlt und sie im Darknet verkauft! Das wäre ein riesiger Imageschaden für unser Unternehmen. Und wir könnten sogar rechtlich belangt werden!“ Werner seufzte. Er wusste, dass Jan Recht hatte. Aber ein Teil von ihm wünschte sich, dass alles so bleiben könnte, wie es war. Er mochte seine Routine, seine Karteikarten und seinen alten Router.

Während Werner grübelte, holte Jan seine alten Karteikarten hervor. Er blätterte darin und suchte nach Informationen über den Router. „Sieh mal, Werner“, sagte er triumphierend. „Hier steht, dass die letzte Wartung schon vor über einem Jahr war. Der Router ist viel zu alt, um noch sicher zu sein.“ Werner runzelte die Stirn. Er hatte diese Karteikarte schon unzählige Male gelesen, aber jetzt, da Jan sie ihm so präsentierte, sah alles ganz anders aus.

Nach langem Hin und Her entschied sich Werner schließlich, das Update durchzuführen. „Okay, Jan“, sagte er. „Lass uns das Ding mal updaten. Aber pass auf, dass du nichts kaputt machst.“ Jan jubelte innerlich. Er hatte gewonnen. Er hatte seinen Kollegen überzeugt und durfte nun zeigen, was er konnte.

Bevor sie mit dem Update begannen, erstellte Werner noch eine Sicherungskopie aller wichtigen Daten. Er wollte auf Nummer sicher gehen, falls etwas schiefgehen sollte. Jan überprüfte noch einmal alle Einstellungen und startete dann den Update-Prozess. Sie beide verfolgten gespannt den Fortschrittsbalken auf dem Bildschirm.

Alles schien gut zu laufen. Der Router bootete neu und die neue Firmware wurde installiert. Jan atmete tief durch. Er hatte es geschafft. Das Netzwerk war jetzt sicherer als je zuvor.

**4 Die Vorbereitung**

Mit einem zufriedenen Lächeln beobachtete Werner, wie Jan die letzten Einstellungen am Router vornahm. Der junge Praktikant schien seine Sache wirklich gut zu machen. Er hatte sich in kürzester Zeit in die komplexe Materie der Netzwerkadministration eingearbeitet und bewiesen, dass er ein echter IT-Experte war.

„So, das sollte es gewesen sein“, sagte Jan schließlich und lehnte sich zurück. „Der Router ist jetzt auf dem neuesten Stand und sicherer als je zuvor.“ Werner nickte zustimmend. Er fühlte sich erleichtert. Die Entscheidung, das Update durchzuführen, war die richtige gewesen.

Bevor sie den Router wieder ins Netzwerk integrierten, wollten sie auf Nummer sicher gehen. Werner holte seine alten Karteikarten hervor und begann, die Konfiguration des Routers zu überprüfen. Er verglich jede Einstellung mit den Angaben auf seinen Karteikarten und nahm hier und da noch kleine Anpassungen vor. Jan beobachtete ihn dabei amüsiert. „Du bist schon ein bisschen altmodisch, Werner“, sagte er lachend. Werner grinste zurück. „Manche Dinge ändern sich einfach nicht“, antwortete er.

Während Werner an seinen Karteikarten arbeitete, machte sich Jan Gedanken über die Zukunft. Er hatte sich schnell in die Arbeit eingefunden und fühlte sich im IT-Team gut aufgehoben. Er träumte davon, eines Tages ein echter IT-Architekt zu werden und komplexe Netzwerke zu entwerfen.

Nachdem sie alle Vorbereitungen getroffen hatten, war es endlich soweit. Werner schaltete den Router wieder ein. Sie beide starrten gespannt auf die blinkenden LEDs. Nach einigen Sekunden erwachte der Router zum Leben und das Netzwerk war wieder online.

„Es hat geklappt!“, rief Jan jubelnd. Werner nickte ebenfalls zufrieden. Sie hatten es geschafft. Der alte Router war wieder fit und das Netzwerk war sicherer denn je.

Absolut! Hier ist der nächste Teil deiner Geschichte:

**5 Der große Moment**

Die Spannung lag in der Luft, als Werner und Jan gespannt auf die blinkenden LEDs des Routers starrten. Jeder Piepton, jedes Aufleuchten schien eine Ewigkeit zu dauern. Werner, der normalerweise so ruhig und gelassen war, begann unruhig hin und her zu wippen. Jan versuchte, ihn zu beruhigen, aber auch er spürte die Anspannung.

„Das dauert ja ewig“, murmelte Werner ungeduldig. „Normalerweise ist das doch viel schneller.“ Jan nickte. Auch er fand, dass das Update länger dauerte als erwartet. Aber er wollte Werner nicht unnötig beunruhigen.

Plötzlich erloschen alle Lichter am Router. Ein kollektiver Atemzug hallte durch den Raum. Jan und Werner starrten gebannt auf das Gerät. War das jetzt schon alles? Hatte das Update funktioniert? Oder war etwas schiefgelaufen?

Nach einigen Sekunden begannen die Lichter wieder zu blinken. Aber dieses Mal war es anders. Die LEDs blinkten wild durcheinander, als wollten sie einen SOS-Code senden. Jan sprang auf und tippte hektisch auf seinem Laptop. Er versuchte, eine Verbindung zum Router herzustellen, aber es gelang ihm nicht.

„Oh nein“, flüsterte Werner. „Das kann doch nicht wahr sein.“ Jan nickte stumm. Es sah ganz danach aus, als hätte das Update das Gerät zerstört. Der Router war tot.

Panik machte sich breit. Was sollten sie jetzt tun? Das gesamte Netzwerk war von diesem Router abhängig. Ohne ihn konnten die Mitarbeiter nicht mehr arbeiten und die Kunden nicht mehr erreicht werden. Jan und Werner sahen sich hilflos an. Sie hatten alles richtig gemacht, dachten sie. Aber trotzdem war alles schiefgegangen.

**6 Die Katastrophe**

Die Nachricht vom ausgefallenen Router verbreitete sich wie ein Lauffeuer durch das Unternehmen. Mitarbeiter standen ratlos vor ihren ausgeschalteten Computern und versuchten, ihre Arbeit fortzusetzen. Die Telefonanlage fiel aus, E-Mails konnten nicht mehr versendet werden und auch die Drucker blieben stumm. Das gesamte Unternehmen lag am Boden.

Werner und Jan standen inmitten des Chaos und fühlten sich wie kleine Kinder, die einen großen Fehler gemacht hatten. Sie hatten das Unternehmen lahmgelegt und wussten nicht, wie sie die Schäden wieder beheben sollten. Werner versuchte, ruhig zu bleiben, aber in seinem Inneren brodelte es. Er hatte noch nie so etwas erlebt.

Jan schlug vor, einen externen IT-Dienstleister zu rufen. Vielleicht konnten die Experten den Router reparieren oder zumindest einen provisorischen Ersatz besorgen. Werner zögerte. Er wollte nicht, dass jemand von außerhalb von ihrem Fehler erfuhr. Aber er hatte keine andere Wahl.

Während sie auf den Techniker warteten, versuchten sie, die Auswirkungen des Ausfalls so gering wie möglich zu halten. Sie informierten die Geschäftsführung und versicherten ihnen, dass sie alles tun würden, um das Problem so schnell wie möglich zu beheben. Die Geschäftsführung war verständlicherweise nicht begeistert. Sie machten Werner und Jan klar, dass sie für den entstandenen Schaden verantwortlich waren.

Als der Techniker endlich eintraf, machte er sich sofort an die Arbeit. Er untersuchte den defekten Router und schüttelte den Kopf. „Das sieht nicht gut aus“, sagte er. „Der Router ist komplett zerstört. Da ist nichts mehr zu retten.“ Werner und Jan tauschten einen besorgten Blick aus. Sie hatten schon damit gerechnet, aber es tat trotzdem weh zu hören, dass ihr Fehler so schwerwiegende Folgen hatte.

Der Techniker schlug vor, einen neuen Router zu bestellen und einzurichten. Das würde jedoch einige Tage dauern. Bis dahin müsste das Unternehmen mit eingeschränkter Funktionalität auskommen. Werner und Jan wussten, dass sie in den nächsten Tagen viel zu tun haben würden.

**7 Die Konsequenzen**

Die folgenden Tage waren eine einzige Katastrophe. Das Unternehmen stand still. Kundenbeschwerden häuften sich, wichtige Projekte wurden verzögert, und die Stimmung unter den Mitarbeitern war am Boden. Werner und Jan arbeiteten rund um die Uhr, um die Schäden zu begrenzen und eine Lösung zu finden. Sie richteten provisorische Arbeitsstationen ein, um zumindest einen Teil der Arbeit aufrechtzuerhalten. Aber es war ein Tropfen auf den heißen Stein.

Die Geschäftsführung war außer sich vor Wut. Sie machten Werner und Jan für den entstandenen Schaden verantwortlich und drohten mit Konsequenzen. Werner fühlte sich schuldig und niedergeschlagen. Er hatte sein ganzes Berufsleben lang zuverlässig gearbeitet und jetzt hatte er das Unternehmen in eine Krise gestürzt.

Jan versuchte, seinen Kollegen Mut zu machen. Er betonte, dass sie aus diesem Fehler lernen würden und dass sie das Unternehmen wieder aufbauen könnten. Aber auch er war unsicher, ob es ihnen gelingen würde.

Der neue Router wurde schließlich geliefert und installiert. Aber das war nur der erste Schritt. Es dauerte noch mehrere Tage, bis das gesamte Netzwerk wiederhergestellt war und alle Mitarbeiter wieder uneingeschränkt arbeiten konnten. In dieser Zeit entstanden hohe Kosten für die Reparatur und den Verlust von Geschäftsmöglichkeiten.

Als das Unternehmen sich langsam erholte, zogen Werner und Jan Bilanz. Sie hatten eine wichtige Lektion gelernt: Auch erfahrene IT-Experten können Fehler machen. Und die Folgen solcher Fehler können schwerwiegend sein. Sie beschlossen, aus dieser Erfahrung zu lernen und zukünftig noch sorgfältiger zu arbeiten.

Werner entschied sich, seine alten Karteikarten abzuschaffen und auf eine moderne Software zur Netzwerkverwaltung umzusteigen. Jan wurde zum Projektleiter für die IT-Sicherheit ernannt. Er sollte dafür sorgen, dass das Unternehmen in Zukunft besser gegen Cyberangriffe geschützt war.

Die Krise hatte das Unternehmen zwar geschwächt, aber sie hatte auch gezeigt, wie wichtig ein funktionierendes IT-System ist. Und sie hatte Werner und Jan näher zusammengebracht. Sie hatten gemeinsam eine schwere Zeit durchgestanden und waren gestärkt daraus hervorgegangen.

Measuring the security risk of a legacy webbrowser

 

With the qemu software its possible to run outdated operating systems for example Debian 9.13 from july 2020. [1] The standard browser in 2020 is of course EOL, that means, it hasn't received any updates for 4 years. To determine if this browser is secure or not we can run a browseraudit.[2] The result is shown in the screenshot and contains of 413 different test and 0 critical outcomes.[3] The shown skipped tests and warning are produced because of a time lag. That means, the internet connection or the Qemu VM was to slow so that the test failed.

The only question left open is how to interpret the results. From a technical standpoint the outdated webbrowser works fine. It can be used to playback videos, connect to HTTPS websites, show wikipedia and run even games. This makes it hard to define what the difference is between secure and insecure, between valid and invalid.

Before its possible to label a browser as insecure, a test has to proof it including a concrete explanation. In the demonstration this was not the case. The only thing what is obvious is, that the quality of the font renderer in the screenshot is low, but this is caused by the resolution in the qemu VM not because of the underlying Debian OS.

[1] qemu-system-x86_64 -enable-kvm -m 2048 -boot d -vga virtio -cdrom debian-live-9.13.0-amd64-xfce+nonfree.iso

[2] https://browseraudit.com/

[3] screenshot with browseraudit

 

Running outdated software inside a virtual machine

Computing is driven by fast development in software and hardware. Software programmers are creating commits every day, new hardware is announced and shipped every week and each version is incompatible to the previous one. The disadvantage for the customer is, that a new installed software and a new hardware will become obsolete very soon in the future.

On the other hand there is a philosophy available to slow down the development and resist to change. To investigate this delayed strategy in detail we have to describe the situation first from a theoretical standpoint. The years measured on a time line are shown in the figure. The past, for example the year 2016, is shown left, while the now year is shown on the right. At first we investigate if its possible to install an outdated Linux distribution from 8 years ago on a computer and then we are using this software to browse in the internet To realize this technical experiment we are preferring a virtual machine instead of a physical to install Debian 7.11 from June 2016.[1]

The first message shown in the web browser is, that the internet connection is not secure. Something with the SSL certificate is wrong. The message can be deactivated but its a serious information that the browser is outdated.[2]

Next thing to do is to open a major website, which works surprisingly well. The online encyclopedia is rendered in the browser including all the images. Not bad, for an operating system which is 8 years old.[3]

Unfortunately, the largest video website isn't working with the old webbrowser. A message is shown “Your browser isn't supported anymore”. Even after tweaking the settings, the browser won't playback the videos.[4]

A rule of thumb is, that the browser shouldn't be older than 4 years to display all the content from the internet including videos, podcasts and social networking websites. This interval is shown in the time axis together with the other information.

The short experiment with a virtual machine has shown, that software has a short time span. Its impossible to use a webbrowser older than 4 years for any large website in the internet. Even if the user is happy with a certain operating system version, the Internet website requires a recent version, otherwise the service isn't working.

[1] qemu-system-x86_64 -enable-kvm -m 2048 -boot d -vga virtio -cdrom debian-live-7.11.0-amd64-gnome-desktop+nonfree.iso

[2] qemu1.webp

 [3] qemu2.webp

 [4] qemu3.webp

 

Uptime mit Hindernissen

 Es war ein ganz normaler Mittwochmorgen in der IT-Abteilung von MegaCorp, als der frisch gebackene Praktikant Kevin mit einem breiten Grinsen und einem Pappbecher voller Energy Drink durch die Tür stürmte.

"Morgen, Herr Schmidt! Ich hab' da 'ne mega Idee!", rief er dem Sysadmin zu, der gerade in seinem heiligen Karteikasten kramte.

Herr Schmidt, ein Mann mit mehr Dienstjahren als Kevin Lebensjahren, blickte skeptisch über seine Lesebrille. "Guten Morgen, Kevin. Was gibt's denn so Dringendes?"

Kevin hüpfte aufgeregt von einem Bein aufs andere. "Also, ich hab gestern Nacht ein bisschen recherchiert und festgestellt, dass unser WLAN-Router total veraltet ist! Der läuft ja schon seit 500 Tagen ohne Neustart. Stellen Sie sich mal vor, was wir alles verpassen!"

Herr Schmidt zog eine Augenbraue hoch. "Und das ist schlecht, weil...?"

"Na, weil es ein Update gibt! OpenWRT hat 'ne neue Version rausgebracht. Mit der könnten wir bestimmt das Internet um mindestens 5% beschleunigen!"

Der Sysadmin seufzte tief. "Kevin, mein Junge, wenn etwas 500 Tage lang ohne Probleme läuft, fasst man es nicht an. Das ist die goldene Regel der IT."

Aber Kevin ließ nicht locker. Mit der Überzeugungskraft eines Gebrauchtwagenhändlers und der Hartnäckigkeit eines Terriers schaffte er es schließlich, Herrn Schmidt zu überreden.

"Na gut", brummte der Sysadmin, "aber nur, weil heute sowieso kaum jemand im Büro ist. Und du machst das Backup!"

Kevin strahlte wie ein Honigkuchenpferd. "Klar, hab ich schon vorbereitet!"

Gemeinsam machten sie sich an die Arbeit. Kevin tippte wie ein Weltmeister, während Herr Schmidt nervös seine Karteikarten sortierte.

"So, jetzt nur noch neustarten und-" PUFF! Der Bildschirm wurde schwarz.

Stille.

Kevin lachte nervös. "Ups, kleiner Wackelkontakt. Moment..."

Fünf Minuten später: Immer noch schwarz.

Herr Schmidt wurde blass. "Kevin, was hast du getan?"

"Keine Panik! Ich probier' nur kurz was anderes." Kevin hämmerte wild auf der Tastatur herum.

Eine Stunde später war der Router immer noch offline. Kevin schwitzte und murmelte Unverständliches, während Herr Schmidt stoisch in seinen Karteikarten blätterte.

"Ähm, Herr Schmidt? Ich glaube, wir haben ein Problem."

Der Sysadmin schaute auf. "Wir?"

In diesem Moment klingelte das Telefon. Es war der CEO. "Schmidt! Warum zum Teufel funktioniert das Internet nicht?"

Herr Schmidt warf Kevin einen vielsagenden Blick zu. "Tja, Herr Direktor, sagen wir mal so: Unser Praktikant hatte eine 'mega Idee'..."

Als der Arbeitstag zu Ende ging, saß Kevin immer noch vor dem toten Router, umgeben von leeren Energy Drink-Dosen. Herr Schmidt klopfte ihm auf die Schulter.

"Lektion gelernt, mein Junge?"

Kevin nickte kleinlaut.

"Gut. Morgen zeige ich dir, wie man einen Router richtig updated. Und jetzt ab nach Hause – aber nimm den Hinterausgang. Der CEO wartet vorne mit einer Mistgabel."

Während Kevin sich davonschlich, murmelte Herr Schmidt: "500 Tage Uptime. Verdammt, das war ein guter Lauf."

Er zog eine Karteikarte hervor und notierte: "20.11.2024: Praktikanten sind wie Updates. Manchmal bringen sie Fortschritt, meistens Chaos."

Mit einem Schmunzeln steckte er die Karte zurück in den Kasten. Es war Zeit, nach Hause zu gehen und ein Bier zu trinken. Oder zehn.

Der Übereifrige Praktikant

 Markus, ein 22-jähriger Informatikstudent, begann voller Enthusiasmus sein Praktikum bei TechSolutions GmbH. Mit dem neuesten Wissen aus der Uni bewaffnet, war er fest entschlossen, seine Fähigkeiten unter Beweis zu stellen.

An seinem dritten Tag bemerkte er einen OpenWRT-Router mit einer beeindruckenden Uptime von 400 Tagen. Fasziniert wandte er sich an Klaus, den erfahrenen Sysadmin.

"Klaus, hast du gesehen? Der Router läuft seit über einem Jahr ohne Neustart!", rief Markus aufgeregt.

Klaus nickte gelassen. "Ja, das alte Schätzchen. Läuft wie ein Uhrwerk."

Markus runzelte die Stirn. "Aber das bedeutet doch, dass er seit über einem Jahr keine Sicherheitsupdates bekommen hat. Sollten wir nicht dringend updaten?"

Klaus seufzte. "Markus, in der Theorie hast du Recht. Aber dieser Router ist das Herz unseres Netzwerks. Solange er läuft, fassen wir ihn nicht an."

Doch Markus ließ nicht locker. Tagelang bombardierte er Klaus mit Artikeln über Sicherheitslücken und den Vorteilen der neuesten Firmware. Schließlich gab Klaus nach.

"Na gut, du Quälgeist. Heute Abend nach Feierabend können wir es versuchen. Aber ich warne dich, wenn etwas schiefgeht..."

Markus konnte sein Glück kaum fassen. Um 18 Uhr trafen sie sich im Serverraum. Mit zitternden Händen lud Markus die neue Firmware herunter.

"Letzte Chance zum Abbruch", warnte Klaus.

"Alles wird gut!", versicherte Markus und klickte auf "Update starten".

Die Minuten krochen dahin. Der Fortschrittsbalken bewegte sich quälend langsam. Bei 99% hielt Markus den Atem an.

Plötzlich wurde der Bildschirm schwarz.

"Äh, Klaus? Ist das normal?", fragte Markus mit zitternder Stimme.

Klaus' Gesichtsausdruck verhieß nichts Gutes. "Nein, das ist es nicht."

Sie versuchten alles: Neustart, Reset, sogar ein Gebet zum IT-Gott. Nichts half. Der Router blieb stumm.

Um Mitternacht gab Klaus auf. "Das war's, Junge. Der Router ist gebrickt. Morgen früh steht uns ein Höllenritt bevor."

Markus sank in sich zusammen. "Es tut mir so leid, Klaus. Ich wollte doch nur helfen."

Klaus legte ihm die Hand auf die Schulter. "Ich weiß. Aber manchmal ist das Risiko eines Updates größer als der potenzielle Nutzen. Das lernt man mit der Zeit."

Am nächsten Morgen herrschte Chaos. Ohne den zentralen Router lag das halbe Netzwerk lahm. Markus verbrachte den Tag damit, sich bei jedem zu entschuldigen, während Klaus versuchte, eine Notfalllösung zu improvisieren.

Als der Arbeitstag endlich vorbei war, rief der CEO Markus in sein Büro. Mit gesenktem Kopf betrat er den Raum, sicher, dass sein Praktikum vorbei war.

Zu seiner Überraschung lächelte der CEO. "Markus, ich habe gehört, was passiert ist. Es war ein kostspieliger Fehler, aber einer, aus dem wir alle lernen können. Wir werden unsere Update-Prozesse überdenken und einen Notfallplan erstellen. Und du wirst dabei helfen."

Erleichtert und dankbar nickte Markus. Er hatte eine wertvolle Lektion gelernt: In der IT-Welt ist Vorsicht manchmal besser als blinder Fortschrittsglaube.

Introduction into the Froozen release model

 

The term isn't widely used, what might be common instead are rolling release systems like Arch Linux and stable release distributions like Debian. From a technical term, froozen release is equal that the End of life (EOL) is at the same date like deployment of the software.

Let me give an example: A new embedded device is sold on day 1 to the market. And the vendor explains, that the EOL for this product is also on day 1. That means, the product won't receive any updates which includes security fixes and feature improvements.

The question left open is, if such a strategy is a best practice or an anti pattern. There are many real world examples available for froozen release models like Slackware Linux (has no dedicated package manager), FreeBSD (same like Slackware) and very important most existing embedded devices are working as froozen release without mention it explicit.

From a technical standpoint a microcontroller has no update mechanism, because the installed software is a slim down version of an operating system and has no ability to change the software. Mostly the software is stored on ROM chips which can't be modified. The only option to update such embedded device is to replace the hardware physically.

Its a fact that such systems are not the exception but the normal situation in today's IoT landscape, there are billion of such devices available. There are two possible discourse space available to talk about the situation. First assumption is, that computer security is only possible by frequent software updates. This is the Arch Linux philosophy which implies that the system will become more stable with every update. The counter argument is, that froozen release is the here to stay strategy, which means, that existing embedded systems which can't be updated are more stable than Arch Linux and other rolling operating systems.

The mismatch between froozen release and rolling release has to do with the difference between software development and production environment. Software development works with a rolling release model. A certain git repository is modified every day by the programmers, they are editing the source code of the software, introducing new features and removing other parts. These source code repositories are useless for the end user, because he needs only the executable binary file which provides useful functionality. In case of Debian like stable releease management, the gap is solved with a fixed schedule. Every two years, a copy of the source code is made which gets compiled into binary files and deployed to the end user. That means, Debian users won't get any updates between two releases.

In case of a froozen release model, the freeze duration is extended. That means, the production system is static and only the upstream source code is modified. In case of embedded system the software is combined with hardware, that means the only option to get a new software version is to replace the hardware.

The interesting situation is, that its possible to design a froozen release software in a secure way. The developers need an awareness, that no further changes are possible which means, they have to program the software with security in mind and bug free from day 1. That means, the software gets deployed similar to a ROM cartridge in the 1980s. This doesn't mean, that the software is unsafe, but it means simply that a different development model was applied.

Classical AI programming until 2010

Before the advent of large language models, grounded language and interactive Turing machines, there was a different understanding available how to program intelligent computers. This naive paradigm should be explained in detail, because it allows to identify potential bottleneck of outdated Artificial Intelligence research.

Until the year 2010 the shared assumption was, that artificial intelligence is a subdiscipline within existing computer science and could be categorized with established terminology about software, hardware and algorithm design. A practical example was a chess playing artificial intelligence. The typical powerful chess program until 2010 was realized in the C language because of performance reasons, has implemented a powerful alpha beta pruning algorithm, runs on a multicore CPU and was able to figuring out the optimal move by itself.

The only difference between the chess program was which preference was available within this category space, For example, some older chess programs were programmed in pascal in stead of C which was perceived as less efficient, and sometimes a new algorithm was implemented which was able to calculate a larger time horizon into the future. 99% of the chess programs were realized with such a paradigm because it was the only available discourse space how to talk about artificial intelligence and about computer chess in detail.

The reason why a certain chess engine was more powerful than another one was located in improved technology which might be a faster programming language, an improved algorithm, a or a better hardware. All these criteria are located within computer science. Its the same vocabulary used for describing other computer science topics like databases, operating systems, or video games. So we can say, that Artificial intelligence until 2010 was seen as detail problem within computer science which has to do with hardware, software and algorithm design.

Surprisingly, the discourse space has changed drastically after the year 2010. A look into recent papers published from 2010-2024 will show, that a different terminology was introduced for Artificial intelligence research. Performance criteria from the past, like a fast programming language like C or a fast multi core CPU seem to be no longer relevant. Many AI related projects have be realized in Python which is known as a very slow programming language not tailored for number crunching problems. Also, lots of AI papers are introducing multimodal datasets which have nothing to do with computer science at all but they have its origin in statistical computing. So we can say, that AI projects after the year 2010 are trying to overcome the limitation of computer science in favor of external disciplines like computer linguistics, biomechanics and even humanities. Such a shift in focus has introduced many new vocabulary. For example, if a computer is used to create a motion capture dataset of a walking human, a certain bio-mechanical vocabulary is used which has nothing to do with computers.

 

A possible explanation why classical computer science oriented description of AI topics has felt out of fashion is, that it has failed to solve any notable problem. Even for simple games like tictactoe a highly optimized C program won't be able to traverse the state space. And for more advanced problems in robotics kinodynamic planning, a classical focus on programming languages and faster hardware won't solve anything.

Classical computer science which is working with a discourse space of hardware, software and algorithm works only for trivial problems but not for more demanding robotics problems which are always np hard. It seems, that the AI problems itself were the cause why a classical computer oriented discourse space has felt out of fashion and was replaced with a different paradigm which is oriented on non computational requirements. Since the advent of large language models, this new discourse space is equal to chatbot driven AI.

Development time for programming a video game

 

Comparing programming languages is traditional measured in machine performance. The overall question is how small the binary file is, how fast its run on hardware. Sometimes, its asked how well the source code looks, but this depends on individual preferences.

A more practical approach is to compare how long it takes to program the same software in different languages. A rough estimation for coding a pong like videogame including graphics is:

• Assembly language, 14 days
• Forth language, 7 days
• C language, 3 days
• Python, 1 day

Such a table might explain why a certain language is popular while other not. In the 1980s the first two languages on the list were very popular. For many 8bit computers there was no alternative available over Assembly and Forth. Both languages need only a small amount of RAM and are working fine without any hard drive. In the 1990s the C language has become the standard for programming. Not because C is better than Assembly but because it takes a shorter amount of time to write a program. A good starting point to create a pong like video game in C is to use existing graphics libraries like SDL, this allows to finish the project in around 3 days. Since the year 2010 the python programming has become more popular. This might be a surprise from a technical perspective, because Python is known for its slow performance, especially in game development.

Nevertheless, Python allows to create complex software in a smaller amount of time. Finding bugs in a python program is much faster, and the sourcecode is dramatically shorter than the C counterpart. Its not very hard to predict which sort of programming language will replace python in 10 years, which are of course large language model which require only a text prompt as input and can generate the game by itself. This will reduce the time until a new game was programmed further down to hours.

Chronological notetaking with problems

 The easiest way to make notes is to append new information at the end. There is no need to use a ring binder or note cards but a normal notebook works fine. A possible entry would be “date: March 10, headline, body of text”. The note is written down on paper and can be read again forever.

There is a large problem available with such a note taking technique. Chronological notetaking will mess up the notes on the long run. Notes about mathematics will follow notes about history and language. The only sorting order available is the date. This makes it hard to read the notes again. Let me give an example.

Suppose the user has written down over a horizon of 2 weeks multiple notes from different subjects. Now he likes to retrieve all the notes about math. The problem is, that the math notes are distributed over different sections in the notebook. Some math notes are written down on march 10, while other are from march 16 and the notes in between have nothing to do with prime numbers but are from different subjects.

Even if the notes are technically well written its impossible to retrieve them because they aren't sorted by topic but only by date. To sort notes by topic, there is need to use a different principle than only adding notes at the end. Some sort of ring binder or Zettelkasten is needed. With such a tool its possible to add new math notes after the old math notes.

The main advantage is, that its much easier to read the notes again. All the math notes are collected together. The user doesn't has to read the entire notebook, but only the math section. This makes it likely that the notes are consulted multiple times. The disadvantage of ring binders and card catalogs is, that its more demanding to create the notes. Before new notes can be added to the system the correct position has to be located. Which slows down the writing process.

Pipeline for developing chatbot based robotcs

 Since the introduction of large language models in the year 2023, the term "artificial intelligence" was defined very clearly. AI means simply that the user interacts with a chatbot in natural language. The chatbot is able to answer questions, can draw pictures and also the chatbot controls a robot.

From the user perspective, the software works suprisingly easy to explain. The user enters a sentence like "open left hand" and submits the text to the chatbot. The chatbot is parsing the sentence and executes the command, which means that the robot will open indeed the hand. More complex actions like moveing to a table and wash all the dishes are the result of more advanced text prompts which contains a list of sub actions.

The unsolved issue is how to program such advanced chatbots in software. Before a user can talk to a robot this way, somebody has to program the chatbot first which can be realized in C++, Java, and so on. The basic element of any chatbot isn't a certain programming library like nltk and its not a certain operating system like Windows or Unix, but the needed building block is a dataset. Or to be more specific, a dataset which maps language to perception, and language to action.

Such a mapping is realized with multiple column because the dataset is always a table. In the easiest example the table consists of a images in the first column and the nouns in the second column:

[picture1.jpg], apple
[picture2.jpg], banana
[picture3.jpg], table
[picture4.jpg], spoon

The chatbot software is using such a dataset to understand a text prompt from the user. For example if the user types into the textbox "take apple". The word apple is converted into [picture1.jpg] and this picture allows to find the apple with the camera sensor.

More complex interactions like generating entire motion data are provided the same way. A verb like "grasp" is converted into motion capture trajectory with the following table:

[trajectory1.traj], open
[trajectory2.traj], grasp
[trajectory3.traj], standup
[trajectory4.traj], sitdown
[trajectory5.traj], moveto

Let me give a longer example to make the point clear. Suppose the user enters the command "moveto table. grasp apple". This command sequence is converted into:
1. [trajectory5.traj], moveto
2. [picture3.jpg], table
3. [trajectory2.traj], grasp
4. [picture1.jpg], apple

In the next step of the parsing pipeline the given jpeg images and .traj data are converted into search patterns and motion pipelines. This allows to convert a sentence into robot actions.

There are mutiple techniques available how to program a chatbot in detail. Its possible to use ordinary programming languages or more advanced deep neural networks. What these methods have in common is, that they are requiring always a dataset in the background. Somebody has to create a table with pictures with objects, and annotate the pictures. Also a dataset with mocap data is needed. Such a dataset allows a chatbot to convert a short sentence into something meaningful. Meaning is equal to a translation task from a word into a picture, and from a word into a trajectory.

So we can say, that a chatbot is the frontend of an AI while the dataset is the backend.

Einführung in grounded language

 Ins deutsche übersetzt heißt es soviel wie gelenkte Sprache oder strukturierte Sprache. Es geht darum die Realität mit Hilfe eines Fragebogens zu beschreiben um darüber die Maschinenlesbarkeit zu erhöhen. Dazu ein Beispiel:

Angenommen, es soll eine Verkehrszählung durchgeführt werden. Im einfachsten Fall beginnt man ohne größere Vorbereitung und führt eine Strichliste. Die bessere Alternative besteht darin, vor dem Zählen zuerst einmal ein Formblatt zu entwerfen worin Variablen definiert werden, welche beschreiben was genau gezählt wird. Zur Erfassung des Autoverkehrs bieten sich folgende Variablen an:
Fahrtrichtung: von links / von rechts
Autofarbe: schwarz / blau / grün / rot / sonstiges
Fahrzeugtyp: PKW / LKW / Bus / sonstiges
Uhrzeit

Ein solcher Zählbogen ist weitaus detailierter als eine simple Strichliste weil man viele wertvolle Details zum Straßenverkehr erhält. Die o.g. statistischen Variablen sind identisch mit grounded language. Es wird dabei natürliche Sprache so verwendet, dass ein Vektorraum entsteht innerhalb derer dann etwas gezählt wird. Am Ende der Verkehrszählung kann man dann sagen, wieviele rote PKWs von links kamen oder wieviele LKW insgesamt die Straße befahren haben.

Im Bereich Statistik und Soziologie sind solche Erhebungsbögen allgemein bekannt und werden seit Jahrzehnten verwendet. Sie dienen als Hilfsmittel um komplexe Fragestellungen zu strukturieren und zahlenmäßig zu erfassen. Was jedoch neu ist, ist dass mit der selben Methode das Problem der Robotik und Künstlichen Intelligenz maschinenlesbar aufbereitet werden kann.

Im Grunde muss ein Roboter, der sich in einem Labyrinth bewegen soll, nur mit einem Formblatt versehen werden, was grounded language enthält. Über dieses Formblatt kann die Umgebung in einen symbolischen Vektorraum überführt werden, also maschinell-mathematisch gespeichert werden. EIne Kategorie in dem Formblatt wie z.B. "Farbe=blau" kann entweder wahr oder falsch sein. Die Strichliste kann einen Strich enthalten oder eben nicht. Darüber vermag der Roboter ein Protokoll anzulegen und Entscheidungen zu treffen. Das komprimiert den Handlungsraum. Anstatt Sensoren hardwaremäßig abzufragen, hat der Roboter ein konzeptionelles Verständnis der Umgebung. Man erhält einen high level Sensor der die Daten des Fragebogens inkl. der darin verwendeten Sprache verwendet.

Chatbot Evolution in den 2010er Jahren

 Es ist naturgemäß schwierig aktuelle Entwicklungen unter historischen Aspekten zu beleuchten, weil die Menge an Literatur zunimmt je näher man sich der Gegenwart nähert und weil die Strömungen schwerer zu überblicken sind. Anstatt die tatsächliche Gegenwart in Bezug auf Chatbots zu beschreiben welche von 2020 bis heute geht, besteht eine mögliche Alternative darin, etwas weiter zurück zu gehen und nur die 2010'er Jahre zu beschreiben.

Einerseits gab es in den 2010er neu entwickelte Algorithmen im Bereich Machine Learning und Natura language processing um Chatbots an sich zu verbessern.  Es gab darüberhinaus aber noch eine weitere weit weniger offensichtliche Technik und zwar die Einführung von Chatbots benchmarks. Dabei geht es nicht darum, einen chatbot in der Leistung zu erhöhen ihn also menschlicher zu gestalten sondern bei einer chatbot challenge geht es darum, vorhandene Chatbots untereinander in ihrer Leistung nach Punkten zu bewerten. Die Annahme lautet dass jemand anderes bereits mehrere Chatbots programmiert hat und es darum geht diese zu ranken.

Die Entwicklung dieser Chatbot vergleichsbenchmarks sind der eigentliche Grund der Verbesserung der Chatbot technologie. Bevor man neuartige Algorithmen inkl. neuronaler Netze entwickelt muss man zuerst einmal wissen wie vorhandene Konzepte leistungsmäßig abschneiden. Praktisch werden die Benchmarks als Dataset realisiert, was übersetzt soviel wie Datenbasis oder Tabelle bedeutet.  Datasets haben ihren Ursprung im Machine learning wo man zwischen Training dataset und test dataset unterscheidet.

Der Übergang von manuell programmierten Chatbots hin zu Dataset benchmark wird durch den ALICE chatbot (1995) aufgezeigt, der das AIML format verwendete. AIML ist einerseits das Datenformat für den Chatbot aber dient gleichzeitig als Korpus für eine Wissensdatenbank. Wenn man jetzt nur den Datensatz verbessert aber nicht den Chatbot, erhält man einen Chatbot dataset. Wo also die Entwicklung eines Punktesystems im Vordergrund stteht. Andere chatbots haben nun die Aufgabe, in Bezug auf einen konkreten AIML Korpus eine möglichst hohe Punktzahl zu erzielen.

Spätere Chatbot benchmarks basierten nicht länger auf dem AIML format sondern verwendeten csv dateien oder sogar Textdateien. Der Benchmark wurde in Form einer dokumentensammlung bereitgestellt was den Übergang zu Question & Answering systemen darstellt. Die Aufgabe für diese Generation von chatbots bestand darin, Fragen zu einem Dokumentencluster zu beantworten. Auch hierbei gab es Algorithmen, die dabei sehr gut abschneiden und andere denen es weniger gut gelang.

Chatbots bis zum Jahr 2010

 Die Geschichte von Chatbots kann man grob in 2 Phasen einteilen: 1960-2010 und 2010-heute. Die ältere Zeitperiode ist gut dokumentiert und leicht nachvollziehbar. Projekte wie Eliza und Cleverbot wurden programmiert um menschliche Dialoge zu imitieren. Sie basieren auf einem parser, der die Eingabe des menschlichen Benutzers auswertet und einem Satzgenerator der daraufhin eine Antwort erzeugt. In der Interaktion führt das dazu, dass Chatbots einerseits Sätze erzeugen aber gleichzeitig die Schwächen der KI deutlich werden.

Ab Anfang der 2000er Jahre gab es in der Chatbot Technologie eine Neuerung und zwar das AIML Dateiformat. Darin können Frage / Antwort Paare außerhalb des eigentlichen Quellcodes abgelegt werden. Man muss also einerseits die Chatbot software programmieren und dann noch eine AIML Wissensdatenbank erstellen die eine normale Datenbank ist. Aber, auch mit AIML ist die Leistungsfähigkeit der erzeugten Chatbots nicht besonders hoch. Es ist nur leichter diese zu programmieren.

Ab dem Jahr 2010 gab es in der Chatbot Entwicklung eine massive Verbesserung. Diese hatte nur indirekt etwas mit Maschine Learning zu tun sondern die Veränderung bestand darin, zunächst einmal das Problem zu definieren um das es geht. Bis 2010 war die implizite Annahme es geht darum einen Chatbot zu programmieren, also eine Computersoftware die auf Sprache reagiert. Nur, das ist nicht das eigentliche Problem. Worum es wirklich geht ist das Question answering Problem zu lösen. Als Q&A challenge bzw. als Q&A dataset wird eine Tabelle mit Quizfragen bezeichnet die ein Mensch oder ein Computer richtig beantworten muss. Es geht also eben nicht um die innere Funktionsweise einer künstliche Intelligenz sondern es geht um eine Wissensspiel ähnlich wie Trivial Pursuit, Jeopardy usw.

Bevor man einen Chatbot programmieren kann muss man zunächst einmal eine Aufgabe programmieren die dieser Bot lösen soll. Also eine Art von Computerspiel ähnlich wie Tetris, Pong usw. Allerdings geht es bei diesem Spiel anders als bei Arcade spielen nicht um schnelle Reaktionsfähigkeiten sondern um das Verstehen von Sprache. Daher auch die Bezeichnung Question&Answering challenge. Dieses Spiel funktioniert so: dem Spieler wird eine Frage präsentiert, z.B. "Was ist 5+2?" und der Spieler muss antworten "7". Eine weitere Frage könnte lauten "Welcher Kontient ist der trockenste und heißeste der Welt?" Antwort: Afrika.

Für ein Quizspiel spielt es keine Rolle ob jemand darin gut abschneidet oder schlecht. Und ob jemand das Spiel als Mensch löst, als Computerprogram oder als neuronales Netz. Sondern ein Quizspiel ist nur ein formalisiertes Problem. Es besteht aus einer Anzahl von quizfragen aus unterschiedlichen Bereichen und es gibt Antworten auf jede Frage die geheim sind für die Kandidaten. Jetzt kann der Quizmaster ermitteln wieviele Antworten ein Kandidat richtig beantwortet.

Das besondere an Q&A challenges ist dass man damit die Performance von Computersystemen bestimmen kann. Man kann unterschiedliche AI Algorithmen entwerfen die die Fragen beantworten und dann lässst sich sagen, welcher Ansatz besser war. Q&A challenges sind die Grundlage um fortschrittliche Chatbots zu entwickeln. Ein chatbot ist schlichtweg eine Software, die in einer Q&A challenge besonders gut abschneidet.

Mit diesem Hintergrundwissen lässt sich besser herausarbeiten was der Unterschied ist zwischen den Chatbots bis 2010 und jenen die danach entwickelt wurden. Chatbots vor 2010 wie Eliza wurden nicht mit Punkten bewertet. Die Software hat zwar einen Dialog geführt aber es gab keine Punktzahl über die Qualität der Ausgaben. Bei neueren Bots wie IBM Watson gibt es eine solche Bewertung. Eben weil neuere Chatbots als Antwortgeneratoren für Q&A Challenges entwickelt wurden.

Um einen neuen Chatbot zu programmieren benötigt man keine besonderen Algorithmen aus dem Bereich sondern benötigt wird ein conversational dataset. Also eine Tablele mit Frage/Antwort Paaren aus dem Bereich smalltalk.  Dieser Dataset wird als Benchmark und als Problemdefinition verwendet. Der Dataset ist eine Art von Small talk spiel und im zweiten Schritt kann man ein Computerprogramm erstellen, dass dieses Spiel spielt. Im wesentlichen geht es also darum zu unterscheiden zwischen einer Aufgabenstellung (dem Q&A Dataset) einerseits und einem Teilnehmer (dem chatbot) der innerhalb des Spiels aktionen ausführt.

Obsolete technische Erfindungen

 Technischen Fortschritt direkt zu messen ist niccht möglich, weil unklar ist was die Zukunft bringen wird. Was man aus Technikhistorischer Perspektive jedoch weitaus besser untersuchen kann sind Dinge die es heute nicht mehr gibt. Also Erfindungen die durch etwas besseres ersetzt wurden wie z.B. die 3.5 Floppy disk, Telefonzellen oder die mechanische Schreibmaschine.

Diese Dinge waren in ihrer jeweiligen Zeit mehr als nur Kuriositäten von verschrobenen Wissenschaftlern, sondern es gab große Unternehmen die die Produkte hergestellt haben und Millionen von Menschen die das benutzt haben. Die 3.5 Floppydisk beispielsweise gab es früher überall zu kaufen, sie war das universale Speichermedium in den 1990er Jahren. Und zwar für die Heimcomputer wie auch die PCs gleichermaßen. Es war also eine Art von Industriestandard. Heute hingegen ist diese Technologie komplett verschwunden, es gibt lediglich noch alte Bücher darüber und natürlich Technikmuseen wo das Medium neben einer 5.25 Zoll Floppy und der Lochkarte ausgestellt ist, die ebenfalls verschwunden ist aus der öffentlichen Wahrnehmung.

Je schneller die Welt voranschreitet, desto zahlreicher sind die Erfindungen die obsolet werden. Die meisten Erfindungen waren relativ fortschrittlich wurden aber durch bessere Erfindungen verdrängt. z.B. waren dampfgetriebene Schaufelradschiffe zu ihrer Zeit das beste Transportmittel um Flüsse in den USA zu befahren. Allerdings gilt die Technologie heute als veraltet. Selbst sehr alte Schiffe werden mit Diesel angetrieben und nicht länger mit Kohlekraft. Demnach wurde eine frühere Kraftquelle durch eine neuere ersetzt. So ähnlich ist es auch mit dem Commodore 64 Heimcomputer der in den 1980er millionenfach verwendet wurde, heute hingegen verschwunden ist und nur noch als Nostalgie-Computer weiterlebt. Die Chance ist groß dass viele der heutigen Dinge wie z.B. Benzin getriebene Autos irgendwann in ferner Zukunft durch andere / bessere Technologien ersetzt werden.

Produkte im Bereich Computertechnologie veralten besonders schnell. So sind frühere Betriebssysteme wie OS/2 oder Windows NT heute nur noch im Museum zu finden. Und neu eingeführte Software wie z.B. eine Linux Distribution wird bereits in der Auslieferung mit einem Verfallsdatum von 3 Jahren versehen. Danach werden die Benutzer aufgefordert auf die Nachfolgeversion zu wechseln. Nach der Selbstwahrnehmung der Programmierer ist die kontinuierliche Weiterentwicklung von Software sogar eine best practice methode damit immer alle wichtigen Anforderungen erfüllt werden.

Das State space Problem innerhalb der Robotik

 Bis zum Jahr 2010 war das Forschungsgebiet der Robotik leicht zu überschauen weil es zwischen Anspruch und Wirklichkeit einen unüberwindlichen Graben gab. Der Ausgang von dezidierten KI und Robotikforschungsprojekten zu dieser Zeit konnte man mit einem simplen Wort beschreiben: Scheitern. Egal ob die Forscher versuchen 4 beinige Laufroboter zu programmieren, eine Roboterhand die einen Apfel greifen sollte oder auch nur eine ingame AI die in einem Computerspiel Punkte sammelt, kamen die Forscher mit den vorhandenen Methoden niemals zum Ziel. Konkret hieß dass, dass es zwar möglich war, die Roboterhardware zu bauen aber es fehlte dann an einer Software die die Bewegung erzeugte. Auch gelang es zwar Computerspiele selber zu erstellen, inkl. 3d Grafik und Soundausgabe, aber sobald eine AI innerhalb eines Spiels benötigt wurde, gab es dafür weder Algorithmen noch Bibliotheken.

Im wesentlcihen scheiterte die Entwicklung an einem Phänomen, dass bereits James Lighthill im Jahr 1973 beschrieben hat und zwar die kombinatorische Explosion. Selbst eine simple Roboterhand die einfach nur ein Objekt greifen soll hat bereits Millionen von Millionen unterschiedliche Servomotor Einstellungen und selbst Supercomputer sind nicht im Stande diesen Gametree in Echtzeit zu durchsuchen. Laienhaft ausgedrückt ist es unmöglich eine Software zu entwickeln die Roboter autonom steuert.

Obwohl diese Feststellung nicht dezidiert in jedem Einzelnen Paper zu Robotik beeschrieben wurde, war es doch die gemeinsame Ansicht zur damaligen Zeit. Jedenfalls gibt es vor 2010 kein einziges Paper in dem erläutert wird, wie man das P=NP problem oder die kombinatorische Explosion lösen könnte, also muss man unterstellen, dass damals das Problem ungelöst blieb. Und das bedeutete, dass die Gesammte KI Community im Grunde nur Fehlschläge, Rückschläge oder nicht eingelöste Versprechungen produzierte. Ganz im Gegensatz zur restlichen Informatik die im Bereich Hardwareentwicklung, Entwicklung neuer Programmiersprachen oder Netzwerk-Protokolle laufend Fortschritte feierte. Mit der normalen Nicht-KI Informatik konnte man immerhin das Internet betreiben und Anwendersoftware programmieren, während die KI Sparte keine praktische Relevanz hatte.

Die einzige Ausnahme bis zum Jahr 2010 wo Künstliche Intelligenz einen Teilerfolg vermelden konnte war Computerschach. Die Bewältigung dieses Brettspiels mit Hilfe von Computer war ein wiederkehrendes Thema seit den 1960er Jahren und im Laufe der Jahre wurden Computer darin immer besser. In 2010 waren selbst Desktop PCs im Stande den amtierenden Menschlichen Großmeister klar und wiederholbar zu besiegen. Allerdings gab es mit dieser technischen Leistung mehrere Probleme: erstens, war der rechenaufwand dafür hoch, typische Schachprogramme haben alle Kerne einer CPU auf 100% ausgelastet und selbst dann mussten sie mehrere minunten Rechnen um den nächsten Zug zu ermitteln, und zweitens ließen sich Schachalgorithmen nicht auf andere Probleme wie der Robotik übertragen. Das heißt, die Schach AI konnte nur schach spielen und sonst gar nichts.

Selbst geringfügig andere Brettspiele wie Backgammon oder Go waren bereits extrem schwierig für eine Schach-KI zu meistern. Man musste den kompletten Quellcode umschreiben und selbst dann war ungewiss ob es gelang menschliche Spieler zu besiegen. Insofern waren schachspielende Computer eher ein Beweis dafür, dass KI nicht realisierbar war.

Obwohl KI bis 2010 utopisch war, haben die Forscher weiterhin die Thematik untrsucht. Und zwar mit einer modifizierten Fragestellung. Wenn es offenbar nicht möglich war, Roboter zu programmieren, wollte man wenigstens wissen woran es genau scheitert. Das führte dazu dass sich die Richtung der Forschung änderte. Anstatt Roboter zu programmieren hat man zunächst versucht, in der Simulation Roboter zu steuern. Wo es also keine Hardware gibt sondern nur eine virtuelle Realität und wo die Aktionsmöglichkeiten des Roboters kleiner sind. Weiterhin wurde besonders von 2000 bis 2010 stark das Gebiet des Deep learning erforscht. Man glaubte durch ein besseres Verständnis von neuronalen Netzen vielleicht etwas über Künstliche Intleligenz im Allgemeinen zu verstehen. Eine weitere Antwort auf gescheiterte KI Projekte war die Fokussierung auf synthetische Probleme wie Robocup oder Micromouse. Damit wurde der Schwierigkeitsgrad gesenkt was bedeutete die Chance auf Erfolg zu erhöhen.

Speziell der Micromouse Wettbewerb ist aus technischer Sicht ein überschaubares Problem. Es gibt nur einen simplen Roboter der nochdazu Räder, und dieser muss einen Weg finden wobei man auf einen Blick sieht ob dieser Weg zum Ziel führt oder nicht. Selbst wenn der Roboter zufällig im Labyrinth herumfährt, wird er irgendwann von ganz allein am Ziel ankommen.

Auch die beschriebenen veränderten Fragestellungen wie synthetische Probleme, Deep Learning und Simulationen vermochten nicht das Problem der kombinatorischen Explosion zu lösen. Selbst bei einem simplen Maze roboter enthält der gametree mehrere Millonen möglicher Systemzustände. Dieses eine Problem des übergroßen Suchbaumes ist der rote Faden der seit den 1950er Jahren verhinderte, dass Robotik und Künstliche Intelligenz realisiert werden konnte. In der theoretischen informatik wird es manchmal als P=NP Problem bezeichnet und gilt nach übereinstimmender Aussage als unlösbar.

Selbstverständlich gab es auch vor 2010 ernstgemeinte Versuche trotzdem Algorithmen zu entwerfen die dezidierte np harte Probleme lösen können. Nur die Ansätze waren unausgereift und verfolgten sehr unterschiedliche Ansätze, es gab beispielsweise Rapidly exploring random tree algorithmen, heuristische Algorithmen, Bewertungsfunktionen, reinforcement learning, probabilistische Suchalgorithmen oder simulated annealing. In manchen Fällen wie dem traveling salesman problem oder dem 15 puzzle problem lässt sich damit tatsächlich eine Lösung finden. In diesem Fall muss der Spielbaum nicht komplett traversiert werden, sondern heuristische Algorithmen finden die optimale Route zum Ziel sehr viel effizienter. Das Problem war jedoch, dass sich diese Verfahren nicht verallgemeinern ließen und das es keine generalierten Lösungen gab die auf mehrere Probleme insbesondere im Bereich Robotik anwendbar waren.

Das einzige was bis 2010 halbwegs zuverlässig funktionierte waren Pfadplanungsalgorithmen mit einer Evaluationsfunktion, also A* und ähnliche Verfahren. Diese wurden sowohl in Computerspielen als auch in der Robotik eingesetzt um auf einer 2d Karte den kürzesten Weg zu planen. Nur A* ist für die Planung einer Roboter hand nutzlos und kann auch nicht für biped walking eingesetzt werden.

Man kann die Kernproblematik der Robotik vor 2010 in einem simplen Satz zusammenfassen: "Mit welchem Algorithmus lässt sich ein sehr großer Zustandsraum schnell durchsuchen?" Schon die Frage offenbart, dass das Problem quasi unlösbar ist. Einerseits gibt es einen Zustandsraum, der aus Millionen von States besteht, gleichzeitig soll dieser Zustandsraum in kurzer Zeit also in realtime durchwandert werden. Dies schließt sich gegenseitig aus. Es gibt mehrere Paper aus der theoretischen Informatik die sogar mathematisch begründen dass so ein Algorithmus unmöglich existieren kann. Im Grunde läuft es auf das altbekannte P=NP Problem hinaus, also der Fragestellung wie man komplexe Probleme auf einem langsamen Computer lösen will.

Die Antwort auf die Probleme ist banal. Keineswegs bedarf es Quantencomputer um np harte Probleme zu lösen, sondern es reicht aus die Prioritäten zu verschieben. Bei einem Schachcomputer fokussiert man auf die Bewertungsfunktion und vernachlässigt die Suche im Gametree. Im Extremfall nutzt man eine optimierte Bewertungsfunktion die auf die Nachkommastelle genau ermittelt ob Weiß oder Schwarz im Vorteil ist und senkt den Suchhorizont ab auf 1 Zug in die Zukunft. Wenn man dann beschreibt, wie sich Bewertungsfunktionen im Allgemeinen mittels Feature engineering erzeugen lassen lässt sich das Paradigma auf andere Aufgaben aus der Robotik ausdehnen und man erhält eine mächtige Methode zur Lösung komplexer Optimierungsaufgaben.

Eine moderne KI die Schach spielen kann besteht weniger darin, irgendwelche neue Algorithmen zu entwickeln sondern als modern gilt eine Chess engine dann, wenn sie bestimmte Dinge einfach weglässt. Im einfachsten Fall nehme man einfach einen Schachcomputer aus den 1980er der durchschnittlich Schach spielt, deaktiviert dort die Suche im Spielbaum und lässt die vorhandene Bewertungsfunktion als einziges Softwareelement aktiviert. Und schon erhält man eine erstaunlich Leistungsfähiges Beispiel für eine heuristisches KI die in der Lage ist, die aktuelle Spielsituation in eine Punktzahl überführen.

Der Zeitreisende im Reality TV

 Die Bewohner des Hauses saßen gerade gemütlich im Wohnzimmer, als plötzlich die Stimme der Projektleitung ertönte: "Achtung, liebe Hausbewohner! Wir haben eine besondere Überraschung für euch. In wenigen Augenblicken wird ein neuer Mitbewohner zu euch stoßen. Bitte empfangt ihn herzlich!"

Die Spannung im Raum war förmlich greifbar. Mia, eine der Teilnehmerinnen, flüsterte aufgeregt: "Oh mein Gott, wer das wohl sein wird?" Kaum hatte sie den Satz beendet, öffnete sich die Eingangstür.

Herein trat ein Mann in einem altmodischen Anzug, mit Hut und einer ledernen Aktentasche. Er blickte sich verwirrt um und stammelte: "Wo... wo bin ich hier gelandet?"

Die Bewohner starrten ihn fassungslos an. Tom, der Sportler der Gruppe, fand als Erster seine Sprache wieder: "Ähm, willkommen in unserem Haus. Wer bist du denn?"

Der Neuankömmling zog seinen Hut und verbeugte sich leicht: "Gestatten, mein Name ist Herbert Schmidt. Ich komme aus dem Jahr 1950 und wurde hierher... nun ja, teleportiert, wie man mir sagte."

Ein ungläubiges Raunen ging durch den Raum. Sarah, die Studentin, prustete los: "Das ist doch ein Scherz, oder? Versteckte Kamera?"

Herbert schüttelte ernst den Kopf: "Nein, meine Dame, das ist kein Scherz. Ich bin genauso verwirrt wie Sie. Eben noch war ich in meinem Büro in Berlin, und plötzlich stehe ich hier."

Die Projektleitung meldete sich erneut: "Liebe Bewohner, Herbert sagt die Wahrheit. Er ist tatsächlich ein Zeitreisender aus dem Jahr 1950 und wird für die nächste Zeit mit euch im Haus leben. Bitte helft ihm, sich in unserer Zeit zurechtzufinden."

Die Gesichter der Bewohner spiegelten eine Mischung aus Unglaube, Faszination und Neugier wider. Lena, die Krankenschwester, trat vor und reichte Herbert die Hand: "Nun, Herbert, willkommen in der Zukunft! Das wird sicher eine interessante Zeit für uns alle."

Herbert ergriff dankbar ihre Hand: "Vielen Dank, gnädiges Fräulein. Ich muss gestehen, ich bin völlig überwältigt von all dem hier." Er deutete auf die moderne Einrichtung und die technischen Geräte.

Die anfängliche Verwirrung wich langsam einer gespannten Erwartung. Die Bewohner begannen, Herbert mit Fragen zu bombardieren, während dieser staunend die für ihn futuristische Umgebung betrachtete. Die nächsten Minuten versprachen, äußerst interessant zu werden.

Nachdem der erste Schock überwunden war, schlug Tom vor: "Lasst uns doch eine richtige Vorstellungsrunde machen. Herbert, möchtest du anfangen?"

Herbert nickte dankbar. "Sehr gerne. Wie gesagt, ich bin Herbert Schmidt, 35 Jahre alt - oder besser gesagt, ich war 35 im Jahr 1950. Ich arbeite als Buchhalter in einem mittelständischen Unternehmen in Berlin."

Sarah konnte ihre Neugier kaum zügeln: "Wahnsinn! Wie war das Leben damals? Hattet ihr schon Fernsehen?"

Herbert lächelte. "Fernsehen war gerade erst im Kommen. Die meisten hörten noch Radio. Aber sagt, was sind das für merkwürdige Geräte, die ihr alle in der Hand haltet?"

Mia hielt ihr Smartphone hoch. "Das? Das ist ein Smartphone. Damit können wir telefonieren, Nachrichten schreiben, im Internet surfen..."

"Internet? Was ist das?", unterbrach Herbert verwirrt.

Tom lachte. "Oh Mann, da haben wir einiges zu erklären. Das Internet ist wie... wie eine riesige Bibliothek, aber digital. Du kannst darüber auf fast alle Informationen der Welt zugreifen."

Herberts Augen weiteten sich. "Unglaublich! Und jeder hat Zugang dazu?"

Lena nickte. "Ja, die meisten Menschen hier haben ständig Zugang zum Internet. Es hat unser Leben komplett verändert."

"Apropos verändert", mischte sich Sarah ein. "Herbert, was denkst du über unsere Kleidung? Muss ja ein Schock für dich sein."

Herbert räusperte sich verlegen. "Nun ja, es ist... gewöhnungsbedürftig. Bei uns tragen die Damen noch längere Röcke und die Herren Hüte auf der Straße."

"Oh, Hüte sind wieder total in Mode!", rief Mia begeistert. "Vintage ist der letzte Schrei!"

Herbert sah sie verwirrt an. "Vintage?"

Tom erklärte lachend: "Das bedeutet, dass alte Sachen wieder modern sind. Dein Stil könnte hier richtig gut ankommen!"

"Interessant", murmelte Herbert. "Und wie steht es um die Politik? Wer regiert Deutschland?"

Die anderen tauschten Blicke aus. Lena antwortete vorsichtig: "Das ist eine lange Geschichte. Vielleicht fangen wir mit etwas Einfacherem an. Möchtest du einen Kaffee?"

"Oh ja, sehr gerne", sagte Herbert erleichtert. "Wenigstens etwas Vertrautes."

Als Lena in die Küche ging, flüsterte Sarah den anderen zu: "Leute, wir müssen vorsichtig sein. Die Welt hat sich so sehr verändert, wir dürfen ihn nicht überfordern."

Tom nickte. "Stimmt. Lass uns die Dinge langsam angehen. Herbert", er wandte sich dem Zeitreisenden zu, "erzähl uns doch mehr von deinem Alltag in den 50ern. Wir sind sehr gespannt!"

Mit einer dampfenden Tasse Kaffee in der Hand begann Herbert, das Haus genauer zu erkunden. Sein Blick fiel auf den großen Flachbildfernseher an der Wand. "Meine Güte, ist das ein Fernseher? Er ist ja riesig und so dünn!"

Tom grinste. "Ja, das ist unser Fernseher. Warte, bis du siehst, was er alles kann." Er nahm die Fernbedienung und schaltete das Gerät ein.

Herberts Augen weiteten sich, als er die gestochen scharfen Bilder sah. "Unglaublich! Und in Farbe! Bei uns waren die ersten Fernsehgeräte gerade erst auf den Markt gekommen, mit winzigen schwarz-weißen Bildschirmen."

Sarah nutzte die Gelegenheit: "Schau mal, Herbert, das hier ist eine Spielekonsole. Damit können wir Videospiele auf dem Fernseher spielen."

"Videospiele? Was ist das?", fragte Herbert verwirrt.

"Lass es mich dir zeigen", sagte Sarah begeistert und startete ein Rennspiel.

Herbert beobachtete fasziniert, wie Sarah das virtuelle Auto steuerte. "Das ist ja wie Zauberei! Ihr könnt tatsächlich diese... Dinge auf dem Bildschirm steuern?"

Währenddessen war Mia in die Küche gegangen und rief: "Hey Herbert, möchtest du sehen, wie wir heutzutage Kaffee machen?"

Herbert folgte ihr neugierig. Als Mia den Kaffeevollautomaten anstellte, zuckte er zusammen. "Was ist das für ein Geräusch? Und woher kommt der Kaffee so schnell?"

Mia lachte. "Das ist unsere Kaffeemaschine. Sie mahlt die Bohnen frisch und brüht den Kaffee in Sekundenschnelle."

"Fantastisch", murmelte Herbert. "Und was ist das?", fragte er, auf die Mikrowelle deutend.

"Oh, das ist eine Mikrowelle", erklärte Lena. "Damit können wir Essen schnell erhitzen. Schau her." Sie stellte eine Tasse Wasser hinein und drückte auf Start.

Herbert sprang zurück, als das Gerät zu summen begann. "Vorsicht! Ist das nicht gefährlich?"

Tom beruhigte ihn: "Keine Sorge, das ist völlig sicher. Sieh, das Wasser ist jetzt heiß."

Herbert schüttelte ungläubig den Kopf. "Es ist, als wäre ich in einem Science-Fiction-Roman gelandet."

Plötzlich klingelte Sarahs Smartphone. Herbert zuckte zusammen. "Was ist das für ein Geräusch?"

Sarah zeigte ihm ihr Handy. "Das ist mein Telefon. Es ist tragbar und kann viel mehr als nur telefonieren."

Herbert betrachtete das Gerät ehrfürchtig. "Darf ich es einmal anfassen?"

"Natürlich", sagte Sarah und reichte es ihm.

Herbert drehte das Smartphone vorsichtig in seinen Händen. "Es ist so leicht und dünn. Wie funktioniert es ohne Kabel?"

Die anderen lachten freundlich. Lena legte Herbert sanft eine Hand auf die Schulter. "Das ist eine längere Geschichte. Wie wäre es, wenn wir uns alle zusammensetzen und dir nach und nach erklären, wie die Welt sich verändert hat?"

Herbert nickte dankbar. "Ja, das wäre wunderbar. Ich habe das Gefühl, ich habe eine Menge zu lernen."

## 4. Beginn der Integration (20:30 - 20:40 Uhr)

Die Gruppe versammelte sich um den Esstisch, wo Lena ein paar moderne Snacks vorbereitet hatte. Herbert betrachtete die bunten Chips und Energyriegel skeptisch.

"Was sind das für seltsame Speisen?", fragte er vorsichtig.

Mia lachte. "Das sind Snacks, Herbert. Probier mal die Chips hier, die schmecken nach Paprika."

Herbert nahm zögernd einen Chip und biss hinein. Seine Augen weiteten sich überrascht. "Das ist ja interessant! Knusprig und würzig zugleich."

Tom reichte ihm eine Flasche. "Hier, probier mal. Das ist Cola – gab's die schon in den 50ern?"

Herbert nickte. "Ja, Cola kannten wir schon. Aber sie war nicht so... alltäglich." Er nahm einen Schluck und hustete leicht. "Oh, sie ist ja viel süßer als ich sie in Erinnerung habe!"

Sarah nutzte die Gelegenheit, um mehr über Herberts Zeit zu erfahren. "Erzähl uns doch mal, was habt ihr in deiner Zeit so gegessen?"

Herbert lächelte nostalgisch. "Nun, wir aßen viel Hausmannskost. Kartoffeln, Gemüse aus dem eigenen Garten, sonntags gab es Braten. Fertiggerichte kannten wir kaum."

"Apropos Fertiggerichte", sagte Lena und holte eine Packung aus dem Schrank. "Schau mal, heute können wir ganze Mahlzeiten in Minuten zubereiten."

Herbert las das Etikett und schüttelte ungläubig den Kopf. "Erstaunlich. Aber sagt, wie steht es um die Arbeitswelt? Hat sich da auch so viel verändert?"

Tom nickte eifrig. "Oh ja! Viele von uns arbeiten heute am Computer, manche sogar von zu Hause aus."

"Computer? Zu Hause arbeiten? Das klingt ja revolutionär!", staunte Herbert.

Mia ergänzte: "Und Frauen sind heutzutage in fast allen Berufen tätig. Wir haben sogar eine Bundeskanzlerin!"

Herberts Kinnlade fiel herunter. "Eine Frau an der Spitze der Regierung? Das ist ja... unglaublich fortschrittlich!"

Sarah bemerkte Herberts überwältigten Gesichtsausdruck. "Ist alles okay, Herbert? Wir können eine Pause machen, wenn es zu viel wird."

Herbert schüttelte den Kopf und lächelte tapfer. "Nein, nein, es ist faszinierend. Bitte erzählt mehr. Wie verbringt ihr eure Freizeit?"

"Oh, da gibt es so viel!", rief Mia begeistert. "Wir schauen Serien auf Netflix, spielen Videospiele, surfen im Internet..."

Herbert hob die Hände. "Moment, moment! Netflix? Surfen? Ihr müsst mir das alles erklären."

Die anderen lachten herzlich. Tom klopfte Herbert auf die Schulter. "Keine Sorge, wir haben Zeit. Wir bringen dich schon auf den neuesten Stand."

Lena hob ihr Glas. "Lasst uns darauf anstoßen! Auf neue Freundschaften und spannende Entdeckungen!"

Alle stießen an, auch Herbert, der trotz seiner Verwirrung ein warmes Lächeln zeigte. "Ich danke euch für eure Geduld. Ich habe das Gefühl, das wird eine äußerst lehrreiche Zeit für mich."

Die Gruppe nickte zustimmend, und es war klar, dass Herberts Anwesenheit nicht nur für ihn, sondern für alle eine einzigartige Erfahrung werden würde.

Reality TV Wochenaufgabe Roboter zusammenbauen

 

Die Stimmung im Haus des TV-Experiments war an diesem Nachmittag spürbar angespannt. Kaum zehn Minuten vergingen, in denen die Kandidaten nicht über die allgegenwärtige Präsenz der Kameras diskutierten. Sarah, eine 28-jährige Grafikdesignerin, lehnte sich frustriert gegen die Küchenzeile und seufzte: "Ich fühle mich wie ein Tier im Zoo. Egal wohin ich gehe, diese Linsen verfolgen mich."

Ihr Unbehagen fand schnell Widerhall bei den anderen Bewohnern. Tom, ein sonst eher zurückhaltender Informatikstudent, platzte förmlich heraus: "Es ist, als ob wir keine Privatsphäre mehr hätten. Selbst beim Zähneputzen fühle ich mich beobachtet!" Die anderen nickten zustimmend, während sie nervös den Raum nach versteckten Kameras absuchten.

Lisa, eine erfahrene Psychologin, versuchte die Situation zu analysieren: "Was wir hier erleben, ist ein klassischer Fall von Kontrollverlust. Unser Gehirn ist ständig in Alarmbereitschaft, weil wir nie wissen, wann wir gerade gefilmt werden." Ihre Worte schienen die Gruppe kurzzeitig zu beruhigen, doch das Gefühl des Unwohlseins blieb spürbar.

Die Kandidaten begannen, kreative Wege zu finden, um zumindest die Illusion von Privatsphäre zu schaffen. Marco, ein findiger Mechaniker, schlug vor: "Vielleicht können wir in den Ecken des Wohnzimmers eine Art Sichtschutz aufbauen? Nur für ein paar Stunden am Tag?" Die Idee wurde jedoch schnell verworfen, da sie gegen die Regeln des Experiments verstoßen würde.

Stattdessen entwickelten die Bewohner eine Art Geheimsprache aus Gesten und Blicken, um sich ohne Worte zu verständigen. "Wenn ich zweimal mit der linken Hand winke, bedeutet das, dass ich ungestört reden möchte", erklärte Emma, eine quirlige Friseurin, den anderen. Dieses neue Kommunikationssystem brachte zumindest ein wenig Erleichterung in die angespannte Atmosphäre.

Doch die Realität der ständigen Überwachung ließ sich nicht lange verdrängen. Als Alex versuchte, sich in einer vermeintlich kamerafreien Ecke umzuziehen, ertönte prompt die Stimme aus dem Lautsprecher: "Alex, bitte nutze für den Kleidungswechsel den dafür vorgesehenen Bereich." Frustriert warf er sein T-Shirt auf den Boden und rief: "Kann man hier nicht mal fünf Minuten für sich haben?"

Die Gruppe versammelte sich daraufhin im Garten, in der Hoffnung, dort etwas mehr Freiheit zu finden. Doch selbst hier fühlten sie sich wie auf einem Präsentierteller. "Ich frage mich, ob die Zuschauer da draußen überhaupt verstehen, wie es sich anfühlt, 24/7 unter Beobachtung zu stehen", sinnierte Sarah, während sie nervös mit einem Grashalm spielte.

Trotz des Unbehagens war allen Bewohnern klar, dass sie sich auf diese Situation eingelassen hatten. Tom fasste es schließlich zusammen: "Wir wussten, worauf wir uns einlassen. Aber zu wissen und zu erleben sind zwei verschiedene Paar Schuhe. Jetzt müssen wir eben das Beste daraus machen."

Mit dieser Erkenntnis kehrte langsam wieder etwas Ruhe ein. Die Kandidaten beschlossen, sich auf die bevorstehende Wochenaufgabe zu konzentrieren, in der Hoffnung, dass die technische Herausforderung sie zumindest zeitweise von dem Gefühl der ständigen Beobachtung ablenken würde.

Die Anspannung im Haus war förmlich greifbar, als die Bewohner sich im Wohnzimmer versammelten, um die neue Wochenaufgabe zu erfahren. Die Stimme aus dem Lautsprecher verkündete: "Eure Aufgabe diese Woche: Baut und programmiert einen Linienfolge-Roboter!"

Stille. Dann ein kollektives "Was?!"

Marco, der Mechaniker, war der Erste, der seine Fassung wiederfand. "Okay, das klingt... interessant. Hat irgendjemand von euch schon mal so etwas gemacht?"

Kopfschütteln in der Runde. Sarah, die Grafikdesignerin, lachte nervös. "Ich kann kaum mein Smartphone bedienen, geschweige denn einen Roboter bauen!"

Tom, der Informatikstudent, kratzte sich nachdenklich am Kopf. "Ich habe zwar schon programmiert, aber noch nie mit Hardware gearbeitet. Das wird eine Herausforderung."

In diesem Moment öffnete sich eine Luke in der Wand, und ein Tablett mit verschiedenen Materialien fuhr heraus. Arduino-Boards, Sensoren, Motoren, Kabel und allerlei elektronische Bauteile lagen vor ihnen.

Lisa, die Psychologin, nahm ein Arduino-Board in die Hand und drehte es vorsichtig. "Es sieht aus wie ein kleiner Computer. Aber wie bringen wir das zum Laufen?"

Alex griff nach der beigelegten Anleitung und überflog sie. "Hier steht, wir müssen zuerst ein Chassis bauen, dann die Elektronik installieren und am Ende alles programmieren."

Emma, die Friseurin, wirkte plötzlich ganz aufgeregt. "Das klingt wie ein riesiges Puzzle! Ich liebe Puzzles!"

Die anfängliche Überforderung wich langsam einer vorsichtigen Neugier. Die Gruppe begann, die Materialien zu sortieren und die Anleitung genauer zu studieren.

"Okay, Leute", sagte Marco und klatschte in die Hände. "Wir sollten uns aufteilen. Wer möchte was machen?"

Nach einiger Diskussion einigten sie sich: Marco und Emma würden sich um den mechanischen Aufbau kümmern, Lisa und Sarah um die Elektronik, während Tom und Alex sich der Programmierung widmen sollten.

"Ich hoffe, wir haben genug Zeit dafür", murmelte Sarah, während sie die Sensoren betrachtete. "Das sieht komplizierter aus, als ich dachte."

Tom versuchte, optimistisch zu bleiben. "Hey, wir lernen hier alle etwas Neues. Das ist doch spannend, oder?"

Die nächsten Stunden vergingen wie im Flug. Das Wohnzimmer verwandelte sich in eine improvisierte Werkstatt. Überall lagen Bauteile, Werkzeuge und aufgeschlagene Anleitungen.

"Verdammt!", fluchte Marco leise, als ihm ein kleines Zahnrad aus der Hand glitt. "Diese Teile sind ja winzig!"

Emma kicherte. "Willkommen in meiner Welt. So fühlt es sich an, wenn ich feine Strähnen schneide."

Währenddessen starrten Tom und Alex konzentriert auf den Laptop-Bildschirm. "Ich glaube, wir müssen diese Schleife hier anders setzen", murmelte Tom.

Alex nickte. "Ja, und vergiss nicht, wir müssen auch noch die Sensordaten auslesen."

Die Stimmung schwankte zwischen Frustration und Begeisterung. Jeder kleine Fortschritt wurde gefeiert, jeder Rückschlag gemeinsam bewältigt.

Als der Abend hereinbrach, hatten sie zwar noch keinen funktionierenden Roboter, aber ein neues Gefühl der Zusammengehörigkeit. Sarah lächelte müde. "Wisst ihr was? Ich habe den ganzen Tag nicht einmal an die Kameras gedacht."

Die anderen stimmten zu. Die technische Herausforderung hatte sie nicht nur abgelenkt, sondern auch näher zusammengebracht. Mit neuem Enthusiasmus blickten sie auf die kommenden Tage, bereit, sich der Aufgabe zu stellen und gemeinsam zu wachsen.

Der nächste Morgen begann früh für die Bewohner des TV-Experiments. Noch bevor das Frühstück serviert wurde, saßen alle um den großen Tisch im Wohnzimmer, umgeben von Bauteilen und technischen Unterlagen.

Tom, der Informatikstudent, hatte die Führung übernommen. "Also gut, Leute. Lasst uns systematisch vorgehen. Wir fangen mit den Grundlagen an und arbeiten uns dann vor."

Sarah nickte zustimmend. "Gute Idee. Aber wo fangen wir an? Das sieht alles so kompliziert aus."

Marco, der Mechaniker, griff nach einem der Schaltpläne. "Ich schlage vor, wir teilen uns die Anleitungen auf. Jeder liest einen Teil und fasst für die anderen zusammen."

"Super Idee!", stimmte Emma zu. "Ich nehme den Teil über die Motoren. Das erinnert mich irgendwie an die Haarschneidemaschinen im Salon."

Die nächste Stunde verbrachten sie damit, die Anleitungen zu studieren und sich gegenseitig zu erklären, was sie verstanden hatten. Lisa, die Psychologin, beobachtete fasziniert die Gruppendynamik.

"Es ist erstaunlich", sagte sie, "wie schnell wir uns in dieser neuen Situation zurechtfinden. Jeder bringt seine Stärken ein."

Alex, der bisher eher im Hintergrund geblieben war, meldete sich zu Wort. "Ich habe eine Idee für die Programmierung. Wir könnten eine Art Flussdiagramm erstellen, bevor wir anfangen zu coden. Das hilft uns, die Logik zu verstehen."

Tom strahlte. "Das ist brillant, Alex! Lass uns das gleich angehen."

Währenddessen hatten Marco und Emma begonnen, das Chassis des Roboters zusammenzubauen. "Reichst du mir mal den kleinen Schraubenzieher?", fragte Marco.

Emma reichte ihm das Werkzeug. "So fühlt sich also Roboter-Chirurgie an", scherzte sie.

Sarah und Lisa widmeten sich der Elektronik. "Okay, laut der Anleitung müssen wir jetzt den Infrarotsensor hier anschließen", murmelte Sarah konzentriert.

Lisa hielt vorsichtig die Platine. "Langsam verstehe ich, wie alles zusammenhängt. Es ist wie ein komplexes Nervensystem."

Die Stunden vergingen wie im Flug. Zwischendurch gab es immer wieder Momente der Frustration, aber auch kleine Erfolge, die gefeiert wurden.

"Ja! Der Motor dreht sich!", rief Marco begeistert, als sie den ersten Test durchführten.

Tom und Alex hatten inzwischen die ersten Zeilen Code geschrieben. "Schau mal", sagte Tom, "wenn wir diesen Befehl hier ändern, sollte der Roboter besser auf Kurven reagieren."

Gegen Abend hatten sie zwar noch keinen voll funktionsfähigen Roboter, aber deutliche Fortschritte gemacht. Das Chassis stand, die Elektronik war größtenteils verkabelt, und ein grundlegendes Programm war geschrieben.

Emma streckte sich und gähnte. "Ich hätte nie gedacht, dass ich mal so viel über Roboter lernen würde. Das ist ja fast spannender als Haarschnitte!"

Sarah lachte. "Ja, und ich fühle mich plötzlich wie eine Technik-Expertin. Wer hätte das gedacht?"

Lisa fasste die Stimmung zusammen: "Was wir hier erleben, ist wirklich bemerkenswert. Wir lernen nicht nur über Roboter, sondern auch über Teamarbeit und unsere eigenen Fähigkeiten."

Tom nickte zustimmend. "Genau. Und das Beste ist: Wir machen das alles zusammen. Jeder bringt etwas ein, und gemeinsam schaffen wir etwas, das keiner von uns alleine könnte."

Mit einem Gefühl des Stolzes und der Vorfreude auf den nächsten Tag beendeten sie ihre Arbeit. Die anfängliche Überforderung war einer enthusiastischen Entdeckerfreude gewichen. Sie hatten nicht nur technische Fortschritte gemacht, sondern auch als Team zusammengefunden.

Der dritte Tag der Roboter-Challenge begann mit einer Mischung aus Aufregung und Nervosität. Das Team hatte beschlossen, heute die ersten echten Tests durchzuführen.

Marco und Emma standen stolz vor dem fertig zusammengebauten Chassis. "Seht mal, wie schön er geworden ist!", rief Emma begeistert. "Lasst uns ihm einen Namen geben!"

Sarah lachte. "Wie wäre es mit 'Robi'? Kurz für Roboter und irgendwie niedlich."

"Robi klingt gut", stimmte Tom zu. "Okay, Robi, lass uns sehen, was du kannst!"

Sie platzierten den Roboter vorsichtig auf einer schwarzen Linie, die sie auf dem Boden des Wohnzimmers aufgeklebt hatten. Alex drückte den Startknopf und alle hielten den Atem an.

Zunächst geschah – nichts.

"Ähm, sollte er sich nicht bewegen?", fragte Lisa vorsichtig.

Tom und Alex tauschten besorgte Blicke aus. "Lass uns noch mal den Code überprüfen", schlug Tom vor.

Während die beiden sich über den Laptop beugten, untersuchten Marco und Emma nochmals die Mechanik. "Die Motoren sind definitiv richtig angeschlossen", murmelte Marco.

Nach einer halben Stunde Fehlersuche rief Alex plötzlich: "Ich hab's! Wir haben vergessen, den Sensor zu kalibrieren!"

Mit zitternden Händen nahmen sie die notwendigen Anpassungen vor. Erneut platzierten sie Robi auf der Linie.

Diesmal begann er sich tatsächlich zu bewegen! Langsam und etwas zitternd, aber er folgte der Linie.

"Er läuft! Er läuft wirklich!", jubelte Sarah und klatschte in die Hände.

Die Freude war jedoch nur von kurzer Dauer. Als die Linie eine scharfe Kurve machte, fuhr Robi einfach geradeaus weiter.

"Oh nein", seufzte Emma. "Was ist denn jetzt los?"

Tom kratzte sich am Kopf. "Ich glaube, wir müssen die Sensitivität der Sensoren anpassen. Und vielleicht die Motorgeschwindigkeit in den Kurven reduzieren."

Die nächsten Stunden verbrachten sie damit, verschiedene Parameter zu justieren. Jedes Mal, wenn sie dachten, sie hätten das Problem gelöst, tauchte eine neue Herausforderung auf.

"Warum fährt er jetzt rückwärts?", fragte Lisa verwirrt, als Robi bei einem weiteren Versuch plötzlich die Richtung wechselte.

Alex lachte erschöpft. "Ich glaube, ich habe versehentlich ein Minuszeichen im Code übersehen."

Gegen Abend hatten sie es geschafft: Robi konnte der Linie folgen, Kurven nehmen und sogar an Kreuzungen die richtige Richtung wählen.

"Ich kann es kaum glauben", sagte Marco stolz. "Wir haben tatsächlich einen funktionierenden Roboter gebaut!"

Sarah nickte anerkennend. "Und das, obwohl keiner von uns vorher Erfahrung damit hatte. Wir sind ein tolles Team!"

Lisa, die den ganzen Prozess aufmerksam beobachtet hatte, fasste zusammen: "Was wir hier erlebt haben, ist ein perfektes Beispiel für kollektives Lernen und Problemlösung. Jeder Rückschlag hat uns nur stärker gemacht."

Tom lächelte müde, aber zufrieden. "Ihr habt Recht. Wir haben nicht nur einen Roboter gebaut, sondern auch gelernt, wie man als Team Herausforderungen meistert."

Als sie an diesem Abend zu Bett gingen, waren alle erschöpft, aber erfüllt. Sie hatten nicht nur die technische Aufgabe gemeistert, sondern auch wichtige Lektionen über Zusammenarbeit, Ausdauer und die Kraft des gemeinsamen Lernens gelernt.

Emma gähnte und meinte scherzend: "Wer hätte gedacht, dass ein kleiner Roboter uns so viel über uns selbst beibringen würde?"

Mit diesem Gedanken schliefen sie ein, stolz auf ihre Leistung und gespannt, welche Herausforderungen das TV-Experiment noch für sie bereithalten würde.