SELF: ваш исполняемый файл — это база данных SQLite

Мне нравятся комментарии.

Когда я публиковал короткую статью с этой идеей в академических кругах, отзывы были не такими доброжелательными.

> Я осознал кое-что, что меня беспокоило. ELF — это уже база данных.

Если применить это ещё шире: любые данные — это уже база данных (именно так переводится это составное слово). Программы вроде sqlite и postgres раньше называли более точным термином «программное обеспечение для управления реляционными базами данных» или «СУБД», пока их использование не стало настолько повсеместным, что их в разговорной речи стали называть просто базами данных.

Самые первые структуры баз данных были больше похожи на то, что каждый геометрический сектор жёсткого диска — это запись, а каждая головка — это столбец. Это был прямой перенос технологии перфокарт на магнитный диск.

Да!

Это уже давно сидит у меня в голове. И, как отметили другие комментаторы, было бы здорово, чтобы файл содержал (самомодифицируемый) Lisp-образ, встроенную виртуальную файловую систему и всё, что приложение захочет использовать как (изменяемые во время выполнения) дополнительные таблицы.

Я нахожу очень впечатляющим, что динамическое связывание SQLite практически совместимо с динамическим связыванием ELF. Могу представить, что при хорошей реализации это могло бы заменить большинство случаев использования AppImages на гораздо более эффективный формат, как предлагает автор.

Как насчёт опции сжатия содержимого секций внутри blob-объектов SQLite, поскольку автор упомянул, что нельзя напрямую mmap'ить текстовые страницы и всё равно приходится копировать?

Есть два расширения, которые, как я думал, сделали бы SQLite-исполняемый файл по-настоящему уникальным.

Во-первых, расширение для связывания, которое позволило бы более напрямую вносить исправления в функции и хуки, чтобы обеспечить очень мощную систему плагинов. Представьте, что плагин SQLite определяет хук BEFORE/AFTER/REPLACE для какого-то символа, который хост-SQLite определяет как расширяемый.

Во-вторых, повторное связывание во время выполнения. Это потребовало бы cooperation разработчика приложения, потому что это нельзя сделать откуда угодно, но представьте, что вы меняете зависимость или загружаете плагин во время выполнения через редактирование базы данных, и интерпретатор просто отображает это по требованию/автоматически в фоновом режиме. Теперь в следующий раз, когда ваш веб-сервер вызовет accept(), он вызовет новую версию обрабатывающей функции.

> Сам формат невероятно лаконичен, создан для мира, где дисковое пространство и пропускная способность сети были на экстремальном уровне дефицита. Изменять формат сложно, часто приходится обнулять секции и добавлять новые, так как он так плотно упакован. Также нет самоописывающейся схемы. ELF — это очень общий формат, который поддерживает секции данных, которые по соглашению интерпретируются определённым образом, но формат этого не обеспечивает.

Похоже, это отличный вариант использования:

1. ELF-файл в SELF-файл

2. изменить SELF-файл

3. SELF-файл в ELF-файл

Ситуация с копируемой и отображаемой памятью — единственный недостаток в этом эксперименте. В остальном унификация форматов файлов была бы большим шагом вперёд. Формат исполняемых файлов PE/COFF, используемый Windows (и некоторыми старыми Unix-системами), также является реляционной базой данных. То же самое относится и к формату .NET-сборок — это тоже реляционная база данных. Колесо изобретают снова и снова.

Я могу согласиться, что объектный файл можно рассматривать как реляционную базу данных. Но почему SQLite? Почему бы не использовать механизм SQL-запросов к объектному файлу через абстракцию виртуальных таблиц? Я не вижу, как большинство функций SQLite, за исключением подмножества механизма запросов, можно было бы перенести.

Если автор хочет обосновать включение метаданных схемы в объектный файл, опять же, почему SQLite? Мне это сильно напоминает человека, который пытается найти применение своему любимому молотку (очень полезному молотку, надо сказать), а не серьёзное исследование того, как мог бы выглядеть новый, улучшенный формат объектных файлов.

(И это совершенно нормально)

Я думаю, это не заходит достаточно далеко! Сделайте само хранилище приложения тем же файлом. Так что это живое приложение, и файл постоянно обновляется в зависимости от того, как вы его используете. Скопируйте его — и вы носите свои данные с собой.

Пойдём глубже. Это веб-серверное приложение + серверный код + код приложения + база данных, так что pocketbase++ где это также цель развёртывания.

Затем объедините это с системой APE, и один и тот же файл загружается и сохраняет данные на каждой платформе. зловещий смех

Очень крутой хак! Снимаю шляпу перед автором.