Re: first impressions of Red Hat 8.0

[Jeff Licquia <jeff@licquia.org>]

On Mon, 2002-09-30 at 23:45, Steven Pritchard wrote:
> On Mon, Sep 30, 2002 at 05:52:49PM -0500, Jeff Licquia wrote:
> > Oh, yeah.  Don't get me wrong; gcc 3.2 isn't the problem here.  It's the
> > solution to a whole host of other problems.
> 
> Right, which is why I'm in the "everything before now is broken, so
> recompile" mindset.
> 
> Then again, as you well know, I've never been a big fan of C++, so my
> opinion might not count for much.  ;-)

What galls me is that it didn't have to be that way.  The vast majority
of software used the ABI of either gcc 2.95 or gcc 2.96; while not
ideal, we weren't that bad off.  By bumping the sonames, we allow for a
fresh new start without making anything worse with older software than
it already was.

It also makes me nervous about RH as the "caretaker of the ABIs".  This
is the second time they've screwed the pooch on this topic.  Fool me
once, shame on you; fool me twice...

/me hopes the LSB takes the baton from RH on ABIs.

> > That's an interesting site.  They have an autobuilder for RPMs?  Do you
> > happen to know if their autobuilder is open source?
> 
> I honestly have no idea.  Matthias seems like a good guy though...  I
> would imagine that any tools he might have are likely to be open
> source.

Didn't see it.  I did see the apt-rpm 0.5.x stuff, which makes me
extremely, extremely happy. :-)

> > You did know that apt is written in C++, right?  :-)
> 
> Yeah.  In fact, when I was writing the last email, I thought of
> that, which makes me rather curious...  When I upgraded my laptop, the
> apt 0.5.4 rpms weren't available yet, so I was still using apt 0.3.x
> with librpm404, and it did work.  So either the older apt is linked
> statically against libstdc++ (which I find somewhat unlikely), or Red
> Hat 8.0 includes some compat- packages which resolve the
> incompatibilites.
> 
> I'll have to remember to check that out the next time I have the
> laptop running.
> 
> > It's not like there aren't solutions.  We may have to tell people
> > "rebuild all your C++ code" or something like that; we may do something
> > like we did for the a.out -> ELF migration.
> 
> It's really not nearly as bad as that...  We're talking about a select
> group of (admittedly large) applications, not core system tools or
> libraries (usually).

No, but the solution is similar: ship libs for both (all five?) ABIs and
teach ld.so how to link to them all.

> > It's hard to make claims about Windows DLL issues, for example, when
> > we create the same problems for ourselves for no good reason at all.
> 
> I'm sorry, but until Linux distributions start letting applications
> update /lib and /usr/lib, I think we've still got valid issues with
> Windows DLLs.  :-)

The fact that we create package managers to screw up our apps for us,
instead of letting our apps screw each other up, doesn't strike me as
much of an advantage.

> > I don't think I have a real point, other than whining about RH's
> > propensity to rush into things without thinking.
> 
> I really hate to be in the position of defending Red Hat, since I do
> think they sometimes do *really* stupid things, but I'm not so sure
> this particular issue is something I'd hold against them.

In the long run, I don't think it'll be a huge problem.  We'll all come
up with workarounds, and eventually it'll all be a distant memory, much
like a.out and libc5.  It's just irritating.

> Shipping a new release with rpm completely broken is something I'd
> definitely hold against them though.  I can't figure out why people
> aren't absolutely screaming about that already.
> 
> I'd also like to know what the thinking was behind releasing Red Hat
> 8.0 with a pre-release glibc too.  Hopefully, like in 7.0, the final,
> stable release will be only a couple of weeks or so away.  It seems to
> me like sticking with glibc 2.2 for a while would have made a lot of
> sense, but maybe they have a good reason.  (Probably not, but Red Hat
> has been good enough about enough things lately for me to want to give
> them the benefit of the doubt.)

At least the glibc ABI isn't toast.  It probably wouldn't have been too
hard to kick back to 2.2.5 if testing determined that 2.2.90 wasn't up
to snuff.

Were I in their shoes, I would have built with 2.2.5 for a while, just
in case. :-)

I wonder if they're in need of a new QA manager... :-)

> I also wonder about the wisdom of dropping all MP3 support.  I can't
> help but wonder if this is another one of their knee-jerk reactions
> (like the attitude they originally had with Qt and KDE), or if they
> actually were advised to do this by their legal department.
> 
> Their "use Ogg Vorbis" answer doesn't exactly work with me, at least
> not until somebody Red Hat can point me to a firmware upgrade for my
> Apex DVD player and my Aiwa car stereo, plus give me a utility to
> convert my 23GB of MP3s without loss (and sometime this century).

Well, now it's my turn to come to RH's defense.

Fraunhofer has been very, very vague about the MP3 patents lately: "a
change to the terms isn't a change, and really our current wording
reflects our thinking on the patents all along, which you were supposed
to learn by reading our minds...".  There's actually a good possibility
that all MP3 decoders in Debian will move to non-free - depending on
whether we can decipher Fraunhofer's position on selling open-source
decoders.

It may suck, but I can't blame RH for covering their butt.  I put the
blame entirely on Fraunhofer for this.

Now, it's also possible that they'll restore the MP3 codecs in the boxed
set, after setting up a channel for royalties to Fraunhofer.  That
wouldn't be too bad a situation.  Newbies should probably be buying the
box anyway, and old hands know (or can easily learn) how to use tools
like apt.

Then again, I'm the proud owner of the only portable Ogg player
available on the market today, and all of my music is in Ogg Vorbis, so
I suppose I can't complain. :-)

> And now you have me venting...  :-)

Become one with the Dark Side... :-)


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.