F8 and Staroffice8

Thu Nov 22 14:06:04 UTC 2007

On Thu, 2007-11-22 at 12:22 +0000, Simon Andrews wrote:
> 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.

Clearly - You have a right to your opinion. I just believe you're
sincerely wrong and your further comments underscore it...
> 
> 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).

...Except the jury is still out on if it's an improvement. That's why
the Java and X people are arguing about it. Note that, from what I have
observed, I still blame the Java guys for this one, but to be neutral
about it means to hear both sides out before taking a stand.

> 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.

I don't expect Fedora to hold back - that's what you don't seem to
understand. I expect that, at a minimum, adequate work-arounds for
things people might need are found, documented, and made available. In
this case something might exist, but if it does, the other critieria
(document and publish) have not yet been met.

> 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.

Agreed - and pressure is being applied. But that same argument, when
combined with your advice to roll back to F7 instead of finding a
work-around also means pressure is being applied _not_ to upgrade to new
versions of Fedora are unnecessarily added to this mix. That causes
Fedora not to move as well as it could or should.

> 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.

Again, this is misguided. Laying the problem and the commercial vendors
and washing your hands of the situation doesn't help people adopt
Fedora. Laying the problem at the feet of the software vendors, and then
helping people find workable, practical answers to help them use the
latest Fedora offerings while the commercial vendors develop a permanent
fix for their products works a lot better.

> > 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...

Ever seen adapters that allow old VHS players to use inputs for DVD
players? Ever seen DVD/VHS combo players? Ever seen VHS/DVD converters?
Hmmm... You're right! Analogies _are_ fun. Esepcially when you know how
to use them well.

> 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.

Seriously - This is an example of the circular logic I mentioned.
> 
> > 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.

Not exactly. Read section 15.1 of the F8 Release Notes. Iced Tea doesn't
work just fine. Moreover, it's a derivative of the portions of Java that
Sun released under the GPL, with additional code developed by others to
try and fill in what hasn't been GPL'd yet. While definitely a good step
in the right direction, it's not all the way there. If it were, people
wouldn't need to post so many work-arounds to get Sun Java working on
their systems.

Those people are applying pressure in all of the appropriate areas - the
external vendors _and_ the Fedora team. ...And I believe they are
applying that pressure correctly.

> > 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.

I've been around using and making contributions to this distro - and its
parent - for a very long time (since Red Hat Linux 4.X - Yikes!! Am I
_that_ old?!?).

My focus is on ensuring that the feedback I give and contributions I
make continue to push Fedora forward, while simultaneously keeping
Fedora's feet firmly on the ground. I point those contributions toward
helping people, myself included, use the distro to satisfy practical
needs. My other posts in various topics show evidence of that.

Businesses _do_ use Fedora both officially and (as in my case)
unofficially, and with the full support of my senior leaders. We use it
to know where things are now and understand how to improve things going
forward. The Fedora developers need that info and feedback to better
position Fedora. It's still a product and it's still supported by a
business. Red Hat has done a great job of properly leveraging GPL
software to support a good, fair, and ethical business - but make no
mistake - it's still a business.

> >> 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.

I'm sure it will in time. But I'd still bet good money it won't fully
happen before F8 has long past its EOL. I'd love to be wrong about that,
but I doubt I will be. Meanwhile, finding practical solutions for F8 for
these situations does help the overall Fedora cause. Finding fixes helps
us all even more. Telling people to roll back doesn't.

Cheers,

Chris

--
====================================================
In theory there is no difference between theory and practice.
In practice there is.

--Yogi Berra