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

Re: Java problem

On Thursday 03 January 2008, Les Mikesell wrote:
> 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.  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 

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 

> > 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, 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).
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772

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