hubersn

Java 8u40: JavaFX jetzt mit Accessibility

 Java  Kommentare deaktiviert für Java 8u40: JavaFX jetzt mit Accessibility
Mrz 052015
 

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

 Hardware  Kommentare deaktiviert für RPi – TNG
Feb 042015
 

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?

 Java, Swing  Kommentare deaktiviert für Java auf dem Desktop? Echt jetzt?
Jan 142015
 

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

 OS  Kommentare deaktiviert für Was ist eigentlich dieses RISC OS
Dez 292014
 

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.

Dez 242014
 

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

 Ada  Kommentare deaktiviert für Mein Ada-Wiedergänger
Dez 032014
 

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

 Software, UI  Kommentare deaktiviert für XYplorer – ein Dateimanager für Windows
Nov 292014
 

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

 Hardware  Kommentare deaktiviert für Neues Entwickler-Board in Sicht: BeagleBoard-X15
Nov 092014
 

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 :-)

Sep 282014
 

Ich fürchte, das „Klagelied“ wird eine Art Dauerserie hier. Denn sowohl Hardware als auch Software lassen häufig zu wünschen übrig. Und irgendwo muss der Frust ja abgelassen werden. Heute also: KVM-Switches.

Ich bin Rechnersammler. Es ist mir ein Rätsel, wie selbst IT-affine Menschen mit nur einem Computer auskommen können. Böse Zungen werden jetzt behaupten, dass ich nur deshalb mehrere Rechner brauche, weil ich ja RISC OS einsetze – und weil es dort nur so wenig Software gibt, braucht man natürlich auch noch einen gewöhnlichen PC. Gut, da mag etwas dran sein, trotzdem habe ich mehrere PCs und mehrere RISC OS-Rechner im Einsatz – das Problem besteht also trotz und nicht wegen meiner Nutzung eines Randgruppen-Betriebssystems.

Weil auch noch andere Leute mehrere Rechner haben, hat uns die IT-Industrie den KVM-Switch geschenkt. Denn die Anforderung, mehrere Rechner mit nur einer Tastatur, einer Maus und einem Monitor zu betreiben, ist dann doch offensichtlich.

Lange Jahre war ich mit einem 4-Port-KVM-Switch von Rextron recht glücklich. Es war die gute alte Zeit, als noch jeder PS/2-Tastatur und -Maus hatte, das Videosignal analog übertragen wurde und die Welt noch in Ordnung war.

Mein Rechnerpark wuchs weiter, und USB kam ins Spiel. Kein Problem, denn da gab es den guten Belkin OmniView Pro 2, der nicht nur 8 Ports hatte, sondern auch sowohl USB als auch PS/2 unterstützte. Allerdings musste die Tastatur und die Maus weiterhin PS/2 sein. Und bei der Videosignalqualität war nicht mehr alles einwandfrei, obwohl nominell der Switch für 2048×1536 gut sein sollte und die entsprechenden Kabel sauteuer waren. Aber schon bei 1600×1200 zeigten sich erste Schwächen. Das Videoproblem nervte so, dass ich inzwischen parallel noch einen einfachen 4-Port-HDMI-Switch für die Videosignale einsetze.

Und heute? Die Hardware ist diversifizierter. Da ist der alte Acorn Risc PC, der nix von USB weiß, der aber zur Not per ViewFinder DVI könnte. Da ist der MicroDigital Omega, der nur PS/2 kann und Video nur analog ausgibt. Da ist der Castle IYONIX pc, der USB kann, aber Video nur analog ausgibt. Da ist ein Wald-und-Wiesen-PC mit AMD APU, der theoretisch PS/2 und USB kann, und auch videoseitig sowohl HDMI/DVI als auch analog kann. Da ist ein Asus eeePC, der USB kann und DVI. Und da sind jede Menge RISC OS-Boards wie Raspberry Pi, BeagleBoard und PandaBoard, die allesamt nur DVI und USB können. Multi-Monitor-Betrieb wäre auch klasse, und inzwischen gibt es ja bezahlbare Monitore mit Auflösungen jenseits der 1920×1200, was nach Dual-Link-DVI-Unterstützung schreit – oder HDMI High-Speed.

Gesucht wird also ein universeller KVM-Switch – mindestens 8 Ports, PS/2 und USB für Maus/Tastatur (Konsole vorzugsweise USB), pro Port zwei Monitoranschlüsse sowohl analog als auch digital. Kaskadierbarkeit wäre gut, denn wer weiß schon wie sich der Rechnerpark entwickelt. Kür: mit HDMI-Soundunterstützung und Digital-Audio-Decoding oder zumindest ein Durschleifen des HDMI-Ports so, dass man einen AV-Receiver verwenden kann zum Decoding. Cool wäre auch, wenn man USB-Geräte zentral sharen könnte – heutzutage sollte das natürlich (man denke an USB-Sticks oder -Platten) USB 3 sein. Und eine universelle Video-Konvertierung analog nach digital und andersrum wäre eine gute Idee.

Wenn man diesen Anforderungskatalog mit real verfügbaren Geräten matcht, ist das ziemlich ernüchternd. Schon 8 Ports und Featurereichtum scheinen sich auszuschließen – offenbar ist der „mehr als 4 Ports“-Bereich fest in Profi-Hand, und dort verwendet man praktisch nur noch IP-basiertes KVM-Switching. Aufgrund abgrundtief schlechter Videoqualität ist das für den Heimbereich indiskutabel.

Kompromisse könnte man machen – der Omega ist eh schon ewig nicht mehr gelaufen, der Risc PC kann locker durch eine Emulationslösung auf dem PC ersetzt werden, der IYONIX ist für die RISC OS-USB-Entwicklung immer noch nützlich, kann letztlich aber durch andere RISC OS 5-Lösungen wie Raspberry Pi und PandaBoard ersetzt werden. Also würde ein Gerät reichen, das nur USB unterstützt, und digitales Videosignal.

Aber kann man mit einer Minimallösung glücklich werden? Geräte, die in Frage kommen würden, wären der Rextron MAAG-3114 (tatsächlich mit USB 3-Unterstützung!) und der Aten CS1794. Zu allem Überfluss auch noch nicht ganz preiswert, diese Kandidaten. Für ein äußerst mageres Featureset. Beide nur Single-Link (max. 1920×1200) und natürlich ohne Multi-Monitor-Unterstützung. Und mit nur 4 Ports. Der Aten CS1788 wäre vielleicht auch noch eine Möglichkeit. 8 Ports, Dual-Link, kaskadierbar. Für „nur“ 800 EUR.

Zum Abgewöhnen. Und wenn man sich so manche Erfahrungsberichte anschaut, gibt es bei vielen Geräten auch noch unglaubliche Schwächen – Zusatztasten auf der Tastatur werden nicht richtig unterstützt, bei manchen Bildschirmauflösungen funktioniert das Switching nicht wirklich gut, bis das Videosignal durchgeschaltet wird vergehen manchmal Sekunden (tödlich, wenn man ins BIOS will)…

Aber sollte ich ein gutes Gerät übersehen haben, bitte ich um einen entsprechenden Kommentar.

Die initiale maximale Größe eines JPanels

 Java, Swing  Kommentare deaktiviert für Die initiale maximale Größe eines JPanels
Sep 102014
 

Heute bin ich über ein interessantes Detail bei der Swing-Programmierung gestolpert. Gegeben war eine JLayeredPane, die ein JPanel (leer, nur mit Hintergrundfarbe ausgestattet) und eine Editor-Komponente (basierend auf JTextPane)  beinhaltete. Die Editor-Komponente wurde durch sehr viel Textinhalt nun relativ groß (über 70000 Pixel hoch), und man sah plötzlich, dass das JPanel nicht mehr die komplette Höhe ausfüllte.

Debugging brachte zutage, dass regelmäßig setBounds des JPanels aufgerufen wurde, mit einer Höhe von 32767 Pixeln. Aha, das Maximum eines vorzeichenbehafteten 16bit-Wertes. Aber wo kommt der her?

Des Rätsels Lösung: es ist die maximumSize des JPanels im Initialisierungszustand. Man lernt halt jeden Tag dazu, selbst wenn man seit Swing 1.1 damit Oberflächen baut.

Wer dieses Detail aus dem Stegreif wusste, darf mir gerne mailen.

Besonderer Gruß an THR, mit dem ich zusammen das Problem gedebuggt habe.