I would say the best practical definition of "Troll" is "I disagree". It doesn't have anything to do correctness.
Both the orginal statement and the reverse statement were equally guilty of making very broad claims without proof. The difference is that more people on Slashdot want to believe the postive statement on Linux then on Windows so they mod one as a "Troll" and the other gets a free pass.
My little experiment forced some people to examine their conscience which people generally don't like to do.
This was a test of the Slashdot moderation system.
Here's how the test works: You take a strong statement made by a previous poster that compares the relative value of Linux and Windows and swap the words "Linux" and "Windows" and post it. This should flip the "Troll" bit.
As you can see, Slashdot moderation is working properly. Thank you for your cooperation.
IBM, an industry leader in [choose an OS] solutions and supporter of [choose a movement], is pursuing membership and plans to be an active participant in the [choose a group].
It think you underestimate in-house programmers. In any case, in-house projects are the least likely candidates for cross-platform development.
Since J++ performed better on Windows than 100% Pure Java (although that phrase didn't exist at the time), in-house programmers would probably have formed a more favorable impression of Java then they would have otherwise.
Of course, once Sun sued MS and J++ was frozen at a particular Java release number (I don't remember which one), it was incompatible with new code and there was less reason to use it (it was still a good language for COM development though).
By then many Windows programmers were sick of the politics and switched back to C++, MFC, ATL, or VB. I suspect if J++ had not been created, even this brief flirtation with Java on Windows probably wouldn't have happened.
So, I think there's at least as much evidence that Sun shot themselves in the foot as there is that MS was responsible.
If what you mean is that you've studied every line of code in Linux carefully to determine that exploits are not possible and assuming you're qualified to make such a judgement, then you can legitimately say it's secure based on your knowledge.
If what you mean is that you could theoretically determine it was secure because the source code is open, then you're just blowing smoke.
Re:the focus on "support concerns" is rather ironi
on
Linux Usage in the UK
·
· Score: 1
x = % of cost due to support for open source y = % of cost due to support for closed source z = % of total cost savings of open source over closed source
You're claiming that x-y = z. You're subtracting apples from apples and getting oranges.
Re:the focus on "support concerns" is rather ironi
on
Linux Usage in the UK
·
· Score: 1
If your software is free, support is 100% of the total cost, so I guess by your analysis closed source is better than open source. Or perhaps your 80% figure doesn't really prove anything.
Re:not *intended* to replace the camel book
on
First Perl 6 Book is Out
·
· Score: 3, Insightful
You forgot ".. Annoyances" which is purchased by people who don't use the product described in the book.
"The conforming extensions were welcome and handy for high level WIndows programming. But MS insisted on dropping in extensions to the java.* core packages to catch the unwary. "
Oh yeah, the hypothetical "unwary". Did Sun show any real evidence that companies had used J++ with the desire to be cross-platform, finished their product, brought it to the marketplace and then afterward found to their horror that it wasn't class platform and wouldn't run on the intended platforms? (I mean beyond the cross-platform problems they have using any Java language implementation).
If I were a Sun shareholder I'd want MS to pay money instead. MS distributing Sun's Java in Windows isn't going to have much positive effect on Sun's bottom line. This case is not about business, it's about ego.
The contract that MS broke was settled to the tune of millions of $ paid to Sun. MS didn't break the latest contract which did not commit MS to distributing Sun's Java.
The current litigation is a private antitrust case, not a contract dispute.
It's a bit dangerous to compare books and software. Fair use might protect you if you were merely publishing a small section of code as text, but incorporating it into a runnable product is a bit different. It would be more like incorporating 1 min of someone else's movie in your movie. I doubt that fair use would protect you in that case.
Reading your post some may get the impression that using C++ on Windows requires using MFC. This is not the case. For many applications MFC offers little advantage over calling the Windows API directly from C++. So if you "want a custom UI that looks great", you don't need to know anything about MFC.
I think the JM chip has been something Sun has always wanted to do and the real reason they were pissed at MS since J++ made such a chip unnecessary (at least for Windows).
Of course this flies in the face of the stated goal of Java: Write_Once-Run-Anywhere. If good performance required special proprietary hardware Java would offer little portability advantage over other languages (assuming it has it now).
"For the price of some of these packages, you can hire 2 developers (or more!) for a year and get them to code an application that does EXACTLY what you want."
Does exactly what WHO wants? Once the person who was king has left the company, his replacement will have his own ideas about how the application should work, so you can throw away the application and hire more developers.
Too much time is already wasted in indulging some managers, let's not encourange them to waste more time.
I'm not against documentation, I just think a lot of energy is wasted on naming conventions.
If the issue were merely obfuscated names as your example suggests, I wouldn't have a problem with it. The problem comes when an attempt is made to embedded additional information in a name beyond its local meaning. Typically naming conventions are inconsistent, incomplete, and a distraction from more important issues.
All that time spent making sure variable names are politically correct (Hungarian or otherwise) could be spend actually evaluating whether the code will function properly.
When was the last time you couldn't understand a section of code because they didn't follow the naming convention?
Slashdot Mirror
So you're saying that the XP menu system is multi-functional?
I would say the best practical definition of "Troll" is "I disagree". It doesn't have anything to do correctness.
Both the orginal statement and the reverse statement were equally guilty of making very broad claims without proof. The difference is that more people on Slashdot want to believe the postive statement on Linux then on Windows so they mod one as a "Troll" and the other gets a free pass.
My little experiment forced some people to examine their conscience which people generally don't like to do.
So "factually incorrect" is the definition of "Troll". Gee, I didn't know that.
This was a test of the Slashdot moderation system.
Here's how the test works: You take a strong statement made by a previous poster that compares the relative value of Linux and Windows and swap the words "Linux" and "Windows" and post it. This should flip the "Troll" bit.
As you can see, Slashdot moderation is working properly. Thank you for your cooperation.
Maybe other manufacturers and consumers will realize that windows is superior to linux in just about every way possible.
IBM, an industry leader in [choose an OS] solutions and supporter of [choose a movement], is pursuing membership and plans to be an active participant in the [choose a group].
It think you underestimate in-house programmers. In any case, in-house projects are the least likely candidates for cross-platform development.
Since J++ performed better on Windows than 100% Pure Java (although that phrase didn't exist at the time), in-house programmers would probably have formed a more favorable impression of Java then they would have otherwise.
Of course, once Sun sued MS and J++ was frozen at a particular Java release number (I don't remember which one), it was incompatible with new code and there was less reason to use it (it was still a good language for COM development though).
By then many Windows programmers were sick of the politics and switched back to C++, MFC, ATL, or VB. I suspect if J++ had not been created, even this brief flirtation with Java on Windows probably wouldn't have happened.
So, I think there's at least as much evidence that Sun shot themselves in the foot as there is that MS was responsible.
"I read every line of code before I compile it"
That's nice but it's going to take a lot more effort than that to insure it's secure.
"Of course, you wouldn't know what "efficiency" and "quality" are, since you use closed-source proprietary crap."
Well, unless you designed your own microprocessor, wrote your own BIOS etc, you also use closed source stuff so I guess we are both in the same boat.
"I know it's secure because I can see the code"
If what you mean is that you've studied every line of code in Linux carefully to determine that exploits are not possible and assuming you're qualified to make such a judgement, then you can legitimately say it's secure based on your knowledge.
If what you mean is that you could theoretically determine it was secure because the source code is open, then you're just blowing smoke.
x = % of cost due to support for open source
y = % of cost due to support for closed source
z = % of total cost savings of open source over closed source
You're claiming that x-y = z. You're subtracting apples from apples and getting oranges.
If your software is free, support is 100% of the total cost, so I guess by your analysis closed source is better than open source. Or perhaps your 80% figure doesn't really prove anything.
You forgot ".. Annoyances" which is purchased by people who don't use the product described in the book.
Another PR victory for the Linux community.
"The conforming extensions were welcome and handy for high level WIndows programming. But MS insisted on dropping in extensions to the java.* core packages to catch the unwary. "
Oh yeah, the hypothetical "unwary". Did Sun show any real evidence that companies had used J++ with the desire to be cross-platform, finished their product, brought it to the marketplace and then afterward found to their horror that it wasn't class platform and wouldn't run on the intended platforms? (I mean beyond the cross-platform problems they have using any Java language implementation).
Actually J++ was a particularly good language for writing Windows COM applications. Not as fast as C++ but a lot easier to use.
If I were a Sun shareholder I'd want MS to pay money instead. MS distributing Sun's Java in Windows isn't going to have much positive effect on Sun's bottom line. This case is not about business, it's about ego.
The contract that MS broke was settled to the tune of millions of $ paid to Sun. MS didn't break the latest contract which did not commit MS to distributing Sun's Java.
The current litigation is a private antitrust case, not a contract dispute.
I guess you're talking hypothetically since no such contract exists between MS and Sun.
There's no contract between MS and Sun in which MS committed to distributing Sun's JVM so it's not a matter of government enforcement.
It's a bit dangerous to compare books and software. Fair use might protect you if you were merely publishing a small section of code as text, but incorporating it into a runnable product is a bit different. It would be more like incorporating 1 min of someone else's movie in your movie. I doubt that fair use would protect you in that case.
Reading your post some may get the impression that using C++ on Windows requires using MFC. This is not the case. For many applications MFC offers little advantage over calling the Windows API directly from C++. So if you "want a custom UI that looks great", you don't need to know anything about MFC.
I think the JM chip has been something Sun has always wanted to do and the real reason they were pissed at MS since J++ made such a chip unnecessary (at least for Windows).
Of course this flies in the face of the stated goal of Java: Write_Once-Run-Anywhere. If good performance required special proprietary hardware Java would offer little portability advantage over other languages (assuming it has it now).
"For the price of some of these packages, you can hire 2 developers (or more!) for a year and get them to code an application that does EXACTLY what you want."
Does exactly what WHO wants? Once the person who was king has left the company, his replacement will have his own ideas about how the application should work, so you can throw away the application and hire more developers.
Too much time is already wasted in indulging some managers, let's not encourange them to waste more time.
I'm not against documentation, I just think a lot of energy is wasted on naming conventions.
If the issue were merely obfuscated names as your example suggests, I wouldn't have a problem with it. The problem comes when an attempt is made to embedded additional information in a name beyond its local meaning. Typically naming conventions are inconsistent, incomplete, and a distraction from more important issues.
All that time spent making sure variable names are politically correct (Hungarian or otherwise) could be spend actually evaluating whether the code will function properly.
When was the last time you couldn't understand a section of code because they didn't follow the naming convention?