KI ist heute überall. Besonders gerne aber dort, wo bisher einfach nur „Software“ drin war, die einen mehr oder weniger intelligenten Eindruck gemacht hat (was auch häufig im Auge des Betrachters lag) – mit anderen Worten: die Begrifflichkeit wird inzwischen inflationär genutzt und es wird dringend eine Neudefinition gebraucht.
Mein Vorschlag: „Die Software enthält mehr als ein if-then-else-Konstrukt.“
Lange nichts mehr zu Graal(VM) geschrieben. Eigentlich überflüssig, diese einleitenden Worte zu verwenden, denn so wenig, wie ich hier schreibe, ist es naturgemäß bei und zu praktisch jedem Thema lange her.
Jedenfalls gibt es ein neues Release, quasi passend und synchron zum Erscheinen von Java 21. Viel hat sich getan im Java-Universum – Projekt Loom aka „Virtual Threads“ hat es nun endlich final ins Release geschafft, etwas das Projekt Panama aka „Foreign Memory and Function and Vector API“ leider nicht vergönnt war. Egal, nach dem LTS-Release ist vor dem LTS-Release, machen wir solange halt JNA. Aber ich schweife ab.
Die GraalVM-Release-Notes vermelden neben den fast schon üblichen – teilweise weiterhin dramatischen – Verbesserungen im Bereich Memory Footprint, Startup Time und Throughput zwei aus meiner Sicht ganz wichtige Neuerungen: zum einen ist man das unselige „gu“-Zeugs los geworden. Bedeutet: man hat nicht mehr ein Graal-JDK rumliegen das man per „gu“-Aufruf quasi in situ und systemspezifisch anreichert und updated – z.B. mit Truffle-Sprachen – sondern die ganze polyglotte Geschichte ist nun in „einfache“ Maven-Abhängigkeiten gewandert, d.h. man kann (bzw. sollte können – ich hab’s nicht selbst verifiziert) nun z.B. tatsächlich sinnvoll die Rhino- bzw. Nashorn-Engine tatsächlich in Rente schicken und stattdessen die Javascript-Implementierung von Graal verwenden. Das ganze läuft unter dem Namen „Truffle Unchained“. Schöne Sache, weil dadurch die ganze Geschichte mit der polyglotten Programmierung endlich anständig und erwartungskonform ins Java-Ökosystem integriert wird anstatt eine GraalVM-Insellösung zu bleiben. Man sollte nur darauf achten, die „community“-Varianten als dependency anzuziehen, es sei denn man will sich mal wieder durch eine neue Variante einer Oracle-Lizenz („GFTC“) kämpfen, und gleichzeitig immer auf der Hut sein, dass Oracle nicht mal wieder was Signifikantes daran ändert.
Zweite wichtige Geschichte: Der G1-GC ist jetzt vollständig integriert und optimiert – im Juni-Release war davon ja schon einiges zu sehen, jetzt gibt es vernünftige Ergebnisse. Die GraalVM hatte da ja Nachholbedarf v.a. im Native-Image-Bereich, was für teils erhebliche Laufzeitnachteile gesorgt hat. Nicht zuletzt durch diese Neuerung ist es gelungen, dass AOT jetzt performancetechnisch beim Durchsatz auf demselben Niveau operiert wie „heated up HotSpot JIT“ – lange Zeit war es ja eine Art Tradeoff, ob der Startup-Time-Vorteil von Native Image wichtiger ist oder der Throughput-Vorteil des HotSpot-JIT. Diese Überlegung kann man sich jetzt sparen, wenn die Benchmarks von den Graal-Entwicklern der Wahrheit nahekommen.
Für Mac-Freunde mit ARM-CPU und Linux-on-ARM-Exoten vielleicht auch noch interessant: AArch64 aka ARM 64bit ist nun auch verfügbar. War es wohl schon bei früheren Graal-Releases, ich hab’s nur nicht mitgekriegt. Aber der oben genannte G1-GC hat es wohl jetzt erst in die AArch64-Native-Image-Implementierung geschafft. Warum auch immer…da will ich nicht länger drüber nachdenken.
Neulich so in einem fernen Urlaubsland meiner Wahl. Nutzung von werbefinanzierten Streamingdiensten. Ich will nicht ins Detail gehen und nenne sie stellvertretend mal „YouTube“ und „Spotify“. Beide Dienste jedenfalls verfügen über weitergehende Informationen über mich – oder zumindest gehe ich davon aus, man hört ja so viel von der Datensammelwut der Anbieter. Also z.B. Informationen wie „Mailadresse“, „Name“ und „aus welchem Land wurden bisher die Dienste genutzt“ und „in welcher Sprache wurde bisher Content bevorzugt abgerufen“.
Nun sitze ich also hier im Urlaubsland meiner Wahl – ich will es nicht spoilern, aber es ist nicht deutschsprachig – und erfreue mich an Werbeeinsprengseln in einer mir fremden Sprache. Nämlich der des Urlaubslandes. Die fortschrittliche Technologie erlaubt es also, meinen derzeitigen Standort zu erkennen. Und bezieht dieses (in den 80ern hätte man gesagt: erstaunliche) Wissen dämlicherweise in die Entscheidung ein, in welcher Sprache mir Werbung eingespielt wird. Weil ich natürlich, sobald ich eine Landesgrenze überquere, plötzlich die Sprache des Ziellandes bevorzuge.
Es braucht schon fortgeschrittene KI, um die Wirksamkeit von Werbung derart nachhaltig zu torpedieren. Oder sehr dumme Entscheidungen von Produktverantwortlichen.
Man geht ja als ITler gerne mit der Zeit. Mindestens, um sich dann darüber aufzuregen, dass früher alles besser war.
Neulich habe ich einen neuen Drucker in Betrieb genommen. Geht jetzt per App. Klingt nach einer guten Idee, und war es letztlich auch. Aber zwischendrin dann etwas Schockierendes: bei der Erstbefüllung der Tintentanks kündigte die App an, dass das Befüllen einer Farbe (bei meinem Modell insgesamt 6) nicht weniger als 40 Minuten dauern soll. Gott sei Dank nur eine falsche Einheit in der App, die gedruckte Schnellanleitung sprach dann korrekt von 40s, und genau so war es.
Weiterer kleiner Zwischenfall: während der Drucker dann die Tinteninitialisierung vornimmt, schlägt die App vor, doch gleich mal währenddessen (der Initialisierungsvorgang dauert nicht weniger als 7 Minuten) das WLAN einzurichten. Gute Idee. Dazu braucht man das Admin-Passwort des Druckers. Das steht nur im Innern des Druckers (beim Anheben der kompletten oberen Einheit). Das Anheben ist aber genau das, was man während der Tinteninitialisierung AUF GAR KEINEN FALL machen darf, wie der Drucker auf seinem Display verkündet. Sagt einem die App aber nicht. Aber der erfahrene Installateur elektrischer Geräte hat vorher natürlich alle papiernen Handbuchfetzen (die meisten davon mit völlig überflüssigen Sicherheitshinweisen der Kategorie „Gerät eingesteckt nicht unter Wasser betreiben“ oder „auf Frequenz 2400 MHz wird mit 53 nW gesendet“) akribisch durchgearbeitet und hat deshalb das Passwort schon vorher notiert. Auch merkwürdig in der App: man hat es für notwendig erachtet, eine eigene Tastatur zu implementieren. Die echt komisch aussieht. Und für die Eingabe sicherer Passwörter gar nicht taugt. Aber man kann einfach auf die Standardtastatur zurückschalten. Könnte für den unbedarften Anwender aber schon eine Extrahürde sein, und der Sinn dahinter erschließt sich mehr jetzt nicht so direkt.
Auch eine App löst halt nicht automatisch alle Probleme, vor allem wenn vom Hersteller schlampig gearbeitet wird. Drucken tut er aber gut. Und das ist in diesem Falle wirklich die Hauptsache.
Es war mal wieder Bundeswarntag mit dem ersten vollständigen Probelauf von DE-Alert, der deutschen Implementierung des EU-Standards EU-Alert, der auf SMS-CB basiert. Also das, was seit mehr als 20 Jahren in USA und Japan am Start ist, und in einigen EU-Ländern wie den Niederlanden gerade 10-jähriges Jubiläum feiert.
Der Cell Broadcast hat hier vor Ort gut funktioniert, alle angeschalteten Mobiltelefone haben gewarnt. Anderswo war das wohl nicht so erfolgreich, aber bei einem Probelauf kann im Gegensatz zum Ernstfall ja auch der Fehlschlag als Erfolg gewertet werden. Die Berichte zeigen ein uneinheitliches Muster des Nichtfunktionierens, scheinbar zufällig verteilt über alle Smartphone-Modelle und Betriebssysteme und Netzbetreiber.
An einer Stelle berichtete jemand, dass bei seinem Xiaomi-Smartphone die Meldung mit „MESSAGE FROM THE PRESIDENT“ betitelt war. Für mein nerdiges Ich ist das wie ein großes Schild „Bitte hier graben“. Und ich habe gegraben. Ging sogar recht schnell.
Ergebnis: Die für SMS-CB und EU-Alert relevante EU-Norm ist ETSI TS 102 900. Laut Tabelle 1 in Abschnitt 5.2.1 gibt es die höchste Prio von Warnmeldungen mit der Bezeichnung „EU-Alert Level 1“, die identisch ist mit dem Level „Presidential Alert“ in CMAS (Commercial Mobile Alert System), dem US-Standard, in dem deren PWS (Public Warning System) auf SMS-CB-Basis spezifiziert ist.
Passiert also vermutlich bei älteren Android- und iOS-Versionen, die halt nur den US-Standard aus grauer Vorzeit kennen und nicht den EU-Neuaufguss davon von 2019. Wobei einige EU-Länder wie oben angesprochen auch schon seit 10 Jahren das implementiert haben, also doch eher „schlampig implementierte Software oder Übersetzung“.
Wichtiges Detail am Rande: diese höchste Dringlichkeit ist von der „Opt-Out“-Möglichkeit durch den Benutzer ausgenommen. Denn wer würde schon seinen Präsidenten ignorieren wollen. Gut, damals konnte sich vermutlich niemand Frank-Walter Steinmeier im höchsten Amt vorstellen.
Eine nicht uninteressante Auswertung der am häufigsten benutzten (und damit höchstwahrscheinlich eher unsicheren) Passwörter ist mir heute über den Weg gelaufen. Nachfolgend einige tiefschürfende Erkenntnisse daraus, nicht nur Passwörter betreffend.
In Deutschland auf Platz 58: „sonnenschein“. Benötigte Zeit zum Passwort-Knacken laut dieser Liste: „3 Jahren“. Zeit, bis der einfache Plural deutscher Wörter korrekt auf originär englischsprachigen Webseiten angekommen ist: voraussichtlich mehrere Jahrzehnte. Zeit, bis in allen Länder-Auswahllisten „Deutschland“ alphabetisch nicht bei „G“ einsortiert wird: unendlich.
Früher war die Welt noch einfach. Wenn man Java wollte (und ich rede jetzt nur mal von Java SE, sonst gibt das gleich wieder eine hundertseitige Abhandlung), ging man zu java.sun.com (oder gar zu java.de), hat JDK oder JRE seiner Wahl runtergeladen, und gut war. Klar, eher nicht das JRE, weil Sun irgendwann mal anfing, irgendwelche Ad-Ware damit zu bundeln, und weil es immer Installer-gebunden war und nicht als schnödes nacktes ZIP zur Verfügung stand.
Heute, im Zeitalter von OpenJDK auf der einen Seite und Oracles wöchentlich wechselnden Lizenzbedingen auf der anderen Seite schaut man sich natürlich nach einem passenden „Stamm-Provider“ eines OpenJDK-Pakets an. AdoptOpenJDK war früher mal meine erste Wahl – Auswahl zwischen HotSpot und OpenJ9, sowohl JRE als auch JDK, viele Plattformen unterstützt, sowohl x86 als auch x64. Inzwischen ist das zu „Eclipse Temurin“ von „Adoptium“ gemorphed, die Auswahl zwischen HotSpot und OpenJ9 scheint es nicht mehr zu geben, aber dafür gibt es bei IBM (wider besseren Wissens setze ich jetzt mal einen Link, wohl wissend, dass der in wenigen Monaten auf Nimmerwiedersehen einer Restrukturierung der IBM-Webpräsenz zum Opfer fällt) ein OpenJDK namens „IBM Semeru“, in den Geschmacksrichtungen „Certified Edition“ oder „Open Edition“, für den typischen IBM-Bauchladen (System/390, AIX) aber auch für Windows/Linux/MacOS als OpenJDK-OpenJ9-Bundle. Sinn? Übersichtlichkeit? Keine Ahnung. Derweil notiere ich: für die Top-IBM-Plattformen S/390 und AIX gibt es als neueste Version Java 11. Auf IBM-Plattformen meint „long term“ eben meistens die lange Zeit, bis aktuelle Versionen zur Verfügung stehen. Meine letzte gute Erfahrung mit IBM JDKs war mit Java 1.3, als auf einem linux-basierten ThinClient mit fast nacktem XServer das IBM-Java deutlich besser mit TrueType-Fonts umgehen konnte als die Sun-Konkurrenz. Lange her. Ansonsten zeichnete sich die IBM-Variante oftmals durch höheren Speicherverbrauch aus (ich erinnere mich an die Class-Sharing-Lösung in JDK 1.5, die zwar relativ gesehen pro zusätzlicher JVM-Instanz eine gute Menge Speicher sparte, aber absolut gesehen gegenüber der Sun-Lösung leider deutlich mehr verbrauchte) und dazu kamen noch abstruse Bugs im JIT-Bereich sowie irgendein dubioses Encoding-Problem im XML-Bereich, das mir den Schlaf raubte.
Ich will jetzt nicht alle OpenJDK-Distributionen aufzählen, die Menge ist inzwischen unüberschaubar, Anbieter kommen und gehen, zeichnen sich durch unvollständige Unterstützung diverser Plattformen aus, haben undurchschaubare Eigeninteressen…unterm Strich habe ich mich jetzt auf Bell Software eingeschossen, die bieten eine OpenJDK-Distribution namens „Liberica JDK“ zum Download an. Besonderheit aus meiner Sicht: alle Versionen bis zurück zu Java 8, alle für mich relevante Plattformen, sowohl JRE als auch JDK, sowohl x86 als auch x64, und als besonderen Service auch noch „Full JRE“ und „Full JDK“, ein Bundle bestehend aus Java SE und OpenJFX. Und dazu noch pre-built docker images, z.B. in einer Minimalversion mit Alpine Linux mit musl-Standard-Lib. Seit Längerem verwende ich praktisch nur noch die diversen Bell-Distributionen, alles funktioniert prächtig – ich habe aufgehört, nach besseren Alternativen zu suchen.
Eine interessante, aus meiner Sicht aber noch eher experimentelle Variante: OpenJDK in der GraalVM Community Edition. Mit dem Graal-JIT, der je nach Workload durchaus Vorteile bringen kann. Derzeit downloadbar als Version 22.1 in den Geschmacksrichtungen Java 11 und Java 17. Quasi der Außenseitertipp unter den OpenJDK-Distributionen.
Zum Schluss noch ein typisches „wann ist mir denn das entgangen“ beim Abprüfen, ob noch alle Anbieter an die ich mich erinnere im Rennen sind: was ist eigentlich JITServer? Das habe ich gerade zum ersten Mal gehört bzw. gelesen. Es gibt aber schon seriöse Infos zu diesem Thema von Januar 2020, mit Andeutungen eines existierenden Prototyps namens „JIT-as-a-Service“ schon Mitte 2019. Auch so eine IBM-OpenJ9-voll-das-fancy-Cloud-Zeugs-Geschichte. Dieses Java-Ökosystem kann einen in den Wahnsinn treiben, wenn man da auf dem Laufenden sein und bleiben will. Nächstes Mal zu diesem Thema: warum fängt man mit „Project Leyden“ an, wenn man schon Graal hat? Die Antwort wird wohl eine ähnliche sein wie bei „warum Java Modules, wenn es schon OSGi gibt“. Es kann was Gutes draus werden, aber man weiß es noch nicht, und es ist ein Haufen Arbeit auf einer ganz langen Zeitschiene. Und entlang dieser Zeitschiene liegen jede Menge Leichen aus früheren gut gemeinten Ansätzen.
Neulich im Dunstkreis von Zahlungsdienstleistungen. Ich wollte bei einem Vertrag meine Mobilfunknummer ändern. Übers Webinterface eingeloggt und die Nummer geändert. Ein Popup informiert mich darüber, dass das leider gar nicht so einfach möglich sei, denn die Mobilfunknummer werde mittels SMS-TAN als zweiter Faktor für Authentifizierung genutzt. Ich hätte die Wahl zwischen Brief-TAN – dann müsse ich aber beim Service-Center anrufen und dies veranlassen – oder könnte die App nutzen, dort die Mobilfunknummer ändern, und bekäme dann eine SMS-TAN.
So weit, so plausibel – natürlich ging ich davon aus, dass ich dazu dann zwei Handys (oder in Zeiten von Dual-SIM: zwei Rufnummern) benötige, einmal die alte hinterlegte Nummer und einmal die neu zu hinterlegende Nummer. Die Frage „warum kann ich nicht einfach mit der alten Nummer und einer SMS-TAN die neue Nummer authentifizieren“ stellte ich mir, beantwortete sie mir aber mit dem naheliegenden „die Software kann das vermutlich nicht, weil einer vergessen hat, diesen Fall zu spezifizieren“.
Also die App auf dem neuen Handy installiert, über die App eingeloggt (gleiche Credentials wie das Webinterface), Mobilfunknummer geändert, und die SMS-TAN auf die neue (!) Mobilfunknummer bekommen. Also auf dasselbe Gerät, auf der die App läuft.
Freunde: so funktioniert das nicht mit der 2-Faktor-Authentifizierung. Das ist einfach nur Bullshit und Pseudo-Security.
Neulich am Windows 10-Rechner meiner Wahl. Daten werden auf einen USB-Stick kopiert zwecks Transfer zu einem nicht netzwerkfähigen Gerät. Zielformat FAT32. Kommt bei einer Datei mittendrin folgende Fehlermeldung:
„Fehler x80240022: Im Laufwerk befindet sich eine falsche Diskette. Legen Sie %2 (Datenträgernummer: %3) in Laufwerk %1 ein.“
Nur echt mit nicht aufgelösten Platzhaltern. Das einzig Gute, was man über diese Fehlermeldung sagen kann: sie ist dermaßen absurd neben der Spur, dass man wenigstens nicht in Versuchung kommt, einer falschen Fährte zu folgen.
Gruseliger als diese Fehlermeldung – und da liegt die Latte wahrlich hoch – ist nur, wenn man nach der Fehlernummer googelt und diverse Artikel in der Microsoft-Knowledge-Base darüber findet. Mein Favorit: wenn der Fehler unter Windows 2000 auftaucht, wenn man den Microsoft Defender updated, muss man die Root Certificates erneuern oder installieren…
Schon früher in diesem Blog habe ich mich als Ada-Anhänger geoutet. Ich habe in Ada eine komplette CD-/DVD-/BluRay-Brenner-Software geschrieben, weiß also so ungefähr von was ich rede. Die weitaus meisten Zeilen Code habe ich allerdings in anderen Programmiersprachen, vornehmlich in Java, verbrochen.
Schon als ich damals 1996 nach vielen Jahren Ada meine ersten Gehversuche mit Java (Version 1.0.2, die Programmier-Opas erinnern sich) machte, rieb ich mir verwundert die Augen. Wie kann man Mitte der 90er, mit so vielen Vorarbeiten wie Algol und Smalltalk und Pascal und Modula und Ada eine derart rudimentäre, vor allem bei den Basisdatentypen so schwach aufgestellte Sprache wie Java auf den Markt werfen? Es wirkte wie eine minimale OO-Erweiterung wie es sich C-Fans ausmalen würden. Keine Generics, keine Enums, keine funktionalen Elemente, kein vernünftiges Scoping (Methode-in-Methode), kein Operator Overloading, keine „unsigned“-Typen, ein sehr schwaches Konzept der Nebenläufigkeit…vom Sprachstandpunkt aus wirkte es wie ein Zurück-in-die-70er. C, eine Prise Objektorientierung, der Rest des Gehirnschmalzes steckte dann in der Standardbibliothek und der virtuellen Maschine nebst der Applet-Idee.
Seither ist viel Zeit vergangen. Jede Menge Programmiersprachen kamen und die meisten gingen auch wieder. Im Bereich systemnahe Programmierung scheint derzeit Rust immer noch der Hype der Stunde zu sein. Und jeder Ada-Kenner fragt sich: was soll denn an Rust eigentlich so besonders sein? Wäre da Ada nicht von Anfang an und seit 1980 die bessere Wahl gewesen? Um Salz in die Ada-Wunde zu streuen, arbeiten sich die Rust-Evangelisten ja auch immer an C als Benchmark ab, anstatt mal über den Tellerrand zu schauen.
Eine Frage kann ich jedenfalls beantworten: warum Ada keine weitere Verbreitung geschafft hat. Das liegt schlicht am (fehlenden) Ökosystem. Vor GNAT gab es keinen bezahlbaren, qualitativ hochwertigen Compiler. Und seit GNAT gibt es leider immer noch keine problemlos und überall einsetzbare Toolchain. Die von AdaCore gepflegten Pakete haben schon auf der Windows-Plattform ihre Stabilitätsproblemchen wenn man auf die „Libre“-Schiene setzt. Andere CPUs als x86/x64 werden sowieso nur sparsam unterstützt. Jahrelang musste man, wenn man für ARM compilieren wollte, ganz bestimmte FSF-GCC-Versionen einsetzen und extreme Vorsicht walten lassen – meist kam man nicht umhin, GNAT selbst zu bootstrappen. Dazu das IDE-Problem: egal ob Plugins für die großen IDEs wie Eclipse, VisualStudio oder NetBeans, oder Standalone-Pakete wie GPS: die Qualität war bestenfalls durchwachsen, teilweise katastrophal schlecht oder in den Anfängen stecken geblieben (Projekt Hibachi). Und manchmal auch nur ein klassisches „one-off“ wie GNATbench im Libre-Bereich. Geholfen hat sicher auch nicht AdaCore’s Taktik, die Libre-Toolchain GPL-only zu machen. So mussten interessierte Entwickler, die nicht an die GPL gebunden sein wollten, auf die FSF-GCC-Variante ausweichen, mit den ganzen zusätzlichen Reibungsverlusten. Oder die one-offs wie „GNAT for JVM“ oder „GNAT for .NET“ – sowas sorgt einfach nicht für das Gefühl von Stabilität und Verlässlichkeit, eigentlich Stärken von Ada.
Dadurch ergab sich auch eine große Distanz zwischen Hobby-Programmierern und der Profi-Welt: Ada ist ja sehr verbreitet in gewissen Industriebereichen, vor allem Militär und Luftfahrt. Dort dominieren die extrem teuren Ada-Toolchains und IDEs mit ihren zig Zertifizierungen und Gedöns, die Bemühungen z.B. von Aonix mit ObjectAda im Zeitalter von Windows 95 und NT waren auch eher kurzlebiger Natur. Und so leben die Profis in ihrer Welt, und die Hobby-Programmierer verwenden weit überwiegend lieber eine leichter zugängliche Programmiersprache.
Nimmt man dann noch die Problematik „Drittbibliotheken“ dazu, die in der Ada-Welt eher sparsam vorhanden waren, hat man eben einfach kein konkurrenzfähiges Ökosystem, sondern Gefrickel. Untauglich für Neueinsteiger, mühsam für interessierte Hobbyisten, frustrierend selbst für Profis. Immerhin gibt es inzwischen Bemühungen, einen Ada-spezifischen Paket- und Library-Manager zu entwickeln mit dem schönen Namen Alire. Noch Beta. Too little, too late. Auch die Bemühungen um Ada-Unterstützung in Visual Studio Code unterzubringen sind respektabel, stecken aber noch in den Kinderschuhen und sind mit dem Stand anderer Sprachunterstützung wie beispielsweise für Python noch lange nicht vergleichbar.
Will man heute eine Programmiersprache in den breiten Einsatz bringen, reicht eben ein Compiler und ein bisserl Toolchain drumrum bei weitem nicht aus. Man braucht über viele Systeme verfügbare, stabile Toolchains. Man braucht IDEs. Man braucht Bibliotheken. Beispielanwendungen. Dokumentation. Tutorials. Viele Seiten, die sich mit Ada beschäftigen, scheinen direkt dem Internet der 90er entsprungen zu sein (hier z.B. eine ZIP-Bibliothek). Damit kann man bei den Entwicklern von heute einfach nicht mehr in der Breite landen und bleibt im Exotendasein stecken.
Es ist unendlich schade um das Potenzial, das in Ada steckt. Aber meine Prognose lautet: das wird nix mehr. Ada wird zurecht vergessen bleiben.