SGrottel.de

Immer wieder steht man vor ganz einfachen Aufgaben und sieht die einfachste Lösung nicht. Des Letzt musste ich zwei Binär-Dateien einfach nur zu einer großen zusammenfügen. Ich wusste zuerst wirklich nicht wie ich das unter Windows ohne irgendwelche Kopfstände hinkriegen könnte. Allen möglichen Unsinn hatte ich mir überlegt, alles auf ein Linux rüber zu kopieren und es dort zu machen, ein Powershell Script, ein Tool googlen, selber ein kleines DotNet-Tools zusammenklicken. Glücklicherweise entscheid ich mich anstatt nach einem Tool, einfach mal nach dem Problem selbst zu googlen. Dabei kam raus, Windows kann das einfach selbst. Bzw. die alten DOS-Kommandos die in Windows noch immer bestehen:

copy /y /b file1+file2 dest

Erschreckend einfach.

Achtung! Dieser Post ist veraltet: hier geht’s zum Update.

Ich habe vor langer Zeit aufgehört mit Dual-Boot-Systemen zu arbeiten und meine Art zu Arbeiten ist fest mit Windows und den dortigen Produkten verankert. Details und den dazugehörigen Glaubenskrieg zwischen Windows und Linux spare ich mir hier. Allerdings ist Linux ein System auf das ich durchaus auch nicht verzichten kann. Die augenblicklich beste Lösung für mich ist VirtualBox und der Betrieb eines virtualisierten Gast-Linux. Im gigantischen Distributions-Zoo hab ich mich recht einfallslos für Ubuntu entschieden. Als Computergraphiker und Visualisierung ist mir hierbei natürlich auch der OpenGL-Support in der Virtualisierung sehr willkommen. Diese Woche habe ich eine neue virtuelle Maschine aufgesetzt und wurde von folgendem Fehler heimgesucht der meine OpenGL-Anwendungen nicht starten lassen wollte:

libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: glFlushVertexArrayRangeNV not found in mesa table
OpenGL Warning: glVertexArrayRangeNV not found in mesa table
OpenGL Warning: glCombinerInputNV not found in mesa table
OpenGL Warning: glCombinerOutputNV not found in mesa table
OpenGL Warning: glCombinerParameterfNV not found in mesa table
OpenGL Warning: glCombinerParameterfvNV not found in mesa table
OpenGL Warning: glCombinerParameteriNV not found in mesa table
OpenGL Warning: glCombinerParameterivNV not found in mesa table
OpenGL Warning: glFinalCombinerInputNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterivNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glDeleteFencesNV not found in mesa table
OpenGL Warning: glFinishFenceNV not found in mesa table
OpenGL Warning: glGenFencesNV not found in mesa table
OpenGL Warning: glGetFenceivNV not found in mesa table
OpenGL Warning: glIsFenceNV not found in mesa table
OpenGL Warning: glSetFenceNV not found in mesa table
OpenGL Warning: glTestFenceNV not found in mesa table
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo

Erstaunlicherweise hat kurzes Googlen nicht viel gebracht. Lediglich auf einer Seite habe ich gelesen, dass es das Problem mit den GuestAdditions zusammenhängen könnte und man unbedingt darauf achten solle die aktuellste Version zu installieren. Logischerweise hatte ich aktuellste Version drauf.

Nach etwas mehr Googlen kam raus, dass das Problem im Zusammenhang mit sehr neuen OpenGL-Extensions existiert; Extensions zu neu für die virtuellen Treiber. Hier gibt es also scheinbar einen Konflikt zwischen dem was die virtualisierte Graphikkarte angibt welche Extensions sie beherrscht und damit was der Linux-Treiber daraus machen kann.

Tatsächlich konnte ich das Problem für mich lösen indem ich auf ältere Versionen der GuestAdditions zurückgegangen bin. Mit Version 4.3.12 läuft alles einwandfrei. Mit den neueren Versionen bis 4.3.18 nicht. Dies ist dann wohl ein Iso was ich mir auf der Platte behalte und abwarte ob neuere GuestAdditions oder Ubuntu-Updates das Problem in den Griff kriegen werden.

Interprozesskommunikation war schon immer ein bisschen ein Mist, zumindest wenn man plattformunabhängiges C++ als Arbeitsgrundlage verwendet. Ich hab viel Ausprobiert und irgendwie war alles nicht zufriedenstellend. Entweder war die Performance nicht akzeptable oder die Benutzbarkeit oder Wartbarkeit waren es nicht. Ich hatte keine Methode gefunden auf der ich guten Gewissens aufbauen wöllte.

Ein de-facto Industriestandard sind ja wohl zweifelsohne Webservices. Aber aus meinem Blickpunkt, dem Blickpunkt eines Visualisierers und Computergraphikers, ist der Overhead, sowohl der Erzeugung als auch der Laufzeit, nicht wirklich akzeptabel. Ich rede nicht unbedingt von jeweils Datendurchsatz, Architektur oder Latenzzeiten. Nimmt man aber alles zusammen und versucht sie auf das Szenario der interaktiven Visualisierung anzuwenden so erhält man ein System was 90% der Probleme löst. Die restlichen 10% allerdings, sind so schmerzhaft schlecht, dass man immer gezwungen wird einen zweiten Datenkanal zu nutzen. Und schon macht man irgendwie wieder alles doppelt. Die Programmierung in der Computergraphik und der interaktiven Visualisierung ist so bedauernswert weit weg von sinnvollem Software Engineering. Aber ich habe es mir ja auch ausgesucht dieses Problem als eigenes Forschungsfeld anzugehen und entsprechende Lösungen zu erarbeiten. Es ist eine äußerst unfruchtbare Arbeit, aber es ist mir wichtig und ich bin überzeugt, dass es das wert ist.

Eine Idee die mir seit neuster Zeit im Kopf rum geht dreht sich hierbei um JSON-RPC. Das Protokoll ist simpel, klein, trivial, aber praktisch für alle technischen Probleme ausreichend; eine charmante Kombination. Im Besonderen, da der eigentliche Kommunikationskanal ja nicht feststehen muss. So können die entsprechenden Anfragen in den high-performance Datenstrom der restlichen Kommunikation mit eingeflochten werden, müssen es aber nicht. Als reine interpretierende und verwaltende Ebene halte ich das Ganze für eine ungemein gute Idee.

Und an der konkreten Umsetzung krankt es wieder. Ich will nicht behaupten, dass ich bisher eine erschöpfende Suche nach Bibliotheken durchgeführt hätte, aber die die ich bisher gesehen habe sind von ernüchternder Qualität. Während, als Grundlage, jsoncpp und jansson einen guten Eindruck hinterlassen haben, kann ich das über JsonRpc-Cpp und libjson-rpc-cpp nicht behaupten. Ich will die beiden Projekte nicht schlecht machen. Sie erfüllen nur einfach meine Anforderungen nicht, z.B. dass man sie als Dlls unter Windows bauen kann, ohne massive Änderungen am Quelltext durchführen zu müssen.

Ehrlich gesagt, weiß ich noch nicht wo das ganze mich hin führen wird. In nächster Zeit sicherlich nirgendwo hin, da ich noch genug andere und wichtigere Baustellen gerade offen habe. Aber die Idee bleibt gut und ich werde sie weiter verfolgen.