Kategorie: Uncategorized

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.

Die traurige Nachricht von Jörg Schillings viel zu frühem Tod hat nun auch mich erreicht. “Schily”, so sein Kürzel beispielsweise im Heise-Forum oder generell bei den Releases seiner zahlreichen nützlichen Tools, starb in viel zu jungen Jahren an Krebs.

Ich hatte nie persönlichen Kontakt mit ihm, obwohl wir beim Thema “Brennersoftware” ja größere Überschneidungen hatten. Sein cdrecord ist nach wie vor der Gold-Standard unter den freien Brennprogrammen. Ja, ich hatte sogar in der Anfangszeit mal einen Blick in die Sourcen geworfen, um herauszufinden, wie man diese Yamaha CDR100/102-Brenner und den Teac CD-R50S zum Brennen überreden könnte. Aus potenziellen Lizenzunverträglichkeitsgründen habe ich das aber mit Beginn der CDBurn-Entwicklung fürderhin unterlassen – nicht etwa nur, weil das Lesen von C-Code irgendwann das Hirn verschwurbelt. Ich muss zugeben, ich war immer ein wenig neidisch darauf, dass er es geschafft hatte, dass diverse Firmen wie Sanyo, LG, Sony, Plextor und Yamaha ihm kostenlos und dauerhaft Laufwerke zu Test- und Entwicklungszwecken zur Verfügung zu stellten. Was aber nur gerecht war, denn ein portierbares Multi-OS-Brenntool ist im großen Spiel der Dinge ganz sicher von größerem Interesse als eine kommerzielle Implementierung auf einem Randgruppenbetriebssystem wie RISC OS.

Irgendwann Ende der 90er oder Anfang der 00er Jahre hatte ich mal eine kurze Unterredung mit einem GPL-/Linux-Fan, der mich überreden wollte, doch CDBurn unter der GPL und für Linux zu veröffentlichen. Auf meine überraschte Nachfrage, warum das im Angesicht von cdrecord eine gute Idee sein sollte, erfuhr ich zum ersten Mal von der eher GPL-ablehnenden Haltung von Schily und seiner auch sonst meinungsstarken und damit wenig kompromissbereiten Persönlichkeit. Und nach näherer Beschäftigung mit seinen Argumenten konnte ich Schilys Standpunkten letztlich zustimmen, ebenso den meisten seiner Einlassungen in diversen Foren zu diesem Thema. Auch wenn ich es nie zu seinem Grad der GPL-Ablehnung geschafft habe – meine kritische Einschätzung der GPL und der grundsätzlichen Schwierigkeiten bei der Interpretation dessen, was diese Lizenz in welchem Szenario nun zulässt oder nicht, ist für immer geblieben.

Immer streitbar und trotzdem produktiv. Ich werde Schily in guter Erinnerung behalten. Session closed.

Wann immer ich ein Stück Technik kaufe, informiere ich mich vorher so gut es geht. Reviews bei Amazon, Testberichte, und natürlich die Hersteller-Website. Bei komplexeren Dingen hilft oft ein Blick ins Handbuch, das ja Gott sei Dank inzwischen fast immer zum Download verfügbar ist (und das auch sein muss, denn gedruckt beigelegt wird es heutzutage ja immer seltener – aber das ist eine andere Geschichte).

Seit Jahren beobachte ich dabei eine ständige Reduktion der Tiefe technischer Daten. Jahrelang habe ich z.B. bei DVD-Brennern den Strombedarf zu ermitteln versucht – meist stand nur “5V/12V” im “Datenblatt”. Sehr nützlich.

Ein besonders sparsames Beispiel ist mir gerade untergekommen: es geht um eine externe USB-Festplatte von Seagate. Was könnte es da an nützlichen Informationen geben, die man in ein Datenblatt schreiben könnte? 512 Bytes/Sektor vs. 4Kn? Strombedarf am USB, womöglich gar getrennt nach Anlaufstrom, Strombedarf im Betrieb und im Standby? rpm der verbauten Platte? Geräuschentwicklung? Ob es intern eine S-ATA-Platte ist und die USB-Schnittstelle mit SAT arbeitet? Format bei Auslieferung?

Man werfe einen Blick drauf und ergötze sich an zwei Druckseiten Nichtinformation.

Immerhin: wir wissen nun, dass in 320 bzw. 240 Hauptkartons pro Palette geliefert wird. Super!

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.

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.

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.

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.

Irgendwann zwischen Weihnachten und Neujahr ist es passiert – genauer ließ es sich nicht rekonstruieren. Meine Webpräsenz wurde gehackt. Alle vier WordPress–Installationen und die Drupal-Installation waren betroffen. Die dahinter liegenden Datenbanken waren Gott sei Dank sauber.

Wie äußerte sich der Hack? Einige Benutzer berichteten von Redirects auf Phishing-Seiten, die meisten waren aber nur von schlechterer Performance betroffen, weil in die HTML-Daten JavaScript injected wurde, das auf gewisse Fremdseiten zugriff, die unglaublich schlechte Antwortzeiten hatten. oil-hockey.ch und rardec.co.uk waren darunter. Das verzögerte den Aufbau der Webseiten erheblich.

Klassifiziert war das Problem als “JS:Injection-A” (Avast) oder “Mass Injection Website 19” (Symantec). Für mehr Details hier ein Link zu Symantec. Es dauerte nicht lange, bis die Webpräsenzen bei mindestens einem Dienst (Norton Safeweb) auf der Blacklist standen. Das zieht dann weitere Kreise – vor allem Firmen haben oftmals automatische Verfahren, um Zugriffe aus dem Intranet auf Seiten auf Blacklists zu unterbinden. Gott sei Dank gab es bei Norton Safeweb eine relativ unkomplizierte Möglichkeit, eine Reevaluierung des Zustands zu veranlassen.

Seit einer Woche ist nun wieder alles bereinigt – WordPress- und Drupal-Neuinstallation nebst zwei WordPress-Theme-Wechseln (die alten sind noch verseucht, die muss ich noch aufräumen) hat das Problem gelöst. Dazu natürlich die Routine-Dinge wie Wechseln aller Passwörter. Scheiss-Aufwand, aber man lernt ja was dabei (man soll ja alles positiv sehen).

Ich danke meinen aufmerksamen Blog-Lesern, die mich über das Problem informiert haben, weil ihre Sicherheitssoftware angesprungen ist. Wer seine Webpräsenz schnell online auf Malware checken will, dem sei der Online-Security-Scanner von Sucuri empfohlen.

Und was lernt man daraus? Früher war alles besser – da hätte man schnell ein paar alte Versionen der HTML-Dateien eingespielt und fertig wäre die Säuberungsaktion. In der heutigen Welt der CMS-Systeme mit ihrem üblen PHP-Verhau dauert eine Analyse viel länger. Und: nur weil eine Webpräsenz eine überschaubare Anzahl Besucher hat – man sollte also denken, dass so ein Hack ein wirklich schlechtes Preis-Leistungs-Verhältnis hat – heißt das nicht, dass nicht doch ein paar üble Gesellen Hand anlegen. Abgesehen davon ist es nie schlecht, regelmäßig Backups zu machen – ok, das ist eine IT-Binsenweisheit, das sollte man schon vorher gewusst haben.

Ich wünsche allen meinen Lesern – die sich allein deshalb glücklich schätzen können, weil sie zu einem ganz kleinen elitären Kreis gehören – ein Frohes Fest und einen guten Rutsch ins neue Jahr. Wir dürfen gespannt sein, was 2016 so bringt. Am Ende vielleicht sogar mehr Blog-Einträge?

Die Gründerzeit der IT aus meiner Sicht war die Heimcomputerzeit. Zwar gab es zuvor jede Menge EDV, aber doch hauptsächlich im Umfeld größerer Firmen oder bei Universitäten, also nichts für den einfachen Mann von der Straße. Erst die Heimcomputerzeit Anfang der 80er brachte den Computer in den Privatbereich. Jede Menge kleine, innovative Firmen entstanden und brachten allerlei Computer auf den Markt. Viele verschwanden genauso schnell wieder in der Versenkung. An die, die länger blieben, haben wir die besten Erinnerungen: Acorn und Sinclair, Commodore und Atari, Amstrad und Apple.

Paul Fellows, ein Software-Entwickler genau aus dieser Gründerzeit, hat auf der RISC OS Show London 2015 einen launigen, kurzweiligen Vortrag gehalten über die Geschichte des Acorn BBC Model B und die frühe Zeit des Acorn Archimedes, als man in größter Not ARTHUR aus dem Boden stampfte. Anschauen! Ab 4:30min geht es los. Eine frühere, ausführlichere Variante kann man hier nachlesen.