SELF-Format: Wenn das Programm selbst eine SQLite-Datenbank ist
Queryable Executables
Das SELF-Format macht ausführbare Dateien zu SQLite-Datenbanken. Mit binfmt_misc gestartet, kann ein Programm seinen eigenen Code und Zustand in derselben Datei speichern – transaktional. Der Autor zeigt mit self-httpd einen Webserver, der seine Inhalte, Logs und sogar Live-Änderungen in sich selbst ablegt. Deployments werden zu Datenmigrationen, und Werkzeuge wie sqldiff oder FTS5 funktionieren direkt auf dem Programm. Eine Hommage an Justine Tunneys redbean, aber mit SQL als universeller Schnittstelle.
Das Programm ist die Datenbank, und die Datenbank ist das Programm.
- larodi
Ich bin erstaunt, wie viel in eine einzige Domäne kollabiert: SQL.
Vielleicht wäre es korrekter zu sagen: "Alle Daten, einschließlich Code, sind tabellenrepräsentierbar, auch wenn sie ein Graph sind" oder "alles fällt auf Tabellen zurück" oder sogar "relationale Algebra ist alles, was man braucht", aber ich bin stark dagegen, dass SQL eine Domäne für alles ist und dass alles in eine solche Domäne kollabiert.
Man kann Segmenttabellen ebenso in DATALOG kollabieren lassen, das auch ein PROLOG-Derivat ist. Das hier Demonstrierte ist also: "Alles kollabiert vielleicht in Grammatiken", was nicht neu ist, aber es gibt viele technische Details und Dinge zu beachten, um ein solches Modell für den großflächigen Einsatz tragfähig zu machen. Und das Problem ist, dass es nicht so einfach ist, etwas über Grammatiken zu schließen, bevor man sie ausführt/erschließt.
Versteh mich nicht falsch – ich liebe SQL und respektiere SQLite und DuckDB für das, was sie sind. Was wir hier sehen, ist ein sehr neugieriger Ansatz und eine großartige Demonstration.
- yjftsjthsd-h
> Wir können nicht nur eine komplette Distribution, sondern den gesamten Zustand jeder Anwendung in eine einzige Datei kollabieren, wodurch /var/ oder /tmp/ oder /home/ oder jedes andere Dateisystem überflüssig wird. Das Programm kann seinen eigenen Zustand in derselben Datei speichern, aus der es läuft, und das transaktional.
Einerseits: Ich glaube nicht, dass ich das will. Statische Inhalte zusammen mit der Binärdatei zu speichern, ergibt sicherlich Sinn. Aber schreibbare Laufzeitdaten dort zu speichern, fühlt sich chaotisch an; ich bevorzuge eine schreibgeschützte Binärdatei, der ein beschreibbares Zustandsverzeichnis übergeben wird (es ist erwähnenswert, dass ich viel Zeit mit Nix und anderen unveränderlichen Distributionen verbracht habe).
Andererseits: Das ist das Coolste und Unterhaltsamste, was ich seit langem gesehen habe, und ich möchte unbedingt, dass es 1000% weitergeführt wird. Wen kümmert schon perfekt operationalisierte unveränderliche Bereitstellung, wenn der Hacker-Geist in der Luft liegt?
Ich wette, man könnte das nutzen, um mit einer anderen Sache zu arbeiten, die APE macht: Fat Binaries. Wenn Programmtext in einer Datenbank lebt, was ist schon eine Zeile mehr? Einfach
SELECT text FROM executable WHERE arch = $(uname -m)
und los geht's :)
Bearbeitung: Eigentlich fühlt sich das bei näherer Überlegung perfekt für Smalltalk an; man kann die VM und das Image in eine einzige Datei packen.
- rao-v
Das ist verrückt und gefährlich nah an dumm, was es zu einem der besten Dinge macht, die ich dieses Jahr auf Hacker News gesehen habe.
Absolut wunderbares Zeug.
- jdub
Anstatt die Binärdatei nachträglich zu bearbeiten, um das Anwendungsschema (nicht-SELF) hinzuzufügen, könntest du Datenbankmigrationen ausführen, bevor du Anfragen bedienst. So erstellt oder aktualisiert die App bei jedem Start des Prozesses ihr eigenes Schema.
Das SELF-Upgrade (heh, Selbst-Upgrade) und Rollback-Prozesse könnten von etwas... ausgefalleneren... Schritten profitieren.
Dein Beispiel hat eine neue Binärdatei, die alte Daten hineinkopiert, aber dann muss man die neue Binärdatei an den Bereitstellungsort verschieben. Das bedeutet eine Ausfallzeit durch Stopp des Dienstes, Datenmigration, Dateiaustausch, Start des Dienstes.
Was, wenn der Upgrade-Prozess eher so wäre... die neuen SELF-Daten in die alte Binärdatei schreiben, SIGHUP senden, und dann gabelt und startet sich der Dienst selbst, während er eine HAProxy-ähnliche Null-Ausfallzeit-FD-Übergabe macht?
Das Ersetzen der SELF-Daten in der vorhandenen Datei ist jetzt sicher, weil man keine Segmente in den Speicher mappen kann. Aber wenn du am Ende doch etwas Cleveres mit BLOB-Ausrichtung und mmap herausfindest, könntest du das SELF-Upgrade wie eine Datenmigration machen! Segmente/Symbole einfügen, fork+exec, und die Datenmigration räumt den alten Code auf. :-D
Das Aktualisieren des SELF-Schemas, um mehrere Sätze von Segmenten und Symbolen zu erlauben, würde diesen Upgrade-Trick ermöglichen, könnte aber auch andere ausgefallene Dinge tun... schlanke Multi-Arch-Binärdateien, bei denen sich nur die Code-Segmente unterscheiden.
BLOB-Ausrichtung sollte auch effizienteres Ausliefern statischer Assets und eine Reihe anderer Annehmlichkeiten bedeuten... definitiv eine Untersuchung wert.
Jedoch – ein sehr starkes Jedoch – so spaßig das auch ist, würde ich niemals, niemals, niemals ein int […]
- JaumeGreen
Also wie ein Lisp-, APL- oder Smalltalk-Programm-Image, aber mit SQL als treibender Kraft.
Alles Alte ist wieder neu. Und ich meine das nicht abwertend. Es gibt viele "alte" Ideen, die einfach großartige Ideen sind, die zu ihrer Zeit nicht gewonnen haben, aber in der Zukunft mit Macht zurückkommen könnten.