The problem with sales people is that in their business, if the project... err, prospect... is "impossible", then you didn't tell a big enough lie so go back and tell a bigger lie.
From a technical point of view, reaching the moon was not an impossible task at all. But it did require resources that the techies of the day would not have been able to get on their own, had some manager given them that directive. That was definitely a project that required not just gung-ho management, but also gung-ho politicians and gung-ho citizens.
Now if only we could get President Bush to issue the special message that we need to have a national last-mile infrastructure to get 1.5 mbps to 99% of urban and 49% of rural locations by 2007, and 100 mbps to 95% of urban locations by 2012. Those are not unrealistic goals at all. And the best part is not only is this not impossible from a techie point of view, but the technology already exists. The issue is the commitment to deployment.
I've had managers before that varied from well experienced, technically, to not at all. Rarely was I asked to perform the impossible. And in those cases where it was impossible, it really was impossible. I simply pointed this out to the manager... and I explained in detail why that was the case. In all cases things got corrected. Maybe I'm not so closed-minded as some techies out there, and I know most everything is possible. The better managers I found came to me with the ideas of what they were considering doing, and asked me to prepare a report on the feasibility and costs (mostly in hours of work) of doing it. I usually included an impact analysis as well. But you can be sure that if I tell my manager that it is impossible, then it really is impossible. Usually the truth is "it'll cost ya". Maybe techies need to learn to say that more often.
... I fix for myself. Slackware is so much easier to do things like rewriting all the init scripts. I don't have the time to create my own distribution, so I very much appreciate all the valuable work Pat V and others put into making this. Now to wait for the store to be un-slashdotted so I can put in my order for a couple of box sets.
When I was in college, there was this 24x7 McDonalds operating across the street a couple blocks up from the four big dorm towers. It was the end of the week before finals and many of us were realizing we were really supposed to be studying all semester, so we were playing catchup on that. Anyway, we needed a break, and at 3 AM, the bars weren't an option.
Someone came down to our floor and announced that 12th floor was going to McD's in 10 minutes, and to spread the word. I ran down to 6th and told them. We were all to meet at the back door closest to McD's. 10 minutes later there were people just pouring out the door. A rough head count put the number at 400. I didn't know that many college students studied.
400 students flooding into McDonalds at 3 AM was definitely a very interesting sight, especially that everyone lined up to order food. Fortunately because it was the end of the semester they had put on a couple extra cashiers. But it did take about half an hour to get all the orders put through. And no, they did NOT run out of fries, but all the fruit tart things were gone. It was definitely SRO. Two police cars came by, but they just stayed outside and watched.
About 300 remained at about the time most people were ready to head back. Right after we crossed the empty street and mostly lined up on the sidewalk heading back to the dorms, one car came by on our side of the street. Everyone thumbed for a ride. It didn't stop.
Quite often, the real cause of software bugs is an inadequate development scheduled. Why blame the programmer for that? If we have a system where programmers always get the blame for crappy software, we'll end up with fewer good programmers, not more, because many will leave the field while managers and corporate executives join in the finger pointing... because... there is a certification system to justify the blame.
No doubt there are bad programmers around, and the numbers are increasing mostly because corporations are trying as much as they can to reduce pay. Only crappy programmers are willing to take the low salaries that can compete against things like H-1B.
If the software is crap, blame first the company that sold it. Then let them review their procedures on how it got to be so crappy.
"We need this package done in 2 months." "OK, 2 months and it will be done. Then 7 more months and it will work right." You think that programmer gets to keep his job, even if he's telling the truth?
Then, ICANN can tell the root servers to stop accepting updates from them.
And do you think ICANN would be so stupid to do that? I hope they do so we can finally get rid of ICANN once and for all.
All country code TLDs should be under the control of the specific country identified. That seems to be the case with many, and maybe most. I think that the government of South Africa has the right to designate who (be it a government department, a corporation, or even an individual) runs the zone, and even specify the policies under which it operates. The fact that some governments already do have that control just makes the case all that much stronger.
I run a DNS server and I can do anything I want with it. I can add domain names to it that someone else owns, nothing is stopping me. However, only people that use that DNS server will see my mapping. Everyone else will see the correct mapping.
What makes you say that any one name space is the correct one? How do you define correct? Is it correct if it's what you think is right? Is it correct just because ICANN runs it?
If I wanted, I could even setup a root with my own TLDs.
My real point is, however, that if it comes down to two different sources of.za TLD zone data, people will demand to use the officially government sanctioned source, as opposed to the one that the current operator runs. If ICANN fails to use the government one, I predict it will be the final stake through the heart of an organization that should have been terminated years ago.
And yes, I will put the South African government sanctioned.za zone delegation in my root zone as soon as they set one up.
See, government control! That is a precedent that the government of South Africa can use. The.ZA namespace does NOT belong to the USA. Therefore it cannot be given by the USA to ICANN. Therefore it does not belong to ICANN, either. It rightly belongs to South Africa. The government of South Africa then has the say on how it is set up, delegated, or whatever.
Who gave ICANN the say so over this? The South African government wanting control over the.za domain seems to me to be less of an issue than ICANN wanting control over the . zone.
Any idiot can break OpenBSD if he dicks around with the configuration. I'm sure "Unbreakable Linux" will suffer the same fate. Of course that's breakability by the administrator. Root access can be a very dangerous thing for most. The question is, can they make a system that can't be broken even by the owner, at least without trying to break it? I doubt it. They'd have to not give root access.
And this won't be the same kind of thing as OpenBSD is. I would trust Theo a whole lot more than Larry or Mike. Where's the source?
What if instead of giving your VHS tape to grandma, you made a copy for her and gave her the copy, keeping the original yourself? IMHO, that's going beyond fair use. I've never examined ReplayTV for myself, but if it lets you send the program over the internet AND keep your own copy, then it's not really any different than making a copy of a VHS tape. The content owners are going to want to fight that more than fight the ability to fast forward over the commercials.
I wonder if this is an anti-trust violation. Given that none of the 4 companies has a monopoly, I would guess not. They do say they are open to any company joining. So what if Microsoft joined?
Actually, yes it does. At least it does in the sense that what is happening here is that the net is self-partitioning through the actions of spammers and anti-spammers into two parts, one with spam, and one without. The latter is owned by the uber-geeks. The blocking of spammers doesn't take down the net; it just isolates the bad parts.
Getting off is generally easy. It's the part of fixing your servers that is not. From what I've seen, the cases where entries continue to be on SPEWS are cases where spam happened yet again. This happens even though "the server is fixed" because of what is known as "multi hop open relay". The ISP getting blacklisted is accepting mail from customer servers that:
Can be reached directly via SMTP.
Are open relays.
Forward outbound mail to the ISP.
It's the ISP that gets listed, because that is the server that's making the connection for which an IP address lookup is made. The first customer that is an open relay might get fixed. The spammers find another, which might well be a new customer. Then the ISP gets listed again. They need to fix their approach to serving customers to get delisted.
A lawsuit won't fix the problem. SPEWS isn't being affected by this and will continue to operate. What the lawsuit will do is ensure that SPEWS never comes out in the open in order to protect itself from such things.
If instead we had a law that shielded blacklist operators from liability, then they could operate entirely in the open. Then it would be a whole lot easier to communicate with the operators. That wouldn't get the stupid ISPs delisted, but they should remain listed anyway, IMHO.
Obviously such a lawsuit shield isn't likely, at least not on a total basis. If we fight hard enough for it, we might get one which limits lawsuits to clear cases of specific matters like fraud.
It's like a bunch of nations getting together to fight terrorism using cowboy tactics. There will be a lot of fire and show, and we'll still have terrorists.
Re:Buy Windows XP Now and forget this Linux Nonsen
on
United Linux is Here
·
· Score: 2
It's not the power of XP that is putting it in the majority of businesses. It can't be, because there is less power in XP. The answer is, it's the hype. That's right, Hype. It's HYPE that drives most of the businesses decisions, and the corporate executives don't even know that the marketing people (in other companies) are the ones who are really driving their decisions through brainwashing hype. Microsoft happens to be the most successful at this.
One core development team? Now I see the scam here. The whole idea is to allow these companies to fire more developers and increase the profits for the greedy.
Why the hell do they need certification if this is going to be based on standards? Why the hell do they need certification if their systems are supposed to work well? Sounds more like a scam to extract more ca$h out of people, since most businesses don't pay extra for certification of any kind (except CCIE).
Why would you be placing the trust of your business into the software of a company that doesn't have the competency to make it work on more than a couple Linux distributions?
If OEMs built different versions of Windows from the source, you can bet that application software developers would find a reason to not support them all. They would end up supporting just one or two flavors of Windows. Hell, they even did that anyway with versions that ran on 98 but not on NT, or visa versa.
I think we need to take a closer look at why some programmers are making lame programs than only work in certain distributions. My bet is they jump to conclusions about how things work instead of trying to understand how things really do work across the scope of several distributions and system types. I've seen some very lame programs that run on Red Hat and not on Mandrake, even when the programmer tries. And I've also seen some programs that were written entirely on Windows and recompiled just fine on Unix and ran not only correctly, but actually faster, too.
If there's a standard we really need today, it's a standard that says no lame programs, and no lame programmers. If your code doesn't work on at least a few systems, you did it wrong.
If your RPMs can't work on all RPM based distributions (assuming the distribution isn't broken... and I assume these distributions are not) then something is wrong with your RPM. If it doesn't work on some specific distribution, then why not? Is the blame because that distribution did something specifically wrong? Or is it because your library function calls are depending on undefined semantics seen only in a specific version of the library?
Join The United Front Opposing Lame Binary Packages!
In Windows it often takes more than one dialog box just to find what you want to do, or if you know where it is already because you have done it a lot, its still more than one to get there. I work faster, better, and simpler, by just executing the command I need to have done without having to spend the time opening up lame dialog boxes. And if I need to do the same thing in a hundred different contexts, instead of having to open one hundred, or twoo hundred, or three hundred dialog boxes, I can drive my one command in all those hundred contexts by wrapping it in a while command in the shell... still interactively. I find that speeding up business really works better by automating with smarter computing, not by flashier prettier computing.
... the standard most businesses are choosing is Red Hat.
That's not true at all. The standard most businesses are still choosing and developing for is not Redhat... it's Windows. Yes, I know you were really speaking in terms of the Linux context. But it's still the same problem. Consider an extreme scenario where Linux manages to oust Windows to say, less than 10% of the market. What will we have then? Linux? No. It will be Red Hat. And if it isn't sanctioned by Red Hat, it won't go anywhere. And in time, someone at Red Hat will become greedy. It may not be the people who are there today, but if that scenario ever happens, you can be sure some very greedy people will be working to take control of Red Hat.
The real problem is not which distribution of Linux is more powerful. No, the real problem is that a distribution of Linux is more powerful. And business in its infinite stupidity is demanding just that. Software developers want just ONE distribution because they are too lame to develop something like portable code that can be compiled on more than one platform.
The whole principle is about choice. While I don't expect the developers of an e-commerce web database system to port it to an embedded Linux setup, I do think it is reasonable to expect them to port it to at least a few different systems so I can have a choice. The problem today is too much software is Windows-only. And given the greater difference between Windows and Unix, I can see how it is hard to cross-port. But when people start talking the very same talk, about having ONE distribution of not just Unix, but of Linux, then that tells me the real problem is not the true difficulty of porting software, or the difference between Windows and Unix... but of the lameness of commercial applications developers.
Your phone company can stop it. Anyone saying otherwise is either lying or stupid. The truth may be that they don't want to stop it. But if enough people cancel out on the e-mail service, that may be hurting them. If there's a competitor phone company that is smarter, it can hurt even more as customers move over to the competitor to get spam-free e-mail.
Paetec made the mistake of agreeing to contract terms that specified that if 2% (I think that was the figure) of the addresses were found to be non-opt-in, that this would be an acceptable margin of error. Presumably MonsterHut would have removed them from the list if asked. Even in the worst case of assuming that every complaint was one of those non-opt-in addresses, the complaints would have had to reach the level of 2% for Paetec to disconnect them under terms of the contact. It's that contact that allowed MonsterHut to get the injunction. MonsterHut didn't need to say that 100% were opt-in... it only needed to say that 98% were opt-in, and Paetec didn't have enough numbers to prove that more than 2% were genuinely non-opt-in, at least not initially.
Paetec made some legal blunders. The rest of us can learn from their mistakes. I'll give Paetec the benefit of the doubt for being fooled in this case. A future company will not get that from me.
One step an ISP can do (if they didn't stupidly sign away any rights to do this) is to put the spammer on static IP and set up reverse DNS to name them with the spammer's domain name. Then I can block the spammer without blocking the ISP, regardless of the stupidity of the ISP's lawyers. And this is my common practice... I block just the spammer if they are in reverse DNS identified static addresses. And I block them by their domain name, so if they move, even to another ISP, they are still blocked. They have to change domain name to evade this (and I'm sure many have).
Also, I do all my anti-spam blocking at the server during the SMTP session. I don't want their spam in my servers, and I don't want rejection notices to sit undelivered for days, either. By stopping spam before the mail is delivered, it doesn't get queued and the sending server has to deal with the rejection (but there is still a rejection in the cases of legitimate mail getting caught so the sender at least knows something happened, and can look for a way around).
I first tried Redhat around 3.0.3 I think it was. What a piece of junk. I stuck with Slackware.
Later I got a cheap Sun Sparc 5 computer and after I got tired of messing with Solaris (lack of source, blah, blah, blah), I wanted to see what Linux would do. Redhat had a Sparc distribution at the time, version 5.1. With that I found that Redhat had improved. So I even tried Redhat on my next x86 box.
As time went one and I upgraded from 5.1 to 5.2 and then to 6.0, I started slipping deeper and deeper into dependency hell. The reason was I upgraded many things by compiling source, and the RPM database just got all out of whack. I was at the point of always doing forced installs of things I did install by RPM, so I was really getting no advantage from the package manager at all. But that wasn't what drove me away.
The system initialization scripts were a nightmare. There were bugs such as the fact that telnet/ssh sessions would not be properly closed when rebooted. The shutdown order seemed right, but maybe it was wrong. I tried re-arranging things but that either didn't help or made things worse. I was at the point of hacking the scripts with little success and a lot of frustration (too many source'd files, too many functions... you are in a maze of twisty passages, all different). I finally decided I had enough and I'd rewrite the init scripts from scratch.
Now that I was going to make such a huge change, I also decided I needed go ahead and solve all my problems, first. I still had machines that were on Slackware that had (luckily) never been switched to Redhat. So I went back to Slackware at version 4.0, and soon 7.0 came out.
I did rewrite the init scripts, and replaced all the Slackware scripts with my own and it runs just fine. My init scripts do have separate scripts for each service to be started or stopped, but everything is in a single subdirectory. There are no symlinks. Run levels are coded in a different way. It's not SYSV, and it's not BSD. But it works, and it's not in source/function hell, and has been solidly reliable for a few years now.
But the real value of all these choices in operating systems and distributions in the free software community is... the choice. The world is most certainly full of different people, and there are different things available for them, including different distributions of Linux, and different flavors of BSD. Not as much choice comes out of the Redmond Washington USA area.
Slashdot Mirror
The problem with sales people is that in their business, if the project ... err, prospect ... is "impossible", then you didn't tell a big enough lie so go back and tell a bigger lie.
From a technical point of view, reaching the moon was not an impossible task at all. But it did require resources that the techies of the day would not have been able to get on their own, had some manager given them that directive. That was definitely a project that required not just gung-ho management, but also gung-ho politicians and gung-ho citizens.
Now if only we could get President Bush to issue the special message that we need to have a national last-mile infrastructure to get 1.5 mbps to 99% of urban and 49% of rural locations by 2007, and 100 mbps to 95% of urban locations by 2012. Those are not unrealistic goals at all. And the best part is not only is this not impossible from a techie point of view, but the technology already exists. The issue is the commitment to deployment.
I've had managers before that varied from well experienced, technically, to not at all. Rarely was I asked to perform the impossible. And in those cases where it was impossible, it really was impossible. I simply pointed this out to the manager ... and I explained in detail why that was the case. In all cases things got corrected. Maybe I'm not so closed-minded as some techies out there, and I know most everything is possible. The better managers I found came to me with the ideas of what they were considering doing, and asked me to prepare a report on the feasibility and costs (mostly in hours of work) of doing it. I usually included an impact analysis as well. But you can be sure that if I tell my manager that it is impossible, then it really is impossible. Usually the truth is "it'll cost ya". Maybe techies need to learn to say that more often.
... I fix for myself. Slackware is so much easier to do things like rewriting all the init scripts. I don't have the time to create my own distribution, so I very much appreciate all the valuable work Pat V and others put into making this. Now to wait for the store to be un-slashdotted so I can put in my order for a couple of box sets.
How about shootemup.com for gun lovers? They can haul in the meat for the bar-b-que.
When I was in college, there was this 24x7 McDonalds operating across the street a couple blocks up from the four big dorm towers. It was the end of the week before finals and many of us were realizing we were really supposed to be studying all semester, so we were playing catchup on that. Anyway, we needed a break, and at 3 AM, the bars weren't an option.
Someone came down to our floor and announced that 12th floor was going to McD's in 10 minutes, and to spread the word. I ran down to 6th and told them. We were all to meet at the back door closest to McD's. 10 minutes later there were people just pouring out the door. A rough head count put the number at 400. I didn't know that many college students studied.
400 students flooding into McDonalds at 3 AM was definitely a very interesting sight, especially that everyone lined up to order food. Fortunately because it was the end of the semester they had put on a couple extra cashiers. But it did take about half an hour to get all the orders put through. And no, they did NOT run out of fries, but all the fruit tart things were gone. It was definitely SRO. Two police cars came by, but they just stayed outside and watched.
About 300 remained at about the time most people were ready to head back. Right after we crossed the empty street and mostly lined up on the sidewalk heading back to the dorms, one car came by on our side of the street. Everyone thumbed for a ride. It didn't stop.
No doubt there are bad programmers around, and the numbers are increasing mostly because corporations are trying as much as they can to reduce pay. Only crappy programmers are willing to take the low salaries that can compete against things like H-1B.
If the software is crap, blame first the company that sold it. Then let them review their procedures on how it got to be so crappy.
"We need this package done in 2 months." "OK, 2 months and it will be done. Then 7 more months and it will work right." You think that programmer gets to keep his job, even if he's telling the truth?
And do you think ICANN would be so stupid to do that? I hope they do so we can finally get rid of ICANN once and for all.
All country code TLDs should be under the control of the specific country identified. That seems to be the case with many, and maybe most. I think that the government of South Africa has the right to designate who (be it a government department, a corporation, or even an individual) runs the zone, and even specify the policies under which it operates. The fact that some governments already do have that control just makes the case all that much stronger.
What makes you say that any one name space is the correct one? How do you define correct? Is it correct if it's what you think is right? Is it correct just because ICANN runs it?
Been there, done that.
My real point is, however, that if it comes down to two different sources of .za TLD zone data, people will demand to use the officially government sanctioned source, as opposed to the one that the current operator runs. If ICANN fails to use the government one, I predict it will be the final stake through the heart of an organization that should have been terminated years ago.
And yes, I will put the South African government sanctioned .za zone delegation in my root zone as soon as they set one up.
See, government control! That is a precedent that the government of South Africa can use. The .ZA namespace does NOT belong to the USA. Therefore it cannot be given by the USA to ICANN. Therefore it does not belong to ICANN, either. It rightly belongs to South Africa. The government of South Africa then has the say on how it is set up, delegated, or whatever.
Who gave ICANN the say so over this? The South African government wanting control over the .za domain seems to me to be less of an issue than ICANN wanting control over the . zone.
Any idiot can break OpenBSD if he dicks around with the configuration. I'm sure "Unbreakable Linux" will suffer the same fate. Of course that's breakability by the administrator. Root access can be a very dangerous thing for most. The question is, can they make a system that can't be broken even by the owner, at least without trying to break it? I doubt it. They'd have to not give root access.
And this won't be the same kind of thing as OpenBSD is. I would trust Theo a whole lot more than Larry or Mike. Where's the source?
What if instead of giving your VHS tape to grandma, you made a copy for her and gave her the copy, keeping the original yourself? IMHO, that's going beyond fair use. I've never examined ReplayTV for myself, but if it lets you send the program over the internet AND keep your own copy, then it's not really any different than making a copy of a VHS tape. The content owners are going to want to fight that more than fight the ability to fast forward over the commercials.
I wonder if this is an anti-trust violation. Given that none of the 4 companies has a monopoly, I would guess not. They do say they are open to any company joining. So what if Microsoft joined?
Actually, yes it does. At least it does in the sense that what is happening here is that the net is self-partitioning through the actions of spammers and anti-spammers into two parts, one with spam, and one without. The latter is owned by the uber-geeks. The blocking of spammers doesn't take down the net; it just isolates the bad parts.
Getting off is generally easy. It's the part of fixing your servers that is not. From what I've seen, the cases where entries continue to be on SPEWS are cases where spam happened yet again. This happens even though "the server is fixed" because of what is known as "multi hop open relay". The ISP getting blacklisted is accepting mail from customer servers that:
It's the ISP that gets listed, because that is the server that's making the connection for which an IP address lookup is made. The first customer that is an open relay might get fixed. The spammers find another, which might well be a new customer. Then the ISP gets listed again. They need to fix their approach to serving customers to get delisted.
A lawsuit won't fix the problem. SPEWS isn't being affected by this and will continue to operate. What the lawsuit will do is ensure that SPEWS never comes out in the open in order to protect itself from such things.
If instead we had a law that shielded blacklist operators from liability, then they could operate entirely in the open. Then it would be a whole lot easier to communicate with the operators. That wouldn't get the stupid ISPs delisted, but they should remain listed anyway, IMHO.
Obviously such a lawsuit shield isn't likely, at least not on a total basis. If we fight hard enough for it, we might get one which limits lawsuits to clear cases of specific matters like fraud.
It's like a bunch of nations getting together to fight terrorism using cowboy tactics. There will be a lot of fire and show, and we'll still have terrorists.
It's not the power of XP that is putting it in the majority of businesses. It can't be, because there is less power in XP. The answer is, it's the hype. That's right, Hype. It's HYPE that drives most of the businesses decisions, and the corporate executives don't even know that the marketing people (in other companies) are the ones who are really driving their decisions through brainwashing hype. Microsoft happens to be the most successful at this.
One core development team? Now I see the scam here. The whole idea is to allow these companies to fire more developers and increase the profits for the greedy.
Why the hell do they need certification if this is going to be based on standards? Why the hell do they need certification if their systems are supposed to work well? Sounds more like a scam to extract more ca$h out of people, since most businesses don't pay extra for certification of any kind (except CCIE).
Why would you be placing the trust of your business into the software of a company that doesn't have the competency to make it work on more than a couple Linux distributions?
If OEMs built different versions of Windows from the source, you can bet that application software developers would find a reason to not support them all. They would end up supporting just one or two flavors of Windows. Hell, they even did that anyway with versions that ran on 98 but not on NT, or visa versa.
I think we need to take a closer look at why some programmers are making lame programs than only work in certain distributions. My bet is they jump to conclusions about how things work instead of trying to understand how things really do work across the scope of several distributions and system types. I've seen some very lame programs that run on Red Hat and not on Mandrake, even when the programmer tries. And I've also seen some programs that were written entirely on Windows and recompiled just fine on Unix and ran not only correctly, but actually faster, too.
If there's a standard we really need today, it's a standard that says no lame programs, and no lame programmers. If your code doesn't work on at least a few systems, you did it wrong.
If your RPMs can't work on all RPM based distributions (assuming the distribution isn't broken ... and I assume these distributions are not) then something is wrong with your RPM. If it doesn't work on some specific distribution, then why not? Is the blame because that distribution did something specifically wrong? Or is it because your library function calls are depending on undefined semantics seen only in a specific version of the library?
Join The United Front Opposing Lame Binary Packages!
In Windows it often takes more than one dialog box just to find what you want to do, or if you know where it is already because you have done it a lot, its still more than one to get there. I work faster, better, and simpler, by just executing the command I need to have done without having to spend the time opening up lame dialog boxes. And if I need to do the same thing in a hundred different contexts, instead of having to open one hundred, or twoo hundred, or three hundred dialog boxes, I can drive my one command in all those hundred contexts by wrapping it in a while command in the shell ... still interactively. I find that speeding up business really works better by automating with smarter computing, not by flashier prettier computing.
That's not true at all. The standard most businesses are still choosing and developing for is not Redhat ... it's Windows. Yes, I know you were really speaking in terms of the Linux context. But it's still the same problem. Consider an extreme scenario where Linux manages to oust Windows to say, less than 10% of the market. What will we have then? Linux? No. It will be Red Hat. And if it isn't sanctioned by Red Hat, it won't go anywhere. And in time, someone at Red Hat will become greedy. It may not be the people who are there today, but if that scenario ever happens, you can be sure some very greedy people will be working to take control of Red Hat.
The real problem is not which distribution of Linux is more powerful. No, the real problem is that a distribution of Linux is more powerful. And business in its infinite stupidity is demanding just that. Software developers want just ONE distribution because they are too lame to develop something like portable code that can be compiled on more than one platform.
The whole principle is about choice. While I don't expect the developers of an e-commerce web database system to port it to an embedded Linux setup, I do think it is reasonable to expect them to port it to at least a few different systems so I can have a choice. The problem today is too much software is Windows-only. And given the greater difference between Windows and Unix, I can see how it is hard to cross-port. But when people start talking the very same talk, about having ONE distribution of not just Unix, but of Linux, then that tells me the real problem is not the true difficulty of porting software, or the difference between Windows and Unix ... but of the lameness of commercial applications developers.
Your phone company can stop it. Anyone saying otherwise is either lying or stupid. The truth may be that they don't want to stop it. But if enough people cancel out on the e-mail service, that may be hurting them. If there's a competitor phone company that is smarter, it can hurt even more as customers move over to the competitor to get spam-free e-mail.
Paetec made the mistake of agreeing to contract terms that specified that if 2% (I think that was the figure) of the addresses were found to be non-opt-in, that this would be an acceptable margin of error. Presumably MonsterHut would have removed them from the list if asked. Even in the worst case of assuming that every complaint was one of those non-opt-in addresses, the complaints would have had to reach the level of 2% for Paetec to disconnect them under terms of the contact. It's that contact that allowed MonsterHut to get the injunction. MonsterHut didn't need to say that 100% were opt-in ... it only needed to say that 98% were opt-in, and Paetec didn't have enough numbers to prove that more than 2% were genuinely non-opt-in, at least not initially.
Paetec made some legal blunders. The rest of us can learn from their mistakes. I'll give Paetec the benefit of the doubt for being fooled in this case. A future company will not get that from me.
One step an ISP can do (if they didn't stupidly sign away any rights to do this) is to put the spammer on static IP and set up reverse DNS to name them with the spammer's domain name. Then I can block the spammer without blocking the ISP, regardless of the stupidity of the ISP's lawyers. And this is my common practice ... I block just the spammer if they are in reverse DNS identified static addresses. And I block them by their domain name, so if they move, even to another ISP, they are still blocked. They have to change domain name to evade this (and I'm sure many have).
Also, I do all my anti-spam blocking at the server during the SMTP session. I don't want their spam in my servers, and I don't want rejection notices to sit undelivered for days, either. By stopping spam before the mail is delivered, it doesn't get queued and the sending server has to deal with the rejection (but there is still a rejection in the cases of legitimate mail getting caught so the sender at least knows something happened, and can look for a way around).
I first tried Redhat around 3.0.3 I think it was. What a piece of junk. I stuck with Slackware.
Later I got a cheap Sun Sparc 5 computer and after I got tired of messing with Solaris (lack of source, blah, blah, blah), I wanted to see what Linux would do. Redhat had a Sparc distribution at the time, version 5.1. With that I found that Redhat had improved. So I even tried Redhat on my next x86 box.
As time went one and I upgraded from 5.1 to 5.2 and then to 6.0, I started slipping deeper and deeper into dependency hell. The reason was I upgraded many things by compiling source, and the RPM database just got all out of whack. I was at the point of always doing forced installs of things I did install by RPM, so I was really getting no advantage from the package manager at all. But that wasn't what drove me away.
The system initialization scripts were a nightmare. There were bugs such as the fact that telnet/ssh sessions would not be properly closed when rebooted. The shutdown order seemed right, but maybe it was wrong. I tried re-arranging things but that either didn't help or made things worse. I was at the point of hacking the scripts with little success and a lot of frustration (too many source'd files, too many functions ... you are in a maze of twisty passages, all different). I finally decided I had enough and I'd rewrite the init scripts from scratch.
Now that I was going to make such a huge change, I also decided I needed go ahead and solve all my problems, first. I still had machines that were on Slackware that had (luckily) never been switched to Redhat. So I went back to Slackware at version 4.0, and soon 7.0 came out.
I did rewrite the init scripts, and replaced all the Slackware scripts with my own and it runs just fine. My init scripts do have separate scripts for each service to be started or stopped, but everything is in a single subdirectory. There are no symlinks. Run levels are coded in a different way. It's not SYSV, and it's not BSD. But it works, and it's not in source/function hell, and has been solidly reliable for a few years now.
But the real value of all these choices in operating systems and distributions in the free software community is ... the choice. The world is most certainly full of different people, and there are different things available for them, including different distributions of Linux, and different flavors of BSD. Not as much choice comes out of the Redmond Washington USA area.