|So I got saw this in the CP Daily Insider today:
One of the most innovative features coming in Windows "Longhorn" Server isn't really a feature as much as a whole new version of Windows. It's called Server Core, and it will only take one-sixth of the disk space of a normal Longhorn installation. It's not expected to need anywhere near as many patches and hotfixes as Windows 2000. It's a version of Windows that does not, in fact, use windows. It's breaking Microsoft's long-standing reliance on graphical interfaces and shaking things up in several of Microsoft's product groups.
Awesome so far. A dream come true for people like me.
Server Core can only act as a file server, domain controller, DNS server or DHCP server.
Cool, file server. Wait. "File server"? Not "Web server"? And then the truth hits hard:
<big>There's also no Microsoft .NET Framework.</big>
No .NET! Can you believe it?! They couldn't make a Web server for Server Core because they couldn't get ASP.NET working! So they had to settle with a (pfft) "file server". And why? Well, here:
This means you can't run any managed code on Server Core. Mason says his development team wants to add the .NET Framework to Server Core, but they first need the Framework team to modularize the code so they can add just the essentials.
.NET 1.1 and 2.0 are modular and very portable for the most part -- .NET 1.1 and 2.0 work on the PocketPC/Smartphone (Compact Framework), Xbox 360 (XNA), and of course, Win32. Heck, .NET 1.1 even compiles and works on FreeBSD and OS X.
Not so anymore: remember, Server Core is Longhorn after all. But they couldn't possibly put .NET 3.0 on it. And so, Server Core's .NET implementation would be damned to either .NET 2.0 or to skip to 3.5 despite the lack of 3.0. Now what: a big huge mess. Customers have .NET 3.5 installed, but their .NET 3.5 programs won't run because they used an itty bitty class that came with .NET 3.0.
This is the exact worst case scenario that I was yelling about in the petition:
2. “Bootstraps” – .NET 3.0 does not have a “bootstrap”. It offers libraries that provide functionality as needed (just as it’s always been for .NET applications), but the “bootstrap” is in fact the .NET 2.0 CLR; “.NET 3.0 applications” merely make use of its libraries. Not only is this misleading, <big>it impairs the modular paradigm of the .NET Framework</big>. In terms of “kernels” and “bootstraps” as in the Channel9 video, the microkernel structure of the .NET Framework has been traded for a monolithic kernel.
5. Non-Win32 (Microsoft and non-Microsoft) implementations – Other implementations of the .NET Framework, such as the Compact Framework, SPOT OS, Singularity and Mono will suffer from naming confusions. The CLR team took very, very careful steps to make sure the .NET Framework works on other platforms as well. Mangling the .NET framework with Win32 specific API breaks that, <big>isolating the entire framework to Windows</big>.
Most of the other teams are a lot more careful: the BCL and CLR are carefully designed to work on other platforms with minimal modification (take a look at System.IO -- it works seamlessly on Unix). The C# team made painstaking efforts to standardize the language and submit it to ECMA and later ISO. They even put everything Windows specific (except System.Windows.Forms) in its own namespace called Microsoft.Win32. All that has gone to waste.
I mean, I'm sure that's not the only modularity issue. I imagine there's some problems with the installers and the complicated way they use MSI scripts to register assemblies in the GAC and such.
But in either case, these such problems point to a single culprit: the .NET Framework management team. This seems to be the team that makes all of the decisions on what goes in and doesn't go in the framework. Jason Zander alone, as he says in his video, is the "approver[^]" of all breaking (or what he likes to call "red bit") changes to the framework, including the one to accept Marketing's idea for the horrible misnomer. The same team also seems to be the one in charge of determining the installation and distribution process.
It looks to me as if there's a fundamental flaw in the decision making within this team.
The concern on the part of the Server Core team was obviously that they could probably do ASPX 2.0, but ASPX 3.5 (or whatever the hell they're going to call it) would be way too risky as a lot of it may rely on .NET 3.0. Therefore, any up-to-date version of the .NET Framework is too risky to support on a server OS due to its lack of modularity and consequent potential for breakage.
Well, you could say, we can still have a Web server on Server Core. Apache works with the Unix Subsystem (formerly known as Services for Unix -- now that's a nice name change eh?), and the Unix Subsystem works on Server Core. But oh man, the irony!
I hate saying this. I really do. I hate being an a***hole. But you can tell from how passionate I've been about this whole thing that this is an exceptional case, so I will say it.
Microsoft, we told you so.