Why should the parent OS offer any service that is not critical to its role as 'parent'? As you point out, anything that kills the parent will affect the children. I would think that would mean that the parent should have as little code as possible. What beyond a kernel, file system, network drivers and hardware drivers should be in the parent OS?
Would it not make sense to have a GUI-less, browser-less, clipply-less DirectX-less operating system for this role? In other words, shouldn't the parent OS have hundreds of thousands of lines of source code, not tens of millions?
Patching the parent OS is going to be a high stress activity. We have just gone through a patch of a database server running SQL Server. This resulted in a series of errors the next day. Since must of the patches were for 'non essential' code in GUIs, etc., wouldn't it be better to have esential services running on the leanest OS possible for the task?
Today, this is only possible on *nix computer. Why cannot Microsoft offer a modern, GUI-less server platform? Give us secure web access to set configurations from a seperate GUI - even if that GUI is running as a child on that very server.
[Updated 5/25/2006] While David Berlind is tearing up the blogsphere, the new kid on the block (that would be me) is just soaking it all in at the Gartner Symposium. I stopped by a Microsoft where Microsoft was telling the audience about some of the product road maps for some of their new Virtualization and management products which were Linux friendly and compatible. One of the Virtualization topics that came up was Microsoft’s new Windows Hypervisor technology for Windows Longhorn Server due out later next year. The Microsoft speaker mentioned that there were Parent and Child operating systems running on top of the Windows Hypervisor which is leveraging Intel and AMD virtualization technology. At the end of the presentation, I asked if Child operating systems had a dependency on the Parent operating systems such that they would die if the Parent OS was shut down. The answer was that if the Parent operating system died, a new Parent OS would be elected and all the Child OSes would continue to run. [Note that this information from the Microsoft speaker at Gartner was wrong. A failure in the Parent OS would in fact kill all Child OSes. This is exactly how all the other virtualization solutions behave. I got this cleared up with Microsoft at WinHEC 2006] Unfortunately I didn’t get a chance to ask how big the Windows Hypervisor is, but I can get that information some other time.
The next event I attended was an IT management conference given by Managing VP Richard D. Buchanan. With my perspective of IT coming from the frontlines as an IT architect and engineer, the style and language of executive management is still a bit alien to me even though I reported directly to a CIO for 4 years. Even so, I listened with an open mind and tried to absorb as much as I can. The theme of the presentation was IT leadership coming from a business-first perspective. Buchanan recommended that people with deep technical knowledge who may have little interest in general management issues be kept from CIO type positions but should play a key role in technical issues.
The last presentation I attended was for Open Source in the Enterprise given by Gartner Research VP Mark Driver. Driver covered a lot of the legal issues with Open Source covered and one of the key issues that came up was Software indemnification or the lack thereof as a major stumbling block for Open Source acceptance in the Enterprise. Driver’s advice was that companies should carefully weigh the risks Intellectual Property issues with Open Source on a case by case basis. One of the more interesting slides shown was Gartner’s maturity ranking of various Open Source projects. SugarCRM for example was ranked very low on the maturity scale while things like Linux and FreeBSD were ranked extremely high. Nessus and Snort were also ranked extremely high though the chart wasn’t updated enough to reflect the fact that Nessus had actually gone closed source last year. Nessus went to a closed source model because they were sick and tired of their competitors taking their software wholesale and packaging it as there own and competing directly with Nessus while no one was actually contributing any significant code to the project.
