Re: F8 and Staroffice8

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

 



Christopher A. Williams wrote:
On Wed, 2007-11-21 at 15:00 +0000, Simon Andrews wrote:
Christopher A. Williams wrote:
I think the appropriate thing to do is to temporarily roll the X libs in
question in F8 back to the F7 versions (or their equivalents) until the
X and Java guys work out their own differences.
With the best will in the world this isn't going to happen, and personally I don't think it should.

Fedora includes IcedTea which is to all intents and purposes the Sun JRE (v1.7). It's been compiled to work with the X libs on F8 and works just fine.
<snip...>

With all due respect, I strongly disagree. This is an idealistic
position that doesn't fix the practical problem. Having Iced Tea
included doesn't help the problem people are having. Period. Suggesting
someone to roll back to F7 also isn't practical. Suggesting (as someone
else did) that you use the appropriate set of libs from the F7 distro is
a little more realistic, but you didn't go there...

I suppose I take a different view of all of this.

If I have an application from outside Fedora on which I rely then before upgrading I'd check that it was going to work on the new version. Things change in every release and compatibility is never going to be 100%. Usually things break either because of a bug (which usually gets fixed fairly quickly) or becuase an improvement in one area (eg X) breaks an API used by something else (Java).

In the second case you really can't expect Fedora to hold back on the latest version of something to maintain compatibility with out of distribution software. One of Fedora's goals is to be using the latest upstream versions so people who want that get to try it first. Unfortunately you're hitting the down side of this.

The good thing about this approach by Fedora is that the volume of Fedora users are usually pretty good at applying pressure to commercial software vendors to make their packages work with the latest Fedora. Without this there's very little incentive for pacakages to get updated and things stagnate.


Understand that you have taken a position that, because a person has a
needed application which, by all rights, _should_ run but doesn't
bacause of a disagreement that they have no say in, you're telling them
that they should use the previous and, by implication, less featured
version of Fedora.

Sure, this is a problem, but it's a problem which should be placed at the door of the commercial software vendors. The *reason* fedora is more richly featured is its agressive update schedule. You can't have this both ways.


Ever walked into a store and, based on your personal
appearance, had someone greet you by saying, "let me show you something
a little less expensive..."? Your suggestion leaves excactly the same
feeling with someone. So much for being inclusive.

Ever walked into a shop selling DVD players holding a bunch of VHS cassettes only to be told that they aren't going to work and you should either get your films on DVD now or stick with using a VHS player? Aren't analogies fun...


In today's world, you will always have a mix of free and proprietary
software to address complete business needs. Commercial vendors aren't
going to react as quickly - for many and various reasons ranging from
the practical and economic to those that make no sense to anyone.

If you're after a distribution which is designed to work better with commerical packages then look at RHEL/Centos. Seriously. These disributions are made to give commercial providers longer lead times to adapt to changes and then to be supported for a long time so you don't have to change anything. You can also get a similar effect by staying one fedora release behind the latest (which is still supported precicely for people in your situation). There is an inherent conflict between progress and backwards compatibility. Fedora explicity falls on the side of progress, but there are options for those who don't want to take that approach.

The X and Java guys don't seem likely to work out their differences
anytime soon, and even if they did, the commercial vendors relying on
these packages aren't likely to change their ways anytime soon either.

The X and Java guys have sorted out their differencs for the version of Java which is distributed with Fedora, which works just fine. That's what's great about a distribution. All of these things get worked out for you. For external pacakges you need to apply pressure to the people producing those packages.

I have found that the key to gaining acceptance is making appropriate
trade-offs and taking practical, measured, acceptable risks, instead of
holding to an impractical standard of idealism. It's possible to do that
without compromising on core values. It's mandatory to do that to
succeed in business.

Then again, maybe if your focus is skewed towards business you should consider a distribution which also thinks the same way. This is not intended as a criticism it's an honest suggestion for helping you avoid the problems you're encountering.

PS Hopefully the inclusion of a free JRE in the core distribution will put an end to the inclusion of a program specific JRE alongside java programs in linux. That always seemed a really hacky way to make your programs work.

It may be hacky, but it still is reality.

I'd say it *was* reality in the days when Sun's java was not redistributable by linux distributions, and the free versions (gcj etc) were not compatible with a lot of code written againt the core Java libraries. With the freeing of java by Sun I suspect and hope that more linux software will be able to assume the presence of a suitable JRE on the system and not have to include its own.

Simon.

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux