RTFA. They are offering a free replacement. However, the FDIV bug was overblown. For most people, it didn't matter (few people were using software that required division precise enough to be affected). This bug is even less worrisome. Its effect is, at the moment, completely unobserved in the wild using real world applications. The FDIV bug was apparent to anyone with a calculator.
I'm not saying AMD should be let off the hook completely, but the bug isn't a big problem, they are offering free replacements, and they publicized it. The FDIV bug was bigger (though still hardly catastrophic), refused (at first) to offer replacements, and they sat on it. The two scenarios are nowhere near similar. Maybe AMD just has more character than Intel, or maybe they were watching in 94/95 when the FDIV bug happened and they've actually learned from Intel's mistakes. Regardless, this whole story is more of a heads-up to concerned buyers than a criticism of AMD.
No sufficiently complex system can ever be completely bug-free.
Not to come off as being too sarcastic, but, wow! You came up with that all by yourself?
Seriously, though, that's one of the main tenets of software engineering. Hardware is no different. The phenomenon is well studied and it basically results from the fact that any change you make to a complex system has a certain likelihood of introducing new problems. Also, as you reduce the number of bugs, the complexity of the remaining bugs increases, thus requiring more complicated fixes. Usually, these factors result in a "steady state" number of bugs (that is, there is a point at which the number of bugs you are fixing is equal to the number of bugs you are adding by fixing them).
Therefore, once a system becomes sufficiently complex, it is impossible to eliminate all the bugs. The only way to fix more bugs, therefore, is to reduce complexity. There are other techniques that can be employed to reduce the number of bugs that are introduced per change (e.g. automated regression testing), but that just lowers the steady-state bug count.
From what I read, you don't really understand the problem, either.
Even scientific applications are probably not going to be affected by this because even checking the counter on a for loop seems to provide enough of a break to let the FPU cool off. They also say that no applications that were tested exhibited the problem, and I'd say it's pretty likely the first thing they thought of when they tried applications were heavy floating point applications (scientific apps, GIMPS, etc.).
Maybe you'd see the problem on some really tight FPU code, like something in GIMPS during the torture test, but I doubt it. I think the only way you'd manage to get this problem is if you wrote code specifically to do it.
That said, I agree with your thesis: people really need to be aware that computers can fail for *no good reason*. There are techniques to correct that (e.g. quorum sensing), and any large-scale cluster that requires accuracy should be using such techniques, anyway, as MTTF is inversely related to the number of components being utilized.
There is a lot of confusion about this, so let me explain exactly what is going on here.
Your second example (with the fwrite) is exactly what's being talked about. I don't believe this technique has any use for read (because reads wouldn't require the kernel to keep a temporary copy of anything, and they either block, or return EAGAIN, so there's no real concurrent work going on.
So this subject is about writing. The problem here is that writes are asynchronous. The writes haven't necessarily happened by the time the write call returns. The network layer still has to wait to send the data. However, the kernel cannot guarantee that userspace will not free or overwrite the data it needs to send before it can send it. Therefore, the kernel must copy it.
However, a possible solution is to use CoW for the page(s) that contain the data to send. If the userspace program attempts to free or modify a page that contains the data (note that it doesn't have to be the send data itself, since other data could share the page with the buffer, or the buffer could be freed and reused, or it could be on the stack and a new frame is pushed on, etc). When a write happens on that page, the kernel must not allow the page to change, because it has not finished with it. Therefore, it has to allocate a new page and copy it (note that if the buffer is less than the page size, this is a net loss since the kernel wouldn't have had to copy as much if it had copied the buffer in the first place), and give the *userspace* program the copy (the original must be kept for the kernel because it is probably part of the DMA scatter/gather list that is passed to the network buffer, so its physical address is not allowed to change).
So now let's go through the actual steps of the CoW mechanism so you can understand how slow it can be. When fwrite is called, the CoW mechanism has to mark the page read-only, which means deleting the page from the process' TLB. That means that, the next time the process accesses that page, for either a read or a write, a TLB miss will occur and the page will have to be swapped in. If a write occurs, then the page must be copied for the userspace program. There is a possibility of having two page faults if the page is read then written (the read would result in a TLB miss, and the write would result in a page fault because the page is read-only).
So, in addition to the overhead from copying the page, there is at least one page fault *for every page in the buffer* (if the buffer spans multiple pages and the userspace program reads or writes them all, then that results in a lot of extra overhead0. Furthermore, when the kernel is finished with the page, it has to mark it writable again, which means that, if the page had been reloaded into the TLB due to a read, it will have to be deleted again, thus eventually causing another page fault (if there was a page fault due to a write, then the kernel obviously never marks the page writable again as the page was copied and the userspace program is actually using a different page).
So therefore, we had better hope that the normal case is for the kernel to finish with the page before the userspace program tries to modify it. However, as we have seen in the example code, it's very likely that the code will be written in such a way that the copy will happen, thus making CoW even slower than the copy-everything approach.
Even barring all of that going wrong, the FreeBSD solution is poor because, apparently, it doesn't allow you to really tell when you are allowed to start modifying the page again, because you don't know when the kernel has finished with it. With Linux, the proposed idea is to allow the userspace program to request a notification when the kernel is finished with the buffer, so it can free it or reuse it at its leisure. Without that, any app on FreeBSD is simply guessing (it's a benign race condition in that, even if the race turns out poorly, the correctness of the program isn't affected, but performance is).
I hope that explains everything and, if I've gotten anything wrong, I hope someone corrects me. If you have any more questions, just ask.
It's really not that simple, though. There's not really any ME technology in XP. XP is just 2K with a new GUI, some new kernel features, remote desktop assistance, multi-user switching, and a few other goodies.
Also, how do you factor Server 2K3 into this? I think that Vista has nothing from 2K3, but I could be wrong about that. Personally, I'd say that the XP development cycle should be traced from NT4. Why? Because 2K was the technology behind XP. The next year was spent turning it into a consumer OS, so let's say about 5 years (I think NT4 came out around 1996, but maybe it was 1995). Therefore, Vista is about on par with that (5.5 year from August 2001 when XP was released to OEM to January 2007; my guess is it'll be delayed again, so let's say an even 6 years from XP to Vista).
Therefore, it's about on par with their last release. But when it comes to delays, I don't think any other Windows product was delayed this long (Win95 slipped about a year, I think; if XP is what 2K was supposed to be, then 2K also slipped a year, you could argue).
I have never written a piece of malware. I am capable of doing it, though, as I am familiar with the Windows API, have programmed plenty of network applications, and have used things like keyboard hooks and such, so I could rather easily write a key logger, a spam bot, or a DDoS bot.
I could do all of this, but I don't know anyone who is in the malware business. If I decided I wanted to write a piece of malware, I'd have to resort to the freely available information on various sites. I don't know anyone on a private network, so, if the open information I'm talking about didn't exist, there'd be a barrier for me. I'd need to have connections with people in the network in order to get access to it.
Therefore, for me, it would lower the entry barrier. As I said, it doesn't make it impossible. If I were determined, I could track down people who were in the network and get myself added, and the antivirus companies could probably do the same, under a pseudonym. However, as I've been saying, all that has happened is that the same barrier has been erected for both new malware writers and the antivirus companies.
I'm well aware that viruses existed long before the Internet was widespread, back when everything was distributed via BBS. The job of an antivirus was mostly to scan floppy disks for boot sector viruses. Even then, communication happened, but it's nowhere near the ease with which people can get rootkit and virus code today.
If you don't agree that getting yourself added to a private network is a higher barrier to entry than simply downloading information from a web site or P2P network, then I really don't see any point in arguing further. Anyone in the network will have all the information he needs. It's the ability to get yourself added to that network that's the problem for many would-be malware authors.
The only question in my mind is this: can the malware authors even be forced underground anymore? Taking down obvious malware sites probably won't even affect them a lot because there will always be new ones popping up, just like P2P servers. Lots of countries will have poor (or no) enforcement of such rules, so those will be havens for servers. That point, however, is ancillary to my argument. My point is that, if you could force the malware writers underground, it would hinder them.
Anyway, I'm done arguing. I disagree with your statement that it wasn't harder when my scenario did happen. Simply saying that viruses were rampant in the 90s is not a rebuttal of that. They were a lot less rampant than they are now. That they were there in the 90s seems to be the basis of your argument, and I don't think that proves anything.
I'm not saying that the private networks would disappear. However, if there are private networks, they are, by definition, private, which raises the entry barrier for new rootkit writers. To get access to the code, they must first get access to the private network. If everything is distributed above-board, that barrier disappears.
My point isn't that communication will go away if this distribution were to stop, and I don't even think it should stop, but it does make it easier on the rootkit writers. My point is simply that the two things are related - the harder it is for rootkit owners to communicate, the harder it will be for the antivirus people to track what's happening, and the easier it is for them to communicate, the easier it is for them to be tracked. I wasn't trying to suggest that all communication would cease if it were outlawed, just as I wasn't trying to suggest that all tracking would cease in that same scenario. Both would just become harder.
Tell me about it. I tried to read this on Digg earlier but it was dead. I just got the first page, but it was dead again before I got to the second page. At least the Coral Cache seems to be working now.
There is another side to this, too. It's like bacterial conjugation. If there are certain bits of DNA (code) in the wild that do certain things, that code can be passed around and inserted into other organisms (rootkits) to help them survive. If they were forced underground, it would make it harder for both groups - for the rootkit makers to create better products and for McAfee to track the rootkit makers.
That's not to say that spreading this information is a bad thing, but you have to realize that McAfee is right about one thing - it does help the rootkit makers in addition to helping the anti-rootkit people.
I must disagree with your premise. Novelists excel at choosing words well, but business speak is not the same thing. The words chosen by novelists are chosen for a reason, just as the words chosen by the business people are chosen for a reason. Those reasons differ. The novelist chooses words to describe something, and the right word can really help the reader see what the novelist is trying to portray.
I find it odd that you speak of how the "cynical among us get attached to what a phrase 'really means'." The purpose of language is to convey meaning, emotion, etc. The better the choice of words is at conveying that meaning in a clear, succinct, and unambiguous way, the better is the speaker at using language.
If we were to be uncharitable, therefore, then we would assume that people who practice business speak are poor with language. No doubt, there are people who use business speak because they are unable to conceive better words that describe their meaning, so they mimic those around them. However, I believe that the real reason that most people use such poor language is they no longer realize they are doing it or they are trying to be ambiguous.
People in the first group have fallen victim to peer pressure. They learned to abuse language from others when there was nobody else there to help them. Most probably don't even realize they have a problem. Some do, like the original poster who asked the question. He knows that relenting would contribute to the problem, but he is also unsure whether he is capable of winning on his own grounds.
The second category is where most of the cynics lay their criticisms. The members of this group deliberately use language in a circumspect manner to dilute or destroy its meaning. These people are not only the enemies of language, as suggested above - they are essentially con artists. They are either protecting their own incompetence by shrouding it in eloquence or trying to sell smoke and mirrors by conjuring an illusion. It is these people who make such abuse of language not just a cancer of the English language, but a menace to productivity and invention.
You were told that Windows is a microkernel and Linux is a monolithic kernel. Neither of which is entirely true.
Windows is not a true microkernel because everything still runs in kernel mode (for performance reasons, I assume), even though many parts are actually separated from the kernel. Thus, you lose the main point of the microkernel: that a driver/task cannot bring down the entire system.
Linux is a monolithic kernel (which does not mean it's not a "true" kernel, whatever the hell that means), but it's layered so that parts of the kernel are separated from other parts, and have well-defined interfaces through which they can interact with the rest of the kernel. For example, the filesystems use the VFS layer. The core kernel is relatively small.
In the end, neither one of the designs is significantly different in the amount of stability or size you get out of each. Linux is more modular and more configurable than Windows, but both are really monolithic kernels that are susceptible to bugs in the graphics or network card drivers killing the entire system.
Wow, that's so much easier than booting from the CD and selecting "Repair Boot Loader" from a menu. Of course, that was Mandrake, and everybody knows that's not meant to be user-friendly.
Of course, the message "NTLDR is missing" makes it so obvious to the new user that the MBR is broken. I suppse it really is that easy to follow the instructions. It says right there that you need to boot the Windows CD, select "Recovery Console", enter the administrator password, and type the obvious, "fixmbr" (not to be confused with "fixboot", but that's so obvious, I'm sure no new user could ever screw that up). Yes, I'm sure any new user could do it, right after he figured out what an administrator password is.
If he balks out and drafts his own, we'll have another Solaris/BSD situation
Um, what? That's simply impossible. Linus doesn't like GPLv3, and it's unlikely that Linux could be licensed under it anyway, for the exact same reason he couldn't "rewrite" the license. Linus does not own the copyright to the Linux kernel, so he can't unilaterally change the license any more than Dave Jones or Alan Cox. The problems with the GPLv3 are: Linus doesn't like it (unimportant from a legal standpoint), and the Linux kernel has always been licensed without the "any future version" clause that is standard in other GPL software. Though whether that actually makes a legal difference is up for debate, the Linux kernel will *always* be distributable under GPLv2.
These results aren't presented to try to make Wine look better, nor is the author, consciously or unconsciously, trying to make it appear faster. These results simply were not meant to be used to say that Wine is better than Windows, and only Slashdot would try to make it appear that way.
The real point of these comparisons, as is apparent if you read the Wine weekly summaries, is to give the Wine developers an idea of what areas need to be improved, and what areas are adequate. Green obviously means "at least as fast as Windows", which means that it's good. There is no point in grouping them any other way, since they don't care if they are 50% better or 1% better.
Also, your criticisms of why this benchmark doesn't give a good idea of the relative speeds of Wine and Windows are quite wide of the mark (though they are valid complaints). The real reason why this benchmark cannot be used to gauge relative speeds is that it doesn't cover real world work loads. They measure a very small number of very specific things, mostly related to gaming and 3D performance. The benchmarks they ran that weren't related to that were designed to test the *hardware* speed, not the speed of the API. The Wine developers know this, and that's what the comment about taking it with a grain of salt means. It's probably adequate to give a rough idea of what parts of Wine need to be improved, but it is nowhere close to a comprehensive comparison of the speed of Windows and Wine, and was never meant as such.
Don't feel so bad about the dog.
Dogs who run away very often know they are going to be punished for being "bad". It's very likely that the dog you found simply didn't want to be punished and normally gets along just fine with the owner.
The dog probably got a slap or two on the head, and maybe didn't get his dinner that night, but he was probably fine after that.
Have you ever written kernel code before? You simply cannot write a kernel in standard C. It isn't possible. You need extensions to the language if you are going to be doing that kind of development.
Sometimes you do need extensions, and there's no way around that. The best that GCC can do is provide its strict mode operation so that you can turn them off if you don't need them. Last I checked, the MS compiler didn't have much in the way of a strict mode. It does let you disable certain extensions and enable various features (like variable scoping for declarations in for loops), but it doesn't let you turn them all off.
Finally, when an open source project creates extensions to something, it is much more forgivable than proprietary extensions simply because the extension is documented by the code - other developers can look at the code and figure out exactly how it's supposed to work, plus there will be no patents covering the extensions. Therefore, it's quite possible that extensions in open source can make it into standards, whereas this may not always be possible in proprietary software.
Have you considered that many people are just using it as a spam drop (i.e. a throwaway account for things that require you to enter an email address)?
Um, there is.
Look for a View in Internet Explorer extension for FF. They did actually release a View in Firefox extension for IE, too, but I don't know if that still exists.
Slashdot Mirror
RTFA. They are offering a free replacement. However, the FDIV bug was overblown. For most people, it didn't matter (few people were using software that required division precise enough to be affected). This bug is even less worrisome. Its effect is, at the moment, completely unobserved in the wild using real world applications. The FDIV bug was apparent to anyone with a calculator.
I'm not saying AMD should be let off the hook completely, but the bug isn't a big problem, they are offering free replacements, and they publicized it. The FDIV bug was bigger (though still hardly catastrophic), refused (at first) to offer replacements, and they sat on it. The two scenarios are nowhere near similar. Maybe AMD just has more character than Intel, or maybe they were watching in 94/95 when the FDIV bug happened and they've actually learned from Intel's mistakes. Regardless, this whole story is more of a heads-up to concerned buyers than a criticism of AMD.
Not to come off as being too sarcastic, but, wow! You came up with that all by yourself?
Seriously, though, that's one of the main tenets of software engineering. Hardware is no different. The phenomenon is well studied and it basically results from the fact that any change you make to a complex system has a certain likelihood of introducing new problems. Also, as you reduce the number of bugs, the complexity of the remaining bugs increases, thus requiring more complicated fixes. Usually, these factors result in a "steady state" number of bugs (that is, there is a point at which the number of bugs you are fixing is equal to the number of bugs you are adding by fixing them).
Therefore, once a system becomes sufficiently complex, it is impossible to eliminate all the bugs. The only way to fix more bugs, therefore, is to reduce complexity. There are other techniques that can be employed to reduce the number of bugs that are introduced per change (e.g. automated regression testing), but that just lowers the steady-state bug count.
From what I read, you don't really understand the problem, either.
Even scientific applications are probably not going to be affected by this because even checking the counter on a for loop seems to provide enough of a break to let the FPU cool off. They also say that no applications that were tested exhibited the problem, and I'd say it's pretty likely the first thing they thought of when they tried applications were heavy floating point applications (scientific apps, GIMPS, etc.).
Maybe you'd see the problem on some really tight FPU code, like something in GIMPS during the torture test, but I doubt it. I think the only way you'd manage to get this problem is if you wrote code specifically to do it.
That said, I agree with your thesis: people really need to be aware that computers can fail for *no good reason*. There are techniques to correct that (e.g. quorum sensing), and any large-scale cluster that requires accuracy should be using such techniques, anyway, as MTTF is inversely related to the number of components being utilized.
Damn you. Don't get my hopes up like that.
There is a lot of confusion about this, so let me explain exactly what is going on here.
Your second example (with the fwrite) is exactly what's being talked about. I don't believe this technique has any use for read (because reads wouldn't require the kernel to keep a temporary copy of anything, and they either block, or return EAGAIN, so there's no real concurrent work going on.
So this subject is about writing. The problem here is that writes are asynchronous. The writes haven't necessarily happened by the time the write call returns. The network layer still has to wait to send the data. However, the kernel cannot guarantee that userspace will not free or overwrite the data it needs to send before it can send it. Therefore, the kernel must copy it.
However, a possible solution is to use CoW for the page(s) that contain the data to send. If the userspace program attempts to free or modify a page that contains the data (note that it doesn't have to be the send data itself, since other data could share the page with the buffer, or the buffer could be freed and reused, or it could be on the stack and a new frame is pushed on, etc). When a write happens on that page, the kernel must not allow the page to change, because it has not finished with it. Therefore, it has to allocate a new page and copy it (note that if the buffer is less than the page size, this is a net loss since the kernel wouldn't have had to copy as much if it had copied the buffer in the first place), and give the *userspace* program the copy (the original must be kept for the kernel because it is probably part of the DMA scatter/gather list that is passed to the network buffer, so its physical address is not allowed to change).
So now let's go through the actual steps of the CoW mechanism so you can understand how slow it can be. When fwrite is called, the CoW mechanism has to mark the page read-only, which means deleting the page from the process' TLB. That means that, the next time the process accesses that page, for either a read or a write, a TLB miss will occur and the page will have to be swapped in. If a write occurs, then the page must be copied for the userspace program. There is a possibility of having two page faults if the page is read then written (the read would result in a TLB miss, and the write would result in a page fault because the page is read-only).
So, in addition to the overhead from copying the page, there is at least one page fault *for every page in the buffer* (if the buffer spans multiple pages and the userspace program reads or writes them all, then that results in a lot of extra overhead0. Furthermore, when the kernel is finished with the page, it has to mark it writable again, which means that, if the page had been reloaded into the TLB due to a read, it will have to be deleted again, thus eventually causing another page fault (if there was a page fault due to a write, then the kernel obviously never marks the page writable again as the page was copied and the userspace program is actually using a different page).
So therefore, we had better hope that the normal case is for the kernel to finish with the page before the userspace program tries to modify it. However, as we have seen in the example code, it's very likely that the code will be written in such a way that the copy will happen, thus making CoW even slower than the copy-everything approach.
Even barring all of that going wrong, the FreeBSD solution is poor because, apparently, it doesn't allow you to really tell when you are allowed to start modifying the page again, because you don't know when the kernel has finished with it. With Linux, the proposed idea is to allow the userspace program to request a notification when the kernel is finished with the buffer, so it can free it or reuse it at its leisure. Without that, any app on FreeBSD is simply guessing (it's a benign race condition in that, even if the race turns out poorly, the correctness of the program isn't affected, but performance is).
I hope that explains everything and, if I've gotten anything wrong, I hope someone corrects me. If you have any more questions, just ask.
It's really not that simple, though. There's not really any ME technology in XP. XP is just 2K with a new GUI, some new kernel features, remote desktop assistance, multi-user switching, and a few other goodies.
Also, how do you factor Server 2K3 into this? I think that Vista has nothing from 2K3, but I could be wrong about that. Personally, I'd say that the XP development cycle should be traced from NT4. Why? Because 2K was the technology behind XP. The next year was spent turning it into a consumer OS, so let's say about 5 years (I think NT4 came out around 1996, but maybe it was 1995). Therefore, Vista is about on par with that (5.5 year from August 2001 when XP was released to OEM to January 2007; my guess is it'll be delayed again, so let's say an even 6 years from XP to Vista).
Therefore, it's about on par with their last release. But when it comes to delays, I don't think any other Windows product was delayed this long (Win95 slipped about a year, I think; if XP is what 2K was supposed to be, then 2K also slipped a year, you could argue).
I have never written a piece of malware. I am capable of doing it, though, as I am familiar with the Windows API, have programmed plenty of network applications, and have used things like keyboard hooks and such, so I could rather easily write a key logger, a spam bot, or a DDoS bot.
I could do all of this, but I don't know anyone who is in the malware business. If I decided I wanted to write a piece of malware, I'd have to resort to the freely available information on various sites. I don't know anyone on a private network, so, if the open information I'm talking about didn't exist, there'd be a barrier for me. I'd need to have connections with people in the network in order to get access to it.
Therefore, for me, it would lower the entry barrier. As I said, it doesn't make it impossible. If I were determined, I could track down people who were in the network and get myself added, and the antivirus companies could probably do the same, under a pseudonym. However, as I've been saying, all that has happened is that the same barrier has been erected for both new malware writers and the antivirus companies.
I'm well aware that viruses existed long before the Internet was widespread, back when everything was distributed via BBS. The job of an antivirus was mostly to scan floppy disks for boot sector viruses. Even then, communication happened, but it's nowhere near the ease with which people can get rootkit and virus code today.
If you don't agree that getting yourself added to a private network is a higher barrier to entry than simply downloading information from a web site or P2P network, then I really don't see any point in arguing further. Anyone in the network will have all the information he needs. It's the ability to get yourself added to that network that's the problem for many would-be malware authors.
The only question in my mind is this: can the malware authors even be forced underground anymore? Taking down obvious malware sites probably won't even affect them a lot because there will always be new ones popping up, just like P2P servers. Lots of countries will have poor (or no) enforcement of such rules, so those will be havens for servers. That point, however, is ancillary to my argument. My point is that, if you could force the malware writers underground, it would hinder them.
Anyway, I'm done arguing. I disagree with your statement that it wasn't harder when my scenario did happen. Simply saying that viruses were rampant in the 90s is not a rebuttal of that. They were a lot less rampant than they are now. That they were there in the 90s seems to be the basis of your argument, and I don't think that proves anything.
I'm not saying that the private networks would disappear. However, if there are private networks, they are, by definition, private, which raises the entry barrier for new rootkit writers. To get access to the code, they must first get access to the private network. If everything is distributed above-board, that barrier disappears.
My point isn't that communication will go away if this distribution were to stop, and I don't even think it should stop, but it does make it easier on the rootkit writers. My point is simply that the two things are related - the harder it is for rootkit owners to communicate, the harder it will be for the antivirus people to track what's happening, and the easier it is for them to communicate, the easier it is for them to be tracked. I wasn't trying to suggest that all communication would cease if it were outlawed, just as I wasn't trying to suggest that all tracking would cease in that same scenario. Both would just become harder.
Tell me about it. I tried to read this on Digg earlier but it was dead. I just got the first page, but it was dead again before I got to the second page. At least the Coral Cache seems to be working now.
No, no. You are 1 - (0.2 * 0.2) = 96% likely to be a mass murderer. If you want 99% likelihood, you're going to need another one.
There is another side to this, too. It's like bacterial conjugation. If there are certain bits of DNA (code) in the wild that do certain things, that code can be passed around and inserted into other organisms (rootkits) to help them survive. If they were forced underground, it would make it harder for both groups - for the rootkit makers to create better products and for McAfee to track the rootkit makers.
That's not to say that spreading this information is a bad thing, but you have to realize that McAfee is right about one thing - it does help the rootkit makers in addition to helping the anti-rootkit people.
I must disagree with your premise. Novelists excel at choosing words well, but business speak is not the same thing. The words chosen by novelists are chosen for a reason, just as the words chosen by the business people are chosen for a reason. Those reasons differ. The novelist chooses words to describe something, and the right word can really help the reader see what the novelist is trying to portray.
I find it odd that you speak of how the "cynical among us get attached to what a phrase 'really means'." The purpose of language is to convey meaning, emotion, etc. The better the choice of words is at conveying that meaning in a clear, succinct, and unambiguous way, the better is the speaker at using language.
If we were to be uncharitable, therefore, then we would assume that people who practice business speak are poor with language. No doubt, there are people who use business speak because they are unable to conceive better words that describe their meaning, so they mimic those around them. However, I believe that the real reason that most people use such poor language is they no longer realize they are doing it or they are trying to be ambiguous.
People in the first group have fallen victim to peer pressure. They learned to abuse language from others when there was nobody else there to help them. Most probably don't even realize they have a problem. Some do, like the original poster who asked the question. He knows that relenting would contribute to the problem, but he is also unsure whether he is capable of winning on his own grounds.
The second category is where most of the cynics lay their criticisms. The members of this group deliberately use language in a circumspect manner to dilute or destroy its meaning. These people are not only the enemies of language, as suggested above - they are essentially con artists. They are either protecting their own incompetence by shrouding it in eloquence or trying to sell smoke and mirrors by conjuring an illusion. It is these people who make such abuse of language not just a cancer of the English language, but a menace to productivity and invention.
And so you have been told incorrectly.
You were told that Windows is a microkernel and Linux is a monolithic kernel. Neither of which is entirely true.
Windows is not a true microkernel because everything still runs in kernel mode (for performance reasons, I assume), even though many parts are actually separated from the kernel. Thus, you lose the main point of the microkernel: that a driver/task cannot bring down the entire system.
Linux is a monolithic kernel (which does not mean it's not a "true" kernel, whatever the hell that means), but it's layered so that parts of the kernel are separated from other parts, and have well-defined interfaces through which they can interact with the rest of the kernel. For example, the filesystems use the VFS layer. The core kernel is relatively small.
In the end, neither one of the designs is significantly different in the amount of stability or size you get out of each. Linux is more modular and more configurable than Windows, but both are really monolithic kernels that are susceptible to bugs in the graphics or network card drivers killing the entire system.
Wow, that's so much easier than booting from the CD and selecting "Repair Boot Loader" from a menu. Of course, that was Mandrake, and everybody knows that's not meant to be user-friendly.
Of course, the message "NTLDR is missing" makes it so obvious to the new user that the MBR is broken. I suppse it really is that easy to follow the instructions. It says right there that you need to boot the Windows CD, select "Recovery Console", enter the administrator password, and type the obvious, "fixmbr" (not to be confused with "fixboot", but that's so obvious, I'm sure no new user could ever screw that up). Yes, I'm sure any new user could do it, right after he figured out what an administrator password is.
Um, what? That's simply impossible. Linus doesn't like GPLv3, and it's unlikely that Linux could be licensed under it anyway, for the exact same reason he couldn't "rewrite" the license. Linus does not own the copyright to the Linux kernel, so he can't unilaterally change the license any more than Dave Jones or Alan Cox. The problems with the GPLv3 are: Linus doesn't like it (unimportant from a legal standpoint), and the Linux kernel has always been licensed without the "any future version" clause that is standard in other GPL software. Though whether that actually makes a legal difference is up for debate, the Linux kernel will *always* be distributable under GPLv2.
tags whenever I use two newlines like all other message boards? Sorry for the big blob of text.
These results aren't presented to try to make Wine look better, nor is the author, consciously or unconsciously, trying to make it appear faster. These results simply were not meant to be used to say that Wine is better than Windows, and only Slashdot would try to make it appear that way. The real point of these comparisons, as is apparent if you read the Wine weekly summaries, is to give the Wine developers an idea of what areas need to be improved, and what areas are adequate. Green obviously means "at least as fast as Windows", which means that it's good. There is no point in grouping them any other way, since they don't care if they are 50% better or 1% better. Also, your criticisms of why this benchmark doesn't give a good idea of the relative speeds of Wine and Windows are quite wide of the mark (though they are valid complaints). The real reason why this benchmark cannot be used to gauge relative speeds is that it doesn't cover real world work loads. They measure a very small number of very specific things, mostly related to gaming and 3D performance. The benchmarks they ran that weren't related to that were designed to test the *hardware* speed, not the speed of the API. The Wine developers know this, and that's what the comment about taking it with a grain of salt means. It's probably adequate to give a rough idea of what parts of Wine need to be improved, but it is nowhere close to a comprehensive comparison of the speed of Windows and Wine, and was never meant as such.
Don't feel so bad about the dog. Dogs who run away very often know they are going to be punished for being "bad". It's very likely that the dog you found simply didn't want to be punished and normally gets along just fine with the owner. The dog probably got a slap or two on the head, and maybe didn't get his dinner that night, but he was probably fine after that.
It also depends on where it lands.
Have you ever written kernel code before? You simply cannot write a kernel in standard C. It isn't possible. You need extensions to the language if you are going to be doing that kind of development. Sometimes you do need extensions, and there's no way around that. The best that GCC can do is provide its strict mode operation so that you can turn them off if you don't need them. Last I checked, the MS compiler didn't have much in the way of a strict mode. It does let you disable certain extensions and enable various features (like variable scoping for declarations in for loops), but it doesn't let you turn them all off. Finally, when an open source project creates extensions to something, it is much more forgivable than proprietary extensions simply because the extension is documented by the code - other developers can look at the code and figure out exactly how it's supposed to work, plus there will be no patents covering the extensions. Therefore, it's quite possible that extensions in open source can make it into standards, whereas this may not always be possible in proprietary software.
Have you considered that many people are just using it as a spam drop (i.e. a throwaway account for things that require you to enter an email address)?
Um, there is. Look for a View in Internet Explorer extension for FF. They did actually release a View in Firefox extension for IE, too, but I don't know if that still exists.