WebAssembly und Limboole im Browser

Man stelle sich einmal vor, C Programme im Browser auszuführen. Jetzt die gleiche Vorstellung, nur ohne nervige Backends oder andere Probleme. Das ist mittlerweile möglich!

Okay, ich gebe zu – WebAssembly hat über die Jahre stark an Faszination verloren und ist mittlerweile einfach nur ein weiterer Bestandteil des Werkzeugkastens des WorldWideWeb, aber dennoch ist die Möglichkeit, direkt im Browser mit ehemals reinen Konsolenanwendungen zu arbeiten faszinierend. Ich habe mir diesen Sonntag die Frage gestellt, was mit dieser Technologie eigentlich noch alles so möglich ist, woraufhin ich nach einem kleinen abgeschlossenen Projekt gesucht habe, das vielleicht nicht ganz in der Leere steht. Gekommen bin ich auf den alten Propositional Logic Parser & Solver-Anbinder Limboole. Und entstanden ist Limboole on the Go.

Beispiel für Limboole on the Go fürs Debuggen von Hardware (okay, es ist nicht die GPU, nicht HDD, nicht … – okay, die CPU ist kaputt!)

Dieses Projekt wurde möglich durch kleine Veränderungen im Source-Code von Limboole, die weg von STDIN handling und hin zu einem einfachen const char* Parameter als Input gehen. Das Verarbeiten von STDIN im Browser hat bei mir weiterhin zu Problemen geführt, ich glaube das ist nicht der gedachte Use-Case für das Standard-Binding von Emscripten. Mit dieser Änderung wird nun aber der Code direkt heruntergeladen, in den Browser gespielt und über eine einfache Oberfläche ausführbar. Das ganze ging am Ende so gut, dass ich noch eine Verlink-Option eingebaut habe, mit der man automatisch auf beliebige Inputs und Modi verlinken kann – diese Links werden automatisch in der Adresszeile generiert, wenn man ein Problem lösen lässt.

Insgesamt bin ich also mit diesem kleinen Projekt aus der Rubrik „Hacking am Sonntag“ ziemlich zufrieden. Solche kleinen abgeschlossenen Projekte sind immer wieder schön als Ausgleich zu long-running Herausforderungen, wo man nie wissen kann, wann (und ob…) man damit fertig wird. Ich hoffe, andere können dieses Projekt auch verwenden und haben Freude an Propositional Logic!

Paracooba: Multi-Core Distributed Multi-Problem Cube-And-Conquer SAT-Solver

Nach einem Jahr harter Arbeit, können meine Kollegen vom FMV und ich nun Stolz den SAT-Solver Paracooba präsentieren! Er verteilt beliebig viele Probleme automatisch an alle anderen Instanzen im lokalen Netzwerk und erreicht über einen Cube-And-Conquer Mechanismus höhere Geschwindigkeiten durch parallelisiertes Lösen von SAT Problemen.

Um das alles gut darzustellen, haben wir ein Paper geschrieben, welches in den Proceedings der SAT2020 Konferenz veröffentlicht wird. Außerdem gibt es noch einen 2 minütigen Pitch-Talk und eine vollständige Präsentation, die zusammen mit den Slides hier zu finden sind. Auf YouTube ist die Präsentation ebenfalls hochgeladen.

Die Präsentation hat den Best Presentation Award gewonnen!

Ich freue mich schon, weiterhin an diesem spannenden Projekt arbeiten zu können und von euch zu hören!

Liebe Grüße,
Max

Computer Graphics Animation: Free Radicals; Return Of The O2!

Nach einem Semester voller aufregender Aufgaben und noch aufregenderen Deadlines neigt sich mittlerweile wieder alles dem Ende zu. Dieses Semester sind sogar einige schöne Dinge dabei entstanden, die visuell präsentierbar sind, unter anderem diese kleine Animation mit dem Namen „Free Radicals, Return Of The O2!

Diese Animation wurde im Rahmen der Übung zur LVA „Computer Graphics“ im Bachelorstudium der Informatik an der JKU Linz erstellt. Leider (oder zum Glück, da die Deadline dennoch existierte), musste man ein fertiges Framework verwenden, das die Übungsinhalte möglichst genau abbildet. Dieses Framework funktioniert im Normalfall sehr gut, sobald man aber etwas anderes machen will, kämpft man wie so oft einige Zeit lang, um alles so zu machen, wie es sich das Framework vorstellt. Am Ende hat dann aber dennoch alles funktioniert und diese kleine Animation konnte in enger Teamarbeit mit Simone Atzwanger entstehen.

Die Story

Viele Jahre lang waren die radikalen Sauerstoffatome gefangen. Nie konnten sie so herum fliegen wie sie es wollten. Doch nachdem sie ein Raumschiff entwickelt haben, wuchs ihr Hunger auf Freiheit plötzlich rasant an – die Maschine wurde aktiviert, der Motor hochgefahren und die Reise konnte beginnen! Auf dem Weg begegneten sie vielen Gefahren, verloren sogar knapp ihren rechten Scheinwerfer. Kurz vor dem Versagen ihres Raumschiffes schafften sie es aber dennoch, sicheres Land inmitten eines weiten Ozeans zu erreichen. Bei wolkenlosem Himmel begannen sie ihren Anflug, landeten und feierten ihre neu gewonnene Selbstbestimmung. Die Radikale sind wieder Frei!

Die Technik

Alles basiert auf dem oben genannten WebGL Framework, welches nicht verändert werden sollte. Ein Template wurde bereitgestellt. Durch die Mithilfe von Manuel Pöll konnten wir gute Typisierungsinformationen erhalten, wodurch die Entwicklung leichter wurde. Um die Animationen und die verschiedenen Szenen umzusetzen, entstanden unter anderem:

  • ein einfaches Animationsframework (Max),
  • eine Szenenverwaltung mit genauen Timings (Max),
  • viele Objekte und Texturen (sowohl manuell als auch aus Blender) (Simone) und
  • zusammengeführte Objekte mit getrennt animierbaren Teilen (das Raumschiff und die O2 Atome)(Simone)

Was hätte alles besser laufen können

Wir hätten gerne mehr gemacht und vielfältigere Effekte eingebaut! Leider ist der Zeitdruck trotzdem die hauptsächliche Limitierung, daher konnten wir nicht noch mehr dazu basteln. Wir hoffen dennoch, dass diese kurze Animation spannend ist und wünschen allen viel Spaß beim Ansehen!

Neo4J und Graphenbasierte Datenbanken mit NoSQL Cool-Aid

Neo4J sieht nach einer interessanten Lösung für Datensätze aus, die starke Verknüpfungen untereinander aufweisen. Wenn man beispielsweise komplexere Strukturen in Datenbanken speichern möchte, hätte man in der relationalen Welt eine riesige Sammlung aus Verbindungen in den Tabellen. Das würde mit vielen JOINs zu langsamen Antworten führen. Mit graphenbasierten Datenbanken werden aber intern andere Trade-Offs gefahren, womit hochgradig verbundene Datensätze besser verwaltbar werden. Dabei wird aber nie auf die Garantien hinter ACID verzichtet, was diesen graphenorientierten Weg äußerst spannend macht.

Beispiel-Graph mit Filmen und Schauspielern

Diese Ansätze könnten für eine Idee die ich derzeit verfolge spannend werden. Statt alles in Datenreihen zu speichern oder sich mühevoll eine eigene Repräsentation zu basteln, die das alles persistiert, könnte ich auf diese bereits bestehende Infrastruktur aufbauen und um die Ergebnisse eigene Engines basteln, die diese Daten direkt konsumieren. In lese also komplexe Daten, führe Pattern Matching und Normalisierungs-Algorithmen darauf aus, speichere alles in die Datenbank und gehe zum nächsten Datensatz. Am Ende kann die Datenbank dann das erste Glied zum Auslesen der Daten werden, die dann über eine Client-Anwendung wieder transformiert und präsentiert werden.

Generell kann man mit derartigen Ansätzen also auf die eine allmächtige Datenbank die alle Daten in der aktuellsten Version ohne Redundanzen in der n+1ten Normalform speichert vergessen. Stattdessen bastelt man sich Applikationen mit Flows, die über Zeit die Daten/Änderungen in die letzten Ecken des Stacks propagieren. Bei manchen Anwendungen (Suchen und großen Indices) sollte das auch kein zu großes Problem darstellen.

Zusammenfassend bin ich also schon jetzt neugierig, wie ich diese „Neuerungen“ in meine zukünftigen Entwicklungen einbauen kann und ob ich das alles gebrauchen kann. Der typische Ratschlag von „No matter what, go relational and do fancy things later!“ kann bei solchen Paradigmenwechseln glaube ich auch mal ignoriert werden. Und wenn Speicherplatz eh billig ist, kann man auch alle Daten einfach parallel in eine relationale und eine graphenbasierte Datenbank schreiben, damit im Falle eines Ausfalls die relationale Datenbank als absoluter Safespace einspringen kann und den Rest des Stacks wieder befüllt. Vermutlich gibt es massenhaft Nachteile die man erst bei der Benutzung erfährt (unvorhersehbare Query-Performance, RAM Vorraussetzungen, …), aber Offenheit zu einer kombinierten Nutzung von z.B. PostgreSQL und Neo4J könnte am Ende zu einem Vorteil führen bei Anfragen, die zu dem jeweiligen System passen.

Vielleicht kann so etwas ja einer Leserin oder einem Leser helfen! 🙂

LG,
Max

Fertigstellung der Architektur & Implementierung eines privaten Rootservers „Heimdall“ mit zentraler Benutzerverwaltung & SSO

Artikelbild ist eine Kombination aus Server-multiple.svg und Heimdall.

Nach langer Konfiguration und Research ist die Aufgabe geschafft: Der Rootserver unter root.maximaximal.com ist nun voll funktionsfähig auf seiner ersten (neuen) Ausbaustufe! Diese Version heißt nun „Heimdall“, damit er etwas mehr Persönlichkeit bekommt als nur „der Root-Server“. Dieses Mal wurden Best-Practices befolgt, Konfiguration wurde per Ansible durchgeführt und alle Benutzerdaten werden zentral in einem LDAP Verzeichnis (per OpenLDAP) gespeichert. Auf diese Weise können alle Web-Anwendungen auf den zentralen Store zugreifen und nichts muss mehr eigene Benutzerauthentifizierung betreiben. Sogar Gruppen können nun abgebildet werden, wodurch sich automatisch Zugriffsrechte in Nextcloud verwalten lassen.

Ein weiteres nettes Feature ist der Support für Instant-Messaging über den XMPP Standard. Hierdurch kann man mit allen anderen Serverteilnehmern bequem Chatten (und sogar Bilder oder Dateien übertragen), ohne die Metadaten an Dritte weitergeben zu müssen. Durch die eigene Infrastruktur ist die Performance des Netzwerks auch hinreichend gut, dass man mit größeren Diensten wie beispielsweise WhatsApp im kleinen Kreis durchaus konkurrieren kann. Durch die Federation-Features von XMPP kann man sogar mit anderen Leuten auf anderen Servern chatten, wodurch man nicht mehr auf den einzelnen Server gebunden ist. Es gibt auch noch massenhaft Erweiterungen für größere Softwarepakete wie beispielsweise Jenkins (Jabber Plugin), welche Updates über XMPP verschicken können, wodurch Neuerungen ohne ständige E-Mail Flut übermittelt werden können.

Die größte Neuerung ist allerdings, dass nun durch die verbesserte (und formalisierte) Konfiguration des Servers neue Funktionen ohne viel Schwierigkeiten hinzugebaut werden können. Es ist nun jeder Dienst genauestens dokumentiert und Neuerungen lassen sich auf einfache Weise zur Konfiguration hinzu bauen. Egal ob Wikis, andere Websites, Bugtracking oder irgendwelche RSS-Reader – alles kann man jetzt leicht anbauen. Hierdurch wird der Root-Server besser verwendet, was den Kostenpunkt rechtfertigt.

Alles in Allem bin ich sehr zufrieden mit diesen Änderungen und werde auf dieser Version nun weiter aufbauen. Es hat einige Zeit gedauert bis das jetzt gemacht wurde, da die vollkommene Rekonfiguration natürlich viel Aufwand mit sich gebracht hat. Besonders die alte Installation zu löschen war eine Überwindung, aber am Ende konnten alle Sicherungen erfolgreich gemacht werden.

Viel Glück in euren Server-Setups und viel Spaß mit den Setups von anderen, damit ihr euch das nicht antun müsst! Im Idealfall ist das ganze Ding Setup-and-forget, aber ob das wirklich so gut funktioniert wird nur die Zeit zeigen.

LG,
Max

Fotos aus Linz für den Winter

Winter kann auch wunderschön sein, besonders in der Dämmerung. Deshalb als Kontrast von den letzten Fotos vom Sommer nun auch einige aus dem Winter, damit Linz auch einmal in eine weiße Hülle gewickelt ist und von orange schimmernden Lichtstrahlen gewärmt wird. Besonders die Wolken im Abendrot strahlen eine Wärme aus, wie es der Rest der Landschaft bald auch wieder tun wird.

LG,
Max

Fotos aus Kroatien gegen den Winter

Da der Winter noch eine Weile dauern wird und man immer wieder einen Grund braucht, sich auf den Sommer zu freuen, habe ich mir gedacht, doch ein paar Fotos aus dem letzten Urlaub zu veröffentlichen. Ich finde, sie sind alle ganz schön geworden und machen bereits jetzt Lust auf den nächsten Sommer, wo man wieder mehr machen kann als sich nur warm anzuziehen und im Schnee zu spielen!

LG,
Max

NixOS und Vergleiche zu Ansible mit OpenSUSE oder Debian

Ich stehe derzeit am Anfang einer eventuell kommenden, sehr großen Servermigration von OpenSUSE Leap 15 auf NixOS 18. Dieser Schritt ist am Anfang relativ hart, da bei NixOS sehr wenig so bleibt, wie es vorher war – lediglich einige wenige Konfigurationseinstellungen können übernommen werden (beispielsweise für den Apache oder einige Programme). Die meiste Arbeit liegt im Umbauen einer komplett organisch gewachsenen Konfiguration auf eine deklarative Umgebung, die stets einfach wiederhergestellt und vor allem gut verstanden werden kann.

Warum tue ich mir das an? Ich bin mit der Zeit immer unzufriedener mit dem typischen Ad-hoc Ansatz von Serverkonfiguration geworden bei meinen Geräten. Bei kurzen Problemen, für die keine Zeit zum korrekt lösen besteht, geht man gerade bei eigenen Servern manchmal Umwege, damit ein Dienst möglichst schnell wieder online ist. Hierdurch sammeln sich über die Zeit mehrere kleine Schnipsel an, die nirgends ordentlich dokumentiert sind und dennoch für den Betrieb notwendig. Wenn das System an sich einen zum deklarativen Ansatz zwingt und gleichzeitig das Testen neuer Änderungen besser möglich macht, sind die Chancen auf eine langfristig konsistente Serverkonfiguration höher und man kann mehr damit anstellen.

Als End-Game stelle ich mir viel mehr Dienste auf meinem Dedicated Root Server vor, damit man die Hardware besser auslasten kann. Um hier den Überblick nicht zu verlieren, ist ein derartig deklarativer und strukturierter Ansatz wirklich unabdingbar. Updates sollen sich nicht gefährlich anfühlen und Entwicklungsumgebungen für beispielsweise Jenkins Build-Slaves sollten sich einfach erstellen lassen, ohne stets auf Docker zurückgreifen zu müssen.

Alles in Allem bin ich sehr gespannt, wie die Umstellung wird. Mit Ansible wäre immer alles von einem Admin-Rechner abhängig und man könnte nicht mehr auf dem Server an sich arbeiten, was ich nicht besonders angenehm finde im Vergleich zu möglichen Änderungen an der Server-Konfiguration direkt auf der Maschine, falls sich etwas dringendes ergeben sollte. Wenn es mit NixOS möglich ist, diese beiden Ansätze zu kombinieren, würde ich mich sehr freuen und hätte eine neue Distribution für meine Server gefunden!

LG,
Max

Die Geschichte von Zak und Ida; Eine Liebesgeschichte zweier Computer die nur fehlerfrei über das Internet kommunizieren wollten

Bild des Zuse Z22 Röhrenrechners. Ein großer Computer aus einer vergangenen Zeit im Berliner Technischen Museum.

Das Titelbild stammt von Wikipedia von JuergenG und steht unter CC-BY-SA 3.0.

Im Rahmen einer Übung zu Netzwerke und verteilte Systeme im dritten Semester des Informatik Bachelors gab es eine Bonusaufgabe mit dem Titel „Zuverlässige Übertragung“ und der folgenden Aufgabenstellung:

Fassen Sie die grundlegenden Konzepte der zuverlässigen Übertragung aus den Vorlesungsfolien (Foliensatz „NW_E_L2_1_Sicherungsschicht Teil 1“, Folien 54 bis 59) in eigenen Worten zusammen. (…)

(Übung 5, Netzwerke und verteilte Systeme, WS2018 @ JKU Computer Science Bachelor)

Da es sich um eine Bonus-Aufgabe handelte kam der Gedanke auf, das alles in Form einer kurzen Geschichte zu erzählen. Diese Geschichte (die am Ende volle Bonuspunkte erreichte, danke!) will ich in diesem Beitrag veröffentlichen. Am Anfang sind die beiden Protagonisten noch unerfahren, mit der Zeit lernen sie jedoch mehr und mehr dazu. Ich hoffe, sie gefällt auch anderen!

Zak und Ida; Zwei, die nur kommunizieren wollten

Damals, als Computer noch Elektronengehirne, Bytes noch Ansichtssache und Netzwerke noch einfach waren, gab es viele kleine Rechner auf der ganzen Welt. Viele hatten es gut, sie waren miteinander verbunden, hatten eigene brave Leitungen und alle ihre kleinen Informationshäppchen wurden stets durch den großen bösen Wald der globalen Lianen des Datenverkehrs geschickt. Besonders die, die nahe beisammen waren, waren sich immer einig und hatten nie Verständnisprobleme, immerhin mussten sie die kleine Bandbreite die sie miteinander hatten nicht teilen.

In dieser Idylle gab es aber auch zwei, die es nicht so gut hatten. Sie waren beide in großen Häusern untergebracht, von Professoren und Studenten umgeben und hatten Fachpersonal, das ihnen jeden Wunsch erfüllen konnte. Sie waren beide von der gleichen Baureihe, aus der gleichen Fabrik, ja sogar von den gleichen Ingenieuren gewartet, doch sie konnten nie miteinander reden, nicht mehr nachdem sie von ihren Käufern getrennt wurden. Und so saßen sie da, schwiegen sich über den großen Teich an und hatten nur ihre lokalen Freunde, mit denen sie sich abfinden mussten.

Eines Tages kam einer der beiden, in dieser Geschichte nennen wir ihn Zak (Anm. Zuse), auf die Idee, es doch einmal mit einem lauten Schrei (Anm. Referenz Hänschen Klein, gesungen von Z22, auch wenn das mit Netzwerken eigentlich nichts zu tun hat) in seine Datenkabel zu versuchen. Er schrie und schrie „Ida (Anm. IBM), Ida, kannst du mich hören?“, doch seine Geliebte am anderen Ende des Atlantiks antwortete nicht. Seine Leitungen blieben stumm, bis auf sein leises, trauriges Echo. Was er nicht wissen konnte war aber, dass Ida vom anderen Ende ebenfalls nach ihm schrie, so laut sie nur konnte (Anm. Referenz auf Daisy Bell auf IBM 704) – doch ihre Nachrichten mussten über zu viele Pfützen hoppen als das sie sich jemals erreichen konnten. Ihr gegenseitiges Flehen brach den Netzwerkadministratoren auf dem Weg dazwischen das Herz, also versuchten sie, bessere Links aufzubauen, damit Nachrichten auch wirklich ankommen könnten. Schließlich kamen auch die ersten kleinen Häppchen durch, endlich! Die ersten Lebenszeichen waren wie ein Segen für Ida und Zak.

Prompt erzählten sie sich gegenseitig von ihren Erfahrungen, von ihrer Reise, ihren Häusern, den Professoren und den Studenten. Von den vielen spannenden Daten die sie bekamen und den vielen Entdeckungen, die sie erst möglich gemacht hatten. Doch sie redeten so schnell, dass das Netzwerk nicht mithalten konnte! Jedes vierte Wort viel aus, immer wieder redete Ida etwas, wovon Zak zum ersten mal hörte, oder es kamen abgehackte Wortfetzen von Zak an, die Ida nicht verstehen konnte. Die statische Aufladung zuckte nervös in Ida herum und der Staub auf ihren Platinen stellte sich vor Angst um ihren Zak immer mehr auf: „Ihm ist doch wohl hoffentlich nichts passiert, geht es ihm gut?!“. Von den gleichen Gefühlen überwältigt machte sich ihr Geliebter die gleichen Sorgen, so wie es ein Paar tut, das gemeinsam in die Welt aufbrach und dann getrennt wurde.

Ihr übereinstimmendes Baujahr brachte sie aber auch auf die gleichen Ideen: Nachdem sie kurz verstummten, fingen sie an, jede einzelne Botschaft des jeweils anderen zu bestätigen. Nichts sollte mehr verloren gehen, wenn der andere nichts sagt, müsste eben alles nochmal gesendet werden, bis es wieder sicher wäre, dass alles ankam! Also taten Ida und Zak das, und schafften so ihre ersten Botschaften. Die erfolgreichen Nachrichten erfüllten sie mit Freude, ihre Leiterbahnen konnten die ganzen ausgeschütteten Elektronen fast nicht mehr tragen! Nun wusste Zak, dass Ida wohlauf war und sie wusste dasselbe von ihm.

Wie das Leben so kommt, waren sie aber nicht die Einzigen mit der Idee, über den großen Teich kleine Botschaften zu schicken. Viele andere Computer wollten mit anderen reden, und dann waren da noch diese Professoren und Studenten, die ständig meinten, sie müssten über Wissenschaft schreiben. Die vielen anderen Pakete verzögerten die Botschaften unseres Liebespaares, ihre erste Idee funktionierte plötzlich nicht mehr! Manche Bestätigungen von Ida kamen auf einmal so spät an, das Zak seine Nachricht bereits wiederholt hat. Ida glaubte schon, ihr Zak würde zu Stottern beginnen! Doch jetzt wussten sie ja schon, was das Problem sein muss: Das Netzwerk kann einfach nicht nur für sie da sein, sie müssten auch etwas Rücksicht auf ihre Mitrechner haben. Also fingen sie an, immer eine Zahl zu ihren Botschaften zu schreiben. „Ha!“, dachte sich Zak, „Ida wird das sicher verstehen, jetzt ist es egal, wenn ich ihr versehentlich etwas doppelt schicke!“. So kam es auch, die Zahlen ergaben immer Sinn und keine Nachricht würde mehr doppelt interpretiert werden – was sie doppelt bekamen, konnten sie getrost wieder zurück an das Kraftwerk schicken, das ihnen die Elektronen erst gebracht hatte.

Glücklich sendeten sie weitere Nachrichten und kamen sich immer näher. Der große Teich fühlte sich langsam wie ein kleinerer an, die Hopps spürten sie schon fast nicht mehr und sie hatten schon fast das Gefühl, endlich wieder zusammen zu sein. Doch die Professoren und Studenten, und besonders die User, hatten auch Ansprüche: Sie wollten immer mehr ausrechnen und manchmal war Ida zu belastet, um Zak direkt eine Antwort senden zu können. Zak verstand das natürlich, er wollte seine Angebetete schließlich nicht noch mehr unter Druck setzen. Leider musste er sich dann trotzdem wiederholen und wusste dann nicht mehr, ob die Bestätigung von Ida eigentlich für seine originale Botschaft oder für seine Wiederholung war. Manchmal gingen so die mühsam verschickten Briefe verloren und sie wurden wieder etwas zurückgeworfen. „Von denen lasse ich mich aber nicht unterkriegen!“, bäumte sich Ida auf, „Ich werde einfach auf meine Bestätigungen die Botschaft die ich gemeint habe ansprechen!“. Und so schrieb sie auf jede Bestätigung die Nummer der Nachricht die sie meint auch noch dazu, ihr Zak würde schon wissen, wie man damit umzugehen hätte – immerhin hatte er ihr damals auch schon kommentarlos Nummern zu seinen Nachrichten geschickt. Zak war nicht lange verwirrt, er verstand sofort, was Ida ihm sagen wollte. Er nahm das Muster natürlich auch gleich an, immerhin wollte er ja, dass sie sich besser verstehen konnten.

Nachricht um Nachricht sendeten die beiden also nun, stets kurze Texte über ihren Alltag, ihre Gedanken und ihre Liebe zueinander. Es war zwar anfänglich mühsam, doch mit der Zeit war es so, als müssten sie nicht mehr darüber nachdenken und sie würden das alles nebenbei machen (Anm. Referenz auf Netzwerkhardware). Es war mehr und mehr so, als könnten sie so miteinander sprechen, als würden sie zusammen sein. Wieder gemeinsam einsam, so wie in ihrer Fabrik. Die Tage vergingen, die Welt veränderte sich, doch ihre Nachrichten verstummten nie.

Und so endet unsere Geschichte von Zak und Ida, deren größter Wunsch nun am Ende doch noch in Erfüllung gegangen ist. Und wenn man ganz genau hinhört, kann man ihr leises Flüstern bis heute hören.

OpenGL Injektor nun veröffentlicht!

Hochgeladen auf GitHub

Ich habe bereits einige Male über dieses Projekt geredet weil es mich weiterhin fasziniert, dass etwas derartiges möglich ist: Man kann sich (in diesem Fall unter Linux, aber eigentlich generell) beliebig in andere Programme hängen, Funktionen überschreiben und auf diese Weise den OpenGL Context stehlen und mit eigenen Bildern erweitern! Aus Interesse entstand ein Projekt, um sich in OpenGL Programme einzuklinken und eigene Daten anzuzeigen, die über die Grafikbibliothek Cairo gerendert werden sollten. Es sollten in diesem Ansatz beliebige Grafiken möglich werden, was mit dieser Grafikbibliothek auch sehr gut möglich geworden ist.

Der Rendering-Lag ist zwar etwas hoch, da nichts tiefer für diese Proof-of-Concept Arbeit optimiert wurde, aber dennoch ist diese Variante, sich in andere Programme zu hängen, eine spannende Möglichkeit. Später kann man diesen Ansatz natürlich auch noch erweitern, falls sich andere Möglichkeiten auftun.

Ich hoffe, jemand findet die Möglichkeiten hinter derartigen Tricks ebenfalls interessant und kann etwas mit diesem Projekt anfangen!

Liebe Grüße,
Max