Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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 file loads and stores things on every platform. evil laugh

    Very cool hacking! My hats off to the author.

    by unified101
  • > ELF MECHANISM: .strtab / .dynstr > The database primitive it reinvents: string interning

    > Surprisingly a lot more falls out as well: .dynstr is gone, because name is TEXT and SQLite already interns strings

    What's with this claim? SQLite does not intern strings, as far as I can find anywhere, and a quick test shows that duplicate strings are actually duplicated in a database file. You can intern strings in SQLite manually with an intern string table, but it doesn't happen automatically.

    by SmasherEpilepti
  • The copied vs. mapped memory situation is the only deal breaker in this experiment. Otherwise, file format unification would be a big step forward. The PE/COFF executable file format used by Windows (and some older Unix systems) is a relational database as well. The same goes to .NET assembly format - it's a relational database too. The wheel gets reinvented over and over again.
    by garganzol
  • 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 is trying to find uses for their favorite hammer (a very useful hammer I might say) rather than a serious exploration of what a new, improved object file format would look like.

    (And that’s totally ok)

    by catlifeonmars
  • > 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
    by djoldman
  • 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 cloud replace most uses of AppImages with a much more efficient format, like the author suggests.

    How about an option for compressing section contents within the SQLite blobs, since the author mentioned you can't mmap directly the text pages and have to copy anyway ?

    There are two extensions that I was thinking would make a SQLite executable truly unique.

    First, a linking extension that would allow patching in functions and hooks more directly to allow for a very powerful plug-in system. Imagine the plug-in SQLite defining a BEFORE/AFTER/REPLACE hook for some symbol the host SQLite defines as extensible.

    Second, re-linking at runtime. This would require application author cooperation because you won't be able to do that from anywhere, but imagine changing a dependency or loading a plugin at runtime through editing the db, and the interpreter just maps that on demand/automatically in the background, now next time your web server accept(), it calls the new version of the handling function.

    by XJ6w9dTdM
  • (author) I'm enjoying the comments. When I published a short-paper with this idea in academic circles, the feedback wasn't so kind
    by setheron
  • 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.

    by andai

Explore Birbla archives