91–100 of 116 posts
> The format itself is incredibly terse, designed for a world where disk space and network bandwidth was at an extreme premium. Modifying the format is hard, you often have to zero out sections and add new ones since it is packed so tightly. There is also no self-describing schema. ELF itself is a very generic format that supports sections of data that by convention are interpreted in specific ways but the format doe…
> I realized something that bugged me. ELF is already a database. Even more broadly applied: Every base of data is already a database (that's what the compound word means). Programs like sqlite and postgres used to be called by the more precise term "Relational Data Base Management Software" or "RDBMS" until their use became so widespread that they were colloquially called databases instead. The very first data base…
(author) I'm enjoying the comments. When I published a short-paper with this idea in academic circles, the feedback wasn't so kind
https://sqlite.org/draft/appfileformat.html
There is little reason that ELF needs to be so complex. My motivation was to bundle multiple wasm modules together along with data.
> The format itself is incredibly terse, designed for a world where disk space and network bandwidth was at an extreme premium. Modifying the format is hard, you often have to zero out sections and add new ones since it is packed so tightly. There is also no self-describing schema. ELF itself is a very generic format that supports sections of data that by convention are interpreted in specific ways but the format doe…
nightmare for anything that relies on checksum based security :D
Like, it's an ugly spec, but it's clear enough on ordering/layout that I think checksumming is probably tractable to get parity for.
A lot of kernel filesystem features should be inside a database as well.
Yes. In this interview Michael Stonebreaker, one of the original developers of PostgreSQL, discusses (among other topics) replacing the file system with a database : https://www.youtube.com/watch?v=YPObBOwIrHk
Earlier quoted context omitted.
This is one of those perennial ideas; let's get rid of hierarchical file systems and just keep all the files in a database. Speaking as a user who knows how to keep things organized, I like hierarchical file systems. Store the data in a database if you like, but don't break my metaphor.
I like a hierarchy, too. Presumably the underlying engine could be a database but it would at least appear to the user as a tree. But with the option to find files with SQL or a SQL-like language. I would love to be able to find files based on all kinds of metadata that was available for searching with the OS’s file system, and not using any special tools. I’m thinking things like EXIF data, audio file metadata, text…
SELECT * FROM files p LEFT JOIN files c ON p.id = c.parent_id LEFT JOIN files gc ON c.id = gc.parent_id LEFT JOIN files ggc ON gc.id = ggc.parent_id .... where p.id = 123
I can buy that an object file can be viewed as a relational db. Why SQLite though? Why not SQL query engine over the object file using a virtual table abstraction? I’m not seeing how most the SQLite features, with the exception of a subset of the query engine would translate over. If the author wants to make a case for including schema metadata in an object file, again why SQLite? This strikes me a lot as someone who…
(author) In the post I say I did write sqlelf which is just that, sqlite + virtual tables prior to this.
Earlier quoted context omitted.
For sure, the main advantage is that since the SQLite file format is easy to use compared to ELF, it's more likely that such experiments would be even tried at all. I got another one: bundling multiple (completely separate) executables with shared dependencies in the same SQLite, selected by argv[0] when called, like what busybox does
Also known as a directory.