Flip your thinking around a bit. Linux, in effect, restricts Sun to working mainly at the high end, in the big iron arena. At the low end, Solaris is expensive, and it's overkill. Linux is quite sufficient, cheaper, and even arguably more secure because of all the eyeballs that look at the code. Sun offsets this somewhat by allowing Linux on Sparc, which allows them to sell Sparc hardware to those who would find Solaris too expensive and would otherwise go for Linux on Intel. However, I suspect that Sun still loses to Linux on Intel at the low end because PC platforms are still cheaper and more widely available.
Further, there is no guarantee that Linux will stay at the low end. The Linux developers seem pretty ambitious, and it it quite possible that two or three years from now that Linux might be scalable enough to rival Solaris. Note that Linux need not be *as* scalable as Solaris in order to be a threat. It could simply provide sufficient scalability so that it could be used where Solaris might otherwise be used. While Linux isn't a strong threat to Sun's revenue stream now, Sun has no guarantee that it will not be in the future, and Sun may very well see Linux as a potential *long-term* threat.
This has nothing to do with the "Open Source Bugaboo." The problem with the upgrade treadmill is that the "upgrades" don't particularly introduce new useful functionality, but instead mostly just introduce gratuituous incompatibility. Doesn't it strike you as unethical for a vendor to introduce incompatibility for incompatibility's sake?
"i wish they'd choose to teach a logic course using psuedocode than any other language."
I've dabbled in Python. It's been described as "executable psuedocode", and from what I've seen of it, it's an accurate description. You are absolutely right; programming is about logic. Python was chosen as their initial language choice because it's good at illustrating programming logic without a lot of fuss.
"The BSD license is more open, but is also quite broken. Other than obvious things like the advertising clause, if BSD ever went mainstream, MS could proprietize it."
BSD-licensed code is potentially more vulerable to becoming permanently proprietary, because there is nothing in the license that forces the users of BSD-licensed code to keep their copy of the code open. If development ceased on a BSD-licensed project and it was orphaned, then someone who could obtain all the copies of the code and keep it hidden from the public, whereas an orphaned GPL project is still legally protected (we hope, anyway) from becoming proprietary. In essence, the freedom of BSD-licensed code is dependent on the commitment of the maintainers to keep it free. In practice this means that so long as the maintainers of the free *BSDs are still doing their thing, the free *BSDs will still remain free. Can MS use their code? Sure. Does that mean that the *BSD code can become proprietary? Only if the *BSD coders abandon the code.
"Even hire off the best BSD developers c(who have no commitment to free software)"
I suspect that if they had no commitment to free software, then they wouldn't even bother contributing to FreeBSD, and/or other *BSDs. You can only hire someone away if they consent, and I suspect that many BSD developers would be suspicious if MS offered to hire them. Wouldn't you be suspicious?
Truly silly suggestion
on
FreeBSDCon 99
·
· Score: 1
If there's ever an convention or expo for both the Linux and *BSD crowds, I think that they ought to have a wresting match between a guy in a Tux costume and a guy in a BSD daemon costume. I don't think it's that much sillier than a paintball fight between vi and emacs partisans (which actually was an event at a Linux convention), and it would give people a chance to laugh at themselves.
"Private, protected, and public interfaces are usefull only if you don't trust people using your class. I have go with the Perl philosophy on this one -- programmers shouldn't touch class internals because they aren't supposed to, not because they aren't allowed to. Not that declaring something 'private' will keep anyone from accessing the private members if they want to. Yes, C can't do it at all, I just don't think it's an important part of good OO design."
The Perl philosophy may not be applicable here. Perl is, AFAIK, really intended to be used for small to medium size projects. Its core competencies are not the same as those of C++ or C. For a small to medium size project, you can probably get away with relying on programmers to not step on class internals. Also, for large projects, you may not be able to get away hacks with internals that are tolerable or even perhaps necessary for smaller projects. In large projects, programmers will likely vary in skill level and experience, simply because there are enough people working on the project so that the distribution of talent within the pool of programmers working on the project is reflective of the distribution of talent of the pool of all programmers at large. Less skilled and less experienced programmers may not fully understand the problems with directly accessing class internals. If it is imposssible to access the internals of a class, then you can screen out the bugs that a lesser skilled programmer might get away with if the compiler didn't stop him or her. In short, you may not be able to trust the users of your class to program cleanly and not muck with internals.
I think the point is that it is much easier to write object-oriented code in C++ than it is in C. I've been exposed briefly to both languages, and from what I can tell, C++ provides higher-level language structures, such as classes, which allow one to write object-oriented programs relatively straightforwardly, while C is by nature a procedural language, so that one who wishes to write object-oriented code in C must find a way to force C's language constructs into an object-oriented mold. In other words, AFAIK, if you're talking about objects and classes, it's easier to say what you mean in C++ than it is in C. This could very well make the difference between code that is easy to debug and code that isn't.
I could be wrong here, and all you real programmers out there are free to correct me.
Actually, the issue of KDE-GNOME interoperability is being addressed. Eventually, one should be able to do something like embed a Gnumeric spreadsheet into Kword. That's probably not something that were going to see for quite a while, maybe in the next couple years.
> Suposedly it only covers "hinting". Someone had > said to me that prior art almost definitly > exists (going back to the egyptions and the > ancient greeks no less).
AFAIK, "hinting" determines what the fonts looks like at different sizes. TrueType font Foo at 12 point may have its serifs positioned a bit differently than the same font at 5 point, for reasons relateded both to aesthetics and readability. I don't think whatever the Greeks and Egyptians did could be considered prior art.
I'd suggest keeping a sharp eye on patent issues. I would not put any trust in a company's laxity in enforcing a patent. A change in leadership could change a company from benign to litigious. If Apple really wants to come down on you and put you in the poorhouse, they probably can. It would be irrational and potentially bad PR for them to do so, certainly, but human beings in general are not always rational and they don't always act in their own best interests. I would not put too much stock in anyone's forbearance.
> A programmer examining the original source for a > program is likely to fall into the same traps as > the author of the program due to reliance on > comments in order to understand the code. When > you are searching through a decompile or > tracing the execution of a binary for which you > don't have the source, you are likely to examine > the program far more closely than you would if > you had source available. Hence you will be more > likely to notice odd program behavior that my be > obscured otherwise.
That's assuming that the programmer is relying on comments to understand the code. I would suspect that a good programmer, or even a decent one would still read the code itself. A programmer may very well look at the comments in the code and say to him/herself "Ok, that's what this code is supposed to do, now let me read the code to see if it really does that."
Ultmately, though, the problem with your comment is that it doesn't work out in practice. In practice, the peer review that open-source software gets does cause bugs to be fixed faster and security holes to be plugged. This isn't theory; this is what ends up actually happening.
> There were probably were half man half apes, but > over time we ate all their food, or all of them > and they became extinct.
That's not a great explanation. If the halfway-man-halfway-apes were starved to death, skeletons should probably have been left behind. If they were eaten, then of course bone evidence might be more lacking, since the after-meal bones would probably get strewn about. Still, there should be something left behind. Ah, questions, questions . . .
This actually could make for a good science classroom discussion, looking at a problem from different angles, trying to see what does and does not fit. That's what science is about.
No it doesn't make sense. The SAMBA developers are already known to use reverse-engineering to figure out NT's network protocols. You could find this out by reading trade publications, Linux web sites, etc. Why would a computer have to announce "Here's what user X is doing"? If reverse-engineering becomes illegal, that throws SAMBA's legal status into question, period. That would make any business gun-shy of going near SAMBA.
The UCITA would make the anti-reverse engineering clauses in software licenses legally enforceable. That could chill the development of such things as SAMBA, which is dependent on reverse-engineering NT protocols.
> Oh, and the information on using X and > installing fonts seemed out of place. Either > you're relatively unix clueful, and can manage > them, or you're not and you have a sysadmin who > does it for you.
Or you're only mildly clueful home user who doesn't have a sysadmin, and doesn't get a chance to learn about how X handles fonts until he/she comes across a problem that requires him/her to find out. That's probably why that section on fonts that you described is in that Artist's Guide to the Gimp.
Crusade's first episode was pretty bad. It dragged on and used overly dramatic dialog. It was clunky the way B5 movies have often been clunky. The episodes after that were pretty cool, though. I'd say the writing was about on par with the B5 series.
> Reading the GPL doesn't mean you agree to the > contract. Using the software doesn't mean you > agree to the contract.
But distributing it does bind you. This is a quote from Version 2 of the GPL (June 1991):
"You are not required to accept this license, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it."
In a nutshell, if you use the software for your own use and don't distribute it, you aren't bound to accept the GPL. Once you've copied and distributed the software, though, that means that you must accept the terms of the GPL since they are what allow you to copy and distribute in the first place.
I remember one of my teachers doing a demonstration in which he had a vase with a ball inside it. If you tried to get the ball out by just sticking your hand in the vase and grabbing the ball, you can't pull your hand back out of the vase. The only way to get the ball out was to turn the vase upside-down and let the ball drop out. The moral of the demonstration was that to get what you want, sometimes you have to let go.
Sun has tried to maintain too much control over Java, and the result has stunted its potential. Java was supposed to be write-once-run-anywhere, but by trying to keep their implementation proprietary, they discouraged Java from proliferating. If Sun had made their implementation free, source and all, it would have encouraged distribution, so that Java could indeed run anywhere, and discouraged alternative implementations--why bother making another implementation if one is readily available?
If Sun gave Java away, they could have probably made a nice amount of money off Java apps. But they didn't, and Java is still kind of in its little corner.
The trouble with BSD-licensed code is that someone can modify it a little and then hide the source from then on. If the code no longer maintained or whatnot, the original BSD-licensed copies of the code can die out, leaving only the proprietary licensed code left. With GPL, even if the code is modified, it can't be made proprietary. Even if the code ceases to be maintained, if there is at least one copy of the code around, even if it's modified, it's still free.
Basically, the freedom of BSD-licensed code is more contingent on the maintainers of the code keeping it free.
The issue that the article was talking about was whether Linux was suitable for very high-end servers. High-end servers aren't the domain of NT, but rather the commercial Unices put out by the likes of Sun, IBM, HP, and so on.
This is pretty much an issue of Unix flavor vs. Unix flavor. Linux just happens to still be a fairly low-end Unix flavor--at least for now.
> However, I must say that the biggest drag on > Linux becoming successful are the radical > elements of the community, who frothingly bash > Microsoft and drool over Linux.
Look, in any community, there will always be the radical elements. There really isn't any way to get rid of them. The best you can do is to keep them from setting the tone of the whole community.
> To a great extent, it's the Mac advocacy that > killed the Macintosh in corporate America.
Actually, I think what killed the Mac was that Win 3.1 + a PC clone was cheaper than the Mac. Windows was a halfway decent cheap GUI that ran on a halfway decent cheap machine that people could afford, namely the 386. While the Mac's GUI was arguably more elegant, the Mac was more expensive. People "voted" with their pocketbooks and Windows 3.1 won. As for Windows 95 . . . well, that's another story. (Uy!)
No one said that KDE and GNOME were planning a merger. What the KDE and GNOME developers are trying to do is have it so that KDE apps and GNOME apps can interoperate with each other.
To some extent, you're talking apples and oranges. This is a college library that you are talking about, and "Pornoman" is legally an adult, whereas the issue in question is how to keep kids from viewing porn in public libraries. From a practical standpoint, it is probably easier for a librarian to tap the shoulder of a kid viewing Internet porn and tell them to leave, than it is to tap the shoulder of a corresponding adult. Also, it is legally much easier, I suspect, to make rules about what content a kid is allowed to access versus what an adult is allowed to access. There is already precedent for barring kids from engaging in conduct considered harmful to them, but conduct that adults are allowed to engage in; kids are not allowed to smoke, drink, and AFAIK, they are not allowed to view printed porn. AFAIK, adults legally have the right to view porn themselves, at least when they are by themselves or with others who are viewing the porn with them. My point is that it is probably much easier to take action against "Pornokid" than "Pornoman".
As is already painful obvious from what I've said above, I am not a lawyer.
Re:Remember whose benchmarks these are . . .
on
NT vs. Linux: Again
·
· Score: 1
> I guess you didn't read the article at all. > Linux has a problem! The TCP stack is single > threaded and can't compete with NT on multi-proc > systems
Actually, I did read the article. I'm just suspicious. For all I knew at the time, the explanation regarding the TCP stack could have been false or distorted. Later things that I read seemed to show otherwise, that indeed the TCP problem was a real and legitimate problem. Fair enough.
I read an article later at the Linux Daily News (6/27/1999) analyzing the results of not only the benchmarks in question, but previous ones, including those that had Linux 'winning', focusing on differences in the testing conditions. The number of clients really made a difference; with a large number of clients, Linux's performance sank due to some bottlenecks like the TCP problem, which is partly why the Mindcraft rematch came out as it did. Also fair enough.
The trouble was that it looked to me at the time that PC Week was merely detailing Mindcraft's results, which didn't tell much at the time since I knew Mindcraft had done hatchet jobs before and had a vested interest in the outcome. They could very well have made up a technical explanation as to why the results turned out as they did. To determine whether the results were due to dishonest testing or to real problems, or even both, requires having others look at the results (which has since been done). The point I was trying to make was that Mindcraft shouldn't have been taken at their word, since they haven't been all that honest before.
Slashdot Mirror
Flip your thinking around a bit. Linux, in effect, restricts Sun to working mainly at the high end, in the big iron arena. At the low end, Solaris is expensive, and it's overkill. Linux is quite sufficient, cheaper, and even arguably more secure because of all the eyeballs that look at the code. Sun offsets this somewhat by allowing Linux on Sparc, which allows them to sell Sparc hardware to those who would find Solaris too expensive and would otherwise go for Linux on Intel. However, I suspect that Sun still loses to Linux on Intel at the low end because PC platforms are still cheaper and more widely available.
Further, there is no guarantee that Linux will stay at the low end. The Linux developers seem pretty ambitious, and it it quite possible that two or three years from now that Linux might be scalable enough to rival Solaris. Note that Linux need not be *as* scalable as Solaris in order to be a threat. It could simply provide sufficient scalability so that it could be used where Solaris might otherwise be used. While Linux isn't a strong threat to Sun's revenue stream now, Sun has no guarantee that it will not be in the future, and Sun may very well see Linux as a potential *long-term* threat.
This has nothing to do with the "Open Source Bugaboo." The problem with the upgrade treadmill is that the "upgrades" don't particularly introduce new useful functionality, but instead mostly just introduce gratuituous incompatibility. Doesn't it strike you as unethical for a vendor to introduce incompatibility for incompatibility's sake?
"i wish they'd choose to teach a logic course using psuedocode than any other language."
I've dabbled in Python. It's been described as "executable psuedocode", and from what I've seen of it, it's an accurate description. You are absolutely right; programming is about logic. Python was chosen as their initial language choice because it's good at illustrating programming logic without a lot of fuss.
You are only half right, IMHO, at best.
"The BSD license is more open, but is also quite broken. Other than obvious things like the advertising clause, if BSD ever went mainstream, MS could proprietize it."
BSD-licensed code is potentially more vulerable to becoming permanently proprietary, because there is nothing in the license that forces the users of BSD-licensed code to keep their copy of the code open. If development ceased on a BSD-licensed project and it was orphaned, then someone who could obtain all the copies of the code and keep it hidden from the public, whereas an orphaned GPL project is still legally protected (we hope, anyway) from becoming proprietary. In essence, the freedom of BSD-licensed code is dependent on the commitment of the maintainers to keep it free. In practice this means that so long as the maintainers of the free *BSDs are still doing their thing, the free *BSDs will still remain free. Can MS use their code? Sure. Does that mean that the *BSD code can become proprietary? Only if the *BSD coders abandon the code.
"Even hire off the best BSD developers c(who have no commitment to free software)"
I suspect that if they had no commitment to free software, then they wouldn't even bother contributing to FreeBSD, and/or other *BSDs. You can only hire someone away if they consent, and I suspect that many BSD developers would be suspicious if MS offered to hire them. Wouldn't you be suspicious?
If there's ever an convention or expo for both the Linux and *BSD crowds, I think that they ought to have a wresting match between a guy in a Tux costume and a guy in a BSD daemon costume. I don't think it's that much sillier than a paintball fight between vi and emacs partisans (which actually was an event at a Linux convention), and it would give people a chance to laugh at themselves.
"Private, protected, and public interfaces are usefull only if you don't trust people using your class. I have go with the Perl philosophy on this one -- programmers shouldn't touch class internals because they aren't supposed to, not because they aren't allowed to. Not that declaring something 'private' will keep anyone from accessing the private members if they want to. Yes, C can't do it at all, I just don't think it's an important part of good OO design."
The Perl philosophy may not be applicable here. Perl is, AFAIK, really intended to be used for small to medium size projects. Its core competencies are not the same as those of C++ or C. For a small to medium size project, you can probably get away with relying on programmers to not step on class internals. Also, for large projects, you may not be able to get away hacks with internals that are tolerable or even perhaps necessary for smaller projects. In large projects, programmers will likely vary in skill level and experience, simply because there are enough people working on the project so that the distribution of talent within the pool of programmers working on the project is reflective of the distribution of talent of the pool of all programmers at large. Less skilled and less experienced programmers may not fully understand the problems with directly accessing class internals. If it is imposssible to access the internals of a class, then you can screen out the bugs that a lesser skilled programmer might get away with if the compiler didn't stop him or her. In short, you may not be able to trust the users of your class to program cleanly and not muck with internals.
I think the point is that it is much easier to write object-oriented code in C++ than it is in C. I've been exposed briefly to both languages, and from what I can tell, C++ provides higher-level language structures, such as classes, which allow one to write object-oriented programs relatively straightforwardly, while C is by nature a procedural language, so that one who wishes to write object-oriented code in C must find a way to force C's language constructs into an object-oriented mold. In other words, AFAIK, if you're talking about objects and classes, it's easier to say what you mean in C++ than it is in C. This could very well make the difference between code that is easy to debug and code that isn't.
I could be wrong here, and all you real programmers out there are free to correct me.
Actually, the issue of KDE-GNOME interoperability is being addressed. Eventually, one should be able to do something like embed a Gnumeric spreadsheet into Kword. That's probably not something that were going to see for quite a while, maybe in the next couple years.
> Suposedly it only covers "hinting". Someone had
> said to me that prior art almost definitly
> exists (going back to the egyptions and the
> ancient greeks no less).
AFAIK, "hinting" determines what the fonts looks like at different sizes. TrueType font Foo at 12 point may have its serifs positioned a bit differently than the same font at 5 point, for reasons relateded both to aesthetics and readability. I don't think whatever the Greeks and Egyptians did could be considered prior art.
I'd suggest keeping a sharp eye on patent issues. I would not put any trust in a company's laxity in enforcing a patent. A change in leadership could change a company from benign to litigious. If Apple really wants to come down on you and put you in the poorhouse, they probably can. It would be irrational and potentially bad PR for them to do so, certainly, but human beings in general are not always rational and they don't always act in their own best interests. I would not put too much stock in anyone's forbearance.
"How about jamming your opponent's RC channel?"
Wouldn't be sporting, I think. Also not very interesting to watch.
> A programmer examining the original source for a
> program is likely to fall into the same traps as
> the author of the program due to reliance on
> comments in order to understand the code. When
> you are searching through a decompile or
> tracing the execution of a binary for which you
> don't have the source, you are likely to examine
> the program far more closely than you would if
> you had source available. Hence you will be more
> likely to notice odd program behavior that my be
> obscured otherwise.
That's assuming that the programmer is relying on comments to understand the code. I would suspect that a good programmer, or even a decent one would still read the code itself. A programmer may very well look at the comments in the code and say to him/herself "Ok, that's what this code is supposed to do, now let me read the code to see if it really does that."
Ultmately, though, the problem with your comment is that it doesn't work out in practice. In practice, the peer review that open-source software gets does cause bugs to be fixed faster and security holes to be plugged. This isn't theory; this is what ends up actually happening.
> There were probably were half man half apes, but
> over time we ate all their food, or all of them
> and they became extinct.
That's not a great explanation. If the halfway-man-halfway-apes were starved to death, skeletons should probably have been left behind. If they were eaten, then of course bone evidence might be more lacking, since the after-meal bones would probably get strewn about. Still, there should be something left behind. Ah, questions, questions . . .
This actually could make for a good science classroom discussion, looking at a problem from different angles, trying to see what does and does not fit. That's what science is about.
No it doesn't make sense. The SAMBA developers are already known to use reverse-engineering to figure out NT's network protocols. You could find this out by reading trade publications, Linux web sites, etc. Why would a computer have to announce "Here's what user X is doing"? If reverse-engineering becomes illegal, that throws SAMBA's legal status into question, period. That would make any business gun-shy of going near SAMBA.
The UCITA would make the anti-reverse engineering clauses in software licenses legally enforceable. That could chill the development of such things as SAMBA, which is dependent on reverse-engineering NT protocols.
Now go have your coffee . . . :-)
> Oh, and the information on using X and
> installing fonts seemed out of place. Either
> you're relatively unix clueful, and can manage
> them, or you're not and you have a sysadmin who
> does it for you.
Or you're only mildly clueful home user who doesn't have a sysadmin, and doesn't get a chance to learn about how X handles fonts until he/she comes across a problem that requires him/her to find out. That's probably why that section on fonts that you described is in that Artist's Guide to the Gimp.
Crusade's first episode was pretty bad. It dragged on and used overly dramatic dialog. It was clunky the way B5 movies have often been clunky. The episodes after that were pretty cool, though. I'd say the writing was about on par with the B5 series.
> Reading the GPL doesn't mean you agree to the
> contract. Using the software doesn't mean you
> agree to the contract.
But distributing it does bind you. This is a quote from Version 2 of the GPL (June 1991):
"You are not required to accept this license, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it."
In a nutshell, if you use the software for your own use and don't distribute it, you aren't bound to accept the GPL. Once you've copied and distributed the software, though, that means that you must accept the terms of the GPL since they are what allow you to copy and distribute in the first place.
I remember one of my teachers doing a demonstration in which he had a vase with a ball inside it. If you tried to get the ball out by just sticking your hand in the vase and grabbing the ball, you can't pull your hand back out of the vase. The only way to get the ball out was to turn the vase upside-down and let the ball drop out. The moral of the demonstration was that to get what you want, sometimes you have to let go.
Sun has tried to maintain too much control over Java, and the result has stunted its potential. Java was supposed to be write-once-run-anywhere, but by trying to keep their implementation proprietary, they discouraged Java from proliferating. If Sun had made their implementation free, source and all, it would have encouraged distribution, so that Java could indeed run anywhere, and discouraged alternative implementations--why bother making another implementation if one is readily available?
If Sun gave Java away, they could have probably made a nice amount of money off Java apps. But they didn't, and Java is still kind of in its little corner.
The trouble with BSD-licensed code is that someone can modify it a little and then hide the source from then on. If the code no longer maintained or whatnot, the original BSD-licensed copies of the code can die out, leaving only the proprietary licensed code left. With GPL, even if the code is modified, it can't be made proprietary. Even if the code ceases to be maintained, if there is at least one copy of the code around, even if it's modified, it's still free.
Basically, the freedom of BSD-licensed code is more contingent on the maintainers of the code keeping it free.
The issue that the article was talking about was whether Linux was suitable for very high-end servers. High-end servers aren't the domain of NT, but rather the commercial Unices put out by the likes of Sun, IBM, HP, and so on.
This is pretty much an issue of Unix flavor vs. Unix flavor. Linux just happens to still be a fairly low-end Unix flavor--at least for now.
> However, I must say that the biggest drag on
> Linux becoming successful are the radical
> elements of the community, who frothingly bash
> Microsoft and drool over Linux.
Look, in any community, there will always be the radical elements. There really isn't any way to get rid of them. The best you can do is to keep them from setting the tone of the whole community.
> To a great extent, it's the Mac advocacy that
> killed the Macintosh in corporate America.
Actually, I think what killed the Mac was that Win 3.1 + a PC clone was cheaper than the Mac. Windows was a halfway decent cheap GUI that ran on a halfway decent cheap machine that people could afford, namely the 386. While the Mac's GUI was arguably more elegant, the Mac was more expensive. People "voted" with their pocketbooks and Windows 3.1 won. As for Windows 95 . . . well, that's another story. (Uy!)
No one said that KDE and GNOME were planning a merger. What the KDE and GNOME developers are trying to do is have it so that KDE apps and GNOME apps can interoperate with each other.
To some extent, you're talking apples and oranges. This is a college library that you are talking about, and "Pornoman" is legally an adult, whereas the issue in question is how to keep kids from viewing porn in public libraries. From a practical standpoint, it is probably easier for a librarian to tap the shoulder of a kid viewing Internet porn and tell them to leave, than it is to tap the shoulder of a corresponding adult. Also, it is legally much easier, I suspect, to make rules about what content a kid is allowed to access versus what an adult is allowed to access. There is already precedent for barring kids from engaging in conduct considered harmful to them, but conduct that adults are allowed to engage in; kids are not allowed to smoke, drink, and AFAIK, they are not allowed to view printed porn. AFAIK, adults legally have the right to view porn themselves, at least when they are by themselves or with others who are viewing the porn with them. My point is that it is probably much easier to take action against "Pornokid" than "Pornoman".
As is already painful obvious from what I've said above, I am not a lawyer.
> I guess you didn't read the article at all.
> Linux has a problem! The TCP stack is single
> threaded and can't compete with NT on multi-proc
> systems
Actually, I did read the article. I'm just suspicious. For all I knew at the time, the explanation regarding the TCP stack could have been false or distorted. Later things that I read seemed to show otherwise, that indeed the TCP problem was a real and legitimate problem. Fair enough.
I read an article later at the Linux Daily News (6/27/1999) analyzing the results of not only the benchmarks in question, but previous ones, including those that had Linux 'winning', focusing on differences in the testing conditions. The number of clients really made a difference; with a large number of clients, Linux's performance sank due to some bottlenecks like the TCP problem, which is partly why the Mindcraft rematch came out as it did. Also fair enough.
The trouble was that it looked to me at the time that PC Week was merely detailing Mindcraft's results, which didn't tell much at the time since I knew Mindcraft had done hatchet jobs before and had a vested interest in the outcome. They could very well have made up a technical explanation as to why the results turned out as they did. To determine whether the results were due to dishonest testing or to real problems, or even both, requires having others look at the results (which has since been done). The point I was trying to make was that Mindcraft shouldn't have been taken at their word, since they haven't been all that honest before.