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
