Kategorien
IMHO

Star Trek: Picard

Star Trek: The Next Generation“ konnte mich nie richtig beigeistern: Zu viele Charaktere auf der Brücke, die in die Handlung gequetscht wurden und dazu ein ganzer Stapel an Drehbüchern wie „Hotel Royale„, die schlicht und einfach underirdisch waren. Darüber hinaus nahm sich die komplette Serie deutlich zu ernst, ein Umstand, der erst mit dem Kinofilm „Star Trek: First Contact“ korrigiert wurde.

Patrick Stewart hingegen konnte mich spätestens durch seine Rolle als Erzähler in Rick Wakemans „Return to the Centre of the Earth“ vollends von sich überzeugen. Seine Performance lässt auch heute noch jedes Hörbuch vor Neid verstummen.

Als die ersten Gerüchte aufkamen, ein gealterter Jean-Luc Picard würde sich noch einmal abseits der Sternenflotte in ein neues Abenteuer stürzen, klang dies nach einem spannenden Projekt – spätestens seit dem Oscar-prämierten „Erbarmungslos“ ist klar, was man aus einer solchen Grundidee machen kann.

Leider entwickelte sich „Star Trek: Picard“ zur Serienenttäuschung 2020. Der Start in die ersten Folgen war gar nicht mal so schlecht, aber leider dümpelt die Serie über weite Strecken dahin, um nach gefühlt viel zu langer Zeit in einem enttäuschenden und ärgerlichen Finale zu gipfeln.

An der Grundidee gibt es dabei wenig zu meckern, diese ist durchaus stimmig und Star Trek-kompatibel, was aber an Storyline und Plot-Holes darum gebastelt wurde, ist schlicht unterirdisch.

Hier ein paar nicht Spoiler-freie Beispiele, im Wesentlichen auf das Finale bezogen:

Wo ist Narek am Ende der Staffel abgeblieben? Sitzt er in einer Zelle? Wurde er getötet? Ist er geflohen? Haben ihn die Romulaner mitgenommen oder die Sternenflotte? Im Laufe der Serie zu einem Hauptcharakter aufgebaut, fehlt am Ende jede Spur. Fakt ist: er ist  nicht da, dieser Umstand wird nicht mal erwähnt und keinen interessiert’s.

Das Ende seiner Schwester Narissa Rizzo ist ebenfalls mehr als dürftig. Der Charakter hätte besseres verdient, als im Verlauf einer kurzen Rangelei von Seven of Nine in die Tiefe des Artefakts geschubst zu werden. Letztere ist zwar mit ihrer coolen Art mit Abstand der beste Sidekick der Serie, wäre aber vielleicht in „Firefly – Der Aufbruch der Serenity“ besser aufgehoben.

Warum gibt die Sternenflotte dem eigentlich dem Reservisten William Thomas Riker das Kommando über die komplette Schutzmission? Der Grund dahinter ist vermutlich Fan-Service, aber das sollte kein Handlungsmotiv für Charaktere in einer Geschichte sein. Man hätte zumindest einen Kniff wie „Picard und Riker lösen eine Situation durch eine Referenz auf irgendwas, das nur sie kennen“ einbauen können, um wenigstens etwas Plausibilität herzustellen.

Tiefpunkt in Sachen Plausibilität und Krönung in Sachen schlechtes Drehbuch ist das Dingsbums mit Griff, das einfach nach dem Motto „Use your imagination“ genau das macht, was sich der Halter gerade so wünscht. Muß man nicht erklären und kann man immer dann prima einbauen, wenn man keine plausible Lösung einer Situation erarbeiten möchte.

Daß nicht Narek sondern Sutra (die Synth im roten Kleid) Saga (die Synth im gelben Kleid) umgebracht hat, ist eigentlich jedem außer den Charakteren vor Ort klar. Sutra wird im ersten Teil des Finales als Gegenspieler aufgebaut, dann einfach abgeschaltet und keinen interessiert’s.

Daß Picard nicht wirklich stirbt, ist spätestens in dem Moment klar, als zum zweiten Mal über den noch unvollendeten Synth geschwenkt und irgendwas von „Transfer“ erzählt wird, abwechselnd mit Szenen, die auf Picards Krankheit referenzieren. Dieser ungefragt nach seinem Tod durchgeführte Transfer in eine identisch aussehende Hülle mit Alterungsprozess und ohne Superkräfte (aber auch ohne Krankheit) führt den kompletten Handlungszweig rund um Picards Erkrankung ad absurdum. Richtig dünn und unglaubwürdig ist aber, daß Picard, der noch immer mit seiner Vergangenheit als Locutus kämpft, sein unfreiwilliges Synth-Dasein mehr oder minder kommentarlos freudig akzeptiert.

Appropos Locutus: es ist schade, daß die Borg (bzw. was von ihnen übrig ist) mitsamt Kubus hauptsächlich als düstere Bühendeko mißbraucht werden, statt sie wirklich in die Handlung einzubeziehen.

Die komplette Data-Sequenz ist zwar ebenfalls gut gemeinter Fan-Service, aber gut gemeint bedeutet nicht zwangsweise auch gut gemacht. So zieht sich das Gespräch zwischen Picard und Data zu sehr in die Länge und man ist irgendwann einfach froh, daß Picard endlich durch die Tür geht. Gleiches gilt auch für Datas Sterbesequenz, die viel zu kitschig geraten ist.

Am Ende stehen alle wieder an Bord der La Sirena und alles ist gut. Alles?

Admiral Picard ist wieder zurück, Seven of Nine offensichtlich Crew-Mitglied, der Aufenthaltsort von Narek ist genauso irrelevant wie der Mord an Bruce Maddox. Wie konnte Oh eigentlich die Sternenflotte unterwandern? Was genau war eigentlich Soji Ashas Mission? Was ist mit Nariks und Narissas Eltern? Was ist mit Raffis Sohn? Was passiert mit Synthville, was mit dem Kubus und überhaupt …? Offensichtlich interessiert das außer den Zuschauern niemanden.

Jean-Luc Picard ist tot und was sein Synth-Ebenbild in Clone Trek: Picard noch erlebt, wird voraussichtlich die oben gestellten Fragen auch nicht mehr beantworten.

Kategorien
Funstuff

Pandemiebär

Kategorien
IMHO

Zeitsynchronisierung mit systemd

Sofern ein Linux-System systemd verwendet muß zum Abgleich der Systemzeit – sofern dieses nicht als Zeitserver für andere Systeme arbeiten sollen – kein ntp mehr insalliert werden.

Es reicht die Anpassung der Datei „/etc/systemd/timesyncd.conf“

$ sudo vi /etc/systemd/timesyncd.conf

in welcher dann in der Zeile „NTP=“ der gewünschte Zeitserver eingetragen wird.

[Time]
NTP=zeitserver.local
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

Nach Änderung der Datei wird der Dienst „systemd-timesyncd.service“ neu gestartet – das war’s.

$ sudo systemctl restart systemd-timesyncd.service

Anschließend kann die Konfiguration des Diensts mittels

$ timedatectl status
               Local time: Mo 2020-04-27 21:19:40 CEST
           Universal time: Mo 2020-04-27 19:19:40 UTC
                 RTC time: Mo 2020-04-27 19:19:40
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

überprüft werden. Wird der Status des „NTP service“ als „inactive“ angezeigt, so ist ein

$ timedatectl set-ntp true

notwendig, um die Synchronisation zu aktivieren. Detaillierte Informationen erhält man entweder über

$ timedatectl timesync-status
       Server: 1.2.3.4 (zeitserver.local)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 4
    Reference: AF0149C
    Precision: 1us (-21)
Root distance: 31.249ms (max: 5s)
       Offset: -1.759ms
        Delay: 1.972ms
       Jitter: 0
 Packet count: 1
    Frequency: +17,237ppm

oder mit Hilfe von

$ timedatectl show-timesync
SystemNTPServers=zeitserver.local
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=zeitserver.local
ServerAddress=1.2.3.4
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=2min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=4, Precision=-21, RootDelay=17.333ms, RootDispersion=18.478ms, Reference=AF0149E, OriginateTimestamp=Mon 2020-04-27 21:05:29 CEST, ReceiveTimestamp=Mon 2020-04-27 21:05:29 CEST, TransmitTimestamp=Mon 2020-04-27 21:05:29 CEST, DestinationTimestamp=Mon 2020-04-27 21:05:29 CEST, Ignored=no PacketCount=2, Jitter=329us }
Frequency=1353001
Kategorien
IMHO

Update Google Pixel von LineageOS 16 auf 17.1

Vor wenigen Tagen wurde LineageOS 17.1 veröffentlicht – Zeit auf die aktuelle Version zu wechseln und hierbei gleich neue Lineage Recovery auszuprobieren. Der in LineageOS eingebaute Updater erkennt zwar, daß eine neue Version vorliegt, kann das Update aber nicht manuell durchführen.

LineageOS

Die sehr kurz gehaltene Upgrade-Doku spart leider aus, daß man das Lineage Recovery nicht wie bisher für TWRP empfohlen mittels „fastboot boot …“ direkt starten kann, denn dann erscheint lediglich eine Fehlermeldung:

$ sudo fastboot boot lineage-17.1-20200418-recovery-sailfish.img
...
FAILED (remote: dtb not found)

Ein Blick in die Installations-Doku zeigt, daß die Lineage Recovery installiert werden soll:

$ fastboot flash boot lineage-17.1-20200418-recovery-sailfish.img

Anschließend kann die Recovery gestartet werden (Power & Volume down) und über die Menüpunkte „apply update“ / „apply from adb“ empfangsbereit gemacht werden. Die eigentliche Installation des Updates ist unspektakulär:

$ adb sideload lineage-17.1-20200418-nightly-sailfish-signed.zip

GApps (optional)

Die Dokumentation weist darauf hin, daß es wichtig ist, den Zustand bzgl. eventuell verwendeter GApps beizubehalten, d.h. wenn welche installiert waren, müssen sie vor dem ersten Start des Betriebssystems aktualisiert werden.

Hierzu wird die Recovery erneut gestartet und bereit zum Datenempfang gemacht, dann kann das Paket installiert werden.

$ adb sideload open_gapps-arm64-10.0-pico-20200418.zip

Root

Das bisher für LineageOS 16 angebotene „addonsu“ ist aus technischen Gründen leider nicht mehr erhältlich

… our usual provided AddonSU zip to enable root access for the user is no longer feasible

weshalb auf Alternativen wie Magisk ausgewichen werden muss.

… if you want root for apps, flash magisk zip in recovery. Just don’t flash it during initial lineage install, as it’s known to cause bootloop if you do.

Wichtig ist, Magisk nicht zusammen mit LineageOS zu installieren, ob hier ein erneuter Start der Recovery reicht oder ein Systemstart erfolgen sollte, ist nicht ganz klar. Die Installation erfolgt analog zu LineageOS bzw. den GApps am sinnvollsten nach einem Systemstart.

$ adb sideload Magisk-v20.4.zip

Nacharbeiten

Nach der Installation kam von Magisk keine Aufforderung von AFWall+ zum Erhalt von Root-Rechten. Nach einem weiteren Reboot kam dann aber die erwartete Aufforderung.

Der Captive-Portal-Check lief trotz übernommener AFWall+-Einstellungen immer auf einen Verbindungsfehler, die Liste der Freigaben musste noch um „[1073] Network Stack, com.android.server.NetworkPermissionConfig“ erweitert werden, ansonsten wurde dauerhaft das „X“ beim Verbindungsstatus angezeigt und einige Apps haben erst gar nicht versucht, sich mit dem Internet zu verbinden.

Kategorien
Funstuff

75 Jahre Ritchie Wernochmal?

Die Heidenheimer Zeitung widmet dem „ewigen Wüterich“ zum 75. Geburtstag einen eigenen Artikel

… und gratuliert mit einem irritierenden Bild: die Haare sind deutlich zu lang und zu hell, die Gitarre zu blau und das Shirt zu neumodisch. Abgebildet ist Ritchies Nachfolger (bei DEEP PURPLE) Steve Morse, der allerdings 1954 geboren wurde und nicht 1945.