On 1/28/2010 12:58 PM, Robert Heller wrote:
http://wiki.centos.org/TipsAndTricks/PluginsFor64BitFirefox
[rhetorical] Why does this mailing list insist on reinventing the wheel rather than perform a simple search of existing documentation first?
You sort-of expect end users to do that. A more relevant question is why is it shipped broken in the first place? Is it just Red Hat trying to maintain their reputation for making java as hard to use as possible?
Java is an odd case: *Sun* has weird / non-compatible license issues, so RH (or CentOS) cannot just re-distribute the Sun JDK and appearently the openjdk does not include a web browser plug in (nothing RH or CentOS can do about that).
Netscape was once an odd case and RH managed to deal with it in a usable way instead of shipping something different and broken with the same name. The jpackage folks had a perfectly usable way to handle the parts that weren't redistributable, back when they weren't redistributable but instead of staying compatible with their repository, RH copied parts and change them in ways that broke the rest. When the license changed on the Sun sdk to make it redistributable and debian incorporated it in their main repostiory, RH only added it to the subscription update stream and CentOS ignored it completely. None of this makes any sense to me.
And it appears that Sun decided to change the name and location of the 64-bit plugin, which is what threw me, esp. since in the *32-bit* Sun JDK (6u18) the *old* plugin library is just where I expected it to be. Why did Sun do *that*? You would have thought that they would have included a README there to explain what they did.
Sun engineers are from some other planet? Since they were so cooperative in open-sourcing the codebase when someone asked, I wonder if anyone from Red Hat ever explained the expected locations for things to land and asked them to build a compatible rpm package the users could install? Having an rpm that doesn't drop into the right places on RH doesn't make any sense to me either.