Define 'stable'. Often those "beta" releases are, in terms of how well they operate, as stable as or more stable than the production releases of commercial software. My rough estimate, from experience, is that at least a third of "professional" projects fail or are abandoned before reaching even the state of the typical "beta" project on FreshMeat, and at least half the remainder never reach "beta" quality even in their production releases. Internet Explorer 5.5, for example, generates an "Illegal Operation" error and dies about 3 times as often as Netscape 6 Preview 3 crashes on me, and NS6pr3 doesn't destabilize the whole rest of my system when it goes down. Similar stats apply for MSWord vs. StarOffice, and I despair of ever getting the Lotus Notes 5 client stable on an NT4SP6 system. And if you had to use NCR's C++ compiler, after not too long you would pray for the opportunity to be able to use an unstable development release of GCC because it'd handle the code better and not die as often. Bluntly put, if you abandon labels and examine equivalent functionality and stability levels, professional commercial software starts to look really shabby by comparison.
On mass-market software, which is the closest fit to most OSS projects, let me ask this: how does a lack of a formal requirements process stop users from e-mailing the author saying they'd find a particular feature useful? Where did this obsession with the idea that things are either formalized or non-existent come from?
Immediate thought: if the OSS community has successfully developed applications using methods that would make the bigger, "professional" closed-source operations go under, doesn't this suggest something is different about the OSS projects? If there weren't, why aren't the OSS projects auguring in like the "professional" ones would?
First thought: OSS projects aren't written to satisfy a client's requirements, they're written to do a job. I've seen too many commercial projects where whether it worked or not was secondary to whether it met the requirements document ( the two are not synonymous ). OSS tends to consider requirements secondary to working, and natural selection by the users prunes off branches that don't work in ways people find useful.
But do you apply the same rules to the Windows boxes, by denying local administrative access to users? It's the same thing, someone with local admin access on a Windows box ( which pretty much means all Win95/98 boxes, unfortunately ) can run rogue servers including DNS and NIS and IIS and the like exactly as they could with root on a Unix box. It's not the OS, it's the access. I've got local admin access on the NT box I have at work ( bad thing, but for various reasons nobody ever took it away ), and you don't even want to think about some of the things I'd probably be able to do ( rogue PDC, anyone? ).
And BTW, you can'trsh root-to-root automatically if the target machine is properly set up. My systems are set up to automatically refuse rsh access from root on other boxes. You want to do that, you use SSH instead with it's better access controls ( also applied on the target box, not the source ).
Frankly I find Microsoft's suggestions as to what salespeople should point out to me as a customer anywhere from insulting to... well, horribly insulting. My likely responses to said salesman:
I know the system needs an OS. If I wanted you to supply said OS I would ask for it. If I do not, then presumably I intend to supply it myself, perhaps from the OS media for the last PC I bought and am now replacing.
I'm sorry, were you suggesting I am a criminal? Starting off by insulting me like that is not the way to build a business relationship. Sorry, I'll take my business to someone with a better grasp of manners.
You're the best-qualified? OK, which versions of OS/2 do you have available? How about FreeBSD? Oh, you've no idea what those are, do you. Then how are you qualified to install them?
And one primary difference between, say, ESR's role with fetchmail and traditional management: traditional management is there. Like them or not, agree with them or not, they are a constant. ESR, on the other hand, could have been displaced if he was found to be less appropriate than someone else.
The article missed one point: anyone can contribute whatever they want to fetchmail and release their version of it, regardless of what ESR thinks. If some person or group does a better job with their version than ESR is doing, ESR will be supplanted by the user community voting with their feet. This is the critical difference between OSS projects and traditional management. And yes, it does work. Take a look at gcc, where egcs was starting to supplant it by doing a better job.
I think VOS has a problem, because this trick dates way back. IBM's mainframes were creating virtual 360's back in the late 1970's to run other OSes hosted under VM.
Copying the general layout is legal. Maybe not polite, but legal.
Copying the underlying HTML directly is not acceptable. Writing your own to acheive the same effect is fine, even if the results are identical to the original, but directly copying the source is not OK.
Copying the actual graphics and such is not acceptable. You can make yours similar, but you can't steal someone else's images.
Deliberately duplicating the entirety of a site's appearance simply to duplicate it isn't exactly the mark of originality. Better to take inspiration and create something of your own than to just copycat someone else's success. Also more satisfying, and more likely to impress others.
Not quite. What MS will is likely what they have done with the Mac: make a version that, while enough to let them claim to support Linux, is actually lacking in features that one would expect ( and that native Linux suites routinely offer ), buggier and more bloated and lower in performance, and then recommend switching to the "superior" Windows version when people complain.
when I read the article, the most vivid impression I get is of Ranum moaning that people working for competitors can too easily poke holes in his company's products. Perhaps, instead of complaining that people are finding the holes, he should encourage his own people to either fix the holes or not create them in the first place?
True, but it insures that the packets can be traced back to at least the originating ISP. At that point, knowing that one of their customers is launching such an attack, they can use other methods to track him down.
True, but any one ISP shouldn't be trying to block out all bad sources. That's just too large a job. They should implement inbound filtering to reject private addresses and packets coming from outside claiming to be from internal addresses, and implement outbound filtering to limit packets to only legal internal addresses. The exception might be NSPs who primarily provide transport for other networks, and they should require inbound/outbound filters on their customer's networks as part of their terms of service.
In fact, what I just described is the default firewall setup I use on my own home network. Probably not needed, but why not?
You don't anti-spoof each individual connection. Even ISPs usually allocate dial-in addresses in blocks, and you anti-spoof the entire block in one shot. Remember that it doesn't matter whether the address is currently in use or not, you can still anti-spoof it either way. That reduces it from one ACL per address to one ACL per contiguous block the ISP owns.
If it's the part in the hardware that's hard to reverse-engineer, wouldn't it remain just as hard if the driver source were available? If so, keeping the driver source closed doesn't protect anything. Having it might enable the competition to write drivers for that hardware, but they still can't make a replacement for the hardware so people will still have to go to the original company for it. No loss to the original company there.
First, the company isn't protecting their technology by limiting it to closed-source Windows drivers only. Their competition has engineers and labs and money, and can and will reverse-engineer the Windows drives. It'll take them a few weeks longer and force them to add a couple-three dollars to the price of their product to preserve their profits, but that's about it.
Binary-only drivers turn into a headache when new kernels come out, or people compile their own kernels to their own preferences. Source for kernel modules can be recompiled to match the kernel by whoever recompiled the kernel. Binary modules can only be done by the company releasing them. Does the company really want to take on the job of tracking every single kernel release out there?
If Linux and other open-source OSes take off in more wide-spread use, companies that have Linux drivers lagging behind the Windows ones in capabilities risk getting left behind on both fronts. If the apps using your cards need, because of creator decisions, to run on both Windows and Linux, they will avoid using things available only under Windows. If your competition starts opening up, those apps will be able to use the more advanced stuff and will work better, and people will start to shift towards them even when they only run Windows ( because all of their friends who run mixed systems use the competition's stuff ).
Sometimes I think we're getting to a point where protecting your rights in something and making a profit from it are starting to be incompatible. Much like printed books: the only way to completely stop people from copying them is to not publish them, but you've got to publish if you want to make any money selling your books.
Well, I wouldn't prevent them from trying. But then, their tricks only disable the Back button, not the history list, so I just pull that down and leave the site and never come back. Rule #1 these guys need to learn: make it difficult for the customer to do what he wants, even if that's to leave, and you will lose that customer and 10 others. Marketing 101.
True on what MS is doing. But interesting twist: what if the German courts, faced with that, rule that using technical means to circumvent the law ( eg. using hardware-specific locks to prevent legal unbundling ) is itself illegal?
True points, but there's one difference. You're talking about, most likely, pings of specific hosts, or VRFYs of specific e-mail addresses. No, those aren't enough to raise flags. But Quova is running scans of entire networks. Repeated pings through your entire address space, or repeated VRFYs scanning all possible mail addresses, are just a little more alarming than individual ones. And the fact that they want to do their scans without alerting me to the fact that they're scanning is even more alarming. That they want to scan is bad enough, but why do they want me not knowing they're scanning?
Their pinging and tracerouting itself doesn't bother me a great deal. My firewalls can deal with that. The fact that they apparently want to get underneath my detection software so they can do this without setting off my alarms, however, bothers me a great deal. There's no legitimate reason to do that. So, time to track down their netblocks and drop everything from or to them into a black hole at the edge of my network.
In this case, you'd have to go to whoever owns the rights to Tux. They could go to that company and tell them to stop using Tux to imply Linux compatibility or be sued for trademark infringement, and back it up. That's about it. Distro brands like RedHat or Debian could enforce this on use of their logos as well, eg. Debian could keep companies from using the Debian logo on their products unless they satisfied Debian that their products worked to Debian's satisfaction with Linux.
One major difference I see between Afternic and the other registrars: the others are primarily pushing registration with the resale being almost an afterthought, while Afternic seems from thier home page to be mainly aiming for resale with registration primarily to support that resale. To me this makes a world of difference.
One problem: P3P blocks access to the site as soon as the negotiation is complete if it doesn't fit my requirements. I don't want that. I simply want to not give that site the data I don't wish it to have. Why should I tell them I don't want to give out that data as soon as I enter the site, as opposed to only refusing to give it when they finally ask for it? My preferences are private information as well, after all.
First, cancelling the account of the victim probably won't shut down the DoS attack, at least not for quite a while. The attacker has to notice that his target's not there anymore before he'll stop.
Second, regarding the nudist-in-WalMart analogy. The nudist might be removed, but he will be removed for his disruption of business. Cancelling a DoS victim's account is more akin to throwing out other people in the store because the nudist might make them gawk and that might disrupt business. Which just plain doesn't make sense.
You might want to think about the consequences if it becomes acceptable to terminate your service because someone else has taken an irrational dislike to you and decided to attack you.
Because the big guy can afford big-guns lawyers of his own and just might win. So you go after the little guys who can't afford to fight and set precedents with your wins there before touching the big guys.
Slashdot Mirror
Define 'stable'. Often those "beta" releases are, in terms of how well they operate, as stable as or more stable than the production releases of commercial software. My rough estimate, from experience, is that at least a third of "professional" projects fail or are abandoned before reaching even the state of the typical "beta" project on FreshMeat, and at least half the remainder never reach "beta" quality even in their production releases. Internet Explorer 5.5, for example, generates an "Illegal Operation" error and dies about 3 times as often as Netscape 6 Preview 3 crashes on me, and NS6pr3 doesn't destabilize the whole rest of my system when it goes down. Similar stats apply for MSWord vs. StarOffice, and I despair of ever getting the Lotus Notes 5 client stable on an NT4SP6 system. And if you had to use NCR's C++ compiler, after not too long you would pray for the opportunity to be able to use an unstable development release of GCC because it'd handle the code better and not die as often. Bluntly put, if you abandon labels and examine equivalent functionality and stability levels, professional commercial software starts to look really shabby by comparison.
On mass-market software, which is the closest fit to most OSS projects, let me ask this: how does a lack of a formal requirements process stop users from e-mailing the author saying they'd find a particular feature useful? Where did this obsession with the idea that things are either formalized or non-existent come from?
Immediate thought: if the OSS community has successfully developed applications using methods that would make the bigger, "professional" closed-source operations go under, doesn't this suggest something is different about the OSS projects? If there weren't, why aren't the OSS projects auguring in like the "professional" ones would?
First thought: OSS projects aren't written to satisfy a client's requirements, they're written to do a job. I've seen too many commercial projects where whether it worked or not was secondary to whether it met the requirements document ( the two are not synonymous ). OSS tends to consider requirements secondary to working, and natural selection by the users prunes off branches that don't work in ways people find useful.
But do you apply the same rules to the Windows boxes, by denying local administrative access to users? It's the same thing, someone with local admin access on a Windows box ( which pretty much means all Win95/98 boxes, unfortunately ) can run rogue servers including DNS and NIS and IIS and the like exactly as they could with root on a Unix box. It's not the OS, it's the access. I've got local admin access on the NT box I have at work ( bad thing, but for various reasons nobody ever took it away ), and you don't even want to think about some of the things I'd probably be able to do ( rogue PDC, anyone? ).
And BTW, you can't rsh root-to-root automatically if the target machine is properly set up. My systems are set up to automatically refuse rsh access from root on other boxes. You want to do that, you use SSH instead with it's better access controls ( also applied on the target box, not the source ).
Frankly I find Microsoft's suggestions as to what salespeople should point out to me as a customer anywhere from insulting to... well, horribly insulting. My likely responses to said salesman:
And one primary difference between, say, ESR's role with fetchmail and traditional management: traditional management is there. Like them or not, agree with them or not, they are a constant. ESR, on the other hand, could have been displaced if he was found to be less appropriate than someone else.
The article missed one point: anyone can contribute whatever they want to fetchmail and release their version of it, regardless of what ESR thinks. If some person or group does a better job with their version than ESR is doing, ESR will be supplanted by the user community voting with their feet. This is the critical difference between OSS projects and traditional management. And yes, it does work. Take a look at gcc, where egcs was starting to supplant it by doing a better job.
This is hardly a cause for concern, seeing as how Tom's Hardware has an article on how to change the settings without needing the pins.
I think VOS has a problem, because this trick dates way back. IBM's mainframes were creating virtual 360's back in the late 1970's to run other OSes hosted under VM.
My thoughts:
Not quite. What MS will is likely what they have done with the Mac: make a version that, while enough to let them claim to support Linux, is actually lacking in features that one would expect ( and that native Linux suites routinely offer ), buggier and more bloated and lower in performance, and then recommend switching to the "superior" Windows version when people complain.
when I read the article, the most vivid impression I get is of Ranum moaning that people working for competitors can too easily poke holes in his company's products. Perhaps, instead of complaining that people are finding the holes, he should encourage his own people to either fix the holes or not create them in the first place?
True, but it insures that the packets can be traced back to at least the originating ISP. At that point, knowing that one of their customers is launching such an attack, they can use other methods to track him down.
True, but any one ISP shouldn't be trying to block out all bad sources. That's just too large a job. They should implement inbound filtering to reject private addresses and packets coming from outside claiming to be from internal addresses, and implement outbound filtering to limit packets to only legal internal addresses. The exception might be NSPs who primarily provide transport for other networks, and they should require inbound/outbound filters on their customer's networks as part of their terms of service.
In fact, what I just described is the default firewall setup I use on my own home network. Probably not needed, but why not?
You don't anti-spoof each individual connection. Even ISPs usually allocate dial-in addresses in blocks, and you anti-spoof the entire block in one shot. Remember that it doesn't matter whether the address is currently in use or not, you can still anti-spoof it either way. That reduces it from one ACL per address to one ACL per contiguous block the ISP owns.
If it's the part in the hardware that's hard to reverse-engineer, wouldn't it remain just as hard if the driver source were available? If so, keeping the driver source closed doesn't protect anything. Having it might enable the competition to write drivers for that hardware, but they still can't make a replacement for the hardware so people will still have to go to the original company for it. No loss to the original company there.
A couple of thoughts here.
- First, the company isn't protecting their technology by limiting it to closed-source Windows drivers only. Their competition has engineers and labs and money, and can and will reverse-engineer the Windows drives. It'll take them a few weeks longer and force them to add a couple-three dollars to the price of their product to preserve their profits, but that's about it.
- Binary-only drivers turn into a headache when new kernels come out, or people compile their own kernels to their own preferences. Source for kernel modules can be recompiled to match the kernel by whoever recompiled the kernel. Binary modules can only be done by the company releasing them. Does the company really want to take on the job of tracking every single kernel release out there?
- If Linux and other open-source OSes take off in more wide-spread use, companies that have Linux drivers lagging behind the Windows ones in capabilities risk getting left behind on both fronts. If the apps using your cards need, because of creator decisions, to run on both Windows and Linux, they will avoid using things available only under Windows. If your competition starts opening up, those apps will be able to use the more advanced stuff and will work better, and people will start to shift towards them even when they only run Windows ( because all of their friends who run mixed systems use the competition's stuff ).
Sometimes I think we're getting to a point where protecting your rights in something and making a profit from it are starting to be incompatible. Much like printed books: the only way to completely stop people from copying them is to not publish them, but you've got to publish if you want to make any money selling your books.Well, I wouldn't prevent them from trying. But then, their tricks only disable the Back button, not the history list, so I just pull that down and leave the site and never come back. Rule #1 these guys need to learn: make it difficult for the customer to do what he wants, even if that's to leave, and you will lose that customer and 10 others. Marketing 101.
True on what MS is doing. But interesting twist: what if the German courts, faced with that, rule that using technical means to circumvent the law ( eg. using hardware-specific locks to prevent legal unbundling ) is itself illegal?
True points, but there's one difference. You're talking about, most likely, pings of specific hosts, or VRFYs of specific e-mail addresses. No, those aren't enough to raise flags. But Quova is running scans of entire networks. Repeated pings through your entire address space, or repeated VRFYs scanning all possible mail addresses, are just a little more alarming than individual ones. And the fact that they want to do their scans without alerting me to the fact that they're scanning is even more alarming. That they want to scan is bad enough, but why do they want me not knowing they're scanning?
Their pinging and tracerouting itself doesn't bother me a great deal. My firewalls can deal with that. The fact that they apparently want to get underneath my detection software so they can do this without setting off my alarms, however, bothers me a great deal. There's no legitimate reason to do that. So, time to track down their netblocks and drop everything from or to them into a black hole at the edge of my network.
In this case, you'd have to go to whoever owns the rights to Tux. They could go to that company and tell them to stop using Tux to imply Linux compatibility or be sued for trademark infringement, and back it up. That's about it. Distro brands like RedHat or Debian could enforce this on use of their logos as well, eg. Debian could keep companies from using the Debian logo on their products unless they satisfied Debian that their products worked to Debian's satisfaction with Linux.
One major difference I see between Afternic and the other registrars: the others are primarily pushing registration with the resale being almost an afterthought, while Afternic seems from thier home page to be mainly aiming for resale with registration primarily to support that resale. To me this makes a world of difference.
One problem: P3P blocks access to the site as soon as the negotiation is complete if it doesn't fit my requirements. I don't want that. I simply want to not give that site the data I don't wish it to have. Why should I tell them I don't want to give out that data as soon as I enter the site, as opposed to only refusing to give it when they finally ask for it? My preferences are private information as well, after all.
First, cancelling the account of the victim probably won't shut down the DoS attack, at least not for quite a while. The attacker has to notice that his target's not there anymore before he'll stop.
Second, regarding the nudist-in-WalMart analogy. The nudist might be removed, but he will be removed for his disruption of business. Cancelling a DoS victim's account is more akin to throwing out other people in the store because the nudist might make them gawk and that might disrupt business. Which just plain doesn't make sense.
You might want to think about the consequences if it becomes acceptable to terminate your service because someone else has taken an irrational dislike to you and decided to attack you.
Because the big guy can afford big-guns lawyers of his own and just might win. So you go after the little guys who can't afford to fight and set precedents with your wins there before touching the big guys.
Shakespeare was right.