Beknackte Oberflächen – heute: Outlook 2010 EMail-Export

hubersn

Ich fürchte, die heute begonnene Serie “Beknackte Oberflächen” könnte ein Dauerbrenner werden. Es gibt weniges, was mich so nervt wie beknackte, unintuitive Benutzungsoberflächen. Es nervt deutlich mehr als hässliche, aber wenigstens funktionale Oberflächen.

Microsoft musste ja viel Kritik einstecken für die Einführung des “Ribbon”-Konzepts. Und das völlig zu Recht. Heute noch frage ich mich, was denn der große Vorteil dieses Konzepts sein soll, und warum es nicht wenigstens möglich war, beide Konzepte parallel zu integrieren – denn letztlich wird ja auch jede Ribbon-Aktion entweder direkt ausgeführt (so wie bei der guten alten Toolbar) oder öffnet irgendwann denselben schäbigen Dialog wie früher.

Es geht ja das Gerücht, dass Microsoft Legionen an UI-Experten beschäftigt und ständig Versuchspersonen befragt zur Benutzbarkeit ihrer Oberflächen. Keine Ahnung, wo diese Experten waren, als ein Programmierer die Aufgabe bekam, in Outlook 2010 die Funktionalität “EMail exportieren” einzubauen.

Die Ausgangssituation: ich hatte diverse zu exportierende EMails in einer Folder-Struktur gesammelt und wollte nun diesen Folder exportieren und war schon gespannt, welche Formate mir wohl Outlook anbieten würde – Microsoft ist ja auch bekannt dafür, Industriestandards – wenn sie nicht von Microsoft selbst erfunden wurden – entweder nicht oder unvollständig oder fehlerhaft zu unterstützen.

Es stellte sich aber heraus, dass das Export-Format gar nicht das Problem ist, denn die Frage war zunächst: wie funktioniert der Export denn überhaupt? Intuitiv wäre gewesen, den Export über das Kontextmenü erreichbar zu machen – aber da geht nur, über “Eigenschaften” über den Reiter “AutoArchivierung” zu archivieren – aber ich wollte ja jetzt exportieren und nicht irgendwann archivieren. Vielleicht direktes Drag&Drop des Folders ins Dateisystem? Nein, da empfängt mich das Verbotsschild. Also mal im “Datei”-Ribbon nachgeschaut, ob es da “Export” oder “Speichern” oder sowas gibt. Gibt es nicht. Jetzt war ich doch einigermaßen ratlos und bin die anderen Ribbons durchgegangen. Nix zu sehen. Die Symbolleiste für den Schnellzugriff inspiziert. Geschaut, ob es dort in den “Weiteren Befehlen” vielleicht irgendeine Export-Aktion gibt. Wieder nix.

OK, dann mal in den “Optionen” nachschauen, ob man dort irgendwo was aktivieren kann. Dann die Überraschung: Unter “Erweitert” gibt es tatsächlich einen Bereich “Exportieren” nebst zugehörigem Button. Drückt man diesen, gibt es noch eine Überraschung: ein Dialog öffnet sich, der eine Auswahl von 9 Aktionen anbietet. 9 Export-Aktionen? Nein, natürlich nicht. 7 davon sind Import-Aktionen. Ah ja. Immerhin: die anderen Dinge unter “Optionen -> Erweitert” scheinen wirklich Optionen zu sein und keine gut versteckte Funktionalität. Es ist also noch nicht alles verloren.

Die Abstraktionskaskade

hubersn

Jeder Informatiker kennt das: wenn man heutzutage Software entwickelt, kämpfen zig Frameworks und andere Technologien um die Gunst der Nutzung bei der Implementierung. Dabei versprechen letztlich alle, die Komplexität der Welt zu verstecken hinter einem mächtigen Schutzschild der Abstraktion. Mit Java ist es uns egal, auf welchem Betriebssystem wir laufen. Mit Hibernate ist es uns egal, welches DB-System wir nutzen. Mit JEE ist es uns egal, auf welchem Application Server wir laufen und mit welcher Middleware wir kommunizieren. Mit GWT ist es uns egal, in welchem Browser unsere Oberfläche dargestellt wird. Und mit Spring ist uns alles egal.

Das Problem ist nur: keine Abstraktion ist perfekt. Und damit meine ich nicht das Phänomen, das Joel Spolsky mit “leaky abstraction” benannt hat. Manche Abstraktion verhindert, dass wirklich gute Software entstehen kann. “Gut” im Sinne von performant, ins System integriert, ressourcenschonend. Allgemein könnte man sagen: Abstraktion verhindert eine spezifische Problemlösung.

Nehmen wir Java als Beispiel. Das “WORA”-Prinzip – “Write Once Run Anywhere” – ist das große Versprechen. Bei der graphischen Oberfläche war der erste Versuch “AWT”, ein Toolkit, das das Prinzip der Abstraktion schon im Namen trägt. Um “WORA” zu garantieren, implementierte AWT schlicht den kleinsten gemeinsamen Nenner bei den graphischen Oberflächen dieser Zeit. Es war erschreckend, wie klein dieser Nenner wirklich war. Der zweite Versuch – Swing – basierte auf dem Ansatz, dass es wenigstens möglich sein müsste, anständige graphische Oberflächen so zu bauen, dass sie wenigstens überall gleich aussehen, wenn auch nicht wirklich “nativ”. Mit der “pluggable Look&Feel”-Technik gab es immerhin die Möglichkeit, sich den einzelnen Plattformen aussehensmäßig anzunähern. Im Detail gab es trotzdem immer Unterschiede, weil Swing bis heute z.B. nicht das plattform-native Font-Rendering verwendet hat. Und auch Swing litt durchaus unter dem Ansatz des kleinsten gemeinsamen Nenners, der erst partiell durch das JDIC-Projekt entschärft wurde.

Wenn man es kritisch formuliert, könnte man sagen: wenn man ein Cross-Plattform-UI-Toolkit verwendet, hat man zwar auf vielen Plattformen ein UI, aber eben auch überall ein suboptimales UI. Erinnert ein wenig an die Situation im Bereich der mobilen Plattformen, wo die “im-Browser-aber-dafür-überall”-Lösungen gegen die “native-und-dafür-nicht-überall-oder-überall-anders”-Lösungen kämpfen.

Wenn man ganz weit zurückgeht, könnte man die CISC-CPUs als erste Abstraktionsschicht begreifen. Beim Z80 zum Beispiel gab es den schönen Speicherblockkopierbefehl “LDIR” (echte Nerds mit Vertiefung in Z80-Assembler wissen durch jahrelanges Studium von Hexdumps sofort den Op-Code auswendig: ED B0). Man hat drei Register geladen, LDIR aufgerufen und 21 Zyklen pro kopiertem Byte verbraten. Hat man das Kopieren “von Hand” übernommen, konnte man allerdings zwei Bytes in nur 16 Zyklen (über clevere Manipulation des Stack-Pointers und Verwendung von Push und Pop) kopieren. Also damals schon ein Fall von Performance vs. Bequemlichkeit, und auch ein wenig “einfacher zu verstehen aufgrund der Abstraktion” – eine Eigenschaft, die nicht alle Abstraktionen haben, denn oftmals abstrahieren sie so weit vom Problem, dass es eher komplizierter wird.

Ich persönlich fühle mich hinter zuviel Abstraktionen unwohl. Zu oft sind die Implementierungen fehlerhaft, so dass man beim Finden von Workarounds von der abstrakten Ebene hinabsteigen muss in den Maschinenraum. Oft wird dann die Problemlösung deutlich komplizierter – eben weil sie irgendwie wieder in die Abstraktion passen muss. Trotzdem habe ich mich über die Jahre mit Java angefreundet, begrenzt auch mit Swing und Vaadin. Trotzdem genieße ich die Abstecher zu C und ARM Assembler unter RISC OS, wo man per SWI-Aufruf mit dem Betriebssystem spricht und die Register dazu direkt befüllt – es ist instruktiv sowohl in Hinsicht auf damit erreichbare Performance und Kompaktheit als auch als Erinnerung an die eigene Fehlbarkeit.

Letztlich gibt es keinen Königsweg. Wer alles selbst machen will, wird niemals in akzeptabler Zeit fertig werden. Wer alles aus Fremdkomponenten zusammenstöpselt, wird bei der Qualität der Lösung immer Abstriche machen müssen. Time to market, Quality and Performance, Price. Choose any two. Und die Kunden nicht aus den Augen verlieren – nicht immer werden Argumente vom Schlage “kann man nix machen, das Framework macht das halt so” akzeptiert. Auf der anderen Seite kann es böse ins Auge gehen, dem Fehlschluss “wenn die Abstraktion eh nix taugt, kann ich es gleich selbst machen” zu erliegen.

Java 8u40: JavaFX jetzt mit Accessibility

hubersn

Das seit kurzem verfügbare Java 8 Update 40 schließt endlich eine der letzten Lücken, die einen seriösen Einsatz von JavaFX in Businessanwendungen verhindert hat: Accessibility, wie es neudeutsch heißt. Gemeint ist damit, dass die Komponenten der grafischen Oberfläche nun in der Lage sind, Anwendungen wie Screenreadern und Hardware wie Braille-Zeilen mit den notwendigen Daten zu versorgen. Swing konnte das seit Ewigkeiten (Java 1.2?), auch wenn die “Java Access Bridge” erst seit Java 7 mit jeder JRE unter Windows direkt in die Accessibility-Funktionalität des Betriebssystems integriert wurde.

Danke an Oracle, die jetzt ihrem Ziel, JavaFX als “Swing, next generation” zu positionieren, einen guten Schritt näher gekommen sind.

Jetzt noch eine offiziell unterstützte Implementierung von JavaFX für Android, iOS und Windows Phone, und wir kommen dem alten “WORA”-Versprechen wieder sehr nahe. One toolkit to rule them all. Auch wenn ich natürlich erst vollends zufrieden bin, wenn auch RISC OS unterstützt wird 🙂

RPi – TNG

hubersn

Recht überraschend hat die Raspberry Pi Foundation die nächste Generation des Raspberry Pi Model B vorgestellt, konsequenterweise benannt “Raspberry Pi 2 Model B”. Offenbar wollte man die Äquivalenz zu den alten 8-Bittern der Acorn BBC-Reihe nicht weiter fortsetzen, sonst hätte das Dingens vermutlich Raspberry Pi Master heißen müssen.

Gegenüber dem letzten “kleinen” Update, dem +-Modell, das bekanntlich nur eine leichte Modellpflege war (microSD statt SD, 4x USB statt 2x USB, etwas sparsamer im Stromverbrauch), handelt es sich jetzt um einen echten Nachfolger – das Herz hört jetzt auf den Namen BCM2836 und beinhaltet einen Quad-Core-Cortex-A7, der mit 900 MHz getaktet ist. Gegenüber dem Vorgänger BCM2835 mit dem 700 MHz Single-Core-ARM11 ein dramatischer Fortschritt bezüglich der CPU-Power. Man beachte, dass der Cortex-A7 ein teilweise superskalares Design ist und daher auch bei der Single-Core-Performance dem ARM11 deutlich voraus ist. Über den Daumen gepeilt würde ich etwa die doppelte Performance vermuten nach den Erfahrungen mit dem Cortex-A8, dem er am nächsten kommt in der wichtigen DMIPS/MHz-Kategorie. Der Cortex-A7 profitiert dabei auch von seiner relativ kurzen Pipeline.

Definitive Aussagen zur Performance sind im Moment schwer zu treffen, weil es kaum Informationen zum BCM2836 – klar ist derzeit nur, dass sich an der GPU namens VideoCore IV nichts geändert hat. Cachegrößen sind unklar, aber nach ersten Infos ist VFP4 und NEON mit am Start, was je nach Auslegung und Software gigantische Fortschritte gegenüber dem Vorgänger erlaubt. Ob der BCM2836 ähnlich gutmütig beim Übertakten ist wie sein Vorgänger, bleibt abzuwarten.

Was speicherhungrigen Systemen (also alle Betriebssysteme außer RISC OS…) definitiv helfen wird, ist die Aufdoppelung des RAMs auf 1 GB. Ob das RAM nicht nur größer sondern auch schneller geworden ist, dazu habe ich keine Informationen gefunden.

Ansonsten ändert sich nichts – die Platine ist für das ungeschulte Auge vom Raspberry Pi B+ nicht zu unterscheiden, demzufolge passen die Gehäuse auch für beide Modelle. Auch der Stromverbrauch sollte im bisherigen Rahmen bleiben – bei Vollauslastung aller Cores tendenziell etwas mehr. Auch schön: der Preis bleibt praktisch unverändert und liegt in Deutschland irgendwo zwischen 38 und 39€.

Für die Linuxer ist interessant, dass der Cortex-A7 nun natürlich ARMv7 implementiert – vor allem Ubuntu hatte sich im ARM-Bereich früh auf ARMv7 konzentriert, das dürfte die Sache nun erleichtern.

Interessanterweise wurde auch angekündigt, dass Windows 10 auf dem Pi kostenlos zur Verfügung gestellt wird. Was Microsoft damit bezweckt, ist mir noch etwas unklar – spannend wird sein, welche Variante es sein wird, wie man hört soll es Windows 10 in den verschiedensten Geschmacksrichtungen von CLI-only bis Full-Blown geben.

Gegenüber der Konkurrenz wie Banana Pi, Cubieboard, Cubietruck, BeagleBone Black oder auch MarS-Board, Cubox und HummingBoard hat der neue Raspberry Pi 2 nun den Wettbewerb stark verschärft – bisher hatte der Pi den Preis auf seiner Seite, die Konkurrenz die CPU-Leistung. Hier wird das Feld nun kräftig durcheinandergewirbelt. Nur im I/O-Bereich lässt der Pi weiterhin der Konkurrenz reichlich Luft zum Atmen, da weiterhin ohne Gigabit Ethernet oder SATA.

Zum Launch am Montag waren 100.000 Geräte verfügbar, offenbar hat man viel aus dem Verfügbarkeitsdesaster aus der Anfangszeit des RPi gelernt. Stand jetzt sind bei den üblichen Verdächtigen wie Reichelt oder Watterott immer noch Lagerbestände verfügbar. Nein, ich muss mich korrigieren: Reichelt meldet “ausverkauft”.

Die RISC OS-Seite der Geschichte habe ich hier schon beleuchtet, aktuell kann man hinzufügen, dass das Nightly-Build-ROM inzwischen auf dem Raspberry Pi 2 läuft.

Nachtrag (2015-02-05)

Auch Watterott ist inzwischen ausverkauft.

Java auf dem Desktop? Echt jetzt?

hubersn

Wie oft haben wir es gehört – der Desktop ist tot, der Browser ist die Plattform der Zukunft, und Java ist auf dem Client sowieso tot und existiert nur auf dem Server.

JSR 377 heißt die Überraschung offiziell. Mindestens zwei der Beteiligten sind keine Unbekannten in der Java-Welt: Andres Almiray und Hendrik Ebbers. Letzterer hat hier darüber gebloggt.

Ich bin gespannt, ob es gelingt, die Pleiten bei JSR 193 (Client Side Container, anno 2002) und dem Swing Application Framework (JSR 296) vergessen zu machen. Der Umfang scheint mir recht ambitioniert zu sein, und man läuft bei diesem Thema immer Gefahr, vom hundertsten ins tausendste zu kommen. Allein die Zielgruppe zu definieren (kleine und/oder große Anwendungen? Modularisierung selbst oder auf Basis von z.B. OSGi (oder gar Jigsaw)? Nur Entwicklung oder auch Test und Deployment? Für ein spezielles Toolkit oder generisch? Support für Persistency irgendeiner Art und wenn ja welcher Art?) ist eine Kunst. Dann die Abgrenzung gegenüber den Platzhirschen Eclipse RCP und Netbeans Platform.

Ich persönlich denke, dass ein schlankes Framework irgendwo zwischen “Swing/JavaFX von Hand” und Netbeans Platform auf jeden Fall seinen Platz finden würde. Aber das dachte ich auch schon beim (B)SAF. Mal sehen, ob es diesmal klappt.

Was ist eigentlich dieses RISC OS

hubersn

Auf meinem Nachbarblog hubersn.RISCOS geht es um dieses exotische Randgruppenbetriebssystem namens “RISC OS”, das eigentlich nur in britischen Landen und mit Abstrichen in einigen Ländern des Commonwealth eine gewisse Bedeutung erlangt hat. Wobei “gewisse Bedeutung” schon recht hoch gegriffen ist.

Nichtsdestotrotz hat RISC OS eine interessante Geschichte und wird auch heute noch von einigen wenigen Nutzern eingesetzt und von noch weniger Entwicklern vorangetrieben. Irgendwas muss also dran sein an diesem Betriebssystem. Was das ist, soll im Folgenden genauer beleuchtet werden. Ich bin hier quasi die dreifache Randgruppe – RISC OS-Nutzer, RISC OS-Entwickler, Nichtbrite.

Es war Mitte der 80er, als die Firma Acorn – auf der Insel wohlbekannt für ihre 8Bit-Rechner wie den BBC Model B oder den Electron, die hauptsächlich im Bildungswesen ihr Unwesen trieben – sich mit der nächsten Generation Computer beschäftigte und dafür einen 32bit-RISC-Prozessor entwickelte, der folgerichtig ARM (Acorn RISC Machine) genannt wurde. Man war knapp bei Kasse, Software hatte noch nie die höchste Priorität, und so schusterte man mehr schlecht als recht ein Betriebssystem mit dem Namen Arthur (angeblich steht das für “A Risc operating system by THURsday, was auf ziemlichen Zeitdruck bei der Entwicklung schließen lässt) zusammen, im Prinzip eine 32bit-Version des alten 8bit-MOS des BBC Model B. Da die Entwicklung des eigentlich vorgesehenen Betriebssystems ARX nicht in die Gänge kam (über den Grad der Fertigstellung ranken sich verschiedenste Gerüchte), entschied man sich für eine stark aufgebohrte Version von Arthur, die man RISC OS 2 taufte. Für die damalige Zeit – man schrieb das Jahr 1988 – gar kein schlechter Wurf. Vernünftige grafische Oberfläche, konsequente Mausbedienung, multitaskingfähig, das freut den Benutzer.

Acorn war Zeit seiner Existenz nicht besonders vom Erfolg seiner Computer verwöhnt, aber ARM (1990 ausgegründet und umbenannt in “Advanced RISC Machine”) war der große Wurf. Die von Acorn gehaltenen Anteile an ARM waren 1997 der Grund für die Zerschlagung von Acorn, aber der Erfolg von ARM ist letztlich der Grund dafür, dass RISC OS in den letzten Jahren wieder so etwas wie einen zweiten Frühling erlebt – eine besondere Ironie der Geschichte.

Zurück zu RISC OS. Ein Meilenstein war RISC OS 3, das 1992 in der Version 3.1 die neue “Baseline” für Archimedes & Nachfolger (A5000, A30x0, A4000, A4) darstellte. Immer noch schnell, schlank, elegant – aber deutlich abgerundet gegenüber seinem Vorgänger. 1994 leicht aufgehübscht als Version 3.5 für den Risc PC veröffentlicht, war der nächste (und gleichzeitig letzte unter Acorn-Ägide) Meilenstein die Version 3.7, die an den StrongARM angepasst war.

Version 4 war eigentlich für die nächste Acorn-Hardware-Generation vorgesehen, “Phoebe” hätte der Rechner heißen sollen. Dazu kam es “dank” der Zerschlagung von Acorn nicht, stattdessen übernahm RISCOS Ltd. (kurz “ROL” genannt) den Staffelstab und brachte 1999 RISC OS 4 auf den Markt. In den Folgejahren kam es zum “RISC OS Split” – ROL entwickelte weiter für die vorhandene (Risc PC, A7000(+)) sowie erhoffte neue Hardware (RiscStation, MicroDigital, Millipede, STD) und später vor allem für Emulatoren (VirtualAcorn) den RISC OS 4-Strang in Form von “RISC OS Select” und “RISC OS Adjust”, Castle Technology hingegen verwendete den RISC OS-Strang von Pace Technologies (die hatten sich die Reste von Acorn einverleibt, die kein anderer haben wollte) für den IYONIX pc und nannte ihn RISC OS 5. So kam es zur für Außenstehende verwirrenden Situation, dass “RISC OS 4” teilweise mehr oder andere Features hatte wie “RISC OS 5”. Vollends chaotisch wurde es dann durch “RISC OS SIX”, einer Weiterentwicklung von ROL aus RISC OS 4.39 (genannt “Adjust”). 2006 machte dann wiederum der “RISC OS 5”-Zweig von sich reden, welcher über RISC OS Open Ltd. (kurz ROOL genannt) nach und nach als Open Source (manche bestehen auch auf der Bezeichnung “Shared Source”, um die non-OSI-ness der Lizenz zu betonen) der Community bereitgestellt wurde. Daraus speist sich auch der neue Schwung in Sachen RISC OS, der dem RISC OS 5-Zweig auf allerlei ARM-Hardware wie BeagleBoard, BeagleBoard-xM, PandaBoard und Raspberry Pi Präsenz verschafft.

Soviel zur historischen Vorrede. Was außer historischem Interesse mag es heute noch für Gründe geben, sich mit RISC OS zu beschäftigen?

RISC OS ist, was viele Konzepte angeht, so etwas wie das “Anti-Linux”. RISC OS steht unter einer GPL-inkompatiblem Shared-Source-Lizenz. RISC OS ist sehr mausbedienzentriert. RISC OS zeigt, wie Datei-Drag&Drop wirklich funktionieren sollte. RISC OS hatte von Anfang an einen strengen Style Guide, so dass die Anwendungen sich alle sehr ähnlich bedienen. RISC OS hatte von Anfang an genau einen Desktop. RISC OS ist ein Single-User-Betriebssystem, das nur eine schwache Idee eines “Prozesses” und eines “Task-Schedulers” hat. RISC OS-Anwendungen müssen sich kooperativ verhalten, damit das Multitasking funktioniert. RISC OS hat keinen virtuellen Speicher. RISC OS hat keinen Datencache für Dateisysteme. RISC OS lässt dem Benutzer fast alle Freiheiten, wie er sein Dateisystem organisiert. Die RISC OS-Kommandozeile ist extrem leistungsschwach. Der RISC OS-Desktop erlaubt einen überaus eleganten, dateisystemzentrierten Umgang mit Anwendungen und ihren Daten. RISC OS hat bis heute einen semi-kommerziellen Softwaremarkt, wo kleine Anwendungen für kleine Beträge (und wenige große Anwendungen für relativ große Beträge) verkauft werden. RISC OS wird mit dem proprietären DDE assembliert und compiliert. RISC OS besteht hauptsächlich aus Assembler und nur ein wenig C. Es gibt genau eine “RISC OS-Distribution”, und zwar die von ROOL. RISC OS ist klein, kompakt und schnell. Während der Raspberry Pi für Linux lahmarschige Hardware mit knappen Speicher ist, ist es für RISC OS eine superperformante Plattform mit unendlichen Speicherweiten. RISC OS ist verhältnismäßig einfach gestrickt – vermutlich ist es das einzige wirklich nützliche Betriebssystem, das noch von einer einzigen Person in Gänze verstanden werden kann.

Als erfahrener RISC OS-Benutzer geht man niemals davon aus, dass ein Gerät unter RISC OS “einfach so” funktioniert – die Lücken in der Hardwareunterstützung sind riesig. Erst kürzlich lernte der RISC OS-USB-Stack, den isochronen Übertragungsmodus zu unterstützen – die meisten Computerbenutzer haben davon vermutlich noch nie etwas gehört, da die Mainstream-Betriebssysteme diesen selbstverständlich unterstützen. RISC OS-Benutzer hingegen haben erst seit kurzer Zeit das Vergnügen, USB-Audio-Geräte verwenden zu können. Anderes Beispiel: bis heute gibt es keine Unterstützung für WLAN-Sticks, RISC OS-Nutzer behelfen sich mit LAN-WLAN-Bridges. Dafür gibt es wiederum ganz anständige Unterstützung für UMTS-Sticks. In Verbindung mit dem Motorola Lapdock ergibt RISC OS so eine ganz passable portable Plattform – zum ersten Mal seit 1992, als der A4 veröffentlicht wurde.

Manchmal muss man unter RISC OS für Dinge bezahlen, die es anderswo wie selbstverständlich kostenlos gibt. Anständige Textverarbeitung zum Beispiel. Da muss man schon ein paar Euro bei meinem Freund Martin Würthner hinterlegen, um EasiWriter oder TechWriter zu kaufen, während auf anderen Systemen OpenOffice und LibreOffice zur Verfügung stehen. Oder Druckertreiber mit Qualitätsanspruch – auch hier ist Martin Würthner mit Gutenprint und dem PostScript3-Treiber erster Ansprechpartner. Will man Email und News lesen und schreiben, empfiehlt sich Messenger Pro von R-Comp (nicht erschrecken beim Besuch dieser Website – es hat keine Zeitreise stattgefunden!). Für Pixelbildbearbeiter ist Photodesk von CJE erste Wahl. Und obwohl eine recht moderne GCC-Version zur Verfügung steht, ist der Kauf des DDE dennoch empfehlenswert – und sei es nur als Unterstützung für die Arbeit von ROOL. Die gute Nachricht: einen Gutteil der genannten Software kann man als Raspberry Pi-Nutzer im NutPi-Bundle für kleines Geld erwerben.

Dass RISC OS das Anti-Linux ist, hat leider teilweise ungünstige Auswirkungen. So ist die Portierung von Anwendungen aus der Linux-Welt – vor allem bei denen mit grafischer Oberfläche – eher schwierig. So gibt es z.B. nur eine Uralt-Portierung von Firefox, keine von Thunderbird und OpenOffice/LibreOffice, es gibt kein Java, kein GIMP, keinen Emacs. Audio/Video-Codec-Unterstützung ist Glücksache. Die Unterstützung für Dateisysteme jenseits von FAT ist nicht vorhanden.

Das Geheimnis des zufriedenen RISC OS-Benutzers ist, dass er RISC OS nur für das benutzt, wo es gescheite Software gibt. Und dann ist die Benutzung ein Traum. Illustrationen mit ArtWorks, Textverarbeitung mit TechWriter, DTP mit OvationPro, Emails und News mit Messenger Pro. Dazu kleine feine Tools wie SparkFS, PrintPDF, StrongEd, Zap, DigitalCD und Sunfish. Zum Surfen tut es auch ein Windows-Rechner, den man per UniPrint und UniScan prima zum Treiber-Knecht degradieren kann. Und der bei Softwarenot per RDP komfortabel auf dem RISC OS-Rechner zur Verfügung steht.

Wer nun Lust bekommen hat, RISC OS mal auszuprobieren, hat zwei relativ einfache Möglichkeiten: wenn man schon einen Raspberry Pi hat, einfach NOOBS verwenden und RISC OS auswählen. Wenn man einen gewöhnlichen PC hat, RPCEmu als RISC OS-Emulationsplattform verwenden – wenn was komisch ist, liegt es dann am PC und dem Emulator und niemals an RISC OS. Man kann “ready-to-run”-USB-Sticks mit RPCEmu für Windows und Mac bei RISC OS Open Ltd. kaufen, aber der wahre Fan baut natürlich selbst.

Frohes Fest und guten Rutsch

hubersn Schreib einen Kommentar

Ich wünsche allen Lesern des hubersn.IT-Blogs ein Frohes Weihnachtsfest und einen guten Rutsch ins neue Jahr.

Ich hoffe, ich kann Qualität und Frequenz der Blogeinträge auch in 2015 halten oder sogar ausbauen. Naturgemäß gibt es in der schnelllebigen IT im Rückblick viel zu viele Themen, die man nicht behandelt hat – mit dem Start als Neublogger in 2014 bin ich dennoch ganz zufrieden, ich hoffe meine Leser sind es auch. Anregungen und Kritik gerne jederzeit per Kommentar oder per Mail.

Mein Ada-Wiedergänger

hubersn

Es war einmal ein Informatik-Student der Uni Stuttgart im vierten Semester. Bis dato wurde er programmiertechnisch mit Modula-2, Prolog und Lisp traktiert. Dann: Das Software-Praktikum in der Abteilung “Software Engineering” mit dem Thema “Durchführung eines Softwareprojekts: Entwicklung eines Fahrplanauskunftssystem” stand an. Die Implementierung erfolgte in Ada 83 unter DEC Ultrix (schon damals eher exotisch), zuvor habe ich deshalb den Ada-Kompaktkurs bei Jürgen Schwille (inzwischen hat es der zum Prof.Dr. gebracht und unterrichtet an der DHBW Stuttgart) genießen dürfen.

Gemessen an den damals verfügbaren Alternativen (C, BASIC, Pascal, Modula-2 und vielleicht noch Objective-C, wenn man sich zufällig einen NeXT leisten konnte) war Ada eine Offenbarung. Die Multithreading-Abstraktion in Form des “Taskings”, die “Derived Types”, die Abstraktionsmöglichkeiten über Packages und Generics – obwohl oft als “Designed By Committee” verschrien, fand ich Ada damals gemessen an der Leistungsfähigkeit bemerkenswert elegant.

Anno 1995 kam dann mit Ada 95 ein großes Sprachupdate. Hierarchische Packages, Objektorientierung via “Tagged Types”, eine stark erweiterte Standardbibliothek – das nächste Uni-Projekt, das Fachpraktikum mit Thema “Entwicklung eines Terminkalenders unter Gesichtspunkten des Software Engineerings” in der interessanten Kombination Backend in Ada – Frontend in Tcl/Tk, machte mich zum Ada-Fan.

Endlich war mit GNAT auch ein freier Ada-Compiler verfügbar, der sogar auf RISC OS portiert wurde. Das gab mir die Gelegenheit, mal schnell eine CD-Brenner-Software namens CDBurn in Ada zu entwickeln. Um Mitstreiter in Sachen Ada unter RISC OS zu finden, habe ich 1999 einen Artikel namens “Die Programmiersprache Ada” für die GAG-News geschrieben – ein wenig Ada-Historie, kurze Codebeispiele, was für den Einsatz unter RISC OS spricht, Literaturempfehlungen.

Der Artikel ist m.E. nicht besonders gut gelungen. Oberflächlich, sehr bemühte Beispiele, setzt gewisse Programmierkenntnisse voraus ohne diese genau zu spezifizieren…aber mangelhafte Qualität hat ja noch nie Verbreitung behindert. Die TU München hat anno 2005 meinen Text für ein Ada-Proseminar als Mini-Einführung verwendet – keine Ahnung, wie die drauf gekommen sind. Und heute sehe ich bei einer statistischen Auswertung der Referrer-URLs auf meine Domains, dass auch die Uni Stuttgart, genauer das Institut für Automatisierungs- und Softwaretechnik, in Unterlagen für das Fachpraktikum Automatisierungstechnik meinen Artikel als Literaturreferenz aufführt.

Jetzt mal ehrlich: wenn mein höchst mittelmäßiger Artikel ein zitierwürdiges Werk im deutschsprachigen Ada-Universum ist, steht es sehr sehr schlecht um diese Programmiersprache. Und das wäre ein Jammer, denn besonders die letzten beiden Sprachupdates Ada 2005 und Ada 2012 haben eine Menge getan, um die Sprache modern zu halten, ohne die ursprünglichen Stärken zu verlieren.

Also: flugs mal bei AdaCore vorbeischauen, GNAT GPL 2014 Edition runterladen , und loslegen – meine Empfehlung ist, eher das Eclipse-Plugin GNATbench zu verwenden, anstatt es mit GPS zu versuchen. Dann ein Tutorial – Vielleicht nicht unbedingt mit meinem Artikel, sondern lieber “Ada Distilled” von Richard Riehle, das Lovelace Tutorial von David Wheeler  (echt oldschool), das Wikibook zur Ada-Programmierung, den Ada Crash-Course oder, falls man einen Background in C oder C++ hat, mit diesem PDF anfangen.

Besonders mutige Naturen laden die GNAT-Variante für die JVM herunter (gibt es leider nur in der GNAT GPL 2013-Variante) – damit kann man Ada-Quellcode in Bytecode compilieren und auf der JVM ausführen. Erste Aufgabe: schreibe ein Ada-Programm, das mit Swing-Mitteln einen JFrame öffnet. Der erste Einsender einer richtigen Lösung erhält einen Sonderbonus.

XYplorer – ein Dateimanager für Windows

hubersn

Die meiste Zeit benutze ich Rechner, die unter Windows laufen. Momentan Windows 7 in der Mehrzahl der Fälle. Ganz freiwillig ist das nicht. Am liebsten würde ich RISC OS nutzen, aber das hat inzwischen nur noch wenig Software verfügbar, die ich für die tägliche Arbeit brauche – Java, eine IDE, ein Browser, alles Mangelware unter RISC OS. Linux nutze ich nur für Spezialaufgaben (aktuell ps3mediaserver, CVS-Server, git-Server, NFS-Server).

Egal welches Betriebssystem man nutzt – eine zentrale Aufgabe ist immer die Navigation im und die Organisation des Dateisystems. Erstaunlich, dass Windows dort seit Version 3.0 mit ziemlich schlechter Software ausgerüstet ist. Der Dateimanager machte den Anfang, später dann der Explorer. Bis heute nicht gerade die Spitze was Leistungsfähigkeit und Ergonomie angeht. Die Änderungen zwischen XP und 7 sind auch eher Verschlimmbesserungen.

Ich habe diverse “Commander-ähnliche” Dateimanager ausprobiert, vom TotalCommander bis zum muCommander. Ich konnte mich nie daran gewöhnen. Eventuell ist das meiner RISC OS-Vergangenheit geschuldet – den RISC OS-Filer halte ich bis heute für das ergonomischste Werkzeug für Dateisystemoperationen. Der Filer ist von derartig eleganter Schlichtheit, dass man den Erfindern täglich auf Knien huldigen will. Unter Linux gibt es den ROX-Filer, entwickelt von einem ehemaligen RISC OS-Benutzer – trotzdem fühlt er sich nicht wie das Original an. Komisch, soll aber nicht das Thema sein.

Letztlich habe ich unter Windows immer mit dem normalen Explorer gearbeitet, in Ermangelung an (mir bekannten) Alternativen. Die Wende kam heute: ich las mal wieder einen der berühmten “die x wichtigsten Freeware-Tools”-Artikel, diesmal in der Geschmacksrichtung “The Register”. Wie so oft waren die Kommentare interessanter als der Artikel, und einer der Kommentatoren nannte ein Tool namens XYplorer als unverzichtbares Werkzeug. Heruntergeladen, auf die Platte extrahiert (ja, es gibt eine “mobile”-Version, die nicht installiert werden muss), gestartet – und sofort gesehen, dass dieses Tool genau das richtige für mich ist.

Highlight-Features aus meiner Sicht – neben der Basisidee der multiplen Tabs – sind der Mini Tree und die “Mouse Down Blow Up”-Funktion. Das lässt sich mit Worten ganz schwer beschreiben, das muss man selbst ausprobieren, oder hier nachlesen. Auch die Such- und Filterfunktionen sehen sehr vielversprechend aus.

Schwächen? Die Internationalisierung scheint nicht vollständig, die deutschen Texte sind immer mal wieder von englischen Einsprengseln unterbrochen, vor allem in den Menüs.

Also: die kostenlose Version herunterladen und ausgiebig testen. Bin gespannt, wie lange meine Euphorie anhält.

Neues Entwickler-Board in Sicht: BeagleBoard-X15

hubersn

Gute Neuigkeiten für die Hardware-Frickler und ARM-Fans unter uns: Vertrauenswürdige Quellen sprechen davon, dass im Februar 2015 die Jungs von BeagleBoard.org die nächste Stufe zünden: das BeagleBoard-X15. Basierend auf TIs AM5728 SoC, einem Dual-Core Cortex-A15 SoC mit USB3, eSATA und Gigabit Ethernet, soll es der legitime Nachfolger des altehrwürdigen BeagleBoard-xM werden, das es tatsächlich auch schon seit 2010 gibt.

Wer es nicht weiß: anno 2008 begründete das BeagleBoard den Trend zum preiswerten Entwickler-Board. Noch Anfang des neuen Jahrtausends war es üblich, für Entwickler-Boards simpler ARM-basierter SoCs ein paar tausend Euro zu verlangen. Intel verlangte für sein XScale-Linie gerne mal 5000 EUR, später bei Marvell kosteten die Kirkwood- und Discovery Innovation-Boards kaum weniger.

Dann die Wende: mit dem BeagleBoard gab es ab Mitte 2008 für rund 150US$ ein voll ausgestattetes Entwickler-Board mit leistungsfähigem SoC (TI OMAP3530, 600 MHz (später 720 MHz), ARM Cortex-A8). Kurze Zeit später zog Marvell mit der PlugComputer-Serie nach, beginnend Anfang 2009 mit dem SheevaPlug, die allerdings ohne Grafikhardware an den Start gingen und mit Gigabit Ethernet ausgestattet auch eher auf den (damals noch gar nicht existierenden) Micro-Homeserver-Markt zielten.

Später beerbten BeagleBoard-xM und PandaBoard (ES) das BeagleBoard und überrundeten es leistungs- und ausstattungstechnisch deutlich. Dann veränderte der Raspberry Pi alles: preislich nochmals deutlich unter dem BeagleBoard und Nachfolgern platziert, kümmerten sich die vielen Käufer nur wenig darum, dass die CPU deutlich weniger leistungsfähig war. Die BeagleBoard-Jungs konterten mit dem BeagleBone und dem BeagleBone Black.

Für die Interessenten, die gerne für mehr CPU-Leistung auch etwas mehr Geld ausgegeben hätten, schien der Markt hingegen stillzustehen. Nur ein paar Boards auf Basis des Freescale i.MX6 hielten die Fahne hoch, konnten aber das PandaBoard CPU-technisch nicht wirklich hinter sich lassen – aber wenigstens war schnelle I/O verfügbar, mit Gigabit Ethernet und eSATA.

Mitte 2014 kam dann das ISEE IGEPv5 auf den Markt. Basierend auf dem TI OMAP5, ein Dual-Core-SoC basierend auf dem ARM Cortex-A15, wurde damit eine neue Leistungsklasse eröffnet. Leider auch eine neue Preisklasse – 210€ für die Lite-Variante sind schon ein Wort. Und es gibt Schwächen im Detail: USB3 gibt es nur als OtG-Port, und Ethernet ist leider über USB angebunden.

Und jetzt also das BeagleBoard-X15. Es wird interessant sein zu sehen, zu welchem Preis es angeboten wird – ich hoffe mal auf unter 200 US$.

Dieser Artikel ist auch ein Kaufhinweis an Gerrit Grunwald, denn ich erwarte natürlich auf dem Java-Forum Stuttgart 2015 eine Demo von JavaFX auf einer Cortex-A15-Plattform 🙂