F8 and Staroffice8

[Simon Andrews]

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.