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