*BSD News Article 46119


Return to BSD News archive

Newsgroups: comp.unix.bsd.freebsd.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!howland.reston.ans.net!Germany.EU.net!nntp.gmd.de!nntp.darmstadt.gmd.de!news.th-darmstadt.de!hrz-ws11.hrz.uni-kassel.de!phase23!citylink.dinoex.sub.org!peter
From: peter@citylink.dinoex.sub.org (Peter Much)
Subject: Re: When did this become linux.advocacy
Organization: Buero fuer Sektenforschung und Qualitaetspruefung in der Esoterik
Message-ID: <DAt15p.F5p@citylink.dinoex.sub.org>
References: <marcus.114.00E9749F@ccelab.iastate.edu> <3sboim$ue@bonnie.tcd-dresden.de> <DAnIFG.7EE@citylink.dinoex.sub.org> <3shime$l2i@news.nynexst.com>
Date: Mon, 26 Jun 1995 23:56:12 GMT
Lines: 73

In article <3shime$l2i@news.nynexst.com>, Nighthhawk <fsosi@j51.com> wrote:

>|> The other point is: Keep a directory with ~2000 files, and run ls
>|> (or ls -l) under linux/ext2. Then run it under *BSD; about Factor 25
>|> faster. This seems typically linux/ext2 Filesystem, it increases dir-

>That was an old feature in the Linux C library as well as the Linux
>kernel. We have modified it in libc 5.1.3 and linux 1.3.3.

Oh well, this is indeed funny! We're just now installing another Linux
server from the newest available distribution, which is 1.2.8. (In the
meantime, i heard of 1.2.9. having been released.)

Comparing my 0.99p15f with 1.2.8. shows one major difference: The deve-
lopment system has become quite unuseable now.

As i know from experience, the precompiled Linux binaries are very of-
ten unuseable for many things (except for demo applications). So I'm
compiling all important stuff by myself.

But, on 1.2.8., it takes days to find all the new bugs & inconsistencies
built into the development system, until one gets the sources compiled.

Some examples (forgotten the easier ones):
1. Often the compiler dies with sig 11; so one cannot rebuild sources
   in background from remote and log out interim.
2. "make" is no longer able to handle recursive makes in some sense-ma-
   king way. So, one cannot compile many larger source distributions
   without editing all makefiles.
3. cc/ld is no longer able to handle certain global variable names. The
   programs will be built without error-message, but will crash with
   segfault, when the global variable is written the first time.
   This happens, for example, when building nntpd, which declares a
   global variable "hostname". So, one has to rewrite all the sources
   in search of variable-names that can be used. (If one at all finds
   out what is going on - which isn't obvious, since the linker doesn't
   report the name conflict - or what the hell that is.)

Pos. 1. and 2. are already known to the world. But i didn't find any
pointer to Pos. 3. by grep'ing thru c.o.l. The "official" bugfix seems
to be the substitution of the non-working programs by others, say, to
use INN instaed of nntpd.

I think it would have been much better using NetBSD or FreeBSD there,
but the argument against was that many people here know Linux, while
only two people know BSD.

But most of this typical trouble cannot happen at all - if one uses
some source contribution control, like the BSD's do.

>you want, you can test it under libc 5.1.3 and linux 1.3.3. Of course,
>your ls has to be dynamicalled linked with libc 5.x.x.

No, thank You. I happily notice that this problem has been spotted and
can be solved. But from 0.99p15f to 1.2.8., lots of things have become
worse and few have become better, and i don't yet see a turnaround.
(I don't need cdroms, and install-menus, and multimedia, and all
that single-user-stuff, if that does weaken the developmet system.)
So i will no longer play with these things in a more intense way than
everydays need brings with it, anyway.

Not to be misunderstood: This is not meant to be offensive, it is just
a description of where it does hurt.

The people working on Linux are doing great work in developing source,
just like the people working on BSD. But the BSD people are doing some-
thing else, that is seldom noticed and nearly never evaluated to it's
true value: they are keeping the whole thing consistant.

Peter
-- 
  Write to:  Peter Much * Koelnische Str. 22 * D-34117 Kassel * +49-561-774961
 peter@citylink.dinoex.sub.org  much@hrz.uni-kassel.de   p.much@asco.nev.sub.de