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

31–40 of 83 posts

Re: Queryable Executables

#31

Post by ccapitalK »

rrgok wrote: post #27

i still don't understand what it does. Can someone ELI5? I've read both articles, still clueless.

I'll take a shot at this.

Native applications ship as executable files. These files are basically a combination of machine code instructions (the program logic to be run) + a bunch of extra data that needs to be loaded into memory for the program to run + metadata so the operating system knows how to combine it all.

The first article noted that the file format for this can be thought of as a very specialised, antiquated database format. The author then managed to convert some real applications of theirs into sqlite databases of the necessary program data, and then taught the operating system how to treat those sqlite databases as programs to run.

The second article builds on this, by creating a program shipped as an sqlite database, and then making that program read and write itself (through sqlite code) to store its application state. So instead of having a web server application that loads an sqlite db table, it is just a database file that the operating system can run as a native application, that also stores user data in itself.

Re: Queryable Executables

#32

Post by gf000 »

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…

While way too restrictive, I believe android actually has the correct idea here, having separate data folders per app. The problem is that you can't really touch this per app data folders - even backup is a special operation only doable by the OS (or you root the phone).

Spamming my home folder on the other hand is criminal..

Re: Queryable Executables

#33

Post by larodi »

>I’m amazed how much collapses into a single domain: SQL.

perhaps is more correct to say "all data, including code, is table-representable, even though being a graph" or "everything falls back to tables" or even "relational algebra is all u need", but I strongly disagree SQL being a domain on its all, and that it (all) collapses into such domain.

One can collapse segment tables likewise into DATALOG, which is also a PROLOG-derivate. So then the thing demonstrated here is - "all collapses into grammars perhaps". which is not new, but there are plenty of engineering details, and whatnots to consider, to make such model viable for large-scale deployment. And trouble is it is not so easy to infer stuff about grammars before you expound/infer on them.

don't get me wrong - I love SQL, and respect SQLite and DuckDB for what they are. what we see here is one very curious approach and great demonstration.

Re: Queryable Executables

#34

Post by thesz »

Reminds me of starkit[2]/tclkit[3]. Directly queryable [4], but these programs were ZIP files with ZIP file VFS, they contain shared libraries and so on. One would add most, if not all, functionality from article into starkit-based application.

  [1] https://en.wikipedia.org/wiki/Metakit - base tech
  [2] https://wiki.tcl-lang.org/page/Starkit
  [3] https://wiki.tcl-lang.org/page/Tclkit
  [4] https://wiki.tcl-lang.org/page/Starkit+Meet+Zip

Re: Queryable Executables

#36

Post by thesz »

larodi wrote: post #33

>I’m amazed how much collapses into a single domain: SQL. perhaps is more correct to say "all data, including code, is table-representable, even though being a graph" or "everything falls back to tables" or even "relational algebra is all u need", but I strongly disagree SQL being a domain on its all, and that it (all) collapses into such domain. One can collapse segment tables likewise into DATALOG, which is also a…

Something like that was very popular in early 2000 in Tcl community and used at what then considered "scale." I posted a comment here with links: https://news.ycombinator.com/item?id=49445681

Re: Queryable Executables

#40

Post by torginus »

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?

afaik Plan9 already solved this issue - you had 'layers' of filesystems, not unlike Docker images/OverlayFS, with each process getting its own view of the filesystem. The last layer was non-persistent scratch. Of course you'd still need to reconcile writes to things like config files, which would be used by multiple processes, but the general approach is sound imo.
Post reply on HN