I wrote about this after reading the white paper. I don't think this is a particularly useful idea.
The key "insight" of the paper is that if you associate cookies with IP addresses, and not domain names, attackers can't spoof DNS to steal cookies. So a server and client have a facsimile of a "trusted channel"; if the server can recover a proper IP-tagged cookie, it knows it's talking to a client and not a man-in-the-middle.
Apart from the fact that this whole scheme is aimed at a relatively exotic exploit, which exploit accounts for only a fraction of all phishing attacks, I don't think it will work technically. The simplest reason is Javascript. Attackers don't have to relay requests for victims; they can complete a transaction and transparently direct the victim back to the server. The server need never have contact with the attacker.
Exim is not a secure replacement for Sendmail. qmail and Postfix were both designed explicitly for security, and include:
Privilege seperation
Rewritten IO and string libraries
Minimal-privilege SMTP listeners
The backing of a security luminary (Bernstein or Venema)
Exim was designed as a modernized SMail. It's got the same monolithic architecture as
Sendmail has, meaning security vulnerabilities in Exim are less survivable than they are in qmail or Postfix, where a buffer overflow (none of which have ever been found, unlike in Exim) only gets you a one-off UID.
I don't know how Exim has managed to brand itself as one of the "secure MTAs", but it's just a marketing trick.
You watched some muslims "dancing in the streets", just like we watched some rednecks beating the shit out of Sikhs after 9/11 because they were thought to be Arabs.
Here are samples, from all three of the cited articles, of what Google didn't want appearing in news search results:
"Honestly, I cannot open a paper or turn on the television without seeing mobs of Muslim savages celebrating in front of burning embassies..."
"Is it really tacky of me to smile at the nightly scenes on TV showing Arab, Afghani and Pakistani Muslims bombing mosques and killing their Muslim brothers, sisters and children at a brisk pace because that's all they know how to do?"
"Islam is moving across the world like a dark, evil cloud."
"Worshiping a sex-maniac and a child molester? [...]
Muslims are true victims of Islam. However, they fail to realize that Islam is a cult, and the prophet was a demon..."
The funnier thing is watching WorldNetDaily stick up for The Jawa Report. Apparently nobody there has seen Star Wars or watched South Park. "Jawas?""You know, sand people."
These aren't news stories critical of Islam. They're "editorials" with as much credibility as content from Stormfront.org.
Process Creation: S: 300000, L: 719000, F: 1032000, W: 5376000
The only stat in this table that Windows trails on is process creation. And anybody who has ever ported Unix code to Win32 knows exactly why: Windows is thread-oriented, and Windows systems don't tend to use helper programs or demand-forking to get work done. Which might be why Windows beats Unix in the thread benchmarks, but not in the IPC benchmarks. On the more general benchmarks, like cycles to issue a system call, Windows falls smack in the middle --- and, again, Windows has a slightly different take on what is and isn't a system call.
Drawing comparisons between Singularity and normal operating systems here is silly. Singularity doesn't have processes in the conventional sense; since there's no hardware dependencies on "process" creation in Singularity, IPC and forking are much faster.
Which is why this benchmark is reasonable inside the Singularity tech report (they're trying to demonstrate that there's a major performance benefit in rethinking boundaries between programs), but totally unreasonably outside that context: these are micro-benchmarks, like the ones CISC and RISC people throw at each other, and don't describe the amount of time it takes to complete a high-level task. Time to execute a system call is meaningful only in the context of how many system calls it takes to complete the task you're measuring.
The clerk doesn't need to "obey" your "stupid writing" on the back of your card telling him to "ask for ID". The clerk just needs to be one of the 90% of all clerks who will do the reasonable thing when he sees those words, and ask you for your ID. Among the 90% of clerks who will do that (89% of whom are happy to), 100% of them will decline your purchase if you refuse to comply with your own instructions.
Which is the value of those words on the back of your card.
The "ask ID" trick isn't about identity theft. It's about credit card theft, which is a much simpler and more common crime. It mitigates the damage of losing your wallet, which is a lot more likely to happen than losing your whole identity.
Just like in the movies (read Edward Epstein's excellent Hollywood Economist column in Slate), the expense involved in bringing music to market has almost nothing to do with the physical media; it's marketing and promotion.
Complain all you want that the marketing machine we have now produces Britney and boy-bands; the labels spend money like this because it produces a predictable return on their investment. They're going to make business decisions going forward based on that fact, not based on Jobs' iTMS cost structure.
The interesting conversation is how iTMS alters promotion costs. How much of the promotion budget for Universal or Sony goes in to locking up the retail channel (shelf space at Best Buy, etc)? How much does it cost them to promote an album on the high-traffic iTMS front page?
On the other hand, since iTMS represents such a negligable chunk of the revenue of a music label now, it's probably a bit early to have that discussion.
Jobs knows this, which is why he's resorting to the (much less interesting) argument that iTMS reduces piracy. I don't think this is going to do much, because (a) no, it really doesn't --- people pirate music to get it for free, not to get it more conveniently, and (b) piracy doesn't REALLY cost the industry that much money.
Obviously, the song/album price changes under debate right now have everything to do with labels maximizing their returns; they want to jack up prices because they can. So, apropos this Slashdot story, my point is, nobody cares that iTMS lowers costs for the publishers: it's only reducing 2-3% of those costs.
The fact is that Real's move garnered them lots of press attention, and in light of that, they are now obliged to disclaim the possibility of a lawsuit in their filings.
It's probably not that they think Apple is going to sue them out of existence. It's that, if they DIDN'T disclose that, even a minor legal tussle with Apple could be the basis for a shareholders lawsuit.
The insanely talented and successful people I know with extensive mods would never think to ask. They simply wouldn't take a job that required them to change their appearance.
If that's not where you are in your career, well, suck it up.
Everyone else in this thread babbling about how "unprofessional" and "childish" mods are, well, they can suck it up too. There are people out there who are good enough to come to work every day with eye patch, a jester's cap, and a codpiece. It has nothing to do with the Internet bubble. They're always going to get away with it. It's a good bet that people who complain about them won't ever get away with it. Too bad.
Since you can't explain how IPv6 demonstrably improves security & authentication (IPSec works fine on IPv4), quality of service (vs. MPLS and DiffServ and the extent to which the problem remains unsolved in either protocol), multicast (we can't even figure out how to route it across domains, let alone make it reliable or scale it in routing tables), or autoconfiguration (99% of which is solved by DHCP), and since IPv6 makes routing MUCH HARDER, you're pretty much left with "simplified headers".
So I guess the biggest problem is lack of awareness of how simplified headers solves real problems for network users.
Tufte's well-known critique of the Columbia presentation, and his famous critique of the Challenger data, centered on the use of visual evidence (idiotic charts, statistically incompetant graphs) and, in the former case, on the manner in which the medium (PowerPoint) butchered the message by making chopping it up into incomprehensible hamster pellets of information.
The author here seems to be making the case that ugly typeface and a poor use of color are to blame; that if we just added a few horizontal rules, maybe put the PDB on nice stationary, it would have been more effective.
When facing a dearth of actionable, analyzable data (like a chart with 4 data points), Tufte is likely as not to advocate doing exactly what the original PDB did, which is to stuff it into prose paragraphs.
Tufte's design criticism work is serious, if perhaps overrated. This new one is just an advertisement for a web designer.
This scheme is "disgusting" because it capitalizes on the fact that their customers don't know enough about their existing mail software to configure it do to the exact same thing.
The only difference between "dmail" and minor Exchange Server deployment change is that the "dmail" scheme is proprietary and comes with vendor lock-in.
Frankly, I think any IT manager that doesn't know enough to have an SMTP system configured to be "private" doesn't know enough to evaluate commercial mail solutions. But I could certainly be wrong, and maybe someone should write the 1-page HOWTO on this.
Establishing less-privileged user accounts, even for the machine's owner, is the single most productive step one can take towards reducing the impact of malware. WinXP makes this possible, but, unfortunately, not necessary.
Why would this be true? All a worm needs to propagate is access to a socket (or to the API of your email agent). This is one of the things that makes worms so powerful.
I certainly don't advocate running systems in single-user configurations (I'm a Mac person, and the Mac handles this elegantly, even if it isn't waterproofed yet). However, as a Unix person at heart, the fact that worms can be effective even against services running as "nobody" in chrooted environments --- often even in systrace-style jails --- is one of the most interesting systems-security implications of the malware problem.
It's far from obvious that "Wall Street" wants Google to "fail" --- they're underwriting the Google IPO. Who do you think Morgan Stanley and CSFB are?
What's more, it's not obvious to everybody that Google's approach is necessarily motivated by helping individual investors (like the average Slashdot reader). For example, take Henry Blodget's recent column on Salon:
However, it's important to remember a few things. First, auctions are not a new IPO mechanism. They have been tried in numerous countries over the last 25 years (including the United States) and, in almost all cases, have been discarded in favor of the traditional American IPO method. Second, what's good for the company (high price) is often bad for investors (less upside). Third, those willing to pay the most for shares may not be those best qualified to evaluate their worth. Fourth, and relatedly, auctions are generally not better for individual investors (i.e., us). When individuals "win" auctions (e.g., get stock), it is often because they outbid professional investors who have better information and/or a better sense of value. In such cases, the future stock performance is usually lousy, and the "winners" end up losing.
Recall that Google is also not the first dot-com darling to choose a dutch auction, either. Other notables include the stunningly successful Salon (heh) and --- wait for it --- Andover.net, back in 1999.
A Dutch Auction doesn't necessarily kill the initial pop in a stock offering (there's an argument that it'll increase the value of Google's shares in the early days), and it doesn't cut the underwriters out of the action. They just keep the money they'd be doling out to cronies.
Finally, "do-no-evil" pledge or not, there are objective criticisms of the way Google is handling this IPO, and they aren't coming from Wall Street.
Personally, I wouldn't know the first thing about the true motivations behind Google's actions, but my totally uninformed take is that Google is doing an auction IPO just to be iconoclastic.
The Visual Studio product, which is well-regarded, is:
A good C++ compiler
A good C++ debugger
A good UI builder
A highly-regard IDE (I prefer emacs)
The Visual Studio product, last time I checked, was not:
Revision control (CVS vs. SourceSafe)
Bug tracking
Memory debugging (Valgrind versus Purify)
A profiler (mprof and gprof versus Quantify)
I'm not "confusing" the IDE with the compiler when I compare debuggers or UI builders. I wouldn't say that the Visual Studio editor beats the available GCC-integrated option (I think emacs is better). I'm comparing the Visual Studio product offering, which is well-regarded, to the alternatives.
Remember that my original point, apropos this whole Slashdot article, is that Microsoft does make highly-regarded products, and Visual Studio is definitely one of them.
The last time I looked at GCC --- and you can correct me where I'm wrong, but, without citing what Apple has done with Xcode, tell me what out-of-the-box dev environment you're referring to --- GCC was inferior to Visual Studio. Here's why:
Visual Studio has a faster compiler.
Visual Studio has working precompiled headers out of the box.
Visual Studio has a good incremental build system (and fix-and-debug support).
GDB C++ support is a wreck; it has trouble demangling symbols, it chokes on template instantiations, and it gets line-number confused.
GDB thread support is a wreck.
Visual Studio generates better X86 code than GCC.
The Visual Studio UI canvas is better integrated with the compiler than Glade is with GCC.
I'm sure GCC has made strides (and I think if you factor speed out of the equation, Xcode has surpassed Visual Studio), but when I was doing cross-platform Visual Studio and Linux GCC dev, Visual Studio won hands down. And don't get me wrong: I like Linux better, and my Visual Studio build environment was Cygwin CLI --- but my compile ran faster on Win32, and my debug sessions were easier.
If you think GCC is a great compiler product, I'll agree. I think the fact that Visual Studio bested it is a strong argument for my point that Visual C++ is not a poorly regarded product.
Most widely-used compilers were non-compliant with the C++ spec. Visual C++ generated good code, had a high-quality debugging environment, and still compiles faster than most out-of-the-box alternatives (G++ included).
These "21 Rules Of Thumb" are distilled from McCarthy's "Dynamics of Software Development" book, which has been on the bookshelf of almost every dev lead I've ever worked with or known. You could have a similar "argument" about how good IBM software is (WebSphere?), but at the end of the day, if you're doing it to critique The Mythical Man Month, you're going to sound really dumb.
More importantly, all bitching about MSFT quality aside, McCarthy was dev/program manager on Visual C++, which is not a poorly-regarded Microsoft product (it's one of the best compiler products on the market). There are extremely successful products --- successful on every axis --- that come out of Microsoft. Visual C++, and McCarthy's book, represents one of them. Microsoft Excel, and Joel on Software, represents another.
Microsoft is a huge company with an enormous talent pool and many very qualified, very effective well-jelled teams. You do not sound credible when you try to tar them with the "Microsoft is buggy crap" brush, especially when you're arguing with McCarthy or Spolsky.
The initiative to ADD SMP to OpenBSD (and the announcement that "a full time developer was working on it")
occurred less than 4 months ago. It took FreeBSD years to get SMP "right", during an adolesence where stability seriously suffered.
Neither NetBSD nor OpenBSD have a significant fraction of the user base of FreeBSD (and an infinitessimal share compared to Linux), and neither NetBSD nor OpenBSD have comparably-sized development teams. FreeBSD SMP had antecedants to build on as well. So logic dictates that it should take longer for OpenBSD SMP to be "ready".
OpenBSD went through a comparable architecture change when they swapped virtual memory systems a few years ago, and several subsequent major releases of OpenBSD had serious VM stability problems (many of them synchronization issues). SMP is even harder (and more of it involves synchronization).
So, is there some mitigating factor here that would convince anyone who was paying attention to deploy a mission-critical system on SMP OpenBSD in 2004?
Slashdot Mirror
Greylock doesn't simply "not invest" in Friendster; they're the lead investor in LinkedIn, Friendster's direct competitor.
I wrote about this after reading the white paper. I don't think this is a particularly useful idea.
The key "insight" of the paper is that if you associate cookies with IP addresses, and not domain names, attackers can't spoof DNS to steal cookies. So a server and client have a facsimile of a "trusted channel"; if the server can recover a proper IP-tagged cookie, it knows it's talking to a client and not a man-in-the-middle.
Apart from the fact that this whole scheme is aimed at a relatively exotic exploit, which exploit accounts for only a fraction of all phishing attacks, I don't think it will work technically. The simplest reason is Javascript. Attackers don't have to relay requests for victims; they can complete a transaction and transparently direct the victim back to the server. The server need never have contact with the attacker.
Why is "Benjamin Horst"'s name in the ad?
Since when do ads have "producer credits"?
Is this an ad for OpenOffice or a chance for some guy to get his name in the paper?
Exim is not a secure replacement for Sendmail. qmail and Postfix were both designed explicitly for security, and include:
Exim was designed as a modernized SMail. It's got the same monolithic architecture as Sendmail has, meaning security vulnerabilities in Exim are less survivable than they are in qmail or Postfix, where a buffer overflow (none of which have ever been found, unlike in Exim) only gets you a one-off UID.
I don't know how Exim has managed to brand itself as one of the "secure MTAs", but it's just a marketing trick.
Because Al Jazeera has reporters.
You watched some muslims "dancing in the streets", just like we watched some rednecks beating the shit out of Sikhs after 9/11 because they were thought to be Arabs.
Jackass.
Here are samples, from all three of the cited articles, of what Google didn't want appearing in news search results:
"Honestly, I cannot open a paper or turn on the television without seeing mobs of Muslim savages celebrating in front of burning embassies..."
"Is it really tacky of me to smile at the nightly scenes on TV showing Arab, Afghani and Pakistani Muslims bombing mosques and killing their Muslim brothers, sisters and children at a brisk pace because that's all they know how to do?"
"Islam is moving across the world like a dark, evil cloud."
"Worshiping a sex-maniac and a child molester? [...] Muslims are true victims of Islam. However, they fail to realize that Islam is a cult, and the prophet was a demon ..."
The funnier thing is watching WorldNetDaily stick up for The Jawa Report. Apparently nobody there has seen Star Wars or watched South Park. "Jawas?""You know, sand people."
These aren't news stories critical of Islam. They're "editorials" with as much credibility as content from Stormfront.org.
There has never been a remotely or locally exploitable vulnerability in qmail, regardless of what your Google query tells you.
Here's the table from the paper, ranked best-worst, W=windows, F=freebsd, L=linux, S=singularity:
Read Cycle Counter: W: 2, F: 6, L: 6, W: 2, S: 8
ABI Call: S:87, L:437, W:627, F:878
Thread Yield: S:394, W:753, L:906, F: 911
2-Thread ping-pong: S:1207, W:1658, L: 4041, F: 4707
2-Message ping-pong: S:1452, L: 5797, W: 6244, F: 13304
Process Creation: S: 300000, L: 719000, F: 1032000, W: 5376000
The only stat in this table that Windows trails on is process creation. And anybody who has ever ported Unix code to Win32 knows exactly why: Windows is thread-oriented, and Windows systems don't tend to use helper programs or demand-forking to get work done. Which might be why Windows beats Unix in the thread benchmarks, but not in the IPC benchmarks. On the more general benchmarks, like cycles to issue a system call, Windows falls smack in the middle --- and, again, Windows has a slightly different take on what is and isn't a system call.
Drawing comparisons between Singularity and normal operating systems here is silly. Singularity doesn't have processes in the conventional sense; since there's no hardware dependencies on "process" creation in Singularity, IPC and forking are much faster.
Which is why this benchmark is reasonable inside the Singularity tech report (they're trying to demonstrate that there's a major performance benefit in rethinking boundaries between programs), but totally unreasonably outside that context: these are micro-benchmarks, like the ones CISC and RISC people throw at each other, and don't describe the amount of time it takes to complete a high-level task. Time to execute a system call is meaningful only in the context of how many system calls it takes to complete the task you're measuring.
Wow, you're dumb.
The clerk doesn't need to "obey" your "stupid writing" on the back of your card telling him to "ask for ID". The clerk just needs to be one of the 90% of all clerks who will do the reasonable thing when he sees those words, and ask you for your ID. Among the 90% of clerks who will do that (89% of whom are happy to), 100% of them will decline your purchase if you refuse to comply with your own instructions.
Which is the value of those words on the back of your card.
The "ask ID" trick isn't about identity theft. It's about credit card theft, which is a much simpler and more common crime. It mitigates the damage of losing your wallet, which is a lot more likely to happen than losing your whole identity.
Just like in the movies (read Edward Epstein's excellent Hollywood Economist column in Slate), the expense involved in bringing music to market has almost nothing to do with the physical media; it's marketing and promotion. Complain all you want that the marketing machine we have now produces Britney and boy-bands; the labels spend money like this because it produces a predictable return on their investment. They're going to make business decisions going forward based on that fact, not based on Jobs' iTMS cost structure.
The interesting conversation is how iTMS alters promotion costs. How much of the promotion budget for Universal or Sony goes in to locking up the retail channel (shelf space at Best Buy, etc)? How much does it cost them to promote an album on the high-traffic iTMS front page?
On the other hand, since iTMS represents such a negligable chunk of the revenue of a music label now, it's probably a bit early to have that discussion.
Jobs knows this, which is why he's resorting to the (much less interesting) argument that iTMS reduces piracy. I don't think this is going to do much, because (a) no, it really doesn't --- people pirate music to get it for free, not to get it more conveniently, and (b) piracy doesn't REALLY cost the industry that much money.
Obviously, the song/album price changes under debate right now have everything to do with labels maximizing their returns; they want to jack up prices because they can. So, apropos this Slashdot story, my point is, nobody cares that iTMS lowers costs for the publishers: it's only reducing 2-3% of those costs.
If they were, they wouldn't have done it.
The fact is that Real's move garnered them lots of press attention, and in light of that, they are now obliged to disclaim the possibility of a lawsuit in their filings.
It's probably not that they think Apple is going to sue them out of existence. It's that, if they DIDN'T disclose that, even a minor legal tussle with Apple could be the basis for a shareholders lawsuit.
If you have to ask, you won't get away with it.
The insanely talented and successful people I know with extensive mods would never think to ask. They simply wouldn't take a job that required them to change their appearance.
If that's not where you are in your career, well, suck it up.
Everyone else in this thread babbling about how "unprofessional" and "childish" mods are, well, they can suck it up too. There are people out there who are good enough to come to work every day with eye patch, a jester's cap, and a codpiece. It has nothing to do with the Internet bubble. They're always going to get away with it. It's a good bet that people who complain about them won't ever get away with it. Too bad.
Since you can't explain how IPv6 demonstrably improves security & authentication (IPSec works fine on IPv4), quality of service (vs. MPLS and DiffServ and the extent to which the problem remains unsolved in either protocol), multicast (we can't even figure out how to route it across domains, let alone make it reliable or scale it in routing tables), or autoconfiguration (99% of which is solved by DHCP), and since IPv6 makes routing MUCH HARDER, you're pretty much left with "simplified headers".
So I guess the biggest problem is lack of awareness of how simplified headers solves real problems for network users.
Good luck with that.
Just a guess that a brand-new IIS exploit is probably worth more than a $150 game system.
Tufte's well-known critique of the Columbia presentation, and his famous critique of the Challenger data, centered on the use of visual evidence (idiotic charts, statistically incompetant graphs) and, in the former case, on the manner in which the medium (PowerPoint) butchered the message by making chopping it up into incomprehensible hamster pellets of information.
The author here seems to be making the case that ugly typeface and a poor use of color are to blame; that if we just added a few horizontal rules, maybe put the PDB on nice stationary, it would have been more effective.
When facing a dearth of actionable, analyzable data (like a chart with 4 data points), Tufte is likely as not to advocate doing exactly what the original PDB did, which is to stuff it into prose paragraphs.
Tufte's design criticism work is serious, if perhaps overrated. This new one is just an advertisement for a web designer.
No, I think what you meant to say was, the quickest way to fail would be to try to find a hole in a djb tool.
This scheme is "disgusting" because it capitalizes on the fact that their customers don't know enough about their existing mail software to configure it do to the exact same thing. The only difference between "dmail" and minor Exchange Server deployment change is that the "dmail" scheme is proprietary and comes with vendor lock-in.
Frankly, I think any IT manager that doesn't know enough to have an SMTP system configured to be "private" doesn't know enough to evaluate commercial mail solutions. But I could certainly be wrong, and maybe someone should write the 1-page HOWTO on this.
Establishing less-privileged user accounts, even for the machine's owner, is the single most productive step one can take towards reducing the impact of malware. WinXP makes this possible, but, unfortunately, not necessary.
Why would this be true? All a worm needs to propagate is access to a socket (or to the API of your email agent). This is one of the things that makes worms so powerful.
I certainly don't advocate running systems in single-user configurations (I'm a Mac person, and the Mac handles this elegantly, even if it isn't waterproofed yet). However, as a Unix person at heart, the fact that worms can be effective even against services running as "nobody" in chrooted environments --- often even in systrace-style jails --- is one of the most interesting systems-security implications of the malware problem.
It's far from obvious that "Wall Street" wants Google to "fail" --- they're underwriting the Google IPO. Who do you think Morgan Stanley and CSFB are?
What's more, it's not obvious to everybody that Google's approach is necessarily motivated by helping individual investors (like the average Slashdot reader). For example, take Henry Blodget's recent column on Salon:
Recall that Google is also not the first dot-com darling to choose a dutch auction, either. Other notables include the stunningly successful Salon (heh) and --- wait for it --- Andover.net, back in 1999.A Dutch Auction doesn't necessarily kill the initial pop in a stock offering (there's an argument that it'll increase the value of Google's shares in the early days), and it doesn't cut the underwriters out of the action. They just keep the money they'd be doling out to cronies.
Finally, "do-no-evil" pledge or not, there are objective criticisms of the way Google is handling this IPO, and they aren't coming from Wall Street.
Personally, I wouldn't know the first thing about the true motivations behind Google's actions, but my totally uninformed take is that Google is doing an auction IPO just to be iconoclastic.
The Visual Studio product, which is well-regarded, is:
The Visual Studio product, last time I checked, was not:
I'm not "confusing" the IDE with the compiler when I compare debuggers or UI builders. I wouldn't say that the Visual Studio editor beats the available GCC-integrated option (I think emacs is better). I'm comparing the Visual Studio product offering, which is well-regarded, to the alternatives.
Remember that my original point, apropos this whole Slashdot article, is that Microsoft does make highly-regarded products, and Visual Studio is definitely one of them.
The last time I looked at GCC --- and you can correct me where I'm wrong, but, without citing what Apple has done with Xcode, tell me what out-of-the-box dev environment you're referring to --- GCC was inferior to Visual Studio. Here's why:
I'm sure GCC has made strides (and I think if you factor speed out of the equation, Xcode has surpassed Visual Studio), but when I was doing cross-platform Visual Studio and Linux GCC dev, Visual Studio won hands down. And don't get me wrong: I like Linux better, and my Visual Studio build environment was Cygwin CLI --- but my compile ran faster on Win32, and my debug sessions were easier.
If you think GCC is a great compiler product, I'll agree. I think the fact that Visual Studio bested it is a strong argument for my point that Visual C++ is not a poorly regarded product.
Most widely-used compilers were non-compliant with the C++ spec. Visual C++ generated good code, had a high-quality debugging environment, and still compiles faster than most out-of-the-box alternatives (G++ included).
These "21 Rules Of Thumb" are distilled from McCarthy's "Dynamics of Software Development" book, which has been on the bookshelf of almost every dev lead I've ever worked with or known. You could have a similar "argument" about how good IBM software is (WebSphere?), but at the end of the day, if you're doing it to critique The Mythical Man Month, you're going to sound really dumb.
More importantly, all bitching about MSFT quality aside, McCarthy was dev/program manager on Visual C++, which is not a poorly-regarded Microsoft product (it's one of the best compiler products on the market). There are extremely successful products --- successful on every axis --- that come out of Microsoft. Visual C++, and McCarthy's book, represents one of them. Microsoft Excel, and Joel on Software, represents another.
Microsoft is a huge company with an enormous talent pool and many very qualified, very effective well-jelled teams. You do not sound credible when you try to tar them with the "Microsoft is buggy crap" brush, especially when you're arguing with McCarthy or Spolsky.
The initiative to ADD SMP to OpenBSD (and the announcement that "a full time developer was working on it") occurred less than 4 months ago. It took FreeBSD years to get SMP "right", during an adolesence where stability seriously suffered.
Neither NetBSD nor OpenBSD have a significant fraction of the user base of FreeBSD (and an infinitessimal share compared to Linux), and neither NetBSD nor OpenBSD have comparably-sized development teams. FreeBSD SMP had antecedants to build on as well. So logic dictates that it should take longer for OpenBSD SMP to be "ready".
OpenBSD went through a comparable architecture change when they swapped virtual memory systems a few years ago, and several subsequent major releases of OpenBSD had serious VM stability problems (many of them synchronization issues). SMP is even harder (and more of it involves synchronization).
So, is there some mitigating factor here that would convince anyone who was paying attention to deploy a mission-critical system on SMP OpenBSD in 2004?