To summarize the next many paragraphs in just one: A toaster operates for only a limited amount of time (‘3 minutes’), and therefore the efficiency of the code running it (if it’s digitally ran) is irrelevant to your life in the kitchen. So if a computer environment was only evoked for ‘3 minutes’ what does it matter if it leaks memory or bogs down over time, assuming that the reliable running time is greater than ‘3 minutes’.
This morning as I was waiting for my bagel to finish toasting, with the digital count-down clock displaying the amount of time left on the cycle I had an amazing idea. My stroke of brilliance was that the toaster probably ran some operating code to allow it to keep time, count time, and work the buttons, and when done, release the spring-loaded slot; then I wondered about how it only had to go for at most 3 minutes-and what implication that placed on the code.
Today my computer has been running for just shy of 48 hours without a flaw—and I’ve been able to keep it for almost 60 days without issue, of course I’m using a Mac (unix)-and even Windows with it’s relatively long uptime around two days before issues set in. That’s when I wondered about last Saturday’s FLOSS Weekly, #67, talking about Xen, the open-source, high-performance virtualization engine, which notably allows an online operating system to be transferred over a network in it’s current state to a different host without a pause in execution, essentially meaning (in theory) unlimited uptime (that stated without delving into RTOS arguments). That little toaster incident made me wonder about application virtualization.
It seems that cloud-computing is somewhat solving the issues of uptime and reliability on the desktop, however it lacks views describing local computer security, reliability, and performance. I think I just experienced the biggest paradigm shift in my life.
What if you’re computer were run in a fast, efficient RTOS which could run on bare hardware almost indefinitely (note that I’m not specifying x86-64, this may be the time we can use to jump from the old x86 architecture.) This RTOS will employ tight garbage collection routines, enforce strict resource allocation, and therefore build on what we as an industry have learned from Windows, Mac OS and *nix.
This basic (RT)OS would then run applications (written in a modern language like Obj-C, Smalltalk, or the bare ASM) in an isolated virtual machine which in theory could run any compatible guest operating system (Windows included), however more interestingly, what if, instead of running a full OS, it ran a bare API environment? (ie Win32 without the rest of the operating system, letting the host take care of file-system management, memory management, display and graphics management, and other system properties-not dedicated memory) In theory this would close with the closure of the isolated application, meaning that like my toaster, the efficiency of the application code is irrelevant to the uptime of the total system because it’s only run as long as it’s doing something (ie toasting).
To clarify, if this system were in the most ideal situation possible, I would have the web browser run as a native application on the RTOS, invoking virtual instances of a low-resource web-basic program space that would contain the web rendering of each of the tabs—and because of the absent need for security, the rendering engine can be (in a similar fashion to Google Chrome) a compiler and execute JavaScript as well as (not in Chrome) Flash, Java, and more in ASM for the most possible performance. Imagine a web browser that was just-like-new all the time, never pausing because of a memory leaf (*cough cough* Firefox), a non-responsive script, or an overload (again, Firefox).
The problem which has come to me in writing this would be the old Bill Gates ideal (from the late 70’s or 80’s) that the amount of abstraction in application code won’t matter in time, because when he had said this, computers were running at about 4 MHz, and his idea was to write bulkier code which is easier to write, get applications, then wait for processors to get fast enough that it won’t matter how inefficient the code is.
Now, as computers are fast enough that we don’t see a significant difference between a native ASM app, a VB app, or a Java app, we’re facing the issues of the poor memory management and therefore runtime (with the latter two environments mentioned). However the issues of the ’80’s are coming all back to us with Net-books/tops (running on ARM or Atom). Netbooks are amazing, but the lesser realized dream is that of the nettops; that in principal (excuse the environmental impact of this statement) you could have a computer always-on, running a browser, office, some media, and messaging. But the issue is that running on low power, low cost processors we need something to increase reliability with some external drive, it’s clear that developers won’t change old habits or environments. Not saying my theory is perfect, or of equal caliber to that of Bill Gate’s, but it certainly may be applied in years, until we have (yet) another problem.