Java problem
Lamar Owen
lowen at pari.edu
Thu Jan 3 18:42:32 UTC 2008
On Thursday 03 January 2008, Les Mikesell wrote:
> Lamar Owen wrote:
> > 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?
To help develop and test it perhaps? Fedora is a community, not a product.
> 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.
In a few ways I think it might be better that common binaries aren't
guaranteed to run. It does give an incentive to release source. However, on
the other hand, the source interface shouldn't be changed (even the kernel
module source API!) within a release. At release boundaries, sure, why not.
But not within a release.
Yes, a user typically doesn't care about that. But a user SHOULD care about
it, and learn that truly Free software is a worthwhile goal, regardless of
the inconvenience. If you want convenience, buy SLED or RHWS.
While I am one who actually understands your issue, and while I agree with
much of it, at the same time, when I chose to run Fedora 8 on this laptop I
knew (or should have known) what I was getting into, and I also knew that
things would be volatile. This is not an Enterprise distribution, after all.
Do I despise it when I have to hand-patch the VMware source shim to get it to
compile, on a regular basis? Sure I do; but it's as much VMware's fault as
it is Fedora's. And, for that matter, it's my own fault for choosing a
proprietary virtualization solution on top of an unsupported (by VMware)
distribution; and I accept that responsibility.
Do I hate it when a new kernel version comes along that breaks the drivers for
my video card? Sure: but I chose to buy that card, I chose to run Fedora,
and I chose to run the BLOB drivers; so it's my fault as much as it is the
others' fault. Will I submit bug reports? Perhaps; perhaps I'll just wait,
and perhaps I won't blindly update my kernel (very very few kernel bugs
result in remote system compromise, and I run enough layers of security, and
am willing enough to reinstall my system from scratch if need be, to where
it's not an issue). Better, though, is that the manufacturer of my FireGL
V3100 is releasing the source so that it can be integrated upstream, helping
everyone.
But to bring it back to Java: Fedora is providing the most compatible Java
that is available under a Fedora-compatible license. It's not 100%
compatible; but, then again, the Sun 1.6 isn't 100% compatible with 1.5,
either. If you want the other Java, no one is going to stop you from
installing it yourself. If and when Sun's Java is available under a
Fedora-compatible license, then it will likely be quickly incorporated
(shades of the demise of Red Baron once Netscape was open enough!). But even
the Sun 1.7 probably won't run the applet/servlet combo that I care most
about, as the 1.6 certainly doesn't.
This is much like the IPv4 to IPv6 'migration' situation that's been discussed
all over NANOG (and other networking groups) for years; the two different
solutions of NAT and CIDR pretty much took the steam out of the motivation to
upgrade to IPv6. And NAT and CIDR, while they work well together, were
presented as two different and competing solutions; many network ops (and
especially protocol people, who seem to go out of their way to make it hard
to NAT their protocols (H.323 and SIP, anyone?)) even today loathe NAT like
bubonic plague. Was NAT a wrong solution? Is there a right and a wrong
solution? NAT (and especially dynamic 'overloading' NAPT, in cisco terms) is
certainly the less free solution (it breaks the true peer-to-peer nature of
IP, and creates a class of content consumers), even though it gives users the
most IP numbering flexibility.
The 'purist' solution would have been IPv6 instead of NAT; use this as a
comparison to the 'purely Free Fedora stance' versus the 'I just want it to
work' stance: many network ops will say (probably correctly!) that NAT set
back the Internet ten years or more on getting IPv6 deployed. Of course, the
overreaching expansion and bloat that is IPv6 didn't help any! Necessity is
the mother of invention; having no necessity produces feeping creaturitis.
Our 'popular network protocol' wasn't designed; it was developed in an
iterative and not well managed process (RFC's? Managed? ROTFL!) ; yet it
works.
--
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
More information about the users
mailing list