Why UNIX is better than Windows... By Microsoft
BenBenBen writes "According to a whitepaper found on "a fairly insecure server", UNIX not only is more reliable and easier to maintain than Windows (2000 in this case), it's cheaper too. These shock results are reported on both The Register and (the source) Security Office."
shoutout to my homeys!
When my child was run over by a popping-ball "lawnmower", and killed... I became suddenly aware of the danger of toys. I have locally formed a group to raise awarness of the liability of the toy industry for allowing such lax standards to pass. In addition to our monthly toy burning, we all agree to read on book together on the evils of the toy industry. This book is so popular, it's been selected over a dozen times for book of the month. Very compelling!
(-1, Raw and Uncut is the only way to read)
At least it shows Microsoft is keeping some goal in mind in developing Windows - personally I was beginning to wonder ...
Comment removed based on user account deletion
I thought this was something we knew for a long time now, despite what other media might claim.
Agreed. Now, if they would just be a little more upfront about this sort of thing, I'd feel a little better.
It seems like most of what we have in this regard is leaked stuff, so internally MS knows, but their public face would never admit to it (IMHO).
This has been a test. Had this been a real emergency, we would have fled in terror and you would not have been informed.
Coming soon to a vendor near you - Dogfood(TM) .NET edition
B******s - i just discovered this artive via another site and tried to read - instantly slashdotted!
WTF is it runing on - a quad Xeon IIS 2.0/w2k machine with 1 GB memory?
...constitute some sort of business tort, like disclosing trade secrets? I'm not trying to give MS lawyers any ideas (like they need them) but I've certainly seen Apple goes nuts over this sort of thing.
:P
BTW, that it was on a "fairly insecure server" is as much a defense as "his house had cheap locks."
It shows that Windows is dying, not BSD!
may have insecure server products(and desktop products for that matter) but whatever Security Office was running is nothing more than a smoking pile of silicon and hard drive.
But! Microsoft is faster. So a more accurate summary of the article is "if you want to set up a fast, insecure, bloated and expensive server, choose Windows 2000."
Once more unto the breach, dear friends, once more, Or close the wall up with our American dead!
Hotmail ran FreeBSD for years, didn't it? We probably don't need a whitepaper to tell us what we already knew. Wouldn't it be neat if MS put out a fully reliable, configurable, cheap O/S?
But Security Office wants us to believe that they hax0red some random MS Server and just happened to find a detailed analysis on Unix vs Windows? And this analysis happened to say "we should eat our own dog food"? Not one analysis I have ever read had such a ridiculous analogy in it.
And let's look at this:
The whitepaper, by MS Windows 2000 Server Product Group member David Brooks, has been posted on the Web by Security Office, which says it discovered the item and numerous other confidential MS documents on a poorly protected server.
So Security Office is admitting to criminal activity? Sorry, I call hoax.
Looks like this was written by someone from hotmail explaining why they chose UNIX over Windows initially. A lot of it describes trade-offs that would not matter at all to Microsoft (e.g. licensing costs of Win2k) and the impact to a "startup" is mentioned at least once.
I don't think this is a Microsoft internal memo so much as a hotmail-to-Microsoft internal memo.
It's not exactly located on a *.microsoft.com server so for all we know someone at securityoffice.net needed a bunch of pageviews and made all this up himself. I can't really check the link because it's all clogged at the moment.
You mean... You mean... That instead of paying for Win2000, I could have installed FreeBSD instead?
Oh, the humanity!
(Yes, this was sarcastic!)
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
"in this case"
These are the key words. The idea that any platform can be best at everything is contrary to logic. However that in no way stops the zealots on both sides loudly proclaiming that their platform of choice is the one that's "it".
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
It's been slashdotted and my browser just shows white space!
Saying this are shock results is like saying finding out Micheal Jackson had plastic surgery.
There has been one hour and 46 minutes since the last MS critical article was posted. You need to wait at least two hours.
"If you think education is expensive, try ignorance" - Derek Bok
This isn't news. It's business.
-
I believe I speak for all of us here when I say:
Tee hee.
High-speed Road Trip (18.000KPH)
Microsoft says you can't trust Microsoft, why would you expect them to think Windows is better?
Here's a "white paper" that we heard from this guy who knows this kid
who's going with a girl who saw Ferris pass-out at 31 Flavors last night. By the way, there is no official credible source.
I read "The Register" like I read "The Weekly World News." It's a tabloid in every sense.
Taco, I can't believe you had the balls to post this nonsense (which, if they're any truth to it, was written by a UNIX admin. WTF?)
a fairly insecure server or a slashdotted one?
Read the paper - pretty reasonable stuff. The only thing that may raise eyebrows is the origin of the paper. Goes to show that Microsoft has some competent people working for them (did anybody doubt that, it's after all the company policy that is rotten) but also a horde of absolutely brilliant PR weasels which can turn black to white when you're not watching.
Existence usually comes as a surprise (Idem)
i feel a great big haha coming on, but its nice to see that there is someone in microsoft who has the wits NOT to run their own dog food, at least someone thre has a brain, mind, its no constiation when i see my hotmail account full to the brim with spam, even with every security setting that microsoft would allow running ho hum
dybia felly dwi a hampster (i think therefore i am a hampster)
Another strike against Windows is the GUI: "GUI operations are essentially impossible to script. With large numbers of servers, it is impractical to use the GUI to carry out installation tasks or regular maintenance tasks."
I love Unix. But a huge reason for this unnatural affection is the command line, and the enhancements Unix has made to it (pipes, file descriptors, everything-is-a-file, shell scripting). Even if Microsoft turned around tomorrow and made everything GPL, fixed their security holes and sent chocolates and hookers to Linus and RMS, I'd still prefer Unix for the power of the command line.
In Windows, the command line almost seems like an optional afterthought. In Unix, it's the other way around. (Disclaimer: I'm partly joking, and much more familiar w/U. than M [as I'm sure everyone can tell].) And I think for admin purposes, that makes Unix the more powerful choice.
Carousel is a lie!
this seems to be a quite well written paper (as far as I can see from the Register's summary, the server is /.'ed).
Everything I read there points out things I don't like on windows, much better than I am capable of. While there exist many papers pointing out these things, they are often to "evangelistic" to be seriously considered for convincing management types.
I'm eager to get the whole document, it might have its worth even without mentioning the originaters (watch the copyright, though).
MS is aware its products have problems. This is a nice place to start to work on them.
A nice place to start?! How many years old is Windows?
Trolling is a art,
I hate Microsoft much as the next guy, but the headline is *way* overwrought. If you actually read the linked article, it's just an honest pro/con comparison. They mention certain advantages of UNIX (text configuration, small size) and certain advantages of Windows (better internationalization, more developer support, better throughput). Entirely realistic and a perfectly fine rationale document. There are some bits I disagree with (eg. Visual Studio being better than the UNIX development tools) but overall, this is just a document written by an engineer weighing the various issues involved in switching from UNIX to Windows.
A deep unwavering belief is a sure sign you're missing something...
I tend to view any such "inside" source very suspiciously - the halloween paper about how to bring linux down was fairly believable, but this... Well, the register says:
Now, I didnt read the paper itself, so I apologize if this post is missing the point.
Join the elite! Post at score:2! Ghostwheel is online.
If Microsoft were to modify their configuration files to be more UNIX like, and offer a decent UNIX-like shell, most of the UNIX advantages would fall away. But this kind of modification would be difficult because of the way Windows is structured. UNIX, on the other hand, doesn't have this problem. It is much easier to build a decent GUI on top of a fundamentally sound architecture than it is to build a fundamentally sound architecture under a good GUI.
This represents a tremendous opportunity for UNIX. The UNIX world must develop GUIs to rival Windows' and make sure that the performance is equal to that of Windows. Then one can have the best of both worlds. And then nobody can argue that Windows is better.
Did ya think of that? Small web sites have bandwidth caps!!!!
[#include unixfan_disclaimer], but honestly: look at the advantages of Unix over Windows in so many situations. I'd always kind of wondered if MS was ignoring those problems/advantages for marketing purposes, or if they Just Didn't Get It. Looks like the former, which is reassuring.
Carousel is a lie!
Don't let all those Windows Folks in on the secret.
Unix is MUCH harder to admin.
No GUI's so I'm forced to let the scripts do all the work.
Ha, Ha
</simpsons>
Looks like once again, M$ gets busted for lying through it's teeth. Of course, that's what all good marketing is. Not that any of this comes as a suprise for anyone who's administered both Windows and *nix boxen.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Spend money to fix problems with its software? If they know its poorly coded, why don't they launch an entire other branch dedicated to fixing bugs/product maintenance? It's not like they don't have the money. Throw a billion dollars at .net and windows and see if you can make it better. Hell throw five. They'll still have enough money to run the company for a year without any other income.
As much as we'd all like to think, they people over at Microsoft are not idiots. They have enough money to hire the best and the brightest. They do have some quality products (i.e. those whose securities problems are not much of a problem like games, and i personally like their Intellimouse Optical.).
Can anybody tell me why so many smart people won't see the light of day and dedicate big resources to overcome their biggest drawback?
Why, o why must the sky fall when I've learned to fly?
... that this whole story is a pile of crap.
MS lawyers aren't exactly shy. Think about it.
All these leaked documents are to have fun at someone's expense.
I think it was ESR that wrote an article about MS, and how quite a lot of its money come from buying and selling its stock. These leaks and others like them could be (but I doubt it) some sort of game to play with the stock price. With a large enough lot of shares, even a small fluctuation that you can psuedo predict can generate quite a lot of cash.
M$ used *nix servers, they wouldn't have this problem
-Athat this is just microsoft forcing it's people to use Winblows regardless of what's cost effective or easier. The general idea seems to be that even though the FreeBSD server would have been a better choice, due to ease of administration, capabilities, control, and installation, MS said you will use win2k. .... well nothing.
Now, we just need to get the average person to read and believe this instead of following the MS butterfly into the flame.
If I could only read the actual whitepaper instead of
find ~your -name '*base* | xargs chown
Let's give MS some credit though, they at least know their weaknesses. Windows 2000 is better that previous OSes and is an excellent desktop OS, and MS being a qick learner will surely find ways to try to meet or exceed Unix in upcoming versions of windows. I alway knew moving Hotmail from BSD to Windows servers was a mistake for exacly the reasons they mentioned and I find their unintentional honesty in this memo refreshing.
I do not know what people are acting all surprised. What MS says and what MS knows are two very seperate things. Why do you think they say Linux is a competitor to be watched? Yea, they say 'MS software is better for xyz reasons, yatta yatta' but you better be damn sure that privately they are analyzing their competition inside and out. The first way to get raped by your competition is to ignore it. The second is to assume that you are automatically better than the competition, product quality wise. If a company is dishonest in its internal evaluations of its products against their competition, they will merely alienate their customers even more due to poor design decisions. Remember, MS has a shitload of investors, so going out publicly saying 'our product is subpar to unix' would result in their stocks playing a rollercoaster game. Never mistake self-honesty with PR.
"What can a thoughtful man hope for mankind on Earth, given the experience of the past million years? Nothing." -Bokonon
A badly drawn stick figure (with glasses) with the text "Billy" over it has a caption saying: "Ha ha! You fell for it!"
"Some fight for law. Some fight for justice. What will you fight for? One day, you will see."
...but being unrealistic isn't one of them. They know what their products are like and they know the golden rule, "You don't have to have the best product to win the product wars."
Beta vs. VHS...Zip drives vs. Jazz drives...etc, etc.
about how legit this document is. I never have installed Windows and have it take over 900MB. Maybe server does, but then again you don't usually farm out server images now do you? Microsoft couldn't determine with saftey what to remover? Doesn't that seem a bit odd, they aren't total idiots. Finally, it states that Windows GUI's are impossible to script. I would say more cumbersome, but not impossible, what do you think Rational Robot does? There are a few other packages that also do Windows GUI scripting.
Why bother then? If Apple, with far less resources of any kind whatsoever, managed to plug a decent user interface on the top of a free UNIX-like layer, Microsoft could certainly do the same, only better and faster.
at least microsfot can boneup to when they suck unlike linus
Best tool for the job is !W2K.
I might be missing this one, as I don't see it in the article, but...
Since when has the windows community had more developer support? MSDN is a bloody nightmare... in 'nix I've had very little problems tracking down assistance, howtos, and code samples.
lamenes filter won't let me post the whole document so I will have to break it up
Abstract
This white paper discusses the approach used to convert the Hotmail web
server farm from UNIX to Windows 2000, and the reasons the features and
techniques were chosen. It will focus primarily on the planners,
developers, and system administrators. The purpose of the paper is to
provide insight for similar deployments using Windows 2000. We will
discuss the techniques from the viewpoint of human engineering as well
as software engineering.
Early results from the conversion, which was limited to the front-end
web servers, are:
Windows 2000 provides much better throughput than UNIX.
Windows 2000 provides slightly better performance than UNIX.
There is potential, not yet realized, for stability of
individual systems to be equal to that of UNIX. The load-balancing
technology ensures that the user experience of the service is that
stability is as good as it was before the conversion.
As this paper will show, while the core features of Windows
2000 are able to run the service, its administrative model is not well
suited to the conversion.
The observations related here are derived from experience gained at a
single site. More work would be needed to establish whether they are
representative.
You have to remember that MS employees are real human beings. They aren't idiots for the most part. This guy was being very candid about the shortfalls of a windows server, perhaps with hopes of seeing it improved it in the future. It's the higher ups in the corporate ladder and the marketers that candy-coat all things windows and belittle all things *nix.
Ironically, many of those (perfectly valid) reasons that *nix can make a better server are the same reasons I don't like it on my desktop. Text configuration is a blessing for server farms but a nightmare for newbies with a fresh install.
Maybe they wanted to show this side of their face, but the PR department wouldn't let them. Hence it's location on the "a fairly insecure server."
I don't see things in black and white; I see the gray. Heck, I actually see in color, which makes things more difficult
Read it on the Internet Archive here:w ww.securityoffice.net/mssecrets/hotmail.html
http://web.archive.org/web/20011123043914/http://
From Microsoft's public version of the description of the migration:
"FreeBSD, a UNIX-like system similar to the Linux operating system, was used to run the front-end Web servers that handled login"
FreeBSD isn't a "UNIX-like", its a real UNIX!!!
great site! if it only worked.
A good job the MS PR department would be after this disaster:
1 Convince us Michael Jackson is black despite the Photos
2 Convince RMS that BIll Gates si a friend via Barney toys
3 Convince Saddam to advocate his rule in Iraq.
Don't Tread on OpenSource
W2K and XP images do not fit on a single cd. Can't be done. Good enough for ya. A 700-800 MG base image is stinking huge.
I actually have a 2K single CD image with Office and driver updates and so on, using Norton Ghost. I don't know about XP.
Converting a UNIX .COM Site to Windows
.COM Site
.
Microsoft Internal Distribution Abstract
This white paper discusses the approach used to convert the Hotmail web server farm from UNIX to Windows 2000, and the reasons the features and techniques were chosen. It will focus primarily on the planners, developers, and system administrators. The purpose of the paper is to provide insight for similar deployments using Windows 2000. We will discuss the techniques from the viewpoint of human engineering as well as software engineering.
Early results from the conversion, which was limited to the front-end web servers, are:
Windows 2000 provides much better throughput than UNIX.
Windows 2000 provides slightly better performance than UNIX.
There is potential, not yet realized, for stability of individual systems to be equal to that of UNIX. The load-balancing technology ensures that the user experience of the service is that stability is as good as it was before the conversion.
As this paper will show, while the core features of Windows 2000 are able to run the service, its administrative model is not well suited to the conversion.
The observations related here are derived from experience gained at a single site. More work would be needed to establish whether they are representative.
Project Overview
Microsoft acquired Hotmail at the end of 1997 as a going concern. The service's creators had defined a two-layer architecture built around various UNIX systems:
Front end web servers, built with dual Pentium systems on racked motherboards, running Apache on FreeBSD (a configuration with no need to install licensed software)
Back end file stores, built with Sun Enterprise 4500 servers, running Solaris 2.6 (Sun's UNIX) and with all user data stored on RAID arrays, accessed using very simple filing semantics
Incoming mail listeners, built on Sun Sparc 5 processors, and interacting directly with the back end
Name/password verification engines, build on Enterprise 4500 servers
Member Directory, built on PCs with NT and SQL
The conversion of the Hotmail web servers to Windows is an ongoing project with several rationales. The team was hoping for better utilization of the existing hardware resources. The superior development and internationalization tools are important. A Microsoft property should eat its own dogfood. Finally, we wished to use the conversion experience as a model for other UNIX conversions that we hope to carry out in the future.
The first phase of the conversion, described here, was limited to the web servers. Appropriate hardware was already in place, and the planning and development staff were confident that they already understood how to perform the conversion successfully.
There were several constraints on the conversion process, which are probably typical of the average Internet site:
Hotmail has established an 8-week cycle of version upgrades, and there was a desire (and some partner pressure) to keep that cycle going.
It is essential to keep the service running continuously.
The staff is small, and there was not an opportunity to add staff. Critical Features of Hotmail as a
We believe Hotmail is instructive as an example of the large Internet server site. It is one of the largest such sites on the planet, so we should be judicious in applying its principles to sites that are comparatively very small, and don't have the issues deriving from multiplication of resources.
As stated above, we are concentrating on the front-end web servers. Although some of the following comments are also applicable to the database machines, we will not address them specifically in this paper.
1) Restricted, well-controlled application. The application under UNIX was a collection of CGI programs, serving about 100 distinct URLs, which have been converted to an ISAPI module. The programs are written in C++. The entire application is under the control of one team, and its architecture is well understood by all of the teams (dev, test and operations). Updates are only due to scheduled code releases, or hotfixes. This contrasts with a site like microsoft.com, which has many different authors and continuous updates.
2) Lights-out administration. All the servers are in a controlled facility that may be staffed by contractors, and it should not be necessary for skilled staff to visit the individual machines for any reason. Machines should be self-monitoring, and Operations staff should be able to maintain them remotely using minimal interaction.
3) Multiple identically configured machines. This leads to a need to have all regular system administration functions, including OS and application update, be scripted, rapid, reliable, and non-interactive. There is simply not time for an administrator to interact personally with all machines. A load-balancing mechanism routes customer requests from a virtual address to one of the real servers.
4) System costs suffer multiplicative effects. Adding a VGA monitor or a second NIC to a server, or running a serial cable to it, may be pocket change when applied to a single machine. Purchasing several thousand such devices, however, becomes a significant investment and has to be thoroughly justified.
5) 100% availability. A large Internet site must provide service 24x7. Furthermore, the full capacity should be available all the time. Hotmail's load fluctuates daily according to the time across the US, but not by much; the international usage is high.
6) Simultaneous upgrade. The pervious two points mean that the servers must be upgraded essentially simultaneously, unless some kind of server affinity mechanism can be implemented per user session. Since a typical user interaction involves several clicks, it would not be good for a user to jump backwards and forwards between code releases; the problems would range from inconsistency in style to (apparently) half-implemented new features.
7) No personal machines or accounts. All machines are assumed to be secure because of physical location and electrical isolation. Generally speaking, when an administrator is operating on the server or a scheduled tasks runs, full administrative privileges are given. This increases the danger, but reduces the load required to maintain and synchronize accounts.
8) Remote monitoring. All performance monitoring is done by querying the server or by automated reports, and monitoring uses the single NIC. In Hotmail's case, there is plenty of spare network headroom on each server for this monitoring not to penalize the primary operation.
9) No architectural limits on growth. An Internet site expects to keep growing, and built-in limits that seem unreasonably high in the early days will one day loom up and need to be fixed, using resources that should be enhancing the site. Hotmail has grown from 9 million accounts when it was acquired by Microsoft, to 100 million in July 2000, without significant changes in the hardware or software architecture.
The final four items are more closely related to Hotmail's architectural choices, but we believe they are representative of the market.
10) Scale-out. The Hotmail website is built from several modules, with each module present in different multiples and able to be scaled out almost indefinitely. In this phase of the project, we are considering the front-end, the web servers that house all of the user interface logic and some parts of the business logic. Among the servers, the majority ("front doors") runs some code in response to each click, and these were the primary targets for conversion. The machines are single-board x86 PCs, moderately powerful, using Apache, running on FreeBSD version 3.0, to deliver content. Fortunately, these servers are good Windows 2000 hosts.
There are also some servers that serve static content and will be almost trivial to convert once the front doors have been converted. Administration of these servers will use the same methodology as the front doors. They also run on FreeBSD, using the server "boa", which is optimized for serving static content rapidly.
11) Configuration conservatism. There are more than 3,000 front door machines, all identically configured. Having the servers essentially identical is important to the operators' ability to administer the site. The approach to the hardware is very conservative: once a hardware configuration is established, it is easy to keep rolling out copies rather than try to qualify a newer model.
This conservatism also applies to the software design. The need to run the project on Internet Time [1] has an impact on this project in several ways: in this case, designers always need to be improving the application and there is little resource left over for redesigning the basic architecture. Furthermore, the various modules of the site are developed independently, creating a force for stability in the internal protocols.
12) Design for stability. Virtually continuous uptime and a consistent response time are crucial. This is achieved by some overcapacity, and highly reliable load-balancing hardware (Cisco Local Director). Local Director is just another module in the scale-out solution.
13) Controlled and understood systems. A fact about UNIX is that it is easy for an administrator to ensure that there are no irrelevant services running. As well as giving the potential for maximizing performance, it is useful to be sure that there are no random TCP/IP or UDP ports open that could be used as a basis for an attack. To some, this transparency is intrinsic to UNIX, but it also comes from a greater familiarity among system administrators with its internal workings.
The headless nature of the systems, and their remote location, have a profound influence on the way the systems are administered. Headless operation means that any direct interaction will be through a remote session (telnet or Terminal Server); nobody will be able to detect an important dialog on the console [2] , and even a bluescreen is not apparent. Remote operation means that there is a specific cost associated with walking up to the machine. The site is serviced by contractors whose job is mainly limited to replacing failed servers and rebooting on demand; it is possible to attach a monitor and keyboard to a running system, but that is operationally an exception. Advantages of UNIX
Commonly, although not strictly correctly, the generic term UNIX describes a family of operating systems that are deployed on a variety of systems. Although their internal design may be different, the variants appear to their end-users as the same system, with minor (and annoying) differences in usage. There are two variants in use at Hotmail: FreeBSD, which can be used without license cost and is available in source form, and Solaris, which is bundled with Sun hardware. Linux, which is just another UNIX variant, was not used at Hotmail.
The following sections will examine facts about UNIX (specifically FreeBSD) as they relate to the conversion problem. We also consider Apache as an intrinsic part of the UNIX-based solution, in the same way that IIS is an intrinsic part of Windows 2000 Server.
1) Familiarity. Entrepreneurs in the startup world are generally familiar with one version of UNIX (usually through college education), and training in one easily converts to another. When setting up a new enterprise, it's easy to work with what you know than to take time investigating the alternatives.
2) Reputation for stability. Both the UNIX kernel, and the design techniques it encourages, are renowned for stability. A system of several thousand servers must run reliably and without intervention to restart failed systems. For Windows 2000, we must first prove the stability in the same environment, and we must then convince the rest of the world.
Apache is also designed for stability and correctness, rather than breadth of features or high performance demands.
3) FreeBSD is free. Although there are collateral costs (it's not particularly easy to set up) the freedom from license costs is a major consideration, especially for a startup. The free availability of source also means that it can be fairly simple (or it can be very difficult) to make local changes [3]
4) Easy to minimize. The typical UNIX server is taking care of one task, not acting as a desktop and development platform for a user. It is particularly easy to cut down the load on the system so that only the minimum number of services is running. This reduced complexity aids stability and transparency.
5) Transparent. It's easy to look at a UNIX system and know what is running and why. Although its configuration files may have arcane (and sometimes too-simple) syntax, they are easy to find and change.
6) Preference for text files. Most configuration setups, log files, and so on, are plain text files with reasonably short line lengths. Although this may be marginally detrimental to performance (usually in circumstances where it doesn't matter) it is a powerful approach because a small, familiar set of tools, adapted to working with short text lines, can be used by the administrators for most of their daily tasks. In particular, favorite tools can be used to analyze all the system's log files and error reports.
7) Powerful but simple scripting languages and tools. Again, familiarity and consistency among UNIX implementations is the key. Over the years, UNIX versions have evolved a good set of single-function commands and shell scripting languages that work well for ad-hoc and automated administration. The shell scripting languages fall just short of being a programming language (they have less power than VBScript or JScript). This may seem to be a disadvantage, but we must remember that operators are not programmers; having to learn a block-structured programming language is a resistance point. Scripts that combine executables into pipelines are simple to build incrementally and experimentally, and even the experienced Hotmail administrators seem to be taking that approach for special purpose scripts (using CMD) rather than authoring with one of the object-oriented scripts.
On the other hand, PERL (another language that has grown organically with a lot of community feedback) is more of a programming than scripting language. It is popular for repeated, automated tasks that can be developed and optimized by senior administrative staff who do have the higher level of programming expertise required. Problems of Windows
Consider the above list of UNIX strengths to be also a list of Windows weaknesses. However, there are some specific issues that need to be called out.
1) A GUI bias. Windows 2000 server products continue to be designed with the desktop in mind. There are too many functions that are either too difficult or impossible to perform using a text-based interface.
Why is this important? There are several reasons:
GUI operations are essentially impossible to script. With large numbers of servers, it is impractical to use the GUI to carry out installation tasks or regular maintenance tasks.
Text-based operations are more versatile; an administrator can usually do more to a system (good and bad) than is provided by the restricted, planned methods using the GUI.
There is in place at Hotmail an established secure channel into the production system, using a text-based secure shell interface.
Using a GUI amounts to hiding the true system modifications from the system administrators and operators. UNIX operators like the sense of control that comes from their ability to modify system tables and configuration files more directly.
Operating a GUI through a slow network connection can be too slow to be useful. Although this is less important, it can still be a consideration when there is a need to administer or diagnose a system through a dialup connection.
There are, indeed, many non-GUI administrative programs provided in the core Windows 2000 product and in the Resource Kit. The problem is that the collection is somewhat arbitrary, incoherent and inconsistent. Programs seem to have been written to fill an immediate need and there is stylistic inconsistency and poor feature coverage.
2) Complexity. A Windows server out of the box is an elaborate system. Although it performs specific tasks well (such as being a web server) there are many services that have a complex set of dependencies, and it is never clear which ones are necessary and which can be removed to improve the system's efficiency.
3) Obscurity. Some parameters that control the system's operation are hidden and difficult to fully assess. The metabase is an obvious example. The problem here is that is makes the administrator nervous; in a single-function system he wants to be able to understand all of the configuration-related choices that the system is making on his behalf.
4) Resource utilization. It's true that Windows requires a more powerful computer than Linux or FreeBSD. In practice, this is a less important constraint. When you are building a large operation, you will use smaller numbers of relatively powerful systems. The PC systems in use at Hotmail are perfectly capable of running Windows, and the machine's basic power is the same whether it is run with UNIX or Windows. For most of the time, it is only executing application code and most of the extra elaboration is not apparent.
5) Image size. The team was unable to reduce the size of the image below 900MB; Windows contains many complex relationships between pieces, and the team was not able to determine with safety how much could be left out of the image. Although disk space on each server was not an issue, the time taken to image thousands of servers across the internal network was significant. By comparison, the equivalent FreeBSD image size is a few tens of MB.
6) Reboot as an expectation. Windows operations still involves too many reboots. Sometimes they are unnecessary, but operators reboot a system rather than take the time to debug it. For example, a service may be hung, and rather than take the time to find and fix the problem, it is often more convenient to reboot. By contrast, UNIX administrators are conditioned to quickly identify the failing service and simply restart it; they are helped in this by the greater transparency of UNIX and the small number of interdependencies. Some reboots are demanded by an application installation, and are not strictly necessary.
7) License costs. As we will see when discussing load balancing, the license cost of Windows software is a major consideration when converting from the unencumbered UNIX implementations. Although there were no costs to the Hotmail project, as a Microsoft department, the team did consider the software costs in order to make the conversion a useful model for future customers.
They used Server in preference to Advanced Server (no features of Advanced Server were necessary).
They reluctantly used Services for UNIX and Interix, to get access to features that were not adequately provided in Windows. Future releases of Windows will have the features that would make it unnecessary to add those subsystems and avoid their notional cost.
No business analysis was undertaken to determine whether the benefit of the conversion would outweigh the notional cost of the Windows licenses.
Strengths of Windows
1)Windows has more resources behind its development. It does have greater complexity than the free UNIX distributions, and used wisely (and with knowledge) that can lead to a more effective solution. For example, IIS is more self-tuning than Apache.
IIS and Windows have many more tuning parameters than Apache and FreeBSD. The problem here is to make them comprehensible to new administrators.
2) The development platform, specifically Visual Studio, is a major advantage. Even before the conversion to Windows was contemplated, Hotmail developers used Visual Studio on NT4 to develop and debug their code. The code was eventually recompiled for UNIX when the first level of testing was complete. There is nothing approaching the power of Visual Studio on any UNIX, let alone the free ones, with the possible exception of the Java development tools.
The superior development platform has also had a positive operational impact in the live site. In the first days of deployment, some server threads went into a CPU-consuming loop. Using Visual Studio, Hotmail developers were able to find the application-level problem in a few minutes. That would have been impossible using UNIX tools.
3) Vastly better monitoring infrastructure. UNIX has some rudimentary event reporting and performance monitoring tools, but nothing to approach the integrated power of the event logging and performance monitoring features. Again, it is necessary to use them wisely; event logging in particular has a human and system overhead that we'll talk about later.
4) Better hardware detection. Setting up UNIX on a new PC is difficult, requiring a more intimate knowledge of how the hardware is built. That's an up-front cost; given the existence of multiple identically configured systems, cloning an established system doesn't present the same problems.
5) Internationalization. The software tools available in Windows to provide multiple localized solutions are far ahead of most UNIX systems. Hotmail Architectural Decisions Project constraints
The constraints called out earlier (the 8-week upgrade cycle, the need to keep the service running, and the small number of staff) produced enough pressure on the development and administrative staff that the team agreed to devote one cycle to the platform conversion and not change the application during that time. This allowed the developers and testers to focus on the specific conversion issues. During the conversion, the application itself was the same on both platforms. This means that a user may have successive pages served by either platform, and not notice the difference.
The same constraints led to a desire not to change operational practices without good reason, because of the investment in training staff at all skill levels, and the feeling that the fewer things were changed, the fewer were the potential blocking problems.
Finally, the economic necessity of not adding technical staff to the conversion means that there was no consideration given to major re-architecture of the application. Installation Methodology Conserved
There is in place a method of remotely bootstrapping a server to a new OS and application suite, and converting one rack (21 machines) in about 20 minutes. Replicating the installation capability was a goal of the project, and conserving as much as possible of the infrastructure to do it was strongly desired. Conversion to ISAPI
The web server application suite consists of about 90 different transactions, each corresponding to a click on a web page. Using Apache, each one is implemented as an executable program using the CGI interface, and run in a separate process managed and owned by the web server. Processes are the natural way of encapsulating a single stateless transaction using UNIX.
Converting to Windows, the development team decided not to use the CGI interface to IIS. Creating a new Windows process is more expensive than creating a UNIX process. Instead, the team converted the CGI code to run as an ISAPI application, in which the transactions are processed by code that (in the most basic implementation) runs within the IIS process.
Running in process will be more efficient than running as a CGI, because the process creation overhead is avoided. We could have brought that advantage to UNIX. Apache supports the same concept; the equivalent to an ISAPI filter is called a module. Naturally, we did not waste time building the module implementation just to throw it away.
Conversion from CGI to ISAPI was essentially automated by using a filter that effectively presents the standard CG interface (using data streams and environment variables) to the user code. Because the application code was well written and did not make assumptions about its environment, the major part of the conversion went very smoothly and did not require significant unexpected engineering [4] . There were some intentional pieces of re-engineering:
The spell, dictionary, and thesaurus functions were rewritten to use Microsoft technology from Office and Encarta. The UNIX versions use binaries from Merriam Webster. The spellcheck feature is much improved; there are coverage problems with the dictionary data that need to be addressed.
The SMTP service of IIS was used to handle outgoing mail, replacing a UNIX standard mail service.
Virus scanning of attachments used an external UNIX utility from McAfee; this was replaced by its NT equivalent.
The most challenging, and anticipated, problem with converting from CGI to ISAPI derives from the forgiving nature of the CGI architecture. Memory leaks, unclosed files and similar problems can be tolerated, because they are automatically cleaned up when the CGI process terminates. Even an occasional abort is tolerated; it results in an invalid page to one customer, but does not usually affect any other part of the system.
By contrast, ISAPI modules share a process with the web server, as do Apache modules. Resource leaks will accumulate, and crashes have the potential to bring down the server (although not the entire service, thanks to load balancing). There are process isolation techniques available in IIS to minimize these problems, but the team decided to use the in-process model for full efficiency. Among the actions taken:
Use a private heap that is cleared at the end of each web transaction.
In testing, monitor for resource leaks and fix them.
Implement an IIS heartbeat monitor that will quickly notice and restart any failed IIS service.
Converting to ASP was not considered. That would have been a complete rewrite of the application, with no great advantage (Hotmail does not use a WinDNA infrastructure, for example). In fact, the implementation uses some ASP ideas and terms, as much of the user content is determined by template files that look like ASP files, but the interpretation engine is completely homegrown. One motivation for borrowing ASP syntax was to use Microsoft development tools (for example, to aid internationalization).
Load Balancing Technology
Hotmail has a large investment in Cisco Local Director; every web access goes to an LD, which redistributes the load among real servers. Hotmail chose to continue with LD, rather than use the Windows load balancing technology, because the infrastructure was in place and did not need to be reconfigured (reducing the learning curve). Also, LD fits the Hotmail model well; it is possible to place up to 400 servers behind the virtual address, and each Hotmail cluster can have over 300 identically configured servers.
Another major issue is the potential cost. Although Hotmail uses Microsoft software without license fees, we must consider this project as a model for real customers. Use of WLBS requires Advanced Server, but Server provides all the other features used by Hotmail. Using list prices, the cost comparison for a farm of 3500 servers is:
Using WLBS (hence Advanced Server): $15M+
Using LD and Server: $6M+
This does not take into account any extra PCs necessary to handle WLBS overhead (administrative, as well as the cycles needed to redirect the load) or the plans by Cisco to further reduce the cost of LD by building it into their network switches.
When considered in the context of a large web farm, WLBS has a serious economic disadvantage that can only be justified by the value of its administrative and monitoring tools. There is considerable competition in the IP load balancing market, which drives costs down; the numbers quoted above are based on the price we paid in mid-1999, around $17,000 per unit. An existing system that has load balancing in place will presumably have adequate tools, so the added value of WLBS, in terms of operational flexibility and superior monitoring, must be considerable if it is to be economically justified. System Creation, Mastering and Installation OS installation and configuration
Each of several thousand systems must be converted to the new operating system and application suite, and this process must be carried out while the service is operating, and within a short timespan. Required are a mechanism for packaging the image and a method for delivering it. Among the special requirements:
Each server already has a name and static IP address; to fit in with existing operating practices and configurations, they should retain the same name and IP address. Using a static address, compared with DHCP, makes system administration simpler and more transparent. A machine's name relates to its physical position within a cluster.
It should be possible to convert a machine without physical access.
It should be possible to revert systems quickly to FreeBSD in case of serious problems with the Windows conversion.
Downtime for reboots and service restarts should be minimized.
Several technologies were investigated and rejected. In most cases, there were blocking issues that were seemingly small, but without guarantee of resolution the team had to adopt a method that they could control. Some of the issues were:
RIS can be used for automatically installing an image from a server when a machine is initially booted. Drawbacks include: physical access is required to the machine (to force a network boot), and the system requires that an IP address be supplied with DHCP (DHCP is not used at Hotmail, because of the requirement for static IP addresses). It was impossible to control the name of the new server as required. In addition RIS was not supported for installing Server, although it was known to work.
AppCenter is intended for this kind of application. However, the initial release of AppCenter is targeted for small installations. It also lacks some features needed by application installation and update.
Unattended setup performs a standard installation across the network; because of all the file copying and calculation involved, it is too slow.
The team opted to extend an existing technology, "kickstart". This uses the OS existing on the machine to bootstrap an image, prepared using sysprep, and then run scripts to perform the remaining configuration tasks that need to be carried out after the install. The image copy is sufficiently fast, and the post-install steps are minimal.
IIS configuration
It proves to be difficult to configure IIS in a precisely controlled way. The metabase is obscure and poorly documented, and produced too many surprises. Furthermore, a system created using sysprep does not produce a ready-to-run metabase.
Consequently, it was necessary to construct the metabase by using scripts. The scripts were a mixture of command files that repeatedly call the mdutil utility, and some special-purpose pieces of scripting code (VBScript in this case, although any language that supports COM would work). The scripts are run as part of the mini-setup step that follows construction of the operating system on the target computer.
Figuring out the metabase structure, which elements needed to be set, and how to suppress the unwanted elements (for example, the trees defining the default and administration site) was the most complex and error-prone part of the entire setup design. Considerable reverse engineering was necessary. Major improvement is needed in the way the metabase is described to users, and the way that administrators can script the commonest tasks.
Tuning and hardening the system
The task was to tune the system for the best combination of throughput and performance, and also to harden it against attack from outside. This required attention in several areas:
System configuration, in removing all unnecessary system services and making sure the remaining services are configured as effectively as possible.
Registry settings for performance and security.
Metabase settings for performance and security.
The team was unable to find a comprehensive set of published settings that covered the above areas, perhaps because there are so many sets of demands on system configuration in general. However, we feel that configuring a system to be a locked down web server will be a common enough task that it would be useful to establish and publish a set of recommended actions and settings. Use of Active Directory
Active Directory (AD) is a key addition in Windows 2000, yet it has been difficult to justify its use in the web server farm context. Users in AD
AD is generally used to manage populations of users and machines. At Hotmail, it is not interesting to use AD to manage customers. User privileges and restrictions are already handled by the Hotmail application code, and there is no concept of granting or restricting access to customers within the Hotmail infrastructure. Furthermore, there is a constantly changing population of many usernames (over 100 million in July, 2000), a size that may be beyond the capabilities of Windows 2000.
The site has users in another sense: administrator accounts that are used to manage the machines by hand or by script. However, all administrators are fully trusted in the system (once they are inside the firewall), and it is normal to allow them to log in with full administrative privileges. This is the equivalent to the UNIX root account. It is useful to allow single sign-in, to allow an administrator to move from one machine to the next, and also to add new users at a central point; however, these needs are easily met by NT4's NTLM. Computer systems in AD
There is a stronger argument for entering the servers in AD. This will provide integration with DNS, and holds out the potential for administrators to classify machines in whatever ways they find useful operationally.
The Hotmail server farm is organized as a series of clusters, each containing several hundred servers. These machines must be named systematically. In practice, server names are duplicated between clusters, as they are identified uniquely by the fully qualified domain name (each cluster is a subdomain). This presents a problem for AD, which (apparently because of NetBIOS compatibility) does not permit duplicate short names anywhere within a set of subdomains. Getting rid of the NetBIOS legacy will be a great boon for Microsoft.
This apparently trivial restriction was enough to postpone the idea of constructing an AD, which in any case is additional work without obvious benefit. It was necessary to maintain the names of systems through the upgrade, because of legacy monitoring and administrative tools. Existing administrative mechanisms were adapted and did not need the benefits of AD. It is expected that, later, administrative staff will be able to develop tools that can make use of AD (for example, the ability to query on servers with a particular characteristic may be useful) but for now there is no need to break into the circle.
The Windows DNS service, operating without AD, proved perfectly capable of handling the load, and was able to take up the data from a UNIX BIND server easily. Windows DNS is used at the site for both internal and external name resolution. Application Installation and Update Application update styles
It is naturally a requirement that a web-based service operate continually, without customer-visible degradations of service. This is not just a matter of pride; even a loss of availability for a few minutes every month can produce too much degradation in the perceptions and (assuming we publish uptime numbers) the availability measurement.
It's a solution, but a weak one, to put servers behind load-balancing equipment and take them out of service when required for upgrade or other maintenance. The challenge is to keep each server running continuously as much as possible. Except for operating system upgrades, a system based on FreeBSD and Apache can keep operating while the application is upgraded, and Windows should be able to do the same.
Application updates at Hotmail are of two kinds: content and code. Content updates change only data files, generally those that directly determine what the customer sees on the screen, and they are carried out on their own schedule. Apache can handle both content and code updates without stopping the service. Updates can be rolled out directly, when the data is updated in place. They can also be timed, when the updates are put on the servers in a staging location together with an update batch job that will be triggered at the desired moment. The timed update is used when it is important for the application's integrity that the entire site be updated simultaneously, something that is impossible to achieve when updating several thousand servers across a single network. Application update techniques
Apache running under UNIX supports both kinds of updates very simply. A CGI application can be replaced, even while the old file is being executed, and the next execution will use the new file. The same is true of content. If Apache's own configuration files must be updated, there is a procedure to signal the server to reset itself and reread its configuration, and that takes around a second.
Unfortunately, IIS 5.0 does not support either kind of update well. When IIS accesses content directly, it locks the folders. Fortunately, this doesn't apply to most of the Hotmail upgrades. The bigger issue is updating the ISAPI filters, which must be done while the IIS server is stopped. The entire process can take a minute or so.
The Hotmail staff has invented a technique that uses a thin ISAPI filter (the "shim"). It loads the application as a separate DLL and passes on all the ISAPI requests. It also watches for updates to the application DLL in a predetermined place, and when it is notified of an update it maps the new DLL, sends it all new requests, and allows the old requests to terminate before removing the old DLL. This technique has been made available to the IIS team. Intellimirror
The team investigated, but decided not to use, Intellimirror-based update. First, Intellimorror requires AD to be implemented. Second, Intellimirror (working with the Installer) only makes updates to applications when a user logs in or when the system is rebooted. Since user login is an irrelevant activity in this context, and the whole idea is to prevent a reboot, Intellimirror-based update does not meet the need. Distribution mechanism and format
The UNIX implementation packaged new code as a compressed file using the UNIX tar format, and distributed it (and the necessary installation code) using the UNIX rdist utility.
The team investigated use of MS Installer technology for a packaging format. Although it would probably have met the requirements (including the ability to unpack versioned files into specific locations, make registry changes, and run arbitrary code during installation) it proved too difficult to learn, despite the availability of a few decent authoring packages. The team stayed with the zipfile method of packaging.
The UNIX rdist mechanism is also well suited to installation and updates on a large number of identical machines. From a central location, the administrator can iterate over a list of servers and push packages to them. The rdist daemon (service) running on the remote systems will extract files from the packages into their specified locations and run arbitrary commands before and after installation. This is approximately equivalent to MS Installer features, with the additional ability to push distributions over a list of machines. The Hotmail team implemented a version of the rdist daemon to run on Windows. Monitoring and Logging Network Operations Center
The Hotmail infrastructure is monitored remotely, in an operations center located with the development staff in the Sunnyvale campus. There are many tools in place to monitor the performance of the server farm. Some of these measure the systems by their external behavior, and they did not need modification. Others use information gathered by the servers themselves (performance counters, disk statistics and so on). It proved to be relatively simple to write scripts that would extract the desired information from the Windows performance counters and send them to the Operations consoles. Autonomous monitoring
Some of the self-test and monitoring features of the servers are performed by customized operations (usually scripts) executed at predetermined intervals. These intervals are anything between a minute and a week.
Using FreeBSD, such tasks are scheduled by the cron service. Jobs are scheduled by being listed in a file, one line per job. Changing the file is easy to accomplish using the command line (or rdist), and replacing the entire file is a good way to ensure that each server has exactly the schedule of jobs that the administrator intended. Jobs can be scheduled to execute once, or at intervals down to one minute.
Although the Windows Task Scheduler service is fundamentally able to look after such jobs, the interfaces provided in Windows does not measure up to the task.
The usual interface is the GUI, which is appropriate for setting up jobs on a machine at a time, is labor-intensive and error-prone.
The command at is deprecated, is not able to schedule repeated jobs at a frequency of less than one day.
The command jt was offered by the Task Scheduler team, but it is unsupported and awkward to use (it was intended for testing).
None of the three interfaces offers an easy way to replace the current task schedule entirely.
The team met the need by running the cron service provided in Services for UNIX. As described earlier, relying on Services for UNIX (or any other package subject to extra license costs) provides a bad model for other customer deployments. We have provided input to the Whistler command line team for an improved interface to Task Scheduler. Logging
There was a minor issue concerning the UNIX integrated logging feature (syslog). The kernel, standard services, and application code can write lines of text to syslog, and a single configuration file is used to determine the destination of the text lines. Thus an important alert can result in a console message and email, while an informational message can be written to a log file. The administrator can change the destinations without code having to be recompiled.
An application like Hotmail often uses the application access to syslog to write statistical data of business interest (such as creation of a new account or sending of an email message). Administrators can use other tools to analyze the logs, archive them, or simply count occurrences and throw the logs away. Typical usage is at the order of one event per second; the high performance associated with the kernel log is not required.
There are no features in Windows 2000 that provide the same combination of convenience and configurability, although the kernel event log comes close. For convenience, and also to avoid recoding, the team elected to use the syslog feature from the Interix subsystem, introducing the issues about notional cost that have already been discussed.
Whistler introduces the Enterprise Event Log, a lightweight WMI feature, which seems to provide the desired functionality. A closer examination of the kernel logging may show that it too can meet the need, Any replacement should involve trivial change to the existing application code (perhaps even using a macro); it would be desirable not to have to recode calls to syslog in order to keep down the amount of source code conversion. Ad-hoc Maintenance
There are occasions when, after deployment, the administrators need to make a configuration change consistently across the entire farm. The rdist mechanism can be used for configuration changes; if the change is simple then rsh can be used. The key fact about UNIX that makes this work is, again, that all system administration tasks can be done from the command line.
Windows should provide the same functionality, given some means of aggregating a group of servers and some way of performing an operation consistently across all the servers. Single commands, pipelines, or scripts (command scripts or COM-based scripts) would be appropriate actors; however, scripts need to be downloaded, executed (and, if necessary, cleaned up). There should be the ability to defer the activity until a specific time, presumably using the improved Task Scheduler. In other words, Windows must support old-fashioned batch processing.
One specific example of a feature that is not accessible to the batch model is Network Interface Card customization; for example, there have been requirements to change the card's speed from 10 Mbps to 100Mbps (at a specific time) or to change the MTU setting. The configuration model of an Ethernet NIC varies between manufacturers, and the standard GUI is driven by a schema that is found in the registry. Such a GUI is not at all adaptable to the batch model. It is possible to make the required changes to the registry, but that would require a subsequent reboot, which is not acceptable. A brief period off the network, while the card resets itself, is the most downtime that can be accepted.
The Hotmail team, with help from a network engineer, developed a rudimentary application that would put a specific value in the registry and (using an undocumented interface) reset the card in a way that will make it pick up the new value. We strongly urge that the feature be put into the shipping system. Converting the UNIX Administrator
Helping UNIX system administrators with the transition to Windows is an experience in itself, and much was learned. Again, this is data from a single corporate experience, but we suspect it is fairly typical. Here, then, is the human engineering overview.
Initially, the plan to convert from FreeBSD to Windows was met with responses ranging from skepticism to hostility, in a way that should be familiar to those who share the attitudes of the various UNIX communities to Microsoft software.
We engaged with the operations staff by asking them to define what their everyday tasks are, in all areas of operating system and application maintenance. Instead of a set of tasks, we were handed a set of the UNIX commands and features that were used to carry out those tasks. While this did not directly meet the need, it gave us an opportunity to address all of the features directly, and show that Windows has an exact equivalent in the core system, or in the Resource Kit, or easily provided with a script. There were very few cases where no satisfactory alternative could be found. Essentially, this was throwaway work, as the eventual solution solved the problems in a more Windows-like way, but it was an excellent opportunity to gain the confidence of the operations staff.
It was clear from the responses that some people from the UNIX side of the house cannot distinguish our different systems that are marketed under the Windows brand; there was an inbuilt assumption that Windows 2000 shares the features and faults of Windows 95. Those who were somewhat familiar with Windows NT were not aware of the range of the non-GUI offerings (to be fair, neither were we); the set of commands in the product and the Resource Kit is fairly broad although, as we have seen, there are gaps and they lack stylistic consistency.
Other staff members, not members of the regular operations team, carried out the conversion. When deployment came near, the Operations staff had to learn the new tools and paradigms. Their existence proved enough; the main interest of Operations staff is, after all, to run and administer the system, and once they found that there were tools, whether custom-built or standard, that did the job well enough, they were able to take control and gain a sense of ownership. Some standard one-day courses were also given to the staff, to prepare them for handling system debugging, hotfix application and so on. By this time, the staff had become convinced that Windows is, after all, a real operating system with surprising richness.
To summarize:
n Make the message clear: Windows 2000 is a modern operating system; it's not Windows 9x.
n Gain the confidence of the skeptics by showing them that it is a real operating system, and not so different from other operating systems in fundamental ways, by showing some basic command-line tools that monitor the system in action.
n Use the self-interest of operations staff to ensure that they have full authority over their areas of responsibility. Conclusions
These are the main lessons that we can extract from the Hotmail conversion.
1) We need a consistent, comprehensive, thoughtful approach to integrated management of a set of servers. This does not necessarily mean that we should slavishly follow the UNIX model of iterating through a list of machines with an rsh command, or pushing configuration files to a list of machines. The fundamental goal is to be able to manage machines as an aggregate; doing this through a GUI is not necessarily evil, so long as it can be done remotely, and once. The point applies to application distribution as well as to system tuning.
2) NLBS is at an economic disadvantage, due to its association with Advanced Server, and Hotmail operations staff were sufficiently satisfied with the existing solution that they did not feel the need to investigate NLBS's operational advantages.
3) The metabase needs to be ripped out and replaced with something that is much easier for an administrator to see and understand, and be confident that there are no hidden surprises. The IIS6 planners have heard this opinion.
4) It should be easier to tune and lock down a single system, and have the changes propagated to all systems in a given class.
5) Windows is too complex to understand at first, particularly during a conversion from UNIX. There are just too many things about it for a planner in a startup to understand. Typically there is little time to attend training. The problem is most Computer Science graduates come to their startups already understanding enough about UNIX to be confident that they can use it effectively. We do need to be careful to balance the complexity and transparency carefully.
6) The basic need for an Internet site, converting from UNIX to Windows, is to be able to quickly replace their application and operational methodology with something at least equally good. Improvements that come for free are good, but implementing new technologies and programming methods will need to take a back seat so long as they delay the main purpose, which is to keep a site online and competitive. Anything else is a cost that needs to bring a clear benefit.
[1] Use of this term can be something of a conceit; here we mean that there are economic pressures to roll out new versions of the application on a rapid cycle, typically 8 weeks. This means the team is constantly in "ship mode". In addition, new systems are built out barely ahead of the demand.
[2] Whistler will enable a Terminal Server user to log on to the console, but as we see later Terminal Server is not an ideal solution.
[3] For example, there was a need to reduce the MTU parameter of the TCP/IP interface. There was no command available to make the change, but the code in the network stack was easy to find, modify (one line) and rebuild.
[4] One notable exception: the Windows library call to perform case-independent string matching was found to be unexpectedly inefficient, presumably because of the internationalization concerns that are not present on the simpler UNIX system
securityoffice.net is not responsible for the misuse or illegal use of any of the information and/or the file listed on this site. Any question please contact: ts@securityoffice.net
In this I must agree, at least in reference to desktops. XP is a RAM pig, and a space pig, but it does a lot of my jobs a whole lot more effectively than 9x/ME did. Less crashing and lockups etc (except in the case of crappy drivers, which were unsigned). It doesn't always run everything 98 did, but at least I'm not seeing "Protection Fault" or "Illegal Operation" over few hours now.
I'm still not entirely happy with windows servers, but a lot of the difficulties do stem from the software being run on them. And almost everyone into webservers probably knows how ugly IIS and friends can be.
Maybe if MS turned towards just making decent desktops, things would improve? Making a Microsoft 'nix would require abandoning their GUI loving ways and actually adding something back-end that made sense.
How many other UNIX servers Microsoft depends on to run it's evil enterprise. I'm sure there are many more that are internal-only and not accessible or visible to the public.
Perhaps the world will someday wakeup and see the beast for what it really is...
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
FUD Alert FUD Alert!
You would think slashdotters wouldn't be so guillable. First we're talking about the register the most unbiased publication in existance right? And they just 'found' this paper doing some illegal activity that they're willng to disclose to thousands of readers.
Sorry guys I'm calling bullshit on this one.
Hold up, wait a minute, let me put some pimpin in it
Having read their section on Windows' Strengths, there are several bits that I disagree with, but really the hardware issue is the most annoying.
Better hardware detection. Setting up UNIX on a new PC is difficult, requiring a more intimate knowledge of how the hardware is built. That's an up-front cost; given the existence of multiple identically configured systems, cloning an established system doesn't present the same problems.
This I don't agree with. Granted that you need a little bit more knowledge to get hardware working, if you do know what you're doing (and this paper is aimed at people who do, or at least should know what they're doing), it is far more reliable. If something goes wrong, there is a reason it went wrong, and a way to fix it. In windows, even the biggest guru finds the hardware detection system to be black magic to say the least. At worst, it can be completely random!
Plus cloning a Linux is very easy and reliable, because as a general rule there are fewer driver dependencies. Think about a Slackware setup booting into console only server mode. How many hardware/module dependencies are there? All I can think of is the Ethernet card. Other than that, the image is completely transferrable.
Malike Bamiyi wanted my assistance.
Excuse me, but they've known this for years and they still have not been able to create a decent product. All they have done is piled more and more complexity on windows and made the problem worse. Please stop appologizing for them.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
memo
Microsoft acquired Hotmail at the end of 1997 as a going concern. The
service?s creators had defined a two-layer architecture built around
various UNIX systems:
Front end web servers, built with dual Pentium systems on
racked motherboards, running Apache on FreeBSD (a configuration with no
need to install licensed software)
Back end file stores, built with Sun Enterprise 4500 servers,
running Solaris 2.6 (Sun?s UNIX) and with all user data stored on RAID
arrays, accessed using very simple filing semantics
Incoming mail listeners, built on Sun Sparc 5 processors, and
interacting directly with the back end
Name/password verification engines, build on Enterprise 4500
servers
Member Directory, built on PCs with NT and SQL
The conversion of the Hotmail web servers to Windows is an ongoing
project with several rationales. The team was hoping for better
utilization of the existing hardware resources. The superior development
and internationalization tools are important. A Microsoft property
should eat its own dogfood. Finally, we wished to use the conversion
experience as a model for other UNIX conversions that we hope to carry
out in the future.
The first phase of the conversion, described here, was limited to the
web servers. Appropriate hardware was already in place, and the planning
and development staff were confident that they already understood how to
perform the conversion successfully.
There were several constraints on the conversion process, which are
probably typical of the average Internet site:
Hotmail has established an 8-week cycle of version upgrades,
and there was a desire (and some partner pressure) to keep that cycle going.
It is essential to keep the service running continuously.
The staff is small, and there was not an opportunity to add staff.
The fact that you can ask that question is a key issue. MS has made a decision to be backwards compatible. This represents a huge liability. It isn't such a big deal for BSD since upgrading is just a matter of typing "make." What MS is doing makes a heck of a lot more sense to me than what Appled has done. (Oh great, here goes my karma, but now I've started...) Apple built a culture of bravado about how advanced its OS (interface really) is. Then when they hit a wall they decided to just change the processor and the instruction set. They then did it again when going to OSx.
MS on the other hand is trying to evolve rather than start over. If they are willing to admit that there are flaws then they can make necessary changes. That is the reason that you can ask how old Windows is.
Personally, I wished that they had tossed out a lot of bad baggage a long time ago. I especially liked the last paragraph from the Guardian:
It is terrifying to contemplate the efficiency bonus MS would have enjoyed if it had only been willing to base its entire corporate operations on UNIX instead of eating its own dog food. The software monopolist might today be in the bizarre position of being the world's only consumer of unices.
Seems like I smell the faint odor of Onions...
Agreed - most likely, it's just some guy with a 28K modem who's got a dedicated phone line. Sometimes, his mom picks up the wrong line and the whole site goes down.
This is a term Microsoft uses alot. Just do a search on msdn for dogfood and you can see when they use it. For example I read their paper on switching Microsoft.com from asp pages to aspx pages while aspx was still in beta. They called it eating their on dogfood.
Critical Features of Hotmail as a .COM Site
/very/ small, and don?t have the issues deriving from
We believe Hotmail is instructive as an example of the large Internet
server site. It is one of the largest such sites on the planet, so we
should be judicious in applying its principles to sites that are
comparatively
multiplication of resources.
As stated above, we are concentrating on the front-end web servers.
Although some of the following comments are also applicable to the
database machines, we will not address them specifically in this paper.
1) Restricted, well-controlled application. The application under
UNIX was a collection of CGI programs, serving about 100 distinct URLs,
which have been converted to an ISAPI module. The programs are written
in C++. The entire application is under the control of one team, and its
architecture is well understood by all of the teams (dev, test and
operations). Updates are only due to scheduled code releases, or
hotfixes. This contrasts with a site like microsoft.com, which has many
different authors and continuous updates.
2) Lights-out administration. All the servers are in a controlled
facility that may be staffed by contractors, and it should not be
necessary for skilled staff to visit the individual machines for any
reason. Machines should be self-monitoring, and Operations staff should
be able to maintain them remotely using minimal interaction.
3) Multiple identically configured machines. This leads to a need
to have all regular system administration functions, including OS and
application update, be scripted, rapid, reliable, and non-interactive.
There is simply not time for an administrator to interact personally
with all machines. A load-balancing mechanism routes customer requests
from a virtual address to one of the real servers.
4) System costs suffer multiplicative effects. Adding a VGA monitor
or a second NIC to a server, or running a serial cable to it, may be
pocket change when applied to a single machine. Purchasing several
thousand such devices, however, becomes a significant investment and has
to be thoroughly justified.
5) 100% availability. A large Internet site must provide service
24x7. Furthermore, the full capacity should be available all the time.
Hotmail?s load fluctuates daily according to the time across the US, but
not by much; the international usage is high.
6) Simultaneous upgrade. The pervious two points mean that the
servers must be upgraded essentially simultaneously, unless some kind of
server affinity mechanism can be implemented per user session. Since a
typical user interaction involves several clicks, it would not be good
for a user to jump backwards and forwards between code releases; the
problems would range from inconsistency in style to (apparently)
half-implemented new features.
7) No personal machines or accounts. All machines are assumed to be
secure because of physical location and electrical isolation. Generally
speaking, when an administrator is operating on the server or a
scheduled tasks runs, full administrative privileges are given. This
increases the danger, but reduces the load required to maintain and
synchronize accounts.
8) Remote monitoring. All performance monitoring is done by
querying the server or by automated reports, and monitoring uses the
single NIC. In Hotmail?s case, there is plenty of spare network headroom
on each server for this monitoring not to penalize the primary operation.
9) No architectural limits on growth. An Internet site expects to
keep growing, and built-in limits that seem unreasonably high in the
early days will one day loom up and need to be fixed, using resources
that should be enhancing the site. Hotmail has grown from 9 million
accounts when it was acquired by Microsoft, to 100 million in July 2000,
without significant changes in the hardware or software architecture.
The final four items are more closely related to Hotmail?s architectural
choices, but we believe they are representative of the market.
10) Scale-out. The Hotmail website is built from several modules, with
each module present in different multiples and able to be scaled out
almost indefinitely. In this phase of the project, we are considering
the front-end, the web servers that house all of the user interface
logic and some parts of the business logic. Among the servers, the
majority (?front doors?) runs some code in response to each click, and
these were the primary targets for conversion. The machines are
single-board x86 PCs, moderately powerful, using Apache, running on
FreeBSD version 3.0, to deliver content. Fortunately, these servers are
good Windows 2000 hosts.
There are also some servers that serve static content and will be almost
trivial to convert once the front doors have been converted.
Administration of these servers will use the same methodology as the
front doors. They also run on FreeBSD, using the server ?boa?, which is
optimized for serving static content rapidly.
11) Configuration conservatism. There are more than 3,000 front door
machines, all identically configured. Having the servers essentially
identical is important to the operators? ability to administer the site.
The approach to the hardware is very conservative: once a hardware
configuration is established, it is easy to keep rolling out copies
rather than try to qualify a newer model.
This conservatism also applies to the software design. The need to run
the project on Internet Time [1] has an impact on this project
in several ways: in this case, designers always need to be improving the
application and there is little resource left over for redesigning the
basic architecture. Furthermore, the various modules of the site are
developed independently, creating a force for stability in the internal
protocols.
12) Design for stability. Virtually continuous uptime and a consistent
response time are crucial. This is achieved by some overcapacity, and
highly reliable load-balancing hardware (Cisco Local Director). Local
Director is just another module in the scale-out solution.
13) Controlled and understood systems. A fact about UNIX is that it is
easy for an administrator to ensure that there are no irrelevant
services running. As well as giving the potential for maximizing
performance, it is useful to be sure that there are no random TCP/IP or
UDP ports open that could be used as a basis for an attack. To some,
this transparency is intrinsic to UNIX, but it also comes from a greater
familiarity among system administrators with its internal workings.
The headless nature of the systems, and their remote location, have a
profound influence on the way the systems are administered. Headless
operation means that any direct interaction will be through a remote
session (telnet or Terminal Server); nobody will be able to detect an
important dialog on the console [2] , and even a bluescreen is
not apparent. Remote operation means that there is a specific cost
associated with walking up to the machine. The site is serviced by
contractors whose job is mainly limited to replacing failed servers and
rebooting on demand; it is possible to attach a monitor and keyboard to
a running system, but that is operationally an exception.
here -l t. asp?url=/technet/prodtechnol/windows2000serv/case/ hotmail/Default.asp
http://www.microsoft.com/technet/treeview/defau
but if you're using IE, better turn off ActiveX scripting, then prepare to click "No" at least ten timies in a row
Advantages of UNIX
.
Commonly, although not strictly correctly, the generic term UNIX
describes a family of operating systems that are deployed on a variety
of systems. Although their internal design may be different, the
variants appear to their end-users as the same system, with minor (and
annoying) differences in usage. There are two variants in use at
Hotmail: FreeBSD, which can be used without license cost and is
available in source form, and Solaris, which is bundled with Sun
hardware. Linux, which is just another UNIX variant, was not used at
Hotmail.
The following sections will examine facts about UNIX (specifically
FreeBSD) as they relate to the conversion problem. We also consider
Apache as an intrinsic part of the UNIX-based solution, in the same way
that IIS is an intrinsic part of Windows 2000 Server.
1) Familiarity. Entrepreneurs in the startup world are generally
familiar with one version of UNIX (usually through college education),
and training in one easily converts to another. When setting up a new
enterprise, it?s easy to work with what you know than to take time
investigating the alternatives.
2) Reputation for stability. Both the UNIX kernel, and the design
techniques it encourages, are renowned for stability. A system of
several thousand servers must run reliably and without intervention to
restart failed systems. For Windows 2000, we must first prove the
stability in the same environment, and we must then convince the rest of
the world.
Apache is also designed for stability and correctness, rather than
breadth of features or high performance demands.
3) FreeBSD is free. Although there are collateral costs (it?s not
particularly easy to set up) the freedom from license costs is a major
consideration, especially for a startup. The free availability of source
also means that it can be fairly simple (or it can be very difficult) to
make local changes [3]
4) Easy to minimize. The typical UNIX server is taking care of one
task, not acting as a desktop and development platform for a user. It is
particularly easy to cut down the load on the system so that only the
minimum number of services is running. This reduced complexity aids
stability and transparency.
5) Transparent. It?s easy to look at a UNIX system and know what is
running and why. Although its configuration files may have arcane (and
sometimes too-simple) syntax, they are easy to find and change.
6) Preference for text files. Most configuration setups, log files,
and so on, are plain text files with reasonably short line lengths.
Although this may be marginally detrimental to performance (usually in
circumstances where it doesn?t matter) it is a powerful approach because
a small, familiar set of tools, adapted to working with short text
lines, can be used by the administrators for most of their daily tasks.
In particular, favorite tools can be used to analyze all the system?s
log files and error reports.
7) Powerful but simple scripting languages and tools. Again,
familiarity and consistency among UNIX implementations is the key. Over
the years, UNIX versions have evolved a good set of single-function
commands and shell scripting languages that work well for ad-hoc and
automated administration. The shell scripting languages fall just short
of being a programming language (they have less power than VBScript or
JScript). This may seem to be a disadvantage, but we must remember that
operators are not programmers; having to learn a block-structured
programming language is a resistance point. Scripts that combine
executables into pipelines are simple to build incrementally and
experimentally, and even the experienced Hotmail administrators seem to
be taking that approach for special purpose scripts (using CMD) rather
than authoring with one of the object-oriented scripts.
On the other hand, PERL (another language that has grown organically
with a lot of community feedback) is more of a programming than
scripting language. It is popular for repeated, automated tasks that can
be developed and optimized by senior administrative staff who do have
the higher level of programming expertise required.
I thought UNIX was intended to play Space Wars?!!!
But I agree that it's a great shortcoming of all GUI-based systems that they don't have a good scripting mechanism thoroughly integrated. You should be able to write a script to do anything that you have authority to do.
One "advantage" Windows has over UNIX is that having the GUI built into the kernel drasticlly imporves performance over the client/server architecture used for X. Of course, that also means a poorly written video card driver or game can crash your whole system. It appears that the only people to get the right balance of performace/stability are the QNX photon developers.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Nice! First ever Missy Elliot reference on Slashdot, if I'm not mistaken.
I was curious about the author, so I started Googling a bit. Many of his newsgroup posts are in relation to Microsoft's UNIX products (like Outlook Express for HP-UX and IE for Solaris) and his .sig is ususally "Test Lead, Microsoft Corp." Here he mentions being an ex-employee of OSF and The Open Group.
Enquiring minds and all that.
the no
*nix is what it is not because it needs a gui or anything like that, but because it's been put through the paces - years of research and dev - and not just constructed by people with a biz deadline in mind.
when people don't have version this or that or media this or upgrade thats hanging over their head constantly, then they produce different code.
plus, how many academic people work on win*? the *nix community has a good relationship with research institutions and the hacker (not cracker) community. these people ususally know what's up and don't care about the pretty aspect of it, which is all the biz, money making industry cares about. that is why you get something that's secure and works.
for systems that need to work, you want it as simple as possible. that means no guis, and text config files. why have some super-duper, encrypted, multiuser, proprietary, 64-bit reverse factored database just to store smb configurations or file system mappings? exactly. it's totally unnecessary and adds more complexity which adds more bugs which adds more security and other flaws.
simple and to the point - that's *nix is about. and that's why it just works.
Consider the above list of UNIX strengths to be also a list of Windows
weaknesses. However, there are some specific issues that need to be
called out.
1) A GUI bias. Windows 2000 server products continue to be designed with the desktop in mind. There are too many functions that are either
too difficult or impossible to perform using a text-based interface.
Why is this important? There are several reasons:
GUI operations are essentially impossible to script. With largenumbers of servers, it is impractical to use the GUI to carry out
installation tasks or regular maintenance tasks.
Text-based operations are more versatile; an administrator can usually do more to a system (good and bad) than is provided by the restricted, planned methods using the GUI.
There is in place at Hotmail an established secure channel into the production system, using a text-based secure shell interface.
Using a GUI amounts to hiding the true system modifications from the system administrators and operators. UNIX operators like the sense of control that comes from their ability to modify system tables and configuration files more directly.
Operating a GUI through a slow network connection can be too slow to be useful. Although this is less important, it can still be a
consideration when there is a need to administer or diagnose a system through a dialup connection.
There are, indeed, many non-GUI administrative programs provided in the core Windows 2000 product and in the Resource Kit. The problem is that
the collection is somewhat arbitrary, incoherent and inconsistent. Programs seem to have been written to fill an immediate need and there
is stylistic inconsistency and poor feature coverage.
2) Complexity. A Windows server out of the box is an elaborate system. Although it performs specific tasks well (such as being a web
server) there are many services that have a complex set of dependencies, and it is never clear which ones are necessary and which can be removed
to improve the system?s efficiency.
3) Obscurity. Some parameters that control the system?s operation are hidden and difficult to fully assess. The metabase is an obvious
example. The problem here is that is makes the administrator nervous; in a single-function system he wants to be able to understand all of the
configuration-related choices that the system is making on his behalf.
4) Resource utilization. It?s true that Windows requires a more powerful computer than Linux or FreeBSD. In practice, this is a less
important constraint. When you are building a large operation, you will use smaller numbers of relatively powerful systems. The PC systems in
use at Hotmail are perfectly capable of running Windows, and the machine?s basic power is the same whether it is run with UNIX or Windows. For most of the time, it is only executing application code and most of the extra elaboration is not apparent.
5) Image size. The team was unable to reduce the size of the image below 900MB; Windows contains many complex relationships between pieces, and the team was not able to determine with safety how much could be left out of the image. Although disk space on each server was not an issue, the time taken to image thousands of servers across the internal network was significant. By comparison, the equivalent FreeBSD image size is a few tens of MB.
6) Reboot as an expectation. Windows operations still involves too many reboots. Sometimes they are unnecessary, but operators reboot a system rather than take the time to debug it. For example, a service may be hung, and rather than take the time to find and fix the problem, it
is often more convenient to reboot. By contrast, UNIX administrators are conditioned to quickly identify the failing service and simply restart
it; they are helped in this by the greater transparency of UNIX and the small number of interdependencies. Some reboots are demanded by an
application installation, and are not strictly necessary.
7) License costs. As we will see when discussing load balancing, the license cost of Windows software is a major consideration when
converting from the unencumbered UNIX implementations. Although there were no costs to the Hotmail project, as a Microsoft department, the team did consider the software costs in order to make the conversion a useful model for future customers.
They used Server in preference to Advanced Server (no features of Advanced Server were necessary).
They reluctantly used Services for UNIX and Interix, to get access to features that were not adequately provided in Windows. Future
releases of Windows will have the features that would make it unnecessary to add those subsystems and avoid their notional cost.
No business analysis was undertaken to determine whether the benefit of the conversion would outweigh the notional cost of the
Windows licenses.
--16:41:28-- http://www.securityoffice.net/mssecrets/msdetails. html
. html
(try: 22) => `msdetails.html'
Connecting to www.securityoffice.net:80...
connect: Connection timed out
Retrying.
--16:44:37-- http://www.securityoffice.net/mssecrets/msdetails
(try: 23) => `msdetails.html'
Connecting to www.securityoffice.net:80... connected!
HTTP request sent, awaiting response...
Read error (Connection reset by peer) in headers.
Retrying.
Sigh. Anyway, here's the hotmail page, which I got earlier. It's over 100k so I zipped it, you evil slashdotters: http://www.kyz.uklinux.net/new/hotmail.zip
Strengths of Windows
1) Windows has more resources behind its development. It does have greater complexity than the free UNIX distributions, and used wisely
(and with knowledge) that can lead to a more effective solution. For example, IIS is more self-tuning than Apache.
IIS and Windows have many more tuning parameters than Apache and FreeBSD. The problem here is to make them comprehensible to new administrators.
2) The development platform, specifically Visual Studio, is a major advantage. Even before the conversion to Windows was contemplated, Hotmail developers used Visual Studio on NT4 to develop and debug their code. The code was eventually recompiled for UNIX when the first level of testing was complete. There is nothing approaching the power of Visual Studio on any UNIX, let alone the free ones, with the possible
exception of the Java development tools.
The superior development platform has also had a positive operational impact in the live site. In the first days of deployment, some server
threads went into a CPU-consuming loop. Using Visual Studio, Hotmail developers were able to find the application-level problem in a few
minutes. That would have been impossible using UNIX tools.
3) Vastly better monitoring infrastructure. UNIX has some rudimentary event reporting and performance monitoring tools, but nothing to approach the integrated power of the event logging and performance monitoring features. Again, it is necessary to use them wisely; event logging in particular has a human and system overhead that we?ll talk about later.
4) Better hardware detection. Setting up UNIX on a new PC is difficult, requiring a more intimate knowledge of how the hardware is
built. That?s an up-front cost; given the existence of multiple identically configured systems, cloning an established system doesn?t
present the same problems.
5) Internationalization. The software tools available in Windows to provide multiple localized solutions are far ahead of most UNIX systems.
There is intelligent live inside Microsoft!
First, is it a real document downloaded while an FTP server had some unsecured directories exposed recently? Possibly. So what? Does this mean that this is official MS scripture? Do you mean that if we review every file on your hard drive we won't find something that a) wasn't written by you, b) you probably don't want us to see, c) doesn't represent your current thoughts.
Ahh the C option... perhaps this was really written by someone who happens to be an MS employee. Perhaps this guy was just given the job; take Hotmail and move it from BSD to Windows and this guy is like many who might say; but it works as it is. Lets not break it to fix it - lets leave it as it is so I'll write up every reason I can think of not to do this!
Has everyone missed/forgotten the MS papers describing the reasons why and exactly how Hotmail WAS moved from BSD to Windows 2000?
In this document you'll find how untrue so much of what was written in the stolen document. No scripting support in windows 2000 because it also includes a GUI? Are you fucking stupid or what? There is complete scripting control in windows 2000, always has been. You can control every part of windows 2000 networking and services and disks and users and security through scripting. Sure, you can use the GUI too. Does the fact that Linux can run a GUI mean that suddenly it's scripting goes away?
In the conversion to Hotmail they employeed scipts and automation tools builtin to windows. They moved because Windows 2000 was faster and more efficient. It is obviously stable as any honest person running W2K/XP can tell you.
I understand there is a need to attack MS at every step around here. I understand the desire to believe every antiMS piece ever submitted. But sometimes even the more ignorant *nix admin has to eventually read the facts and find that NO OS is perfect. That W2K is not utterly and totally flawed and that it actually is a real competitor for other Server OSes. Once you accept this you can drop the zealous approach and do things in a logic, calm and professional manner. If is really better - prove it to us with grown up responses and facts - not running around waving a copy of The Enquirer which tells us Michael Jackson and Bill Clinton were seperated at birth by aliens somewhere near Roswell.
Project constraints
The constraints called out earlier (the 8-week upgrade cycle, the need
to keep the service running, and the small number of staff) produced
enough pressure on the development and administrative staff that the
team agreed to devote one cycle to the platform conversion and not
change the application during that time. This allowed the developers and
testers to focus on the specific conversion issues. During the
conversion, the application itself was the same on both platforms. This
means that a user may have successive pages served by either platform,
and not notice the difference.
The same constraints led to a desire not to change operational practices
without good reason, because of the investment in training staff at all
skill levels, and the feeling that the fewer things were changed, the
fewer were the potential blocking problems.
Finally, the economic necessity of not adding technical staff to the
conversion means that there was no consideration given to major
re-architecture of the application.
Installation Methodology Conserved
There is in place a method of remotely bootstrapping a server to a new
OS and application suite, and converting one rack (21 machines) in about
20 minutes. Replicating the installation capability was a goal of the
project, and conserving as much as possible of the infrastructure to do
it was strongly desired.
Conversion to ISAPI
The web server application suite consists of about 90 different
transactions, each corresponding to a click on a web page. Using Apache,
each one is implemented as an executable program using the CGI
interface, and run in a separate process managed and owned by the web
server. Processes are the natural way of encapsulating a single
stateless transaction using UNIX.
Converting to Windows, the development team decided not to use the CGI
interface to IIS. Creating a new Windows process is more expensive than
creating a UNIX process. Instead, the team converted the CGI code to run
as an ISAPI application, in which the transactions are processed by code
that (in the most basic implementation) runs within the IIS process.
Running in process will be more efficient than running as a CGI, because
the process creation overhead is avoided. We could have brought that
advantage to UNIX. Apache supports the same concept; the equivalent to
an ISAPI filter is called a module. Naturally, we did not waste time
building the module implementation just to throw it away.
Conversion from CGI to ISAPI was essentially automated by using a filter
that effectively presents the standard CG interface (using data streams
and environment variables) to the user code. Because the application
code was well written and did not make assumptions about its
environment, the major part of the conversion went very smoothly and did
not require significant unexpected engineering [4] . There were
some intentional pieces of re-engineering:
The spell, dictionary, and thesaurus functions were rewritten
to use Microsoft technology from Office and Encarta. The UNIX versions
use binaries from Merriam Webster. The spellcheck feature is much
improved; there are coverage problems with the dictionary data that need
to be addressed.
The SMTP service of IIS was used to handle outgoing mail,
replacing a UNIX standard mail service.
Virus scanning of attachments used an external UNIX utility
from McAfee; this was replaced by its NT equivalent.
The most challenging, and anticipated, problem with converting from CGI
to ISAPI derives from the forgiving nature of the CGI architecture.
Memory leaks, unclosed files and similar problems can be tolerated,
because they are automatically cleaned up when the CGI process
terminates. Even an occasional abort is tolerated; it results in an
invalid page to one customer, but does not usually affect any other part
of the system.
By contrast, ISAPI modules share a process with the web server, as do
Apache modules. Resource leaks will accumulate, and crashes have the
potential to bring down the server (although not the entire service,
thanks to load balancing). There are process isolation techniques
available in IIS to minimize these problems, but the team decided to use
the in-process model for full efficiency. Among the actions taken:
Use a private heap that is cleared at the end of each web
transaction.
In testing, monitor for resource leaks and fix them.
Implement an IIS heartbeat monitor that will quickly notice and
restart any failed IIS service.
Converting to ASP was not considered. That would have been a complete
rewrite of the application, with no great advantage (Hotmail does not
use a WinDNA infrastructure, for example). In fact, the implementation
uses some ASP ideas and terms, as much of the user content is determined
by template files that look like ASP files, but the interpretation
engine is completely homegrown. One motivation for borrowing ASP syntax
was to use Microsoft development tools (for example, to aid
internationalization).
People keep saying the article is fake. Maybe it is maybe it isn't. It seems to state what most objective users of Unix and Windows have been saying all along, there are advantages/disadvantages to both Microsoft and Unix.
I don't believe it is fake but it could be a pretty smart troll, either way it is an interesting read.
I'm not going to say windows makes a better server. They don't. Linux has been way more effecient, unless you spend big bucks on a badass box for your doze.
However this whitepaper is probably not from microsoft. Most M$ employees would know that you can shut all the services that don't need to be running just by using three clicks to access Computer Management.
Security is in the hands of the holder, and just becuase most windows admins are morons and don't devote thier lives to learning about computers, doesn't mean theres a couple people out there that know what to do.
Microsoft's "public" interface is constantly tearing at the bounds of credibility. Witness Balmer's talk about how they didn't adequately sell their customers on the benefits of Software Assurance:)
Internally, though, this shows that Microsoft is quite rational and realistic. As a company, they will survive and prosper a lot longer on that course than if too much of the internal management started to actually believe what is destined for external public consumption in the marketplace.
Let's all learn the good lesson from Microsoft here.
It should be obvious that if you're in a business that relies on evaluation of information technology that you should rely only very loosely upon what is presented to you publicly.
Second, keep your internal evaluations
Shoot, I knew years ago that BSD was a cheap solid workhorse after learning about ftp.cdrom.com
"Provided by the management for your protection."
Hotmail has a large investment in Cisco Local Director every web access
goes to an LD, which redistributes the load among real servers. Hotmail
chose to continue with LD, rather than use the Windows load balancing
technology, because the infrastructure was in place and did not need to
be reconfigured (reducing the learning curve). Also, LD fits the Hotmail
model well; it is possible to place up to 400 servers behind the virtual
address, and each Hotmail cluster can have over 300 identically
configured servers.
Another major issue is the potential cost. Although Hotmail uses
Microsoft software without license fees, we must consider this project
as a model for real customers. Use of WLBS requires Advanced Server, but
Server provides all the other features used by Hotmail. Using list
prices, the cost comparison for a farm of 3500 servers is:
Using WLBS (hence Advanced Server): $15M+
Using LD and Server: $6M+
This does not take into account any extra PCs necessary to handle WLBS
overhead (administrative, as well as the cycles needed to redirect the
load) or the plans by Cisco to further reduce the cost of LD by building
it into their network switches.
When considered in the context of a large web farm, WLBS has a serious
economic disadvantage that can only be justified by the value of its
administrative and monitoring tools. There is considerable competition
in the IP load balancing market, which drives costs down; the numbers
quoted above are based on the price we paid in mid-1999, around $17,000
per unit. An existing system that has load balancing in place will
presumably have adequate tools, so the added value of WLBS, in terms of
operational flexibility and superior monitoring, must be considerable if
it is to be economically justified.
"Eating your own dog food" is a well-known expression, esp. common in Microsoft, that refers to products mature enough that you use them yourself.
One of the primary uses for the phrase is when you can use your compiler to compile your own compiler. That's a major milestone that indicates the product is actually useful for a non-trivial task.
Another example is using your own accounting software to maintain your own books. Or your own mail software to manage your own mail system.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
This brings to mind a ramble I bored my wife with not too long ago - What if the cause for the secrecy and closed source doctrine @ MS is to cover up the truth... Might we find a bit of *NIX code in the NT kernel? Yeah, the wife was reeeeal interested in that one....
find something original to say.
OS installation and configuration
Each of several thousand systems must be converted to the new operating system and application suite, and this process must be carried out while
the service is operating, and within a short timespan. Required are a mechanism for packaging the image and a method for delivering it. Among
the special requirements:
Each server already has a name and static IP address; to fit in with existing operating practices and configurations, they should retain
the same name and IP address. Using a static address, compared with DHCP, makes system administration simpler and more transparent. A
machine?s name relates to its physical position within a cluster.
It should be possible to convert a machine without physical access.
It should be possible to revert systems quickly to FreeBSD in case of serious problems with the Windows conversion.
Downtime for reboots and service restarts should be minimized.
Several technologies were investigated and rejected. In most cases, there were blocking issues that were seemingly small, but without
guarantee of resolution the team had to adopt a method that they could control. Some of the issues were:
RIS can be used for automatically installing an image from a server when a machine is initially booted. Drawbacks include: physical
access is required to the machine (to force a network boot), and the system requires that an IP address be supplied with DHCP (DHCP is not
used at Hotmail, because of the requirement for static IP addresses). It was impossible to control the name of the new server as required. In
addition RIS was not supported for installing Server, although it was known to work.
AppCenter is intended for this kind of application. However, the initial release of AppCenter is targeted for small installations. It
also lacks some features needed by application installation and update.
Unattended setup performs a standard installation across the network; because of all the file copying and calculation involved, it is
/mdutil /utility, and some special-purpose pieces of scripting
too slow.
The team opted to extend an existing technology, ?kickstart?. This uses the OS existing on the machine to bootstrap an image, prepared using
sysprep, and then run scripts to perform the remaining configuration tasks that need to be carried out after the install. The image copy is
sufficiently fast, and the post-install steps are minimal.
IIS configuration
It proves to be difficult to configure IIS in a precisely controlled way. The metabase is obscure and poorly documented, and produced too
many surprises. Furthermore, a system created using sysprep does not
produce a ready-to-run metabase.
Consequently, it was necessary to construct the metabase by using
scripts. The scripts were a mixture of command files that repeatedly
call the
code (VBScript in this case, although any language that supports COM
would work). The scripts are run as part of the mini-setup step that
follows construction of the operating system on the target computer.
Figuring out the metabase structure, which elements needed to be set,
and how to suppress the unwanted elements (for example, the trees
defining the default and administration site) was the most complex and
error-prone part of the entire setup design. Considerable reverse
engineering was necessary. Major improvement is needed in the way the
metabase is described to users, and the way that administrators can
script the commonest tasks.
Tuning and hardening the system
The task was to tune the system for the best combination of throughput
and performance, and also to harden it against attack from outside. This
required attention in several areas:
System configuration, in removing all unnecessary system
services and making sure the remaining services are configured as
effectively as possible.
Registry settings for performance and security.
Metabase settings for performance and security.
/root /account. It is useful to allow single sign-in, to allow an
The team was unable to find a comprehensive set of published settings
that covered the above areas, perhaps because there are so many sets of
demands on system configuration in general. However, we feel that
configuring a system to be a locked down web server will be a common
enough task that it would be useful to establish and publish a set of
recommended actions and settings.
Use of Active Directory
Active Directory (AD) is a key addition in Windows 2000, yet it has been
difficult to justify its use in the web server farm context.
Users in AD
AD is generally used to manage populations of users and machines. At
Hotmail, it is not interesting to use AD to manage customers. User
privileges and restrictions are already handled by the Hotmail
application code, and there is no concept of granting or restricting
access to customers within the Hotmail infrastructure. Furthermore,
there is a constantly changing population of many usernames (over 100
million in July, 2000), a size that may be beyond the capabilities of
Windows 2000.
The site has users in another sense: administrator accounts that are
used to manage the machines by hand or by script. However, all
administrators are fully trusted in the system (once they are inside the
firewall), and it is normal to allow them to log in with full
administrative privileges. This is the equivalent to the UNIX
administrator to move from one machine to the next, and also to add new
users at a central point; however, these needs are easily met by NT4?s NTLM.
Computer systems in AD
There is a stronger argument for entering the servers in AD. This will
provide integration with DNS, and holds out the potential for
administrators to classify machines in whatever ways they find useful
operationally.
The Hotmail server farm is organized as a series of clusters, each
containing several hundred servers. These machines must be named
systematically. In practice, server names are duplicated between
clusters, as they are identified uniquely by the fully qualified domain
name (each cluster is a subdomain). This presents a problem for AD,
which (apparently because of NetBIOS compatibility) does not permit
duplicate short names anywhere within a set of subdomains. Getting rid
of the NetBIOS legacy will be a great boon for Microsoft.
This apparently trivial restriction was enough to postpone the idea of
constructing an AD, which in any case is additional work without obvious
benefit. It was necessary to maintain the names of systems through the
upgrade, because of legacy monitoring and administrative tools. Existing
administrative mechanisms were adapted and did not need the benefits of
AD. It is expected that, later, administrative staff will be able to
develop tools that can make use of AD (for example, the ability to query
on servers with a particular characteristic may be useful) but for now
there is no need to break into the circle.
The Windows DNS service, operating without AD, proved perfectly capable
of handling the load, and was able to take up the data from a UNIX BIND
server easily. Windows DNS is used at the site for both internal and
external name resolution.
What, do you honestly think that there are no Unix systems anywhere within the Microsoft organization?
Of course they'll have some Unix boxes around, just as I'm sure Sun has some Microsoft boxes around. Even if they don't actually run applications on them (doubtful), they'll want them for competitive analysis for their marketing people. It's hard to compete if you don't know what the competition is doing.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Application update styles
It is naturally a requirement that a web-based service operate
continually, without customer-visible degradations of service. This is
not just a matter of pride; even a loss of availability for a few
minutes every month can produce too much degradation in the perceptions
and (assuming we publish uptime numbers) the availability measurement.
It?s a solution, but a weak one, to put servers behind load-balancing
equipment and take them out of service when required for upgrade or
other maintenance. The challenge is to keep each server running
continuously as much as possible. Except for operating system upgrades,
a system based on FreeBSD and Apache can keep operating while the
application is upgraded, and Windows should be able to do the same.
Application updates at Hotmail are of two kinds: content and code.
Content updates change only data files, generally those that directly
determine what the customer sees on the screen, and they are carried out
on their own schedule. Apache can handle both content and code updates
without stopping the service. Updates can be rolled out directly, when
the data is updated in place. They can also be timed, when the updates
are put on the servers in a staging location together with an update
batch job that will be triggered at the desired moment. The timed update
is used when it is important for the application?s integrity that the
entire site be updated simultaneously, something that is impossible to
achieve when updating several thousand servers across a single network.
Application update techniques
Apache running under UNIX supports both kinds of updates very simply. A
CGI application can be replaced, even while the old file is being
executed, and the next execution will use the new file. The same is true
of content. If Apache?s own configuration files must be updated, there
is a procedure to signal the server to reset itself and reread its
configuration, and that takes around a second.
Unfortunately, IIS 5.0 does not support either kind of update well. When
IIS accesses content directly, it locks the folders. Fortunately, this
doesn?t apply to most of the Hotmail upgrades. The bigger issue is
updating the ISAPI filters, which must be done while the IIS server is
stopped. The entire process can take a minute or so.
The Hotmail staff has invented a technique that uses a thin ISAPI filter
(the ?shim?). It loads the application as a separate DLL and passes on
all the ISAPI requests. It also watches for updates to the application
DLL in a predetermined place, and when it is notified of an update it
maps the new DLL, sends it all new requests, and allows the old requests
to terminate before removing the old DLL. This technique has been made
available to the IIS team.
Intellimirror
The team investigated, but decided not to use, Intellimirror-based
update. First, Intellimorror requires AD to be implemented. Second,
Intellimirror (working with the Installer) only makes updates to
applications when a user logs in or when the system is rebooted. Since
user login is an irrelevant activity in this context, and the whole idea
is to prevent a reboot, Intellimirror-based update does not meet the need.
Distribution mechanism and format
The UNIX implementation packaged new code as a compressed file using the
UNIX
code) using the UNIX
The team investigated use of MS Installer technology for a packaging
format. Although it would probably have met the requirements (including
the ability to unpack versioned files into specific locations, make
registry changes, and run arbitrary code during installation) it proved
too difficult to learn, despite the availability of a few decent
authoring packages. The team stayed with the zipfile method of packaging.
The UNIX
updates on a large number of identical machines. From a central
location, the administrator can iterate over a list of servers and push
packages to them. The
systems will extract files from the packages into their specified
locations and run arbitrary commands before and after installation. This
is approximately equivalent to MS Installer features, with the
additional ability to push distributions over a list of machines. The
Hotmail team implemented a version of the
Monitoring and Logging
Network Operations Center
The Hotmail infrastructure is monitored remotely, in an operations
center located with the development staff in the Sunnyvale campus. There
are many tools in place to monitor the performance of the server farm.
Some of these measure the systems by their external behavior, and they
did not need modification. Others use information gathered by the
servers themselves (performance counters, disk statistics and so on). It
proved to be relatively simple to write scripts that would extract the
desired information from the Windows performance counters and send them
to the Operations consoles.
Autonomous monitoring
Some of the self-test and monitoring features of the servers are
performed by customized operations (usually scripts) executed at
predetermined intervals. These intervals are anything between a minute
and a week.
Using FreeBSD, such tasks are scheduled by the
scheduled by being listed in a file, one line per job. Changing the file
is easy to accomplish using the command line (or
the entire file is a good way to ensure that each server has exactly the
schedule of jobs that the administrator intended. Jobs can be scheduled
to execute once, or at intervals down to one minute.
Although the Windows Task Scheduler service is fundamentally able to
look after such jobs, the interfaces provided in Windows does not
measure up to the task.
The usual interface is the GUI, which is appropriate for
setting up jobs on a machine at a time, is labor-intensive and error-prone.
The command /at /is deprecated, is not able to schedule
repeated jobs at a frequency of less than one day.
The command /jt /was offered by the Task Scheduler team, but it
is unsupported and awkward to use (it was intended for testing).
None of the three interfaces offers an easy way to replace the
/cron /service provided in Services
/syslog/, and a single configuration file is used
/syslog /to write statistical data of business interest (such as creation of a
/syslog /feature from the Interix subsystem, introducing the
/syslog/ in order to keep down the amount of source code
/rdist /mechanism can be used for configuration changes; if the change /rsh/ can be used. The key fact about UNIX that makes
current task schedule entirely.
The team met the need by running the
for UNIX. As described earlier, relying on Services for UNIX (or any
other package subject to extra license costs) provides a bad model for
other customer deployments. We have provided input to the Whistler
command line team for an improved interface to Task Scheduler.
Logging
There was a minor issue concerning the UNIX integrated logging feature
(/syslog/). The kernel, standard services, and application code can
write lines of text to
to determine the destination of the text lines. Thus an important alert
can result in a console message and email, while an informational
message can be written to a log file. The administrator can change the
destinations without code having to be recompiled.
An application like Hotmail often uses the application access to
new account or sending of an email message). Administrators can use
other tools to analyze the logs, archive them, or simply count
occurrences and throw the logs away. Typical usage is at the order of
one event per second; the high performance associated with the kernel
log is not required.
There are no features in Windows 2000 that provide the same combination
of convenience and configurability, although the kernel event log comes
close. For convenience, and also to avoid recoding, the team elected to
use the
issues about notional cost that have already been discussed.
Whistler introduces the Enterprise Event Log, a lightweight WMI feature,
which seems to provide the desired functionality. A closer examination
of the kernel logging may show that it too can meet the need, Any
replacement should involve trivial change to the existing application
code (perhaps even using a macro); it would be desirable not to have to
recode calls to
conversion.
Ad-hoc Maintenance
There are occasions when, after deployment, the administrators need to
make a configuration change consistently across the entire farm. The
is simple then
this work is, again, that all system administration tasks can be done
from the command line.
Windows should provide the same functionality, given some means of
aggregating a group of servers and some way of performing an operation
consistently across all the servers. Single commands, pipelines, or
scripts (command scripts or COM-based scripts) would be appropriate
actors; however, scripts need to be downloaded, executed (and, if
necessary, cleaned up). There should be the ability to defer the
activity until a specific time, presumably using the improved Task
Scheduler. In other words, Windows must support old-fashioned batch
processing.
One specific example of a feature that is not accessible to the batch
model is Network Interface Card customization; for example, there have
been requirements to change the card?s speed from 10 Mbps to 100Mbps (at
a specific time) or to change the MTU setting. The configuration model
of an Ethernet NIC varies between manufacturers, and the standard GUI is
driven by a schema that is found in the registry. Such a GUI is not at
all adaptable to the batch model. It is possible to make the required
changes to the registry, but that would require a subsequent reboot,
which is not acceptable. A brief period off the network, while the card
resets itself, is the most downtime that can be accepted.
The Hotmail team, with help from a network engineer, developed a
rudimentary application that would put a specific value in the registry
and (using an undocumented interface) reset the card in a way that will
make it pick up the new value. We strongly urge that the feature be put
into the shipping system.
95 percent of hits to an average website are from a version of IE, typically running on a version of Windows.
They're subject to market forces in the way that mountian is subject to the effects of gale force winds. Minor, barely measurable effects, that only theoretically could rise to the point of being an actual dander.
Converting the UNIX Administrator
Helping UNIX system administrators with the transition to Windows is an
experience in itself, and much was learned. Again, this is data from a
single corporate experience, but we suspect it is fairly typical. Here,
then, is the human engineering overview.
Initially, the plan to convert from FreeBSD to Windows was met with
responses ranging from skepticism to hostility, in a way that should be
familiar to those who share the attitudes of the various UNIX
communities to Microsoft software.
We engaged with the operations staff by asking them to define what their
everyday tasks are, in all areas of operating system and application
maintenance. Instead of a set of tasks, we were handed a set of the UNIX
commands and features that were used to carry out those tasks. While
this did not directly meet the need, it gave us an opportunity to
address all of the features directly, and show that Windows has an exact
equivalent in the core system, or in the Resource Kit, or easily
provided with a script. There were very few cases where no satisfactory
alternative could be found. Essentially, this was throwaway work, as the
eventual solution solved the problems in a more Windows-like way, but it
was an excellent opportunity to gain the confidence of the operations staff.
It was clear from the responses that some people from the UNIX side of
the house cannot distinguish our different systems that are marketed
under the Windows brand; there was an inbuilt assumption that Windows
2000 shares the features and faults of Windows 95. Those who were
somewhat familiar with Windows NT were not aware of the range of the
non-GUI offerings (to be fair, neither were we); the set of commands in
the product and the Resource Kit is fairly broad although, as we have
seen, there are gaps and they lack stylistic consistency.
Other staff members, not members of the regular operations team, carried
out the conversion. When deployment came near, the Operations staff had
to learn the new tools and paradigms. Their existence proved enough; the
main interest of Operations staff is, after all, to run and administer
the system, and once they found that there were tools, whether
custom-built or standard, that did the job well enough, they were able
to take control and gain a sense of ownership. Some standard one-day
courses were also given to the staff, to prepare them for handling
system debugging, hotfix application and so on. By this time, the staff
had become convinced that Windows is, after all, a real operating system
with surprising richness.
"all efforts to stop content swapping/theft - possibly even including Palladium - are in the long term futile"
Is is me, or did anyone else read this as "eat their own dogshit"?
Not too bright, are you?
According to Showstooper! by GZachary, The phrase was a favorite of David Cutler, the "mastermind" behind the creation of Windows NT. Not that this makes the paper more credible, but this "ridiculous analogy" has been in widespread use at Microsoft.
http://en.wikipedia.org/wiki/Signature_bloc
Nope, not the death penalty.
A special clause on page 394 of the enacting legislation says that anyone convicted of publishing Microsoft's dirty laundy is enjoined from using any other operating system for life. It's Microsoft only, baby!
Repeat offenders are enjoined from using any operating system other than Windows ME.
And for the hard-core cases... they bring out BOB.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
that upon opening http://www.microsoft.com/servers , read "Build and Deploy", as "Build and Destroy"?
The windows command line seems to be built as an emergency backup tool, for when it can't be done in a GUI for some reason. It is in no way intended for the system to be USED from the command line.
Modern unix shells however, are designed to be comfortable, and easy to use. (Easy as in, the lack of the amount of work required from a dos-style shell.)
The parent post is a Troll. The background of this story can be found all over the place:
4 81,00.html
1 121017417.htm
A Microsoft spokeswoman said the company has disabled downloads from the PSS Support server "to improve the privacy protections on the site."
http://www.wired.com/news/infostructure/0,1377,56
http://www.geek.com/news/geeknews/2002Nov/gee2002
Trusted Computing FAQ | Free Dawit Isaak!
Eat your own dogfood is a common, widely used term for companies using their own products. You should get out more.
Conclusions
/rsh /command, or pushing configuration files
These are the main lessons that we can extract from the Hotmail conversion.
1) We need a consistent, comprehensive, thoughtful approach to
integrated management of a set of servers. This does not necessarily
mean that we should slavishly follow the UNIX model of iterating through
a list of machines with an
to a list of machines. The fundamental goal is to be able to manage
machines as an aggregate; doing this through a GUI is not necessarily
evil, so long as it can be done remotely, and once. The point applies to
application distribution as well as to system tuning.
2) NLBS is at an economic disadvantage, due to its association with
Advanced Server, and Hotmail operations staff were sufficiently
satisfied with the existing solution that they did not feel the need to
investigate NLBS?s operational advantages.
3) The metabase needs to be ripped out and replaced with something
that is much easier for an administrator to see and understand, and be
confident that there are no hidden surprises. The IIS6 planners have
heard this opinion.
4) It should be easier to tune and lock down a single system, and
have the changes propagated to all systems in a given class.
5) Windows is too complex to understand at first, particularly
during a conversion from UNIX. There are just too many things about it
for a planner in a startup to understand. Typically there is little time
to attend training. The problem is most Computer Science graduates come
to their startups already understanding enough about UNIX to be
confident that they can use it effectively. We do need to be careful to
balance the complexity and transparency carefully.
6) The basic need for an Internet site, converting from UNIX to
Windows, is to be able to quickly replace their application and
operational methodology with something at least equally good.
Improvements that come for free are good, but implementing new
technologies and programming methods will need to take a back seat so
long as they delay the main purpose, which is to keep a site online and
competitive. Anything else is a cost that needs to bring a clear benefit.
OpenVMS will rise from the ashes and stomp out the Windows and un*x blasphemers! Mark my words!
http://en.wikipedia.org/wiki/Signature_bloc
What happened to www.wehavethewayout???? a campaign that was aimed against all unixes??
Best Quote:
;)
"Initially, the plan to convert from FreeBSD to Windows was met with responses ranging from skepticism to hostility"
I love that
HURD - Hurd's Under Research & Development
Nobody "stole private documents", hacked the server or anything like that. Best of all, it's Microsofts own marketing droids who posted these documents.
See this Wired article
Trusted Computing FAQ | Free Dawit Isaak!
(and not WINE, i'm talking something straight from MS, like OS X.x)
https://www.accountkiller.com/removal-requested
Wrong link in my parent post, here's the correct link to the Wired article: Microsoft Spills Customer Data.
Trusted Computing FAQ | Free Dawit Isaak!
while it's right there under your nose...
. ht ml#_ftnref3
take a look at the footnotes, yeah, the footnotes, especially the 3rd one.
http://www.securityoffice.net/mssecrets/hotmail
[3] For example, there was a need to reduce the MTU parameter of the TCP/IP interface. There was no command available to make the change, but the code in the network stack was easy to find, modify (one line) and rebuild.
And that, ladies and gentlemen, is the WHOLE fuckin' point in OpenSource, so casually admitted in a MS Engineering Doc.
i had a sig, once..
The Security Office is slashdoted, using the web archive people can read the whitepaper!
Many reasons why this is not technically accurate (the by microsoft part):
.net.
1. They think all their stuff is the best in the market.
2. They wouldn't dare say anything that might harm their profit margin.
3. Microsoft wants people to _move_ from unix to windows 2000 /
4. Microsoft wants to generate as much money as possible.
5. They never cited their sources for the whitepaper.
I interned at MS and that was the first place I heard about "eating your own dogfood" which does help to make a product better. But I've told this to many people and most have already heard of it from another non-MS company. Sounds like a rather common term, and it's not exactly a confidential phrase, anyone could "plant" it to make a document look more authentic.
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
At the beginning I liked Slashdot, but the continued agenda of most of the posters is to bash Microsoft and praise Linux. I bet on a normal day there could be 3 or 4 pro Linux articles and 1 or 2 articles about a new MS security hole, which is mostly likely true. Most of use probably use Microsoft or Linux products, we know enough of the shit. I come to read articles NOT related to my job. Now let's get bad to Slashdoting some poor basterds web site.
I am reminded of a time during my short term at Best Buy where I was demoing an eMachine with Windows XP for a customer. All of a sudden, the screen froze and there was no response from keyboard or mouse. Embarrassed, I quickly made up some excuse and went to Start -> "Turn off computer" to restart the machine.
The next words out of the customer's mouth were, "Oooh, I like how it fades."
Apparently, this customer was an ex-Millenium user who looked past computer lockups as commonplace, or perhaps they just really dig user interfaces and could care less about the fact that a new display computer is having problems locking up during a simple mouse meneuver.
Because most business don't run servers on a P133 with 24 MB of RAM. UNIX or MS. n00b
You have to keep in mind that this paper wasn't released today, it was in August of 2000. So it is safe to say that the research behind it was probably even earlier in 2000. I don't think it was that simple back then, it has certainly gotten much better. Given the fact that it used to be that there weren't *nix drivers for new hardware provided by the manufacturer, it would have been more difficult to set up a new PC with *nix. Now, things have changed, but there is still work to be done. Note the story right after this one on /. frontpage, where ATI released new Linux drivers. Also, not knowing what the article meant by "unix" could play into that decision - if speaking in general, then yes, generally it WAS a little more difficult to get these things working.
My beliefs do not require that you agree with them.
Since when are results like these shocking? The only shock here is that Microsoft would publish the whitepaper.
Regarding the much touted recent Windows 2000 Common Criteria Certification, see: Chapter 3 - Secure Configuration for this gem:
"Installation of applications conforming to Windows Installer-based package requirements will have difficulty installing from a CD-ROM on a computer running a Windows 2000 operating system in the Evaluated Configuration.
.Cap file directly from a CD-ROM.
"The reason is that the Windows Installer service is not a service that was evaluated and is therefore disabled in the Evaluated Configuration of Windows 2000. Additionally, the AllocateCDRoms Registry value that is set in the Evaluated Configuration will not allow Windows Installer to open a
"Therefore, to install an application conforming to Windows Installer-based package requirements, the Windows Installer service must be temporarily enabled and the "MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AllocateCDRoms" Registry value must be temporarily set to 0 (this can be accomplished through the Local Security Policy interface)."
So, in order to install any apps on your "secure" Win 2K box, you have to hack the registry and disable the protections that the very Windows 2000 Common Criteria Certification itself were set up to require!
And of course, the "secure" configuration has to have the floppy drive removed, or made inaccessible!
But hey! who's gonna install Office 2K from floppies, anyway?
What are these people smoking?
t_t_b
I'm on PJ's "enemies" list! Are you?
If I need to get a Product that is known to work on Linux and need to port it to Solaris, who do I go to?
Advanced support is one of the major downsides to *nix and one of the major advantages of MS. Trying to track down someone like this in the *nix world is next to impossible. At MS, it's a phone call away.
I don't use W2000/XP...
...but I've seen both blue screen while just sitting with no one even using the machine. I've seen Linux die twice in four years of heavy use and one of those was faulty hardware.
So you admit you're coming from a position of lack of knowledge. I respect your honesty.
Okay, here are my observations. I work at a site with several hundred NT4/W2K servers, and in general we don't have servers crash unless there's a critical hardware fault. We never see our W2K servers crash because of a Windows fault, and hardly ever see our NT4 servers crash. (Although I must admit W2K is much more stable than NT4.)
If we ever see a crash because of software, it's from a third-party vendor, and I can't remember the last time it crashed the OS. Many of our servers have uptimes of over a year. The vast majority (> 99%) of them just run. Period. This is in what is literally a 24x7x365 operation. These servers get hammered, constantly. There's less workload at 2am on Sundays, certainly -- but we don't have convenient windows for downtime, so we have to guarantee our servers will stay up.
Maybe, just maybe, it's because we know how to spend a few minutes making sure the things are set up properly, rather than just rushing in and expecting it to be magically bullet-proof? Do you remember the saying -- "A poor workman blames his tools"? We don't have that luxury -- if it doesn't work, we don't work -- so we just get to grips, accept we need to know what we're doing, and, gosh darn it, somehow manage to achieve the allegedly impossible. Robust Windows servers -- who would imagine?
I am confused by this. How are they backwards compatible? I can't upgrade Win98 to NT, or 2000, or XP. It is a fresh install. I *may* be able to run some of my old apps from Win98 to a newer MS OS, but that isn't guaranteed.
And where they are backwards compatible, it is only a liability because of HOW they implement things, with their closed "standards". If they were openly available formats and standards, then it would be much less of a liability. Their liability is in HOW they chose to be backwards compatible, or more correctly on how they chose to architect their system.
My beliefs do not require that you agree with them.
If what's inside is to be taken as facts, it's interesting to see that in a large scale environment:
-IIS management is not easy (due to the metabase, and reloading their custom ISAPI module required an additionnal layer to do it without iisreset)
-there's actually no equivalents for rdist, cron, syslog. They ported them to win32.
-they had to hack the net driver to change MTU on the fly
More important to me: they had an hard time figuring out stuff because of the lack of documentation and all undocumented interfaces. They even didn't suspected all the CLI facilities of Win2000 (nor do I).
So, W2K Server is powerful, yet it's setup in a bloated way making it difficult to manage. I wish some good papers would be written on the subject for all of us stuck with administring such boxes to benefit of other's experiences.
have you been defaced today?
because it informed us that people will leave IT jobs because they don't like the current buzzword/catch phrases thrown around?
Or because it informed us that you can write code in Word?
FYI, Powerpoint is a clone of Harvard Graphics
And Mod me up for telling you to mod parent up! ;)
Sdelat' Ameriku velikoy Snova!
Do you think they are leaking this kind of stuff just to mess with us?
So is Mandrake 9.0 (much better windows, but I have never tried XP).
Anything I left out I left out because I don't have personal experience using.
Sdelat' Ameriku velikoy Snova!
Scientists have dicovered there is intelligent life on planet Microsoft! Wait.... that would be Earth.
Mvh:
- Knut S.
Even eating your own dog food is not free. Microsoft itself has proven that.
.Net because it is designed to require the use of inferior Microsoft technology we still see those who think (or fail to think) that using Microsoft has merit.
.Net and the Microsoft OS itself both suffer from being single source products. That simply means that if you choose them your prices will go up. Microsoft has proven itself to be the kind of company that will raise prices even in tough economic times simply because it could care less about any customer.
And, today when we see the benefit of not using
If you will reflect back, Unix came into the market based upon the benefits of not being tied to a single vendor. It has not wiped out the proprietary solutions on larger systems but it sure has reduced their value.
Today,
Smart money avoids the Microsoft brand.
The company is run by idiots and liars.
Can you believe those idiots actually told the judge they think that icon removal corrects illegal acts related to commingling code? And, these idiots claim to be computer aware? They are just liars. (The subject white paper is a rare exception.)
NexuSys - Linux support by the best
That's just two people enjoying intimate moments between themselves in the privacy of their homes/cars/boats, where someone broke into their home and stole the video.
This is a company who does the equivalent of handing out free newspapers for everyone to read and accidently places confidential memos in them.
Microsoft might lose money off of their mistake, so we have to protect them from their own idiocy. As for Pam and Tommy - well, they oughtn't videotape their intimate moments and keep the tapes locked away in their house. That's just plain stupid.
We do not live in the 21st century. We live in the 20 second century.
It proves to be difficult to configure IIS in a precisely controlled way. The metabase is obscure and poorly documented, and produced too many surprises. Furthermore, a system created using sysprep does not produce a ready-to-run metabase... Figuring out the metabase structure, which elements needed to be set, and how to suppress the unwanted elements (for example, the trees defining the default and administration site) was the most complex and error-prone part of the entire setup design. Considerable reverse engineering was necessary. Major improvement is needed in the way the metabase is described to users, and the way that administrators can script the commonest tasks.
Microsoft's engineers can't figure out their own configuration files.
Well, I can agree with some of what is written,
:)
but can't agree wth some others.
I think it's easier on windows to figure out what service is running.
Well.. I know, I know. There are many not so important component for being a server on Windows.
As far as that kind of services, it's hard to figure out what are running on Windows, but with email servers, ftp server, web servers, etc... which you can find on service list, it's easy on Windows.
And.. 'Another strike against Windows is the GUI: "GUI operations are essentially impossible to script. With large numbers of servers, it is impractical to use the GUI to carry out installation tasks or regular maintenance tasks."'
Hmm... AppleScript?
Wow, that is amazing! It's a nice break from Sun and Oracle's "we are infallible" approach to software development.
Give me another hundred shares of MS please.
There is no real reason to break compatability over time.
... you will step in the manure and the beast will turn on you and illegally terminate your life)
You can argue that bad crap aught to be tossed. But that decision should and could be left up to the individual consumer anyway.
Why design Office XP so that it requires Windows XP? That is not inherit in application design. It is simply an effort by Microsoft to put some capability in the OS rather than the application so as to force the upgrade of both.
Of course that just adds to the high cost of doing business with Microsoft (Microsnort).
Smart money avoids all of the Microsoft brands. Why? Because in the end you will be screwed by them. Your products will be inferior. Your prices will be increased. And, your choice severly restricted.
Linux on the otherhand will begin to offer some really significant advangages.
1. illegal acts are not going to preclude superior technology from the marketplace
2. backward capatability will not be eliminated prematurely just to favor the sales of other technology
3. second and third sourcing will continue to give all customers the ability to control their own destiny, cost structures and the implementation of technology on a time frame best for them
4. highly innovative products can surface without being precluded illegally from the market (wake up you idiots that think that following the elephant through the forest is the only way to go
5. various vendors will be able to freely package together distributions for particular target markets eliminating the need to be screwed by the vendor simply because they want to dominate a market for a product you do not even need (forcing everyone to buy the inferior Microsoft Media player is just an example)
Are there a few more?
You bet.
And, direct on point with the white paper is the possibility that under Linux, if a GUI approach to system management actually is the better idea then that technology can surface and become dominant on its own time rather than be grammed down the throat of users like Microsoft has done.
Is there something wrong with a GUI? Maybe with your "GUI". But, maybe not with the technology that someone else may be able to put together. And, with Linux that is likely to occur. Who will do it does not matter. What is important is that it can be done and it will be done if possible.
Single vendor solutions are just that. A single solution. And if the industry has learned anything over the number of years in play, it is that no one can predetermine where the great ideas are going to come from.
Gates is an idiot for thinking that technology can be suppressed indefinately by illegal means. It simply can not. And, he is an idiot for thinking that consumers can be forced to eat the crap they decide upon. The white paper illustrates how stupid that is.
NexuSys - Linux support by the best
Outing a white paper not intended for public publication could be a trade secret violation.
But, I doubt that Microsoft will do anything but sweep this under the rug as quickly and efficiently as possible. Suing someone or making a big stink about it will only increase its dissemination.
NexuSys - Linux support by the best
The whitepaper sounds like a bunch of unix gurus who were forced to use Windows bitching because it isn't unix. Sure some of their point may be valid, but how much of it is due to inexperience with windows and the inability to accept change?
Vote for Pedro
It that is true, then the release was just not intended.
Too bad.
Once the "cat is out of the bag", the cat is out of the bag.
NexuSys - Linux support by the best
It's called "Innovation(TM)", dude.
cheers
``If a program can't rewrite its own code, what good is it?'' - Mel
...or you can just remove the binding to NetBIOS (aka File and Printer Sharing) from the network adapter itself. Problem solved.
I recall a profile of a guy during the 1996 election named Clinton Gore. He had a heckuva time making dinner reservations, because people simply wouldn't believe him.
My mom had a friend named Horny. He changed it after his father died.
Astonishingly, I do not see a web page yet dedicated to embarassing names. No, here's one (1000+ -- this must be where the Car Talk guys get their stuff). One study claimed that juvenile delinquents with embarassing names were in trouble four time more often.
Oh, I goofed on Chanda Lear's name. It is Chrystal Chanda Lear.
-- Natalie Clad
BSD is dead. Long live MacOSX and OpenBSD!
Congratulations on receiving Microsoft Chocolate(R) and Microsoft Hookers(R). By accepting these gifts, you agree to the conditions in the following End User License Agreement . . .
Damn it. I went to that link you posted, and what do I get? Two toy languages and one that isn't actively used yet, although may well be a good choice in a while.
How about having code for a few real languages, with some power and flexibility, if you are trying something like that?
Don't do people the disservice of teaching them bad habits, either. Please.
You defend Windows as if it were your lifeline, but tell me... How often do you actually walk into your server room, use the KVM switch to get to the proper server, administer the server in person while looking at a monitor? With a GUI, you almost need to do this.
A server is not something that you should not have a mouse or a keyboard hooked up to. It's a little box, in a darkened and protected room. It should NEVER go down. Ideally, it should never even be touched after the day it's installed.
The problem with GUI's is that you need to have a pretty fat pipe to administer the server remotely. You also need to use 3rd party tools like VNC (spawned on UNIX, of course) to do this with any chance of efficiency. The CLI for windows, as you state, is flexible and fit for doing maintenance of most tasks. With UNIX, I don't need a fricken GUI, I can do Everything from the command line.
Tell me, how often do you surf the web from your database or web server? You don't? Then why the hell do these servers have Internet Explorer installed on them? Not only is this a potential security risk, it's cruft... valuable space on the hard disk that could be used to store data that's actually meaningful.
You say that open ports on Windows servers should be taken care of by a firewall. Tell me, if Windows were secure, why would a firewall be necessary at all? If I had all of my *NIX servers exposed to the 'Net, with only the ports open that are necessary, I'm sure that those boxes would still be more secure than the Windows based counterpart. Besides, requiring a firewall is an extra expense, a lame excuse, and usually shooting yourself in the foot... Most decent-excellent FW's out there are Unix based.
The imaging servers / multicasting solution you speak of is the lazy man's solution. It is the state of programming society that has lost the interest in efficiency, because modern hardware can cover up inefficiency. The inefficiency still remains. This lazy way is not the kind of mindset that a forward looking, intelligent individual should have. So what if the right way is sometimes a little more difficult? Tell me, if everyone decided to start doing drugs, and you felt the social pressure... would you take the hard way, yet correct way, or the easy way? I work in a business environment, one where costs are limited by the wisdom of the management. We have to stretch our minds to keep things in budget, which has overlap into our practices in programming/administration. I value every bit of bandwidth that I can save. Sometimes we don't have fibre, sometimes we don't have 1000BT. Most times, we don't have the massive RAID arrays and ultra expensive hardware that MS can provide.
So tell me, can you say that Windows is a more efficient, effective, and secure platform than BSD, or any other UNIX?
Oh, and a *Nix can have just about everything turned off with exception of the kernel. I can load hardware drivers without rebooting, I can kill every process that isn't necessary. I can completely update my system without a reboot, yet every service pack I've encountered requires at least 1 reboot. I've run into situations where I couldn't "Stop" a service that was running on Win2k, but never with *nix.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
It looks like some idiot slashdot moderator missed your sarcasm :)
:)
They prolly could see through the "Buy more now. Buy. And be happy." statement
Mod this funny you drones!
(queue in the mod me flamebait)
Another example is using your own accounting software to maintain your own books.
Incidentally, doesn't MS use SAP for its books?
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
But it portrays, about as accurately as I've ever seen it, how systems are created to do one thing and end up doing something very different - and usually not something all that valuable.
The following is quoted (excerpted) from the back cover.
The dominant presentation tool was Harvard Graphics. It was used by EVERY business that needed a tool like that. Microsoft used it all the time.
Then they created PowerPoint. As typical of their strategy, version one and two we're worth wiping your butt with. A friend at MS was ORDERED to stop using HG and start using PowerPoint. He lost animation, audio, etc.
"PPT is a multimedia presentation tool without the burden of being multi or very useful" in his words.
How to get market share for this ? Hmmmm (/me strokes beard).
I know! Bundle it with Word and Excel, call it "Office" and make that the only way for businesses to buy it!
It was a two-fer. If you lived on WordPerfect and Excel, or Word and 1-2-3 or Quattro Pro, well, when you upgraded, you have both MS products. It's now a bad business idea to also go get WordPerfect or 1-2-3 (to be fair, Lotus never really upgraded 1-2-3 in a timely way and Quattro smoked it for $119).
Need a presentation tool? PowerPoint is Free! (no, your honor, it was fair competitive practices - we just gave customers the 3 tools and charged them for Word and Excel but we didn't make PowerPoint "free").
As it aged, it did become more useful. And bloated. And proprietary.
This is like saying that "I hate Chevys, they're just clones of Fords". Unless you come up with the Very First version of something, ALL competing products are going to be like yours ("clones", if you will). If Sony comes up with a new gadget that's popular, Toshiba and RCA will probably make something as similar as possible and sell it. That's how a market works. It's rediculous (and just damn whiny) to blame a company for recognizing the success of another company's product, and then making something similar to get a piece of that market.
Life is hard, and the world is cruel
quite possibly, and i'm not sure if its a good thing!
dybia felly dwi a hampster (i think therefore i am a hampster)
Uh, sorry, but this is just plain wrong. Microsoft took the code they had from OS/2 and made it into Windows NT.
Uh, sorry, but this is just plain wrong. NT is the product of VMS engineers bringing their talents and experience into a different product.
Ever wonder why the first release of Windows NT was called '3.1'?
No, actually. It was to avoid maturity confusion between NT and Windows 3.1. Releasing Windows NT as 1.0 would have made marketing less effective. Given it had the same UI as Windows 3.1 was another reason.
While your last paragraph is true, it hardly constitutes receiving a score of 5. Moderators need less crack.
Why bother.
People like you, who constantly quote past MS security holes, must also be constantly reminded that popular UNIX software is not without vulnerabilities. If you are expanding the scope to bugs that have been solved for years, I'd like to remind you that there are serious exploits for Apache, OpenSSH, bind, and sendmail. This selective memory that you zealots seem to have isn't getting us anywhere. There's plenty of valid ways to criticize Microsoft, but constant reminders of past exploits is not one of them.
The file limit (MAX_PATH) is 260, for the directory path and file name combined. An individual filename can be 257 characters long in a root directory, and 1 character long in a 259 character path
Well said!
If you need a GUI to administer a server - then you should'nt administer a server!
With *nix this is no problem, as it as always been ben run through the CLI.
Some years ago I was administering a few OS/2 servers. One of them was a combined web- and mailserver. Thankfully I could disable the loading of Presentation Manager (the GUI) in OS/2 so that only the to apps I needed got started. I saved a lot of resources by doing that and there was less processes that could possibly crash. The server ran on low end hardware but was rock solid.
Do not think that any experience from working in any Institutional environment maps to the 'real world'.
You can probably imagine the embaressment this caused the own once it was publicized that he used his competitor's dog food. Pretty much every introductory marketing class since has included a section on making sure that a business "eats its own dog food."
Windows NT 3.0 (not 3.1) still used the OS/2 API. But rather than being the primary system, it was used as a subsystem. NT 3.x retained an OS/2 1.0 compatible subsystem. Among other things, NT could use the HPFS file system that Microsoft created for OS/2.
All desktop machines are Intel based. Not a PowerPC chip in sight. Macs are banned.
How do you feel about the future of the PowerPC knowing that Motorola refuse to use it themselves?
Government of the people, by corporate executives, for corporate profits.
You're right that in 2000 Linux was harder to set up than Win2k (though the article really said 'Unix'),
but my feeling is that today Linux is *easier* to set up than WinXP.
Most hardware nowadays that was around in 2000 has to be tossed for the newer OS. It's been the other way around for Linux - more and more old hardware is supported under the newer Linux revisions.
You could study win2k a bit more before making such statements.
Go to your network card's TCP/IP properties, click the "Advanced" button, select the "Options" tab and edit the "TCP/IP filtering" option. You can then block every port except 80, 443, 21 or whatever you want. There is plenty of reading material covering this.
-h
Remember that Microsoft spent 4 Billion on R&D last year. 4 Billion. Plus this whole trustworthy computing crap session we have been going through since Feb. 02. Let me say that again. MS spent 4,000,000,000 on R&D. Instead of working on intelligent refrigerator magnets and tablet PCs you would think that they would really start concentrating on security.
Disclaimer: Windows is my lifeline. I'm paid to work on Windows machines. And to answer your question, I do it quite often if it's the most convenient way to get things done. Of course, I also have an admin workstation with MMC tools loaded, can telnet in, can run TightVNC, or Terminal Services for remote control, or can use a lot of tools (native Win2K + 3rd party) to administer from the CLI of my own box. Or, I can automate things via WSH using VBScript (my scripting language of choice) if it's something repetitive. Whichever suits me and the problem at hand at the moment and makes my life easier.
Not saying that UNIX is wrong in it's CLI, but saying that a GUI in Windows is not a good excuse for not being able to automate or run from the CLI if you want.
Servers DO go down, both UNIX and Windows. It's a cost of doing business. And you usually don't have to touch a Windows server after it's installed unless you want to change something. That's about the same as for UNIX, isn't it?
So, do you run *nix boxes on the internet without a firewall? I don't. I'd say it's pretty standard practice to put webservers of all kinds behind firewalls, so the paper pointing out open ports is a bit of a red herring.
When the "right way" takes more time, specialized skill, and effort, then it's the "more expensive way". And then you have to weigh the costs involved as well. A forward looking, intelligent individual uses the resources available to him to do the job in the most EFFICIENT manner. When hardware is cheaper than eeking out another .1% performance boost from recoding or optimizing, then throwing hardware at the problem is a viable solution. I can buy 512MB of RAM for less than what it costs for a client to pay me for 1 hour. If that solves the problem, then it makes more sense to buy the RAM. That's business.
Yeah, multicasting a 900MB image requires fiber and 1000BT. And huge terabyte SAN's of course. Right. And don't forget the massive supercomputer cluster to process that huge load. My god, it's almost 1.5 CD's worth! That's half of the RedHat download! (I know, RedHat includes more than just Linux, but it's quite feasible to download all 3 ISO's on a DSL line, so I don't think Gigabit Ethernet is required for a 900MB image).Umm...you can kill every process in Windows that isn't necessary too. That's why they're called unnecessary. Admittedly, if your only tool is the taskmanager then you're not a knowledgeable admin, so Windows will protect you from yourself...but I see that as a good thing.
Like a reboot is that big of a deal. It takes all of 5 minutes, and can even be scheduled. Let's get off the uptime high horse, eh? If you need 24/7 uptime, there's ways to get it, but be prepared to pay for it...both with *nix or Windows.
Like I said, you're probably not a Windows admin. I am, and have never run into a service I couldn't stop. There are some I shouldn't have stopped, but that's another story. =)
Bottom line is that both Windows (2000) and *nix are good operating systems. Well suited to almost any task required of a server. They both require knowledgeable admins to be used to their fullest potential, but Windows has the edge in ease of use. A semi-technical manager can have a Windows network up in an weekend...not so for *nix. Of course, the price the manager pays is that his server isn't really set up correctly, but that's what you get when a manager or low skilled admin sets up a server. Same thing as when I work on my car, I know it's not up to the same standards as a professional mechanic, but sometimes it's worth the tradeoff. Linux and FreeBSD have advantages in that they're free, highly configurable, and can run on old hardware. Strong selling points for some, not so for others. Everything involves tradeoffs.
A C++ compiler cannot call itself a C++ compiler if it only has half-ass support for a nearly 5 year old standard!
Which leaves us with the EDG compiler as the only acceptable option? If you're operating under the delusion that g++ meets ISO definitions, you're sadly mistaken. Nobody but EDG has even attempted to implement "export" yet, and g++ still has issues with complex templates.
VC++ 7 is getting better, and the 7.1 beta is supposed to be quite good
I don't know anything about MS compilers except what I read on comp.std.c++ and in the C/C++ Users Journal, but the same thing is true of g++: 3.x is getting better (2.x was really pathetic in terms of C++ standards compliance), but is not there yet. Interestingly, I gather that MS has the lead in library comformance (they get their libraries from P.J. Plauger's company, Dinkumware, rather than attempting to write their own, which probably explains this oddness), but g++ has the lead in compiler conformance. However, both still fall short in their support for this "nearly 5 year old standard".
64.4.14.24
64.4.16.24
You, oh great genius, will notice something strange. It seems that FreeBSD IS being used.
Due diligence.
Thats what it takes.
fudpucker
Like a reboot is that big of a deal. It takes all of 5 minutes, and can even be scheduled. Let's get off the uptime high horse, eh? If you need 24/7 uptime, there's ways to get it, but be prepared to pay for it...both with *nix or Windows.
Evidentally you haven't rebooted a system with a RAID array before, then... takes longer than that.
Besides, the ONLY times I have ever had to reboot a Solaris server was between tcp parameter changes (scheduled during a change to be totally sure the init scripts work properly), a bad simm chip (nice Sun fiasco back then), and when a massive power outage hit my old jobs main campus, taking out the NFS servers. (for some reason, they wouldn't respond afterwards even though the shares were there, and it was one of the important partitions)
Rebooting is never NECESSARY, barring hardware environmental, or kernel upgrade issues. That's the mentality that got us to where we are today. Everyone thinks that rebooting is alright, but back them into a corner where there is a deadline to meet and they have to reboot continously... see what happens.
It doesn't cost any more to have a reliable operating system. That's the key right there...
Sure, Win2K is a great step in the right direction. It doesn't exactly have the power and flexibility of Unix (think server, not desktop), but it's definately starting to achieve more stability. I still wouldn't trust it in my organization if I was a head-admin,however.
The price difference, along with proprietary lockins, and issues that spring up out of thin air with Microsoft kicking and screaming the whole time while they are forced to fix it, makes me wary.
That, and I don't put toys in the server room.
-- This space for lease, low setup fee, inquire within!
With altiris image blaster I was unable to get my images small enough to fit on a cd for w2k and certainly not for xp.
Microsoft is using FreeBSD. Check it out on netcraft
netcraft.com tells me that Microsoft is still using FreeBSD. The truth? Ya gotta dig.
I tried to shut off all extraneous services with XP I killed the system. I couldn't log out. I couldn't go back in to services and turn things back on. The system would not let me back in. I turned the machine off. I was unable to login. I rebooted again. I slipped my openbsd cd in and breathed a sigh of relief.
The problem occurs when the strategic people (who are higher up in the company and therefore assume they know more) start dictating to the tactical people design decisions or not listening to the tactical people when they say it will take x amount of time.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
I am not using MS products in my day to day life and work not using MS products . I work at a large corporation . I use Linux and Openoffice. We develope serveral J2EE apps for our corporation.
I am sure u all can live with our windoze if you try.
thats my 2 cents
Comment removed based on user account deletion
I'm glad to hear that M$ has some sense. My wife and a good friend still use Hotmail. In the last year or so, the service has been degraded and I worried that it would become useless. They limited mailbox size and the service slowed down considerably. The obvious ineficiency of Windows must have been costing them a fortune. It's great that they have enough brains to put BSD back in charge. I hope they were able to locate the previous knowlegeble operators to guide the hoards of GUI button pressing folks that must have been required. Now I know, that no matter how dishonest M$ is, that they have the brains to save themselves a buck and will always be able to provide Hotmail to all my friends who's ISP won't let them run a real mailserver. Rejoice in the practicality of a liar.
Can you tell me just how they fixed any of their wonderful server "products"? Have they made it easier to tell what processes are required for a given task? Have they included secure shells for remote scriptable administration? Have they reduced the footprint from 900MB to some tens of MB? Or is this just Alpo with tap water added to simulate a saucy steak?
Yer living off dog food. It makes you shiny and clever too.
Friends don't help friends install M$ junk.
It's an old paper. We might assume the author was fired long ago. After all, who needs talent when you think you can just extort and lie? A guy like that is about as much use to Microsoft as BSD was. Honest people don't last long in a place like that nor should they want to work there.
The level of duplicity is shocking. They obviously care nothing for effeciency, even their own and are willing to take anyone who trusts them down with them. They know that what they promote is vastly inferior and impractical, yet such is their love of money and power that they would inflict it on everyone everywhere. This proves that Microsoft will never care. They will never improve, inovate or make anything useful. Never trust dishonest people because they are insane. Those that deny the truth are bound to be crushed by it. No one trusts a liar and everyone remembers what you say.
Friends don't help friends install M$ junk.
Comment removed based on user account deletion
That's what safe mode is for. All services are disabled in safe mode - no matter how badly I've treated the services list during experimentation, safe mode has always let me back in to correct things.
There's also the recovery console if you know what you're doing.
-h
On the other hand, csc.exe, the C# compiler, was itself written in C#.
Patents can be a problem.
However, a vast number of the software patents are simply not enforceable.
Of course, you need the money to challenge them. And, if you do not, you may find that you have to leave the game early simply due to a shortage of funds for lawyers.
But, Lindows has shown that you can take on the big boys and win. Microsoft is on the verge of losing its "Windows" trademark. That will most likely occur.
And if you are facing a software patent suit, I do suggest you strongly consider contesting it. There is a fundamental requirement that a patent application list all prior art related to the patent application. Few if any software patent applications did that. And, while some truly new and innovative work may have occured and been the subject of a patent application, most software patents can be challanged simply on the basis of the application failing to disclose other known work.
Even if the earlier work was in fact not known by the patent holder, proof that similar work pre-existed the development can also invalidate it.
Patents are not worth much unless they truly added to the technology. Many of the software patents simply do not. It is not enough to simply have the earliest application. The patent also needs to not be the obvious solution to the problem. And, if someone already solved that problem in a similar way, the patent may not be validated.
NexuSys - Linux support by the best
Trade secrets are only secrets as long as they are secret.
That may read a bit strange but it is true. Once the "cat is out of the bag", the cat is out of the bag (and no longer in the bag).
And, yes, your point is well taken. If someone posted the document on a public web site, that material is no longer secret, right? And, if it is no longer secret, it is no longer a trade secret.
Someone may get sued for it. But, that someone would be a Microsoft employee who either did it deliberately or by mistake. It matters not. Out is out.
NexuSys - Linux support by the best
Seriously, you didn't, did you?
Not Buzzword 2.0 compliant. Please speak english.
Not so.
... [or] learn about a trade secret by accident or mistake, but had reason to know that the information was a protected trade secret." This includes journalists, if they know or ought to know that they're getting an illegal leak. (I was surprised by this, too, given the First A. and all.)
It is equally prohibited (even criminal in some cases) to pass on what you know to be a trade secret if among other circumstances you "acquire a trade secret through improper means such as theft, industrial espionage or bribery [or] knowingly obtain trade secrets from people who have no right to disclose them
Nolo.com FAQ
Of course you have to ask what the customer needs to do.
But, that simply illustrates that "one size fits all" fails to fit anyone.
That does not mean that the kernel must be different for each customer. And, it does not even mean that the kernel must be subject to modification as is the case with open source software.
But, what it does point out is that bundling crap with the OS is always a bad idea.
1. bundling increases the cost for everyone
2. bundling suppresses advanced technology by eliminating fair and open markets
The result is harm to the industry and consumers.
As for the change in "threads", I doubt that threads have anything to do with the new features in Office XP. More likely than not any additions to Office XP could be completely contained in the application itself.
Gosh, if OpenOffice/StarOffice, Mozilla and others can run on Linux, Microsoft Windows, Unix, the Mac and others then the idea that the OS must be custom to permit the application to run is just silly.
Requiring the OS to be upgraded harms consumers directly by greatly increasing their costs to benefit from new applications. And, that additional cost should be avoided if at all possible.
Of course, Microsoft could care less about saving customers money and is only interested in forcing customers to upgrade so that the bundled applications are more pervasive. And, collecting more money from the fools, of course.
NexuSys - Linux support by the best
All inventions (or nearly all) tend to be modifications of previous technology.
First pc was the altair. Damn IBM, Compaq, HP et al. for ripping them off!
I guess the model T was a rip off of trains and carriages.
Planes are a rip off of birds...etc.
--Joey
It's NetBIOS (LanManager, if you like)
Old-school networking, using it's own protocol.
And in the pre-IP days, if all you had was a bunch of computers and some ethernet cards, it's all you needed, and easier to set up to boot (no setup involved)
And it has less overhead that NetBIOS over TCP, if you want to get really technical.
Netscape failed for one reason only.
400 million were forced to buy, install, support and use IE.
Period.
Every other reason is pure garbage because when all possible consumers are forced to buy IE first, install IE first, support IE first and regardless and in fact use IE no other product has a chance in hell of being successful.
You can lie all you want about what Netscape did or did not do.
But, no company ever wants to be in a situation where almost all of your potential customers are first required to buy, install, support and use a competitors product.
If the company you work for competes in that environment then you can talk. Otherwise you are just lying when you say that you can sell anything to anybody when they already have been forced to buy your competitors product.
End of story.
General Motors would go bankrupt in a year if all of their potential customers were first required to buy a FORD, right? Each and every time they buy a car?
NexuSys - Linux support by the best
IE is a forced sale product.
It is bundled with the Microsoft OS so that YOU are forced to buy it, install it, maintain it, support it and use it.
If idiots want to continue to fool themselves by claim that being raped is free sex, then fine.
But, with the sole exception of the very first version of Win95 all Microsoft customers have been forced to buy it.
Yet, some incrediably stupid people still think it was free.
YOU paid cash money in exchange for it.
That means that the copy you bought for cash was NOT free. It was paid for. And, you were forced to pay for it.
NexuSys - Linux support by the best
In the past, when I've got a "thumb up my butt" type
job where I'm basically sitting watching servers
that hardly ever die, I'll sit and extrapolated and
expound on the details with someone. On the other
hand, when I've been the lead developer on something
huge, they are paying me enough to own every minute
of my life and they know it, I'm more inclined to
take 5 minutes to SHOW the pesky junior admin HOW
to use a search engine logically to find the answers
to things. I'll also promote the idea of sharing
good sources for information on departmental
mailing lists. It's truly awesome when you can
say "hmmm, bob had the same problem I'm having
three weeks ago and shot mail to the list. Lets
see if I have that.........."
The most important thing any republican needs to know.