Do you think that realistically, Microsoft could not release a patch for this in the 7 day timeframe of the original auction?
Are you kidding? Of course not. Excel is used by MILLIONS of people and the testing that needs to go into any kind of patch takes a weeee bit longer than 7 days.
In addition, we have no idea of the implementation details of the patch. Perhaps the offending code actually lives in a system library. This further adds to the time it takes to implement and test a patch.
This guy put the exploit on eBay for purely egotistical reasons... and perhaps some greed. It had nothing to due with holding Microsoft accountable, and even if it did it would be questionable at best.
Ah, interesting. So information can be supressed as long as all parties that are privy to the information agree to keep that information secret.
I disagree with your conclusions, but I now understand your distinction.
I think that the world is a better place because some information is kept secret. I don't view this as a "slipery slope" because I don't view it as an all or nothing question.
Why is this a kludge? Seems like a perfectly valid tactic.
Often times programmers will isolate particularly dangerous code inside specific class libraries. This take it one step further and isolates that code in a seperate process, there by allowing IE to be run as a low-privs user.
How would you suggest implementing a "general mechanism"? Code Access Security in.NET allows for code to be run within a security context seperate from the user's credentials, but this is in the managed world only. Aside from re-writing IE in managed code, I don't see any backwards compatible way of doing this.
Remember, many thousands of applications depend on IE. Microsoft can't just wipe the slate clean without breaking a lot of code.
As far as security holes appearing in the broker, of course that's possible... but it's far less likely. It is much easier to audit a 5000 line program than a 500,000 line program.
In fact, that right has already been upheld and Esquire (IIRC) published an article that describes how to make a nuclear weapon.
Do you have links?
In the second case, you're talking about classified material that only those with clearances who agreed not to disclose it would be privy to
Isn't that somewhat circular logic? It's OK to supress information that's classified, but only because it's classified as top secret by the government? Why is it top secret? Isn't that the reason it's classified?
I find it ironic that someone with the name "think freely" would argue in favor of suppression of information.
My name is meant to convey my skeptical outlook on life. I don't tend to think it sweeping generalisms like "all information needs to be free".
What is the difference? Both are pieces of information that would allow you to gain entry to the person's home.
Perhaps you saw the person type in that security code. If you saw them type it in, is there not a chance that somebody else did as well? Perhaps the owner of the home doesn't take his system seriously enough and occasionally tells people his code.
By releasing this information, and making sure you know he released it, he will be more likely to change that security code... in the same way the maker of the security system would be more likely to fix the problem.
Seems to me your distinction is somewhat arbitary.
So is it OK for me to provide a detailed description of how to make a suitcase nuclear weapon, including people to contact to get the materials used in its production? How about the nuclear launch codes and how to use them? How about some top secret security codes used for encryption of data regarding national security? How about the security codes to your house alarm?
Supression of information is a necessary fact of life in a world where information can be used to harm others.
This does not justify supression of any information a goverment feels like supressing. Each case must be examined carefully, but to say that there is never a justifiable reason to supress information is dangerous and clearly at odds with reality.
The original Pentium at 200 MHz can easily handle a 100Mbit Ethernet connection with the right software.
Ya, it's called Windows 95. Or Linux. Or NT. Or XP for that matter. What's your point?
The original Pentium at 66 MHz can handle one million database transactions per second, with the right software.
That's a pretty silly statement. What software would that be.
The tcp/ip stack on FreeBSD 4.x, slightly modified to manage connections on a per port basis, can handle over one million connections per second on the original Pentium at 200 MHz.
Interesting. There are a max of 64,000 ports. That would mean each port would need to handle over 15,000 connections per second. What useful thing could be done with so little time to do it? The memory resource required alone would almost certainly be more than any PII motherboard could hold. Even if each connection only consumed 1Kb of memory, it would take about a GIG of ram just for the connections.
It seems like you do not have any experience with real high load software. Your setup is overkill for anything other than something developed on the Microsoft Windows platform.
It seems like you enjoy making up stuff and then making judgements about other people's experience which you are clearly not qualified to make.
We have done testing to confirm this, and in fact we had a NIC failure in one machine which resulted in the failover of all traffic to a single machine right at the beginning of our normal peak load times.
The result? That second machine hovered around 75% to 80% CPU for the hour or so it took us to replace the NIC in the first machine.
IE 7 on Vista will run in sandbox that isn't really like anything out there today. (That I know of, anyway.) Even if you're an admin user, IE 7 is contained in such a way that it is not able to access anything outside of its sandbox without explicit permission.
This helps even when non-admins are running IE 7 because it doesn't just prevent system changes (like adding a program to the startup folder), it also prevents changes to anything outside of the sandbox... including files that the non-admin user has full access to.
They accomplish this by using the concept of a broker which IE 7 has to ask to do pretty much anything to the local system, independant of the privledges of the user running the browser. Want to save a file to your desktop? IE 7 must first ask the broker for permission. When the broker gets this request it then asks the user using a dialog. If the user approves, the broker then gets the appropriate information from IE 7 and saves the file for IE 7. At no point does the IE 7 process have access to the desktop or any of the users files.
The net effect is isolating all dangerous code in the broker, which is far simpler and easier to audit and debug than IE 7, thereby decreasing the attack surface dramatically.
For a detailed description of all this, check out the channel 9 video about it.
20,000 hits a minute doing what? I've created.NET sites that handled about 60 million hits a day (advertising related), with peak traffic doing 5000 requests a second. (That would be 300,000 requests a minute.)
All this traffic was handled by two Dell servers which cost about $5000 a piece. (1.5GB of ram, 10k RPM SCSI RAID, dual 2.8 Ghz CPUs.) Neither machine ever went above 40% CPU, which means a single machine could have handled all the traffic. During peak times, we were fully utilizing a 100Mb pipe.
Each request typically did some MSMQ operations and the occasional SQL Server DB hit if there was a cache miss, but most of it was served via the kernel mode HTTP listener and a few custom HTTP Handlers written in C#/ASP.NET.
It all depends on what each hit is doing. If each request takes 1 second to complete there is no way you could do 20,000 hits per minute unless you had a large web farm. In our case, our TTFB (time to first byte) was very, very small..NET performed extremely well, as did IIS 6.0 on Win2k3 Server. Very reliable too... never had downtime thanks to NLB..NET is a fully capable platform. If the.NET application is written correctly, it can handle just as much load as a custom ATL-based application, which is typically regarded as the best performing platform. And trust me, writing an ATL app is painful for all but the best C++ developers.
I know of a few bugs in v1.0 of the framework, nothing too serious... mostly stupid stuff (like a property being protected when it should have been public and is therefore inaccessible to anybody using the framework), but the documentation has always been stellar.
That's one that Microsoft does better than pretty much everybody. MSDN is an incredibly good resource. For the most part, it always has been. Can you provide examples of crappy documentation in v1.0 or v1.1 of the framework? Again, I'm aware of a few isolated areas, but they were few and far between.
AJAX is a baby step on the march back to rich clients.
Web apps are great because of their ease of deployment. There is no "upgrade cycle" for users. They just refresh the page and they get the latest and greatest.
Rich client apps are great because of the ability to have a rich UI and far more control over the presentation of your application. Speed is almost always better. You can just do more.
AJAX is an attempt to merge the two. Sometimes it works very well, sometimes not. But it's just a stop-gap solution that tries to use existing web technology to mimic the experience users know and love from rich client apps.
The real solution to this problem is to allow for rich client apps to have the ease of deployment of web apps. There are a few possibilities in this area.
One solution is Microsoft click-once deployment paradigm in.NET 2.0, although it has its limitations as well. (Windows-only being a big one.) It looks as though Windows Vista is going to try and blur the line between Windows and the Web as much as possible, making rich client applications created with WPF (Avalon) fully hostable inside the web browser. (With code access security restrictions, of course.)
Of course, this has the same problems as most.NET solutions at this point... it's Windows only. One of the great thing about web apps is that they run pretty much anywhere. I suspect that many companies will say that 90% market coverage is good enough for the benefit of web-deployed rich client apps.
Does anybody know of similar projects coming down the pipe that will offer this to more than Windows clients? Something other than people implementing WPF and the.NET Framework on other platforms? I know about WPF/E (Windows Presentation Foundation Everywhere), which is a subset of WPF that Microsoft is trying to make cross-platform, but what about non-Microsoft solutions?
Stocks are not physical things either. They are limited in supply arbitrarily. When the price of a particular stock becomes high the company will often split their stock one or more times to make it available to more people at a lower price. Existing share holders have the same dollar value in stock but with double (or whatever) the shares. Outstanding shares simply double in quantity and half in value, or whatever the case may be.
Downloads wouldn't have the same arbitrary limitation on the maximum number of downloads available, of course, but the basic principals are the same.
The value of the stock is obviously based on demand, but initially based on the financials of the company. Similarly, the value of a music download would initially be based on the perceived popularity of the song in question. Over time, this value would fluctuate in much the same way a stock does. Not because of scarcity, but because of popularity... the same way a stock's price soars not because the company is all of a sudden doing better, or because the stock has become more rare, but because people desire the stock more.
It's not exactly the same, though. It is possible for all shareholders of a company to hold the stock regardless of the offering price. This would simulate a lack of supply. In the downloads world, I don't expect iTunes would refuse to sell a song regardless of the price people were willing to pay.
THe original poster said he had to restard IIS in order to get it to handle requests again. In other words, it hadn't crashed... he was doing an IISRESET which restarts the running process.
I don't think I've ever seen IIS actually crash... aside from buffer overflows being exploited back in the day by worms.
I post mostly Microsoft stories to Slashdot in an attempt to even things out a little. There aren't a whole lot of balanced articles on this site, and the forums are certainly skewed.
Actually, it's just proof you didn't watch the video.
Re:Recycling processes is normal for windows
on
Debugging Microsoft.com
·
· Score: 4, Insightful
But Apache never crashed (and this was on a comparatively memory-poor box by today's standards - 256 meg), just took a second or two... and nobody else connected to the box complained.
Apache, like IIS, has a finite number of threads it uses to handle incoming requests. If you use up all those threads, Apache, and IIS, can't respond. You either must increase the number of threads or users will be denied access to the site. Eventually, you run out of system resources. In either case, you've prevent one (or likely a lot more) request from being fulfilled by the web server. End of story.
Your example is a foolish one. You never caused Apache to run out of resources. If you had, it would have "crashed" as the originally posted meant it... it couldn't handle further requests. That wasn't because Apache is superior in some way to IIS, it's because your clicking didn't use up all the threads. Simple as that. That's what I was explaining... the same thing can happen to Apache as can happen to IIS. Just because Apache is open source doesn't make it invulnerable to resource exhaustion due to inept programmers.
No, its Windows that pretty much has no credibility. The one thing it DOES have that nobody else has is the widest selection of trojans, viruses, worms, and idiot users.
That and the majority of the fortune 500 companies running on it. Windows is a fully capable server platform, and there are countless examples to back that up... just as there are countless examples that show that Linux can be a capable server platform. My point was that IIS is not inherently flawed as the original poster suggested. In fact, IIS 6.0 is in my opinion the best web application server on the market if cost is not an issue. (Windows licenses can be too expensive for a small company.) It's had extremely few security holes (FAR fewer than Apache has in the same timeframe), it's very fast (thanks to advanced features like kernel mode listeners), it's extremely reliable thanks to application isolation, process recycling, and great management and monitoring tools, and it's host to many excellent development platforms from PHP to ASP.NET.
IIS 7.0 is shaping up to be even better with some great ways to customize the web server to make it as bare metal as possible if that's what you want.... taking a hint from Apache in this case.
But for you to sit there and question the intelligence of somebody who uses Windows as a server platform shows your ignorance. It shows you don't bother to really examine alternatives to what you're comfortable with. When choosing a platform for a project I make sure to consider as many things as possible... from portability requirements, to intellectual property issues, to performance, to cost, to ease of development. That's my job as a software architect. Sometimes I choose LAMP for its very low initial cost. (Basically free.) Sometimes I pick ASP.NET because of how robust the.NET framework is and how much bang for my buck I can get out of ASP.NET on IIS. Sometimes I pick Java for those rare cases one needs a server application to be portable.
Regardless, there are lots of options out there and until you're able to pick the best one for the job at hand you're just going to be limiting yourself for no good reason. Both career wise and intellectually.
I agree that no modern OS runs a 30 year old stack... but most modern OS's today still have major issues with high latency connections even when those pipes have plenty of bandwidth. There is nothing we can do about a 100ms latency when the connection is 5000 miles long, but there is a lot we can do to improve the TCP protocol to optimize for those long distance/high bandwidth connections that are becoming more and more common.
The problem was connecting two datacenters that were physically seperated by a long distance but connected with a high bandwidth pipe... the TCP protocol has problems with this because of latency issues.
Slashdot Mirror
Wow, did you totally miss the point.
Do you think that realistically, Microsoft could not release a patch for this in the 7 day timeframe of the original auction?
Are you kidding? Of course not. Excel is used by MILLIONS of people and the testing that needs to go into any kind of patch takes a weeee bit longer than 7 days.
In addition, we have no idea of the implementation details of the patch. Perhaps the offending code actually lives in a system library. This further adds to the time it takes to implement and test a patch.
This guy put the exploit on eBay for purely egotistical reasons... and perhaps some greed. It had nothing to due with holding Microsoft accountable, and even if it did it would be questionable at best.
So information can be surpressed if it only affects a small number of people? How small? 1 person is OK, but is 2? 10? 100?
Another arbitrary distinction.
Ah, interesting. So information can be supressed as long as all parties that are privy to the information agree to keep that information secret.
I disagree with your conclusions, but I now understand your distinction.
I think that the world is a better place because some information is kept secret. I don't view this as a "slipery slope" because I don't view it as an all or nothing question.
Why is this a kludge? Seems like a perfectly valid tactic.
.NET allows for code to be run within a security context seperate from the user's credentials, but this is in the managed world only. Aside from re-writing IE in managed code, I don't see any backwards compatible way of doing this.
Often times programmers will isolate particularly dangerous code inside specific class libraries. This take it one step further and isolates that code in a seperate process, there by allowing IE to be run as a low-privs user.
How would you suggest implementing a "general mechanism"? Code Access Security in
Remember, many thousands of applications depend on IE. Microsoft can't just wipe the slate clean without breaking a lot of code.
As far as security holes appearing in the broker, of course that's possible... but it's far less likely. It is much easier to audit a 5000 line program than a 500,000 line program.
How does that make any difference regarding the supression of the information? Why does it matter whose "fault" it is?
If your security code is public knowledge, are you not more likely to change it?
It's an arbitary distinction.
In fact, that right has already been upheld and Esquire (IIRC) published an article that describes how to make a nuclear weapon.
Do you have links?
In the second case, you're talking about classified material that only those with clearances who agreed not to disclose it would be privy to
Isn't that somewhat circular logic? It's OK to supress information that's classified, but only because it's classified as top secret by the government? Why is it top secret? Isn't that the reason it's classified?
I find it ironic that someone with the name "think freely" would argue in favor of suppression of information.
My name is meant to convey my skeptical outlook on life. I don't tend to think it sweeping generalisms like "all information needs to be free".
What is the difference? Both are pieces of information that would allow you to gain entry to the person's home.
Perhaps you saw the person type in that security code. If you saw them type it in, is there not a chance that somebody else did as well? Perhaps the owner of the home doesn't take his system seriously enough and occasionally tells people his code.
By releasing this information, and making sure you know he released it, he will be more likely to change that security code... in the same way the maker of the security system would be more likely to fix the problem.
Seems to me your distinction is somewhat arbitary.
The two I trust:
PriceWatch.com
ResellerRatings.com
So is it OK for me to provide a detailed description of how to make a suitcase nuclear weapon, including people to contact to get the materials used in its production? How about the nuclear launch codes and how to use them? How about some top secret security codes used for encryption of data regarding national security? How about the security codes to your house alarm?
Supression of information is a necessary fact of life in a world where information can be used to harm others.
This does not justify supression of any information a goverment feels like supressing. Each case must be examined carefully, but to say that there is never a justifiable reason to supress information is dangerous and clearly at odds with reality.
The original Pentium at 200 MHz can easily handle a 100Mbit Ethernet connection with the right software.
Ya, it's called Windows 95. Or Linux. Or NT. Or XP for that matter. What's your point?
The original Pentium at 66 MHz can handle one million database transactions per second, with the right software.
That's a pretty silly statement. What software would that be.
The tcp/ip stack on FreeBSD 4.x, slightly modified to manage connections on a per port basis, can handle over one million connections per second on the original Pentium at 200 MHz.
Interesting. There are a max of 64,000 ports. That would mean each port would need to handle over 15,000 connections per second. What useful thing could be done with so little time to do it? The memory resource required alone would almost certainly be more than any PII motherboard could hold. Even if each connection only consumed 1Kb of memory, it would take about a GIG of ram just for the connections.
It seems like you do not have any experience with real high load software. Your setup is overkill for anything other than something developed on the Microsoft Windows platform.
It seems like you enjoy making up stuff and then making judgements about other people's experience which you are clearly not qualified to make.
Microsoft software is always poorly design.
Why am I even replying to this... never mind.
Why would that be scary?
We have done testing to confirm this, and in fact we had a NIC failure in one machine which resulted in the failover of all traffic to a single machine right at the beginning of our normal peak load times.
The result? That second machine hovered around 75% to 80% CPU for the hour or so it took us to replace the NIC in the first machine.
IE 7 on Vista will run in sandbox that isn't really like anything out there today. (That I know of, anyway.) Even if you're an admin user, IE 7 is contained in such a way that it is not able to access anything outside of its sandbox without explicit permission.
This helps even when non-admins are running IE 7 because it doesn't just prevent system changes (like adding a program to the startup folder), it also prevents changes to anything outside of the sandbox... including files that the non-admin user has full access to.
They accomplish this by using the concept of a broker which IE 7 has to ask to do pretty much anything to the local system, independant of the privledges of the user running the browser. Want to save a file to your desktop? IE 7 must first ask the broker for permission. When the broker gets this request it then asks the user using a dialog. If the user approves, the broker then gets the appropriate information from IE 7 and saves the file for IE 7. At no point does the IE 7 process have access to the desktop or any of the users files.
The net effect is isolating all dangerous code in the broker, which is far simpler and easier to audit and debug than IE 7, thereby decreasing the attack surface dramatically.
For a detailed description of all this, check out the channel 9 video about it.
20,000 hits a minute doing what? I've created .NET sites that handled about 60 million hits a day (advertising related), with peak traffic doing 5000 requests a second. (That would be 300,000 requests a minute.)
.NET performed extremely well, as did IIS 6.0 on Win2k3 Server. Very reliable too... never had downtime thanks to NLB. .NET is a fully capable platform. If the .NET application is written correctly, it can handle just as much load as a custom ATL-based application, which is typically regarded as the best performing platform. And trust me, writing an ATL app is painful for all but the best C++ developers.
All this traffic was handled by two Dell servers which cost about $5000 a piece. (1.5GB of ram, 10k RPM SCSI RAID, dual 2.8 Ghz CPUs.) Neither machine ever went above 40% CPU, which means a single machine could have handled all the traffic. During peak times, we were fully utilizing a 100Mb pipe.
Each request typically did some MSMQ operations and the occasional SQL Server DB hit if there was a cache miss, but most of it was served via the kernel mode HTTP listener and a few custom HTTP Handlers written in C#/ASP.NET.
It all depends on what each hit is doing. If each request takes 1 second to complete there is no way you could do 20,000 hits per minute unless you had a large web farm. In our case, our TTFB (time to first byte) was very, very small.
I know of a few bugs in v1.0 of the framework, nothing too serious... mostly stupid stuff (like a property being protected when it should have been public and is therefore inaccessible to anybody using the framework), but the documentation has always been stellar.
That's one that Microsoft does better than pretty much everybody. MSDN is an incredibly good resource. For the most part, it always has been. Can you provide examples of crappy documentation in v1.0 or v1.1 of the framework? Again, I'm aware of a few isolated areas, but they were few and far between.
Ah yes, I remember reading about XUL and how it compares to XAML.
There have also be news stories about it.
AJAX is a baby step on the march back to rich clients.
.NET 2.0, although it has its limitations as well. (Windows-only being a big one.) It looks as though Windows Vista is going to try and blur the line between Windows and the Web as much as possible, making rich client applications created with WPF (Avalon) fully hostable inside the web browser. (With code access security restrictions, of course.)
.NET solutions at this point... it's Windows only. One of the great thing about web apps is that they run pretty much anywhere. I suspect that many companies will say that 90% market coverage is good enough for the benefit of web-deployed rich client apps.
.NET Framework on other platforms? I know about WPF/E (Windows Presentation Foundation Everywhere), which is a subset of WPF that Microsoft is trying to make cross-platform, but what about non-Microsoft solutions?
Web apps are great because of their ease of deployment. There is no "upgrade cycle" for users. They just refresh the page and they get the latest and greatest.
Rich client apps are great because of the ability to have a rich UI and far more control over the presentation of your application. Speed is almost always better. You can just do more.
AJAX is an attempt to merge the two. Sometimes it works very well, sometimes not. But it's just a stop-gap solution that tries to use existing web technology to mimic the experience users know and love from rich client apps.
The real solution to this problem is to allow for rich client apps to have the ease of deployment of web apps. There are a few possibilities in this area.
One solution is Microsoft click-once deployment paradigm in
Of course, this has the same problems as most
Does anybody know of similar projects coming down the pipe that will offer this to more than Windows clients? Something other than people implementing WPF and the
FTFA: Microsoft's copyrights in this specification are licensed under the Creative Commons Attribution-ShareAlike License.
This license is more simple, but the same in principle, to the GPL.
Stocks are not physical things either. They are limited in supply arbitrarily. When the price of a particular stock becomes high the company will often split their stock one or more times to make it available to more people at a lower price. Existing share holders have the same dollar value in stock but with double (or whatever) the shares. Outstanding shares simply double in quantity and half in value, or whatever the case may be.
Downloads wouldn't have the same arbitrary limitation on the maximum number of downloads available, of course, but the basic principals are the same.
The value of the stock is obviously based on demand, but initially based on the financials of the company. Similarly, the value of a music download would initially be based on the perceived popularity of the song in question. Over time, this value would fluctuate in much the same way a stock does. Not because of scarcity, but because of popularity... the same way a stock's price soars not because the company is all of a sudden doing better, or because the stock has become more rare, but because people desire the stock more.
It's not exactly the same, though. It is possible for all shareholders of a company to hold the stock regardless of the offering price. This would simulate a lack of supply. In the downloads world, I don't expect iTunes would refuse to sell a song regardless of the price people were willing to pay.
Nice try for what?
THe original poster said he had to restard IIS in order to get it to handle requests again. In other words, it hadn't crashed... he was doing an IISRESET which restarts the running process.
I don't think I've ever seen IIS actually crash... aside from buffer overflows being exploited back in the day by worms.
No, I don't work for Microsoft.
I post mostly Microsoft stories to Slashdot in an attempt to even things out a little. There aren't a whole lot of balanced articles on this site, and the forums are certainly skewed.
Actually, it's just proof you didn't watch the video.
But Apache never crashed (and this was on a comparatively memory-poor box by today's standards - 256 meg), just took a second or two ... and nobody else connected to the box complained.
.NET framework is and how much bang for my buck I can get out of ASP.NET on IIS. Sometimes I pick Java for those rare cases one needs a server application to be portable.
Apache, like IIS, has a finite number of threads it uses to handle incoming requests. If you use up all those threads, Apache, and IIS, can't respond. You either must increase the number of threads or users will be denied access to the site. Eventually, you run out of system resources. In either case, you've prevent one (or likely a lot more) request from being fulfilled by the web server. End of story.
Your example is a foolish one. You never caused Apache to run out of resources. If you had, it would have "crashed" as the originally posted meant it... it couldn't handle further requests. That wasn't because Apache is superior in some way to IIS, it's because your clicking didn't use up all the threads. Simple as that. That's what I was explaining... the same thing can happen to Apache as can happen to IIS. Just because Apache is open source doesn't make it invulnerable to resource exhaustion due to inept programmers.
No, its Windows that pretty much has no credibility. The one thing it DOES have that nobody else has is the widest selection of trojans, viruses, worms, and idiot users.
That and the majority of the fortune 500 companies running on it. Windows is a fully capable server platform, and there are countless examples to back that up... just as there are countless examples that show that Linux can be a capable server platform. My point was that IIS is not inherently flawed as the original poster suggested. In fact, IIS 6.0 is in my opinion the best web application server on the market if cost is not an issue. (Windows licenses can be too expensive for a small company.) It's had extremely few security holes (FAR fewer than Apache has in the same timeframe), it's very fast (thanks to advanced features like kernel mode listeners), it's extremely reliable thanks to application isolation, process recycling, and great management and monitoring tools, and it's host to many excellent development platforms from PHP to ASP.NET.
IIS 7.0 is shaping up to be even better with some great ways to customize the web server to make it as bare metal as possible if that's what you want.... taking a hint from Apache in this case.
But for you to sit there and question the intelligence of somebody who uses Windows as a server platform shows your ignorance. It shows you don't bother to really examine alternatives to what you're comfortable with. When choosing a platform for a project I make sure to consider as many things as possible... from portability requirements, to intellectual property issues, to performance, to cost, to ease of development. That's my job as a software architect. Sometimes I choose LAMP for its very low initial cost. (Basically free.) Sometimes I pick ASP.NET because of how robust the
Regardless, there are lots of options out there and until you're able to pick the best one for the job at hand you're just going to be limiting yourself for no good reason. Both career wise and intellectually.
Read this to see what they're doing.
I agree that no modern OS runs a 30 year old stack... but most modern OS's today still have major issues with high latency connections even when those pipes have plenty of bandwidth. There is nothing we can do about a 100ms latency when the connection is 5000 miles long, but there is a lot we can do to improve the TCP protocol to optimize for those long distance/high bandwidth connections that are becoming more and more common.
Watch the video. That wasn't the problem.
The problem was connecting two datacenters that were physically seperated by a long distance but connected with a high bandwidth pipe... the TCP protocol has problems with this because of latency issues.
Read this to see how they solved it.