Reader

Some thoughts on statistical modeling and data science James Garrett

Some years ago, in a large pharmaceutical company, an academic paper circulated among some of the members of the statistical staff (of which I was one). It addressed the question of how logistic regression compared to machine learning (ML) methods in predictive accuracy with clinical trial data. The authors of the paper applied logistic regression models and found equal or better predictive performance than had been reported earlier with ML methods.

The paper was greeted by the statisticians with an uncomfortably tribal quality—I think someone may have literally written, “Hooray for our side!” If that wasn't the literal statement, the discourse within the group certainly ran along that line, such was the feeling of siege that prevailed.

(Unfortunately, I cannot find that paper now. A search on this topic uncovers many papers on the relative predictive accuracy of logistic regression on clinical data. It's been a topic of some concern, apparently.)

I had been studying statistical modeling methods advocated by Dr. Frank Harrell, Jr., whom I like to call “The most respected ignored statistician in America.” He's an elected fellow of the American Statistical Association, which is as close to a Nobel Prize as the statistics world comes. He specializes in exploratory modeling of clinical data. He mined decades' worth of statistical thinking to synthesize an exploratory modeling workflow that is purported to be thorough, efficient, and likely to yield replicable results.

The funny thing about this methodology is that at any single given point in its process, it is utterly familiar to statisticians. Logistic regression here; sure, feeling right at home. Model selection criteria there; got it. Assessment of correlations among predictor variables; of course. However, when you put all the pieces together and take it from A to Z, the whole is not familiar at all. On two occasions, with two large corporations, sat with large statistics groups and heard Dr. Harrell walk through his process. I've left the room watching audience members nodding their heads and saying the good Doctor had made a lot of convincing points. But would they incorporate these ideas in their own work? “No, my clients would never let me.” That's why I say Harrell is highly respected yet mostly ignored.

One aspect that figures prominently in Harrell's workflow is inclusion of spline expansions to enable simple non-linearity for continuous predictors. In over ten years of work within the large statistical group, I had seen lots of logistic regression models, but not one included a spline expansion.

So it was interesting indeed when I looked more closely at the paper which “scored one for our side.” It didn't give a lot of detail about how the logistic regression models were fitted, but they contained spline expansions. It seemed extremely likely that the creators of the models were aware of Harrell's process. At any rate, by using splines they were out of step with typical practice.

In fact, this paper wasn't a win for “our side,” if “our side” refers to statisticians who fit models in the typical manner. It was a win for something completely different, neither ML nor typical statistical practice. It was a win for what statistical modeling could be, but rarely is. I believe my colleagues were a little quick to accept this paper as representing their practice. It suggested a middle way between traditional statistical modeling and ML, a way which can predict as well as ML, can be as flexible in many respects, and can be more informative to boot. If the data is appropriate.

I intend to write a follow-up essay soon suggesting why I think Harrell's approach works well for most clinical data sets, so stay tuned. I'll also offer some thoughts on a way to categorize statistical and ML modeling methods according to their behavioral properties, to aid in picking the right method for the data set at hand. We really shouldn't be organized in tribes at all; there is no best modeling method, there is only a method that is best at exploiting the features of a particular data set. What are those features? I'll offer my suggestions soon.

Der Singularity Viewer hat vor allem in OpenSim noch viele treue Anhänger. Was diese aber zumeist nicht wahrhaben wollen: Der Viewer ist eigentlich mausetot. Oder vielleicht eher untot. Seit 2020 sind keine neuen Binaries mehr herausgekommen. Und es werden auch keine mehr kommen. Der ganze Viewer wird nicht mehr weiterentwickelt werden.

Warum das so ist und warum das so kam, möchte ich hier erzählen.

Singularity ist eigentlich ein uralter Viewer. Vor etwa zehn Jahren wurde er von Ascent geforkt, was seinerseits ein Fork von Inertia war mit dem Ziel, den vor 14 Jahren gestarteten, aber nur kurze Zeit entwickelten Inertia in Second Life zugelassen zu bekommen.

Asbach-Code

So alt der Viewer ist, so alt ist zu erheblichen Teilen natürlich auch der Code. Und wenn man aus der Software-Entwicklung eins gelernt hat, dann ist das: Wenn Bibliotheken oder andere Abhängigkeiten, gegen die etwas entwickelt ist, aktualisiert werden, wird der Code, der gegen sie entwickelt wurde, nicht mitaktualisiert. Jedenfalls nicht, wenn es nicht unbedingt notwendig ist.

Niemand eröffnet einen Issue, weil irgendeine Abhängigkeit aktualisiert wurde, um den Code entsprechend zu modernisieren, wenn der Code auf dem Stand von vor sieben Jahren immer noch wunderbar kompiliert. Und selbst wenn, wird der Issue nicht etwa gefixt, sondern ignoriert oder mit Won't Fix geschlossen. Den Aufwand, etwas zu „reparieren“, was funktioniert, ohne daß sich sichtlich irgendetwas verbessert, macht sich kein Entwickler. Selbst wenn jemand einen Pull Request einreichen würde mit einer gründlichen Code-Modernisierung, dürften viele Kernentwickler keine Lust haben, den zu überprüfen, wenn er nichts wirklich repariert oder verbessert.

Natürlich fängt der Compiler irgendwann an, „Deprecated“-Meldungen auszugeben. Und die werden mit der Zeit immer mehr. Die werden aber geflissentlich ignoriert. Kompiliert ja und läuft hinterher auch. Also alles in Ordnung. „Deprecated“ wird von vielen Entwicklern als „stilistisch veraltet“ angesehen. Tatsächlich aber bedeutet es: „Wird demnächst nicht mehr unterstützt, also kommt in die Puschen und bringt euren Code auf Stand!“

Die ganz schlimmen Finger copy-pasten sogar Code, der deprecated ist, oder schreiben ganz neuen Code, der gleich deprecated ist, weil sie das schon immer so gemacht haben. Außerdem: Wer achtet denn beim Kompilieren darauf, was genau deprecated ist?

Und irgendwann geht’s einfach nicht mehr

Eines schönen Tages dann bekommt man auf seinen Rechner per Systemupdate neue Versionen der Bibliotheken und des anderen Zeugs, gegen die man baut. Auf einmal kompiliert der eigene Code nicht mehr. Was bis gerade eben noch deprecated war, wird jetzt endgültig gar nicht mehr unterstützt.

Dann hat man als Entwickler ein Riesenproblem. Einige Entwickler erinnern sich an die „Deprecated“-Meldungen und sagen: „Hätte ich mal …“ Andere reden sich ein, daß das doch niemand hätte ahnen können, daß das mal passieren würde – nur daß eben die „Deprecated“-Meldungen genau das eben angekündigt hatten.

Gewissenhafte Entwickler würden nun eine sofortige Modernisierung ihres ganzen Code in Angriff nehmen, und zwar mit höchster Priorität. Wenn man allerdings zigtausende oder hunderttausende Codezeilen hat, ist das ein Riesenaufwand, auch ein zeitlicher.

Um trotzdem irgendwas kompilieren zu können, versuchen einige daher, auf irgendeinem Wege alte Versionen ihrer Abhängigkeiten zu installieren. Noch viel mehr Entwickler tun das aber, um die Code-Modernisierung entweder möglichst lange aufzuschieben oder ganz vermeiden zu können. Natürlich bringt auch das nur etwas bei statischen Builds, die die Abhängigkeiten nur zum Kompilieren brauchen und hinterher ohne diese Abhängigkeiten laufen. Ansonsten wäre das Ganze nämlich allmählich auch bei den Nutzern nicht mehr lauffähig.

Irgendwann kommt man dann aber an einen Punkt, an dem die alten Versionen der Abhängigkeiten des eigenen Code auf der eigenen Maschine nicht mehr installierbar sind, weil ihre eigenen Abhängigkeiten nicht mehr da sind bzw. per Update auf eine zu neue Version gebracht werden. Selbst dann gibt’s Entwickler, die schlicht und ergreifend ihre Maschine, auf der sie entwickeln, einfach nicht mehr updaten. Nicht, daß sie sich dann endlich mal dran machen würden, ihren Code auf Stand zu bringen. Natürlich nicht, denn seit aus „deprecated“ „nicht mehr unterstützt“ wurde, hat sich die Menge an eigentlich nicht mehr unterstütztem Code nicht verringert, sondern vermehrt, weil auch der Entwickler sich nicht aufgeschlaut hat, wie man’s denn heute macht.

Paradebeispiel Python

Singularity ging letztlich vermutlich an zwei Abhängigkeiten zugrunde. Die eine ist die GNU Compiler Collection, kurz gcc, die andere Python. Der Python-Anteil im Singularity-Code macht zwar nur 0,6% aus, aber auch die können sich quer stellen.

Schon das ganze Jahrzehnt über gibt es Riesenärger mit uraltem Python-2-Code, von dem irgendetwas abhängt, den auf Python 3 zu bringen aber wie ein unmögliches Unterfangen wirkt. Eigentlich wäre das Migrieren von relativ aktuellem Python-2-Code, also auf dem Stand von Python 2.7, nach Python 3 nicht so überwältigend schwierig. Aber wenn etwas bis heute auf Python 2 basiert, dann basiert es wahrscheinlich auf einer ziemlich alten Version von Python 2, also Python 2.5 oder älter, das noch keine Python-3-Bestandteile hat. Und wieder hat sich niemand je die Mühe gemacht, den Code zu modernisieren, weil er ja auch unter Python 2.7 wunderbar lief. Allen „Deprecated“-Meldungen zum Trotze.

Calibre zum Beispiel, eine E-Book-Verwaltung, ist von 2006, also aus der Zeit von Python 2.5 und somit der Zeit vor Python 3. Python 3.0 war im Dezember 2008 erschienen; zeitgleich kam Python 2.6 raus, das schon Elemente von Python 3 enthielt. Schon im Juni 2009 kamen Python 3.1 und Python 2.7 hinterher. Seitdem wurde aber höchstwahrscheinlich am Bestandscode von Calibre genau gar nichts modernisiert, nicht nach Python 3.1, nicht mal nach Python 2.7.

Auch noch 2008 kündigte die Python Foundation an, die Unterstützung von Python 2 im Jahr 2015 einzustellen. Python-Entwickler hatten sechs Jahre Zeit, ihre Projekte auf Stand zu bringen. Sehr viele haben genau gar nichts gemacht. Anfangs hatten sie keine Eile, dann vergaßen sie es ganz einfach und entwickelten mitunter lustig auf dem vollkommen veralteten Stand von Python 2.5 oder älter weiter, und als der Termin vor der Tür stand, hätte die Zeit nicht mehr gereicht. Das betraf durchaus wichtige, kritische Sachen, auf die nicht verzichtet werden konnte. Also wurde der Support von Python 2 bis 2020 verlängert. Dann sollte aber Ende sein.

Einige drückten nun auf die Tube. Spätestens ab 2018 saßen ihnen einige Linux-Distributionen im Nacken, die sagten, wenn sie nicht auf Python 3 gehen, fliegen ihre Projekte raus.

Schließlich fingen 2020 Linux-Distributionen an, das ab Jahreswechsel 2019/2020 offiziell nicht mehr unterstützte Python 2 aus ihren Softwarequellen zu entfernen. Damit mußten natürlich auch diejenigen Pakete aus den Quellen geworfen werden, die von Python 2 abhingen. Die Entwickler wurden angeschrieben; sie sollten entweder ihre Sachen schleunigst auf Python 3 bringen, oder die werden aus den Quellen entfernt. Einige reagierten wieder erst, als große Distributionen ankündigten, ihre Kreationen aus Versionen mit Langzeitunterstützung (Debian stable, Ubuntu LTS etc.) zu entfernen.

Das betraf letztlich nur noch sehr wenige Projekte. Aber Calibre betraf es sehr wohl. Der einzige Entwickler fing daraufhin an zu jammern, daß Calibre über eine halbe Million Codezeilen auf Python-2-Stand hatte, die könne er nie und nimmer auf Python 3 bringen. Das klang schon sehr danach, als wenn das ganze Ding tatsächlich immer noch praktisch komplett auf Python-2.5-Stand war, also genau überhaupt nichts aus Python 3 eingebaut hatte. Und der Entwickler schlug vor, er könne statt dessen die Weiterentwicklung von Python 2 übernehmen, dann könnten die Distributionen das weiter in ihren Quellen behalten, und er bräuchte Calibre nicht aufwendig zu sanieren. Das schien ihm wirklich der geringere Aufwand zu sein. Allerdings lehnten die Distributionen das ab.

Letztlich konnte Calibre nur weiter bestehen, indem es bis September 2020 doch noch auf Python 3 aktualisiert wurde. Daran wirkten wohl einige Freiwillige mit. Außerdem wurden in diesem Zuge den Entwicklern von Plugins, die immer noch auf Python 2 aufbauten, Pistolen auf die Brüste gesetzt: Wenn die nicht auch auf Python 3 aktualisieren, fliegen ihre Plugins raus. Einige Plugins, die schon längst nicht mehr weiterentwickelt wurden, sind wohl tatsächlich geflogen.

Auch wenn bei Singularity nun der gesamte Python-Anteil auf dem Stand von Python 2.5 sein, also keinerlei Spuren von Python 3 enthalten sollte, ist Python längst nicht das größte Hindernis. Das ist vielmehr gcc, denn Singularity ist größtenteils in C++ geschrieben.

Extremfall gcc

Auch C++ ist nicht TeX, wo 46 Jahre alter Dokumentencode heute noch kompiliert und das daraus resultierende Dokument haargenau so aussieht, wie wenn es vor 46 Jahren kompiliert worden wäre. Es ist auch nicht LaTeX, wo das mit einer Zeitdifferenz von 40 Jahren noch funktioniert. C++ entwickelt sich nicht nur weiter, es baut auch mal Sachen um und schmeißt alte Sachen raus.

Das heißt: Knapp vier Jahrzehnte alter C++-Code kompiliert heutzutage nicht mehr unbedingt. Und schon zehn Jahre alter Code kompiliert heute nicht mehr, wenn er nur ausgefuchst genug ist.

Genau deshalb gibt es ja „Deprecated“-Meldungen. Kaum ein Entwickler folgt irgendeiner Mailinglist, die Änderungen in Compilern ankündigt. Aber was beim Kompilieren passiert, das sehen die meisten. Also wird genau da darauf hingewiesen, daß Teile des Code so veraltet sind, daß das schon kritisch wird und schleunigst behoben werden sollte. Blöderweise ignorieren Entwickler meistens kleinere Mengen an „Deprecated“-Meldungen als harmlos und zu vernachlässigen. Und wenn die Meldungen sich häufen, wird es ihnen zuviel Arbeit, endlich was dagegen zu machen.

Durch sein Inertia-Erbe ist der Code von Singularity zu erheblichen Teilen auf dem Stand von Mitte der 2000er, also bestenfalls dem von C​+​+​03. Auch dieser Code wurde nie auf einen neueren Stand gebracht.

Der C++-Compiler in der Collection heißt g++. Mit g++ 4 war der Code noch kompilierbar, wobei wahrscheinlich neuere Versionen jede Menge „Deprecated“-Meldungen ausgaben. Aber schon der g++ 5 konnte den Code nicht mehr in etwas Ausführbares umsetzen.

gcc 5 kam schon im April 2015 raus, aber Singularity wurde auf einem Ubuntu-LTS-Rechner kompiliert. Ubuntu 14.04 LTS „Trusty Tahr“ kam noch mit gcc 4.8.2. Mit dem Upgrade auf Ubuntu 16.04 LTS „Xenial Xerus“ wurde das aber ersetzt durch gcc 5.3.1. Und schon war Singularity nicht mehr kompilierbar. Das war schon vor gut neun Jahren.

Statt jetzt aber den veralteten Code auf Vordermann zu bringen, ging man einen einfacheren Weg – und bastelte irgendwie wieder gcc 4 auf die Maschine drauf. Aber nicht, um sich für die Code-Modernisierung die nötige Zeit zu verschaffen, sondern wohl eher in der Hoffnung, damit den Code überhaupt nie modernisieren zu müssen. Dahinter stand auch die Hoffnung, daß es bis in alle Ewigkeit möglich sein würde, gcc 4 unter Ubuntu zu installieren.

Nichts geht mehr

Ziemlich genau vier Jahre später wurde Singularity das letzte Mal erfolgreich kompiliert, und zwar immer noch unter demselben alten Ubuntu „Xenial“. Das war im Frühjahr 2020. Inzwischen waren Ubuntu 18.04 LTS „Bionic Beaver“ und Ubuntu 20.04 LTS „Focal Fossa“ erschienen. Es dürfte klar sein, warum der Rechner, auf dem Singularity kompiliert wurde, nicht auf eine der beiden Versionen upgegradet wurde. Vielleicht hatte man festgestellt, daß die alten gcc-4-Pakete schon unter „Bionic“ nicht mehr installierbar waren.

Normalerweise hätte spätestens 2018 die Aussicht, daß gcc 4 irgendwann nicht mal mehr nachinstalliert werden kann, auch nicht aus losen Paketdateien, der Tritt in den Hintern sein müssen, der dazu hätte führen müssen, den Code von Singularity endlich auf einen Stand zu bringen, der nicht schon seit mindestens drei Jahren völlig veraltet war. Passiert ist aber wieder genau gar nichts. Man hatte ja Ubuntu „Xenial“, das lief, da war gcc 4 installiert, Singularity kompilierte, alles war gut.

Wie gesagt, bis Frühjahr 2020. Da wurde noch einmal eine neue Release-Versionen kompiliert, 1.8.9, die erstmals Bakes-on-Mesh neue Beta-Versionen kompiliert. Etwas später folgten ein paar neue Beta-Versionen. Wahrscheinlich ist dann irgendwas mit dem Rechner passiert, auf dem kompiliert wurde. Zu diesem Zeitpunkt dürfte das der einzige noch verfügbare Rechner mit Ubuntu „Xenial“ gewesen sein, auf dem also gcc 4 installierbar war.

Aktuell war damals ja Ubuntu „Focal“, das gcc 9.3.0 mitbrachte und als erstes Ubuntu LTS kein Python 2 mehr. Der Support für Ubuntu „Xenial“ lief noch bis April 2021, aber ich glaube nicht, daß Ubuntu für diese alte Version noch Images zum Installieren zur Verfügung stellte. Hätte also der Rechner, auf dem Singularity kompiliert wurde, neu aufgesetzt oder durch eine andere Maschine ersetzt werden müssen, hätte kein Ubuntu mehr installiert werden können, mit dem Singularity hätte kompiliert werden können.

Ein mögliches Szenario ist also, daß irgendetwas mit dem Entwicklungsrechner bzw. dem Rechner, auf dem kompiliert wurde, passierte. Irgendetwas, das die Weiterverwendung der alten Ubuntu-Installation unmöglich machte, z. B., daß die Festplatte ihren Geist aufgab.

Wie auch immer: Der Rechner stand so, wie er war, nicht mehr zur Verfügung. Es brauchte Ersatz. Dieser Ersatz hätte aber Ubuntu „Xenial“ von 2016 als System gebraucht. Schon 2020 hätte man das Problem gehabt, daß man „Xenial“ nicht mehr hätte installieren können, sofern man kein entsprechend altes Installationsmedium mehr hatte und auch kein ISO-Image, um eins zu bauen. Und wer bewahrt so etwas auf? Schlimmstenfalls hatte man auch die gcc-4-Pakete verloren oder verschlampt und konnte die auch nirgendwo mehr herunterladen, weil Ubuntu „Trusty“, von dem sie kamen, seit 2019 nicht mehr unterstützt wurde.

So hatte man keinen Rechner mehr, auf dem Singularity hätte kompiliert werden können. Man hatte auch keine Möglichkeit mehr, einen Rechner aufzusetzen, mit dem man Singularity hätte kompilieren können. Schon die eh notwendige Weiterentwicklung, um mit Neuerungen in und neuen Anforderungen von Second Life Schritt zu halten, schaffte man 2020 gerade noch so mit Ach und Krach. Selbst die Website war damals schon in Teilen veraltet; das Versprechen, die Singularity-Erklärseite auf den damals aktuellen Stand von Version 1.8.9 zu bringen, wurde nie eingelöst; sie ist bis heute auf dem Stand von Singularity 1.7.0. Da war also auch nicht daran zu denken, den Code von Singularity so aufzufrischen, daß er wieder kompilierbar wäre.

Heutiger Stand

Inzwischen ist 2024. Die letzte Ubuntu-Version, auf der Singularity hätte kompiliert werden können, kam vor zehn Jahren heraus und wird seit fünf Jahren nicht mehr unterstützt. Auch andere Linux-Distributionen unterstützen gcc 4 schon lange nicht mehr. Und selbst die aktuellsten Singularity-Binaries starten, obwohl sie weitgehend statische Builds ohne großartige Abhängigkeiten sind, unter mehr und mehr Linux-Distributionen inzwischen überhaupt nicht mehr.

Vielleicht hätte man noch eine Chance, Singularity unter Arch Linux oder einem seiner Derivate zu kompilieren, ohne den Code anfassen zu müssen. Im Arch User Repository gibt es sehr viele Sachen auch noch in wirklich uralten Versionen, so auch gcc 4.9 und Python 2.7.18. Aber das wäre wirklich für sehr weit Fortgeschrittene – und der Sprung von Ubuntu nach Arch wäre heftig – und würde auf eigene Gefahr laufen, weil beides von den jeweiligen Anbietern schon ewig nicht mehr unterstützt wird.

An eine Weiterentwicklung von Singularity wäre aber selbst dann nicht zu denken. Inzwischen ist sehr viel passiert. Singularity unterstützt noch Windlight, das inzwischen nicht nur in Second Life, sondern auch fast im gesamten Hypergrid durch EEP ersetzt wurde; das wiederum unterstützt Singularity noch nicht. Von Physically-Based Rendering will ich gar nicht erst anfangen.

Es wäre allerdings reiner Wahnsinn, das in den Singularity einbauen zu wollen, wie er jetzt ist. Schon vor acht Jahren ging der Code von Singularity nur noch mit Tricks und unter Verwendung eines veralteten Compilers zu kompilieren. Wenn überhaupt, muß der ganze Code als allererstes um mehr als ein Jahrzehnt modernisiert werden. Ansonsten wäre der Einbau neuer Features wie ein nagelneuer Anbau an einem Gebäude, das seit acht Jahren wegen Baufälligkeit gesperrt ist.

#OpenSim #SecondLife #FürFortgeschrittene #Software

Geht wählen! Das ist unsere Chance Europa mitzugestalten. Und gerade in Zeiten wie diesen ist es wichtig, seine Stimme abzugeben.

🗳️ Warum wählen? → https://elections.europa.eu/de/why-vote 🗳️ Wie wählen? → https://elections.europa.eu/de/how-to-vote/de 🗳️ Wen wählen? → Wahl-O-Mat / WahlSwiper 🗳️ Wahlergebnisse → https://results.elections.europa.eu/de

aspe:keyoxide.org:XVGZCZSHGOSGNIDFAH6WQDDLEQ

StarTrekTagebuch, 33. Eintrag TNG S02F08 (A Matter of Honor) SpoilerAlert

SuvwI' may'vaD may'luch!

Und damit herzlich willkommen zu dieser sehr unterhaltsamen Folge, in der endlich die Klingonen einmal en détail beleuchtet werden können und ich ngup endlich ein paar Wissenslücken schließen kann.

Die Starfleet und ihre Verbündeten haben beschlossen, durch ein Offiziersaustauschprogramm mehr voneinander zu lernen. Unter anderem kommt dabei der Benzit Mendon an Bord.

Von der Enterprise soll Riker als erster Offizier auf dem klingonischen Schiff Pagh dienen (als erster Mensch überhaupt!). Als gewissenhafter Commander bereitet er sich natürlich auf diese geschichtsträchtige Aufgabe vor. Größtenteils indem er Unmengen an klingonischem Essen in sich hineinstopft, unter anderem Schlangenwürmer, Blutpastete und andere vorwiegend rohe und fleischlastige Speisen. Anscheinend ist ein Magen aus Stahl Grundvoraussetzung für den Dienst bei den Klingonen. Worf ist allerdings der Meinung, dass das nicht ganz genügt und gibt Riker zur Sicherheit noch einen Notfallsender, mit dem Rikers Position ermittelt und er schnell wieder an Bord gebeamt werden kann.

An Bord der Pagh wird Riker auch gleich seiner ersten Prüfung unterzogen. Als 1. Offizier hat er natürlich einen sehr hohen Rang inne und damit auch einige Klingonenkrieger unter sich, die, streitbar wie sie sind, nicht unbedingt damit warm werden, Befehle von einem Menschen entgegenzunehmen.

Dazu kommt, dass die chain of command bei Klingonen offenbar dadurch sichergestellt wird, dass man sich in der Hackordnung nach oben boxt und Offiziere, wenn Niedrigergestellte nicht mit den Befehlen einverstanden sind, einfach umgebracht werden (oder zumindest wird das versucht). Riker erlebt das direkt am eigenen Leib, als der 2. Offizier seine Loyalität infrage stellt. Daraufhin wird er sehr spektakulär von Riker vermöbelt, klingon style, und fügt sich ab da.

Auf der Enterprise wird inzwischen eine Beschädigung am Schiffrump entdeckt, verursacht von einer “subatomaren Bakterienform” (wie auch immer das funktionieren soll), die die Außenhülle auffrisst und aller viertel Stunde um das doppelte wächst. Diese ist offenbar von dem Klingonenschiff übergesprungen, die nichts davon zu wissen scheinen.

Dort hat Riker seine Feuerprobe bestanden und wird auch von dem Rest der Crew akzeptiert, die sehr von seiner “klingonischen Seite” angetan sind. Das geht so weit, dass sie ihm lebenden Gagh (diese Schlangenwürmer) servieren und die klingonischen Kriegerinnen ihm Avancen machen.

Und damit zum..

Speaking of: Klingonen (Kultur und Ehrenkodex)

Klingonen sind kriegerisch, soweit kann man so ziemlich alle Klingonen zusammenfassen, die mir bisher begegnet sind. Mit jeder Folge wird jedoch ein klein wenig mehr ihrer komplexen Kultur offenbart, die sehr viel komplexer ist, als ihr martialisches Aussehen und Verhalten schließen lässt.

Ich habe schon oft Vergleiche gezogen zu den Kroganern aus der Mass Effect-Reihe und auch die Klingonen stammen offenbar von einer lebensfeindlicheren Welt als der Erde, auf der die natürliche Selektion auch etwas härter zuschlägt. Auch in der Gesellschaft spielt Stärke eine große Rolle für gesellschaftliches Ansehen und Macht, dabei ist es aber nicht so, dass sich hochdekorierte Krieger:innen auf ihren Loorbeeren ausruhen können.

Sich eine Stellung zu erkämpfen ist eine, sich eine Stellung zu erkämpfen ist die eine, sie zu halten eine andere. Wer schwach wird, stirbt und überhaupt ist der Tod im Kampf aus klingonischer Sicht der einzig würdige.

Der 2. Offizier Klag erzählt von seinem Vater, der von Romulanern gefangen aber nicht getötet wurde, bis ihm schließlich die Flucht gelang. Damit hat er jedoch jegliche Ehre verloren und ist nun dazu “verdammt” auf dem Heimatplaneten auf einen natürlichen Tod zu warten.

Abgesehen von diesem strikten Ehrbegriff, scheint die klingonische Gesellschaft überraschend egalitär zu sein. Geschlecht, Wohlstand oder Abstammung spielen eine untergeordnete Rolle, solange man nur stark genug ist, sich seinen Platz zu erkämpfen.

Es wird zwar immer von einem klingonischen Imperium gesprochen, jedoch ist bisher unklar wodurch genau der Titel des Imperators bestimmt wird (ich tippe ja auf ein jährliches Battle Royal anstatt einer Erbmonarchie🤔)

Zurück zur Folge:

Auch die Klingonen haben die Beschädigung durch die Bakterien jetzt bemerkt und halten sie für eine heimtückische Waffe der Enterprise. Riker versucht sie vom Gegenteil zu überzeugen, doch der Captain beschließt, die Enterprise anzugreifen und verlangt von Riker seiner vorher beteuerte Loyalität unter Beweis zu stellen.

Riker gibt vor sich zu fügen und überreicht Captain Kargan sogar seinen Notfallsender. Außerdem empfiehlt er, erst auf einer Distanz von 40.000 km zu feuern (zufällig genau die Reichweite des Senders).Als die Enterprise das Signal bemerkt (die Pagh nähert sich wie üblich im Tarnmodus) wird sogleich Kargan (der für Riker gehalten wird) an Bord gebeamt.

Damit übernimmt Riker das Kommando als Captain der Pagh und fordert Picard auf, sich zu ergeben. Ein genialer Schachzug, da ihm (als Captain eines Klingonenschiffes) jedes andere Verhalten als Schwäche ausgelegt würde.

So können die Klingonen ihr Gesicht waren und das ganze als “Sieg” verbuchen, während der benzitische Austauschoffizier Mendon eine Methode gefunden hat, beide Schiffe von den Bakterien zu befreien.

Soweit ist alles friedlich ausgegangen. Nur Riker fängt sich noch eine Ordnungsschelle ein, als er Kargan wieder das Kommando übergibt, da dieser seine Autorität wieder herstellen muss.

Insgesamt eine ebenso unterhaltsame wie informative Folge mit einem grandiosen Jonathan Frakes. 🖖

StarTrekTagebuch, 32. Eintrag TNG S02F07 (Unnatural Selection) SpoilerAlert

In dieser Folge ist wahrscheinlich eine Unsumme an Budget in die Maske geflossen. Die Enterprise empfängt mal wieder einen Notruf eines anderen Föderationsschiffes. Als man bei diesem eintrifft, ist allerdings schon die gesamte Besatzung gestorben und nicht nur das, alle sehen buchstäblich ganz schön alt aus.

Ist das eine schief gelaufene galaktische Kaffeefahrt? Eher nicht, denn laut dem medizinischem Logbuch wahr wohl ein extrem rasanter Alterungsprozess der Grund. Außerdem ist eine relativ harmlose Grippe verzeichnet, die aber normalerweise keine solchen Symptome verursacht.

Die Enterprise begibt sich zu der Forschungsstation, die das Versorgungsschiff zuletzt besucht hat und auch dort sieht es aus wie beim Bingo-Abend, auch wenn dort zumindest vorerst noch alle am Leben sind.

Dort wird an der genetischen Verbesserung von Menschen geforscht (ich dachte, das wäre nach der Ära der Supersoldaten verboten oder zumindest geächtet?).

Die gezüchteten “Kinder” (mit der Statur von Jugendlichen oder jungen Erwachsenen) sind von dem schnellen Altern nicht betroffen.

Im weiteren Verlauf geht es darum, ob zumindest diese Kinder evakuiert werden können und es entspannt sich ein Konflikt zwischen Picard und Dr. Pulaski. Schließlich einigt man sich, dass Pulaski eines der Kinder in einem Shuttle außerhalb der Enterprise untersucht, um eine Ausbreitung zu verhindern.

Letztlich steckt sie sich auch mit der “Krankheit” an. Zur Erklärung wird angeführt, dass das verbesserte Immunsystem der Kinder schon Antikörper gegen eine Krankheit bildet, bevor sie in den Körper eindringt (wie auch immer das funktioniert). Das Immunsystem hat auf die bereits erwähnte harmlose Grippe reagiert und die entwickelten Antikörper haben offenbar die Eigenschaft, die DNA “normaler” Menschen, insbesondere die Gene für den Alterungsprozess, zu verändern (wie auch immer DAS funktioniert).

Die Wissenschaftler*innen der Station sind also Opfer ihrer eigenen Forschung geworden, was direkt überleitet zum heutigen

Speaking of: Pandemie als Topos vs. echte Pandemie.

Mit Corona erleben die meisten (wie auch ich) wohl zum ersten Mal eine echte Pandemie und – spoiler alert – es ist ja gar nicht wie im Film !!11!

Weder ist ein streng geheimes Biowaffenlabor in die Luft geflogen, noch haben wir uns alle in hirnlose Zombies verwandelt. Viren, die echte Pandemien auslösen, sind in den meisten Fällen einfach nur natürlich mutierte Variationen bereits bekannter Erreger oder Zoonosen, die durch zu engen Kontakt von Menschen mit Tieren übergesprungen sind.
Zudem sind die Symptome mitunter einfach nur stärker oder länger anhaltend, als bei ähnlichen Krankheiten, was für sich ja schon beschissen und tödlich genug ist. Nur muss wohl niemand Angst haben durch ein Virus plötzlich als verfaulende Leiche herumzulaufen, was aber auch heißt, dass irgendwelche Superkräfte genauso unwahrscheinlich sind.

Viren, bzw. Pandemien in Filmen können dagegen alles Mögliche und Unmögliche auslösen und sind fast ausschließlich das Resultat von zweifelhaften Genexperimenten, finsteren Weltvernichtungsplänen, Aliens oder allem zusammen.

Die unterschwellige Botschaft, die damit leider immer vermittelt wird, ist: “Wissenschaft kann zivilisationsbedrohende Gefahren schaffen!”

Und klar, die Atombombe ist ein Beispiel, wie Wissen um die Physik des Atoms für militärische Zwecke verwendet werden kann. Aber will man deswegen auf dieses Wissen verzichten? Ähnliche Vorbehalte treffen die Forschung zum menschlichen Genom, die zur Heilung oder Prävention erblicher Krankheiten genutzt werden könnte. Sollte man diese einstellen, nur weil man sich vor “Designerbabys” fürchtet?

In Filmen mit Virus-Pandemie, ist es meist ein einzelner strahlender Held der durch irgendeine gefährliche Aktion, alles wieder ins Lot bringt.

In der realen Welt war und ist es – surprise surprise – die Wissenschaft selbst, die den Karren wieder aus dem Dreck zieht. Und das sind nicht einzelne, sondern große Teams aus allen Teilen der Erde, die daran arbeiten. Uns anderen nur unseren Beitrag zu leisten, auf uns und andere zu achten, den Schnutenpulli anzuziehen und Menschenansammlungen zu meiden. Leute, die selbst diese einfachen Sachen nicht hinbekommen, gibt es leider zur Genüge..

Zurück zur Folge:

Dr. Pulaski wird letztlich durch eine DNA-Probe aus einem Haar gerettet. Mit diesem Stück DNA vor der Erkrankung kann der Transporter die Änderungen herausfiltern und Dr. Pulaski wieder verjüngen. Den Wissenschaftler:innen auf der Station kann auf ähnliche Weise geholfen werden.

Nur die Kinder sind, da sie immer noch die Krankheit übertragen können, zu einem Leben in Quarantäne auf der Station verdammt. Wie in der aktuellen Pandemie haben junge Leute mal wieder die Arschkarte gezogen.

In dieser Folge wird der Charakter Dr. Pulaskis ein wenig weiter entwickelt und sie wirkt weit weniger forsch und freundet sich sogar mit Data an. 🖖

StarTrekTagebuch, 31. Eintrag TNG S02F6 (The Schizoid Man) SpoilerAlert

Die Folgen der neuen Staffel scheinen jetzt öfter Data in den Vordergrund zu stellen, was mir persönlich sehr gefällt, so auch diese Folge.

Die Enterprise ist auf dem Weg, einem Hilferuf des berühmten Wissenschaftlers Dr. Ira Graves nachzugehen. Berühmt ist hier nicht untertrieben, denn der Planet, auf dem er lebt, heißt nach ihm: Gravesworld oder es liegt an seinem massiven Ego.

Jedenfalls erreicht die Crew unterwegs noch ein weiterer Hilferuf von dem Föderationsschiff Constantinopel, welches mehrere Verletzte verzeichnet.

Picard will erst nicht von seiner top priority Mission abweichen, stimmt dann aber zu, Dr. Pulaski zur Constantinopel zu schicken, während das Bodenteam, bestehend aus Data, Worf und Troi von einem neuen Charakter, Dr. Selar, dem Aussehen nach eine Vulkanierin begleitet wird. Auf Gravesworld begegnet man zunächst nur Dr. Graves Assistentin Kareen Briannon.

Wie sich herausstellt, wusste Dr. Graves nichts von dem Notruf, den Kareen aufgrund seines besorgniserregenden Gesundheitszustandes gesendet hat und macht keinen Hehl daraus, was er von Ärzten, Frauen und weiblichen Ärzten hält.

Viel mehr interessiert ihn Data.

Denn Nooien Soong, Datas Schöpfer, war ein Student von Graves, was, so Graves, ihn zu einer Art Großvater Datas macht. Selar stellt inzwischen fest, dass Graves an der unheilbaren Darnyschen Krankheit leidet und nur noch wenig Zeit zu Leben hat.

Als Data und Graves allein in seinem Labor sind, erzählt der Wissenschaftler von seinem Durchbruch in der Kybernetik, genauer, der Gedankenübertragung eines menschlichen Bewusstseins in einen Computer. Nebenbei findet er auch heraus, dass Data einen Ausschalter besitzt🧐

Speaking of Kybernetik:

Ich bin mir gerade nicht mehr sicher, ob ich das Thema Bewusstseinsübertragung schonmal in einer früheren Folge angesprochen habe, ich hab zumindest auf die schnelle nichts gefunden. However, allgemein kann man das wohl im Gebiet der Kybernetik verorten.

Das ist die “Wissenschaft der Steuerung und Regelung von Maschinen und deren Analogie zur Handlungsweise von lebenden Organismen” Daher auch die Bezeichnung Cyborg (cybernetic organism). Die obige Definition ist natürlich sehr allgemein gehalten, wobei ich hier natürlich eher den Aspekt Robotik betrachte.

Bei Cyborgs denkt man am ehesten an die Augmentierung von Teilen eines biologischen Organismus mit technischen Komponenten zur Heilung von Krankheiten, Verletzungen oder Optimierung bzw. Verstärkung. In diesem Sinne ist schon heute jede*r mit einer künstlichen Hüfte, einer Armprothese oder einem Cochlea-Implantat eine Art Cyborg. Noch Zukunftsmusik ist dagegen die Augmentierung des Gehirns, welches dafür noch nicht gut genug erforscht ist.

Zwar lassen sich Gehirnaktivitäten messen und teilweise sogar damit grob bestimmen, woran jemand denkt. Aber man ist noch meilenweit entfernt, die Funktionsweise eines Gehirns mit einem Digitalrechner kompatibel zu machen, was ja die Voraussetzung wäre, das Bewusstsein als eine Art “Betriebssystem” darauf zu übertragen. Ein anderer Ansatz wäre ein “Biocomputer” der nicht auf Halbleiterbasis, sondern biochemisch arbeitet, eben genau wie das Gehirn.

In der Science Fiction wird diese Barriere gern überwunden, um komplexe ethische Fragen oder bedrohliche Szenarien aufzubauen, wie z.B. in Trancendence.

In Star Trek ist es sowohl möglich Maschinen mit einem eigenen Bewusstsein zu schaffen (–> Data ), als auch die Bewusstseinsübertragung von einem organischen Lebewesen auf ein anderes, ist, zumindest für Vulkanier, kein Problem (The Search for Spock). Die von Graves entwickelte Schnittstelle ist jedoch auch für Star Trek etwas Neues.

Zurück zur Folge:

Data berichtet dem Rest des Bodenteams vom Tod Graves in seinen Armen und sie kehren zusammen mit Kareen zurück zur Enterprise. Dort verhält sich Data reichlich seltsam und hält zum Beispiel eine extrem pathetische Rede bei Graves Bestattungszeremonie und wird sehr eifersüchtig, als Picard mit Kareen spricht.

Picard lässt Data zunächst von sich selbst und später von La Forge durchchecken, finden aber (zumindest auf Hardwareseite) keinen Fehler. Troi merkt an, dass vielleicht etwas mit seiner Psyche nicht in Ordnung ist und unterzieht Data einer “psychotronischen Stabilitätsuntersuchung”. Diese ergibt, dass Data quasi unter einer gespaltenen Persönlichkeit leidet, eine gerade aktive, die irrational und aggressiv agiert und eine passive, logische, die des “echten” Data.

In der Bord-Bar spricht “Data” mit Kareen, eröffnet ihr seine Liebe und dass er in Wirklichkeit Graves ist und Datas Körper gestohlen hat. Graves hat also Datas Software nicht direkt überschrieben, sondern sein Bewusstsein in einer Art dual boot in Datas Körper transferiert.

Trotzdem droht seine Partition, die von Data langsam aber sicher zu zerstören. Als Kareen ihn von sich weist und sein Angebot, ihr auch einen Androidenkörper zubauen, ausschlägt, verletzt er ihren Arm und stürmt davon.

Picard verfolgt ihn in den Maschinenraum, wo er schon La Forge bewusstlos geschlagen hat und versucht ihn davon zu überzeugen, Data freizugeben, der genauso ein Recht auf Leben hat. Graves-Data wird nur umso aggressiver und schlägt auch Picard zu Boden. Geschockt von seinem Handeln, scheint er zur Besinnung zu kommen.

Pulaski findet Picard und La Forge und bringt sie beide wieder zu Bewusstsein. Data scheint in sein Quartier zurückgekehrt zu sein. Dort finden sie ihn auch bewusstlos auf dem Boden liegen und er scheint, nachdem er wieder aktiviert ist, wieder ganz der Alte zu sein. Weiterhin bemerken sie, dass Graves sein Wissen um seine Forschung auf den Computer der Enterprise übertragen konnte, sein Bewusstsein jedoch endgültig verloren ist. Ob er das mit Absicht getan hat oder ob es doch eine technische Hürde gab, bleibt unklar.

Zusammengefasst hatte man hier wieder eine interessante, wenn auch etwas vorhersehbare, Folge zum Thema Tod und der Beziehung zwischen organischem und künstlichem Leben und erneut einer sehr starken Gastrolle. 🖖

StarTrek Tagebuch, 30. Eintrag TNG S02F05 (Loud as a Whisper) SpoilerAlert

Eine Folge der etwas anderen Art und eine herausragende Gastrolle von Howie Seago, der mir leider noch nirgendwo anders begegnet ist. Die Enterprise spielt mal wieder galaktische Postkutsche und soll einen berühmten Diplomaten und Friedensvermittler abholen, um einen jahrzehntelangen Bürgerkrieg auf dem Planeten Solais V beizulegen. Der Unterhändler Riva ist unter anderem deswegen berühmt, weil er die Friedensverhandlungen zwischen der Föderation und dem Klingonischen Imperium begleitet hat. Grund genug für Worf, Vorbehalte gegen ihn zu haben.

Als Picard, Troi und Worf ihn von seinem Heimatplaneten Ramatis III abholen, stellt sich heraus, dass Riva selbst gehörlos ist und durch einen sog. “Chor” bestehend aus drei “Aspekten” kommuniziert. Diese drei Personen können Rivas Gedanken lesen und ihm die Äußerungen und auch das Verhalten seines Gegenübers abhängig von ihrem jeweiligen Aspekt widerspiegeln.

Die drei Aspekte sind dabei: der Gelehrte, zuständig für Logik und Rationalität, der Romantiker, welcher Libido (🧐), Leidenschaft und Kriegertum widerspiegelt und schließlich den (weiblichen) Aspekt der Harmonie, der für Ausgleich und Gelassenheit sorgen soll. Diese einzigartige Art und Weise der Kommunikation ermöglicht es Riva viele verschiedene Sichtweisen und Verhaltensweisen wahrzunehmen und zu verstehen. Etwas, dass bei Verhandlungen mit grundverschiedenen Spezies und deren Kultur wohl höchst hilfreich ist. Riva hat sogleich ein Auge auf Troi geworfen, die ja auch eine besondere kommunikative Fähigkeit hat.

Auf der Enterprise spricht er auch La Forge auf seine Blindheit an und ist von seinem Visor fasziniert.

Das führt mich direkt zu meinem Thema für ein

Speaking of: Behinderung in Star Trek und Science Fiction generell.

Wenn Menschen mit Behinderung in Science Fiction auftauchen, kann man sich fast sicher sein, dass diese entweder durch irgendeine technische Errungenschaft ausgeglichen wird oder mit einer besonderen Eigenschaft oder Kraft zusammenhängt. Sie ist kaum einfach nur “grundlos” da, sondern dient entweder dem Plot oder der Charakterentwicklung.

So ist z.B. Charles Xaviers Behinderung in den neueren X-Men Filmen Voraussetzung für seine mentalen Kräfte.

Sie wäre zwar heilbar, dafür müsste er allerdings auf seine Kräfte verzichten. Ähnlich verhält es sich mit Geordi La Forges Visor. In dieser Folge wird auch von Dr. Pulaski angesprochen, dass es mittlerweile ein Verfahren gibt, mit dem er “normal” sehen könnte.

Doch Geordi bleibt vorerst bei seiner erweiterten Sicht mit dem Visor, auch wenn ihm das chronische Schmerzen verursacht. Star Wars bietet auch einige Beispiele, wo Anakins verlorene Hand durch eine gleichwertige Prothese ersetzt wird oder Chirrut Îmwe aus Rouge One, der zwar blind ist, sich aber mithilfe der Macht orientieren und sogar kämpfen kann.

Auch wenn diese Rollen wahrscheinlich inklusiv gedacht sind, ist es doch problematisch, dass dieser angesprochene “Ausgleich” immer dabei sein muss.

Hier zieht der Nützlichkeitsgedanke: “ErSie ist hat zwar diese und jene Behinderung, dafür kann ersie aber XY, was ihn*sie nützlich macht”. Rollen von behinderten Personen ohne diesen Ausgleich sind mir leider in der SF bisher nicht begegnet. Vielleicht wisst ihr ja mehr?

Eine weitere furchtbare, aber oft genutzte Variante, Behinderung in eine Story einzubauen, ist, um einen Antagonisten zu kennzeichnen. Wenn z.B. Missbildungen oder Verstümmelungen als Marker für einen Bösewicht gelten, frei nach: “Der sieht schon so komisch aus, der muss böse sein!”

Zur Folge:

Riva ist offensichtlich sehr von seinem Verhandlungsgeschick überzeugt und verbringt den Flug vor allem damit, mit Troi beim Dinner zu flirten, als mit der strategischen Besprechung.

Bei Solais V angekommen, läuft das erste Treffen mit den Delegationen alles andere als ideal. Einer der Solaisianer ist offenbar wenig an Frieden interessiert und feuert auf Riva, welcher von Riker zu Boden geworfen und damit gerettet wird. Allerdings trifft der Schuss damit Rivas Chor, der komplett vaporisiert wird. Der abtrünnige Schütze wird von seinem Generalniedergestreckt und die Crew beamt zusammen mit Riva schleunigst zurück auf die Enterprise.

Riva ist nun aufgeschmissen und verzweifelt. Troi versucht, seine gebärdenden Aussagen zu verstehen, scheitert aber. Picard weist daraufhin Data an, sich verschiedene Gebärdensprachen anzueignen, was er natürlich extrem schnell bewerkstelligt. Riva gibt sich selbst die Schuld an dem, was passiert ist und weigert sich, die Verhandlungen fortzusetzen, selbst als die Solaisianer darum bitten. Troi soll stattdessen seinen Platz einnehmen.

Als diese vorgibt, sich von Riva ein letztes Mal beraten lassen zu wollen, überzeugt sie ihn schließlich doch davon, dass er der einzige ist, der die Verhandlungen erfolgreich abschließen kann. Sie bringen schließlich zurück auf die Planetenoberfläche und lassen ihn dort zurück.

Rivas Absicht ist es, den Solaisianern seine Gebärdensprache beizubringen, damit sie, indem sie über längere Zeit gemeinsam die Kommunikation mit ihm lernen, auch lernen untereinander zu kommunizieren. 🖖

StarTrekTagebuch, 29. Eintrag TNG S02F04 (The Outrageous Okona) SpoilerAlert

Achtung, diesmal wird es kitschig. Was zuerst nach der Jagd nach einem Han Solo-mäßigem Schmuggler aussieht, wird schnell zu Romeo und Julia im Weltraum, aber von Anfang:

Die Enterprise befindet sich im Omega-Sagitta 12 System, das zwei Zivilisationen beherbergt, Straleb und Atlec (wieder zufälllig sehr menschenähnlich). Diese stehen sich, wenn auch nicht in offener Feindschaft, doch eher in einer zähneknirchenden Waffenruhe gegenüber.

In diesem System greift die Enterprise einen manövrierunfähigen Frachter auf, dessen Captain, Okona, sie ihre Hilfe anbieten. Okona ist das, was man wohl als galaktischen Schürzenjäger bezeichnen könnte, immerhin beginnt er, direkt nachdem er an Bord gebeamt wurde, mit Lieutenant Robinson am Transporterpult zu flirten, die ihn nur wenig später direkt in ihr Quartier einlädt(!).

However, kurz danach treffen zwei Delegationen der jeweiligen Planeten ein. Debin von Atlec bezichtigt Okona seine Tochter Janaar geschwängert zu haben, während Kushell von Straleb behauptet, Okona habe das “Juwel von Thesia” gestohlen, indem er die Freundschaft mit seinem Sohn Benzaan ausnutzte. Hier bringt die Prime Directive Picard wieder in eine Zwickmühle, da er laut dieser eigentlich das Rechtssystem beider Planeten akzeptieren und Okona ausliefern müsste. Da aber, egal an wen er ihn ausliefert, die jeweils andere Seite sofort einen Krieg anfangen würde, beschließt er erst einmal Okona an Bord zu behalten. Auch weil beide Zivilisationen nicht über die technologisch fortschrittlichen Waffen verfügen, um die Enterprise überhaupt zu beschädigen.

Völlig unabhängig davon versucht Data in dieser Folge herauszufinden, was Humor ist, ich gehe aber jetzt nicht weiter drauf ein, da das Ganze doch sehr gezwungen wirkt. Guinan (Whoopie Goldberg) steht ihm beratend zur Seite, aber man findet dadurch auch nicht wirklich viel mehr über sie heraus. Hier wollte man anscheinend einfach nur Zeit füllen, da der main-plot nicht so viel hergibt.

Okona, nachdem er nicht preisgeben will, was er nun wirklich ausgefressen hat, beschließt sich ausliefern zu lassen (wobei immer noch nicht klar ist zu wem) und Picard lädt beide Delegationen auf die Enterprise ein.

Dort stellt sich heraus, dass nicht Okona, sondern Benzaan (der Sohn von Kushell) Janaar (Debins Tochter) geschwängert hat. 😱 Okona hat quasi den Job des Liebesboten gemacht, Botschaften zwischen den beiden überbracht und sie, für heimliche Treffen, von ihren jeweiligen Planeten geschmuggelt. Das Juwel von Thesia hat er tatsächlich bei sich, auch wenn er es technisch gesehen nicht gestohlen hat, sondern im Auftrag von Benzaan zu Janaar bringen sollte, als Zeichen ihrer Verlobung. Wie romantisch 🥰

Die Wogen sind damit kurz geglättet und die beiden Väter stimmen der Verlobung zu. Also eher Romeo und Julia mit Happy End.

Auch wenn diese Folge eher Kitsch als Kult ist, ist mir zum Schluss doch noch ein Thema für ein Speaking of eingefallen:

Speaking of: der gutmütige Schurke als Archetyp.

Im Englischen würde man dazu passender den Begriff “lovable rouge” verwenden. Dabei handelt es sich um einen Archetyp, der meist als Sidekick und Speigelbild für den strahlenden Helden als Hauptcharakter fungiert.

Beispiele dafür sind natürlich Han Solo aus Star Wars, Captain Jack Sparrow aus Fluch der Karibik oder Bronn aus Game of Thrones.

In einer Mischung aus den Archetypen “trickster” und “rebel” ist der lovable rouge als Antiheld meist weitaus verschlagener und ich-bezogener, als der Held, lässt seinen Egoismus aber fallen, wenn es darauf ankommt. Er (oder sie) stolpert vorwiegend zufällig in den plot und den Weg des Helden und folgt im zuerst größtenteils nur aus egoistischen Motiven (meist gegen Bezahlung oder Aussicht auf Reichtum) und macht dann eine Charakterwandlung zum “Held wider Willen” durch, der trotzdem meist irgendwelche “niederen Charakterzüge” behält (meist ein sehr charmantes und verführerisches Auftreten).

Das macht ihn zu einem Charakter der mit seinen “Ecken und Kanten” wesentlich mehr Fläche für Identifikation bietet, als der eigentliche Held und der dadurch oft zum Publikumsliebling wird.

Okona erfüllt diesen Archetyp fasst vollständig, was ihn, bei allen Schwächen der Folge, doch zu einem sehr liebenswürdigen Charakter macht. 🖖