In a nutshell, pre-compiling doesn't offer any performance advantages.
That's a claim which is unproven. There are applications where gcj provides a significant
speed-up, and there are others where Sun's JIT-VM
runs faster. But it's not necessarily a fair comparison: Sun has spent a lot of resources on a
smart and highly-tuned implementation, but there has
been comparitively little work on Java-specific
optimizations in GCJ. (Most of the effort has
focused on functionality, especially the libraries.)
It is also worth noting that pre-compiled applications start up faster (and people are
working on improving this further).
That will remove the code if release is definied to true, and have it switchable if release is false (obviously you can make it look a bit nicer)
In other words, you're conditionally compiling two different binaries depending on the compile-time value of release. Clearly you want a preprocessor for this, rather than editing the codebase by hand.
The VM is relatively small part of Java. It's the
class libraries that are the biggest problem
- and IBM's class libraries are basically Sun's
class libraries.
Five will get you ten they all run just fine on any Java runtime worth its salt.
That means "any Sun-derived runtime". Name me
any Java runtime "worth its salt" in your
opnion that is not derived
from Sun's code.
It is because those implementations suck.
That's the same as saying that Linux sucks
because it does't implement (all the features,
including 3rd-party device drivers)
of the Windows "standard".
My point is that the Java community basically doesn't give a shit.
But many in the GNU/Linux community does care
about the issues - and any distribution that
wants to survive needs to learn to care.
And that is why there are no "available-everywhere" Java applications.
Thanks to lots of work by GNU Classpath, GCJ,
Red Hat, Kaffe, and
others that may soon change.
I did not make judgement about the reasons they have for not including it, but there is nothing in the Sun's JRE license that prevents a linux distribution from including it. Proof of that is that many do include it.
No, that is just proof that of lots of
people (including distributions that ought to
know better) are incredibly sloppy about licenses.
Of course they can distribute JRE - but
may they? Are they
violating the license - or encouraging others to violate the license? The license puts rather strong
(if vague) restrictions on any GNU/Linux/*BSD
distribution who wants to
(legally) distribute the JRE, and a general-purpose distribution that does so is
probably violating the license. Not a good idea.
Are sysadmins really so busy or incompetent that they can't just download Java if they need it?
Sysadmins - what's a sysadmin? Oh, you mean Aunt Tillie's nephew Eric.
And who we blame: Java for having a test suite, or the distros for ruling out software whose license requires test suites?
I suggest you read Sun's LICENSE. There are a
number of problems with it that should give
pause to anyone considering including it in a
GNU/Linux or *BSD distribution (unless they've
negotiated some other license, as Apple has).
I've read a fair amount of Apache source code, and I've never seen it depend on "Sun-only features." Can you give some examples of Sun-only features used by a Jakarta projects?
Let me re-phrase that and turn it around a bit:
Which Apache Java packages, if any, have a policy
that they must run and execute properly (at least
core functionality) on a Free Java implementation?
Sun's Java JVM can be included in linux distributions without problems. Knoppix, SuSE and SoL include it. Don't know about others. The reason some distributions don't include Sun's Java implementation is because they don't want to include it.
No, it's because some distributions are less cavalier about Sun's license than others.
For example, the Supplemental License Term B iii
(of JDK 1.4.2) seem to prohibit distributing
both JDK and GCJ. Note also that redistribution
is "non-tranferable", so somebody who receives a
copy of Knoppix can't give it to somebody else.
In fact your only allowed to reditribute JDK
"for the sole purpose of running, your Programs".
Note also (3 RESTRICTIONS) "you may not modify, decompile, or reverse engineer [Sun's] Software."
I wish people who made these claims about Java
being "Free enough" would
actually read the Java license...
The source is already available, and all that is required to change it and redistribute it is to pass a standard suite of tests. Now, call me crazy, but I think that's not A Bad Thing.
It's not a bad thing, but there are a couple of problems:
The testsuite is big and monolithic. Suppose I
have an experimental JVM that doesn't support all
of Sun's required features yet. I can't use part
of Sun's implementation (such as say java.io),
even though I have no intention of changing that,
because my system as a whole can't
pass the testsuite.
What if I'm a researcher wanting to experiment
with a new but incompatible dialect of Java -
perhaps I have some ideas I'd like to propose
for "Java 3". I can't release this experimental
dialect, because I can't pass the testsuite -
even if I call it someelse else besides Java.
GNU Java kind of sucks, even after many years of work, [Stallman's] "free software" baby isn't winning in the Java world, and nobody really cares except GNU... so there's a bit of sour grapes.
Any GNU/Linux distribution cares if it is strict
about being Open Source, because it can't include
Sun's Java. This is includes Debian and Red Hat / Fedora. Likewise, these distributions can't include
(as part of the core distriction at least) any
software that depends on non-Free Java,
including most Apache Java software. (Apache is
heavily in bed with Sun, and is happy to develop
code that depends on Sun-only features - though
the GNU/Free Java community can run more and
more of these Apache packages.)
This hurts (or at least inconveniences)
everybody who uses these distributions.
If Free Java and Sun could share more code,
then there might be a lot GNU/Linux "system"
software (including pre-installed applications)
written in Java.
But Java is one platform; if you need to do something that different on each underlying OS or system, then you're doing something wrong!
Nonsense. JDK 1.4 is a very different platform from JDK 1.1 or 1.0. In my Java code I might want to use
weak references (say), which are available on JDK
1.2 but not 1.1. I might want to support JDK 1.1
using some inferior fallback backanism. In theory
I can do this using reflection, but that's
both slow and painful to write. So conditional
compilation is reasonable alternative - certainly
better than refusing to support JDK 1.1 - which
is the solution most Java projects select.
Sun would not be able to incorporate changes made under the GPL into their corporate version.
Of course they can, as long as they keep the copyright. They can also do what the FSF does:
Require a copyright assignment for any code
that they accept into the official source (i.e.
their) source tree. Of course somebody could make
a fork, but a fork is likely to see only niche use
if Sun does a decent job of maintaining Java.
Trying to pass all ill-feelings the world has on the current president is worse than naive. There are those who hate those who have or simply have more.
Well, duh. The US had a lot of support after 9/11.
"We are all Americans." But the ill-feelings have increased tremendously in the last year
or so. That is indisputable.
They will always want their cut, whethere they earned/deserve/can make use of it.
You're providing ammunition for those who say
"Americans think everything it's all about money."
I'm talking about Western Europe, Canada, Japan.
They don't hate America (they certainly don't
hate Americans!), and are more financially secure than most Americans, but people there are very
concerned about the direction America is taking:
Many people think American policy is dangerous,
naive, definitely arrogant, and maybe
immoral.
What does that have to do with the UN? Here's two [valid] ways off the top of my head I can say the UN is not a representative democracy:
True. But my point is that complaining that many of
the UN's member are dictatorships, oppressive or
non-functioning is beside the point: They represent
what the world is. I think it is better
that the UN includes all the world's countries,
rather just the ones whose governments we
(or our government) happens to like.
Only fools and crackpot leftists take the UN seriously.
Only fools and crackpot leftists take representative democracy seriously. Only educated men of property and good character should be allowed to vote or participate in the political process. That is of course how it used to be in the good old days.
It is a den of dictators, murders, theives and their apologists.
How did this nut-case slander get rated as "Insightful"? You're arguing that 90% of
the world's population are "apologists". Wake
up: Bush has managed to make most of the world
angry at the US's foreigh policy - and this is
not just dictators but the educated informed
newspaper-reading middle classes of Western
democracies. You know, it is possible these
"apologists" might be right; recent events in
Iraq certainly bear out their concerns.
In any case, even if you disagree with someone
please don't automatically impugn their character
and motives.
The so-called ICC makes a mockery out of due process of law. Secret witnesses, evidence, no right to trial by jury.
I think you're confused. The mockery of the due process of law is promulgated by Bush/Ashcroft.
Detainees face secret witnesses, evidence, no right to trial by jury. If you have something
concrete (not paranoid fantasies) where the ICC
was abusive,
please post a link. (Also, trial by jury
is not a requirement for due process, and may be
detrimental when jurors can be retaliated against.
Plus from where would you recruit jurors? Think
about it before spouting nonsense.)
That was the case last time I looked at GCJ about a year ago. I ended up being unable to use it because of lack of windowing toolkit support. Anyone know the status on all that?
Eclipse uses its own SWT toolkit, which works well under GCJ. SWT is a combination of native code and Java, and is said to both be fast and integrate
well with other window systems, as it uses native
widgets when available.
The implementation of AWT (including applets) is coming
along very quickly, but it isn't complete yet.
This means that if you make changes to an LGPL library you use via import in Java, you must make the changes to the LGPL library available to others.
Section i6 isn't about modification to an LGPL library - it about certain requirements that apply when you distribute an application that uses the library. These requirements may be inconvenient to somebody distributing a commercial program - but not "viral". Furthermore, using a shared library version of the LGPL library has distorically been considered to satisfy the linkage requirement of section 6; using a Java archive should do the same.
i realised gcj was a compiler, and you just made me think it was a runtime environment again (with rubbish collection, jit compiling, virtual machine and all that).
It's a compiler, with a runtime environment.
(It doesn't currently have jit compiling.)
are you saying the reason for my confusion is because it is BOTH [a run-time environment and a library like libstdc++]... a native compiler/dynamically linkable lib AND potentially a virtual machine for running byte-compiled (portable) binaries,
Yes. The insight you need is that these are not two different things, but the same thing. Most of the Java class library is like a bigger libstdc++. But note the presence of java.lang.ClassLoader. If your run-time library implements this (and libgcj does), then you have a VM. The java program is just a little wrapper application that parses a command line and uses reflection to call a main method.
with a lack of authors being the only holdup to the jit.
A jit is not part of the specification or concept of a JVM. It is a performance optimization. GCJ has the functionality of a JVM. GCJ can't run bytecodes as fast as it could if it had a JIT, so it would be nice to have a JIT. On the other hand, it's not that high a priority, since you can always just compile an application to native code when you install it.
i assume redhat are looking to improve the virtual machine end of things?
I don't know. I don't think that's as important as fleshing out the class libraries. (Full AWT support is getting close, except for Java2D, and even Swing is moving along.)
i hate [the jre], and if i had the choice, i'd machine code all my java apps to run without it!
You have the choice. It's called gcj.
if you guys get the GUI side of things working with gtk2, then it'll probably be just as slow;-) but at least the beautiful text rendering and widgets will justify it
There is no reason Java GUIs need to be slow. And using GCJ will certainly help, especially with start-up time. (Though GCJ's start-up time when using shared libraries could also be improved.)
I forgot to add: Yes, we should probably do a better job of explaining the wonders of GCJ on the web-site. We explain how it's different, but it probably isn't as obvious as it should be how it's the same as well (i.e. how it aims to be a full replacement for non-free Java).
but why then does the gcj webpage on gcc.gnu.org not mention the (project) GCJ at all, but just the compiler gcj?
I assume you mean this page. I quote the second paragraph:
Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications.
i got modded "flamebait"
I didn't view it as flamebait, just an all-too-common lack of information about Gcj.
as if it were g++ modified for java syntax and linked to a java standard library, similar to the c/c++ philosophy.
Yes, that is the Gcj approach, but Gcj attempts to provide the best of both worlds including support for traditional VM-based usage models. (In fact, we would be happy to incorporate a Just-in-Time compiler into the runtime, but nobody has done so yet.)
gcj only makes native binarys from java source, INFO or byte compiled java code to run on a virtual machine. it is NOT a virtual machine.
Wrong. The programgcj is a compiler, like javac, but the GCJ project and run-time includes a virtual machine. The command gij is a plug-in replacement for the java command (except for unimplemented features and bugs, of course).
And by introducing a new non-sun version of java leads to the same problems that M$ had with J++ where 100% pure sun java code is incompatible with other flavors.
That's the irony: By refusing to open-source Java, Sun is forcing the Free Software community to develop their own non-Sun version of Java. Classpath would not exist if Sun's class libraries were Free Software. It would be possible to fork the libraries, but as long as Sun was actively maintaining the libraries a fork would be very unlikely, judging from history. Sun's fear of Microsoft creating incompatible extensions has some historical basis, but the fear is overblown, and there are better solutions, such as tradmark law.
Remember that GCJ was developed at Cygnus (starting in 1996), and that Red Hat bought Cygnus. While Red Hat has not put a lot of resources in GCJ, they still employ some of the early GCJ engineers, who are still active in GCJ in at least on a part-time volunteer basis. In Red Hat 8.0, what you get when you run "java" is the interpreter component of GCJ. And it looks like they are getting serious about Java, and GCJ.
My guess (as original "inventor" of GCJ, but no longer associated with Red Hat except as share holder): To the extent that Sun is willing to open-source parts of JDK, they'll use that; if Sun is unwilling, they will use GCJ.
Kawa: Scheme, XQuery, Emacs Lisp etc to bytecodes
on
The Future of Java?
·
· Score: 2, Informative
I have been working on
Kawa
since 1996. Originally it just compiled Scheme
to bytecodes, but it is now a multi-language
framework supporting XQuery,
Emacs Lisp, some
Common Lisp and other languages. It is easy
to compile any of those into modules,
applications or servlets. These
days I'm mostly working on XQuery,
a very interesting and useful new language
from the
W3C.
And "cygnus" is a recursive acronym from "cygnus your GNU software".
No, it's not. The Cygnus founders have said the
"gnu" in Cygnus, while neat, was not something
they were looking for. They was looking for an
available un-trademarked name! And
"Cygnus" was never a acronym, recursive or not.
Linux is a generic term for an operating system using a Linux kernel and it doesn't need some brain exception prefix that ignores the contribution of hundreds of other contributors in the process.
Well, that's the point, isn't it? "Linux" has become a generic term, even though very
little of of the "personality" (or user interface)
of (say) a Red Hat "Linux" system has annything to
do with the kernel. Red Hat could switch to using
the Hurd or some other kernel, and most people
wouldn't notice any difference. So using the term
"Linux" is misleading.
It's like traditionalist "grammarians" insisting
that "he" means "he or she". Well, it doesn't.
More importantly, the choice of words has
consequences. When people read "he" they
visualize a man. When girls hear "he" they don't
visualize tehmselves. When
people read "Linux" they visualize Linus creating
a whole operating system in his attic in
Helsinki.
The real question I have is why do people get so
upset at the FSF's request to use the term
GNU/Linux? You may disagree with it, or think
it silly, or misplaced, but clearly something
more than that is going to cause these strong reactions. (Nobody is requiring anybody
to call it GNU/Linux!) That to me suggests that
RMS is right, and that perhaps calling it
GNU/Linux does encourage more thinking about
issues - that sometimes
people don't want to think about.
Slashdot Mirror
That's a claim which is unproven. There are applications where gcj provides a significant speed-up, and there are others where Sun's JIT-VM runs faster. But it's not necessarily a fair comparison: Sun has spent a lot of resources on a smart and highly-tuned implementation, but there has been comparitively little work on Java-specific optimizations in GCJ. (Most of the effort has focused on functionality, especially the libraries.)
It is also worth noting that pre-compiled applications start up faster (and people are working on improving this further).
In other words, you're conditionally compiling two different binaries depending on the compile-time value of release. Clearly you want a preprocessor for this, rather than editing the codebase by hand.
The VM is relatively small part of Java. It's the class libraries that are the biggest problem - and IBM's class libraries are basically Sun's class libraries.
Five will get you ten they all run just fine on any Java runtime worth its salt.
That means "any Sun-derived runtime". Name me any Java runtime "worth its salt" in your opnion that is not derived from Sun's code.
It is because those implementations suck.
That's the same as saying that Linux sucks because it does't implement (all the features, including 3rd-party device drivers) of the Windows "standard".
My point is that the Java community basically doesn't give a shit.
But many in the GNU/Linux community does care about the issues - and any distribution that wants to survive needs to learn to care. And that is why there are no "available-everywhere" Java applications. Thanks to lots of work by GNU Classpath, GCJ, Red Hat, Kaffe, and others that may soon change.
No, that is just proof that of lots of people (including distributions that ought to know better) are incredibly sloppy about licenses.
Of course they can distribute JRE - but may they? Are they violating the license - or encouraging others to violate the license? The license puts rather strong (if vague) restrictions on any GNU/Linux/*BSD distribution who wants to (legally) distribute the JRE, and a general-purpose distribution that does so is probably violating the license. Not a good idea.
Sysadmins - what's a sysadmin? Oh, you mean Aunt Tillie's nephew Eric.
And who we blame: Java for having a test suite, or the distros for ruling out software whose license requires test suites?
I suggest you read Sun's LICENSE. There are a number of problems with it that should give pause to anyone considering including it in a GNU/Linux or *BSD distribution (unless they've negotiated some other license, as Apple has).
I've read a fair amount of Apache source code, and I've never seen it depend on "Sun-only features." Can you give some examples of Sun-only features used by a Jakarta projects?
Let me re-phrase that and turn it around a bit: Which Apache Java packages, if any, have a policy that they must run and execute properly (at least core functionality) on a Free Java implementation?
No, it's because some distributions are less cavalier about Sun's license than others. For example, the Supplemental License Term B iii (of JDK 1.4.2) seem to prohibit distributing both JDK and GCJ. Note also that redistribution is "non-tranferable", so somebody who receives a copy of Knoppix can't give it to somebody else. In fact your only allowed to reditribute JDK "for the sole purpose of running, your Programs".
Note also (3 RESTRICTIONS) "you may not modify, decompile, or reverse engineer [Sun's] Software."
I wish people who made these claims about Java being "Free enough" would actually read the Java license ...
It's not a bad thing, but there are a couple of problems:
Any GNU/Linux distribution cares if it is strict about being Open Source, because it can't include Sun's Java. This is includes Debian and Red Hat / Fedora. Likewise, these distributions can't include (as part of the core distriction at least) any software that depends on non-Free Java, including most Apache Java software. (Apache is heavily in bed with Sun, and is happy to develop code that depends on Sun-only features - though the GNU/Free Java community can run more and more of these Apache packages.)
This hurts (or at least inconveniences) everybody who uses these distributions. If Free Java and Sun could share more code, then there might be a lot GNU/Linux "system" software (including pre-installed applications) written in Java.
Nonsense. JDK 1.4 is a very different platform from JDK 1.1 or 1.0. In my Java code I might want to use weak references (say), which are available on JDK 1.2 but not 1.1. I might want to support JDK 1.1 using some inferior fallback backanism. In theory I can do this using reflection, but that's both slow and painful to write. So conditional compilation is reasonable alternative - certainly better than refusing to support JDK 1.1 - which is the solution most Java projects select.
Of course they can, as long as they keep the copyright. They can also do what the FSF does: Require a copyright assignment for any code that they accept into the official source (i.e. their) source tree. Of course somebody could make a fork, but a fork is likely to see only niche use if Sun does a decent job of maintaining Java.
Well, duh. The US had a lot of support after 9/11. "We are all Americans." But the ill-feelings have increased tremendously in the last year or so. That is indisputable.
They will always want their cut, whethere they earned/deserve/can make use of it.
You're providing ammunition for those who say "Americans think everything it's all about money." I'm talking about Western Europe, Canada, Japan. They don't hate America (they certainly don't hate Americans!), and are more financially secure than most Americans, but people there are very concerned about the direction America is taking: Many people think American policy is dangerous, naive, definitely arrogant, and maybe immoral.
True. But my point is that complaining that many of the UN's member are dictatorships, oppressive or non-functioning is beside the point: They represent what the world is. I think it is better that the UN includes all the world's countries, rather just the ones whose governments we (or our government) happens to like.
Only fools and crackpot leftists take representative democracy seriously. Only educated men of property and good character should be allowed to vote or participate in the political process. That is of course how it used to be in the good old days.
It is a den of dictators, murders, theives and their apologists.
How did this nut-case slander get rated as "Insightful"? You're arguing that 90% of the world's population are "apologists". Wake up: Bush has managed to make most of the world angry at the US's foreigh policy - and this is not just dictators but the educated informed newspaper-reading middle classes of Western democracies. You know, it is possible these "apologists" might be right; recent events in Iraq certainly bear out their concerns. In any case, even if you disagree with someone please don't automatically impugn their character and motives.
The so-called ICC makes a mockery out of due process of law. Secret witnesses, evidence, no right to trial by jury.
I think you're confused. The mockery of the due process of law is promulgated by Bush/Ashcroft. Detainees face secret witnesses, evidence, no right to trial by jury. If you have something concrete (not paranoid fantasies) where the ICC was abusive, please post a link. (Also, trial by jury is not a requirement for due process, and may be detrimental when jurors can be retaliated against. Plus from where would you recruit jurors? Think about it before spouting nonsense.)
Eclipse uses its own SWT toolkit, which works well under GCJ. SWT is a combination of native code and Java, and is said to both be fast and integrate well with other window systems, as it uses native widgets when available.
The implementation of AWT (including applets) is coming along very quickly, but it isn't complete yet.
This means that if you make changes to an LGPL library you use via import in Java, you must make the changes to the LGPL library available to others.
Section i6 isn't about modification to an LGPL library - it about certain requirements that apply when you distribute an application that uses the library. These requirements may be inconvenient to somebody distributing a commercial program - but not "viral". Furthermore, using a shared library version of the LGPL library has distorically been considered to satisfy the linkage requirement of section 6; using a Java archive should do the same.
It's a compiler, with a runtime environment. (It doesn't currently have jit compiling.)
are you saying the reason for my confusion is because it is BOTH [a run-time environment and a library like libstdc++]... a native compiler/dynamically linkable lib AND potentially a virtual machine for running byte-compiled (portable) binaries,
Yes. The insight you need is that these are not two different things, but the same thing. Most of the Java class library is like a bigger libstdc++. But note the presence of java.lang.ClassLoader. If your run-time library implements this (and libgcj does), then you have a VM. The java program is just a little wrapper application that parses a command line and uses reflection to call a main method.
with a lack of authors being the only holdup to the jit.
A jit is not part of the specification or concept of a JVM. It is a performance optimization. GCJ has the functionality of a JVM. GCJ can't run bytecodes as fast as it could if it had a JIT, so it would be nice to have a JIT. On the other hand, it's not that high a priority, since you can always just compile an application to native code when you install it.
i assume redhat are looking to improve the virtual machine end of things?
I don't know. I don't think that's as important as fleshing out the class libraries. (Full AWT support is getting close, except for Java2D, and even Swing is moving along.)
i hate [the jre], and if i had the choice, i'd machine code all my java apps to run without it!
You have the choice. It's called gcj.
if you guys get the GUI side of things working with gtk2, then it'll probably be just as slow ;-) but at least the beautiful text rendering and widgets will justify it
There is no reason Java GUIs need to be slow. And using GCJ will certainly help, especially with start-up time. (Though GCJ's start-up time when using shared libraries could also be improved.)
I forgot to add: Yes, we should probably do a better job of explaining the wonders of GCJ on the web-site. We explain how it's different, but it probably isn't as obvious as it should be how it's the same as well (i.e. how it aims to be a full replacement for non-free Java).
I assume you mean this page. I quote the second paragraph:
i got modded "flamebait"
I didn't view it as flamebait, just an all-too-common lack of information about Gcj.
as if it were g++ modified for java syntax and linked to a java standard library, similar to the c/c++ philosophy.
Yes, that is the Gcj approach, but Gcj attempts to provide the best of both worlds including support for traditional VM-based usage models. (In fact, we would be happy to incorporate a Just-in-Time compiler into the runtime, but nobody has done so yet.)
Wrong. The program gcj is a compiler, like javac, but the GCJ project and run-time includes a virtual machine. The command gij is a plug-in replacement for the java command (except for unimplemented features and bugs, of course).
That's the irony: By refusing to open-source Java, Sun is forcing the Free Software community to develop their own non-Sun version of Java. Classpath would not exist if Sun's class libraries were Free Software. It would be possible to fork the libraries, but as long as Sun was actively maintaining the libraries a fork would be very unlikely, judging from history. Sun's fear of Microsoft creating incompatible extensions has some historical basis, but the fear is overblown, and there are better solutions, such as tradmark law.
Remember that GCJ was developed at Cygnus (starting in 1996), and that Red Hat bought Cygnus. While Red Hat has not put a lot of resources in GCJ, they still employ some of the early GCJ engineers, who are still active in GCJ in at least on a part-time volunteer basis. In Red Hat 8.0, what you get when you run "java" is the interpreter component of GCJ. And it looks like they are getting serious about Java, and GCJ.
My guess (as original "inventor" of GCJ, but no longer associated with Red Hat except as share holder): To the extent that Sun is willing to open-source parts of JDK, they'll use that; if Sun is unwilling, they will use GCJ.
I have been working on Kawa since 1996. Originally it just compiled Scheme to bytecodes, but it is now a multi-language framework supporting XQuery, Emacs Lisp, some Common Lisp and other languages. It is easy to compile any of those into modules, applications or servlets. These days I'm mostly working on XQuery, a very interesting and useful new language from the W3C.
No, it's not. The Cygnus founders have said the "gnu" in Cygnus, while neat, was not something they were looking for. They was looking for an available un-trademarked name! And "Cygnus" was never a acronym, recursive or not.
Ghostscript isn't GNU.
Wrong - Ghostscript is GNU.
Linux is a generic term for an operating system using a Linux kernel and it doesn't need some brain exception prefix that ignores the contribution of hundreds of other contributors in the process.
Well, that's the point, isn't it? "Linux" has become a generic term, even though very little of of the "personality" (or user interface) of (say) a Red Hat "Linux" system has annything to do with the kernel. Red Hat could switch to using the Hurd or some other kernel, and most people wouldn't notice any difference. So using the term "Linux" is misleading.
It's like traditionalist "grammarians" insisting that "he" means "he or she". Well, it doesn't. More importantly, the choice of words has consequences. When people read "he" they visualize a man. When girls hear "he" they don't visualize tehmselves. When people read "Linux" they visualize Linus creating a whole operating system in his attic in Helsinki.
The real question I have is why do people get so upset at the FSF's request to use the term GNU/Linux? You may disagree with it, or think it silly, or misplaced, but clearly something more than that is going to cause these strong reactions. (Nobody is requiring anybody to call it GNU/Linux!) That to me suggests that RMS is right, and that perhaps calling it GNU/Linux does encourage more thinking about issues - that sometimes people don't want to think about.
(Oops - meant to hit preview.) This is the correct URL for Qexo (Kawa-XQuery).