On Thu, 2008-01-03 at 07:27 -0700, Karl Larsen wrote: > Peter Boy wrote: > > Am Sonntag, den 30.12.2007, 12:49 -0600 schrieb Les Mikesell: > > > >> It would be better if you tried to understand the consequences of this > >> choice instead of blindly defending it. > >> > > As with most decisions in real life: most benefits in one dimension have > > drawbacks in others. If I want the freedom of free software, I may have > > to struggle with issues in using non-free software. It is simply a > > matter of choice (and conscious decision). > > > > > >>> Fedora did not choose "not to be compatible with..." but Fedora choosed > >>> not to include an non-free program (i.e. Sun's Java) > >>> > >> They did both. Including or not including isn't the issue. Making it > >> difficult for the user to install his own freely available copy is one > >> problem. > >> > > > > Fedora does not make it specifically difficult. You may install the Sun > > provided Linux rpm, are free to search the Sun bugzilla database why it > > doesn't work out of the box (doesn't work in any Linux distribution, the > > bug report is some years old and Sun choosed not to fix it), install one > > of the suggested workarounds (e.g. edit a shell script > > in /etc/profile.d) and you are ready to go. As with any distributions > > Fedora does only care about software, which is part of its distribution. > > Third party vendors have to care ybout their software. > > > > And don't confuse the Fedora model with RHEL. In RHEL Red Hat takes care > > about Sun java integration and customers have to pay for it. Or the > > former SuSE distribution where SuSE made a different regarding the > > licence issue. > > > > > >> A whole separate 'jpackage' project has to exist just to fix > >> this problem in the distribution. The problem wouldn't exist if the > >> distribution included a java-*-sun-compat package of perfectly legal > >> symlinks. > >> > > > > You may think of the jpackage distribution as just another workaround > > for the fact that Sun didn't care about Linux compatibility of their > > Linus rpm's. And it is a general purpose workaround, not a Fedora > > specific one. > > > > > > > >> The bigger problem is distributing something that is not java compatable > >> but executing it with the java name. Microsoft tried to promote an > >> incompatible program that similarly fit their agenda with the java name > >> and Sun successfully sued them over it. The fedora-shipped not-java > >> program that executes with the java name does just as much damage and > >> shouldn't be named java until it passes the compatibility tests. I'm > >> surprised fedora's legal dept. allowed this abuse of a trademarked name. > >> > > > > The software is not shipped as java, but as gcj (and with some starter > > scripts with the filenama java for compatibility). And in contrast to MS > > the gcj project aimed to full compatibility and the lack thereof was an > > intermediate state during development. All this is quite different. > > > > > > > >>> So you can develope (or simply run) against the reference version and > >>> you can test (and support the devel of) the truly free alternative in > >>> parallel. That's the Fedora way. > >>> > >> It's not an alternative java until it passes the compatibility test. > >> > > > > You are free, not to use (and just to ignore) it! Remember, you just > > have to use one of the above mentioned alternative ways. > > > > > > Peter > > > > > You guys are both wrong. Fedora does ship F7 and F8 with a small > java version 1.5 which is too old for newer java programs, and that > broken icedtea that does nothing good. But light at the end of the > tunnel. Fedora can make the necessary changes to their design to allow > the method given on the Sun Site to work. I have been doing the work. > Look at my new messages on java. ---- nice of you to weigh in on something you know absolutely nothing about. Craig
