*BSD News Article 87607


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!goanna.cs.rmit.edu.au!news.apana.org.au!cantor.edge.net.au!news.mira.net.au!news.vbc.net!vbcnet-west!samba.rahul.net!rahul.net!a2i!hustle.rahul.net!rahul.net!a2i!news.clark.net!mr.net!news.maxwell.syr.edu!news.bc.net!nntp.portal.ca!cynic.portal.ca!not-for-mail
From: cjs@cynic.portal.ca (Curt Sampson)
Newsgroups: comp.os.linux.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc
Subject: Re: Linux vs BSD
Date: 28 Jan 1997 08:38:14 -0800
Organization: Internet Portal Services, Inc.
Lines: 69
Distribution: comp
Message-ID: <5cla1m$jip@cynic.portal.ca>
References: <32DFFEAB.7704@usa.net> <5c9444$9vq@lace.colorado.edu> <5c98sl$gbn@cynic.portal.ca> <5ckluo$mbl@josie.abo.fi>
NNTP-Posting-Host: cynic.portal.ca
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:154671 comp.unix.bsd.bsdi.misc:5761 comp.unix.bsd.misc:2067

In article <5ckluo$mbl@josie.abo.fi>, Mats Andtbacka <mandtbac@abo.fi> wrote:

>i would claim that the *BSD
>concept of one "make" in one tree does everything, while certainly
>convenient, is more suitable to people somewhat afraid of their
>compiler. less, after all, to compile, or so it appears to the person
>just typing one "make".

Recompile your full userland on four different architectures a few
times a month and you'll think differently about the ability to
type one `make' and have everything update. The reason it's done
this way is because people who do a *lot* of compiling need a decent
build procedure. GNU/Linux variants can live without this only
because recompiling a full system is not a common thing on Linux
boxen.

>how do you configure all those sources pre-compilation? wouldn't you
>have to delve deep into /usr/src to hack the headers and/or Makefiles?
>how do you choose what gets compiled, which versions of what patched
>how?

The whole point of having the single source tree together is that
those programs that need to be configured for particular OSs already
are configured, the makefiles are standard BSD-style makefiles that
use the built-in build system, and any other configuration is done
during the build based on the system that's being run and environment
variables. For example, when GCC is built, what platform it will
generate code for is determined at that time by what the target of
the build is.

Yes, there are often minor changes between some of the code we
distribute and the vendor source. For example, in the sendmail
makefiles we use `MAN=foo.1 bar.8' rather than `MAN1=foo.0' and
`MAN8=bar.0'. These changes are virtually no work at all to maintain,
since we use CVS for our source tree. (In fact, I had no idea we
had made this change until after I did my sendmail 8.8.5 import
and it had been verified to compile; it came to my attention for
another reason.)

>granted, the *BSD object directory system is worth drooling over, i'd
>love to see that in many Linux sources - not least the kernel.

Surely you must have something like that now. How do you keep
kernels separated when you've got three or four different configurations
for three or four different machines? Couldn't that be extended?

>but i'd
>also like to see separate source packages stay separate; if not, then
>somebody would have to decide which packages to include in the one
>official userland source tree, and reaching consensus would probably
>prove impossible....

Well, perhaps the BSD folks just co-operate more easily with each
other than the GNU/Linux folks. :-)

Seriously, though, it's not all that hard to decide on a base
system.  Who's going to want a system without init, or ls, or cat?
If you're worried about things that are not essential, such as tcl,
either don't include it or put it under a `contrib' tree that users
don't have to download if they don't want. Sure, you may end up
with several differently configured systems being sold, but how is
that different from having several differently configured systems
being old by Red Hat, Debian, Slackware, etc?

cjs
-- 
Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.