Tu ejecutable es una base de datos SQLite: ahora también almacena su propio estado
Queryable Executables
El autor presenta SELF, un formato donde el programa es una base de datos SQLite. Con binfmt_misc, el kernel ejecuta el archivo como un script, y el programa puede abrirse a sí mismo como base de datos. La prueba de concepto self-httpd es un servidor web de un solo archivo que guarda sus rutas, visitas y contadores en la misma base de datos. Esto permite editar el sitio en caliente con transacciones ACID, migrar datos entre versiones con simples INSERT SELECT, y usar herramientas como FTS5 para búsqueda de texto completo. El autor compara su enfoque con redbean de Justine Tunney, destacando que SELF es un 'ejecutable realmente consultable'.
El programa es la base de datos, y la base de datos es el programa.
- larodi
>Me asombra cuánto colapsa en un solo dominio: SQL.
Quizás sea más correcto decir "todos los datos, incluido el código, son representables en tablas, aunque sean un grafo" o "todo se reduce a tablas" o incluso "el álgebra relacional es todo lo que necesitas", pero estoy firmemente en desacuerdo con que SQL sea un dominio en sí mismo, y que todo colapse en tal dominio.
Uno puede colapsar tablas de segmentos de manera similar en DATALOG, que también es un derivado de PROLOG. Así que lo que se demuestra aquí es que "todo colapsa quizás en gramáticas", lo cual no es nuevo, pero hay muchos detalles de ingeniería y demás a considerar para que tal modelo sea viable para despliegue a gran escala. Y el problema es que no es tan fácil inferir cosas sobre gramáticas antes de exponerlas/inferirlas.
No me malinterpretes: amo SQL, y respeto SQLite y DuckDB por lo que son. Lo que vemos aquí es un enfoque muy curioso y una gran demostración.
- yjftsjthsd-h
>Podemos colapsar no solo una distribución completa sino todo el estado de cada aplicación en un solo archivo, aliviando la necesidad de /var/ o /tmp/ o /home/ o cualquier otro sistema de archivos. El programa puede almacenar su propio estado en el mismo archivo desde el que se ejecuta, y puede hacerlo transaccionalmente.
Por un lado: no creo que quiera eso. Incluir contenido estático con el binario tiene sentido, ciertamente. Sin embargo, almacenar datos de escritura en tiempo de ejecución allí se siente desordenado; prefiero un binario de solo lectura al que se le entrega un directorio de estado escribible (vale la pena decir que he pasado mucho tiempo con nix y otras distros inmutables).
Por otro lado: Esto es lo más genial y divertido que he visto en mucho tiempo, y absolutamente quiero verlo llevado un 1000% más lejos. ¿A quién le importan los despliegues inmutables perfectamente operacionalizados cuando el espíritu hacker está en el aire?
Apuesto a que podrías usar esto para ejecutar con otra cosa que hace APE: binarios gordos. Si el texto del programa vive en una base de datos, ¿qué es una fila más? Solo
SELECT text FROM executable WHERE arch = $(uname -m)
y allá vamos:)
Editar: en realidad, tras reflexionar, esto se siente perfecto para Smalltalk; puedes poner la VM y la imagen en un solo archivo.
- rao-v
Esto es descabellado, y peligrosamente cerca de ser tonto, lo que lo convierte en una de las mejores cosas que he visto en Hacker News este año.
Absolutamente maravilloso.
- jdub
En lugar de post-procesar el binario para agregar el esquema de la aplicación (no SELF), podrías ejecutar migraciones de base de datos antes de atender solicitudes. Así, cada vez que inicias el proceso, la aplicación crea y/o actualiza su propio esquema.
El proceso de actualización SELF (je, auto-actualización) y de rollback podría beneficiarse de algún... movimiento... más elegante.
Tu ejemplo tiene un nuevo binario copiando datos antiguos, pero luego tienes que mover el nuevo binario a la ubicación de despliegue. Lo que significa una interrupción: detener servicio, migrar datos, reemplazar archivo, iniciar servicio.
¿Qué tal si el proceso de actualización fuera más como... escribir los nuevos datos SELF en el binario antiguo, enviar SIGHUP, y luego el servicio hace fork+exec de sí mismo, mientras hace una transferencia de FD sin tiempo de inactividad estilo haproxy?
Reemplazar los datos SELF en el archivo existente es seguro ahora mismo, porque no puedes mapear segmentos en memoria con mmap. Pero si terminas descubriendo algo ingenioso de alineación de BLOB con mmap, podrías hacer la actualización SELF como una migración de datos! INSERT segmentos/símbolos, fork+exec, y la migración de datos limpia el código antiguo. :-D
Actualizar el esquema SELF para permitir múltiples conjuntos de segmentos y símbolos permitiría este truco de actualización, pero podría hacer otras cosas elegantes... binarios multi-arquitectura delgados donde solo difieren los segmentos de código.
La alineación de BLOB también debería significar un servicio de activos estáticos más eficiente y un montón de otras ventajas... definitivamente digno de investigación.
Sin embargo -- muy fuerte sin embargo -- por divertido que sea, nunca, jamás, permitiría que un int [...]
- JaumeGreen
Así que es como una imagen de programa de Lisp, APL o Smalltalk, pero con SQL como fuerza impulsora.
Todo lo viejo es nuevo otra vez. Y no lo digo de manera despectiva. Hay muchas ideas "viejas" que son simplemente grandes ideas que no ganaron en su tiempo pero podrían volver con fuerza en el futuro.