>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.

> 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 writable run-time data there feels messy; I prefer a read only binary which is handed a writable state directory (it is worth saying that I've spent a lot of time with nix and other immutable distros).

On the other hand: This is the coolest, most fun thing I've seen in a good while, and I absolutely want to see it taken 1000% further. Who cares about perfectly operationalized immutable deployments when the hacker spirit is in the air?

I'll bet you could use this to run with another thing APE does: fat binaries. If program text lives in a database, what's one more row? Just

  SELECT text FROM executable WHERE arch = $(uname -m)

Edit: actually on further consideration this feels perfect for smalltalk; you can put the VM and image in a single file

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.

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 the new binary to the deployed location. Which means an outage through stop service, data migration, replace file, start service.

What if the upgrade process was more like... write the new SELF data into the old binary, send SIGHUP, and then the service fork+execs itself, while doing haproxy-like zero downtime FD handover?

Replacing the SELF data in the existing file is safe right now, because you can't mmap segments into memory. But if you do end up figuring out some clever BLOB alignment mmap stuff, you could do the SELF upgrade like a data migration! INSERT segments/symbols, fork+exec, and the data migration cleans out the old code. :-D

Updating the SELF schema to allow multiple sets of segments and symbols would allow for this upgrade trick, but could do other fancy things... thin multi-arch binaries where only the code segments differ.

BLOB alignment should also mean more efficient static asset serving and a bunch of other niceties... definitely worthy of investigation.

However -- very strong however -- as fun as this is, I would never, ever, ever allow an internet-facing service binary to be self-writable. :-)

So like a Lisp, APL, or Smalltalk program image, but with SQL as the driving force.

Everything old is new again. And I don't mean it in a disparaging way. There's lots of "old" ideas that are simply great ideas that did not win on their own time but might come back with force in the future.

Where this approach might shine right now is .o/.obj files for assemblers/compilers/linkers. Instead of using COFF/ELF/whatever binary voodoo, a relational DB container makes most of the previously hard things trivial, including optional vendor extensions.

This would be a super pragmatic approach for a modern compiler suite. This is the brilliant part of the whole idea.

I build a SQLite clone in Rust with this analogy in mind, and unlike SQLite it support multiple writers by giving them separate segment in a file. Calles the programming "language" PySpell, it converts Python into AST then into RUST with a lot of cool features you can enable when the database and programming language is living in the same place.

http://github.com/punnerud/mpedb

Between this and actually portable executable I'm not convinced someone hasn't made a PNG thats a spreadsheet, or an audio file the somehow renders DOOM across the room. HN amazes me with the absolutely cursed ideas of implementing a minecraft in pure css (or showing whatever other nightmares one can do with CSS). It shows the most incredible creativity in what one can do with the freedom of arranging bits however one wants. I'm in love with all these cursed projects and hope they never stop.

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

> All state is updated in the same SQLite file as the program itself.

And now all SQL injection bugs are RCE!

It's a fun idea, though.

Neat stuff. I’m sold!

Could the webserver receive a code segment from the web and add it to itself (like a plugin upload)?

So the next logical step is to make the whole OS a self modifying queryable sqlite file :)

Fantastic ideas. The SQL Injection to ACE pipeline is incredible.

I wonder if the interpreter could create a mount namespace and mount virtual filesystems backed by the SQLite database itself, so you wouldn’t need source changes to self-contain (ha!) file accesses.

Is it just me or does this create a huge potential security vulnerability where it’s a lot easier to trick the application into mutating itself. There’s also the alternate problem where if the file is placed in a privileged location, you won’t be able to store any state. And the final problem that each user needs their own copy of the application if it’s a multi-user application.

The biggest concern for me would be the security angle - if there would be some way to seal the executable itself and descriptor tables so that an application can be guaranteed to never touch that and only ever modify the other “runtime” tables. Not doable with raw sqlite though since it has no kind of ACL mechanism, but would be a neat extension so that the interpreter handed the handle to the process directly with the privileged tables cordoned off from writing.

so the executable is now a database you can query with sql. next step is someone writing an ORM against a binary and i will simply retire.

https://archive.is/eMRTd

Somebody else mentioned OS/400, I’ll mention MUMPS and its “globals”… specifically ^rOBJ

Everything old is new again.

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

SQLite is >< close to becoming the lingua franca for all next-generation ideas

these are useful primitives for VM/Sandboxes

This for some reason reminds me of OS/400 libraries. Basically on AS/400 everything is an object, libraries are basically like DB tables but are first class OS objects (like files in unix). You might want to read up on it, they took the concept incredibly far and it’s of course still a part of i series to this day. You basically can use SQL right on the command line.

When I read program like this, I ask myself: Am I the only one that do not dream to make skynet?

extremely creative stuff!

interesting