Mailing List Archive


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

Re: [tlug] Mandrake vs. Red Hat



>>>>> "Matt" == Matt Gushee <mgushee@example.com> writes:

    Matt> If you unslant that statement a bit, yes, that's what I
    Matt> mean.  "Obsolete?" Jeezus. If you ask me, stuff that works
    Matt> is not obsolete.

Obsolete is hyperbole, even for stable.

    Matt> But the point is, what's all the bloody rush to fix what
    Matt> probably isn't broken?

Dependencies, mostly.  If you want to install any bleeding-edge
package, you typically find yourself in a cascade of dependencies.
The first production box that I went to unstable on was my mail server
(!)  because I needed ipchains, then not available in the stable
distro.  I forget what the cascade was there.  Then my personal
workstation caught the bug because I was sick of building Ghostscript,
but the features I needed depended on libraries not available on
stable (a particular version of vflib, which pulled in a bunch of
stuff that conflicted with kterm or something, yarg).

    Matt> Unusable for compulsive upgraders, you mean? Or if not, just
    Matt> what do you mean?

I mean that there are a lot of apps in unstable that aren't in stable
_at all_ and if you're dependent on one of those, you lose.  (At least
they weren't when I moved to unstable; being able to choose whether to
build a bunch of apps was a pleasant side effect of the move.)

    Matt> But I guess it's too old, and I suppose you have a duty to
    Matt> turn me in to the Obsolesence Police.

Huh.  If it works for you, I don't have a problem with it.  My mail
server would still be running hamm (which _was_ unstable when I
switched to it ;-), but it's too slow to build some of the software I
use on it, and my workstation is running unstable so it pulls in
dependencies on recent libraries.  So I switched from hamm to unstable
(back before sid when woody was unstable).  It hasn't done me any harm
yet, and it's much less painful to build-my-own when appropriate this way.

    >> Red Hat's real weakness in this regard, I suspect, is that it
    >> is enterprise-oriented.  If you can afford an enterprise-class
    >> system, Red Hat will work for you.  ;-)

    Matt> Your logic escapes me, maestro. Enterprise-oriented? Is that
    Matt> why RedHat went to glibc before it was ready for prime time?

Yes.  Enterprises needed the features (or thought that they did) and
the future upgrade path, and were willing to pay for Red Hat support.

    Matt> Why they put out half-assed configuration tools like
    Matt> XConfigurator?

Yes.  Enterprises stick to the Red Hat "approved hardware list", and
you get on that list by working with HACT tools.[1]

    Matt> Why they have a long history of shipping XEmacs packages
    Matt> that really sucked?

Yes.  XEmacs isn't an enterprise-quality package, I'm afraid, hasn't
been since about 19.14.  It's got enterprise-class features and has an
enterprise-class source tree; there's some really interesting add-ons
like "I could tell you but then I'd have to kill you" done by
companies like "I could tell you but then I'd have to kill you" ;-)

One of them depends on the external widget, which allows you (in
principle) to embed a client that connects to XEmacs via X protocol
anywhere you could put an XmText (or the Athena variant).  You simply
couldn't do those with GNU Emacs or vi or any other free software app
I know of.  Until very recently---I think you still need alpha vim to
get KPart (or maybe it's XPart) support.  XEmacs had that working in
1995.  Nobody used it, and on Linux now it doesn't work very well in
Xt anymore.  (I haven't tried in Motif, not supported in GTK.  If
you're interested I can show you at a nomikai, or build it yourself:
http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/XEmacsInside.c.)

But I can't really recommend XEmacs to any business which doesn't have
the resources (either love or money, but you gotta have one or the
other) to support an Emacs guru or two.  It's not something you can do
tar xvzf xemacs.tar.gz && configure && make && make install and forget
about.  It has enormous potential to annoy the heck out of sysadmins,
because there are so many features that "just about work but not
quite" for the novice.

And it's different enough from GNU Emacs that I'm not surprised they
decided they could do a good job on only one Emacs.  Nor am I
surprised they chose GNU.  I was pleased when they brought back the
"official" XEmacs RPM "by popular demand", of course.


Footnotes: 
[1]  Sorry for the redundancy, but I couldn't resist the acronymic pun.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links