ARM-Missverständnisse

 Hardware  Kommentare deaktiviert für ARM-Missverständnisse
Jul 232016
 

Durch die möglicherweise anstehende Übernahme von ARM Ltd., Macher der allseits beliebten ARM-Prozessoren (oder eher: des lizenzierbaren „Materials“, aus dem ein Lizenznehmer dann den Prozessor machen kann), liest man wieder vermehrt von den Gründen, warum ARM es eigentlich als einzige alternative Prozessorarchitektur geschafft hat, x86 die Stirn zu bieten. Wir gedenken für einen Moment PowerPC, MIPS und SPARC als „zwar noch nicht tot, aber eher wenig verbreitet“ und ignorieren sie ab sofort. Ein kurzes Gedenken an den Alpha ist natürlich auch zulässig.

Oft ist zu lesen, das Tolle an den ARM-Prozessoren sei, dass sie so stromsparend sind. Das ist zwar irgendwie richtig, reicht aber als Erklärung nicht aus. Eine Menge Prozessoren (oder Prozessorarchitekturen) sind stromsparend und könnten relativ problemlos nach unten skalieren – denn viele ARM-Prozessoren, die sehr leistungsfähig sind (man denke an die diversen Cortex-A15-Implementierungen), sind auch nicht so richtig stromsparend. Viele Intel-Prozessoren, die sehr leistungsfähig sind, sind verhältnismäßig stromsparend. In punkto „Effizienz“ hat ARM also nicht wirklich eine magische Technologie entwickelt, die der Konkurrenz voraus ist.

Nein, die Gründe für die ARM-Dominanz sind woanders zu suchen – und bis sie sich etabliert hatte, hat es ja auch eine ganze Zeit gedauert. ARMs entscheidender Vorteil, der meines Erachtens auch die Basis für den erfolgreichen Abwehrkampf gegen Intels Eindringen in die Welt der „mobile chips“ war, ist das preiswerte, flexible Lizenzierungsverfahren. Ein Intel-Chip kommt aus einer Intel-Fabrik und enthält die Komponenten, die Intel dafür vorgesehen hat. Ein ARM-Chip kommt aus irgendeiner Fabrik und enthält die Komponenten, die der Lizenznehmer dafür vorgesehen hat. Die Lizenznehmer konkurrieren untereinander, sind ganz nah bei ihren Kunden, bauen teilweise spezifische Lösungen, die dann unerwartet bei anderen Kunden auch beliebt werden. Durch die niedrigen Lizenzgebühren braucht man keine Millionenstückzahlen, um Gewinne einzufahren – das erleichtert das Experimentieren, Versuch und Irrtum, kurze Verbesserungszyklen. Es hat sich ein riesiges Ökosystem entwickelt, wo praktisch jeder „seinen“ Chip finden kann. Oder er baut ihn gleich selbst (siehe als herausragende Beispiele Apple und Samsung, oder früher DEC mit dem StrongARM). Ethernet, Wifi, Bluetooth, S-ATA, LTE, USB, Grafik, Flash-RAM – der Variantenreichtum ist unerschöpflich, und alles kann strom- und kostensparend auf einem einzigen Chip vereinigt implementiert sein. Und der Wechsel des Lieferanten ist auch einfach.

Am Ende ist es vielleicht der Kampf zwischen Marktwirtschaft (ARM und Alternativen, Lizenznehmer, Auftragsfertiger) und Zentralverwaltungswirtschaft aka Planwirtschaft (Quasi-Monopolist Intel). Es dauert, es geht auf und ab, aber am Ende ist der Sieger eindeutig. Selbst wenn der Verlierer am Anfang des Kampfes gewaltigen Vorsprung hatte.

Wird sich an der ARM-Dominanz etwas ändern durch den Verkauf an Softbank? Man wird sehen. Glaskugeln sind gerade Mangelware.

GNAT GPL 2016 verfügbar

 Ada  Kommentare deaktiviert für GNAT GPL 2016 verfügbar
Jun 112016
 

Vor einigen Tagen hat AdaCore die Verfügbarkeit von GNAT GPL 2016 angekündigt. Die 2016er Variante steht in den Geschmacksrichtungen Linux-x86-64bit, Windows-x86-32bit, Mac OS X-x86-64bit, RPi2-32bit (Linux-hosted, und zwar x86-64-Linux) und ARM ELF (Windows- oder Linux-hosted) zum Download bereit.

GNAT kann natürlich Ada 2012 compilieren, aber auch die älteren Standards Ada 2005 und Ada 95 werden weiterhin verstanden. Neue Versionen von GtkAda, Win32Ada und GPS, der GNAT-IDE, runden die Sache ab. Basis ist GCC 4.9. Merkwürdig: die GNAT GPL-Seite erzählt immer noch Geschichten von der Vorversion.

Die älteren Versionen stehen weiterhin auch zum Download bereit. Besonders schade finde ich, dass das JVM-Target offenbar ins Hintertreffen geraten ist, die letzte Version die das Compilieren von JVM-tauglichen Class-Dateien aus Ada-Sourcen unterstützt hat, war GNAT GPL 2013. Ich hatte ein schönes Beispiel am Start, um eine Swing-GUI in Ada an den Start zu bringen, darüber wollte ich immer mal bloggen…aber mit so einer alten GNAT-Version macht das ja keinen Spaß.

Pyra-Vorbestellung möglich

 Hardware  Kommentare deaktiviert für Pyra-Vorbestellung möglich
Mai 262016
 

Ich bin etwas spät dran, weil Vorbestellungen schon seit Anfang Mai möglich sind. Irgendwie ist das aber an mir vorbeigegangen. Also besser spät als nie.

Was ist denn nun überhaupt eine Pyra? Im Prinzip eine OpenPandora in schöner und besser und schneller und überhaupt.

OK, aber was ist jetzt eine OpenPandora? Geistige Vorgängersysteme waren portable Spielkonsolen in der Tradition von Atari Lynx oder Sega GameGear, aber ganz auf der Idee offener Systeme basierend: GP32 (2001), GP2X (2005) und GP2X Wiz (2009), allesamt von der südkoreanischen Firma Game Park/GamePark Holdings entwickelt. Linux-basiert, mit einem ARM als Herz, Grunddesign mit Pad links, Bildschirm in der Mitte, Knöpfe rechts. Da die Systeme softwaretechnisch vollständig offen waren, waren sie der Traum für die „Homebrew“-Szene. Dementsprechend viele, meist freie Software entstand deshalb für diese Handhelds. Der Markt für native Spiele war eher klein, aber es gab eine Menge Emulatoren für den Spielspaß unterwegs, vom C64 bis zum CPC konnte zumindest aus der 8bit-Welt praktisch alles emuliert werden, das GP2X Wiz mit einem 533 MHz ARM9 hatte sogar genug Saft für die 16bit-Spielkonsolen. Die OpenPandora war dann quasi der inoffizielle Nachfolger der Game Park-Handhelds, die nicht nur den Handheld-Spielekonsole-Charakter abdecken sollte, sondern ein vollständiges portables Linux-System mit integrierter Tastatur.

Die OpenPandora – manchmal auch kurz Pandora genannt – basiert hardwaretechnisch auf einem BeagleBoard-ähnlichen Design, also ARMv7 TI OMAP 3 mit bis zu 1 GHz Taktfrequenz. Verpackt in ein klappbares Gehäuse – im weitesten Sinne ähnlich einem Nintendo DS – mit einem Sack voll Schnittstellen von 2 SD-Cards bis zu USB. Auf der einen Seite dank der Tastatur eine Art Mini-PC, auf der anderen Seite aber auch als Handheld-Spielkonsole positioniert dank entsprechenden Controller-Elementen vom 8-Wege-Pad bis zu Schultertasten. Ein 4,3″-Touchscreen mit 800×480 Bildpunkten sorgt für ein klares Bild. Es gab eine Menge Probleme und Verzögerungen bei Herstellung und Auslieferung, grob ab 2010 war die OpenPandora endlich in Stückzahlen erhältlich.

Genug der Historie. Der Nachfolger der OpenPandora ist die Pyra. OMAP5 statt OMAP3, also 1,5 GHz Cortex-A15 Dual-Core statt maximal 1 GHz Cortex-A8 Single-Core. Über den groben Daumen gepeilt bedeutet das eine etwa um Faktor 5 erhöhte Rechenleistung. 2 bis 4 GB Hauptspeicher sind verbaut, dazu aktuelle Schnittstellen wie HDMI, eSATA und USB3. Das Display ist nun 5″ groß und schafft die 720p-HD-Auflösung. Kontakt nach außen gibt es via WiFi und Bluetooth, optional gibt es auch ein UMTS/LTE-Modul inklusive der gängigen Smartphone-Sensorik von GPS über Höhenmesser bis zum Gyro-Sensor. 32GB Flash ist eingebaut, damit man auch ohne eingesteckte SD(XC)-Karte das System seiner Wahl booten kann. Es steckt ein 6000mAh-Akku drin, der ausgetauscht werden kann. Die Tastatur hat eine Hintergrundbeleuchtung spendiert bekommen.

Eine weitere Besonderheit: das Hardware-Design ist modular. So leben CPU und RAM auf einem separat tauschbaren Board, was zukünftige Updates ermöglicht. Inwiefern dieses Szenario realistisch ist, insbesondere nachdem TI die OMAP-Reihe nicht mehr fortführt, sei dahingestellt – ich habe es noch nie für eine gute Idee gehalten, auf spätere Updates zu hoffen. Man kauft am besten das, was existiert, und nicht die Hoffnung auf etwas eventuell irgendwann existierendes.

Wer ist nun Zielgruppe der Pyra? Schwer zu sagen. Sie ist portabler als ein kleines Netbook. Aber auch deutlich dicker als ein Smartphone oder von mir aus eine PS Vita. Aber die hat halt auch eine vollständige Tastatur, die – ich nehme mal meine OpenPandora als Benchmark – durchaus benutzbar ist. Sie ist nicht ganz preiswert, mit 4 GB RAM und mit 3G/4G-Modul liegt man doch schon bei 750€. 2 GB ohne Mobile-Modul liegt bei 600€. Also doch eher unterm Strich ein Liebhaberstück. Damit bin ich Zielgruppe. Hurra! Zumal RISC OS auf der OpenPandora problemlos lief und die Pyra dank HDMI-Out und USB ja sowohl als stationäres als auch mobiles System dienen könnte.

Hier unter pyra-handheld.com gibt es die volle Info-Dröhnung und Details zur Vorbestellung.

Swing-Rätsel – JTree-Zeilenhöhe

 Java, Swing  Kommentare deaktiviert für Swing-Rätsel – JTree-Zeilenhöhe
Apr 112016
 

Manchmal hat man Probleme schon vor so langer Zeit gelöst, dass man sich bei erneutem Auftreten nicht mehr dran erinnert. Weder an das Problem, noch an die Lösung.

Es geht um Java Swing. Die Basics. Man nehme einen JTree. Da gibt es eine Methode namens „setRowHeight“ wo man die zu rendernde Zeilenhöhe setzen kann. Wie so oft gibt es hier auch eine „magic number“, die besonderes Verhalten aktiviert. Hier ist es die 0 (oder negative Werte) – damit instruiert man den Tree, doch bitte den Renderer zu fragen, wie hoch die Zeile denn nun wirklich werden soll. Man sollte meinen, dass das auch ein wirklich guter Default wäre.

Nun gibt es ja in Swing zwei Varianten, wie so ein Default in Aktion tritt. Entweder simple Hartcodierung, oder durch die UI-Defaults des aktiven Look&Feel. Wer weiß auswendig, wie der hartcodierte Wert ist und welches der Standard-Look&Feels dann welchen Wert setzt? Bonuspunkte für denjenigen, der das auch noch schlüssig erklären kann.

Amüsante Randnotiz (Achtung, Spoiler! Teile der Antwort auf obige Frage inside!): hier ein Bug aus Zeiten von Java 1.4 (gab es das wirklich schon 2002?), der sich ebenfalls mit diesem Problem befasst.

Beknackte Oberflächen – heute: Windows-Explorer

 UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: Windows-Explorer
Mrz 252016
 

Gerade kopierte ich eine größere Menge Daten zwischen verschiedenen Platten hin- und her. Wider besseren Wissens per Standard-Explorer (Windows 7). Da erreicht mich folgende Fehlermeldung: „Zielpfad ist zu lang. Die Dateinamen wären zu lang für den Zielordner. Kürzen Sie die Dateinamen und wiederholen Sie den Vorgang, oder verwenden Sie eine anderen Ort, der einen kürzeren Pfad hat.“

OK, danke für die Info. Den kleinen Grammatikfehler finde ich für den Multi-Milliarden-Konzern Microsoft zwar peinlich, aber halb so schlimm. Auch schlimm, aber auch nicht Thema: die Tatsache, dass im 21. Jahrhundert die Pfadnamenlänge überhaupt noch eine Rolle spielt. Nein, das Problem ist vielmehr der gravierende Mangel an Information. Welche Dateinamen? Welcher Zielordner? Wenn ich den „Vorgang“ wiederholen soll, wäre das doch schön zu wissen. Im Dialog wird ein Name partiell angezeigt (ist es der Zielpfadname? Ein Dateiname? Oder das Quellverzeichnis?), leider nur die ersten 44 Zeichen, danach folgen die beliebten drei Punkte. Gut, dass der Fehlerdialog nicht vergrößerbar ist, um den Namen ganz anzeigen zu können – konnte ja keiner ahnen, dass bei einer Meldung bezüglich zu großer Länge von Datei-/Pfadnamen tatsächlich lange Namen angezeigt werden müssen. Und die Größe von Dialogen scheint ja weiterhin dem „Benutzer hat maximal 640×480“-Paradigma zu folgen. Wer hat sich nicht schon über den Dialog geärgert, wo man die Systemvariablen setzt. Scrollbars als Notlösung scheinen auch aus der Mode gekommen zu sein. Selbst ein Tooltipp mit dem vollen Namen wäre zur Not akzeptabel.

Ganz schlecht, liebe Freunde von Microsoft. Der Grundsatz des „information hiding“ sollte bei der Programmierung realisiert werden, nicht bei der Benutzerinformation.

Beknackte Oberflächen – heute: WinZip

 Software, UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: WinZip
Mrz 202016
 

Nein, es soll nicht darum gehen, dass der einzig wahre Weg, Archive zu behandeln, die Idee des „Image Filing System“ unter RISC OS ist, und nach wie vor SparkFS von David Pilling die ultimative Implementierung dieser Idee ist. Warum unter Windows bis heute nichts annähernd vergleichbares existiert, ist eines der großen Mysterien der Weltgeschichte. Naja, dort hält man ja teilweise auch den Explorer noch für eine gute Idee.

Also, was nervt mich heute darüber hinaus an WinZip? Das unglaublich schlechte Fehlerhandling. Ich archiviere ein Verzeichnis mit ein paar tausend Dateien. Am Ende des Vorgangs informiert mich WinZip mit folgender alarmierender Meldung: „Es sind Fehler aufgetreten. Möchten Sie die WinZip-Protokolldatei aufrufen?“ Fehler? Natürlich will man wissen, was schiefgegangen ist. Also die Protokolldatei öffnen (keine Ahnung, welcher Schwachspieler hier „aufrufen“ übersetzt hat). Aber was bekommt man zu sehen? Nicht etwa eine Liste der aufgetretenen Fehler. Nein, eine Liste aller Vorgänge. Wie das Hinzufügen einer Datei zum Archiv. Und wie findet man jetzt die Fehler? Leider gibt es überhaupt keinen Hinweis, durch welchen Text so ein Fehler benannt werden könnte. Doch es kommt noch besser: oft sind gar keine Fehler im Protokoll zu finden, sondern lediglich Warnungen.

Fassen wir zusammen: Irreführende Fehlermeldung, gut versteckte Informationen – ein würdiger Kandidat für den Preis der „Beknackten Oberfläche“. Ergonomiewertung: 0%.

In meinem Falle ist der Grund für Warnungen übrigens meistens, das Dateien mit Datestamps früher als dem 1.1.1980 (das früheste Datum, das im ZIP-Format darstellbar ist) archiviert werden. Da fragt man sich doch direkt, was sich Phil Katz damals gedacht hat. Leider können wir ihn nicht mehr fragen.

Raspberry Pi 3 verfügbar

 Hardware  Kommentare deaktiviert für Raspberry Pi 3 verfügbar
Feb 292016
 

Heute hat die Raspberry Pi Foundation den Raspberry Pi 3 offiziell vorgestellt. Er ist bereits (im Gegensatz zum RPi Zero, der immer noch bei der Verfügbarkeit schwächelt) in kleinen Stückzahlen bei den üblichen Verdächtigen lieferbar. Preise liegen bei rund 40€.

Jetzt gibt es also harte Fakten. Die weichen gar nicht so sehr von den Gerüchten ab, die ich vorgestern eingesammelt habe:

  • SoC 1,2 GHz BCM2837 Quad-Core Cortex-A53 – also ARMv8 64bit, aber mit AArch32-Unterstützung
  • WiFi (802.11n) und Bluetooth (4.1) über BCM43438 on board

Rest ist unverändert zum RPi 2 – 1GB RAM, 4x USB2.0, 100MBit Ethernet über USB angebunden, analog Video/Audio out über Klinke, HDMI für digital Video/Audio, microSD-Slot. Es wird ein 2,5A-Netzteil empfohlen, wenn man die 4 USB-Ports voll belasten will. Alle Ports sind an der gleichen Stelle wie beim RPi B+ und RPi 2 B, die Gehäuse sind also kompatibel.

Performancetechnisch wird die Steigerung vermutlich bei 50% gegenüber dem RPi 2 liegen – etwas höherer Takt, und höhere Effizienz des Cortex-A53 gegenüber dem Cortex-A7. NEON soll deutlich schneller geworden sein.

Ben Avison hat ein paar interessante Details zur Rückwärtskompatibilität im ROOL-Forum gepostet. Es scheint diesmal kein übles Ei wie die Änderung der non-word-aligned-memory-access-Geschichte bei ARMv7 vs. ARMv6 zu geben, nur Kleinigkeiten die vermutlich nur das OS betreffen.

In Summe ist der RPi 3 eine super Sache – gleicher Preis wie bisher, und man hat die Chance preiswert einen realen 64bit-ARM zu betreiben. Und im High-End-Bereich gibt es genügend Platz für Alleinstellungsmerkmale wie Gigabit Ethernet und S-ATA.

 

Raspberry Pi 3 im Anmarsch

 Hardware  Kommentare deaktiviert für Raspberry Pi 3 im Anmarsch
Feb 272016
 

Der heise-Newsticker hat es vermeldet: der nächste Streich der Raspberry Pi Foundation ist im Anmarsch, im Moment von der Presse Raspberry Pi 3 getauft. Sicher scheint zu sein, dass WLAN und Bluetooth serienmäßig mit an Bord sind. Laut diesem Titelbild von der kommenden Ausgabe des MagPi-Magazins können wir uns auch auf 64bit (also ARMv8) und 1,2 GHz freuen. Laut diesem Bild einer Seite des CPC-Katalogs wird der UK-Preis bei 26,38 UKP liegen (netto vermutlich), im Innern steckt ein Broadcom BCM2837 SoC – es bleibt also beim Quadcore. WLAN und Bluetooth wird durch den BCM43143 bereitgestellt.

Ansonsten sieht er dem Raspberry Pi 2 Model B zum Verwechseln ähnlich. microSD, USB, Ethernet, Analog-Audio und -Video über die vierpolige Klinkenbuchse, 40pin-GPIO.

Die offizielle Ankündigung der Raspberry Pi Foundation steht noch aus. Aber demnächst feiert der Raspberry Pi seinen vierten Geburtstag, da wäre es doch passend.

Das Ende des Java-Plugins

 Java, Swing, UI  Kommentare deaktiviert für Das Ende des Java-Plugins
Feb 032016
 

Ich habe mich ja schon zu Anfangszeiten dieses Blogs als Fan der Java Applet-Technologie geoutet. Daran hat sich eigentlich nichts geändert. Nach wie vor halte ich Applets für den elegantesten Weg, vernünftige Benutzeroberflächen in den Browser zu bringen und gleichzeitig problemlos mit derselben Codebasis die Freunde des FatClients zu bedienen. Kluge Menschen haben behauptet, die Idee, GUIs in den Browser zu bringen, hätte die Qualität von Benutzeroberflächen 20 Jahre zurückgeworfen. Inzwischen dürften es wohl eher 25 Jahre sein, denn die Qualität von gängigen Oberflächen der 90er, sei es RISC OS oder MacOS oder die diversen GEM-Varianten, ist bis heute nicht erreicht. Optisch vielleicht schon, aber ergonomisch und performancetechnisch auf keinen Fall.

Nun hat Oracle verkündet (und schon vorher anklingen lassen, siehe etwa hier), man werde das Java-Plugin, das für die Ausführung von Applets im Browser zuständig ist, mit Java 9 als „deprecated“ erklären und es in einer späteren Version aus Java entfernen. Als Grund wird genannt, dass mobile Browser ja noch nie Plugins unterstützt hätten und diverse Browser entweder die Plugin-Unterstützung schon entfernt hätten (Chrome), dies vorhätten (Firefox) oder noch nie eine gehabt hätten (MS Edge). Dazu die Security-Problematik.

So weit, so traurig. Insbesondere den Security-Aspekt konnte ich noch nie nachvollziehen – man kann das Java-Plugin ja so konfigurieren, dass es nur Applets mit bestimmter Signatur überhaupt ausführt, insofern ist diese Technologie wohl kaum unsicherer als die Ausführung beliebigen anderen Codes auf der Maschine. Dass es ab und zu in der Sandbox (auch klaffende) Security-Lücken gab, ist ja kaum ein Alleinstellungsmerkmal von Plugins – auch die Browser selbst sind ja wandelnde Sicherheitslöcher, selbst bei so simplen Dingen wie Grafikdecodierung. Das hat man halt davon, wenn man in Pseudo-Hochsprachen wie C entwickelt. Aber ich schweife ab.

Letztlich ist das alles „water under the bridge“, und man sollte nach vorne schauen. Dazu sollte man zunächst herausfinden, in welchem Zeitrahmen man nun Abschied von den Applets nehmen muss.

Entscheidend dafür ist zunächst der verwendete Browser. Bei IE11 kann man sich noch etwas Zeit lassen – Januar 2023 endet der Support von Microsoft für den IE11, zumindest unter Windows 8. Bei Firefox muss man sich schon eher sputen, Ende 2016 dürfte es vorbei sein. Es gibt aber durchaus noch Browser, die die NSAPI für Plugins unterstützen und noch nicht abgekündigt haben – Konqueror, QupZilla oder Midori (allesamt WebKit-basiert). Wie lange das anhält, wird man sehen – nicht so weit verbreitete Browser folgen ja häufig mit kurzer Ankündigungsfrist dem Mainstream und bieten selten lange Support-Garantien.

Wie sieht es auf der Java-Seite aus? September 2017 endet voraussichtlich die Verfügbarkeit öffentlicher Java 8-Updates, basierend auf dem Oracle-Releasezyklus wird das Ende der öffentlichen Java 9-Updates also frühestens September 2019 sein. Danach kann man Oracle etwas Geld in den Rachen werfen, um weiterhin Java 9-Updates zu bekommen. Bis heute unterstützt Oracle ja gegen Einwurf kleiner Münzen sogar Java 5. Wer es also aussitzen will bis zuletzt, muss sich vermutlich bis zum Ende von IE11 (frühestens 2023 laut Microsoft) keine Sorgen machen.

Executive Summary: Don’t Panic.

Die gehackte Webpräsenz

 Uncategorized  Kommentare deaktiviert für Die gehackte Webpräsenz
Jan 302016
 

Irgendwann zwischen Weihnachten und Neujahr ist es passiert – genauer ließ es sich nicht rekonstruieren. Meine Webpräsenz wurde gehackt. Alle vier WordPressInstallationen 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.