Re: Java problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lamar Owen wrote:

Have you run any tests against icedtea? Which specific ones failed? Were bugs filed in bugzilla about them?
No, I don't see the point of replacing something that works with
something not already proven to be better.

What is 'better'? Sorry, I know that sounds like splitting hairs, but there is no way of proving something is 'better' (in the most amorphous sense of that already amorphous word) without releasing it.

If you can't measure it, you can't improve it. And if you haven't measured it, why, if you release it, should someone install it?

That's why you have alternatives, and that's why the system is an open one. That's why it is a built-in possibility to replace the provided java infrastructure with the Sun one.

I don't understand how a bizarre and mostly undocumented series of symlinks pointing to symlinks 'builds in' the possibility to replace things. Did 'rm' stop working?

So why don't you run the tests and see how good or how bad it is, rather than wasting time griping about something that isn't going to change unless and until Sun releases under a redistributable (by Fedora) license?

So you do understand the damage that shipping incompatible versions
causes...

Of course I do. But I also understand the reasons that IcedTea is in F8 instead of a Sun java. I also understand that it is not hard to get a Sun java into F8 (once a few things are worked around, and the systems provided in F8 are used).

Even Sun could have done a better job with versioning the code and
providing backwards compatibility.

And that's the point: java compatibility issues are not isolated to IcedTea or gcj.

But they are compounded by additional versions with no standards verification.

Ever try a real Korn shell on different platforms?
I used it on AT&T sysvr4, but only with Bourne-compatible syntax since I
didn't expect it to be available everywhere.

I mention the real Korn shell since it is even available for F8; also on Solaris, HP-UX, and others. Particularly since Bash is not a Bourne shell (strictly speaking), I use as an example a shell that can be used to isolate compatibility differences to things outside the shell itself.

You'd hate that system;
depending upon the setting of an environment variable, you had different
shells, different sets of programs, and different behaviors (SysV, BSD,
or Aegis).

Did any of the settings fail with Bourne-compatible syntax?

Yes, since the default behavior (of the version I had) was to make the c-shell /bin/sh if in BSD mode, and the Bourne shell /bin/sh if in SysV mode; a shell script could change the environment variable within itself, then morph from a Bourne script to a csh script, then change the envvar back and resume processing as a Bourne script.

Yes, you were right - I hated anything that made csh a default shell.

Yes, that is very broken, but it was the case on the DN3500 with DomainOS 10.2 (with AutoCAD on it; that was why the machine existed) I worked on. The $PATH had the envvar embedded in various paths; the default /bin (and /usr/bin) was a variably symlinked (yes, an embedded envvar inside the symlink!) directory, with three possible targets: one the SysVR3-compatible one, one the 4.3BSD-compatible one, and one the Aegis (the previous Apollo environment) one. Oh, and Apollo DomainOS had a great gui, but it wasn't X11 (which had to be added separately): instead of xterms, you had what were known as 'pads' which are much like xterms of serious steroids. It was a big enough target that AutoDesk built for it (in the late 1980's).

People who complain that Linux distribution differences are like the old unix war-era differences don't know what they're talking about; Ubuntu, OpenSUSE, Fedora, etc are all much more alike than they are different; the various competing Unixen of the late 80's and early 90's were more different than they were alike. Even in the case of SCO Unix versus SCO Xenix; same company, quite different Unix variants (Xenix, of course, being the Microsoft-licensed Unix derivative sold to the old SCO).

Still, if you can't run the same binaries, scripts, and java-bytecode across them, it doesn't matter that they share a tux logo somewhere.

--
   Les Mikesell
    lesmikesell@xxxxxxxxx


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux