In direct contrast to the title of this blog, I do assume that Microsoft Office applications are specifically designed to make my life miserable.
I assume this because:
a) I have several friends who actually work on MS Office. They have not yet shown a tendency to this kind of prank, but that only means they are devious.
b) The behaviour is just too bizare to be a bug.
Two days ago, Outlook decided that it should group my mailbox by flag status. I have been unable to change it's mind. Whenever I open any mailbox, it is sorted by flag. I click on the date column, and it sorts by date. Then the next time I navigate away from the folder and back to it, we're back to being grouped by flag. It's maddening!
Thursday, August 10, 2006
Tuesday, August 08, 2006
New twist on an old concept
This is a flash animation, but I wonder how long before this is actually done in hardware?
http://www.brl.ntt.co.jp/people/hara/fly.swf
http://www.brl.ntt.co.jp/people/hara/fly.swf
Saturday, August 05, 2006
New Blog
Not that this blog is really interesting or valuable to society, but I've created a new one, which is even less interesting and less valuable. http://wadefit.blogspot.com
Are VMs the new OSs?
A brief history of programmable electronic computers:
1) Back in the early history, the application software ran directly "on the hardware". Every program needed to know how to access hardware devices, etc. Writing a program was a lot of work, because you need to code everything!
2) Then came the invention of reusable code. First the static library and then the dynamic library allowed a program to re-use the common boilerplate code, particularly the code needed to access hardware and the like.
3) Then came the OS. The OS served 2 purposes: it provided a standardized, high-level access to hardware (like a library does), and it allowed multiple programs to share the hardware without conflicting with each other.
4) Then came the REALLY BIG OS. After the original operating systems that were really about just providing fair access to hardware, some companies started putting more and more functionality in the OS. Around the same time as the REALLY BIG OS, the idea of dynamically linked libraries (which started in step 2) become really popular. Any given application depends on a very large number of dynamic libraries, some of which are part of the OS, and some of which aren't. Not that the distinction really matters.
5) Then came OS patches. As the OS gets more and more complex, the number of places where an OS can go wrong inreases. So there are more bugs, and more patches. Along with OS patches, there are other dynamic library patches, since those are also complex and therefore prone to bugs.
This is the state commonly known as "DLL Hell", and quite frankly, we're still there. To elaborate a bit more on DLL Hell, in theory, all patches are perfectly backwards compatable, so that if your computer has the absolutely latest version of all components, everything will be peaches and cream. In reality, patches frequently introduce new bugs, and a given software application depends on a specific version of the OS and DLLs. Older version won't work, and neither will newer versions.
Of course, this leads to a new problem: what if you are running two different apps on a computer, but those two apps require a different version (patch level) of the OS. You're stuck. If you set up the patches for one, the other won't work. If you set up for the otherer, the first won't work. This, in a nutshell, is DLL hell.
The fix to this problem is an interesting step backwards. Many IT companies are dedicating hardware to a single application. Instead of having a single "big iron" mainframe doing everything, they have a fleet of smaller computers, and each computer is configured for a single app. This is how IT managers get out of DLL Hell.
But that's expensive. So to reduce the cost, the IT departments are starting to cut down on the number of computers they are using, and simulating the many computers with virtual machines (such as VMWare, MS Virtual Server, Xen or the like). They have one big computer running a VM monitor which simulates several standardized machines, and shares the resources between those machines.
Sound familier? It is. The "new" vm monitors are effectively old-school operating systems, which only standardize the hardware and fairly divide hardware resources between the apps.
So now we have this:
1) At the bottom, the real hardware.
2) Running on the real hardware, the "host OS".
3) Running on the host OS, the VM monitor, which creates several virtual machines.
4) Running in one of the virtual machines, the "guest OS".
5) Running in the guest OS, the single application.
This way, each guest OS can be patched and configured to the level required by the single application that runs on it. the "host OS" can be patched and configured to what is required by the VM Monitor. And in the end, we're back to having several applications running on one chunk of real hardware. But at a significant performance cost, as everything now goes through 5 levels.
I think there are some good lessons learned here. I think the lessons are:
1) DLLs cause more problems than they solve.
2) The OS should be minimal and simple.
What should be in the future?
I think where we should go from here is to modify the vm monitor so that it runs directly on the hardware, making the host OS unnecessary. VMWare, Inc. has already done this, Microsoft will never do this (that would be admitting Windows wasn't needed), and Xen might do that some day. The next step is to lose the DLLs and go back to statically linked libraries, with no OS. The functionality of the OS can be pulled directly into the application via code libraries, so that the application can and should run directly on the virtual machine. Since it's going to be the only thing running in that VM image, there's no point in having an OS to share resources.
What will be in the future?
Basically, I expect we'll continue to live with the 5 layers, even though two of them serve no purpose any more, because hardware is getting cheaper all the time, and it's easier to leave it alone than to make big changes.
But I do predict that software companies will start selling their software as pre-configured VM images, rather than as applications. They will need to work through some licensing issues, but the amount this will simplify support will make it worthwhile.
1) Back in the early history, the application software ran directly "on the hardware". Every program needed to know how to access hardware devices, etc. Writing a program was a lot of work, because you need to code everything!
2) Then came the invention of reusable code. First the static library and then the dynamic library allowed a program to re-use the common boilerplate code, particularly the code needed to access hardware and the like.
3) Then came the OS. The OS served 2 purposes: it provided a standardized, high-level access to hardware (like a library does), and it allowed multiple programs to share the hardware without conflicting with each other.
4) Then came the REALLY BIG OS. After the original operating systems that were really about just providing fair access to hardware, some companies started putting more and more functionality in the OS. Around the same time as the REALLY BIG OS, the idea of dynamically linked libraries (which started in step 2) become really popular. Any given application depends on a very large number of dynamic libraries, some of which are part of the OS, and some of which aren't. Not that the distinction really matters.
5) Then came OS patches. As the OS gets more and more complex, the number of places where an OS can go wrong inreases. So there are more bugs, and more patches. Along with OS patches, there are other dynamic library patches, since those are also complex and therefore prone to bugs.
This is the state commonly known as "DLL Hell", and quite frankly, we're still there. To elaborate a bit more on DLL Hell, in theory, all patches are perfectly backwards compatable, so that if your computer has the absolutely latest version of all components, everything will be peaches and cream. In reality, patches frequently introduce new bugs, and a given software application depends on a specific version of the OS and DLLs. Older version won't work, and neither will newer versions.
Of course, this leads to a new problem: what if you are running two different apps on a computer, but those two apps require a different version (patch level) of the OS. You're stuck. If you set up the patches for one, the other won't work. If you set up for the otherer, the first won't work. This, in a nutshell, is DLL hell.
The fix to this problem is an interesting step backwards. Many IT companies are dedicating hardware to a single application. Instead of having a single "big iron" mainframe doing everything, they have a fleet of smaller computers, and each computer is configured for a single app. This is how IT managers get out of DLL Hell.
But that's expensive. So to reduce the cost, the IT departments are starting to cut down on the number of computers they are using, and simulating the many computers with virtual machines (such as VMWare, MS Virtual Server, Xen or the like). They have one big computer running a VM monitor which simulates several standardized machines, and shares the resources between those machines.
Sound familier? It is. The "new" vm monitors are effectively old-school operating systems, which only standardize the hardware and fairly divide hardware resources between the apps.
So now we have this:
1) At the bottom, the real hardware.
2) Running on the real hardware, the "host OS".
3) Running on the host OS, the VM monitor, which creates several virtual machines.
4) Running in one of the virtual machines, the "guest OS".
5) Running in the guest OS, the single application.
This way, each guest OS can be patched and configured to the level required by the single application that runs on it. the "host OS" can be patched and configured to what is required by the VM Monitor. And in the end, we're back to having several applications running on one chunk of real hardware. But at a significant performance cost, as everything now goes through 5 levels.
I think there are some good lessons learned here. I think the lessons are:
1) DLLs cause more problems than they solve.
2) The OS should be minimal and simple.
What should be in the future?
I think where we should go from here is to modify the vm monitor so that it runs directly on the hardware, making the host OS unnecessary. VMWare, Inc. has already done this, Microsoft will never do this (that would be admitting Windows wasn't needed), and Xen might do that some day. The next step is to lose the DLLs and go back to statically linked libraries, with no OS. The functionality of the OS can be pulled directly into the application via code libraries, so that the application can and should run directly on the virtual machine. Since it's going to be the only thing running in that VM image, there's no point in having an OS to share resources.
What will be in the future?
Basically, I expect we'll continue to live with the 5 layers, even though two of them serve no purpose any more, because hardware is getting cheaper all the time, and it's easier to leave it alone than to make big changes.
But I do predict that software companies will start selling their software as pre-configured VM images, rather than as applications. They will need to work through some licensing issues, but the amount this will simplify support will make it worthwhile.
Subscribe to:
Comments (Atom)