Yeah, but I've been writing software commercially for almost a decade, and I've never yet needed a "true multidimensional array" and I've certainly never needed to write an FFT.
Well, thanks for at least being honest about your limited experience.
Until then, I'll pick a language that suits my needs (and, quite importantly, those of my employer) and not get my knickers in a twist about non-my-real-world scenarios that the language may or may not handle.
Do you deal with images? With graphics? With user interfaces? With databases? With spam? With audio? With speech? With video? Do you think that the libraries that support that functionality appear by magic? Do you think they don't cost anything to develop? Don't you mind when those libraries crash your application or create security holes?
Since Java isn't up to it, those libraries are still written in C. That's why it took so long to get something like the Java imaging API and why it took even longer to get it ported to the main platforms Java runs on. That's also why so many audio and video codecs for Java media aren't available on Macintosh or Linux. "Pure Java" is a lie: in order to do most of the things people would like to do with Java, the JCP keeps having to define new native code modules.
You may just be hacking application programs for a living, but you still depend on all those libraries and all that C code, whether you know it or not. And the fact that Java can't handle it means that your work gets a lot harder, even if you don't even realize it.
Several components of C# are integrated right into the operating system so naturally it's going to run faster on a windows machine.
Oh, really? How is going to be "integrated right into the operating system" going to help with integer and floating point microbenchmarks? I'd really like to know.
And, also, in what sense is the CLR "integrated right into the operating system" that the JVM isn't? Both are a bunch of DLLs running on top of the NT kernel. What's the difference in your mind?
Oh wait! C# only runs on one operating system. Can you name any other development languages that only run on ONE OS, boys and girls? Neither can I.
C# runs on many operating systems, as does the CLR. And unlike Java, all of whose implementations are derived and licensed from Sun, C# actually has multiple independent implementations.
C# is not quite as free and open as, say, ANSI C or Python. You have to decide for yourself whether C# is open enough for you. But C# is clearly far more open and non-proprietary than Java; Java is covered by numerous Sun patents and doesn't even have a free and open specification.
This is (once again) proof that Java is not slow, in fact it's really fast.
No, it is not "proof" that "Java is not slow". Doing well on those microbenchmarks is necessary to establish that Java is not slow, but it is far from sufficient.
It's like saying that a Civic is a really fast car because you can make it go really fast by welding some booster rockets to it. That may be true in some sense of the word "fast", but that isn't a sense of "fast" that is going to be of any use to real drivers because, among other things, you can't steer the thing once you light the booster rockets.
Java is not a good high performance language at this point. And, yes, that is a problem with the Java language, not just its implementations.
Also, the memory use should be addressed by project Barcelona
What 1.5 or 1.6 promise to address to some degree is excessive size of the code segment, by allowing code to be shared among multiple Java programs. But memory used for byte code and JIT output is only one of the ways in which Java memory usage is excessive; the Java language itself imposes lots of memory overhead on even simple data structurers and there is no indication that the Java language design is going to be changed to address that.
The Pentium trig instructions are not IEEE compliant (they don't return the correct values for large magnitude arguments). gcc errs on the side of caution and generates slow, software-based wrappers that correct for the limitations of the Pentium instructions by default. Other compilers (e.g., Intel and probably Microsoft) just generate the in-line instructions with no correction. When you look at the claimed superiority of other compilers over gcc, it is usually such tradeoffs that make gcc appear slower.
You can enable inline trig functions in gcc as well, either with a command line flag, or an include file, or by using "asm" statements on a case-by-case basis. Check the documentation. With those enabled, gcc keeps up well with other compilers on trig functions.
The Java JIT has been comparable to C in performance for many years on certain microbenchmarks. But Java remains a "slow language". Why?
The design of the Java language and the Java libraries means that enormous numbers of calls are made to the memory allocator in idiomatic Java.
The Java language has several serious limitations, such as the lack of true multidimensional arrays and the lack of value classes.
So, yes, you can construct programs, even some useful compute intensive programs, that perform as well or better on Java than they do in C. But that still doesn't make Java suitable for high-performance computing or building efficient software.
Benchmarks like the one published by OSnews don't test for these limitations. Microbenchmarks like those are still useful: if a language doesn't do well on them, that tells you that it is unsuitable for certain work; for example, based on those microbenchmarks alone, Python is unlikely to be a good language for Fortran-style numerical computing. But those kinds of microbenchmarks are so limited that they give you no guarantees that an implementation is going to be suitable for any real-world programming even if the implementation performs well on all the microbenchmarks.
I suggest you go through the following exercise: write a complex number class, then write an FFT using that complex number class, "void fft(Complex array[])", and then benchmark the resulting code. C, C++, and C# all will perform reasonably well. In Java, on the other hand, you will have to perform memory allocations for every complex number you generate during the computation.
Yes, the makers of Lego hold interviews to see who can create entire buildings and sculptures by snapping together little rectangular pieces of plastic. I think the marines are also holding interviews for the enviable job of cleaning entire barracks with nothing more than a toothbrush. Both jobs seems pretty similar to me--if you don't get the first, apply for the second.
For the life of me, can you imagine any CEO contributing as much to a company as 2290 rank and file workers? Unless they can literally print money, I have trouble imaging how an executive can make that kind of contribution compared to the employees they lead.
She probably isn't worth it. And the way the market punishes such waste is by having the company go out of business or get taken over. Just give it a few years.
I'm sure people will create color management for the Gimp. My point is: unlike what calibrationists claim, color calibration is not a requirement for professional imaging, it's just one particular hangup that a (sizeable) subpopulation of imaging professionals have. It's just that people who don't want or need calibration never complain about the fact that Photoshop has it or that the Gimp doesn't have. All you ever hear from is people who believe in calibration and keep whining that the Gimp doesn't have it.
Many so-called US firms actually do most of their business in other countries. Why shouldn't most of their jobs be in other countries as well?
In fact, from the point of the rest of the world, this looks like a long overdue change of direction. For decades, companies like IBM, Ford, Apple, MacDonalds, WalMart, etc., have displaced domestic manufacturers and service industries in those other nations and only created low-end jobs in those nations. Skilled jobs, administration, and management have largely remained in the US and the US has received a disproportionate share of the benefits from those overseas business activities. It's about time that high-skilled and high-paying jobs associated with US-based multinationals also move out of the US.
They have already done that many times and they will continue to do that. Usually, it happens when an ailing US company is taken over by a foreign company. Those foreign CEOs get paid much less than the US CEOs they replace.
Having CMYK support is all fine and dandy but it won't get you far in the printing world without support for colour profiles and colour calibration.
Some people swear by color calibration, other think its complete b.s. Not having color calibration certainly limits the acceptance of the Gimp.
But, since I'm in the category of people who think that color caliberation is b.s., maybe that's a good thing: let the calibrationists pay top dollar for useless features in Photoshop; maybe they'll go out of business, pick up flower arranging instead, and stop messing around with color. We can only hope.
Eventually, the Voyagers will pass other stars. In about 40,000 years, Voyager 1 will drift within 1.6 light years (9.3 trillion miles) of AC+79 3888, a star in the constellation of Camelopardalis. In some 296,000 years, Voyager 2 will pass 4.3 light years (25 trillion miles) from Sirius, the brightest star in the sky . The Voyagers are destined--perhaps eternally--to wander the Milky Way.
This answers the question of what advances are needed. Basically, we need either laser-powered solar sails, or we need antimatter propulsion. Even then, the trip would still take a long time and be enormously expensive.
Pull out the design of Voyager and learn why it lasted this long,
Let's see. Oh, look here: Voyager isn't attempting to crash at high speeds onto a planet with almost no atmosphere. Instead, we gave it a shove and it's just floating away passively now, far away from any body that could harm it. Maybe that could just be the reason???
Just because the features are not built into the language doesn't mean they are emulated.
Because the features are not built into the language, there is no consistency among different C/C++ systems in how they are implemented. Furthermore, because they are not built into the language, the compiler can perform little checking.
Languages should have as little built in as possible, not as much as possible!
Unfortunately, C/C++ have too little built in when it comes to object models, and too much when it comes to exposing implementation and hardware details.
If you are talking about Java or C#, on the other hand, then there is little they can do that C++ can't, except for bind the hands of the programmer.
Java and C# provide garbage collection, runtime safety, reflection, dynamic method invocation, and dynamic code generation. I'd say that's a lot more than C/C++ offer. Furthermore, while Java does bind the hands of the programmer, C# does not: it has well-defined but carefully controlled unsafe constructs, the same way Modula-3 did.
How is KIO hokey???
Because it is only used by KDE, it presents the user with a namespace that is inconsistent with the rest of the system and other desktops. It's the operating system's responsibility, not some desktop library, to give the user a single, consistent namespace for files and streams.
Huh? I just gave you a boat-load of reasons why that is not the case!!!
Both Gnome and KDE are gigantic C/C++ systems. They emulate all sorts of advanced object oriented features with cumbersome, unsafe, low-level workarounds. They make up for deficiencies in the underlying operating systems with hokey libraries like KIO and VFS. The "features" you named are indications of how limited and backwards Gnome and KDE both actually are.
Any desktop environment primarily written in C/C++ was outdated and technically obsolete the day it started development. (Of course, that doesn't mean it isn't useful--I run Gnome myself).
IBM doesn't have a default desktop
What IBM ships as part of SuSE or RedHat doesn't matter since it's not under their control. But as I understand it, IBM is going with Gnome for AIX in the long run. More importantly, they are also using Gnome/Gtk+ as the basis for things like SWT and other UI efforts.
I can't find any papers from the said authors on the physics archive, so these two obviously aren't well known or respectable among the scientific community.
Arxiv (mirrored at xxx.lanl.gov) is not peer reviewed, it's just a place where pretty much anybody affiliated with any university or research lab can archive their technical reports. If you want peer reviewed publications, look in journal and conference publications (on-line or off-line).
Furthermore, Arxiv is so disorganized and cumbersome to use that many scientists just don't bother with publishing on it at all.
Until some well-known scientist confirms this, I think I'll just believe the 'official' story about black holes.
It's not for scientists to confirm, it's for observations to confirm. Right now, observations seem consistent with black holes, gravastars, and many other possibilities, so you might as well keep an open mind.
Does it really matter? KDE and Gnome work about the same, they have about the same functionality, and neither of them has an architecture or a design that seems particularly future-proof.
Between the two, the Gnome/Gtk+ license is far less restrictive, so why bother spending time on KDE/Qt? The Qt license apparently makes KDE unacceptable as the default desktop choice for companies like IBM and Sun. And even many open source projects would have to pay thousands of dollars in licensing fees to Troll Tech initially because of the way open source development is carried out in industry.
If the mainstream desktop environments for Linux systems are going to be poor Microsoft Windows wannabes, I might as well pick the one that has fewer licensing restrictions, and that happens to be Gnome/Gtk+.
Doesn't the fact that a new Linux file selector dialog box becomes headline news really illustrate the state of the Linux GUI?
Yes, it means that the Linux GUI community has grown up to have become just as obsessed as the Macintosh GUI community, where issues like springy folders and file selection dialogs are debated for years and years.
No, that's not the "original version". Smalltalk, for example, had graphical file selection dialog boxes showing directories and file lists years before the Mac, and I don't even want to claim that Smalltalk was first.
In fact, text-based, screen-oriented interfaces had file selection dialogs that would present lists of choices from which you could easily pick.
Wow: installing firewall rules seems like a very complicated and cumbersome way of telling your mail reader to only display the text of messages. Most commonly used modern mail readers have that option. I suggest you upgrade from Outlook 2003 to something a little more current.
Honestly, I don't see what the big deal is. [...] You really need to drop the "OSS Or Nothing" banter.
Ah, yes, the usual strategy of Java zealots: portray everybody who objects to Sun's restrictive licenses as some kind of open source maniac. But this isn't about open source it's about open standards.
Open standards are of fundamental importance to modern, commercial software development. The industry started moving to open standards some time in the 1970's, long before open source started becoming important. Sun is trying to take us back to even before that time, to the time when companies like IBM dominated the industry with proprietary standards, and that is what I find highly objectionable, as a commercial software developer. You are probably too young to remember how awful that situation was.
I have no problems with Sun shipping closed source implementations. I have big problems with Sun trying to establish their proprietary standards as industry standards. And I have even bigger problems with Sun shipping proprietary standards and claiming that they are "open" because they permit you to work on them for free.
Using Java imposes a level of dependency on Sun, the company, that no software developer, whether open source or commercial, should rationally enter if he understands the implications. And the fact that Java is free-as-in-beer just makes it a loss leader, no different from Microsoft's anti-competitive 90% discounts on Windows in their effort to keep Linux out of the market.
Then follow the fricking license.
One enters a license agreement if it's mutually benficial. The Java license agreement isn't: it is very one-sided in Sun's favor. So, no, I won't "follow the fricking license" because I won't agree to the Java license agreement in the first place: it's a bad deal and I'm not taking it.
Instead, I choose to use open standards, both for my commercial software development and my free software development.
But in all honesty, in seven years of developing Java applications I have never *once* needed more flexibility with the platform or license than was provided "out of the box"
Well, how nice for you. Lots of people say the same thing about VisualBasic, too. That doesn't make VisualBasic an open platform either or a technically good platform. Personally, I think Java has stagnated technically over the last half dozen years and that it simply isn't good enough to develop high quality desktop applications (which is why Sun has to ship a desktop with their systems that is almost completely written in C).
I've posed several challenges to you in my earlier posts, and none of them have gone answered.
You mean like your "challenge" to give examples where Sun has sued people over licenses? I answered that challenge: they haven't. Unfortunately, you just don't understand the implications: the fact that they haven't makes Sun's behavior more deceptive, not less so. You pose meaningless challenges. But if you have any more of them, at least state them clearly and bother to read my responses.
Bzzt! JSP's and Servlets are indeed part of the J2EE Spec, and they are covered by the same EULA that you cited. [...] You should read it, as it appears to blow several of your arguments out of the water.
All that matters is that Sun has published a license in which they claim that they own the J2EE specifications and that you can't implement them freely. That is an explicit intellectual property claim by Sun, something they might take you to court for at any time and have a good chance of winning. No ASF press releases, no amount of Sun PR, and no amount of contorted reasoning about Tomcat and J2EE change that fact.
If I were to implement the spec for a commercial product, you can bet your arse that It would be corporate lawers, not myself, who would iron out any legalities before the first line of code was written.
Your lawyer would tell you that you need an explicit, written licensing agreement with Sun in order to implement their specifications.
How "quietly" is Sun putting in these restrictions if they are spelled out at the top of the EULA in relatively plain English?
Quietly enough, apparently, that you mistakenly thought that Java was an open standard.
Yikes!!!! What fortune 500's have you worked for???
Several. They all spent IT money quite wastefully.
Now comes the nasty part... I need to install a Hideous, Closed Source, Imperialistic Java Runtime Environment. And let's see.... the cost of that is again..... FREE!!!! I don't have to pay Sun to use Java to deploy my app; it doesn't need to go through a certification process; in all actuality, from this standpoint, Java is just as economical and "Free" as the oss part of my solution.
No, it is not as "free" as the OSS part of your solution, it is merely free-as-in-beer. I'm sorry if you don't understand the difference, but the difference is enormous, not merely philosophically, but in terms of the code quality and financial risks you accept as a commercial user when you choose Java compared to an open platform.
Slashdot Mirror
Yeah, but I've been writing software commercially for almost a decade, and I've never yet needed a "true multidimensional array" and I've certainly never needed to write an FFT.
Well, thanks for at least being honest about your limited experience.
Until then, I'll pick a language that suits my needs (and, quite importantly, those of my employer) and not get my knickers in a twist about non-my-real-world scenarios that the language may or may not handle.
Do you deal with images? With graphics? With user interfaces? With databases? With spam? With audio? With speech? With video? Do you think that the libraries that support that functionality appear by magic? Do you think they don't cost anything to develop? Don't you mind when those libraries crash your application or create security holes?
Since Java isn't up to it, those libraries are still written in C. That's why it took so long to get something like the Java imaging API and why it took even longer to get it ported to the main platforms Java runs on. That's also why so many audio and video codecs for Java media aren't available on Macintosh or Linux. "Pure Java" is a lie: in order to do most of the things people would like to do with Java, the JCP keeps having to define new native code modules.
You may just be hacking application programs for a living, but you still depend on all those libraries and all that C code, whether you know it or not. And the fact that Java can't handle it means that your work gets a lot harder, even if you don't even realize it.
The Java JIT should not have significant platform dependencies--these microbenchmarks should perform comparably on x86 Linux.
Where Java performance sucks on Linux is in the GUI; there, Sun's tuning for Windows really does give Windows a leg up.
Several components of C# are integrated right into the operating system so naturally it's going to run faster on a windows machine.
Oh, really? How is going to be "integrated right into the operating system" going to help with integer and floating point microbenchmarks? I'd really like to know.
And, also, in what sense is the CLR "integrated right into the operating system" that the JVM isn't? Both are a bunch of DLLs running on top of the NT kernel. What's the difference in your mind?
Oh wait! C# only runs on one operating system. Can you name any other development languages that only run on ONE OS, boys and girls? Neither can I.
C# runs on many operating systems, as does the CLR. And unlike Java, all of whose implementations are derived and licensed from Sun, C# actually has multiple independent implementations.
C# is not quite as free and open as, say, ANSI C or Python. You have to decide for yourself whether C# is open enough for you. But C# is clearly far more open and non-proprietary than Java; Java is covered by numerous Sun patents and doesn't even have a free and open specification.
This is (once again) proof that Java is not slow, in fact it's really fast.
No, it is not "proof" that "Java is not slow". Doing well on those microbenchmarks is necessary to establish that Java is not slow, but it is far from sufficient.
It's like saying that a Civic is a really fast car because you can make it go really fast by welding some booster rockets to it. That may be true in some sense of the word "fast", but that isn't a sense of "fast" that is going to be of any use to real drivers because, among other things, you can't steer the thing once you light the booster rockets.
Java is not a good high performance language at this point. And, yes, that is a problem with the Java language, not just its implementations.
Also, the memory use should be addressed by project Barcelona
What 1.5 or 1.6 promise to address to some degree is excessive size of the code segment, by allowing code to be shared among multiple Java programs. But memory used for byte code and JIT output is only one of the ways in which Java memory usage is excessive; the Java language itself imposes lots of memory overhead on even simple data structurers and there is no indication that the Java language design is going to be changed to address that.
The Pentium trig instructions are not IEEE compliant (they don't return the correct values for large magnitude arguments). gcc errs on the side of caution and generates slow, software-based wrappers that correct for the limitations of the Pentium instructions by default. Other compilers (e.g., Intel and probably Microsoft) just generate the in-line instructions with no correction. When you look at the claimed superiority of other compilers over gcc, it is usually such tradeoffs that make gcc appear slower.
You can enable inline trig functions in gcc as well, either with a command line flag, or an include file, or by using "asm" statements on a case-by-case basis. Check the documentation. With those enabled, gcc keeps up well with other compilers on trig functions.
So, yes, you can construct programs, even some useful compute intensive programs, that perform as well or better on Java than they do in C. But that still doesn't make Java suitable for high-performance computing or building efficient software.
Benchmarks like the one published by OSnews don't test for these limitations. Microbenchmarks like those are still useful: if a language doesn't do well on them, that tells you that it is unsuitable for certain work; for example, based on those microbenchmarks alone, Python is unlikely to be a good language for Fortran-style numerical computing. But those kinds of microbenchmarks are so limited that they give you no guarantees that an implementation is going to be suitable for any real-world programming even if the implementation performs well on all the microbenchmarks.
I suggest you go through the following exercise: write a complex number class, then write an FFT using that complex number class, "void fft(Complex array[])", and then benchmark the resulting code. C, C++, and C# all will perform reasonably well. In Java, on the other hand, you will have to perform memory allocations for every complex number you generate during the computation.
Yes, the makers of Lego hold interviews to see who can create entire buildings and sculptures by snapping together little rectangular pieces of plastic. I think the marines are also holding interviews for the enviable job of cleaning entire barracks with nothing more than a toothbrush. Both jobs seems pretty similar to me--if you don't get the first, apply for the second.
Because the firms wish to use the US Legal, tax dollars, and Military systems to protect their stuff.
Well, when they are moving jobs and operations overseas, clearly they are indicating that they don't care about the US providing any of that.
Who's gettign punished?
The people who keep the stock of a company whose executives pay themselves too much money.
For the life of me, can you imagine any CEO contributing as much to a company as 2290 rank and file workers? Unless they can literally print money, I have trouble imaging how an executive can make that kind of contribution compared to the employees they lead.
She probably isn't worth it. And the way the market punishes such waste is by having the company go out of business or get taken over. Just give it a few years.
I'm sure people will create color management for the Gimp. My point is: unlike what calibrationists claim, color calibration is not a requirement for professional imaging, it's just one particular hangup that a (sizeable) subpopulation of imaging professionals have. It's just that people who don't want or need calibration never complain about the fact that Photoshop has it or that the Gimp doesn't have. All you ever hear from is people who believe in calibration and keep whining that the Gimp doesn't have it.
Many so-called US firms actually do most of their business in other countries. Why shouldn't most of their jobs be in other countries as well?
In fact, from the point of the rest of the world, this looks like a long overdue change of direction. For decades, companies like IBM, Ford, Apple, MacDonalds, WalMart, etc., have displaced domestic manufacturers and service industries in those other nations and only created low-end jobs in those nations. Skilled jobs, administration, and management have largely remained in the US and the US has received a disproportionate share of the benefits from those overseas business activities. It's about time that high-skilled and high-paying jobs associated with US-based multinationals also move out of the US.
They have already done that many times and they will continue to do that. Usually, it happens when an ailing US company is taken over by a foreign company. Those foreign CEOs get paid much less than the US CEOs they replace.
Having CMYK support is all fine and dandy but it won't get you far in the printing world without support for colour profiles and colour calibration.
Some people swear by color calibration, other think its complete b.s. Not having color calibration certainly limits the acceptance of the Gimp.
But, since I'm in the category of people who think that color caliberation is b.s., maybe that's a good thing: let the calibrationists pay top dollar for useless features in Photoshop; maybe they'll go out of business, pick up flower arranging instead, and stop messing around with color. We can only hope.
This answers the question of what advances are needed. Basically, we need either laser-powered solar sails, or we need antimatter propulsion. Even then, the trip would still take a long time and be enormously expensive.
Pull out the design of Voyager and learn why it lasted this long,
Let's see. Oh, look here: Voyager isn't attempting to crash at high speeds onto a planet with almost no atmosphere. Instead, we gave it a shove and it's just floating away passively now, far away from any body that could harm it. Maybe that could just be the reason???
Just because the features are not built into the language doesn't mean they are emulated.
Because the features are not built into the language, there is no consistency among different C/C++ systems in how they are implemented. Furthermore, because they are not built into the language, the compiler can perform little checking.
Languages should have as little built in as possible, not as much as possible!
Unfortunately, C/C++ have too little built in when it comes to object models, and too much when it comes to exposing implementation and hardware details.
If you are talking about Java or C#, on the other hand, then there is little they can do that C++ can't, except for bind the hands of the programmer.
Java and C# provide garbage collection, runtime safety, reflection, dynamic method invocation, and dynamic code generation. I'd say that's a lot more than C/C++ offer. Furthermore, while Java does bind the hands of the programmer, C# does not: it has well-defined but carefully controlled unsafe constructs, the same way Modula-3 did.
How is KIO hokey???
Because it is only used by KDE, it presents the user with a namespace that is inconsistent with the rest of the system and other desktops. It's the operating system's responsibility, not some desktop library, to give the user a single, consistent namespace for files and streams.
Huh? I just gave you a boat-load of reasons why that is not the case!!!
Both Gnome and KDE are gigantic C/C++ systems. They emulate all sorts of advanced object oriented features with cumbersome, unsafe, low-level workarounds. They make up for deficiencies in the underlying operating systems with hokey libraries like KIO and VFS. The "features" you named are indications of how limited and backwards Gnome and KDE both actually are.
Any desktop environment primarily written in C/C++ was outdated and technically obsolete the day it started development. (Of course, that doesn't mean it isn't useful--I run Gnome myself).
IBM doesn't have a default desktop
What IBM ships as part of SuSE or RedHat doesn't matter since it's not under their control. But as I understand it, IBM is going with Gnome for AIX in the long run. More importantly, they are also using Gnome/Gtk+ as the basis for things like SWT and other UI efforts.
I can't find any papers from the said authors on the physics archive, so these two obviously aren't well known or respectable among the scientific community.
Arxiv (mirrored at xxx.lanl.gov) is not peer reviewed, it's just a place where pretty much anybody affiliated with any university or research lab can archive their technical reports. If you want peer reviewed publications, look in journal and conference publications (on-line or off-line).
Furthermore, Arxiv is so disorganized and cumbersome to use that many scientists just don't bother with publishing on it at all.
Until some well-known scientist confirms this, I think I'll just believe the 'official' story about black holes.
It's not for scientists to confirm, it's for observations to confirm. Right now, observations seem consistent with black holes, gravastars, and many other possibilities, so you might as well keep an open mind.
Does it really matter? KDE and Gnome work about the same, they have about the same functionality, and neither of them has an architecture or a design that seems particularly future-proof.
Between the two, the Gnome/Gtk+ license is far less restrictive, so why bother spending time on KDE/Qt? The Qt license apparently makes KDE unacceptable as the default desktop choice for companies like IBM and Sun. And even many open source projects would have to pay thousands of dollars in licensing fees to Troll Tech initially because of the way open source development is carried out in industry.
If the mainstream desktop environments for Linux systems are going to be poor Microsoft Windows wannabes, I might as well pick the one that has fewer licensing restrictions, and that happens to be Gnome/Gtk+.
Doesn't the fact that a new Linux file selector dialog box becomes headline news really illustrate the state of the Linux GUI?
Yes, it means that the Linux GUI community has grown up to have become just as obsessed as the Macintosh GUI community, where issues like springy folders and file selection dialogs are debated for years and years.
No, that's not the "original version". Smalltalk, for example, had graphical file selection dialog boxes showing directories and file lists years before the Mac, and I don't even want to claim that Smalltalk was first.
In fact, text-based, screen-oriented interfaces had file selection dialogs that would present lists of choices from which you could easily pick.
Wow: installing firewall rules seems like a very complicated and cumbersome way of telling your mail reader to only display the text of messages. Most commonly used modern mail readers have that option. I suggest you upgrade from Outlook 2003 to something a little more current.
Honestly, I don't see what the big deal is. [...] You really need to drop the "OSS Or Nothing" banter.
Ah, yes, the usual strategy of Java zealots: portray everybody who objects to Sun's restrictive licenses as some kind of open source maniac. But this isn't about open source it's about open standards.
Open standards are of fundamental importance to modern, commercial software development. The industry started moving to open standards some time in the 1970's, long before open source started becoming important. Sun is trying to take us back to even before that time, to the time when companies like IBM dominated the industry with proprietary standards, and that is what I find highly objectionable, as a commercial software developer. You are probably too young to remember how awful that situation was.
I have no problems with Sun shipping closed source implementations. I have big problems with Sun trying to establish their proprietary standards as industry standards. And I have even bigger problems with Sun shipping proprietary standards and claiming that they are "open" because they permit you to work on them for free.
Using Java imposes a level of dependency on Sun, the company, that no software developer, whether open source or commercial, should rationally enter if he understands the implications. And the fact that Java is free-as-in-beer just makes it a loss leader, no different from Microsoft's anti-competitive 90% discounts on Windows in their effort to keep Linux out of the market.
Then follow the fricking license.
One enters a license agreement if it's mutually benficial. The Java license agreement isn't: it is very one-sided in Sun's favor. So, no, I won't "follow the fricking license" because I won't agree to the Java license agreement in the first place: it's a bad deal and I'm not taking it.
Instead, I choose to use open standards, both for my commercial software development and my free software development.
But in all honesty, in seven years of developing Java applications I have never *once* needed more flexibility with the platform or license than was provided "out of the box"
Well, how nice for you. Lots of people say the same thing about VisualBasic, too. That doesn't make VisualBasic an open platform either or a technically good platform. Personally, I think Java has stagnated technically over the last half dozen years and that it simply isn't good enough to develop high quality desktop applications (which is why Sun has to ship a desktop with their systems that is almost completely written in C).
I've posed several challenges to you in my earlier posts, and none of them have gone answered.
You mean like your "challenge" to give examples where Sun has sued people over licenses? I answered that challenge: they haven't. Unfortunately, you just don't understand the implications: the fact that they haven't makes Sun's behavior more deceptive, not less so. You pose meaningless challenges. But if you have any more of them, at least state them clearly and bother to read my responses.
Bzzt! JSP's and Servlets are indeed part of the J2EE Spec, and they are covered by the same EULA that you cited. [...] You should read it, as it appears to blow several of your arguments out of the water.
All that matters is that Sun has published a license in which they claim that they own the J2EE specifications and that you can't implement them freely. That is an explicit intellectual property claim by Sun, something they might take you to court for at any time and have a good chance of winning. No ASF press releases, no amount of Sun PR, and no amount of contorted reasoning about Tomcat and J2EE change that fact.
If I were to implement the spec for a commercial product, you can bet your arse that It would be corporate lawers, not myself, who would iron out any legalities before the first line of code was written.
Your lawyer would tell you that you need an explicit, written licensing agreement with Sun in order to implement their specifications.
How "quietly" is Sun putting in these restrictions if they are spelled out at the top of the EULA in relatively plain English?
Quietly enough, apparently, that you mistakenly thought that Java was an open standard.
Yikes!!!! What fortune 500's have you worked for???
Several. They all spent IT money quite wastefully.
Now comes the nasty part... I need to install a Hideous, Closed Source, Imperialistic Java Runtime Environment. And let's see.... the cost of that is again..... FREE!!!! I don't have to pay Sun to use Java to deploy my app; it doesn't need to go through a certification process; in all actuality, from this standpoint, Java is just as economical and "Free" as the oss part of my solution.
No, it is not as "free" as the OSS part of your solution, it is merely free-as-in-beer. I'm sorry if you don't understand the difference, but the difference is enormous, not merely philosophically, but in terms of the code quality and financial risks you accept as a commercial user when you choose Java compared to an open platform.