the increasing safety of cars causing people to be less worried about being injured in an accident since the airbag would most likely save them
This phenomenon goes by the name of Homeostasis of Risk. Psychologists and economists investigate it, and if you stick that phrase in google, you'll get 20,000 hits. Some of the hits even look informative.
Wariac writes: Now I hate spam as much as anyone but look at it like the crap I find in my mailbox everyday. It's just one of those things that you learn to deal with (As Taco mentioned...) with filtering.
No can do, Wariac. Email advertising is NOT like paper postal junk mail. Paper postal junk mailers pay through the nose to get their crapola to you. You pay for the spammer to send his/her/its crapola to you. Paper junkmailers, for better or for worse, help finance the US Postal system. Spammers don't. Spammers cost every victim some small amount of money for network connection time, CPU cycles, disk space and either the time to "just hit delete" or the CPU time for filtering.
Besides that Wariac, or should I say "Sanford", suppose that 1 million firms each want to send you 1 spam a year. That's an average of 2739 spams every day of the year. How long does it take you to "just hit delete", Sanford? 1 second? That's 45 minutes a day just hitting delete.
Suppose each of the 2739 spams a day is 2048 bytes. That's 5Mb of disk space that you have to keep around for someone else's oatmeal-for-brains advertisments, Sanford. It's 5Mb of network traffic every day that you didn't ask for and don't want, since you're filtering it anyway.
There can be No Compromise on this issue. Spamming must stop. Spammers must be punished.
Will Microsoft take an active roll in using any "suggestions" from programers regarding bugs in future SPs or versions?
I doubt it. Several years ago, back when NT wasn't a single-architecture Operating System, I talked to a guy who sold file server appliances to DEC. If you recall, the DEC Alpha architecture was the last non-x86 CPU that NT ran on. This salesman told me that DEC engineering was very frustrated with Microsoft, because M$FT wouldn't use any of the bug fixes, performance enhancements, etc that the DEC engineers submitted.
If M$FT won't use bug fixes from DEC, who had a very vigorous engineering department at the time, why should they use a bug fix from some lamer customer site? M$FT and the NT team in particular appears to have nothing but contempt for any outsider's abilities.
You can discount anything that Ronda Hauben says. She's been a usenet pest for at least 5 years. She's well known for 2 things:
1. Persistence
2. An almost fanatical devotion to illogic
3. Stupidity
4. Really nice red costumes.
The only usenet entity I can compare Hauben to is Jon DiNardo. He's just as illogical, just as persistent, and he's been around since '89 or so.
As I understand it, SOAP evolved from XML-RPC. See: http://www.develop.com/soap/soapfaq.htm#22 for a hint at history and ancestry.
I'm of a mixed mind about both SOAP and XML-RPC. XML-RPC includes explict typing of passed values, and SOAP does not. Point to XML-RPC. XML-RPC is substantially simpler than SOAP. Point to XML-RPC.
I bet SOAP wins, because it's heinously complicated. Big companies and big devel shops love complicated: it raises the cost of entry into a market where the complicated standard prevails.
About the windows source... hhm.. there must be some internal documents explaining things, I'm guessing.
I think you guessed wrong. In 1997, the Usenix Association had an NT workshop. One of the discussion groups was called "Do You Need Source ?" - you can find a write-up at http://www.usenix.org/publications/library/proceed ings/usenix-nt97/summaries/ntsums.html . One interesting quote from a researcher who had access to NT source:
Vogels cautioned that NT consists of millions of lines of code and only six pages of documentation, which barely tells you how to get it off the CDs and how to build a kernel from scratch at the top level.
I seriously doubt the situation has improved, given how much more code the Windows 2000 kernel includes and what we outsiders know about Microsoft's internal corporate culture.
Perdida writes:
>Radio shows were sponsored by advertisers and all of their content was, in that sense, a form of spam.
I don't see how you could be more wrong. Email spam, by definition, is an ad in a medium that isn't supported by ad revenue. The spam ad uses resources that the spammer did not pay for - my CPU cycles, my disk space, my network connection time. In effect, email is free to spammer.
Broadcast radio is free to me, but not to the advertiser. The advertisers pay for me. That's a dramatic difference, and one, I think, that you're deliberately ignoring, because you go on to write:
> The freedom of advertising IS the freedom of the press.
Again, you couldn't be more wrong. Advertising has never, ever been a form of protected speech. Why do you think we have such things as truth in advertising laws? I doubt that anyone has proposed a rational argument for considering advertising as free speech.
> Remember, spam is the tool of the small business, the underdog- he who cannot afford the banner ads and other less obtrusive forms of advertising.
Remember that spam is the tool of the small-time crook, the theif- he who doesn't want to pay his own way on the internet, but wants to do the most obtrusive form of advertising.
"Formal methods" sounds really great at first, as does "better quality". But each phrase contains so much hidden meaning that using them identifies you as someone who hasn't really thought about the issues at all.
"Formal methods" falls down because using them assumes that we can specify accurately and precisely what the system should do. And you have to do that specification up front. Such exacting up front specification poses more of a problem than iterative development by service packs and patches.
"Better quality" has no specific meaning. The American Society for Quality says: "Quality is a jubjective term for which each person has his or her own definition." This allows each of us, programmers, managers, salesmen or customers to "know" what quality is, and use the phrase informally. Then, when the rubber has to meet the road, you can't actually write code that represents "quality" because it doesn't exist except as a figment of some executive director's imagination.
Measurement is *not* the heart of science, the scientific method is. Most of these management methodologies are totally unscientific, or suited for an environment other than that in which they are employed.
Besides that (which is enough to render most methodogies irrelevant) what do you propose to measure? Lines of code? "Faults" or "Defects"? "Function Points", or something even less tangible?
I've been involved in several methodologies over the years, starting with TQM and lately a debacle involving CMM. Every single methodolgy promises every thing (zero defects, minimum time to market, guaranteed schedule and budget) to every one, except the developers who actually have to do the work. The key word in "management methodologies" is "management". Don't ignore that.
Slashdot Mirror
the increasing safety of cars causing people to be less worried about being injured in an accident since the airbag would most likely save them
This phenomenon goes by the name of Homeostasis of Risk. Psychologists and economists investigate it, and if you stick that phrase in google, you'll get 20,000 hits. Some of the hits even look informative.
Wariac writes: Now I hate spam as much as anyone but look at it like the crap I find in my mailbox everyday. It's just one of those things that you learn to deal with (As Taco mentioned...) with filtering.
No can do, Wariac. Email advertising is NOT like paper postal junk mail. Paper postal junk mailers pay through the nose to get their crapola to you. You pay for the spammer to send his/her/its crapola to you. Paper junkmailers, for better or for worse, help finance the US Postal system. Spammers don't. Spammers cost every victim some small amount of money for network connection time, CPU cycles, disk space and either the time to "just hit delete" or the CPU time for filtering.
Besides that Wariac, or should I say "Sanford", suppose that 1 million firms each want to send you 1 spam a year. That's an average of 2739 spams every day of the year. How long does it take you to "just hit delete", Sanford? 1 second? That's 45 minutes a day just hitting delete.
Suppose each of the 2739 spams a day is 2048 bytes. That's 5Mb of disk space that you have to keep around for someone else's oatmeal-for-brains advertisments, Sanford. It's 5Mb of network traffic every day that you didn't ask for and don't want, since you're filtering it anyway.
There can be No Compromise on this issue. Spamming must stop. Spammers must be punished.
I doubt it. Several years ago, back when NT wasn't a single-architecture Operating System, I talked to a guy who sold file server appliances to DEC. If you recall, the DEC Alpha architecture was the last non-x86 CPU that NT ran on. This salesman told me that DEC engineering was very frustrated with Microsoft, because M$FT wouldn't use any of the bug fixes, performance enhancements, etc that the DEC engineers submitted. If M$FT won't use bug fixes from DEC, who had a very vigorous engineering department at the time, why should they use a bug fix from some lamer customer site? M$FT and the NT team in particular appears to have nothing but contempt for any outsider's abilities.
You can discount anything that Ronda Hauben says. She's been a usenet pest for at least 5 years. She's well known for 2 things: 1. Persistence 2. An almost fanatical devotion to illogic 3. Stupidity 4. Really nice red costumes. The only usenet entity I can compare Hauben to is Jon DiNardo. He's just as illogical, just as persistent, and he's been around since '89 or so.
As I understand it, SOAP evolved from XML-RPC. See: http://www.develop.com/soap/soapfaq.htm#22 for a hint at history and ancestry.
I'm of a mixed mind about both SOAP and XML-RPC. XML-RPC includes explict typing of passed values, and SOAP does not. Point to XML-RPC. XML-RPC is substantially simpler than SOAP. Point to XML-RPC.
I bet SOAP wins, because it's heinously complicated. Big companies and big devel shops love complicated: it raises the cost of entry into a market where the complicated standard prevails.
Perdida writes: >Radio shows were sponsored by advertisers and all of their content was, in that sense, a form of spam. I don't see how you could be more wrong. Email spam, by definition, is an ad in a medium that isn't supported by ad revenue. The spam ad uses resources that the spammer did not pay for - my CPU cycles, my disk space, my network connection time. In effect, email is free to spammer. Broadcast radio is free to me, but not to the advertiser. The advertisers pay for me. That's a dramatic difference, and one, I think, that you're deliberately ignoring, because you go on to write: > The freedom of advertising IS the freedom of the press. Again, you couldn't be more wrong. Advertising has never, ever been a form of protected speech. Why do you think we have such things as truth in advertising laws? I doubt that anyone has proposed a rational argument for considering advertising as free speech. > Remember, spam is the tool of the small business, the underdog- he who cannot afford the banner ads and other less obtrusive forms of advertising. Remember that spam is the tool of the small-time crook, the theif- he who doesn't want to pay his own way on the internet, but wants to do the most obtrusive form of advertising.
"Formal methods" sounds really great at first, as does "better quality". But each phrase contains so much hidden meaning that using them identifies you as someone who hasn't really thought about the issues at all. "Formal methods" falls down because using them assumes that we can specify accurately and precisely what the system should do. And you have to do that specification up front. Such exacting up front specification poses more of a problem than iterative development by service packs and patches. "Better quality" has no specific meaning. The American Society for Quality says: "Quality is a jubjective term for which each person has his or her own definition." This allows each of us, programmers, managers, salesmen or customers to "know" what quality is, and use the phrase informally. Then, when the rubber has to meet the road, you can't actually write code that represents "quality" because it doesn't exist except as a figment of some executive director's imagination.
Measurement is *not* the heart of science, the scientific method is. Most of these management methodologies are totally unscientific, or suited for an environment other than that in which they are employed.
Besides that (which is enough to render most methodogies irrelevant) what do you propose to measure? Lines of code? "Faults" or "Defects"? "Function Points", or something even less tangible?
I've been involved in several methodologies over the years, starting with TQM and lately a debacle involving CMM. Every single methodolgy promises every thing (zero defects, minimum time to market, guaranteed schedule and budget) to every one, except the developers who actually have to do the work. The key word in "management methodologies" is "management". Don't ignore that.