Mailing List Archive

Support open source code!

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

Re: FreeBSD vs. Linux

>>>>> "hy" == YAMAGATA Hiroo <> writes:

    hy> At 20:57 00/11/12 +0900, you wrote:
    >> Also, as Yamagata-san mentioned, I am VERY happy with the ports
    >> system, especially as compared to the RedHat rpm system. One of
    >> the most frustrating things I had dealt with using RH was
    >> broken dependencies.

    hy> Oh, about this point. BSDs have ports (which patch and compile
    hy> things from source) and packages (binaries). They are both
    hy> supposed to take care of dependencies, but all of these stuff
    hy> are only as good as the person who assembles them.

It's not just the quality of the packager.

Probably Debian passed 6000 packages over the weekend (I haven't
looked at dselect since XFree86 4.0 showed up; I haven't time to deal
with a broken X installation 'til Wednesday but you _know_ that's the
first thing I'll do ;).  The standard Linux packaging systems are just
wilting before the storm of package proliferation.  The BSDs don't
have to deal with that, AFAIK FreeBSD's ports number in the low

If people start using them as desktop systems, so that all of the
flash'n'trash is demanded and starts to become available, you can bet
the "ports" system will break down in the same way.

I think that lack of flash'n'trash is a real advantage of the *BSDs,
but most Linux users won't. ;-)

    hy>  There ARE broken dependencies in these stuff, too. I had a
    hy> lot of trouble before finding out that XEmacs needs gettext.

That's interesting.  XEmacs doesn't use it at all.  I wonder what
FreeBSD knows that doesn't....

To be fair, Emacs is probably the hardest single class of application
to configure correctly, since it isn't really adapted to loadable
modules yet.  (Both rms and several XEmacs board members oppose it.
rms's reasons I haven't heard.  The XEmacs argument is that if it
provides a Lisp-level API, it had better provide "first-class objects"
and not break down mysteriously if a module is missing or something.
The XEmacs "ell" project is hanging fire until the advocates get
around to designing plausible mechanisms to guarantee this; so far
they're satisfied to have it configured in the beta series by
default.  But nobody is porting existing functionality to it.)

XEmacs ports are notoriously bad across the board.  This is at least
partly due to the fact that Emacs is a full-scale user interface in
itself, and XEmacs tries to support access to any OS facility
available, including image, audio, advanced database, LDAP, Asian
language FEPs, etc.  All that has to be compiled in as matters stand
today, and loading will fail if a lib*.so is missing.

The FreeBSD port is one of the worst, I don't know why, but the Red
Hat contrib RPM for a long time (years ago) was configured to lose
mail, and Debian's suffers under both from the Stalinist "Emacs
policy" and some really stupid Debian innovations (like xaw-wrappers).
AFAIK _no_ distro, Linux or *BSD, is currently represented by an
active XEmacs developer on the XEmacs devel lists.  (Steve Baur of
Turbolinux hasn't been very active since resigning the chief
maintainership and Andreas Jaeger of SuSE recently resigned as package
maintainer.)  However, one would imagine those distros have more solid
XEmacs packages than average.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links