However, a private monopoly is probably the least worst kind (with State monopolies being the worst kind, since they often abuse the law to maintain their monopoly, this is Friedman's view).
What are you measuring as "worse" ? Because from the consumer perspective, I'd imagine a private monopoly to be far "worse".
No, it hasn't always met those requirements. It has always met what Microsoft has claimed to be "Multi-User". They didn't invent the term, they just applied a brand new meaning to the term and people, like yourself, buy it as the "only" definition that matters.
The only definition that matters is the computer science/OS design definition - and Windows NT meets (and always has met) that definition of multiuser (which, again, has absolutely nothing to do with how many people can log into the GUI, what servre applications an OS ships with or the administration tools it offers).
That's Microsoft's new definition talking, once again. When the term was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously. You get an "A" for sticking to the party line, but you should study more of the history of computing.
So you're prepared to argue that DOS is a multiuser OS ? MacOS [Classic] ? Windows 95 ? OS/2 ? Because they can all meet the requirements of your stupid definition (not to mention that according to you systems that don't have interactive users can't be multiuser).
It sounds like you haven't really spent anytime studying permission control on UNIX.
Only about 15 years.
With groups, it is entirely possible to create controls with nested layers of access.
I never suggested otherwise. I merely pointed that such methodology is primitive, clumsy, complex, difficult to manage outside of trivial environments and error prone because of its higher human overheads.
There just hasn't been a need to implement ACLs on the business servers that I am running right now, there's no benefit to implementing that at this time.
Well, without knowing anything about your environment, it's hard to comment on your specific requirements - however, it's quite feasible with a simple environment you wouldn't see group nestings complex enough to become a significant management overhead. However, from the experience of managing unix systems with thousands of users, when you start nesting dozens of groups together, or creating special groups just so three people from different divisions can all access the same set of shared file, it can become a fucking nightmare.
Even in small environments ACLs make things easier, however, when Betty from accounting needs to be given access to a handful of upper-management files, it's a hell of a lot easier to change a couple of ACLs than go messing with creating new groups, changing group memberships, changing permissions, etc.
However, if you are so uppity about ACLs, just check this. It is the command listing for Solaris 2.5's ACL system, released in 1995. It's UNIX and it had ACL's in 1995. Oh, I bet you didn't know that.
I did, which was why I quite specifically commented on *traditional* unix. Very few environments use ACLs on unix platforms, mainly because of obstinate old-skool unix administrators.
At no stage did I suggest ACLs were Windows-only, or even Windows-first.
Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
Shift+Right click.
You know why it is like that?
Bad UI.
I am taking an educated guess here, but having attempted to run installs after creating a shortcut and then using "RunAs" on the installer shortcut. I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
And you are wrong.
Moreover, if you had even a tenth the understanding and "education" you think you
Okay, now you are smoking something. Why don't you look up Multi-User and understand that Windows still isn't as Multi-User as UNIX is.
I know perfectly well what multiuser means (although that definition you linked to is terrible), and Windows NT meets (and always has met) the requirements.
It's important to understand the "user" part of "multiuser" doesn't refer to actual people. The ability to host multiple interactive sessions doesn't make an OS multiuser (otherwise OS/2 running a BBS server would be considered multiuser) any more than the lack of doing so makes an OS not multiuser (else a unix workstation with only one person in front of it wouldn't be multiuser).
"Multiuser" is the ability of an OS to run code in different "user" contexts. It's got nothing to do with how many people can log in to a machine at once.
I say NT is "more multiuser" because access to just about everything in the OS is based around per-user ACLs. (Traditional) Unix, OTOH, only really has two different user contexts at its core - root and "not root" (this is why you *have* to be root to perform certain actions and so many applications use the clumsy hack of starting as root and then "dropping" to a regular user context). User groups are also used to further divide the "not root" aspect and access restrictions to resources are typically implemented by hacking some presentation layer together that looks like a filesystem, but fundamentally it's a primitive system that can't deliver fine-grained permissions.
An application program with components that ship with the operating system from the operating system vendor.
What are you talking about ?
The point is that if a malicious application elevates itself to "SYSTEM" level privileges, the only recourse is to wipe the machine completely. You are effectively 'rooted' and there is no method of truly protecting that level of the OS as an Administrator, since you are effectively cut out from it.
Yes, just like root on unix (although strictly speaking, in terms of design, 'root' is less secure than SYSTEM - practically speaking they're the same thing).
I really don't understand what point you're trying to make here. Yes, the SYSTEM user has basically carte-blanche access to the entire OS - but so does a root user on unix (actually more so, technically speaking). If you can get SYSTEM level privileges on Windows, you pretty much own the machine, just like getting root level privileges on unix.
SYSTEM is hardly a unique weakness of Windows (and from an architecture perspective, it's less vulnerable than root).
Then enlighten me.
You are confusing OS-level user contexts (eg: SYSTEM) with hardware-level execution contexts (ring 0). You don't really understand what "multiuser" means and you think that whether or not an OS is "multiuser" is determined by the software tools it ships with (rather than its fundamental design). You appear to think SYSTEM is something unique to Windows and represents a weakness not present on unix.
(Heck, you're probably one of these people that thinks "IE is integrated into the OS" means it's part of the kernel, or runs with some special elevated privileges.)
All this indicates to me that you don't really know what you're talking about (OS architecture and design), thus meaning you're not in any position to criticise it.
And to top it all off, you had the gall to patronisingly tell someone else they don't understand.
My hope for Vista in the begining was what Apple did. Throw out the old code and start fresh with all new from the ground up. Then use their VirtualPC buy to create a wine like interface for backward compatiblity.
There were compelling reasons for Apple to do that. No such compelling reasons existed for Microsoft to do the same thing with Vista (Windows NT 6.0).
No wonder why you need a dual core processor to run Vista.
I wonder if some of the virus exploits are just impossible to properly close off and still allow the system to function as the user intends.
Since the most common "exploit" in the system is the end user, yes, it is pretty hard to "properly close off".
Maybe the anti-virus anti-spam anti-adware layers are needed just to decipher what a user's program is allowd to do an an unwanted program might try to do.
Anti-[virus/spam/adware] layers are necessary because identifying "malware" algorithmically is practically impossible.
If you're referring to the NT codebase, I think it's fair to say that GNU/Linux is giving support and updates to an OS that is over 10 years old, and FreeBSD is giving support and updates to an OS that is 35+ years old.
He's referring to Microsoft's 8 year support window.
And I doubt you'll find many pieces of OSS software still being maintained 8 years after release. Shit, you're usually lucky to find OSS software being maintained 1 - 2 years after release.
Then again, you could mean that by the NT codebase being 8 years old that it's actually *very young* and therefore will have more problems than more-established OSes.
The NT codebase is actually between 13 and 18 years old.
Perhaps one of the biggest ones which are commonly overlooked is that Windows wasn't originally intended to be a multi-user OS and it only reached a half decent level of multi-user capability when XP was released.
Was NT was designed to be (in 1988) - and has been since release (in 1993) - a fully multiuser OS.
Let's not forget that Windows 2000 and XP inherited most of their software from 9x, which still was the descendant of a single-user OS. I'm not even sure whether the 9x line had proper multiuser support.
Windows 9x was single user. However, from about Windows 95 OSR2 onwards, it *did* have all the necessary APIs and capabilities for developers to write "multiuser friendly" code that would work, as a regular user, with the real multiuser Windows (NT).
The evidence of the problems with the the Windows development model is showcased in that virtually every single flaw exploited has almost always resulted in a total compromise of the system, not just a compromise of one subsystem giving the attacker limited access to the total system.
This is because the typical user runs as Administrator. Simply running as a regular user either stops, or severely limits the impact of, 99% of Windows malware.
As you are a Home User, I won't knock you for not understanding the true difference between what an effective User-Level and Multi-User OS is and what MS has provided.
Windows is a multiuser OS. *More* so than the typical unix, if anything, with it's fine grained per-user ACLs in just about every aspect of the OS.
While they have made major leaps forward, with the "RunAs" feature, there are still significant applications that cannot be run using the "RunAs" feature. It only goes so far.
This is an application problem, not an OS problem.
Then, there is the SYSTEM group. This "Group" is controlled by the computer itself and if an application good or bad, runs under the SYSTEM level privileges, there is no method for even an administrator of the machine to kill or otherwise control what is going on, without rebooting/rebuilding the OS.
Yes, SYSTEM is about as close as you get on Windows to 'root' on unix. What's your point ?
Effectively, you do not "control" or have "full control" as an available option on a Windows machine and at best, you have Ring 1 access and never Ring 0 access to the OS and its internals.
Yes it has. I read the interview where a member of the team itself told about how the code was unmanageable, and they had to rewrite big parts of it. That doesn't mean they improved it, they just wrote it to become more easily managed.
I think you should be cautious with drawing conclusions of low-level development details from PR fluff pieces.
Vista is Windows NT 6.0. It has major changes, to be sure - but a rewrite it ain't.
I wasn't talking about the core literally, I was talking about the core being that they should focus on Windows being stable and secure, as is.
If you run it on decent hardware, avoid using known-buggy software to perform risky tasks (eg: browse the web with IE) and follow best practices that have been around for decades (eg: don't run as Admin), Windows *is* "stable and secure".
They shouldn't use old software, patch it for 10 years, and the re-use that old, patched code for yet ANOTHER operating system so that they can patch THAT even more.
This is not realistic. Writing (or rewriting) an OS like Windows is a *massive* task. It would take ten years to rewrite Windows, or create another OS from scratch, that had the same levels of functionality.
The "core" of Windows is quite solid and well-designed. Most of the problems (that aren't end-user related, so very few in the grand scheme) are in subsystems (like IE) or the work of third parties (crappy drivers).
Certain *parts* of Windows (like IE) would probably benefit from a ground-up rewrite, I'll agree, but that's about it.
I'd say that in my case, getting the word out that Linux is just a kernel and that there are many flavours built arround it is the greatest problem.
Getting the word out is not the problem. The "problem" is that the vast, vast bulk of people neither understand or - more importantly - care about the distinction.
To most people a computer and its OS are logically one and the same. In other words, they perceive computers to be just like every other "appliance" in their lives (and justifiably so, IMHO, end users shouldn't _need_ to concern themselves with the nuances of hardware and software just to browse the web, check their email or play a game).
"Linux" still isn't at the appliance stage. Neither are Windows or OSX, to be sure, but they're a hell of a lot closer.
Is this type of thing difficult to do in the Windows world?
Well, it's not really *relevant* to the "Windows world". The reason most daemons on unix start as root and then change to another user is because to do most "interesting" things on unix - eg: bind to a low port - you have to be root (more accurately, UID==0). Since Windows uses ACLs for just about everything, you can assign privileges for specific things on a per-user basis.
Basically, the security models of unix and Windows are fundamentally different. On unix, you have to let the code be able to do anything (run as root) then change to another user with fewer privileges. On Windows, you just grant the user the specific privileges they need (in theory at least, most applications aren't written well enough to actually do this).
How difficult is it to create a 'Firefox' user with NO privs, and have the bulk of the browser run under that ID?
Maybe some small part would need to retain privs to write to the user's download area (maybe it can even chroot() to the user's Documents and Settings area?), but most of the browser drops to a non-privileged state.
You are trying to apply unix concepts to Windows. It doesn't work, because they are fundamentally different under the hood.
Yes, they will. They'll almost cetainly be the biggest expense of your entire IT infrastructure.
In your original post you imply that deploying Linux will cost you more in staff costs. That is not true.
It is true. It is something that nearly every study into the subject finds and it is something backed up by the experience of every IT professional I've ever met.
Unix people cost more than Windows people. As they should, since they're rarer and the barrier to entry is higher. Unix is not as easy to use as Windows.
The reality is that yes, you're more likely to be able to hire an inexperienced MSCE cheaper, however a decent Windows admin will cost the same as a decent Unix admin.
The reality is that an inexperienced MCSE - or even weekend dabbler with no formal qualifications - is capable of rolling out a functional IT infrastructure for a small business. A Domain, Exchange, IIS, file sharing, global address books, etc. These things are easy to setup on Windows, even if you don't do it for a living. The equivalents on Linux are *not* easy to setup, if they even exist. They require much more experience and intricate knowledge. Hence, the people capable of doing it cost more.
To put it simply, minimally useful unix people cost more than minimally useful Windows people. Once you get to a certain point, they cost about the same, but there's a hell of a lot of businesses whose requirements are below that level.
Admittedly this is partly true. The difference(tm) though is that Apple doesn't regard their customers as piggybanks/greasy morons/retards/irritations to the same extent that Microsoft does.
Bollocks.
Apple are just as bad - if not worse - than Microsoft are. The only difference is their corporate bastardry affects fewer people.
Did it occur to them that most of the software on Linux don't require purchasing? Groupware servers, Web servers, FTP servers... IRC servers... all free.
Any up-front cost savings are typically offset by higher implementation and staffing costs.
Buying software is usually the *cheapest* aspect of using it.
Is it just me, or did Microsoft pretty much `invent' the TCO term strictly to counter free software like Linux? Did the term exist before Linux did, or was it just Microsoft making it popular?
Yes. "TCO" has been around forever. Mac zealots regularly rolled out the "MacOS has better TCO than Windows" arguments back in the early (and mid, and late) 90s (in reference to a single TCO comparison of MacOS 7.x and Windows 3.0, IIRC).
"TCO" is a pretty well known term in a business environment (which is probably why so few people on Slashdot have heard of it outside Linux-Windows fluff articles).
Slashdot Mirror
What are you measuring as "worse" ? Because from the consumer perspective, I'd imagine a private monopoly to be far "worse".
The only definition that matters is the computer science/OS design definition - and Windows NT meets (and always has met) that definition of multiuser (which, again, has absolutely nothing to do with how many people can log into the GUI, what servre applications an OS ships with or the administration tools it offers).
That's Microsoft's new definition talking, once again. When the term was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously. You get an "A" for sticking to the party line, but you should study more of the history of computing.
So you're prepared to argue that DOS is a multiuser OS ? MacOS [Classic] ? Windows 95 ? OS/2 ? Because they can all meet the requirements of your stupid definition (not to mention that according to you systems that don't have interactive users can't be multiuser).
It sounds like you haven't really spent anytime studying permission control on UNIX.
Only about 15 years.
With groups, it is entirely possible to create controls with nested layers of access.
I never suggested otherwise. I merely pointed that such methodology is primitive, clumsy, complex, difficult to manage outside of trivial environments and error prone because of its higher human overheads.
There just hasn't been a need to implement ACLs on the business servers that I am running right now, there's no benefit to implementing that at this time.
Well, without knowing anything about your environment, it's hard to comment on your specific requirements - however, it's quite feasible with a simple environment you wouldn't see group nestings complex enough to become a significant management overhead. However, from the experience of managing unix systems with thousands of users, when you start nesting dozens of groups together, or creating special groups just so three people from different divisions can all access the same set of shared file, it can become a fucking nightmare.
Even in small environments ACLs make things easier, however, when Betty from accounting needs to be given access to a handful of upper-management files, it's a hell of a lot easier to change a couple of ACLs than go messing with creating new groups, changing group memberships, changing permissions, etc.
However, if you are so uppity about ACLs, just check this. It is the command listing for Solaris 2.5's ACL system, released in 1995. It's UNIX and it had ACL's in 1995. Oh, I bet you didn't know that.
I did, which was why I quite specifically commented on *traditional* unix. Very few environments use ACLs on unix platforms, mainly because of obstinate old-skool unix administrators.
At no stage did I suggest ACLs were Windows-only, or even Windows-first.
Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
Shift+Right click.
You know why it is like that?
Bad UI.
I am taking an educated guess here, but having attempted to run installs after creating a shortcut and then using "RunAs" on the installer shortcut. I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
And you are wrong.
Moreover, if you had even a tenth the understanding and "education" you think you
I know perfectly well what multiuser means (although that definition you linked to is terrible), and Windows NT meets (and always has met) the requirements.
It's important to understand the "user" part of "multiuser" doesn't refer to actual people. The ability to host multiple interactive sessions doesn't make an OS multiuser (otherwise OS/2 running a BBS server would be considered multiuser) any more than the lack of doing so makes an OS not multiuser (else a unix workstation with only one person in front of it wouldn't be multiuser).
"Multiuser" is the ability of an OS to run code in different "user" contexts. It's got nothing to do with how many people can log in to a machine at once.
I say NT is "more multiuser" because access to just about everything in the OS is based around per-user ACLs. (Traditional) Unix, OTOH, only really has two different user contexts at its core - root and "not root" (this is why you *have* to be root to perform certain actions and so many applications use the clumsy hack of starting as root and then "dropping" to a regular user context). User groups are also used to further divide the "not root" aspect and access restrictions to resources are typically implemented by hacking some presentation layer together that looks like a filesystem, but fundamentally it's a primitive system that can't deliver fine-grained permissions.
An application program with components that ship with the operating system from the operating system vendor.
What are you talking about ?
The point is that if a malicious application elevates itself to "SYSTEM" level privileges, the only recourse is to wipe the machine completely. You are effectively 'rooted' and there is no method of truly protecting that level of the OS as an Administrator, since you are effectively cut out from it.
Yes, just like root on unix (although strictly speaking, in terms of design, 'root' is less secure than SYSTEM - practically speaking they're the same thing).
I really don't understand what point you're trying to make here. Yes, the SYSTEM user has basically carte-blanche access to the entire OS - but so does a root user on unix (actually more so, technically speaking). If you can get SYSTEM level privileges on Windows, you pretty much own the machine, just like getting root level privileges on unix.
SYSTEM is hardly a unique weakness of Windows (and from an architecture perspective, it's less vulnerable than root).
Then enlighten me.
You are confusing OS-level user contexts (eg: SYSTEM) with hardware-level execution contexts (ring 0). You don't really understand what "multiuser" means and you think that whether or not an OS is "multiuser" is determined by the software tools it ships with (rather than its fundamental design). You appear to think SYSTEM is something unique to Windows and represents a weakness not present on unix.
(Heck, you're probably one of these people that thinks "IE is integrated into the OS" means it's part of the kernel, or runs with some special elevated privileges.)
All this indicates to me that you don't really know what you're talking about (OS architecture and design), thus meaning you're not in any position to criticise it.
And to top it all off, you had the gall to patronisingly tell someone else they don't understand.
You don't even drink coffee ?
KHTML is LGPLed (the one RMS doesn't really like). If it had been GPLed, Apple wouldn't have touched it with a barge pole.
There were compelling reasons for Apple to do that. No such compelling reasons existed for Microsoft to do the same thing with Vista (Windows NT 6.0).
No wonder why you need a dual core processor to run Vista.
You don't.
Since the most common "exploit" in the system is the end user, yes, it is pretty hard to "properly close off".
Maybe the anti-virus anti-spam anti-adware layers are needed just to decipher what a user's program is allowd to do an an unwanted program might try to do.
Anti-[virus/spam/adware] layers are necessary because identifying "malware" algorithmically is practically impossible.
He's referring to Microsoft's 8 year support window.
And I doubt you'll find many pieces of OSS software still being maintained 8 years after release. Shit, you're usually lucky to find OSS software being maintained 1 - 2 years after release.
Then again, you could mean that by the NT codebase being 8 years old that it's actually *very young* and therefore will have more problems than more-established OSes.
The NT codebase is actually between 13 and 18 years old.
Was NT was designed to be (in 1988) - and has been since release (in 1993) - a fully multiuser OS.
Windows 9x was single user. However, from about Windows 95 OSR2 onwards, it *did* have all the necessary APIs and capabilities for developers to write "multiuser friendly" code that would work, as a regular user, with the real multiuser Windows (NT).
This is because the typical user runs as Administrator. Simply running as a regular user either stops, or severely limits the impact of, 99% of Windows malware.
Windows is a multiuser OS. *More* so than the typical unix, if anything, with it's fine grained per-user ACLs in just about every aspect of the OS.
While they have made major leaps forward, with the "RunAs" feature, there are still significant applications that cannot be run using the "RunAs" feature. It only goes so far.
This is an application problem, not an OS problem.
Then, there is the SYSTEM group. This "Group" is controlled by the computer itself and if an application good or bad, runs under the SYSTEM level privileges, there is no method for even an administrator of the machine to kill or otherwise control what is going on, without rebooting/rebuilding the OS.
Yes, SYSTEM is about as close as you get on Windows to 'root' on unix. What's your point ?
Effectively, you do not "control" or have "full control" as an available option on a Windows machine and at best, you have Ring 1 access and never Ring 0 access to the OS and its internals.
You have NFI what you're talking about.
The concept of 'root' (and all the hacks and workarounds that have stemmed from it).
I think you should be cautious with drawing conclusions of low-level development details from PR fluff pieces.
Vista is Windows NT 6.0. It has major changes, to be sure - but a rewrite it ain't.
I wasn't talking about the core literally, I was talking about the core being that they should focus on Windows being stable and secure, as is.
If you run it on decent hardware, avoid using known-buggy software to perform risky tasks (eg: browse the web with IE) and follow best practices that have been around for decades (eg: don't run as Admin), Windows *is* "stable and secure".
They shouldn't use old software, patch it for 10 years, and the re-use that old, patched code for yet ANOTHER operating system so that they can patch THAT even more.
This is not realistic. Writing (or rewriting) an OS like Windows is a *massive* task. It would take ten years to rewrite Windows, or create another OS from scratch, that had the same levels of functionality.
The "core" of Windows is quite solid and well-designed. Most of the problems (that aren't end-user related, so very few in the grand scheme) are in subsystems (like IE) or the work of third parties (crappy drivers).
Certain *parts* of Windows (like IE) would probably benefit from a ground-up rewrite, I'll agree, but that's about it.
If it were impossible - as opposed to trivial - to run Windows without falling victim to malware, you just might have the glimmerings of a point.
No, it hasn't.
Harden the system at the core, don't make the fingertips bulletproof.
The "core" of Windows is the part _least_ in need of improvement.
The power draw figures given on the last page are for the *entire system*, not just the CPU.
Getting the word out is not the problem. The "problem" is that the vast, vast bulk of people neither understand or - more importantly - care about the distinction.
To most people a computer and its OS are logically one and the same. In other words, they perceive computers to be just like every other "appliance" in their lives (and justifiably so, IMHO, end users shouldn't _need_ to concern themselves with the nuances of hardware and software just to browse the web, check their email or play a game).
"Linux" still isn't at the appliance stage. Neither are Windows or OSX, to be sure, but they're a hell of a lot closer.
Well, it's not really *relevant* to the "Windows world". The reason most daemons on unix start as root and then change to another user is because to do most "interesting" things on unix - eg: bind to a low port - you have to be root (more accurately, UID==0). Since Windows uses ACLs for just about everything, you can assign privileges for specific things on a per-user basis.
Basically, the security models of unix and Windows are fundamentally different. On unix, you have to let the code be able to do anything (run as root) then change to another user with fewer privileges. On Windows, you just grant the user the specific privileges they need (in theory at least, most applications aren't written well enough to actually do this).
How difficult is it to create a 'Firefox' user with NO privs, and have the bulk of the browser run under that ID?
Maybe some small part would need to retain privs to write to the user's download area (maybe it can even chroot() to the user's Documents and Settings area?), but most of the browser drops to a non-privileged state.
You are trying to apply unix concepts to Windows. It doesn't work, because they are fundamentally different under the hood.
Yes, they will. They'll almost cetainly be the biggest expense of your entire IT infrastructure.
In your original post you imply that deploying Linux will cost you more in staff costs. That is not true.
It is true. It is something that nearly every study into the subject finds and it is something backed up by the experience of every IT professional I've ever met.
Unix people cost more than Windows people. As they should, since they're rarer and the barrier to entry is higher. Unix is not as easy to use as Windows.
The reality is that yes, you're more likely to be able to hire an inexperienced MSCE cheaper, however a decent Windows admin will cost the same as a decent Unix admin.
The reality is that an inexperienced MCSE - or even weekend dabbler with no formal qualifications - is capable of rolling out a functional IT infrastructure for a small business. A Domain, Exchange, IIS, file sharing, global address books, etc. These things are easy to setup on Windows, even if you don't do it for a living. The equivalents on Linux are *not* easy to setup, if they even exist. They require much more experience and intricate knowledge. Hence, the people capable of doing it cost more.
To put it simply, minimally useful unix people cost more than minimally useful Windows people. Once you get to a certain point, they cost about the same, but there's a hell of a lot of businesses whose requirements are below that level.
Bollocks.
Apple are just as bad - if not worse - than Microsoft are. The only difference is their corporate bastardry affects fewer people.
On the contrary, it's the "right" staff that are going to cost you the most.
Netcraft doesn't count intranets.
Any up-front cost savings are typically offset by higher implementation and staffing costs.
Buying software is usually the *cheapest* aspect of using it.
Yes. "TCO" has been around forever. Mac zealots regularly rolled out the "MacOS has better TCO than Windows" arguments back in the early (and mid, and late) 90s (in reference to a single TCO comparison of MacOS 7.x and Windows 3.0, IIRC).
"TCO" is a pretty well known term in a business environment (which is probably why so few people on Slashdot have heard of it outside Linux-Windows fluff articles).