zlacker

>>generi+(OP)
Here's a thought: just distribute source code. ABI issues should be mostly fixed. Most computers can compile source code fast enough for the user not to notice and cache the results so that it's never a problem again. If you want optimised code, you can do a source to source optimisation then zip and minify the file. You could compile such a library to approximately native speeds without much user-end lag using modern JIT methods, and maybe even run LTO in a background thread so that the exectuables outdo dynamically linked ones.

>>James_+dd
the first launch of firefox would take a few hours.

let alone the first boot of the linux kernel... :)

>>m463+ei
Just because you are used to slow compilers doesn't mean fast ones are impossible. As I said in the original post, code optimisation can be done before compilation on the developers machine, so all that need be done on the target is a simple debug build. An example is Jonathon Blow's JAI compiler which compiles around 250,000 lines of code per second. Even on very slow hardware this is reduced to perhaps 80,000LoC/s, two minutes for 10 million lines of code. Most users would be tolerant of an "install" box with a progress bar that takes at most two minutes for only the largest application on the computer. Or perhaps the browser people would opt not to distribute their software in this way. Advanced software may have advanced needs, beyond that of the average application. Most code is already written in Javascript these days, meaning it begins life being interpreted and is JIT compiled on the user's computer. Few seem to notice the compilation but many complain about the general sluggishness.

If you offered users a deal: spend 1 minute installing the software and it is snappy and responsive when you use it, I suspect all would accept.