Hacker News Reader

Comment by regularfry | Hacker News Reader

Heh, this reminds me of a trick I was working on right about the ruby 1.8->1.9 transition: import the tree of .rb files (including gems) into a sqlite database, mess with the `require` mechanism to read from it instead of the actual filesystem, and make a static build of ruby with sqlite itself, the ruby code database packaged as a .text area, and any binary extensions all linked up into a single file. Ta-da, single file static ruby apps and trivial deployments: a truly useful thing back when Capistrano was the latest and greatest.

Unfortunately, 1.9 changed the ruby build system enough that I couldn't quite get it working, and I've not got round to looking at it since.

View on HN

For what it's worth, you can realize your dream in Tcl, since this has generally been possible (and utilized) for a long time !

Tcl supports the concept of "Virtual Filesystems" that an interpreter can "mount" wherever it chooses, and these can be backed by anything. So you can mount a zip file or an HTTP resource, or stack them and mount a zip file over a mounted HTTP resource, etc.

One of the virtual filesystems I've written is called "C-VFS" which takes files and converts them into object code in a shared object or archive (.a) and you can then link against 1 or more of those and mount them at runtime from the running process.

That is very neat! I always thought about expanding that idea to most programming languages. Most of the startup time is probably spend stating and reading files.

Just from a quick experiment

    time python -c ''; time python -S -c ''

    real	0m0.079s
    user	0m0.021s
    sys 	0m0.030s

    real	0m0.017s
    user	0m0.007s
    sys 	0m0.007s

From the manpage:

    -S     Disable the import of the module site and the site-dependent manipulations of sys.path that it entails.

I also considered doing the same thing for a linux distro. Just out of pure curiousity to what would happen to the boot up times. Wish I could have time to try it one day :(

What about going all the way and using an unikernel (or something approaching one)? Statically link suitable readonly data/code into a single global address space (to make use of optimizations possible by combining binaries, as apparent in e.g. busybox, and remove the overhead of code duplication and dynamic linking, if possible even skipping some overhead with syscalls, by allowing the compiler to reduce spilling registers to stack in an effort to prevent clobbering), and just make sensitive and modifiable data unavailable to or at least not writable by other/unprivileged processes.

This would probably require some modification to GCC or LLVM, if the latter even supports building a normal Linux.

Madness! Or actually really similar to an idea that Joe Armstrong presented in Strange Loop one time (just the idea no demo or anything)

https://www.youtube.com/watch?v=lKXe3HUG2l4

There exists an Erlang unikernel (of sorts): http://erlangonxen.org/

Well yeah, but that's like saying there exists hardware that eats java bytecode. Yes, it does, but it brings _large_ restrictions with it.

https://github.com/regularfry/carton is where I got to. Might give someone some ideas.

Reply on news.ycombinator.com