実行ファイルがSQLiteデータベースに: 自己完結型Webサーバー「self-httpd」が示す新世界

完全なディストリビューションだけでなく、すべてのアプリケーションのすべての状態を単一のファイルに集約でき、/var/ や /tmp/ や /home/ などのファイルシステムが不要になる。プログラムは自身の状態を、実行中のファイルと同じファイルに、トランザクション的に保存できる。

一方で、私はそれを望まないと思う。静的コンテンツをバイナリに含めるのは確かに理にかなっている。しかし、書き込み可能な実行時データをそこに置くのは雑然としているように感じる。私は読み取り専用のバイナリを好む。それには書き込み可能な状態ディレクトリが渡される（nixや他のイミュータブルなディストリビューションで多くの時間を過ごしてきたと言っておく価値はある）。

他方で、これは久しぶりに見た中で最もクールで楽しいものであり、ぜひ1000%先へ進めてほしい。ハッカーの精神が漂っているときに、完全に運用化されたイミュータブルなデプロイなど誰が気にするだろうか？

これを使って、APEが行う別のことを実行できるだろう。ファットバイナリだ。プログラムテキストがデータベースにあるなら、行が1つ増えるだけだ。単に

SELECT text FROM executable WHERE arch = $(uname -m)

で、それでおしまいだ:)

編集：実際、さらに考えると、これはSmalltalkにぴったりだ。VMとイメージを単一のファイルに入れることができる。

これは非常識で、愚かさに危険なほど近い。だからこそ、今年ハッカーニュースで見た中で最高のものの一つだ。

本当に素晴らしい。

アプリケーション（非SELF）スキーマを追加するためにバイナリを後処理する代わりに、リクエストを処理する前にデータベースマイグレーションを実行できます。つまり、プロセスを起動するたびに、アプリは自身のスキーマを作成またはアップグレードします。

SELFのアップグレード（ふふ、自己アップグレード）とロールバックのプロセスは、もう少し…凝った…フットワークが役立つかもしれません。

あなたの例では、新しいバイナリが古いデータを新しいバイナリにコピーしていますが、その後、新しいバイナリをデプロイ先に移動する必要があります。つまり、サービス停止、データ移行、ファイル置換、サービス開始というダウンタイムが発生します。

アップグレードプロセスがもっと…古いバイナリに新しいSELFデータを書き込み、SIGHUPを送信し、その後サービスが自身をfork+execし、haproxyのようなゼロダウンタイムのFDハンドオーバーを行うようなものだったらどうでしょうか？

既存のファイル内のSELFデータを置き換えることは今は安全です。セグメントをメモリにmmapできないからです。しかし、巧妙なBLOBアライメントmmapを実現できたら、SELFアップグレードをデータマイグレーションのように行えるでしょう！セグメント/シンボルをINSERTし、fork+execし、データマイグレーションが古いコードをクリーンアップします。:-D

SELFスキーマを更新して複数のセグメントとシンボルのセットを許可すれば、このアップグレードトリックが可能になりますが、他の凝ったこともできるでしょう…コードセグメントだけが異なるシンなマルチアークバイナリなど。

BLOBアライメントは、静的アセットのより効率的な配信やその他の多くの利点も意味するはずです…確かに調査に値します。

しかし、非常に強い「しかし」ですが、これが楽しいとしても、私は決して、絶対に、絶対にint […] を許可しないでしょう。

つまり、Lisp、APL、またはSmalltalkのプログラムイメージのようなものだが、駆動力がSQLである。

古いものはすべて新しい。そして、それを軽蔑的な意味で言っているわけではない。時代に勝てなかっただけで、将来力強く戻ってくるかもしれない素晴らしいアイデアが「古い」ものにはたくさんある。