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 one. 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. > > 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 (828)862-5554 www.pari.edu
