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
