Microsoft Claims Firms 'Hitting a Wall' With Linux

maxifez writes writes to tell us that Microsoft has released yet another independent study downplaying the viability of Linux at the enterprise level. The study claims that Windows is "more consistent, predictable, and easier to manage than Linux." From the article: "The study, commissioned by the software giant from Security Innovation, a provider of application security services, claimed that Linux administrators took 68 per cent longer to implement new business requirements than their Windows counterparts." Vnunet.com has also provided a PDF of the original report.

Comments

It's all about the criteria.

[khasim]

The key, as always with these "studies", is to find the portion where it deviates from Reality. That is, where it uses some strange definition or where the sysadmins choose some bizarre action.

In this "study", that step into UnReality begins where all systems are required to stay on the same time-line for upgrades.

This means that what would otherwise be a normal upgrade from SLES 8 to SLES 9 instead becomes a strange mix of back-porting patches from SLES 9 to SLES 8. In other examples, the sysadmins are downloading code from the glibc and mysql sites and applying it to those server WITHOUT TESTING. So, over time, the SLES systems become unstable.

Meanwhile, no non-Microsoft supplied code is applied to the Windows boxes.

Of course, the one who commissions the "study" gets to choose the criteria ...

Actually, it does.

[khasim]

Weekly reboots.

Get a copy of Win2K3 on your box. Create a directory that's 3 directories below the root.

Put 200,000 files in that directory (size of each file does not matter).

Now, watch the application that reads and writes files to that directory get slower and slower over time. Until you need to reboot the box.

For an instant problem, open that directory in Explorer. All of your processor speed will be eaten by the "system" process. Even after you close Explorer. Rebooting is the only thing that will clear the problem.

Re:Nice to know

[swillden]

The reason Windows locks an executable file that is in-use is that it uses it as a kind of mini-swap file. If you need to swap part of that binary's code out to disk, windows doesn't - it just forgets it. If it needs that code back in memory, it reads it directly from the file on disk.

All modern Unix-type systems, including Linux, do the same thing. Yes, that means you can have a situation where:

1. Program 'foo' is executed.
2. Program 'foo' is swapped out (or perhaps just never loaded -- application code is paged in on-demand, so if there are big parts that were never executed, they were never loaded).
3. Program 'foo' is deleted, while the process is still running.
4. The running process needs to page in a portion of the deleted file.

What happens? Nothing much. It works just fine. How? Because when I said the program was "deleted" in step three, I wasn't being precise. What really happened was that the program was "unlinked". That removes the directory entry and makes it so no process can create a new reference to the file. But any running processes already have a reference to the file, and the actual file stays in existence until all references (both filesystem references and process references) to it go away.

This holds true for all files, too, not just executables. For example, it's not uncommon for me to start a download then, while the download is running, decide I don't like where it's being written. No problem. I just move it. As long as I'm not moving it to a different file system, the download process doesn't care, because it isn't writing to "/home/shawn/foo.tar.gz", it's writing to "the file handle referencing inode 274327". It doesn't matter a bit if that inode happens to get relinked into a different part of the file system.

No, there's no excuse for this particular bit of Windows braindamage. The Unix solution is better in every way.