5 windowing systems? Last I saw, there was only one windowing system on Linux and that's X11 ( Berlin doesn't seem to be going anywhere in the near future ). There's a dozen or so window managers, but I haven't met an app yet that cared much about the window manager. Some of the desktop environments might be a different matter, but even there it looks like apps are going to be relatively independent of the desktop. Worst case seems to be that you lose things like drag-and-drop between apps if you aren't running a desktop that supports the right protocol.
Bill, get a clue: Linux isn't Windows and we don't have to live with a tightly-bound mess like the one you created. So we have multiple window managers, so what? They all talk ICCCM and similar standard protocols at this point, so from the app's POV it's irrelevant which one is running.
And if Linux is only going to have limited impact, why's it growing 8 times as fast as NT?
Actually controlling scalping/squatting should be relatively easy. Most of the people who do it do so to re-sell the name. So, make a simple rule: nobody can re-sell a domain name. You can drop your registration and let someone else pick it up, but you can't get money for doing so. Anyone caught reselling domain names immediately loses all of their registered domain names.
This is nicely self-enforcing, too. If the buyer wants the name, as soon as the seller makes an offer all the buyer has to do is forward a copy of the offer to InterNIC and bam, the name is free. The proof of re-selling comes from the seller's own hand, so there's no credibility question. InterNIC doesn't even have to go looking, the buyers will do that for them.
The only thing that needs care is distinguishing a scalper from a company that's handling the registration and administrivia on behalf of others, and that's easy: a scalper owns the name beforehand, the companies ( ISPs mainly ) handling DNS administrivia for their clients don't.
Problem: paragraphs 1a and 1b require that the use be likely to cause confusion. In your example, the color scheme alone would be likely to cause confusion unless someone was specifically looking for the text. Nobody is likely to confuse Linux with Windows ( at least any more than they're likely to confuse a semi rig with a mid-sized car ), especially since that slogan typically begins with "Linux:" rather than "Microsoft:" ( I can't check the page in question because the site seems to have been slashdotted ).
Further, if your argument were true under US law then we would not be seeing the ads on US television where one company will show an "unamed competitor's" store where uniforms, slogans, products and characteristic names are so close to a real competitor's that the competitor in question is readily recognizable.
When you create a slogan or name, take-offs on it are one of the facts of life you accept.
"But it's just a game," you say. Hell, let's all grab some shotguns, and go out to the fields, and start trying to blow each other's heads off.. what cool special effects we can have - wont that be a wonderful game?
No, that wouldn't be a game, that would be reality.
Sure YOU may know the line between computer and reality, but do kids?
I don't know about you, but I figured out the line back in elementary school. Of course, I spent a lot of time wondering why all the adults seemed to have such a problem distinguishing the difference between reality and books/movies/games/fantasy, since they were always the ones who ( from my POV ) were trying to bring the latter into the former.
Third, what is the fucking point of these games?
Stress relief?
These games should be restricted from children.
No argument there. OTOH, the parents of the kid in question could easily have done this. They didn't. They should be the ones being sued by the parents of the victims.
Where is it trademark infringement? Last I checked MS had "Where do you want to go today?" trademarked, not the slogan in question. Sure they're similar, but the criteria for trademarks is "Is it's use likely to cause confusion between products?", and there's no way Linux will ever be confused with an MS product.
As a counterpoint, the GPL was coercive for a reason. Look at the CDDB flap recently. The GPL's terms were coercive precisely to make it impossible for the equivalent to happen to GPLd software. That has a cost, but considering corporate attitudes it might not be as paranoid as all that after all. The Community license is more friendly towards commercial software, but it also allows for someone to benefit from openly-developed software without letting anyone else benefit from the results. There's a cost there just as there is with the GPL. The question is which is greater: the cost to the commercial develpers of the GPL, or the cost to the community of taking work derived from open-source code and making it proprietary.
The point I caught was his comment on testing the code. And its something I've brought up here in the past: lots of Linux programmers, not a lot of QA.
Not a lot of formal QA, you mean. What you've got is a lot of users banging on every change almost as quickly as the developers can release code. Carpet-bombing isn't efficient, but if you drop enough iron in there pretty soon there aren't any bugs left.
Also, in OSS the changes are often relatively small because they come out so quickly, as opposed to commercial software where the version sent to test may have dozens to hundreds of change orders in it. Interaction bugs don't get caught until test in commercial software, while in OSS they usually get caught quickly after creation.
Final sanity check: if Linux lacks testing, then logically it's bug rate should be higher than commercial software. Experience and the extant data says it's lower, so either Linux doesn't lack testing or has something that's doing a better job of eliminating bugs than testing.
Well, Bill, if Linux "can't compete", why is it growing faster than your oh-so-innovative OS? If the versions are so incompatible, why can I grab packages from Caldera and Debian distributions and (assuming proper package format conversions as needed) drop them into my RedHat system? If it doesn't have a graphical interface, what are KDE and GNOME then? And why is one of the biggest complaints about Windows the sheer size and complexity of the API?
And most important, why is the Linux community concerned with your opinions? We're winning without competing on your terms, why should we change that?
The libc5/libc6 mess is why version numbers on shared libraries exist. The main problem was that people didn't link libraries against libc so the loader couldn't figure out which version to use. This could have been prevented had people followed the existing rules which recommended exactly that sort of library cross-linking.
As for which is present, the standard should be simply that a Posix.1-&c-compatible library is present. Applications that require a specific implementation of the library should specify which one or provide versions for the major implementations as Netscape does for libc5 and libc6. One then selects a distribution based on how easily it deals with the implementations your apps need, eg. RedHat uses primarily libc6 binaries but provides libc5 libraries for apps that aren't available for libc6 yet, and I have yet to see a libc6-based distro that you couldn't add libc5 to trivially.
Basically, I can see an application specifying that you must have libc6 to use it, but I can't see the point of having a standard say "You must provide libc6.". That sort of standard mucks up binary-compatible libraries in distributions, and requires constant revision as new versions come out.
That's kind of a fatalistic attitude. The DNS alternatives have been "just talk" mainly because NSI was doing a sufficiently good job (or at least not a sufficiently bad job) that most people weren't terminally fed up with them. At some point NSI will push it far enough that even the most objectionable alternative will look better. And frankly, the old guard has a better chance of making an alternative work simply because they do pre-date the commercial interests.
You'd need someone like Jon Postel, completely outside the DNS registry process and sufficiently respected as an impartial judge, who could make the final decision. And his decision would have to be final, no appeal possible. Whether that's doable or not I don't know, but I think that's the only way it could be done.
One thing I think would put a damper on NSI and the squatters would be a simple rule: one domain name per organization. Period. No exceptions. You have multiple divisions in your company you want names for? Create 3LDs for them under your company name. Want.com and.net names? Sorry, decide which one you are. I suspect that'd take the wind out of NSI's sails, not to mention giving the domain squatters fits. Any thoughts?
You make reasonable points. However, regarding #'s 1 and 3, if Apple truly doesn't intend to terminate the license at the first hint of an unsubstantiated complaint then they should have no problem in saying so outright in the license. If they don't, one has to wonder why they're leaving that option open. No, pulling that sort of stunt doesn't make sense from our point of view, but corporations have been known to do stupid things before and corporate legal departments are even more prone to such blunders. Yes, we could deal with the blunders as they happen. I'd rather avoid the headache in the first place.
Doesn't require Apple to lose the suit, just requires the person alleging infringement to prove infringement before Apple can terminate the license on part of the code for infringement. As written, I could write Apple a letter saying that routine X in their code infringed on one a patent and, even if I never substantiate the claim or file suit, Apple could legally terminate the license on that code because they have been subjected to a claim. At the least the license should require actual, not just claimed, infringement (whether determined by a court or by agreement between Apple and the complaining party) before jerking code out from under the rest of us.
The question of what happens if the stated URL goes away can go either way. Eric's reading would be the reasonable one, Bruce's reading would be the paranoid one any corporate attorney would recommend you use on the assumption that that's the one the other guy's lawyer would use.
As for the section 9.1 termination, I think Bruce has it right here. The license says they can terminated at their sole discretion if they become the subject of a claim of infringement. It doesn't say that the claim has to be proven, so we can't assume that. I'm extremely uncomfortable with any license that doesn't require actual, proven infringement to terminate.
Why is source code important?
on
Linux on CNN
·
· Score: 1
From a developer's standpoint, I think the importance of source code can be summed up fairly succinctly:
If we have the source code, we can decide whether we want to fix a bug ourselves or wait for the author to do it. Without source code it doesn't matter whether it's a trivial bug or one that shuts down our whole operation, we have no choice but to live with it.
What would you change about sendmail's design? Yes the config file syntax is a bear. That's not a result of the program's design. Having had to hack local mods into sendmail's code before, I find it relatively easy to do so. To me, that's the ultimate criteria for a good design: someone who wasn't part of the design team finds it easy to modify the program.
That depends on whether or not the software needs a redesign. One of the advantages of open-source is that, given the number of people working on a piece of software, design decisions that make it hard to maintain and/or extend get found and eliminated early in it's life. The result is software that doesn't suffer nearly as badly from rot as changes are made. The canonical examples would be BIND or the nigh-immortal sendmail
Hopefully any initiative along these lines will be constructed a bit more reliably than your 20-year-old mainframe.
Microsoft's software, which they presumably are going to use as the basis for the central server, is about 2-3 orders of magnitude less reliable than that "20-year-old mainframe", based on uptime figures. And the central server is only one part of the reliability chain, a failure in a router or network hub will take down the system even if both the server and the client system are running perfectly. Maybe a distributed, redundant database system, but distributing the data wipes out the gains from centralizing it.
I do the same at-work, at-home stuff you probably do. The difference is that I'm not dependent on the work system when at home. I need it to be reachable to pass data back and forth, but I still have all my apps, config data and such locally when the connection is down. For syncing things up, rdist and the occasional bit of diff and patch magic works nicely.
And, as you pointed out, X11 and Unix already have complete remote access to the desktop, apps and config data on another system down pat. Rather than creating yet another standard, why doesn't NT simply adopt the network- and location-independent approach we're used to using X11?
I've done both. If you're looking at an MB with integrated video/sound/NIC, look at the chipset they're using and check if Linux supports it. If the kernel (or the X server in the case of video chipsets) supports the chipset, things should work fine.
OTOH, the integrated stuff tends to be at the low end of the scale. Some boards are using moderately decent S3 video, but generally you'll find that for not much more you can get better performance and better quality output from add-in cards. Plus it's easier to replace the cards with newer hardware than it is to disable and replace the integrated stuff.
Technically there shouldn't be any problems with integrated hardware if the basic chipsets are supported. If you're building a system where performance isn't a major issue in that area, integrated hardware might be a bit cheaper. If you need maximum performance and/or flexibility, skip the integrated stuff and go for seperate cards.
I see one big disadvantage, the same one we had with terminals attached to central mainframes: lose the server, lose everything. If your network connection is down, regardless of why, you can't even work locally. Not to mention the fun when the central staff "upgrades" the software to a version that breaks half your stuff with no warning whatsoever. What joy.
I don't understand why we would want to GPL our software. What advantage is it to our clients if we've solved a problem for them that a competitor could gain access to without paying for it, funding the development?
Turn that around: how much advantage would it be for you to be able to get all of your competitor's code without having to pay them for it? Once you rephrase the question from "Is it costing me anything?" to "Is what I get back worth what it costs me?", things change a bit.
Slashdot Mirror
What the story describes sounds like literal piracy plain and simple. I just wonder two things:
5 windowing systems? Last I saw, there was only one windowing system on Linux and that's X11 ( Berlin doesn't seem to be going anywhere in the near future ). There's a dozen or so window managers, but I haven't met an app yet that cared much about the window manager. Some of the desktop environments might be a different matter, but even there it looks like apps are going to be relatively independent of the desktop. Worst case seems to be that you lose things like drag-and-drop between apps if you aren't running a desktop that supports the right protocol.
Bill, get a clue: Linux isn't Windows and we don't have to live with a tightly-bound mess like the one you created. So we have multiple window managers, so what? They all talk ICCCM and similar standard protocols at this point, so from the app's POV it's irrelevant which one is running.
And if Linux is only going to have limited impact, why's it growing 8 times as fast as NT?
Actually controlling scalping/squatting should be relatively easy. Most of the people who do it do so to re-sell the name. So, make a simple rule: nobody can re-sell a domain name. You can drop your registration and let someone else pick it up, but you can't get money for doing so. Anyone caught reselling domain names immediately loses all of their registered domain names.
This is nicely self-enforcing, too. If the buyer wants the name, as soon as the seller makes an offer all the buyer has to do is forward a copy of the offer to InterNIC and bam, the name is free. The proof of re-selling comes from the seller's own hand, so there's no credibility question. InterNIC doesn't even have to go looking, the buyers will do that for them.
The only thing that needs care is distinguishing a scalper from a company that's handling the registration and administrivia on behalf of others, and that's easy: a scalper owns the name beforehand, the companies ( ISPs mainly ) handling DNS administrivia for their clients don't.
Problem: paragraphs 1a and 1b require that the use be likely to cause confusion. In your example, the color scheme alone would be likely to cause confusion unless someone was specifically looking for the text. Nobody is likely to confuse Linux with Windows ( at least any more than they're likely to confuse a semi rig with a mid-sized car ), especially since that slogan typically begins with "Linux:" rather than "Microsoft:" ( I can't check the page in question because the site seems to have been slashdotted ).
Further, if your argument were true under US law then we would not be seeing the ads on US television where one company will show an "unamed competitor's" store where uniforms, slogans, products and characteristic names are so close to a real competitor's that the competitor in question is readily recognizable.
When you create a slogan or name, take-offs on it are one of the facts of life you accept.
"But it's just a game," you say. Hell, let's all grab some shotguns, and go out to the fields, and start trying to blow each other's heads off.. what cool special effects we can have - wont that be a wonderful game?
No, that wouldn't be a game, that would be reality.
Sure YOU may know the line between computer and reality, but do kids?
I don't know about you, but I figured out the line back in elementary school. Of course, I spent a lot of time wondering why all the adults seemed to have such a problem distinguishing the difference between reality and books/movies/games/fantasy, since they were always the ones who ( from my POV ) were trying to bring the latter into the former.
Third, what is the fucking point of these games?
Stress relief?
These games should be restricted from children.
No argument there. OTOH, the parents of the kid in question could easily have done this. They didn't. They should be the ones being sued by the parents of the victims.
Where is it trademark infringement? Last I checked MS had "Where do you want to go today?" trademarked, not the slogan in question. Sure they're similar, but the criteria for trademarks is "Is it's use likely to cause confusion between products?", and there's no way Linux will ever be confused with an MS product.
As a counterpoint, the GPL was coercive for a reason. Look at the CDDB flap recently. The GPL's terms were coercive precisely to make it impossible for the equivalent to happen to GPLd software. That has a cost, but considering corporate attitudes it might not be as paranoid as all that after all. The Community license is more friendly towards commercial software, but it also allows for someone to benefit from openly-developed software without letting anyone else benefit from the results. There's a cost there just as there is with the GPL. The question is which is greater: the cost to the commercial develpers of the GPL, or the cost to the community of taking work derived from open-source code and making it proprietary.
The point I caught was his comment on testing the code. And its something I've brought up here in the past: lots of Linux programmers, not a lot of QA.
Not a lot of formal QA, you mean. What you've got is a lot of users banging on every change almost as quickly as the developers can release code. Carpet-bombing isn't efficient, but if you drop enough iron in there pretty soon there aren't any bugs left.
Also, in OSS the changes are often relatively small because they come out so quickly, as opposed to commercial software where the version sent to test may have dozens to hundreds of change orders in it. Interaction bugs don't get caught until test in commercial software, while in OSS they usually get caught quickly after creation.
Final sanity check: if Linux lacks testing, then logically it's bug rate should be higher than commercial software. Experience and the extant data says it's lower, so either Linux doesn't lack testing or has something that's doing a better job of eliminating bugs than testing.
Well, Bill, if Linux "can't compete", why is it growing faster than your oh-so-innovative OS? If the versions are so incompatible, why can I grab packages from Caldera and Debian distributions and (assuming proper package format conversions as needed) drop them into my RedHat system? If it doesn't have a graphical interface, what are KDE and GNOME then? And why is one of the biggest complaints about Windows the sheer size and complexity of the API?
And most important, why is the Linux community concerned with your opinions? We're winning without competing on your terms, why should we change that?
The libc5/libc6 mess is why version numbers on shared libraries exist. The main problem was that people didn't link libraries against libc so the loader couldn't figure out which version to use. This could have been prevented had people followed the existing rules which recommended exactly that sort of library cross-linking.
As for which is present, the standard should be simply that a Posix.1-&c-compatible library is present. Applications that require a specific implementation of the library should specify which one or provide versions for the major implementations as Netscape does for libc5 and libc6. One then selects a distribution based on how easily it deals with the implementations your apps need, eg. RedHat uses primarily libc6 binaries but provides libc5 libraries for apps that aren't available for libc6 yet, and I have yet to see a libc6-based distro that you couldn't add libc5 to trivially.
Basically, I can see an application specifying that you must have libc6 to use it, but I can't see the point of having a standard say "You must provide libc6.". That sort of standard mucks up binary-compatible libraries in distributions, and requires constant revision as new versions come out.
Let's see:
- File system location standard: already exists for Linux.
- Basic utilities: Posix.2 specifies this already.
- Basic libraries: functions are specified in Posix.1 and friends, the X11 specs, et. al.
- Widget sets: not a system specification, should be specified on an application-by-application basis.
What exactly is LSB specifying that isn't already a standard independent of LSB?That's kind of a fatalistic attitude. The DNS alternatives have been "just talk" mainly because NSI was doing a sufficiently good job (or at least not a sufficiently bad job) that most people weren't terminally fed up with them. At some point NSI will push it far enough that even the most objectionable alternative will look better. And frankly, the old guard has a better chance of making an alternative work simply because they do pre-date the commercial interests.
You'd need someone like Jon Postel, completely outside the DNS registry process and sufficiently respected as an impartial judge, who could make the final decision. And his decision would have to be final, no appeal possible. Whether that's doable or not I don't know, but I think that's the only way it could be done.
One thing I think would put a damper on NSI and the squatters would be a simple rule: one domain name per organization. Period. No exceptions. You have multiple divisions in your company you want names for? Create 3LDs for them under your company name. Want .com and .net names? Sorry, decide which one you are. I suspect that'd take the wind out of NSI's sails, not to mention giving the domain squatters fits. Any thoughts?
You make reasonable points. However, regarding #'s 1 and 3, if Apple truly doesn't intend to terminate the license at the first hint of an unsubstantiated complaint then they should have no problem in saying so outright in the license. If they don't, one has to wonder why they're leaving that option open. No, pulling that sort of stunt doesn't make sense from our point of view, but corporations have been known to do stupid things before and corporate legal departments are even more prone to such blunders. Yes, we could deal with the blunders as they happen. I'd rather avoid the headache in the first place.
Doesn't require Apple to lose the suit, just requires the person alleging infringement to prove infringement before Apple can terminate the license on part of the code for infringement. As written, I could write Apple a letter saying that routine X in their code infringed on one a patent and, even if I never substantiate the claim or file suit, Apple could legally terminate the license on that code because they have been subjected to a claim. At the least the license should require actual, not just claimed, infringement (whether determined by a court or by agreement between Apple and the complaining party) before jerking code out from under the rest of us.
The question of what happens if the stated URL goes away can go either way. Eric's reading would be the reasonable one, Bruce's reading would be the paranoid one any corporate attorney would recommend you use on the assumption that that's the one the other guy's lawyer would use.
As for the section 9.1 termination, I think Bruce has it right here. The license says they can terminated at their sole discretion if they become the subject of a claim of infringement. It doesn't say that the claim has to be proven, so we can't assume that. I'm extremely uncomfortable with any license that doesn't require actual, proven infringement to terminate.
From a developer's standpoint, I think the importance of source code can be summed up fairly succinctly:
What would you change about sendmail's design? Yes the config file syntax is a bear. That's not a result of the program's design. Having had to hack local mods into sendmail's code before, I find it relatively easy to do so. To me, that's the ultimate criteria for a good design: someone who wasn't part of the design team finds it easy to modify the program.
That depends on whether or not the software needs a redesign. One of the advantages of open-source is that, given the number of people working on a piece of software, design decisions that make it hard to maintain and/or extend get found and eliminated early in it's life. The result is software that doesn't suffer nearly as badly from rot as changes are made. The canonical examples would be BIND or the nigh-immortal sendmail
Hopefully any initiative along these lines will be constructed a bit more reliably than your 20-year-old mainframe.
Microsoft's software, which they presumably are going to use as the basis for the central server, is about 2-3 orders of magnitude less reliable than that "20-year-old mainframe", based on uptime figures. And the central server is only one part of the reliability chain, a failure in a router or network hub will take down the system even if both the server and the client system are running perfectly. Maybe a distributed, redundant database system, but distributing the data wipes out the gains from centralizing it.
I do the same at-work, at-home stuff you probably do. The difference is that I'm not dependent on the work system when at home. I need it to be reachable to pass data back and forth, but I still have all my apps, config data and such locally when the connection is down. For syncing things up, rdist and the occasional bit of diff and patch magic works nicely.
And, as you pointed out, X11 and Unix already have complete remote access to the desktop, apps and config data on another system down pat. Rather than creating yet another standard, why doesn't NT simply adopt the network- and location-independent approach we're used to using X11?
I've done both. If you're looking at an MB with integrated video/sound/NIC, look at the chipset they're using and check if Linux supports it. If the kernel (or the X server in the case of video chipsets) supports the chipset, things should work fine.
OTOH, the integrated stuff tends to be at the low end of the scale. Some boards are using moderately decent S3 video, but generally you'll find that for not much more you can get better performance and better quality output from add-in cards. Plus it's easier to replace the cards with newer hardware than it is to disable and replace the integrated stuff.
Technically there shouldn't be any problems with integrated hardware if the basic chipsets are supported. If you're building a system where performance isn't a major issue in that area, integrated hardware might be a bit cheaper. If you need maximum performance and/or flexibility, skip the integrated stuff and go for seperate cards.
I see one big disadvantage, the same one we had with terminals attached to central mainframes: lose the server, lose everything. If your network connection is down, regardless of why, you can't even work locally. Not to mention the fun when the central staff "upgrades" the software to a version that breaks half your stuff with no warning whatsoever. What joy.
I'm going to be optimistic and assume this is sarcasm.
I don't understand why we would want to GPL our software. What advantage is it to our clients if we've solved a problem for them that a competitor could gain access to without paying for it, funding the development?
Turn that around: how much advantage would it be for you to be able to get all of your competitor's code without having to pay them for it? Once you rephrase the question from "Is it costing me anything?" to "Is what I get back worth what it costs me?", things change a bit.