実行ファイルがSQLiteデータベースになる「SELF」、ELFを置き換える革新的フォーマット
Executable Is a SQLite Database
SQLiteを実行ファイルフォーマットとして使う「SELF」（Structured Executable & Linkable Format）を開発者が発表。ELFをデータベースとして再解釈し、セクションやシンボルテーブルをSQLテーブルに置き換える。`chmod +x`して実行可能で、`sqlite3`でクエリできる。stripやpatchelfがトランザクションになり、動的リンクもSQLで実現。サイズはほぼ同等、起動は約5msのオーバーヘッド。NixOSでbinfmt_miscを利用して実行する。
ELFはすでにデータベースであり、多くのデータベースプリミティブを手作業で実装しているにすぎません。
HNでの議論
106- andai
この記事は全体として素晴らしいですが、冒頭のSQLite仮想テーブルの部分で既に度肝を抜かれました。
https://www.sqlite.org/vtablist.html
ファイルシステム（やその他何でも）をSQLデータベースとして「マウント」できるんですよ、信じられますか？ 驚異的です。
これは非常に有用になりそうですね。
- setheron
（著者）コメントを読んで楽しんでいます。
このアイデアを学会で短い論文として発表したときは、フィードバックはそれほど好意的ではありませんでした。
- inigyou
> ELFはすでにデータベースであることに気づいた。
もっと広く言えば、あらゆるデータの集合はすでにデータベースです（複合語の意味そのものです）。sqliteやpostgresのようなプログラムは、以前はより正確な「リレーショナルデータベース管理ソフトウェア」または「RDBMS」と呼ばれていましたが、広く使われるようになり、口語的にデータベースと呼ばれるようになりました。
最初のデータベース構造は、ハードドライブの各セクタがレコード、各ヘッドがカラムというようなものでした。これはパンチカードのワークフローを磁気ディスクにそのまま移し替えたものでした。
- XJ6w9dTdM
そうです！
これは以前から頭の片隅にありました。また、他のコメント投稿者も指摘しているように、ファイルに（自己改変可能な）Lispイメージ、組み込みの仮想ファイルシステム、そしてアプリケーションが（実行時に変更可能な）追加テーブルとして使用したいものを含めることができると素晴らしいでしょう。
SQLiteの動的リンクが基本的にELFの動的リンクと互換性があるのは非常に印象的で、うまくやれば、著者が提案しているように、AppImageのほとんどの用途をはるかに効率的なフォーマットに置き換えることができると想像できます。
著者がテキストページを直接mmapできずコピーする必要があると述べていたので、SQLiteのblob内のセクションコンテンツを圧縮するオプションはどうでしょうか？
SQLite実行ファイルを真にユニークにするであろう2つの拡張機能を考えていました。
まず、関数やフックをより直接的にパッチできるようにするリンク拡張機能で、非常に強力なプラグインシステムを可能にします。ホストのSQLiteが拡張可能として定義しているシンボルに対して、プラグインのSQLiteがBEFORE/AFTER/REPLACEフックを定義することを想像してみてください。
第二に、実行時の再リンクです。これにはアプリケーション作者の協力が必要です。どこからでもできるわけではないからです。しかし、データベースを編集して実行時に依存関係を変更したりプラグインをロードしたりすることを想像してみてください。そしてインタプリタがそれをバックグラウンドでオンデマンド/自動的にマッピングするのです。すると、次にWebサーバーがaccept()を呼び出したとき、新しいバージョンのハンドリング関数を呼び出すことになります。
- djoldman
> このフォーマット自体は非常に簡潔で、ディスク容量とネットワーク帯域幅が非常に貴重だった世界向けに設計されています。フォーマットの変更は難しく、密に詰め込まれているため、セクションをゼロにして新しいものを追加しなければならないことがよくあります。また、自己記述的なスキーマもありません。ELF自体は非常に汎用的なフォーマットで、慣例によって特定の方法で解釈されるデータのセクションをサポートしていますが、フォーマットはそれを強制しません。
これは次のようなユースケースに最適ですね：
1. ELFファイルをSELFファイルに変換
2. SELFファイルを変更
3. SELFファイルをELFファイルに変換
- garganzol
コピーされたメモリとマップされたメモリの状況だけが、この実験の唯一のネックです。それ以外は、ファイルフォーマットの統一は大きな前進となるでしょう。Windows（および一部の古いUnixシステム）で使用されているPE/COFF実行可能ファイルフォーマットもリレーショナルデータベースです。.NETアセンブリフォーマットも同様で、これもリレーショナルデータベースです。車輪は何度も再発明されています。
- catlifeonmars
オブジェクトファイルがリレーショナルDBと見なせることは理解できます。しかし、なぜSQLiteなのでしょうか？ 仮想テーブル抽象化を使用してオブジェクトファイル上でSQLクエリエンジンを使うのではダメなのでしょうか？ SQLiteの機能のほとんどが、クエリエンジンのサブセットを除いて、どう移行できるのかわかりません。
著者がオブジェクトファイルにスキーマメタデータを含めることを主張するなら、繰り返しますが、なぜSQLiteなのでしょうか？ これはどちらかというと、お気に入りのハンマー（非常に便利なハンマーだとは思いますが）の使い道を探している人、という印象で、新しい改良されたオブジェクトファイルフォーマットがどうあるべきかという真剣な探求ではありません。
（そしてそれは全く問題ありません）
- unified101
私はこれでは不十分だと思います！ 実際のアプリストアを同じファイル自体にしてしまいましょう。そうすれば、それは生きたアプリケーションであり、ファイルはあなたの使い方に応じて常に更新されます。それをコピーして持ち歩けば、データも一緒に持ち運べます。
もっと深く行きましょう。それはウェブサーバーアプリ + サーバーコード + アプリケーションコード + DBであり、つまりpocketbase++であり、それがデプロイターゲットでもあります。
そして、それをAPEのようなシステムと組み合わせれば、同じファイルがすべてのプラットフォームでロードされ、保存されます。邪悪な笑い。
とてもクールなハッキングです！ 著者に敬意を表します。