Recently, several representatives from Windows IT Pro Magazine received a briefing about the Beta 1 version of Longhorn Server, the next member of the Windows Server family, currently due in the first quarter of 2007, or about six months after Windows Vista ships in late 2006.
To read all comments associated with this story, please click here.
Member since:2005-07-08
"I do like the notion that the installation is more modular along the W2k3 lines as opposed to the all eggs in one basket style of W2k server and the desktop OSes."
I agree that this modular (roles-based) design is a big deal. Sysadmins and CIOs alike will be pleased by this design. Finally there is a Windows that first boots a base install and then allows you to add individual packages (included with the OS). If they can sell premium addon "roles" for download, then that would be pretty sweet. From a high-level perspective, this indicates that the development of Longhorn Server has been a well-thought-out process.
"The idea of making the OS more secure during installation is something I never would have thought of but I'm impressed that they were aware of the need for it and addressed it with the Secure Install feature."
Not what you think. This has more to do with verifying the legitimacy of your install media than somehow protecting the security. This is anti-piracy technology cleverly spun by the MS/Thurrot alliance. Why would the installer need to open itself to the net? To do the infamous activation? To download patches? There isn't any local storage mounted, and there aren't any inbound services running, so the user's data security is not in jeopardy. This is for the Microsoft's financial security.
"The Secure Startup feature makes sense ; you want the security subsystem to be operating before network connections can be established. But since I don't have a TPM 1.2 chipset it'll have to wait until I get a machine equipped with one. It makes sense that you will want this to install any patches or service packs needed. I've sweated through installations that needed to go online for patching at sites where I didn't have local to service packs and patches."
Once again, I would be weary of any technology that requires hardware TPM. What would encompass this security subsystem? What services/daemons would you want to have started before bringing up your network interfaces? The firewall sits on the TCP/IP stack (and probably also on the boundary routers). Until your kernel is ready to pull data off the Rx queue (which is after around a million or more lines of initialization code), you are not susceptable to anything. Read your statement again and listen carefully for the gulping sound... that's you swallowing Kool-Aid:
"The Secure Startup feature makes sense ; you want the security subsystem to be operating before network connections can be established."
Ahh... I was feeling a little parched.
"XML based log files to enable management tools? This sounds like throwing technology at a communication issue,..."
There is no better problem to throw technology at then communication. Controlling the proletariat is number two on the survey.
"...but they may be taking advantage of the investment others have made in XML parsers."
Yes, and press releasing touting their romantic ties to open standards make them feel warm and fuzzy inside.
"It still sounds overly complicated but more interoperable than a binary-based API or something undocumented or both."
Which is exactly why freedesktop.org is pushing its own standard event and message passing bus called DBUS, who's only dependency is... XML. It also provides APIs for glib, qt, python, and .NET/mono (possibly more).
Member since:Thank you for your comments. I don't mind being the straight man when some "good humor" is being dispensed in response to what I say. (Mmmmmm, ice cream!)
I take it that the Vista/Longhorn server's XML based log file facilities won't interoperate with DBUS just like their "Open" XML won't interoperate with any standard XML parser. On the other hand it seems early on on the process and perhaps a third, fourth or further system will emerge that will become the new standard. I will go check out opendesktop.org and look into DBUS. It sounds interesting.
I haven't had much need to look at my log files so far, but it's an area that I am interested in. Especially if there is a front end to parse them and alert me to potential or actual issues.
Member since:
Member since:
Mr Thurrott writes in his article:
"Indeed, though one can make great arguments about the quality of Windows requiring such an overhaul, it's equally true that no other OS vendors have made the ongoing and never-ending security investments that Microsoft has."
This left handed compliment overlooks that no other "vendor" has had to make such an investment in their product as well as that many OSes, commercial or non-vended, avoid this sort of backporting of security by investing in the design of the OS before it is released.
I do like the notion that the installation is more modular along the W2k3 lines as opposed to the all eggs in one basket style of W2k server and the desktop OSes.
The idea of making the OS more secure during installation is something I never would have thought of but I'm impressed that they were aware of the need for it and addressed it with the Secure Install feature.
The Secure Startup feature makes sense ; you want the security subsystem to be operating before network connections can be established. But since I don't have a TPM 1.2 chipset it'll have to wait until I get a machine equipped with one. It makes sense that you will want this to install any patches or service packs needed. I've sweated through installations that needed to go online for patching at sites where I didn't have local to service packs and patches.
XML based log files to enable management tools? This sounds like throwing technology at a communication issue, but they may be taking advantage of the investment others have made in XML parsers. It still sounds overly complicated but more interoperable than a binary-based API or something undocumented or both.
If this has a side benefit of providing a better interface for system health and other information than SNMP then the overhead may be worth it. We'll see.