4 ms·
Somehow my first thought from the title was using sqlite as a format for applications. So like a replacement for ELF. I think this idea is both fascinating and
by askl 11mo ago
Somehow my first thought from the title was using sqlite as a format for applications. So like a replacement for ELF. I think this idea is both fascinating and horrifying.
- trws 11mo agoI worked @fzakaria on developing that idea. It actually worked surprisingly well. The benefits are mostly in the ability to analyze the binary afterward though rather than any measurable benefit in load time or anything like that though. I don’t have the repo for the musl-based loader handy, but here’s the one for the virtual table plugin for SQLite to read from raw ELF files: https://github.com/fzakaria/sqlelf https://github.com/fzakaria/sqlelf
- deleted 11mo ago[deleted]
- gjvc 11mo agowonder if this would make hot-swap functions easier, if every function had its own section and every section was in the db
- kstrauser 11mo agoI think we could call it Library Internal Sequel Procedures.
- giancarlostoro 11mo agoForget elf, imagine having a SQLite file that stores elf, exe and DMG binaries. I would not mind working on something like this.
- actionfromafar 11mo agoNot that at all, but interesting in its own right - https://pypi.org/project/sqlelf/ https://pypi.org/project/sqlelf/ explore ELF via SQL.
- giancarlostoro 11mo agoYeah I'm thinking of like "appimage" but you can use it to run on any platform.
- yread 11mo agoOr a replacement for Access
- actionfromafar 11mo agohttps://docs.devart.com/odbc/sqlite/access.htm https://docs.devart.com/odbc/sqlite/access.htm https://github.com/sam-ludlow/access-linker https://github.com/sam-ludlow/access-linker
- yellowapple 10mo agoI've been pondering something similar as a modern approach to fat binaries, basically around a table like CREATE TABLE functions (name TEXT, arch TEXT, body BLOB); The advantage would be that binaries could be partially fattened, i.e. every function would have at least one implementation in some cross-platform bytecode (like WASM), and then some functions would get compiled to machine code as necessary, and then the really-performance-dependent functions would have extra rows for different combinations of CPU extensions or compiler optimization levels or whatever — and you could store all of these in the same executable instead of having a bunch of executables for each target. As a bonus, it'd be possible to embed functions' source code into the executable directly this way, whether for development purposes (kinda like how things are sometimes done in the old-school Smalltalk and Lisp worlds) or for debugging purposes (e.g. when printing stack traces).