[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:
> > To help develop and test it perhaps? Fedora is a community, not a
> > product.

> I thought rawhide was the place for testing.

Rawhide is the place for development, not testing.  That's why it's 
called 'development' now.  

> > 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.

> No it isn't.  That would be the same for any non-included code.  You
> can't seriously think that every possible, useful piece of code should
> be included in the distribution and all rebuilt whenever any of it is,
> can you?

The Gentoo people believe that, Les.  

No, it would be VMware's fault for not being fully integrated into the 
upstream kernel, where modules belong, not as a separate package.  That is, 
after all, one of the Fedora Packaging Guidelines, that there be no package 
providing a kernel module (from an Official Fedora repository, of course; 
third party repos still do this).  Fact is, having all kernel modules in the 
upstream kernel where rebuilds are automatic is far better for the user; they 
don't have to rebuild anything, then.  If VMware's kernel module(s) were to 
be in the upstream kernel, the problem goes away.  VMware's own license 
conflicting with the upstream license prevents this; this is both the Linux 
kernel developers' fault and VMware's fault, as either could change licenses 
(well, VMware can change its license quicker than the kernel can....).  And 
if you don't like the kernel policy and license, well, I hear the OpenBSD 
kernel devs are very receptive to gadflies.

> > 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.

> But you've got that source that you recompile every time the kernel
> breaks your binary.

Yep, and if I had just chosen a VT supporting chip and used Xen instead, I 
wouldn't have that problem.  At the time I chose VMware (and it was a 
choice!) Xen didn't exist.  Nor did the VT stuff, for that matter.  But the 
fact remains that I as the user of this computer have chosen the software 
grouping I run and am responsible to making sure it works for me.  Caveat 
Emptor.  Now, if I had purchased RHEL and VMware to run on it, and the RHEL 
people had introduced such a kernel issue, I would have grounds to be unhappy 
and get in the face of some poor Red Hat tech support guy.  But; for a free 
distribution?  Built primarily by volunteers?  Get real.  Or get another 
distribution that does it your way.  Hmm, make your own, even.

> > Better, though, is
> > that the manufacturer of my FireGL V3100 is releasing the source so that
> > it can be integrated upstream, helping everyone.

> Maybe - do you expect the people who don't care about the trouble they
> are causing you now to do any better once they are in complete control?

Uh, Les, you're sounding paranoid.  Who are 'they' and over what do 'they' 
have complete control?  The Linux kernel developer community already has 
complete control of the system, and I am trusting them and the Fedora 
packagers to not put in a backdoor; the fact that I choose to run Fedora at 
all proves that I have a certain amount of trust for them, no?

If by 'they' you mean the 'Linux kernel developers' I don't blame them for 
VMware's binary.  But if I were worried about that I would be running a 
FreeBSD, OpenBSD, or OpenSolaris system and not a Linux kernel based Fedora 
system.  Obviously I'm not worried.

And, many years ago, I had a dialog with Alan Cox where he was very helpful in 
assisting me getting a weird soundcard working properly (he was the 
maintainer for the OSSFree stack in the 2.0 Linux kernel at the time; I said 
it was a long time ago!); he was then and still is a gentlemen, as most of 
the kernel developers (and Fedora packagers!) are if treated with the respect 
that they have earned, and not with a 'I want this so you must give it to me 
this way bwahaha!' attitude.

> > But to bring it back to Java: Fedora is providing the most compatible
> > Java that is available under a Fedora-compatible license.

> Is this horseshoes?  Do you get extra points if your code almost works?

Not IcedTea's fault; the incompatibility with my code exists with any JDK 
other than the 1.5 Sun Java.  That includes the 1.6 Java from Sun; not a 
Fedora problem, but a Sun problem.  My code needs to be less fragile and 
version specific, too, but that's a different topic. 

In the ideal case, I would run a test case on my code, and then get back to 
the IcedTea devs with a thorough bug report.  It hasn't been important enough 
yet to go to that trouble, nor have I been able to justify it in a business 
sense.  But, since I can have the Sun Java and IcedTea installed at the same 
time, and switch between them easily with alternatives (and I don't find 
alternatives to be too bizarre, given what it is really doing), I can both 
have a production Sun Java to run, as well as being able to test the IcedTea 
updates as they come out; and when it can run my code, I'll switch to it; or 
when the full OpenJDK can be on Fedora, whichever comes first.

After all, from the IcedTea FAQ: " What are the future plans for IcedTea?

IcedTea is a basis on which to experiment, trying to build a completely FOSS 
(free & open source software) version of the OpenJDK. Ideally, we would like 
to work upsteam directly on the OpenJDK, but there are some legal and 
technical issues that must first be resolved.

IcedTea is not a fork, and is not meant to be a permanent project - just a 
stopgap measure to create a fully FOSS OpenJDK. "

You do realize that OpenJDK IS the Sun Java of the future, right, Les?  It 
needs bug reports, regressions listed, etc, so that it can be the best it can 
be, backwards compatibility and all.

If you don't want to run experimental software, then get Sun's current Java.  
I for one want to see bleeding edge (which by definition MEANS experimental) 
software in Fedora; Fedora itself is bleeding edge.  That means you're going 
to get cut sooner or later trying to use it.  Don't like that?  Buy RHEL and 
stick with something supported.

> > This is much like the IPv4 to IPv6 'migration' situation that's been
> > discussed all over NANOG (and other networking groups) for years;
>
> [...]
>
> > The 'purist' solution would have been IPv6 instead of NAT;

> The 'purist' approach would have been to use the overspec'd and
> underimplemented OSI protocols in the first place instead of IP and not
> run out of addresses.  But there wasn't a *bsd licensed version to drive
> adoption (or a free gov't sponsored directory service)...

As the GOSIP specs and standards specified the use of the OSI stack (CLNS, 
CLNP, IS-IS, and friends), and since BSD-licensed support of OSI as of 4.3BSD 
Reno (released in 1990) existed, this too is a strawman.  TCP/IP won because 
it wasn't designed then implemented; TCP/IP won because it learned from its 
errors (slow start, anyone?) and went on.  Incidentally, many TCP/IP networks 
use the OSI IS-IS interior gateway routing protocol; OSI at some levels is 
far from dead.  CLNS/CLNP and friends aren't going to the desktop anytime 
soon, but they are still in use.

But I'm talking about the purist approach to solving the IPv4 numbering 
problem, which first manifested itself as a shortage of Class B networks.

> I believe there was exactly one non-backwards compatible change when
> there were about a dozen hosts connected.  Since then, backwards
> compatibility and not breaking the existing, installed base has been the
> primary concern - and the reason that base has continued to increase.

Not entirely true.  The transition to CIDR was not at all painless, and BGPv4 
(the current primary Internet exterior gateway routing protocol) isn't 
terribly backwards compatible with its predecessors.  The change from the old 
ARPA protocol to TCP/IP was on January 1, 1983, although the use of TCP/IP 
had been increasing before that.  Reread RFC801 for context.  Also, in 
August, 1983, shortly after the great TCP cutover, there were approximately 
562 hosts on the Internet, not just a dozen.  It was a real flag day.  With 
the number of hosts connected today, such a flag day would be impossible.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


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