SELF: Wenn dein Executable eine SQLite-Datenbank ist
Executable Is a SQLite Database
Der Autor stellt SELF vor, ein experimentelles Format, das ELF-Dateien durch SQLite-Datenbanken ersetzt. Dadurch werden Binärdateien zu durchsuchbaren Datenbanken, in denen Tools wie ldd oder nm zu SQL-Abfragen werden. Der Artikel zeigt, wie ELF bereits Datenbank-Primitive nachbildet, wie SELF funktioniert, und diskutiert Größen- und Latenz-Overhead.
ELF ist bereits eine Datenbank – es implementiert nur viele Datenbank-Primitive von Hand.
- andai
Dieser ganze Artikel ist fantastisch, aber schon am Anfang haut mich die Sache mit den SQLite-Virtual-Tables um.
https://www.sqlite.org/vtablist.html
Man kann sein Dateisystem (oder alles andere) als SQL-Datenbank "mounten", verdammt. Das ist erstaunlich.
Das klingt, als könnte es extrem nützlich sein.
- setheron
Ich genieße die Kommentare.
Als ich eine Kurzfassung dieser Idee in akademischen Kreisen veröffentlichte, war das Feedback nicht so freundlich.
- inigyou
> Mir ist etwas aufgefallen, das mich störte. ELF ist bereits eine Datenbank.
Noch allgemeiner angewendet: Jede Datenbasis ist bereits eine Datenbank (das bedeutet ja das zusammengesetzte Wort). Programme wie sqlite und postgres wurden früher mit dem präziseren Begriff "Relational Data Base Management Software" oder "RDBMS" bezeichnet, bis ihre Verwendung so weit verbreitet war, dass sie umgangssprachlich als Datenbanken bezeichnet wurden.
Die allerersten Datenbankstrukturen waren eher so, dass jeder geometrische Sektor einer Festplatte ein Datensatz ist und jeder Kopf eine Spalte. Das war eine direkte Übersetzung des Lochkarten-Workflows auf eine Magnetplatte.
- XJ6w9dTdM
Ja!
Das schwirrt mir schon eine Weile im Kopf herum. Und, wie andere Kommentatoren bereits angemerkt haben, wäre es großartig, wenn die Datei das (selbstmodifizierbare) Lisp-Image, ein eingebautes virtuelles Dateisystem und alles, was die Anwendung als (zur Laufzeit modifizierbare) zusätzliche Tabellen verwenden möchte, enthalten würde.
Ich finde es sehr beeindruckend, dass SQLite-Dynamic-Linking im Grunde mit ELF-Dynamic-Linking kompatibel ist. Ich kann mir vorstellen, dass es, wenn es gut gemacht ist, die meisten Verwendungen von AppImages durch ein viel effizienteres Format ersetzen könnte, wie der Autor vorschlägt.
Wie wäre es mit einer Option zum Komprimieren von Abschnittsinhalten innerhalb der SQLite-Blobs, da der Autor erwähnte, dass man die Textseiten nicht direkt mappen kann und sie ohnehin kopieren muss?
Es gibt zwei Erweiterungen, von denen ich dachte, dass sie ein SQLite-Executable wirklich einzigartig machen würden.
Erstens eine Linking-Erweiterung, die es ermöglichen würde, Funktionen und Hooks direkter zu patchen, um ein sehr leistungsfähiges Plugin-System zu ermöglichen. Stellen Sie sich vor, das Plugin-SQLite definiert einen BEFORE/AFTER/REPLACE-Hook für ein Symbol, das das Host-SQLite als erweiterbar definiert.
Zweitens: Relinking zur Laufzeit. Dies würde die Zusammenarbeit des Anwendungsentwicklers erfordern, da man das nicht von überall aus tun kann, aber stellen Sie sich vor, Sie ändern eine Abhängigkeit oder laden ein Plugin zur Laufzeit, indem Sie die Datenbank bearbeiten, und der Interpreter mappt das einfach bei Bedarf/automatisch im Hintergrund. Wenn Ihr Webserver das nächste Mal accept() aufruft, ruft er die neue Version der Behandlungsfunktion auf.
- djoldman
> Das Format selbst ist unglaublich knapp, entworfen für eine Welt, in der Speicherplatz und Netzwerkbandbreite extrem kostbar waren. Das Format zu ändern ist schwierig; man muss oft Abschnitte nullen und neue hinzufügen, da es so eng gepackt ist. Es gibt auch kein selbstbeschreibendes Schema. ELF selbst ist ein sehr generisches Format, das Datenabschnitte unterstützt, die per Konvention auf bestimmte Weise interpretiert werden, aber das Format erzwingt es nicht.
Das klingt nach einem großartigen Anwendungsfall für:
1. ELF-Datei in SELF-Datei
2. SELF-Datei ändern
3. SELF-Datei in ELF-Datei
- garganzol
Die Situation mit kopiertem vs. gemapptem Speicher ist der einzige Deal-Breaker in diesem Experiment. Ansonsten wäre die Vereinheitlichung des Dateiformats ein großer Schritt nach vorne. Das von Windows (und einigen älteren Unix-Systemen) verwendete PE/COFF-Executable-Dateiformat ist ebenfalls eine relationale Datenbank. Das Gleiche gilt für das .NET-Assembly-Format – es ist auch eine relationale Datenbank. Das Rad wird immer wieder neu erfunden.
- catlifeonmars
Ich kann akzeptieren, dass eine Objektdatei als relationale DB betrachtet werden kann. Warum aber SQLite? Warum nicht eine SQL-Abfrage-Engine über der Objektdatei unter Verwendung einer virtuellen Tabellenabstraktion? Ich sehe nicht, wie die meisten SQLite-Funktionen, mit Ausnahme einer Teilmenge der Abfrage-Engine, übertragen werden könnten.
Wenn der Autor argumentieren möchte, dass Schema-Metadaten in eine Objektdatei aufgenommen werden sollten, warum dann wieder SQLite? Das wirkt auf mich eher wie jemand, der versucht, Verwendungen für seinen Lieblingshammer zu finden (ein sehr nützlicher Hammer, das muss ich sagen), als eine ernsthafte Erkundung dessen, wie ein neues, verbessertes Objektdateiformat aussehen würde.
(Und das ist völlig in Ordnung)
- unified101
Ich denke, das geht nicht weit genug! Mach den eigentlichen App-Store zu derselben Datei. So ist es eine lebende Anwendung und die Datei wird ständig aktualisiert, je nachdem, wie du sie verwendest. Kopiere sie herum, und du trägst deine Daten auch mit dir.
Gehen wir tiefer. Es ist eine Webserver-App + der Servercode + Anwendungscode + DB, also PocketBase++, wo es auch das Bereitstellungsziel ist.
Dann kombiniere es mit einem APE-ähnlichen System, und dieselbe Datei lädt und speichert Dinge auf jeder Plattform. Böses Lachen.
Sehr cooles Hacking! Ich ziehe meinen Hut vor dem Autor.