Windows has NUMA support since Windows 2003, and if I am not mistaken it was extended to XP-64.
Of course, that support has been continued on Vista (argh) and Windows 2008.

If you are talking about Solaris and other high-end UNIXes, yeh, you're right, Windows was a little behind on NUMA.
But if you're talking about Linux, I am sorry to bring you to the reality that NUMA support on commercial Linux distribution came over at least one year after windows.

Really. I am a Mac User, I really like Unix. But spreading FUD is bad, regardless of who is doing it, that means: I consider it bad even when it is against MSFT.

Don't talk about what you don't have even the remotest cue. NT always had SMP support, since the dawn of time. XP, Vista and Servers are descendents of Windows NT, which was a superbly well-designed OS. Windows NT had a great design, and if it was not for some stupid marketing ideas like integrating braindead IE all over the places on the UI, the burden of backward compatibility (like having to run DOS and win32 apps) NT would have not had half the problems it had.

Windows NT has been design from ground up to be a SMP system and also a multi-platform system.

Sincerelly, I recomend you read a good book like Windows Internals, and a good book on the Linux Kernel. That also some books on secure coding that cover both platforms. Get informed and you'll be enlightened.

Microsoft has an history of corporate bad behaviour, of over-promising and under-delivering, of being to lax on preventing trouble, of having the mentality that we didn't win if they are still alive. I also would like to see Windows Open Source, and maybe some of the programmer and even some executives would like that also. But on their current business model, that would mean plain suicide, and their shareholders wouldn't be very happy with it,

But the bad ways of MSFT corp. cannot serve as a justification to deny the technical merits of some of their products, and it can't serve as an excuse for us to spread FUD, on the irresponsible way they used to do. Let us at least respect the work of some great people who works/worked there, like Dave Cutler, and give them due credit were appropriate.

For added effect, and possibly the fun of meeting some guys from the FBI on the near future, you should do this and start collecting gun magazines on you desk, wear a long beard and buy your clothes from some military surplus store.

Not being an american, and having never lived on the US, it scares me out the hell the mere thought of what kind of car a Grand Marquis could be.

Thanks for fucking my christmas day with the images you've made me dream of about a car with such a name. I only hope it doesn't have some kind of fake wooden finish on it's doors.

or is a frustrated racer......

It fuck annoys me people who think that they are entitled to stay on the left lane just because they are close to the speed limit, and thus, on their twisted minds, they think they must act like some sort of cops and violate the law by negating passage to a faster car. But, it also annoys me the kind of people who think that they are on a racing circuit by doing exactly what you've described.

Never thought there were that so many Ohioans here in Rio de Janeiro, Teresopolis and Sao Paulo (brasil).

And if Novell had won the war for being the Directory Services for us all with Netware Directory Services, I bet we wouldn't see a Netware Rights Management System which would not require NDS. Duh!
You can use another RMS with AD at least. But it would be a bit of stretch to think Microsoft must have the obbligation to provide a product like that when it's not clearly on their business interests.
Alas, would Windows had became a niche product, I doubt there would be so much people interested on working with Samba, or whether netscape would have come with XPCOM.

THE SAME TEXT AS ABOVE, BUT FORMATTED AS GOOD OL' Plain Text.

You're right.
But for the sake of civilization, and for sparing me from such public and google-indexed embarassment, please let me get by with the story of having had too many beers before writing my post. I just got home, cheked up /. and I saw this. I got outraged and I decided that I had to reply to this. Unfortunately I was still a bit under the influence, and could not come with my ideas very clearly, and add to this the fact that is very hard to write in a second language when drunk :-)

That said, let me add that I've had several recent experiences at my current employer (soon to be former, may I add with undeniable relief) where they failed prey to the stupid idea that throwing some million dollars on the mouths of servers, network and storage vendors could help solving problems caused by bad code. Right now I am still trying to convince a Database Administrator that one of the main database production servers is swapping like hell, just because the user account that run the RDBMS doesn't have the right to lock pages in physical memory and the database server is setup to the default memory limits (that means, all memory). Well, considering that this is the same shop where we pay a huge lot for Oracle on licenses and maintanance, but keeping on using MSSQL and it's shitty concurrency model for most things, because they don't want to rewrite their systems, it's no wonder that such an article strung a very personal string on me.

For me, this situation is analogue to the situation of bad doctors vs. good doctors. Bad Doctors can't have a clue about an issue, and so they ask for a NMR Scan if you get to them with a sore throath, as well as every other conceivable exam they can imagine of.
Good doctors know from your story how to get to plausible hypothesis of what is causing your illness, and thus, they ask for exams only for confirming things and testing their hypothesis. For me, the Bad Doctor standard procedure is the medical equivalent of the "Let's throw hardware at it and hope it works" philosophy.

Of course, We should not go over the board with endless and premature optimizations, but we also cannot get away forever with hordes of script kiddies writing bad code, and being told by incompetent managers that this is the Right Thing to do, this is bad for the script kiddies (And I am not being derrogatory here, being a script kid is a step on the evolution of a programmer, we all have been there somewhere in the past).

And let me tell you that I am not telling it only from a technical point view, but also from a business point of view. We are all seeing the effect of the short time thinking on the big automakers. After years of massive layoffs, massive R&D investment cuts, reckless regard for qualtiy, and an insane dependency on the humours of short-sighted so-called analysts that could not see beyond quarterly results, we are now seeing were they are heading. While GM and chrysler were busy cutting jobs, closing factories, and looking good for a while for the clueless wall-street types, Toyota was keeping jobs open in the US, investing on more power-efficient technologies, keeping quality as No 1. But this kind of thinking is now costing their stakeholders the economies of their lifes. We've also seen the permanent damage that Carly Fiorina did to the spirit of the Old HP, and we saw what happened. So, business story is full of examples of where this kind of short-term thinking can lead on the long-run. I don't see why this obsession on short term results at the expense of long term sustainabilty could not also be damaging on our industry.

You're right. But for the sake of civilization, and for sparing me from such public and google-indexed embarassment, please let me get by with the story of having had too many beers before writing my post. I just got home, cheked up /. and I saw this. I got outraged and I decided that I had to reply to this. Unfortunately I was still a bit under the influence, and could not come with my ideas very clearly, and add to this the fact that is very hard to write in a second language when drunk :-) That said, let me add that I've had several recent experiences at my current employer (soon to be former, may I add with undeniable relief) where they failed prey to the stupid idea that throwing some million dollars on the mouths of servers, network and storage vendors could help solving problems caused by bad code. Right now I am still trying to convince a Database Administrator that one of the main database production servers is swapping like hell, just because the user account that run the RDBMS doesn't have the right to lock pages in physical memory and the database server is setup to the default memory limits (that means, all memory). Well, considering that this is the same shop where we pay a huge lot for Oracle on licenses and maintanance, but keeping on using MSSQL and it's shitty concurrency model for most things, because they don't want to rewrite their systems, it's no wonder that such an article strung a very personal string on me. For me, this situation is analogue to the situation of bad doctors vs. good doctors. Bad Doctors can't have a clue about an issue, and so they ask for a NMR Scan if you get to them with a sore throath, as well as every other conceivable exam they can imagine of. Good doctors know from your story how to get to plausible hypothesis of what is causing your illness, and thus, they ask for exams only for confirming things and testing their hypothesis. For me, the Bad Doctor standard procedure is the medical equivalent of the "Let's throw hardware at it and hope it works" philosophy. Of course, We should not go over the board with endless and premature optimizations, but we also cannot get away forever with hordes of script kiddies writing bad code, and being told by incompetent managers that this is the Right Thing to do, this is bad for the script kiddies (And I am not being derrogatory here, being a script kid is a step on the evolution of a programmer, we all have been there somewhere in the past). And let me tell you that I am not telling it only from a technical point view, but also from a business point of view. We are all seeing the effect of the short time thinking on the big automakers. After years of massive layoffs, massive R&D investment cuts, reckless regard for qualtiy, and an insane dependency on the humours of short-sighted so-called analysts that could not see beyond quarterly results, we are now seeing were they are heading. While GM and chrysler were busy cutting jobs, closing factories, and looking good for a while for the clueless wall-street types, Toyota was keeping jobs open in the US, investing on more power-efficient technologies, keeping quality as No 1. But this kind of thinking is now costing their stakeholders the economies of their lifes. We've also seen the permanent damage that Carly Fiorina did to the spirit of the Old HP, and we saw what happened. So, business story is full of examples of where this kind of short-term thinking can lead on the long-run. I don't see why this obsession on short term results at the expense of long term sustainabilty could not also be damaging on our industry.

But think about it...

1)You don't meet the fucking deadline:
          a) you have a boss: if you are not fired, you will have desired you had been.
          b) you don't have a boss: you lose money, but depending on the customer you can reach an agreement with them.

2) You meet the fucking deadline
          a) you have a boss: He is the hero.
          b) you don't have a boss: You are the hero, and you'll probably get more contracts from this customer, if you don't mind an ulcer, or if better, you hire some slaves, in a few years you could be driving a lambo.

Understanding the relational model is important, but performance-wise it's also very important to understand the inner workings of the concrete implementations of RDBMS you'll find out there.
Unfortunatelly, most developers know nil out of dbms. They don't understand how data is stored, how indexes work, why you have all those logs, what are the main different concurrency protocols used by different databases, they don't understand how buffer caches are used and so on. As an anedocte, once I've heard an history about someone who could not come with a counter argument for the idea that distributed caches like memacached or hibernate could not offer any advantage because if you give more memory to your dbms it would cache it anyway in memory. Well, the bottom line is that the developer thought memcached was cool(and it is), and Oracle is a piece of trash (it's not) but could not explain why that Oracle kept *blocks* on buffer caches, not objects, or individual rows, that Oracle had to maintain consistency (what memcached is not concerned with) and because of it there was merit of using a distributed cache for mostly-read-only data behind the webservers. So what is the problem here? We have tools that isolate most of the things that were the concern of programmers of ancient ages like middleware, distributed transaction controllers, dbms, garbage collection, but most programmers have forgotten, or have never learned, what those tools have to do behind the scenes, I am not advocating that everyone should be able to implement an OS, or a dbms system, a compiler or a garbage collection module for a VM, but instead, that people should be acquainted with the fundamental problems that exists on the system level, that every programmer should not see the computer as a black box, but that he should understand some fundamental things on the system level.

And it's not only the fault of the programmers. As DBAs became more and more specialized, they understand less and less of programming, and thus are sometimes unable to understand simple things, because they don't see their DBMS under a programmer's point of view, and thus with all those point and click management interfaces they have no idea of why things like having a low page density on SQL Server table leads to bad performance on reads. I've seen it too many times: People with lots of certifications but that would not understand how Virtual Memory works, and thus would configure their systems on the worst possible way. People who procured large multi-core system but that have no idea of how Ahmdal's law would broke their dreams of linear performance improvements on pieces. People who could not believe that IO is terribly slow, and that because of that could not believe that putting a lot of log statements in their production code would waste most of the available processor time waiting on IO.
Those things may not look like very much important on the short run, you can get away with horribly optimized code for most of the time. The trouble is: Ignoring performance will hurt your businness on the worst of the circunstances, in the christmas period for a retail chain, on vacations time for a airline reservation system and so on.
I know that Dijkstra said that "Early Optimization is the root of all evil" and I agree with him. But I humbly must add a phrase of mine:
"Reckless regard for optimization is the cube of all evil"
Marcos Eliziario - Brazilian-Joe-Nobody(1974- )

And if you are microsoft, make your users think it's normal to throw hardware at it. After all, it's their money, not yours.

From someone who has been there, done that. I can say that throwing hardware at a problem rarely works.
If nothing else, faster hardware tend to increase the advantage of good algorithms over poorer ones.
Say I have an alghorithm who runs at O(N) and another one functionally equivalent that runs at O(N^2). Now let's say that you need to double the size of the input keeping the execution time constant. For the first algorithm you will need a machine which is 2X faster than the current one, for the second O(N^2) you'll need a 10X times faster machine.
Let's not forget that you need not only things to run fast, but to run correctly, and the absurdity of choosing less skilled programmers with more expensive hardware will become painfully evident.

PS: Sorry for the typos and other errors: english is not my native language, and I've got a bit too much beer last night.

No problem, he must be already used to type google.com when he wants to do a search. After all, who would search in yahoo?