Oracle und VisualVM

Eines meiner Lieblings-Java-Tools ist die VisualVM – vor wenigen Tagen wurde Version 1.4 released, mit offiziellem Java 9-Support. Die Vorgänger-Version 1.3.9 funktionierte schon leidlich mit Java 9, aber „offiziell“ ist bekanntlich immer besser.

Und das führt uns zum traurigen Teil der Geschichte, nämlich Oracle’s Entscheidung, JDK 9 ohne die VisualVM auszuliefern (neben der grandiosen Idee, die bisher per Definition in ISO-8859-1 vorliegenden .properties-Dateien einfach mal in UTF-8 zu lesen, sicher die schlechteste). Und das ohne vernünftigen Ersatz – Java Mission Control hat bekanntlich eine üble Lizenzeinschränkung bezüglich kommerziellem Einsatz, und die gute alte JConsole ist eben genau das – alt. Mit VisualVM war es schön einfach, selbst unbedarfte User „mal schnell“ einen Heapdump oder Threaddump ziehen zu lassen. Vorbei.

Immerhin ist die Version 1.4 ein Lebenszeichen, ich hatte schon Schlimmeres befürchtet. Der Hinweis, dass 1.4 nun auf der NetBeans-Plattform Version 9 basiert (wenn auch einer Entwicklungsversion), ist gleichzeitig auch ein Lebenszeichen von NetBeans, das bekanntlich vor einiger Zeit von Oracle zu Apache gewechselt ist – seither hoffen alle, dass das besser läuft als bei OpenOffice. NetBeans 8.2 war ja von Oktober 2016, seither waren die News eher sparsam. Ich bin zar nie mit NetBeans warm geworden, aber etwas Konkurrenz tut sowohl Eclipse als auch IntelliJ immer gut.

Amüsantes Detail aus den Release Notes von VisualVM 1.4: Windows 10 ist offenbar keine unterstützte Plattform…

Frohes Fest, guten Rutsch

2017 war ein eher sparsames Blog-Jahr in meiner IT-Abteilung. Gewisse Dinge in der IT frustrieren mich zunehmend. Sei es die beinahe grenzenlose Naivität gewisser Teile der agilen Bewegung, die Entscheidung von eBay einen unglaublich schlechten automatischen Übersetzungsmechanismus für Angebote aus dem Ausland einzusetzen (natürlich nicht abschaltbar), die unentwegte Ankündigung des autonomen Fahrens ohne auch nur die grundlegenden Probleme KI-technisch im Griff zu haben, das ständige Erfinden neuer Programmiersprachen mit denselben alten Schwächen ohne aus der Historie zu lernen, die Unfähigkeit von Windows einfach nur eine Menge Dateien unfallfrei zu kopieren (unbedingt lesen: der Fehler 0x80070057)…aber man kann doch nicht jede Woche einen Abkotzartikel schreiben. Das macht doch schlechte Stimmung.

Vielleicht bin ich im neuen Jahr ja erfolgreicher beim Aufstöbern von positiven Entwicklungen im IT-Bereich. Die Hoffnung stirbt zuletzt (aber sie stirbt…) – immerhin hat die IT noch nicht den Frustfaktor der Politik erreicht.

MediaWiki-Gefrickel

Ich konnte gerade durch beherzte Recherche ein nerviges Problem lösen, das mich fast in den Wahnsinn trieb. Die Zutaten: PHP, MediaWiki, Perl und PCRE. Und ein gehosteter Server ohne Shellzugriff.

Ich verwende MediaWiki seit einiger Zeit als mein privates Wiki – nicht gerade der ursprüngliche Einsatzzweck eines Wikis, wo ja eher Kollaboration im Mittelpunkt steht, aber was soll’s – es taugt für meine Zwecke. Da ich der Backup-Strategie von Profis mehr vertraue als meiner eigenen, läuft das Dingens bei einem bekannten Hoster in deutschen Landen. Problem: ich habe dort keinen Shell-Zugriff, nur FTP-Zugriff. Was das Updaten von „Apps“ wie MediaWiki oftmals schwierig macht. Also laufen hier gerne mal etwas ältere Versionen, wenn neuere DB-Updates brauchen, die nur über die Shell möglich sind.

Von einem Tag auf den anderen entschied sich MediaWiki nun, die Wiki-Seiten nicht mehr anzuzeigen. Oder genauer: nur noch den Seitentitel, nicht aber den Inhalt. Über „Bearbeiten“ konnte man aber sehen, dass die Inhalte nach wie vor vorhanden waren, die Datenbank selbst also keinen Schaden davongetragen hatte – irgendwo in der Aufbereitung durch PHP steckte also der Wurm.

Zunächst dachte ich, dass vielleicht eine Datei korrupt ist. Also das Backup zurückgespielt. Keine Änderung. Dann das Original-Release von MediaWiki drüberkopiert. Keine Änderung. Die neueste MediaWiki-Version installiert. Kann nicht mit der vorhandenen Datenbank zusammenarbeiten, der Web-Updater versagte ebenfalls den Dienst. Mit einer frischen Datenbank funktioniert alles – also prinzipiell sind die beteiligten Komponenten auf dem Server immer noch MediaWiki-tauglich.

Also den Google angeworfen. Nach diversen Irrungen und Wirrungen durch die Weiten des Webs fand ich einen Hinweis, dass das Problem durch ein Update von PCRE von 8.33 auf 8.34 ausgelöst wurde. Klar, wer käme nicht auf die Idee, dass ein mickriger Patch mal kurz gravierend die Rückwärtskompatibilität bricht.

Die schmutzigen Details: hier die Info aus dem Mediawiki-Wiki. Hier der entsprechende Thread im MediaWiki-Bugtracker. Hier kann man den Diff im Gerrit sehen. Man muss lediglich in include/MagicWord.php eine Zeile löschen und zwei hinzufügen. Einfach, wenn man weiß wie…

Die Konsequenz? Ich werden wohl das Wiki auf einen Server umziehen müssen, bei dem ich Root-Zugriff habe, um das Einspielen von Updates zu vereinfachen.

Java Forum Stuttgart 2017

Das Java Forum Stuttgart fand 2017 zum nunmehr zwanzigsten Male statt, und ich war mal wieder vor Ort dabei, da das Vortragsprogramm aus meiner Sicht recht ansprechend war. Ich nutze das Java Forum hauptsächlich, um mal wieder dran erinnert zu werden, wie riesig das Java-Universum ist und wie viele Technologien und Frameworks es da gibt, Hype inklusive. Es gab zum Abschluss als Pecha-Kucha-Vortrag einen Rückblick auf die letzten 19 Veranstaltungen inklusive Blick auf die damals aktuellen Themen, da war einiges an damals hippem Zeugs dabei, das schon wenige Jahre später komplett in der Versenkung verschwunden war.

Aber das Thema soll ja weniger die Vergangenheit als die Gegenwart sein.

Los ging’s mit der JAX-RS 2.1-Schnellbleiche durch Markus Karg, der in der Expert Group des dazugehörigen JSR 370 mitarbeitet. Meine Expertise in diesem Bereich ist sehr begrenzt, aber ich konnte dem Vortrag inhaltlich sehr gut folgen und habe auf meine Todo-Liste „REST-API für CinePoll“ geschrieben. Wie bei fast allen Technologien kann man ja viel drüber lesen, aber verstehen wird man es erst wenn man es nutzt. Interessant fand ich die Anmerkung, dass ja „im Prinzip“ keiner mehr den großen Server am Start hat, sondern stattdessen alle Microservices im Docker-Container deployen. Dazu kann ich nur sagen: in manchen Branchen ist man noch lange nicht soweit.

Im nächsten Zeitslot habe ich ReactiveX mit RxJava besucht. Ursprünglich wollte ich da nicht hin, weil der vorgesehene Vortragende bei mir bei einer vorherigen Ausgabe des Java Forum einen eher durchwachsenen Eindruck hinterließ, und ich die Erfahrung gemacht habe, dass ein guter Referent wichtiger ist als ein spannendes Thema. Jan Blankenhorn hat hier seine Sache jedenfalls sehr gut gemacht, inklusive Live-Coding, was ja immer einen gewissen Risikofaktor beinhaltet. Jedenfalls nahm ich mindestens zwei Erkenntnisse mit: ich muss doch IntelliJ IDEA eine zweite Chance geben, und ich muss dringend Routine bei den neuen Java 8-Features bekommen – bei der Lambda-Notation muss ich immer zweimal hinschauen, um den Code zu verstehen. Da ich täglich im Beruf auf Java 7 limitiert bin, fehlt einfach der routinierte Blick darauf.

Dann war es wieder Zeit für Michael Wiedeking, diesmal mit dem Thema Über den Umgang mit Streams. Wie immer sowohl unterhaltsam als auch lehrreich. Und wieder ein Knoten im Taschentuch für „Java-8-Features“. Und sehr plastische Beispiele für die Komplexitätsbetrachtung von Operationen.

Auch den Slot vor dem Mittagessen bestritt ein alter Bekannter: Björn Müller von der CaptainCasa GmbH mit dem Thema Von Java-Swing, über JavaFX zu HTML für operativ genutzte Geschäftsanwendungen. Er berichtete von der Reise des CaptainCasa-Frameworks von der Swing-UI über die JavaFX-UI hin zur neuen HTML-UI. Der Ansatz von „RISC-HTML“ führt zu höchst erstaunlichen Ergebnissen, die damit erreichte Performance der Oberfläche im Browser war aus meiner Sicht verblüffend. Die nicht immer ganz hasenreinen Ausführungen und Analogien zu CISC-vs-RISC bei den Prozessoren habe ich da gerne verziehen. Interessant auch die Einschätzungen und Erfahrungen zu JavaFX, die sich durchaus mit meinen Beobachtungen decken: am Markt gescheitert, Zukunft ungewiss. Die Krise der Cross-Platform-UI-Toolkits geht weiter.

Nach der Mittagspause ging es bei mir weiter mit Mobile hybride Applikationen – Investment-App der BW-Bank, präsentiert von Manfred Heiland von der avono AG. Cross-Platform-Lösungen interessieren mich seit Anbeginn der Java-Zeit mit dem Versprechen „Write Once, Run Anywhere“. Was auf der Serverseite nach wie vor prima funktioniert, ist im Bereich der grafischen Oberfläche ja schon längere Zeit eher schwierig. Swing war der letzte aus meiner Sicht einigermaßen erfolgreiche Versuch, ein Cross-Platform-UI-Toolkit an den Start zu bringen. Aber bezüglich mobiler Plattformen bringt das halt auch nix. Dort hat man im Prinzip die Wahl auf WebViews zu setzen, oder halt mehrfach native Apps zu bauen – ob Technologien wie Gluon hier irgendwann adäquate Lösungen erlauben, die auch über viele Jahre stabil bleiben, ist aus meiner Sicht noch unklar. Die Tatsache, dass iOS Objective C oder Swift nahelegt und Android Java erleichtert die Sache nicht. Und hier bietet das vorgestellte Projekt mit seinem Hybridansatz eine interessante Alternative. Die fachlogisch einfachen Teile, die die Steuerung der App übernehmen, werden nativ implementiert, diverse komplexere Inhalte hingegen, die hauptsächlich der Anzeige dienen, werden über WebViews gemacht. Offenbar gibt es inzwischen sowohl unter Android als auch unter iOS einigermaßen elegante Lösungen, per JavaScript in beide Richtungen zu kommunizieren, so dass mir der hybride Ansatz sehr plausibel erscheint. Laut Referent gab es auch keine Probleme, die Apps in die App-Stores zu bringen – das ist bei „ich kapsle meine Webanwendung einfach als App“-Variante ja nicht immer so problemlos.

Als passionierter Frontend-Entwickler habe ich dann natürlich UI Technologieradar besucht. Das erwies sich als nicht so besonders fruchtbar. Die versprochene „objektive Entscheidungshilfe bei der UI-Technologiefindung“ erwies sich als eher simple Ansatz einer Bewertungsmatrix verschiedenster (aber immer noch sehr lückenhafter) UI-Technologien, wobei die Bewertungen sich als durch und durch subjektiv erwiesen. Die ausgearbeiteten Kriterien entsprachen ungefähr dem, was ein etwas erfahrener Consultant oder Entwickler nach 30 Minuten scharfem Nachdenken selbst erarbeitet hätte. Und es traten verschiedene Einschätzungen und Aussagen zu diversen Technologien hervor, die die Glaubwürdigkeit der ganzen Idee doch in einem ziemlich schalen Dämmerlicht erscheinen ließen – beispielsweise wurde die These aufgestellt, dass mit Java Swing ja nie jemand eigene Komponenten erstellt habe, während das bei diversen Webtechnologien gängige Praxis sei. Aus meiner Sicht eine komplett absurde Einschätzung und nur durch sehr enge Scheuklappen aus der eigenen Projekterfahrung zu erklären – was der Consultant noch nicht gesehen hat, gibt es nicht. Zu allem Überfluss bildeten die beiden Vortragenden auch noch einen scharfen Kontrast bezüglich ihrer präsentatorischen Fähigkeiten, was sich als sehr störend herausstellte. Präsentieren im Duo geht aus meiner Sicht nur, wenn beide sich entweder gut ergänzen oder gut aufeinander eingespielt sind. Keines von beidem war hier der Fall. Und als Schlusspunkt: das „UI Technologieradar“ wurde in der Vortragsankündigung als fertig einsetzbares Tool charakterisiert – im Vortrag stellte sich allerdings heraus, dass es sich noch in einem sehr frühen Stadium der Entwicklung befindet. Ebenfalls in der Ankündigung: man würde Technologien wie React.js oder Spring MVC kurz kennenlernen. Das entpuppte sich als stark übertrieben: Spring MVC beispielsweise tauchte nur namentlich auf einigen Folien auf. Interessant auch ein innerer Widerspruch: auf mehreren Folien tauchte die These auf, dass GWT stark auf dem absteigenden Ast sei. Empfehlung: nicht mehr für neue Projekte verwenden. Kann man so sehen. Aber die Begründung, warum AngularJS so eine gute Wahl sei, war, dass eine große Firma wie Google dahinter steht. Finde den Fehler.

Den Abschluss bildete für mich die Pecha-Kucha-Session. Auch dieses Mal muss ich feststellen: das Format gibt mir überhaupt nix. Wenn der Vortragende gut ist (wie in diesem Falle mal wieder Michael Wiedeking), merkt man im Vortrag gar nicht, dass es im Pecha-Kucha-Style abläuft. Wenn der Vortragende schlecht ist (bzw. den Ablauf nicht häufig genug geübt hat, um das passende Timing zu entwickeln), passt die Folie nicht zum Gesprochenen. Und das Format scheint zur Nutzung nichtssagender Bilder zu animieren, denn dann passt die Folie auch automatisch zum gesprochenen Wort. Auf die einzelnen Vorträge (klassisches 20×20-Format, 5 Vorträge für die zur Verfügung stehenden 45 Minuten) will ich gar nicht detailliert eingehen und will nur den von Michael Wiedeking lobend hervorheben, der unter dem Titel „Schall und Rauch“ sehr plastisch ausführte, wie kompliziert es ist sprechende Methodennamen zu finden. Aus meiner Sicht übrigens der Knackpunkt der CleanCode-Bewegung und ihrem Mantra „Kommentare überflüssig, der Code erklärt sich von selbst“. Das zeigte sich, als das Publikum abstimmen durfte, welcher Methodenname am passendsten zur beschriebenen Operation sei. Da herrschte kein klares Meinungsbild, was die Problematik doch sehr verdeutlicht. Essenz daraus: entscheide Dich für ein Wording, aber ziehe das dann auch konsistent durch – Du wirst es nie allen recht machen können.

Wer Beispiele für gelungene Pecha-Kucha-Vorträge kennt (also nicht nur: guter Vortrag, sondern Mehrwert durch die Tatsache, dass er dem Format folgt): gerne Links an mich schicken, vielleicht ändere ich meine Meinung.

Unterm Strich fand ich die Veranstaltung sehr gelungen. Die Vielfalt der Vorträge gefällt mir gut, preislich ein Schnäppchen, Top-Organisation, Verpflegung OK. Gut, die Liederhalle ist etwas in die Jahre gekommen, aber das stört nicht sonderlich. Also: nächstes Jahr wieder dabei. Hoffentlich wieder bei Vorträgen von Michael Wiedeking und Björn Müller.

Reflexe

Eine Meldung erschüttert die Grundfesten der deutschen Sprache: am Donnerstag gab der „Rat für deutsche Rechtschreibung“ bekannt, dass das große scharfe S nun (endlich?) offizieller Bestandteil der deutschen Rechtschreibung werden soll. So berichten beispielsweise Die Welt oder SPIEGEL Online.

Mein erster Reflex (und deshalb landet dieser Artikel im IT-Blog, weil es eben der Reflex eines IT-geprägten Menschen ist): sind die wahnsinnig? Was ist denn der Unicode-Codepoint, und wie lange wird es dauern bis das Dingens in Tastaturtreibern und Fonts auftaucht? Ein kurzes Googeln später die Erkenntnis: das ist schon seit 2008 durch. Unicode-Codepoint U+1E9E, als HTML-Entity also &7838;. Unter Windows per Shift+AltGr+ß tippbar (nicht unter Windows 7, aber zumindest unter Windows 10). Und auch diverse Fonts sind bereits seit Längerem damit ausgerüstet: Arial, Times New Roman, Verdana und Tahoma seit Windows 7, unter den freien Schriften sind DejaVu und Bitstream Vera am Start. Also: das Rückenmark lag (dieses eine Mal) falsch.

Nichtsdestotrotz wäre mir die „Schweizer Lösung“ lieber gewesen: ersatzlose Abschaffung des ß. Braucht kein Mensch. Zweitbeste Lösung: mit der bisherigen Situation leben. Kein Mensch braucht – abgesehen von Designern und Werbefuzzis – die reine Großschreibung (Versalsatz). Da geistern zwar merkwürdige Begründungen wie „Maschinenlesbarkeit“ durch die Gazetten, aber das ist im 21. Jahrhundert kein valider Grund mehr. Auch nicht auf Personalausweisen.

Vom MIST zum MISTer

Es gibt ein interessantes neues Projekt im MIST-Universum. Sorgelig, einer der aktivsten Core-Portierer und -Entwickler fürs MIST-Board, hat ein neues Projekt gestartet: der MISTer ist sowas wie ein Nachfolger für das MIST-Board, mit deutlich verbesserter Hardware, aber weitestgehend kompatibler Firmware und damit einer einfachen Möglichkeit, die verfügbaren MIST-Cores auf den MISTer zu portieren.

Warum überhaupt neue Hardware? Das MIST ist langsam an die Grenze seiner Leistungsfähigkeit angekommen. Atari ST und Amiga sind noch im machbaren Bereich, beim Acorn Archimedes wird es schon sehr knapp, und am Sega Megadrive scheitert man aktuell (einige Dinge laufen gut, andere weniger). Die Atari ST-Community träumt natürlich von einer Falcon-Nachbildung, was von den Experten für das MIST aufgrund mangelhafter Leistungsfähigkeit ausgeschlossen wird. Dazu kommt, dass der VGA-Ausgang des MIST ein ständiges Problem darstellt: der Core selbst muss sich darum kümmern, dass videotechnisch so einigermaßen was Kompatibles zu heute verfügbaren Monitoren oder Fernsehern rauskommt. Im MIST-Forum behandeln gefühlt 90% der Postings die Themen Scandoubler, Picture Centering und Konvertierung des analogen Videosignals nach HDMI. Fast alles am MIST ist Plug-and-Play, aber nicht die Bildschirmfrage.

Hardware-Basis des MISTer ist das Terasic DE10-nano-Board. 130 US$ kostet das Basis-Board, natürlich ohne Gehäuse oder ähnlichen Schnickschnack. Der zentrale FPGA-Baustein übertrifft den des MIST um Längen: ein Intel (ex-Altera) Cyclone V mit 110K LEs (MIST: Cyclone III mit 25K LEs), einem ARM Cortex-A9 mit 800 MHz (MIST: 48 MHz ARM), deutlich mehr internem Speicher, und der ARM kann deutlich enger mit dem FPGA-Teil kooperieren. Ein HDMI-Ausgang ist an Bord, es wird automatisch auf 720p skaliert. Per Daughterboard gibt es aber weiterhin Zugriff auf das analoge Signal der Cores nebst analogem Audio-Ausgang.

Während im MIST der ARM nur Steueraufgaben hatte – USB, Menü anzeigen, auf die SD-Karte zugreifen, I/O-Ports kontrollieren – kann im MISTer der ARM durch die enge Kopplung viel mehr Aufgaben übernehmen, sogar Teile der Emulation selbst. Vor allem für Dinge wie das Auslesen von Daten aus Floppy-Images oder ähnliches ist das ein Segen, weil man auf fertig verfügbare Bibliotheken zurückgreifen kann, wie sie auch gewöhnliche Emulatoren verwenden. Mit einem Cortex-A9, der auf nicht weniger als 1 GB RAM zugreifen kann, ist sowas kein Problem. Auf dem ARM läuft ein Minimal-Linux, so dass man auch auf vorgefertigte Treiber z.B. für USB-Devices zurückgreifen kann. Damit ist ein einfacher Weg geebnet, um einiges an Legacy-Hardware wiederzuerwecken, vom seriellen über den parallelen Port bis hin zu IDE oder Floppy (z.B. über Kryoflux).

Aus Entwicklersicht ist laut Sorgelig der größte Vorteil, dass man komfortabel in einer IDE wie Visual Studio die Firmware entwickeln kann und per Knopfdruck auf das Board deployed. Neben der Tatsache, dass die Hardware viel leistungsfähiger ist natürlich und man deshalb bei der Verwendung oder Portierung anderer FPGA-basierter Projekte nicht mehr so viele Handstände machen muss.

Das Projekt ist noch im Frühstadium. Die MIST-Firmware wurde erfolgreich portiert, einige Cores auch. Im Moment wird der Sega Megadrive-Core angepasst.

Gibt es andere Nachteile außer der Tatsache, dass sich das Projekt in einer unausgereiften Frühphase befindet? Der MISTer hat keine klassischen DB9-Joystickports und auch keine MIDI-Ports wie das MIST Plus (aber es gibt GPIO-Pins, die dafür verwendet werden könnten). Und man kann das Ding (noch?) nicht fertig kaufen inklusive Gehäuse. Beim MIST konnte man das Board noch komplett selbst bauen – Platine ätzen und bestücken, kein Problem (genügend Geduld und entsprechendes Equipment vorausgesetzt). Der MISTer-FPGA ist in BGA-Bauweise, so dass man zwingend ein professionell gefertigtes Board wie das Terasic DE10-nano als Basis verwenden muss.

Ich bin gespannt auf die weiteren Fortschritte des Projekts.

Pich, Telefnica und koda

Die Überschrift hätte auch „Schei? Encoding“ heißen können – ich denke, fast jeder ITler sollte dieses T-Shirt besitzen.

Das Thema Encoding – früher auch als Codepage-Problematik bekannt – verfolgt die IT schon seit der Gründerzeit. Auf den IBM-Großrechnern der Anfangszeit der kommerziellen elektronischen Datenverarbeitung war man noch ganz konsequent – nur Großbuchstaben und Ziffern waren möglich. Noch heute geht das Gerücht, dass die Adressdatenbestände der großen Banken und Versicherungen ausschließlich in Großbuchstaben vorliegen und von cleverer Software „mittendrin“ angepasst wird, bevor der Kunde es schwarz auf weiß auf Papier sieht.

Lange Zeit war in Stein gemeißelt, dass ein Zeichen („Character“) 8 Bit zu haben habe (E-Mail-Transport war sogar nur 7-Bit-sicher). Über Codepages wurde dann jedem Byte ein Zeichen zugeordnet. Bekannteste Vertreter dieser Art sind ISO-8859-1, auch Latin1 genannt, sowie dessen Spezialisierung WINDOWS-1252 (weitestgehend äquivalent zu ISO-8859-15, also mit Eurozeichen). Zu DOS-Zeiten war die Codepage 850 noch vorne dabei, auf dem Großrechner war die Cp273 (EBCDIC) der Standard, später zu IBM-1141 mit dem Eurozeichen erweitert.

Dann trat Unicode auf den Plan. Die Idee: eine Zeichencodierung für alles. Erste seriöse Implementierung war UTF-16, genutzt beispielsweise in den Joliet-Extensions zu ISO9660 (das CD-Image-Format, nicht etwa ein weiteres Encoding!) und in NTFS. 16 Bits pro Zeichen. Java war die erste verbreitete Programmiersprache, die Nägel mit Köpfen machte und dem char-Datentyp 16 Bits spendierte (und es gleich wieder teilweise versaute, weil der Datentyp signed definiert wurde – darauf muss man erst mal kommen. Aber der Datentyp byte ist auch signed, das ist zumindest eine Entschuldigung, dass man nicht alleine blöd war). Irgendwann merkte man: das ist stark suboptimal, weil erstens bei 65536 Zeichen Schluss ist, und zweitens Texte aus dem westlichen Sprachraum doppelt so viele Bits brauchen als bei einer 8-Bit-Codierung. UTF-8 war die Antwort. An UTF-16 wurde zusätzlich eine Erweiterung hingedoktort, so dass inzwischen ein Zeichen auch als 32bit-Wert codiert werden kann. Und weil Informatiker gerne mal Standards ignorieren und ihr eigenes Süppchen kochten, entstand CESU-8, weil es fehlerhafte Konvertierroutinen zwischen UTF-16 und UTF-8 gab. Wurde dann flugs zum eigenen Standard erkoren. Man muss sich manchmal schon schämen für unseren Berufsstand.

Nun ja. Jetzt ist überall UTF-8, sollte man meinen. Die üblichen Linux-Distributionen haben das als System-Encoding, nur das selten genutzte Windows tanzt mit WINDOWS-1252 etwas aus der Reihe. Ein steter Quell der Freude für sorglose Software-Entwickler, die sich unbewusst bei diversen Konvertierungen auf das System-Encoding verlassen. Statt WORA eben WODE (Write Once – Debug Everywhere). Sogar RISC OS hat inzwischen einen Font-Manager, der Unicode-fähig ist, es gibt nur keine Fonts dafür und der Rest des Systems besteht aus hauptsächlich englischen Anwendungen, die selbst von den deutschen Umlauten oft nicht viel halten. Da ist es wieder, das Schämen für den Berufsstand.

Und jetzt der Schwenk zur Überschrift: auch im Jahre 2017 trifft man das Encoding-Problem regelmäßig an. In meinem Fall im Kindle-Abo der Frankfurter Allgemeinen Zeitung. Im Wirtschaftsteil ist offenbar irgendwas grandios schiefgelaufen, und so wurde Ferdinand Piëch zu Herrn Pich, die Telekommunikationsfirma Telefónica zu Telefnica und der Autohersteller Škoda zu koda. Wie man sieht hat es nicht mal für ein Ersatzzeichen gereicht. Gut, bei einem Artikel über VW kann man den fehlenden Buchstaben bei Ferdinand Piëch leicht im Geiste erkennen und ergänzen. Aber bei Personen in Bezug auf weniger bekannte Betriebe kann das schon mal schwieriger werden.

Wer auch immer in der Kette von der FAZ über Amazon bis auf meinen Kindle das verbockt hat: Schämt Euch. Obwohl ich als Bewohner einer Straße mit Umlaut natürlich Kummer gewohnt bin – bis auf den Lieferscheinen von Amazon keine merkwürdigen Ersatzzeichen waren, sondern wirklich der richtige Umlaut auftauchte, das hat länger als ein Jahrzehnt gedauert. Ich rechne also mit einer fehlerfreien elektronischen FAZ gegen 2027 auf meinem Kindle. Gut Ding will Weile haben.

Neues vom MIST

Ich hatte mich schon in früheren Beiträgen (hier, hier und hier). Speziell der Archimedes-Core liegt naturgemäß in meinem Fokus (siehe hier und hier).

Beim Archimedes-Core hat sich leider wenig getan, aber dafür hat sich im Rest der MIST-Welt erheblicher Fortschritt ereignet, über den ich kurz berichten will.

Zum einen gibt es jede Menge neue Cores. Der C16-Core gilt inzwischen als ausgereift und weitgehend komplett. Der VC20 steht nun auch als Core bereit. Und um die Commodore-Fraktion abzurunden, ist ein PET2001-Core gerade in der Mache. Bei den Arcade-Cores gibt es viele Neuzugänge – Galaga ist sicher das Highlight, viele weitere sind in der Pipeline. Bei den Spielkonsolen freuen wir uns auf den Sega MegaDrive (aka Genesis) Core – der macht schon einen guten Eindruck, aber die Soundunterstützung fehlt noch. Unter der Rubrik „Exoten“ würde ich den Mattel-Aquarius-Core einordnen. Die Sinclair-Fraktion freut sich über den Spectrum-128K-Core und den Sam-Coupe-Core. Und noch was aus der Rubrik „Ultra-Exot“: der BK0011M aus Russland, quasi ein PDP11-Clone, gab sein Debüt.

Signifikante Fortschritte gab es beim Amiga-Core (Minimig-Aga) und beim Amstrad CPC-Core, der nun sowohl 60Hz-VGA- als auch 50Hz-TV-Ausgabe beherrscht. Auch der NES-Core hat eine Neuauflage erfahren. Der Atari800-Core kann nun 50Hz-PAL. Der MSX-Core kann auch mit der allerneuesten MIST-Auflage, wo wohl leicht verändertes SDRAM-Timing am Start ist, arbeiten.

Sorgelig hat sich um verbesserte Kompatibilität mit Bildschirmen gekümmert. Viele Cores unterstützen nun den 15kHz-Modus und erlauben eine Videoausgabe nicht nur per RGB für die Scart-Fraktion, sondern auch per YUV (auch als YPbPr oder Komponente bekannt). Das hat einige Vorteile. Während bei RGB via Scart strenggenommen nur PAL klassisch interlaced unterstützt war und die progressive-Ausgabe klassischer Computer und Konsolen mehr aus Versehen bei den typischen Röhrenfernsehern funktioniert hat, ist die progressive Ausgabe beim Komponenten-Signal anständig spezifiziert. Das erhöht die Chance, auch mit modernem Equipment anständige Ergebnisse zu erzielen. Seit der Erfindung von HDMI ist der Komponenteneingang zwar auf dem Rückzug (bei Fernsehern der neuesten Generation fehlt er ebenso wie der Scart-Eingang), aber selbst die neueste Generation AV-Receiver hat immer noch Komponenten-Eingänge an Bord, wenn auch in ständig reduzierter Anzahl.

Die Firmware des MIST wurde ebenfalls verbessert, vor allem die Konfigurationsoptionen zur Zuordnung von Funktionen auf Buttons von USB-Controllern wurden flexibilisiert. Die Repeat-Intervalle für Feuerknöpfe können nun ebenfalls eingestellt werden. Dazu die Unterstützung für die YUV-Ausgabe per mist.ini.

Ich hoffe, ich habe nix vergessen. Ich finde es sehr erfreulich, wie sich die MIST-Community über die Jahre entwickelt hat – zu Anfang lag noch viel Last auf den Schultern des MIST-Erfinders, aber in letzter Zeit gibt es immer mehr Contributers. Es bleibt spannend. Wenn jetzt noch Stephen Leary ein paar seiner geplanten Erweiterungen des Archimedes-Cores nachlegt…

Gedanken zum Thema KI

In letzter Zeit erkenne ich einen gewissen Trend zur positiven bis euphorischen Berichterstattung über die Fortschritte im Bereich KI. Die einen feiern den Sieg eines Computers über menschliche Spieler (egal ob Schach, Go oder Jeopardy). Die anderen prognostizieren, dass in absehbarer Zeit das vollautonom fahrende KfZ unsere Straßen bevölkert. Und es gibt die Sorge, dass „Skynet“ Wirklichkeit wird. Der Pflegeroboter gilt aus Ausweg aus der demographischen Krise (keine Ahnung, was das für eine Krise sein soll, aber das gehört nicht hierher).

Unterm Strich halte ich das alles für Mumpitz – zumindest, wenn man an „Intelligenz“ einen gewissen Anspruch stellt, der über „wir haben es mit massiver Rechenleistung und cleveren Algorithmen für dieses spezielle Problem hinprogrammiert“ hinausgeht.

Betrachten wir doch mal den Status Quo. Wir befinden uns grob 60 Jahre nach den ersten Gehversuchen der KI. Trotz einzelner Erfolge in sehr spezifischen Gebieten – wie oben genannt – sehe ich die Informatik weit weg von einem etwaigen Durchbruch. Die Komplexität von „Intelligenz“ scheint einfach zu – wie soll man sagen – komplex, um es auf bekannte Weise in Algorithmen zu gießen und in Datenbanken zu verwalten.

Gerne lasse ich mich vom Gegenteil überzeugen. Z.B. durch wirklich intelligente, menschlich agierende Gegner in einem Autorennen – darauf warte ich schon seit Pitstop. Z.B. durch eine Spracheingabe, die auch leichtes Nuscheln einwandfrei versteht – auch gerne durch ein bandbreitenbegrenztes Medium wie das Telefon. Oder wie wäre es mit einer Übersetzungssoftware von Deutsch nach Englisch und andersrum, das keine Stilblüten erzeugt sondern einwandfreie Texte?

Und bitte aufhören, Assistenzsysteme im Auto als Vorstufe zum vollautonomen Fahren zu glorifizieren. Ein „Autopilot“, der regelmäßig die Kontrolle an den menschlichen Fahrer abgeben muss, ist noch sehr weit entfernt von dem, was wirklich nützlich ist – denn wenn ich während des Fahrens nicht was anderes machen kann, habe ich allerhöchstens ein Sicherheitsplus und vielleicht ein Komfortplus, aber gegenüber der Vision des vollautonomen Fahrens ist es doch letztlich nur eine minimale Verbesserung gegenüber heute.