Wine/Cedega and fedora 3

[Sean Middleditch]

On Wed, 2004-12-08 at 10:06 -0500, Sean wrote:
> On Wed, December 8, 2004 9:46 am, Sean Middleditch said:
> >
> > The problem is that nothing is solved.  I have RHEL 2.1, but it's near
> > bloody impossible to find up-to-date RPMs of various software I need for
> > it.  I *could* upgrade to RHEL 3.0, but then that would require massive
> > server downtime across several *very* important servers, and who knows
> > if things will actually work afterwards?
> 
> These were the same issues facing people moving from Windows NT to Windows
> 2000.  There's no magic bullet.

The issues are, in general, far smaller.  While things may break in the
upgrade, far less things break.  With Linux, you watch the entire bloody
OS break since glibc or gcc or some other insanely important component
decides to just become incompatible for the most trivial of advantages,
most of which can be had _without_ breaking ABI.

With most Windows upgrade problems I've seen (very, very few - I can
count them on one hand) the problem was usually broken applications that
made assumptions.  That problem definitely does exist in Linux, no
questions, and I'm not complaining (to the OS guys) about that.  With
most Linux upgrade problems I've seen (more than I can count) it's not
the apps, but the OS that breaks perfectly well behaved apps.  In most
cases, the OS itself is fine, but the way the OS was packages created
artificial conflicts that don't really exist anywhere but in RPM
headers!

> 
> > Why the hell should I have to upgrade my operating system to get a new
> > version of SSH or Exim installed?
> 
> The same is true with Windows 2000, the updates from Microsoft are slowing
> down.  You take the software that is released by them at the pace they
> release it or you roll your own.   I don't see the difference between that
> and RHEL 2.1.

Most people in reality do not just use software from one vendor.  If we
only used Microsoft software our IT staff wouldn't be needed, since our
network wouldn't actually do anything other than exist.  Likewise, if we
only used what Red Hat slapped on their CDs, we wouldn't be here,
because the network would be useless.  If all our software was supplied
by Novell, our network would let us share files that we wouldn't have
because the apps we use aren't supplied by Novell.

Real deployments depend on third party software from ISVs, be they
proprietary or open source.  Red Hat knows that, and work with it, which
is good.

> 
> >
> > Why should I have to compile it and patch it myself, then becoming
> > responsible to manually track all security updates and repatch/rebuild
> > it asap after each is released, when it's *already* being repatched and
> > recompiling by thousands of other people around the world, including
> > people at Red Hat?
> >
> 
> So, we need a RHEL 2.1 extras repository?   Sounds like an opportunity.
> Even without a RHEL repository, the burden of recompiling custom rpm's
> really isn't all that great anyway.

An extras repository just for RHEL 2.1?  So the small handful of people
who are capable of putting the time and effort into maintaining quality
packages can be spread even thinner?  Re-read my original mail on this
subject - this kind of mass duplication of effort and waste of human
resources is completely pointless, and can be worked around by just
doing a better job packaging in most cases.

The biggest differences between two versions of a distro are usually
which versions of libraries are available.  If the packaging of those
libraries would allow parallel installation without the headaches (which
the libraries themselvs often have no problem with) there wouldn't be
any reason to have to recompile an app for each version of each distro
of Linux.  You'd just compile it once, provide copies of the library
RPMs for distros that only have older/newer versions, and things would
Just Work(tm) independent of whether you use RHEL 2.1, RHEL 3.0, Novell
Enterprise Linux, Mandrake, whatever.

> 
> > With the "solution" you seem to think to exists, those are my only two
> > options.  Neither is very appealing at all.
> 
> Exactly what extra solution do you have on a Windows 2000 box?   Does your
> complaint boil down to you prefer binaries over source code?

When I'm trying to get work done that doesn't involve code I'm writing?
Of course I prefer binaries.  It wouldn't do me a lot of good to prefer
source code in that kind of case.  Source doesn't do any real work at
all for you.  The binaries do.  The second you touch the source, you
completely break the chain of automatic security updates from your
vendor, the QA testing done by your vendor, the compatibility with ISVs
that only tested against what your vendor supplied, the upgrade path for
new versions of the OS supplied by the vendor, etc.  By "vendor" I mean
whichever vendor the app came from, be it my OS vendor (Red Hat),
framework library vendor (Novell), application vendor (quite a few), or
other open source vendor (openssh.org, exim.org, whoever).

All of which would be unnecessary in most cases with slightly better
packaging standards.  There's no good reason why I shouldn't be able to
drop in a third-party repository that over-rides some RH-supplied
package and just have things work, especially if I trust that repository
to handle security updates.  Due to how RH packages things third party
vendors need to supply packages for four or five versions of RHL, two or
three versions of RHEL, three versions of Fedora, not to mention
multiple architectures of each, nor the other distros they probably want
to support (SUSE/Novell, Debian, Mandrake, etc.).  Then they have to
host all those insanely redundant bits somewhere.  Then there's the UI
head-aches that causes.  It's bloody stupid.  A binary compiled on x86
against libs X, Y, and Z should just work, end of story, on Linux x86
with libs X, Y, and Z installed, and there should be *no* reason why you
can't install those libs if they're not already.  The only thing that
does stop it is apathy on the part of the developers and packagers.

Big huge Extras repositories are not the answer.  If they were, Debian
would be a utopia, because they have more "extras" than Fedora or RHEL
will have anytime soon.  There will always be apps that just aren't in
any Extras repository, there will always be apps that upgraded more
frequently than the Extras maintainers care (or are able) to keep up
with.  There will always be the fact that Extras repositories are only
maintained for a limited time until you are forced to upgrade your
entire OS and all related software just to keep up with a single
application.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.