Live data from Hacker News

Executable Is a SQLite Database

fzakaria.com

31–40 of 116 posts

Re: Executable Is a SQLite Database

#31
> 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 does not enforce it.

Sounds like a great use case for:

  1. ELF file to SELF file
  2. modify SELF file
  3. SELF file to ELF file

Re: Executable Is a SQLite Database

#33
> 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 structures were more like, each geometric sector of a hard drive is a record, and each head is a column. This was a straightforward translation of punch-card workflow onto a magnetic disk.

Re: Executable Is a SQLite Database

#35

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…

sqlite is a great replacement for fopen - although the C interface is much more verbose.

Re: Executable Is a SQLite Database

#36
post #8

Great read. I always find these turn a feature of a computer into a database an interesting read/idea. It certainly has upside, and downsides. For example having an entire filesystem as a sqlite database etc, or in this case an executable. It would be nice to have a structured way of talking to our utilities, rather than interpreting various commands as json through a few layers of tools to then get the output in a c…

Two tools come to mind that you might be interested in

- osquery: virtual table abstraction over proc fs. https://www.osquery.io/

- nushell: shell with structured I/O. https://www.nushell.sh/

Re: Executable Is a SQLite Database

#37

Yes ! This has been on the back of my mind for a while. And, as other commenters have noted, it would be great for the file to contain the (self-modifiable) Lisp image, a builtin virtual file system, and whatever the application want to use as (runtime modifiable) extra tables. I find SQLite dynamic linking being basically compatible with ELF dynamic linking to be very impressive, I can imagine that if well done, it…

You can do any of this in-memory wife ELF of course, it's just that nobody does and nobody's written the tools for it (the most obscure tool I know of is `ld -r`, which links two or more .o files and produces a new .o file instead of an executable)

Re: Executable Is a SQLite Database

#38
post #17
post #5

I appreciate the inventiveness of this idea. But I don’t find myself thinking I must have this.

Yeah... Original and clever, and a great read! But it seems mostly useful to the handful of people dealing with ELF internals, than to the vast majority of people executing ELF blissfully ignorant of its internals... Maybe if the latency and size trade-offs were the other way around it would be more appealing to the masses.

So a great hacker project.

Re: Executable Is a SQLite Database

#39

I don't think this goes far enough! Make the actually app store be the same file itself. so it's a living application and the file is constantly updated to how you use it. Copy it around, and you carry your data wiht you as well. Let's go deeper. it's a webserver app + the server code + application code + db, so pocketbase++ where it's also the deployment target. Then combine it with APE liek system, and the same fil…

The application writing its state to the executable is basically Smalltalk (or Lisp). It's an extremely powerful way of writing software, IMO.

Or Forth. But all of these are extreme spaghetti-bait too. Being able to see all the code that goes into an executable, and generate a clean one using only that code, is important for good development hygiene, which of course they didn't know yet in the 1970s. Imagine trying to use version control on a REPL - it doesn't work - you have to version control the commands that go into the REPL and running them on a fresh REPL every time.
Post reply on HN