Live data from Hacker News

Executable Is a SQLite Database

fzakaria.com

41–50 of 116 posts

Re: Executable Is a SQLite Database

#41
post #11

I wonder how flexible is the SQLite binary format to allow to design a tool that would take a SELF binary/db and rewrite it to make BLOB values more mmap-able (OS page aligned) in order to allow shortcuts in the self-exec loader.

You'd have to at least increase the page size to allow 4kB of consecutive data without interfering with the page header.

OR you restructure the code and data to work around the page headers.

Re: Executable Is a SQLite Database

#42
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…

We do have a single database, it's the filesystem. But quite importantly it's a very composable kind of database, because you can "section off" a part of the database, calling it a folder, and the folder looks like a whole filesystem of its own. Working in the folder is like working in a separate database that's visible from the outside but the outside isn't visible from the inside unless you deliberately choose to go out through the escape hatch. SQL isn't like that - it's a flat namespace and that is like the original filesystems that didn't have folders. Those were usable when a computer was only big enough to hold a few activities at a time and when you had a stack of disks next to your computer, each with a different program's filesystem.

A flat namespace might actually work with an app-based OS model (like on android) where everything that happens is associated with an app ID and apps mostly can't talk to each other. But there's a reason nerds don't do nerd stuff on smartphones.

Re: Executable Is a SQLite Database

#44

Yeah, I have been amazed for an entire life how many tools the IT industry invented during last 50 years to just disguise a database. OK, in '70s, '80s or '90s when compute and storage resources were limited and every bit counted, specialized formats did make sense. But nowadays we'd save enormous efforts by just packaging stuff in SQLite databases. Microsoft's proprietary file formats (Office, Power BI etc.), OpenOf…

At first I thought it was still for a word document to be saved in SQL but then I thought about embedded images and it makes complete sense. Makes more sense for a Publisher/Impress app though as they have more self-contained objects. In Word/Writer the main text is one huge run of characters, how would you sqlize that effectively?

Re: Executable Is a SQLite Database

#45
post #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.

Oh do you mean as a way to store app state? Yeah 100%. It also helps that there are native reimplementations in many major languages, which means you don’t even need to link a libsqlite3 in contexts where it can sometimes be impractical to use the official C library (looking at you, CGO_ENABLED=0). And let’s not forget about sqlite3 running in wasm :)

Re: Executable Is a SQLite Database

#46

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…

I wrote a tool[0] for manipulating elf files to support inline assembly for a compiler that doesn’t support it (based on a similar python tool). That required knowing any of the ELF sections that were being changed and how those changes would impact other sections.

sqlite would have made this pretty trivial. Replace the .text fields of a few rows. Insert a few rows for symbols, update a few from the old object.

The best part - there’s tons of library support for sqlite. If it was a new object format, there would be no support and I’d just have to write different parsers and generators.

The schema might the the biggest issue for efficiency. As others have noted, ELF->SELF->ELF might be the best use case for compatibility. That said, a big part of [0] was performance, and I don’t know how sqlite would have done compared to my naive elf parsing and manipulation.

0 - https://github.com/ttkb-oss/metrowrap

Re: Executable Is a SQLite Database

#47
post #32

This whole article is fantastic, but already at the start, the SQLite virtual tables thing is blowing my mind. https://www.sqlite.org/vtablist.html You can "mount" your filesystem (or anything else) as a SQL database, wtf. That's amazing. This sounds like it could be extremely useful.

Check this out: https://github.com/osquery/osquery

Re: Executable Is a SQLite Database

#48

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…

Doesn't redbean do this in a more portable way (not ELF dependent)?

Re: Executable Is a SQLite Database

#50

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…

I wrote a tool[0] for manipulating elf files to support inline assembly for a compiler that doesn’t support it (based on a similar python tool). That required knowing any of the ELF sections that were being changed and how those changes would impact other sections. sqlite would have made this pretty trivial. Replace the .text fields of a few rows. Insert a few rows for symbols, update a few from the old object. The b…

> I wrote a tool[0] for manipulating elf files to support inline assembly for a compiler that doesn’t support it (based on a similar python tool). That required knowing any of the ELF sections that were being changed and how those changes would impact other sections.

Would this normally be something the compiler would handle, or would it be the linker? I guess I’m curious how this would impact any optimizations the compiler implements.

Also I’m guessing for your use case (elf edits) you would be looking at both SELECT and INSERT type operations?

Post reply on HN