Wo sind die guten E-Mail-Clients?

hubersn

Im Moment bin ich auf der Suche nach einem anständigen E-Mail-Client unter Windows. Ich bin mit Thunderbird noch nie warm geworden und halte ihn für überladen, instabil, unintuitiv und unzuverlässig. Outlook 2013 kostet mich gerade den letzten Nerv beim Support eines weitgehend unerfahrenen Computernutzers. Quasi unbedienbar, dazu ein Ressourcenfresser sondergleichen. Wenn man eine Einstellung sucht, vergeht mal gern eine Stunde. Die Suchfunktion kann sich nicht entscheiden, ob sie was findet oder nicht – und diese Entscheidung dauert lang.

Und dann stößt man beim googeln auf Beiträge wie diesen – erster Satz: „Microsofts Outlook gilt als das beste E-Mail-Programm.“ Äh – bei wem? Bei denen, die nur Lotus Notes (heißt jetzt IBM Notes, sieht aber kein Stück besser aus) als Alternative kennen? Und dann werden dort doch tatsächlich Windows Live Mail und Windows Mail als Alternative genannt. Und natürlich Thunderbird. Ansonsten: nix. Wenn man schon keinen Bock auf Recherche hat, sollte man sich doch solche Artikel gleich sparen.

Jetzt könnte man sagen – tja, was liest Du auch IT-Artikel in der WELT? Ich Dummerchen. Mal bei den Experten von CHIP stattdessen nachlesen. Großartig, diese Top 5. Wenigstens bei heise Downloads gibt es in der E-Mail-Rubrik ein paar Kandidaten.

Aber was sind denn nun die Alternativen? Pegasus Mail, das ich schon unter Windows 3.11 nicht leiden mochte? Opera Mail? Foxmail? Mailbird? eM Client, der in der freien Variante ganze zwei E-Mail-Accounts verwalten kann? Columba – immerhin in Java programmiert und Open Source, d.h. ich könnte realistischerweise eigene Anpassungen vornehmen – dessen letztes Release aus 2007 stammt? Ich ertappe mich kurz beim Gedanken, mutt oder elm unter Cygwin zu installieren. Wenn schon Retro, dann richtig.

Oder was anderes Radikales – mein aus RISC OS-Zeiten liebgewonnenes Messenger Pro in der Windows-Variante kaufen? Hatte ich schon mal in 2002, als Mark Sawle intellegit gründete und Gemini als Messenger Pro-Portierung auf Windows veröffentlichte. Bin ich unter Windows nie mit warm geworden, warum weiß ich eigentlich nicht. Inzwischen ist R-Comp auch der Vertrieb für die Windows-Version, und damit ist es traditionell fast unmöglich, Näheres über die Software herauszufinden, ohne direkt Kontakt aufzunehmen oder die Software einfach zu kaufen. Einfach kaufen? Tja, die R-Comp-Shopseite ist legendär…man kommt über den „Order now!“-Knopf auf eine selten hässliche Zwischenseite, wo einem erklärt wird, dass man doch besser die !Shop-Applikation verwenden soll. Gilt natürlich nur für RISC OS, und der arme Windows-Nutzer clickt vor lauter Verwirrung auf den „secure ordering site“-Link. Ist man clever genug, findet man hier raus, dass es offenbar eine „basic“-Version und eine „full“-Version gibt. Was mag wohl der Unterschied zwischen beiden sein? Auch konsequent: Preise nur in UKP.

Immerhin: für drei Screenshots und ein paar warme Worte hat es gereicht. Liebe Freunde von der Insel: das wird dieser Software (höchstwahrscheinlich) nicht gerecht. Der arme Mark. Nur wer die Original-Intellegit-Seite kennt, kann das Handbuch studieren oder eine etwas ausführlichere Featurebeschreibung lesen. Man kann auch eine Trial-Version herunterl…nein, man kann nur seine E-Mail-Adresse in ein Formularfeld eingeben und eine Trial-Version anfordern. Die 90er feiern ihr Revival.

Wer den ultimativen E-Mail-Client für Windows kennt, immer her mit den Infos. Am besten per E-Mail.

Die guten Erinnerungen an Ada

hubersn

Meine Programmierlaufbahn begann mit einem Schneider CPC 464 und dem eingebauten Locomotive BASIC 1.0. Ich hangelte mich am (durchaus ansprechenden) Handbuch entlang durch die Untiefen der Sprache. In ganz jungen Jahren und Mitte der 80er fand man das irgendwie alles cool und hat wenig hinterfragt, aber die Tatsache, dass man Zeilennummern verwenden musste und es als einziges Strukturierungsmittel GOTO und GOSUB gab, fand ich damals schon nicht gut. Auch wenn ich noch nicht ahnte, wieviel besser man es machen kann.

Mit den Zwischenstationen Logo, Z80-Assembler, Turbo Pascal, BBC BASIC, ARM-Assembler, C, Modula-2, HP-PA-RISC-Assembler und LISP lernte ich dann Ada kennen. Damals noch in der Variante Ada 83, also erst mal objektbasiert und nicht objektorientiert. Es war wie eine Erleuchtung. Endlich eine Sprache, die einfach alles konnte. Und in schöner Syntax verpackt. Die nicht nur auf ein paar guten Ideen basierte, wo man dann so eine Restsprache drumrum gestrickt hat. Wo schon bei liebevollen Details im Typsystem klar wird: da haben schlaue Köpfe lange gehirnt. Dazu das wunderbare „Language Reference Manual“, wo eben die definitiven Antworten drin stehen. Und das „Rationale“, wo man nachlesen konnte, warum was wie umgesetzt wurde. Und Ada 95 verstärkte diesen großartigen Eindruck noch.

Nun bin ich gestern auf einen Artikel namens „A Random Walk Through Ada“ von David Given gestoßen, der mich wieder an viel erinnert hat, was ich an Ada so alles großartig fand und finde. Leider habe ich die Weiterentwicklungen Ada 2005 und Ada 2012 nicht mehr im Detail verfolgt, weil sich die IT-Industrie ja entschieden hatte, irgendwelche anderen Sprachen zu favorisieren.

Der Artikel ist absolut lesenswert und erklärt schön, was an Ada so liebenswert ist. Eine Warnung allerdings: man wird sich dann zukünftig bei der Beschäftigung mit den diversen neuen Sprachen, die jedes Jahr aufpoppen, immer fragen, warum deren Erfinder die vielen guten Ideen der Vergangenheit schlicht ignorieren. Das scheint mir generell so eine Art Krankheit der IT zu sein: das ständige Bedürfnis, das Rad neu zu erfinden. Ohne dabei ein besseres Rad zu erschaffen, sondern nur ein anderes.

Nur eine minimale Unschärfe des Artikels will ich kritisieren: zwar ist die Container-Bibliothek, die es seit Ada 2005 in den Standard geschafft hat (und die es unter dem schönen Namen „Charles“ auch für Ada 95 gibt), nach der STL von C++ modelliert worden, aber der Autor von Charles, Matthew Heaney, ist keineswegs auch der Autor der C++-STL – die haben wir vielmehr den Herren Stepanov und Lee zu verdanken. Stepanov selbst begann seine Experimente mit generischen Containerbibliotheken allerdings mit Ada (damals noch Ada 83), vielleicht daher die Verwechslung.

Die Idiotie nachträglicher Änderungen an altgedienten Schnittstellen

hubersn

Update – siehe unten

Ich beschäftige mich derzeit mit allerlei Retro-Hardware in Vorbereitung auf die Classic Computing 2016, wie man auf dem Nachbarblog nachlesen kann. Also Floppylaufwerke, viel zu kleine IDE- und SCSI-Festplatten (Megabytes statt Gigabytes), alte Rechner als Festplatten noch Sonderausstattung waren.

Dabei ist mir eine besondere Idiotie der IT-Industrie sauer aufgestoßen. Es geht um die gute alte IDE-Schnittstelle. Früher war alles bestens: 40pin Wannenstecker am Controller und am Device, verbunden per 40pin-Flachbandkabel mit 40pin-Pfostenstecker. Verpolsicher wurde es gemacht durch die klassische „Nase“ am Stecker und einer entsprechenden Nut an der Wanne. So weit, so prima. Alle waren glücklich.

Irgendwann kam jemand auf die Idee, die Verpolungssicherheit per Nase-Nut könnte eventuell nicht ausreichend sein (und tatsächlich gab es einige Ultra-Billigheimer-Kabel, die doch tatsächlich die Nase einsparten) und führte ein zusätzliches Merkmal ein: das fehlende Loch an Pin 20 des Pfostensteckers, und damit korrespondierend der fehlende Pin in der Wanne.

Jedem Durchschnittsdummen sollte sofort klar sein: eine derartige Inkompatibilität kann nur zu Problemen führen. Während der fehlende Pin in der Wanne logischerweise nie zum Problem wird, macht das nicht-Loch nur Scherereien. Kabel passen nicht mehr in die Wanne, und wenn man nicht aufpasst, ruiniert man sich schnell mal die Hauptplatine. Aktuell habe ich hier ein Mainboard eines Microdigital Omega, der Ultra-ATA unterstützt, aber alle Pins in der Wanne bestückt hat. Ersatzkabel finden? Fehlanzeige. Pin abtrennen scheint die einzige Möglichkeit zu sein. Macht keinen Spaß bei wertvoller alter Hardware. Bei einem CF-IDE-Adapter dasselbe Problem. Gut, es geht auch noch schlechter: ein SD-IDE-Adapter hat nur eine doppelte Stiftleiste ohne Wanne, dafür mit allen Pins – wie man da die Polung herausfinden soll, bleibt im Dunkel. Vorsichtshalber wurde auch jegliche hilfreiche Beschriftung wie „Pin 1“ weggelassen.

Ebenfalls dämlich: das nicht-Loch an einem Noname-IDE-Flash-Modul. Schon die Tatsache, hier die weibliche statt der männlichen Steckerseite zu verbauen, ist besonders dämlich – somit taugt das Modul nicht als Drop-In für ein altes Laufwerk, sondern man muss noch einen Gender Changer dazwischen hängen. Oder das Modul direkt in die IDE-Buchse auf dem Mainboard reinstecken – klar, so ein kleines Flash-Modul hat als Zielgerätschaft ja keinesfalls altgediente Hardware, die mit modernen großen Platten nix anfangen kann. Und natürlich belegt man gerne mit einem Device einen IDE-Strang, der prima zwei Devices betreiben könnte. Aber gut, dann hätte man ja noch einen wertvollen Jumper vorsehen müssen für die Master-Slave-CS-Einstellung.

Und übrigens: Molex-Stecker und -Buchsen für die Laufwerksstromversorgung sind das Allerletzte.

Update – in der ersten Version dieses Artikels wurde den Transcend-IDE-Flash-Modulen unterstellt, ein nicht-Loch im weiblichen Stecker zu haben und keine Master-Slave-CS-Umschaltung zu unterstützen. Ersteres war falsch, zweiteres teilweise falsch – Master-Slave geht per kleinem Schalter, CS aber nicht (was vergleichsweise aber ein unbedeutendes Problem ist). Ich hatte das verwechselt mit einem Noname-Flash-Modul. Sorry, Transcend.

ARM-Missverständnisse

hubersn

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

hubersn

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

hubersn

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

hubersn

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

hubersn

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

hubersn

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

hubersn

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.