Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Queryable Executables

fzakaria.com

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Queryable Executables

#21

Post by ebcode »

yjftsjthsd-h wrote: post #18
kleiba2 wrote: post #16

Earlier quoted context omitted.

What if I'm running multiple instances of the same binary?

Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.

SQLite doesn't have system-versioned / temporal tables, but a quick search turns up a fairly straightforward approach. Instead of overwriting existing rows, always write new rows with timestamps. https://www.ohnekontur.de/2024/02/19/unlocking-time-harnessi...

I'm thinking now of the hoops you have to jump through to edit a package.json file to update your dependencies, and thinking yeah, what if you could do: "UPDATE dependencies SET version='1.2' where name='madlib';"

Re: Queryable Executables

#23

Post by vincnetas »

jdub wrote: post #5

Instead of post-processing the binary to add the application (non-SELF) schema, you could run database migrations before servicing requests. Thus, every time you start the process, the app creates and/or upgrades its own schema. The SELF upgrade (heh, self upgrade) and rollback processes could benefit from some... fancier... footwork. Your example has a new binary copying old data into it, but then you have to move t…

"internet-facing service binary to be self-writable", yeah, this elevates sql injections to a whole new levels!!!

Re: Queryable Executables

#25

Post by QuantumNomad_ »

yjftsjthsd-h wrote: post #18
kleiba2 wrote: post #16

Earlier quoted context omitted.

What if I'm running multiple instances of the same binary?

Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.

> the question of how you reset to a known-working state if it mutates itself

I have this problem on my computers already, because configuration files and other program data is spewn across all kinds of directories and files all over the place.

The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that has been excreted by the software on my systems just so that I can keep the data that I actually want to keep.

Whereas to pick up all of my data that I do care about and copy only that and nothing extra to another place, is extremely time consuming to the point that it’s not realistically doable :(

Of course, cramming absolutely everything including user documents into the program won’t solve that either.

My ideal system would separate data that was written because of me (non-default config values, bookmarks, etc) from documents etc made by me, from garbage that the program wants to write that I absolutely do not care about and do not want to know about.

Re: Queryable Executables

#26

Post by dasyatidprime »

yjftsjthsd-h wrote: post #18
kleiba2 wrote: post #16

Earlier quoted context omitted.

What if I'm running multiple instances of the same binary?

Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.

A single SQLite ‘connection’ can be ATTACHed to multiple database files (which appear as separate prefixed schemata, but you can do things like joins across them) and it seems to work properly if some are read-only and some are not!

Re: Queryable Executables

#28

Post by yjftsjthsd-h »

QuantumNomad_ wrote: post #25
yjftsjthsd-h wrote: post #18

Earlier quoted context omitted.

Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.

> the question of how you reset to a known-working state if it mutates itself I have this problem on my computers already, because configuration files and other program data is spewn across all kinds of directories and files all over the place. The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that…

Look, I try to avoid bringing up nix in unrelated conversations. But.

> The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that has been excreted by the software on my systems just so that I can keep the data that I actually want to keep.

NixOS solves this.

> My ideal system would separate data that was written because of me (non-default config values, bookmarks, etc) from documents etc made by me, from garbage that the program wants to write that I absolutely do not care about and do not want to know about.

And NixOS with https://github.com/nix-community/impermanence does this, forcefully. Actually normal nix might solve it depending on how far you want to go.

Again, I wouldn't usually try to evangelize it, but you have described your ideal system, and it exists.

Re: Queryable Executables

#29

Post by hypendev »

rao-v wrote: post #13

This is deranged, and perilously close to dumb, which makes it one of the best things I’ve seen on hacker news this year. Absolutely wonderful stuff.

I'd say its perilously close to brilliant and dumb at the same time.

Re: Queryable Executables

#30

Post by asalahli »

kleiba2 wrote: post #16
yjftsjthsd-h wrote: post #8

> We can collapse not only a complete distribution but all the state for every application into a single file, alleviating the need for /var/ or /tmp/ or /home/ or any other filesystem. The program can store its own state in the same file it is running from, and it can do so transactionally. On the one hand: I don't think I want that. Including static content with the binary makes sense, certainly. However, storing w…

What if I'm running multiple instances of the same binary?

As another comment points out down in the thread, that's already a problem today with programs storing their config and data in a fixed location.

On the other hand, sqlite supports concurrency and ACID transactions, so it might actually be better at handling concurrent access to shared state

Post reply on HN