Re: tlug: Locale problem

["Stephen J. Turnbull" <turnbull@example.com>]

--------------------------------------------------------
tlug note from "Stephen J. Turnbull" <turnbull@example.com>
--------------------------------------------------------
>>>>> "Totoro" == Totoro  <riley@example.com> writes:

    >> tlug note from "Stephen J. Turnbull"
    >> <turnbull@example.com>
    >> --------------------------------------------------------
    Totoro> installed it. After exporting the language this time, the
    Totoro> perl errors disappeared. Have to check those rpm's more
    >> Which is why switching to Debian made sense for me.  Debian
    >> messes up occasionally, but when they do (1) you can fix it by
    >> hand[3], and (2) they seem to be a lot more careful about
    >> dependencies than is RedHat[4].

    Totoro> Well, in cases such as mine, it was not RedHat, but folks
    Totoro> who had made rpm's on their own and sent them in to the
    Totoro> ftp site. Perhaps the RH people are not screening these. I

RH doesn't have a screening process AFAIK.  They decide what they want 
and don't want; if there's a good package they adopt it and fix it.

    Totoro> don't know. I've noticed recently that there have been
    Totoro> increasing oddities (such as failing to install due to
    Totoro> lack of "/bin/sh", which obviously exists). Is Debian
    Totoro> better at checking for this, or are the debian users who
    Totoro> create .deb packages doing better?

>>>>> "Thomas" == tzler  <Thomas> writes:

(Supercite is not read for MIME time....)

    Thomas> Interesting question - I haven't seen too many "local"
    Thomas> packages yet - most people who take the trouble to roll
    Thomas> their own .debs end up adding them to the distribution
    Thomas> anyways, so they get thoroughly checked till they end up
    Thomas> in stable.

That's part of it, but more important is that the Debian distribution
is an open process, with published standards and textbooks (although
not yet tutorials) on how to make packages.  (See /usr/doc/debian.)  I
build a Debian package for new kernels, and I did it for PGP as well.
Also, Debian opted for using shell and/or Perl scripts for pre-and-
post unpacking configuration, rather than the less flexible pass-
parameter-to-master-script that MS^H^HRedHat Linux uses.  This means
that (for example) tetex takes an incredibly long time to start
unpacking while it's checking for other TeXs.  I assume that it's
looking for spoor like .tfm files and dvi* executables and so on
... on all accessible filesystems.

    Thomas> The only stuff that I more or less regularly install that
    Thomas> isn't in the master.debian.org packages tree (yet) are the
    Thomas> japanese packages - and those that I can get to work seem
    Thomas> to work quite fine.

Well, the blurbs in dselect are horrible; half of the ja packages
don't even mention Japanese anywhere except in the "ja" appended to
the package name.  Half of those that do go no farther than a mention.
The j(la)?tex packages don't include at least one critical file
(/usr/lib/texmf/tex/sitekcode.tex), presumably because they didn't
remember it was a symlink into /etc/texmf.  This left me with a
virjtex but no {jtex,jlatex,amsjlatex}.fmts.  Pret-ty useless.  I
don't know yet if the p(la)?tex packages work.  gs-vflib-ja neither
depends on, excludes, nor suggests gsfonts.  One of xjdic's helper
programs core-dumped during the install process.

    >> Footnotes: [5]
    >> [1] That system is on a hard drive no longer available after a
    >> 3-day scheduled University-wide power out.  I forgot, but
    >> sheesh, sometimes one starts to believe one is living in a 1st
    >> world economy.

    Totoro> Sure it is; it just doesn't operate under the suppositions
    Totoro> that we bring from "gai-atsu-driven" 1st-world
    Totoro> economies...  ;->

I think you have that _exactly_ backwards.  First-world economies are
"nai-atsu" driven, and in particular by consumers.  In Japan, none of
the "not for export" industries look anything like first-world class,
except for politics.  Consider banks, TV, and popular music, for
starters.  What I wouldn't do for a good rock or jazz bar ... is go to
Tokyo.  There must be some there, but just going in is the equivalent
of smoking a pack of cigarettes, let alone the bar atmosphere.

    >> [5] If you like these footnotes, you should be using XEmacs
    >> 20.3!

    Totoro> Is it really different from 20.2?

Hmm.  Good question.  Depends on what you use XEmacs for.  It's faster
if you compile without error-check and debug code, but not by that
much.  Native (ie, written in LISP) national language input support is
substantially improved, except for Asian languages.  XEmacs does not
use the completely rewritten Mule that FSFmacs 20.1 does, though, and
this is probably a very good thing given the reports on comp.emacs
that "every line of Emacs LISP ever written will be broken".  XIM now
works, but that's not a big deal unless you expect to build a lot of
betas (the FEP patches are one of the things that are pretty fragile).
Canna and Wnn support are working well, although Wnn itself is
apparently very broken under Linux libc6.

One important improvement is that defcustom is now the rule in most
XEmacs packages.  This means that most of the important user options
are now customizable through a consistent menu interface.  More
defcustoms are added every day!

Lots of neat little doodads have been added, like strokes-mode.  You
can draw your kanji into the buffer, and use "gestures" to control
XEmacs.  However, the kanji are only recognizable to XEmacs;
handwriting recognition is not there yet (I can count to 10 in kanji,
but not reliably).  Nor is there a dictionary of even moderately
useful size (those 10 kanji plus prepackaged latin characters are all
I have so far. ) The gestures are potentially useful when cutting and
pasting for doing things like adding a line break without releasing
the mouse.

Major packages like VM and Gnus are being updated.  VM especially has
small improvements in MIME and so on; I no longer notice the MIME
problems are causing delays in my workstream.  I now prefer VM's
native MIME support to tm-vm, although I don't do much of it.  (tm-vm
also blow chunks on MIME in mail headers; not dangerously, but some
visual unprettiness.)  VM also now has excellent "virtual folder"
support; I've been using procmail + mh + mh-e to do most of what
virtual folders do, but there are some applications that only virtual
folders handle.

Steve
Next TLUG meeting is Saturday October 11, 1997
-----------------------------------------------------------------
a word from the sponsor will appear below
TWICS - Japan's First Public-Access Internet System.
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096