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
