Remember that troubleshooting the problem isn't the point. It's the amount of work needed to get an acceptable solution out of the support line after you've identified the problem that's being demonstrated. Both Windows and Linux can throw some pretty non-obvious problems at people, but while the Linux solution to the problem may be more complex on it's face the problems of the Microsoft "solution" gets nicely demonstrated.
Except that on Windows if you reinstall the original libraries from the Windows disks, you've likely wiped out updates to the libraries that the other software you've installed has made and needs to run. And until it runs like it did before, the assignment's not over.
You have a Windows PC with a subtle problem which is preventing it from running (possibly a trashed library or something similar). It contains several complex pieces of installed software such as Visual C++ that have had their configurations customized. Obtain a fix for the problem and return the PC to service with all configuration exactly as it was initially except for the broken bit now working. This is a pass/fail assignment, any discrepancy will result in you getting an F for the course.
Now do the same with a Linux box with a horked copy of bash preventing a boot.
As far as Joel goes, I've been there, done that, got the t-shirt. The problem is, he's wrong. Yes, it costs to rewrite code from scratch. What he misses is that it costs to not rewrite code from scratch too. The question is, which costs more? After a certain point, all those accumulated bug-fixes and patches and kludges to make the code work take longer to work around than it would take to throw it out, take what you learned from it and reimplement it right so it doesn't need all those kludges. At that point, if you refuse to rewrite you end up tying your hands. To borrow one of his cases, yes Netscape sacrificed a lot by throwing out the crap codebase of 4.x. Yes, they couldn't respond to MS's advances while they were rewriting. But if they hadn't rewritten, they wouldn't be able to respond to MS now because it'd take forever to try and turn a tag-soup browser into something that could actually parse XML given a DTD.
I think I'll agree with the analysis I ran across in the IEEE software development magazine, that concluded that software has a lifespan of about 4-6 years, at which point it's cheaper and faster to throw it out and rewrite it based on what you've learned than it is to keep modifying it.
Come to think of it, that applies to lots of things. There's a point where you just have to stop tinkering with a prop-driven aircraft, abandon the whole propeller idea and start building jets if you want to go faster.
I can see why he's unhappy. I would be too. However, as someone who runs a system I'd rather know about it as soon as possible so I can either turn off the service or replace wu-ftpd with a different server until a patch can be released. The whole incident also says something against hiding the details and in favor of full disclosure. If technical details about the vulnerability had been included, there wouldn't have been any question about whether it was a hoax or not. And it wouldn't have helped the script-kiddies positions any to have that information in the announcement, because as someone else noted their machines were already being broken into using what was likely this vulnerability so the crackers apparently already knew the details. Notice to the maintainer before the announcement, with the details, would have been ideal, but hiding the information did nothing but confuse the issue and prolong the mess.
It wouldn't be very cool of them to leave me vulnerable to a break-in when the fix is available. And the fix is available in the wu-ftpd package, regardless of whether the various distributors have packaged it for their systems, so I can install the fix even if my vendor hasn't gotten it's act together.
My whole complaint with the non-full-disclosure movement is that vendors under it tend to not acknowledge that security holes exist (which means I can't even do something as simple as disable the vulnerable service until a fix is out) and delay putting patches out (so I'm either vulnerable or off the air longer than needed). I'd be more annoyed at CERT for not reporting the vulnerability than at RedHat for telling me about it.
And good luck to them if they do. They're just another bunch of crackers trying to root my machine, and I've been dealing with those for 20 years now. Nothing new. And if they do root the thing, they can forget about it going undetected. Offsite copies of Tripwire checksums on CD-R are a Good Thing.
And no, I don't do that specifically because of the FBI or even crackers. My niece is curious and possesses clue in full measure and is at that age where rm -rf/ is an irresistable temptation.
You own the code. Nothing says you have to license it under only one license. So, simple solution. License it to the public under the LGPL. If someone wants to use it in a proprietary embedded device, license it to them under a conventional license or whatever license you want. You can do that, you're the owner of the code. The two licenses won't interfere with each other, as long as you make sure to include in the proprietary license wording to the effect that this license is non-exclusive and does not affect your licensing of the code to other parties under other terms. You give the proprietary people what they're happy with without endangering the free nature of the code as licensed to everyone else.
Actually it has been written. It's called a Linux box with masquerading/NAT and port forwarding enabled. Or the equivalent in *BSD, or a Netgear or Linksys or other router with the same functionality. The CAT box sees just the gateway, and if it tries to query the gateway for what's behind it it gets back either no answer or "I dunno what protocol you're talking, buddy, so go away.". End of problem.
And if you think I'm trusting cable-company equipment between my computers and the world, you've gotta be kidding.
On point #1, objection. Binary names can clash, just not in packages used at the same time. Eg., if I have a foomatic program for both KDE and Gnome desktops, I want both versions of foomatic installed simultaneously, say in/usr/bin/gnome/foomatic and/usr/bin/kde/foomatic. I'll only put one of/usr/bin/kde and/usr/bin/gnome in my path at once, so there's no conflict at run-time.
There's even a sensible reason for having the same name. Suppose foomatic is the same program under both desktops, but the Gnome version's built with the Gnome/GTK toolkits and the KDE version's build with the KDE toolkits so that each version has the right look-and-feel for the desktop it's used with.
Use Ctrl-T (open new tab)? Seriously, I can understand wanting to replace a mouse click that would open a new window with one that'd open a new tab, but a command keystroke? No, if I tell it deliberately I want to open a new window I want it to do what I told it, not do something else. There's a way to rebind the menu accelerator keystrokes, but frankly I'd prefer to leave them the way they are and just use the proper keystroke.
Unfortunately, in most of the US a retailer can't get away with refusing to accept returns on defective products. The UCC requires warranty of merchantibility and fitness for purpose, and manufacturers and retailers aren't allowed to disclaim those warranties. All it takes is one customer getting ticked and talking to a lawyer, and the floodgates open.
And yes, the retailer's caught in the middle. A smart retailer would look at this and refuse to carry product that's going to cost him money. The label doesn't have to listen to consumer complaints, but they'll sure as Hell listen to major retail chains that won't carry their product because the retailers can't make a profit on it. Which is the only thing that'll kill these copy-prevention schemes for good.
Actually there'd be plenty to dispute, as McDonald's proved. That's why you have to stick to the truth and the facts, not your interpretation. Instead of saying "McDonald's grows food on land that used to be rainforests.", you say "McDonald's grows food on land that <list of agencies classify as rainforest.". The former's subject to interpretation as to exactly what constitutes a rainforest, while the latter's a strictly factual statement that leaves McDonald's very little target for claiming what you said is not true.
Because what you suggest isn't protecting trademarks. No, you can't start a store called "McDonald's Sucks". Yes, you can put up a sign saying "McDonald's Sucks" and tell people why you think they suck. You can't spread falsehoods, but if you stick to the truth McDonald's can't legally touch you.
This is the fallacy that the UDRP falls into: the assumption that only trademark gives a valid claim to a name. It's what leads to decisions that a person doesn't have the right to use their own name for a Web site about themselves.
One thing the article forgets: I don't pay in a bookstore to look at a book. I pay to get the book permanently. Before I plop down my money I can open the book up, see what it has to say and see whether I want to buy it. What they're proposing is to charge to open the book up and see if it's got anything useful in it.
The penny-a-page might work for someplace like the Motley Fool, where the content's already know to be good enough to be worth paying for if you're interested in that subject at all. It won't work for general news sites like CNN or Yahoo News, where the material's nothing that can't be gotten for less from other sources ( trade rags, newspapers, TV news ). Some people might pay for the convenience, but the failure of the subscription model in that area tells me that Yet Another Subscription Model probably won't fly either. And forget about it for e-commerce sites. That amounts to charging your customers a toll to come into your store and look at what you've got to sell. That'll just drive people to the competition. If you're selling things on the Web, you're selling product. Your Web site's a way to let people buy your product, just like a storefront. Treat it the same way.
As far as books in electronic form, riddle me this: why should I pay $10 for a book I can only read on a single low-resolution piece of electronics and can't sell when I'm done with it, when I can pay $7 for the same book on paper that I can take anywhere I want, not have to worry about breaking it if I drop it or sit on it, and can sell to a used bookstore or give to someone else when I'm done? The answer to that'll tell you why e-books, and e-music, and e-video, tank in the market. Penny-a-page won't change the fundamental dynamic there.
Check Preferences | Privacy and Security | Cookies. Turn on "Enable cookies based on privacy level" and check View Privacy Levels. See the Session option on the menubuttons. This only works in recent nightly builds, the 10/30 builds seem reasonable.
Actually there's a legitimate use for navigation tracking: to tell where people go on your site and how they get there. That lets you spot confusing navigation points, for example, or lets you see how people find content so you can eliminate confusing or awkward paths in favor of obvious-to-the-user ones based on actual user patterns instead of vague theories. What's bad is tying navigation tracking to personal information. Knowing that N visitors followed path X is quite different from knowing which visitors followed path X.
From what I read, they aren't banning cookies per se. What they're banning is any collection of personal information without explicit informed consent. So you can use cookies all you want, as long as you tell the user what personal information you're storing in them and let them say whether they want to allow it or not. And if you use cookies for things like shopping carts, where there's no personal information in them, then there's no restrictions on them. All perfectly sensible to me.
Actually, Jaime, sites are put onto the RBL for three reasons:
Spam originates from them and they have failed to do anything about it despite repeated complaints over the course of months.
They host web sites belonging to proven spammers.
They sell programs and materials whose only purpose is to enable spammers to spam.
Those criteria are well-known by anyone who knows about MAPS at all. And yes, this blacklisting catches anyone associated with the spammers or the ISPs who support them in these ways. That's the point: to force those ISPs to choose between the spammers and the non-spammers. Complaints from the rest of us about the spammers don't have any effect because it doesn't hurt the ISP to ignore them. We aren't their customers, after all. It's only when their customers begin to complain and take their business elsewhere that the ISPs do anything.
It's the Internet equivalent of going into a shoe shop and telling the owner "I don't like Nike's child-labor practices. So, not only am I not going to buy Nike shoes, I'm not going to do business with you, at all, as long as you continue to carry Nike shoes on your shelves. And neither is half the rest of the area.". If you just stopped buying Nike shoes but kept patronizing him, he'd have no reason to stop carrying Nikes. He still gets your money for other brands, plus money from people buying Nike. But when he's got to choose between carrying Nike and losing half his customers, it's a slightly different story. And that's what every single one of us who want our ISPs using the MAPS RBL are doing to the ISPs who continue to host spammers.
Naw, you want it passed. When it passes, you immediately sue SafeSurf for publishing information (their blocked-site list) that you feel harmed your child (by preventing them from finding information on various topics that could save their life). Then watch SafeSurf try to worm out of their own legal language.
It'd have to be all developers everywhere. If it weren't, some of them would be heeding the user's calls for easier-to-use. And with open-source, it doesn't matter what the original developers think. If they're too out of touch with what the users want, the users switch away from their branch because, well, it's not what the users want. The X Consortium tried to take their ball and bat and go home with their licensing, remember that one? That's a classic example of what'd happen in the situation you posit.
The end users can't fork, no. But if the project's not satisfying the needs of a large number of end users, then it's likely that either a number of them are also developers who'll fork the project to scratch their own unsatisfied itch or they'll attract the interest of some developers. Remember that, unlike closed-source systems, the project developers in open-source projects can't prevent a fork. Community pressure tends to prevent forks when they aren't productive, but it also tends to create them when they are going to be productive ( see the gcc/egcs split, for example ).
Check Google's help page and check the Basics of Search and Advanced Search Tips links for information on operators, related searches and other things along the lines you're talking about.
Won't happen. If one group in a project starts to try and force issues that compromise what other interested parties want, then a legitimate fork will develop based on what the users want/need. If the CLI fork compromises ease of use and the other fork allows ease of use without compromising too much more, then the CLI fork will die off from lack of interest outside that small CLI group.
Working advantage of open source development: the vendor/developers can't force the project down paths that compromise what the users need. If they try, somebody else with an itch not being scratched will pick up the ball and the users will follow that instead.
Slashdot Mirror
Remember that troubleshooting the problem isn't the point. It's the amount of work needed to get an acceptable solution out of the support line after you've identified the problem that's being demonstrated. Both Windows and Linux can throw some pretty non-obvious problems at people, but while the Linux solution to the problem may be more complex on it's face the problems of the Microsoft "solution" gets nicely demonstrated.
Except that on Windows if you reinstall the original libraries from the Windows disks, you've likely wiped out updates to the libraries that the other software you've installed has made and needs to run. And until it runs like it did before, the assignment's not over.
You have a Windows PC with a subtle problem which is preventing it from running (possibly a trashed library or something similar). It contains several complex pieces of installed software such as Visual C++ that have had their configurations customized. Obtain a fix for the problem and return the PC to service with all configuration exactly as it was initially except for the broken bit now working. This is a pass/fail assignment, any discrepancy will result in you getting an F for the course.
Now do the same with a Linux box with a horked copy of bash preventing a boot.
As far as Joel goes, I've been there, done that, got the t-shirt. The problem is, he's wrong. Yes, it costs to rewrite code from scratch. What he misses is that it costs to not rewrite code from scratch too. The question is, which costs more? After a certain point, all those accumulated bug-fixes and patches and kludges to make the code work take longer to work around than it would take to throw it out, take what you learned from it and reimplement it right so it doesn't need all those kludges. At that point, if you refuse to rewrite you end up tying your hands. To borrow one of his cases, yes Netscape sacrificed a lot by throwing out the crap codebase of 4.x. Yes, they couldn't respond to MS's advances while they were rewriting. But if they hadn't rewritten, they wouldn't be able to respond to MS now because it'd take forever to try and turn a tag-soup browser into something that could actually parse XML given a DTD.
I think I'll agree with the analysis I ran across in the IEEE software development magazine, that concluded that software has a lifespan of about 4-6 years, at which point it's cheaper and faster to throw it out and rewrite it based on what you've learned than it is to keep modifying it.
Come to think of it, that applies to lots of things. There's a point where you just have to stop tinkering with a prop-driven aircraft, abandon the whole propeller idea and start building jets if you want to go faster.
I can see why he's unhappy. I would be too. However, as someone who runs a system I'd rather know about it as soon as possible so I can either turn off the service or replace wu-ftpd with a different server until a patch can be released. The whole incident also says something against hiding the details and in favor of full disclosure. If technical details about the vulnerability had been included, there wouldn't have been any question about whether it was a hoax or not. And it wouldn't have helped the script-kiddies positions any to have that information in the announcement, because as someone else noted their machines were already being broken into using what was likely this vulnerability so the crackers apparently already knew the details. Notice to the maintainer before the announcement, with the details, would have been ideal, but hiding the information did nothing but confuse the issue and prolong the mess.
It wouldn't be very cool of them to leave me vulnerable to a break-in when the fix is available. And the fix is available in the wu-ftpd package, regardless of whether the various distributors have packaged it for their systems, so I can install the fix even if my vendor hasn't gotten it's act together.
My whole complaint with the non-full-disclosure movement is that vendors under it tend to not acknowledge that security holes exist (which means I can't even do something as simple as disable the vulnerable service until a fix is out) and delay putting patches out (so I'm either vulnerable or off the air longer than needed). I'd be more annoyed at CERT for not reporting the vulnerability than at RedHat for telling me about it.
And good luck to them if they do. They're just another bunch of crackers trying to root my machine, and I've been dealing with those for 20 years now. Nothing new. And if they do root the thing, they can forget about it going undetected. Offsite copies of Tripwire checksums on CD-R are a Good Thing.
And no, I don't do that specifically because of the FBI or even crackers. My niece is curious and possesses clue in full measure and is at that age where rm -rf / is an irresistable temptation.
You own the code. Nothing says you have to license it under only one license. So, simple solution. License it to the public under the LGPL. If someone wants to use it in a proprietary embedded device, license it to them under a conventional license or whatever license you want. You can do that, you're the owner of the code. The two licenses won't interfere with each other, as long as you make sure to include in the proprietary license wording to the effect that this license is non-exclusive and does not affect your licensing of the code to other parties under other terms. You give the proprietary people what they're happy with without endangering the free nature of the code as licensed to everyone else.
Actually it has been written. It's called a Linux box with masquerading/NAT and port forwarding enabled. Or the equivalent in *BSD, or a Netgear or Linksys or other router with the same functionality. The CAT box sees just the gateway, and if it tries to query the gateway for what's behind it it gets back either no answer or "I dunno what protocol you're talking, buddy, so go away.". End of problem.
And if you think I'm trusting cable-company equipment between my computers and the world, you've gotta be kidding.
On point #1, objection. Binary names can clash, just not in packages used at the same time. Eg., if I have a foomatic program for both KDE and Gnome desktops, I want both versions of foomatic installed simultaneously, say in /usr/bin/gnome/foomatic and /usr/bin/kde/foomatic. I'll only put one of /usr/bin/kde and /usr/bin/gnome in my path at once, so there's no conflict at run-time.
There's even a sensible reason for having the same name. Suppose foomatic is the same program under both desktops, but the Gnome version's built with the Gnome/GTK toolkits and the KDE version's build with the KDE toolkits so that each version has the right look-and-feel for the desktop it's used with.
Use Ctrl-T (open new tab)? Seriously, I can understand wanting to replace a mouse click that would open a new window with one that'd open a new tab, but a command keystroke? No, if I tell it deliberately I want to open a new window I want it to do what I told it, not do something else. There's a way to rebind the menu accelerator keystrokes, but frankly I'd prefer to leave them the way they are and just use the proper keystroke.
Unfortunately, in most of the US a retailer can't get away with refusing to accept returns on defective products. The UCC requires warranty of merchantibility and fitness for purpose, and manufacturers and retailers aren't allowed to disclaim those warranties. All it takes is one customer getting ticked and talking to a lawyer, and the floodgates open.
And yes, the retailer's caught in the middle. A smart retailer would look at this and refuse to carry product that's going to cost him money. The label doesn't have to listen to consumer complaints, but they'll sure as Hell listen to major retail chains that won't carry their product because the retailers can't make a profit on it. Which is the only thing that'll kill these copy-prevention schemes for good.
Actually there'd be plenty to dispute, as McDonald's proved. That's why you have to stick to the truth and the facts, not your interpretation. Instead of saying "McDonald's grows food on land that used to be rainforests.", you say "McDonald's grows food on land that <list of agencies classify as rainforest.". The former's subject to interpretation as to exactly what constitutes a rainforest, while the latter's a strictly factual statement that leaves McDonald's very little target for claiming what you said is not true.
Because what you suggest isn't protecting trademarks. No, you can't start a store called "McDonald's Sucks". Yes, you can put up a sign saying "McDonald's Sucks" and tell people why you think they suck. You can't spread falsehoods, but if you stick to the truth McDonald's can't legally touch you.
This is the fallacy that the UDRP falls into: the assumption that only trademark gives a valid claim to a name. It's what leads to decisions that a person doesn't have the right to use their own name for a Web site about themselves.
One thing the article forgets: I don't pay in a bookstore to look at a book. I pay to get the book permanently. Before I plop down my money I can open the book up, see what it has to say and see whether I want to buy it. What they're proposing is to charge to open the book up and see if it's got anything useful in it.
The penny-a-page might work for someplace like the Motley Fool, where the content's already know to be good enough to be worth paying for if you're interested in that subject at all. It won't work for general news sites like CNN or Yahoo News, where the material's nothing that can't be gotten for less from other sources ( trade rags, newspapers, TV news ). Some people might pay for the convenience, but the failure of the subscription model in that area tells me that Yet Another Subscription Model probably won't fly either. And forget about it for e-commerce sites. That amounts to charging your customers a toll to come into your store and look at what you've got to sell. That'll just drive people to the competition. If you're selling things on the Web, you're selling product. Your Web site's a way to let people buy your product, just like a storefront. Treat it the same way.
As far as books in electronic form, riddle me this: why should I pay $10 for a book I can only read on a single low-resolution piece of electronics and can't sell when I'm done with it, when I can pay $7 for the same book on paper that I can take anywhere I want, not have to worry about breaking it if I drop it or sit on it, and can sell to a used bookstore or give to someone else when I'm done? The answer to that'll tell you why e-books, and e-music, and e-video, tank in the market. Penny-a-page won't change the fundamental dynamic there.
Check Preferences | Privacy and Security | Cookies. Turn on "Enable cookies based on privacy level" and check View Privacy Levels. See the Session option on the menubuttons. This only works in recent nightly builds, the 10/30 builds seem reasonable.
Actually there's a legitimate use for navigation tracking: to tell where people go on your site and how they get there. That lets you spot confusing navigation points, for example, or lets you see how people find content so you can eliminate confusing or awkward paths in favor of obvious-to-the-user ones based on actual user patterns instead of vague theories. What's bad is tying navigation tracking to personal information. Knowing that N visitors followed path X is quite different from knowing which visitors followed path X.
From what I read, they aren't banning cookies per se. What they're banning is any collection of personal information without explicit informed consent. So you can use cookies all you want, as long as you tell the user what personal information you're storing in them and let them say whether they want to allow it or not. And if you use cookies for things like shopping carts, where there's no personal information in them, then there's no restrictions on them. All perfectly sensible to me.
Actually I do.
Actually, Jaime, sites are put onto the RBL for three reasons:
- Spam originates from them and they have failed to do anything about it despite repeated complaints over the course of months.
- They host web sites belonging to proven spammers.
- They sell programs and materials whose only purpose is to enable spammers to spam.
Those criteria are well-known by anyone who knows about MAPS at all. And yes, this blacklisting catches anyone associated with the spammers or the ISPs who support them in these ways. That's the point: to force those ISPs to choose between the spammers and the non-spammers. Complaints from the rest of us about the spammers don't have any effect because it doesn't hurt the ISP to ignore them. We aren't their customers, after all. It's only when their customers begin to complain and take their business elsewhere that the ISPs do anything.It's the Internet equivalent of going into a shoe shop and telling the owner "I don't like Nike's child-labor practices. So, not only am I not going to buy Nike shoes, I'm not going to do business with you, at all, as long as you continue to carry Nike shoes on your shelves. And neither is half the rest of the area.". If you just stopped buying Nike shoes but kept patronizing him, he'd have no reason to stop carrying Nikes. He still gets your money for other brands, plus money from people buying Nike. But when he's got to choose between carrying Nike and losing half his customers, it's a slightly different story. And that's what every single one of us who want our ISPs using the MAPS RBL are doing to the ISPs who continue to host spammers.
Naw, you want it passed. When it passes, you immediately sue SafeSurf for publishing information (their blocked-site list) that you feel harmed your child (by preventing them from finding information on various topics that could save their life). Then watch SafeSurf try to worm out of their own legal language.
It'd have to be all developers everywhere. If it weren't, some of them would be heeding the user's calls for easier-to-use. And with open-source, it doesn't matter what the original developers think. If they're too out of touch with what the users want, the users switch away from their branch because, well, it's not what the users want. The X Consortium tried to take their ball and bat and go home with their licensing, remember that one? That's a classic example of what'd happen in the situation you posit.
The end users can't fork, no. But if the project's not satisfying the needs of a large number of end users, then it's likely that either a number of them are also developers who'll fork the project to scratch their own unsatisfied itch or they'll attract the interest of some developers. Remember that, unlike closed-source systems, the project developers in open-source projects can't prevent a fork. Community pressure tends to prevent forks when they aren't productive, but it also tends to create them when they are going to be productive ( see the gcc/egcs split, for example ).
Check Google's help page and check the Basics of Search and Advanced Search Tips links for information on operators, related searches and other things along the lines you're talking about.
Won't happen. If one group in a project starts to try and force issues that compromise what other interested parties want, then a legitimate fork will develop based on what the users want/need. If the CLI fork compromises ease of use and the other fork allows ease of use without compromising too much more, then the CLI fork will die off from lack of interest outside that small CLI group.
Working advantage of open source development: the vendor/developers can't force the project down paths that compromise what the users need. If they try, somebody else with an itch not being scratched will pick up the ball and the users will follow that instead.