Let's talk about speed.
That's right, speed. Pure, unadulterated, adrenaline-pumping, speed. Not the kind you get from fast cars, fighter jets, or drug dealers. The kind that comes out of your computer.

See, speed boils down to about one thing: perception. And these days, I'm not perceiveing a lot of speed out of my computers. There's a reason for this, or rather, many reasons. Quite a number of those reasons have names that end in .dll.

What causes my computer to take minutes to go from zero to usable? Why does it take minutes to start or stop a web browser, or open a word processing document? The answer is that I don't care. I just want it to stop. Of course, an engineer needs to understand these issues, and then he or she needs to fix the problems. With gigahertz and gigabytes, there's no justifying all the time lost to slow software. Indeed, one of the big selling points for Macintosh computers is that they go from zero to usable in about a fourth of the time it takes a standard PC.

Responsiveness in a computer may be compared to handling in a car. If your car doesn't change directions the instant you turn the steering wheel, you'll probably die in an accident. Your typical home computer might not be subject to quite the same constraint, but people expect to see a snappy response to a typical problem. I wanted to open a text file for reading and editing. My graphical shell knows to open gedit for this task. The process took an unbearable 35 seconds. WHAT THE CUSS-WORD?! Why does it have to take so long?

The real answer is that it doesn't have to take so long. The software of a bygone age would have been on-screen and usable within the all-important tenth-of-a-second threshold of delay perception. But we're not in a bygone age. I really have no idea how many libraries you have to load just to get gedit on the screen. In any case, it's probably embarassing. Most of what gedit needs is going to be shared with every other gnome application on the same computer, and it's a pretty good bet that I'll load some gnome applications from time to time. However, under the current regime, the machine to load and link a ****-ton of libraries for the simplest program, every time that program starts. And if it's any recent time since boot, then most of those libraries are still on disk instead of cache. Oh, and by the way, this whole 'position-independent code' thing can go kiss my talented anatomy. The ELF linker has to alter the contents of the memory image of a library to link it to whatever else is already in a given process, which means that every page of a library image gets copied and you don't get any of the benefits of shared code images, which means that the first thing you do when you start a program is to make a spare copy of all the code into fresh new ram, which overpopulates your ram, which means you wind up paging things out even with large amounts of ram, which ultimately ends up costing time in a major way, which is the big no-no.

Is there even the slightest bit of anger showing through? I thought so.

Some people have attacked this problem in a few ways. They've worked to improve the algorithms used by the linker (which, in the past, have been n^2 at best) and they've worked to minimize the time spent linking by doing some of it in advance on disk.

There has to be a better way.

Now, assuming you've read this far, which is a big assumption, I'm going to explain one possible better way.

Imagine, for a moment, that there were a trusted agent that could provide a read-only ram image with most of the big important libraries in direct-linked form. A client "linker" could get most of its work done simply by mapping that image into a well-known location within its own address space. Having done so, it need only snap the pointers embedded in the main application, rather than all the layers of dynamic-link libraries that it may depend on.

Now, suppose that the trusted agent could also tell, in advance, exactly which pointers to snap, and where, upon the invokation of a given (known) binary. This would eliminate all the time spent looking up symbols in the various linkage tables normally found in libraries.

Suddenly, you'd be able to load very dependent programs in a very small amount of time and memory. Things would feel snappy again.

So, there's an engineering problem to solve: How do you make the trusted agent? How do you update or add libraries? How do you tell the agent which binaries to know about? How do you keep it from getting confused about different versions of files?

One thing is clear: Boot times would be reduced dramatically if this "trusted agent" came up first of all, and if it had a fast way to recover previously learned linkages.

I claim that this idea isn't too far distant from a sort of servlet environment for ordinary user-mode programs. If we put this idea through the right psychoactive substances, we might end up with the conclusion that large shared libraries could be implemented as forking servers, and all would be well with the world. This would strongly resemble a microkernel approach to system design, and it would resemble a capabilities system if connections to one server were generally granted by passing file descriptors from another.

Now, how many mythical man-months of effort would it be to create the trusted server? To coax GCC to produce binaries in its format? To rebuild significant portions of a running Linux desktop system using the new binary format?

Can it be done? Yes, absolutely. Will it be easy? Not for me. Not now. Not with my present background. However, I can imagine learning all about loading programs and kicking them off and interprocess communications and shared memory and memory-mapped files and on and on and eventually constructing a system that worked according to the principles described above.

Actually, it doesn't quite have to be that hard. I could just shut up and go home. After all, I'll personally probably save time by just relaxing. But many hands might make this light work, if they're all suitably educated hands.

Anyhow, I have to get back to having a good time blasting pixels out of the virtual sky.