Das Klagelied: warum baut keiner gescheite…KVM-Switches

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

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.

Ein Hoch auf die Applet-Technologie

Java-Applets waren mal hip. Zu einer Zeit, als das Wort hip noch nicht hip war. Als noch nicht mal Netscape der Browser der Wahl war, sondern gerade HotJava sich anschickte, Mosaic abzulösen.

Seit geraumer Zeit verfolgt die Applet-Technologie jedoch ein schlechter Ruf. Breit publizierte Sicherheitslücken im Java-Plugin, die teilweise fragwürdigen Entscheidungen von Sun und Oracle in punkto Weiterentwicklung, und durchaus auch schlechte Qualität der Plugins in den Anfangsjahren. Inzwischen scheint der allgemeine Konsens zu sein, dass Java eigentlich auf den Server gehört. Maximal ist noch ein FatClient akzeptabel. Aber Applet? Tote Technologie. Wenn Browser-Oberfläche, dann HTML-basiert. Mit Frameworks wie GWT, Vaadin, ZK, Wicket. Oder node.js, AngularJS, jQuery. Auch die ehemals hippen Technologien wie Flash, Silverlight oder Flex sind totgesagt.

Zweifellos gibt es valide Anwendungen für pure Browser-Oberflächen. Google Maps oder Gmail zeigen das eindrucksvoll. Und doch sind die Anwendungen meist nur ein Schatten von „echten“ Anwendungen. Word im Browser? Noch nie gescheit gesehen. VisualStudio oder Eclipse im Browser? Wer mal JazzHub probiert hat – wenn sich mal jemand den Spaß am Coden verleiden will, ist das ein probates Mittel.

Doch wenn ich heute eine einigermaßen komplexe Anwendung mit graphischer Oberfläche entwickeln muss, wäre meine erste Wahl immer noch Java mit Swing als Oberflächentechnologie. Erstens ist man flexibel, was das Einsatzszenario angeht – egal ob Anwendung standalone oder als Applet im Browser. Dazu weitgehende Unabhängigkeit vom Betriebssystem und anständige Performance. Für die Entwicklung kann man das leistungsfähige Java-Tooling verwenden. Dazu die Unmengen an Librarys des Java-Ökosystems.

Durch die Flexibilität des Look&Feels von Swing (oder natürlich das neumodische CSS für JavaFX für die, die näher am Hype sein wollen) kann man eine sehr gute Integration in vorhandene Webanwendungen erreichen. Und mit der entsprechenden Konfiguration des Plugins, nur signierte Applets aus vertrauenswürdiger Quelle auszuführen, ist die Security-Problematik ebenfalls stark entschärft.

Bleibt der Nachteil, dass ein Plugin installiert werden muss und der Browser allein nicht ausreicht. Aber ist das ein größeres Problem als die Cross-Browser-Kompatibilität?

Gibt es was neues unter der Sonne?

Nach meinem Studium der Informatik habe ich mein Hobby zum Beruf gemacht. Das bringt mit sich, dass ich versuche immer auf dem neuesten Stand in der Informationstechnik, hier vor allem der Softwareentwicklung, zu sein. Dieser Blog dient deshalb nicht nur der Information der hoffentlich zahlreichen Leserschaft, sondern auch als eine Art Archiv, als Gedächtnisstütze, wie ich wann über was dachte – denn „ich hab’s ja gleich gesagt“ kann hinterher nur der glaubwürdig behaupten, der dokumentiert hat, was er vorher tatsächlich gesagt hat.

Kommentare sind hier üblicherweise deaktiviert. Wer Anmerkungen hat, darf mailen.