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.
A Look at Windows Server Longhorn Beta 1
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
but where’s the torrent?
-Chuckles
That was the PDC in September!
its great for gaming, but nothing more.
P.S. To disable 14 days activation just shut down the “Software Licensing Service”
here are some new nice gimmicks:
http://slicer.homeip.net/PICS/games_vista.png
here you can see why teh screensaver sucks on vista:
http://slicer.homeip.net/PICS/game_crashed_by_screensaver.png
Uh.. this article is about Windows Server Longhorn Beta1, not Vista. Try again troll.
after being drivin away from windows as a desktop os, and only ever seeing the windows 2000 version of their server Os. i just recently picked up windows 2003 server for a webserver im being forced to implement. while i cant say much about it as a server OS, with some tweeking it makes a right wonderfull desktop OS. if they keep all the bloat out of the new vista server versions i may hafta check them out. and im actually considering dual booting win 2k3 on my desktop too use as a gaming platform.
Windows Server 2003 has very poor driver support, so I suspect you’ll find it problematic to use as a desktop OS (this is the experience of a few people I know who have tried it).
ITS NOT OPEN SOURCE!!!!!!!!!BOOOOOOOOOOOO!!!!11
you forogt the ones.
XML based log files. Wow.
It seems to me that XML is probably, bar none, the dumbest format for log files. XML is great for certain types of data, but I don’t think log file data is one of them.
So what would be a better format? XML is a great choice for this as writing front end applications for parsing them will be a snap given the parsing infrastructure is already here.
“It seems to me that XML is probably, bar none, the dumbest format for log files. XML is great for certain types of data, but I don’t think log file data is one of them.”
Yeah, I’m going to go ahead and disagree with you there. It is the best possible choice? Maybe not. It largely depends on whether reading the raw log is important to you, or if you’re more concerned with having rich GUI tools and APIs for doing thins with the data.
If I were Microsoft, I would immediately choose this application as a perfect poster child for the effectiveness of the .NET framework. Make each “entry” a object implementing a LogEvent class, with loads of nice information on the event, where it came from, lists of subscribers, and other stuff. Then make nice GUI apps that and APIs that leverage this class. I guess they have a mighty aversion to their own framework, because this seems like a good place to use it.
But in any case, XML isn’t a bad option. There are tons of efficient XML code generators and parsers already written, it’s an “open standard,” and it allows for a good deal of richness. And if XML is without a doubt the worst format than this is better?:
Oct 6 15:55:17 disarray e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Oct 6 16:00:01 disarray cron[28633]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Oct 6 16:00:01 disarray cron[28634]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly)
Oct 6 16:10:01 disarray cron[28646]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Oct 6 16:12:57 disarray e100: eth0: e100_watchdog: link down
Oct 6 16:12:59 disarray e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Oct 6 16:14:18 disarray su(pam_unix)[9425]: session closed for user root
Oct 6 16:20:01 disarray cron[28723]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Oct 6 16:29:19 disarray e100: eth0: e100_watchdog: link down
Oct 6 16:29:21 disarray e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
I’m a user of both Linux, Windows and OSX in both a desktop AND enterprise situations. I helped certify Win2k3 for one of the largest software companies in the world (no, not microsoft) and I, as well as my co-workers were thoroughly impressed with the MASSIVE improvements Microsoft had made from 2000 to 2k3.
To those who complain about drivers, seriously, what is the problem? Business aren’t going to be paying thousands of dollars to role out a true server OS (whether Unix, Windows, etc.) on a homebuilt server. Thats asinine. They’ll purchase in bulk from a major supplier who IS certified to work with whatever enviroment you want.
We tested HP, IBM, Dell AND a few homebuilt servers and never had a problem with driver support for Win2k3. And it smoked the Win2000 servers we had and lets not even talk about security differences. Win2k was like a levee protecting NO. Win2k3 was like a 300 ft brick wall. Ok, maybe not that extreme but you get my point. It was Microsoft’s first true good server OS and in fact, it kept getting better. That it also makes a great workstation OS is just besides the point.
I truely can’t wait for their Longhorn based server to come out. I’ve played with some very, very early versions and even they were improvements over Win2k3 to the point that it was noticeable. I can’t say anything else really (damn NDA’s) but if they continue the way they are I won’t be deploying Linux at small businesses any more but rather Microsoft Server version X small business edition. It just makes sense.
Yea, flame all you want. I’ll even leave the contact information to do it right.
– Chris Knittel
knittel@gmail.com
http://www.tealart.com
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.
“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).
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.
What do you mean their XML won’t interoperate with any standard XML parser?
Their Office XML formats are documented and the DTDs are available online. They are standard-compliant XML whether you want to admit it or not.
Oops! freedesktop.org, not opendesktop.org.
I did go over there and look around. Not exactly a beehive of activity, but it still looks like a good site for references to useful standards.