SELF: convierte tu ejecutable en una base de datos SQLite
Executable Is a SQLite Database
Farid Zakaria propone reemplazar ELF por SQLite como formato de ejecutables. Su prototipo, llamado SELF, permite que un binario sea una base de datos consultable: las secciones se convierten en tablas, los símbolos en filas y las herramientas como readelf o strip se reducen a simples consultas SQL. El artículo detalla cómo funciona, incluyendo el enlazado dinámico mediante consultas, y analiza el costo en tamaño y latencia, mostrando que el overhead se puede reducir a menos del 1%.
ELF es _ya_ una base de datos; solo que implementa muchos primitivos de bases de datos a mano, junto con una sorprendente cantidad de estructuras de datos para el rendimiento, como un filtro de bloom para la búsqueda de símbolos.
- andai
Todo este artículo es fantástico, pero ya al principio, lo de las tablas virtuales de SQLite me está volando la cabeza.
https://www.sqlite.org/vtablist.html
Puedes "montar" tu sistema de archivos (o cualquier otra cosa) como una base de datos SQL, ¿qué demonios? Eso es increíble.
Esto suena como que podría ser extremadamente útil.
- setheron
(autor) Me están gustando los comentarios.
Cuando publiqué un artículo corto con esta idea en círculos académicos, la retroalimentación no fue tan amable.
- inigyou
> Me di cuenta de algo que me molestaba. ELF ya es una base de datos.
Incluso aplicado de forma más amplia: toda base de datos ya es una base de datos (eso es lo que significa la palabra compuesta). Programas como sqlite y postgres solían llamarse con el término más preciso "Software de Gestión de Bases de Datos Relacionales" o "RDBMS" hasta que su uso se generalizó tanto que coloquialmente se les llamó bases de datos.
Las primeras estructuras de bases de datos eran más como que cada sector geométrico de un disco duro es un registro, y cada cabezal es una columna. Esto era una traducción directa del flujo de trabajo de tarjetas perforadas a un disco magnético.
- XJ6w9dTdM
¡Sí!
Esto ha estado en el fondo de mi mente por un tiempo. Y, como han señalado otros comentaristas, sería genial que el archivo contenga la imagen de Lisp (auto-modificable), un sistema de archivos virtual integrado, y lo que la aplicación quiera usar como tablas adicionales (modificables en tiempo de ejecución).
Encuentro muy impresionante que el enlace dinámico de SQLite sea básicamente compatible con el enlace dinámico de ELF, puedo imaginar que si se hace bien, podría reemplazar la mayoría de los usos de AppImages con un formato mucho más eficiente, como sugiere el autor.
¿Qué tal una opción para comprimir el contenido de las secciones dentro de los blobs de SQLite, ya que el autor mencionó que no se puede mapear directamente las páginas de texto y hay que copiarlas de todos modos?
Hay dos extensiones que estaba pensando que harían un ejecutable SQLite verdaderamente único.
Primero, una extensión de enlace que permita parchear funciones y hooks más directamente para permitir un sistema de plugins muy potente. Imagina que el plugin SQLite defina un hook BEFORE/AFTER/REPLACE para algún símbolo que el SQLite anfitrión defina como extensible.
Segundo, re-enlazar en tiempo de ejecución. Esto requeriría cooperación del autor de la aplicación porque no podrás hacerlo desde cualquier lugar, pero imagina cambiar una dependencia o cargar un plugin en tiempo de ejecución editando la base de datos, y el intérprete simplemente lo mapea bajo demanda/automáticamente en segundo plano, ahora la próxima vez que tu servidor web haga accept(), llamará a la nueva versión de la función de manejo.
- djoldman
> El formato en sí es increíblemente conciso, diseñado para un mundo donde el espacio en disco y el ancho de banda de red eran una prima extrema. Modificar el formato es difícil, a menudo tienes que poner a cero secciones y añadir nuevas ya que está empaquetado tan apretadamente. Tampoco hay un esquema autodescriptivo. ELF en sí es un formato muy genérico que soporta secciones de datos que por convención se interpretan de maneras específicas pero el formato no lo hace cumplir.
Suena como un gran caso de uso para:
1. Archivo ELF a archivo SELF
2. modificar archivo SELF
3. archivo SELF a archivo ELF
- garganzol
La situación de memoria copiada vs. mapeada es el único factor decisivo en este experimento. De lo contrario, la unificación del formato de archivo sería un gran paso adelante. El formato de archivo ejecutable PE/COFF utilizado por Windows (y algunos sistemas Unix más antiguos) también es una base de datos relacional. Lo mismo ocurre con el formato de ensamblado .NET: también es una base de datos relacional. La rueda se reinventa una y otra vez.
- catlifeonmars
Puedo aceptar que un archivo objeto puede verse como una base de datos relacional. ¿Por qué SQLite? ¿Por qué no un motor de consultas SQL sobre el archivo objeto usando una abstracción de tabla virtual? No veo cómo la mayoría de las características de SQLite, con la excepción de un subconjunto del motor de consultas, se traducirían.
Si el autor quiere hacer un caso para incluir metadatos de esquema en un archivo objeto, de nuevo, ¿por qué SQLite? Esto me parece mucho como alguien que está tratando de encontrar usos para su martillo favorito (un martillo muy útil, podría decir) en lugar de una exploración seria de cómo se vería un nuevo formato de archivo objeto mejorado.
(Y eso está totalmente bien)
- unified101
¡No creo que esto llegue lo suficientemente lejos! Haz que la tienda de aplicaciones real sea el mismo archivo. Así es una aplicación viva y el archivo se actualiza constantemente según cómo la uses. Cópialo y llevas tus datos contigo también.
Vamos más profundo. Es una aplicación de servidor web + el código del servidor + código de aplicación + base de datos, así que pocketbase++ donde también es el objetivo de despliegue.
Luego combínalo con un sistema tipo APE, y el mismo archivo carga y almacena cosas en cada plataforma. risa malvada
¡Hackeo muy genial! Me quito el sombrero ante el autor.