Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Dec 1996 08:36:04 +0800
From:      Peter Wemm <peter@spinner.DIALix.COM>
To:        sos@FreeBSD.org
Cc:        CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-usrbin@freefall.freebsd.org
Subject:   Re: cvs commit: src/usr.bin/vi Makefile 
Message-ID:  <199612310036.IAA01892@spinner.DIALix.COM>
In-Reply-To: Your message of "Mon, 30 Dec 1996 23:11:37 %2B0100." <199612302211.XAA00711@ravenock.cybercity.dk> 

next in thread | previous in thread | raw e-mail | index | archive | help
[Whoo.. this is going to be a loong day...]

sos@FreeBSD.org wrote:
> In reply to Peter Wemm who wrote:
> > sos@FreeBSD.org wrote:
> > > In reply to J Wunsch who wrote:
> > > > As Jordan K. Hubbard wrote:
> > > > 
> > > > > I was just going to comment that perhaps its time to throw out perl4
> > > > > and adopt perl5 in our main tree.  Yes, I know it's 3 times larger,
> > > > > but...
> > > > 
> > > > Couldn't we find a ``golden way'' to only commit the basic parts to
> > > > the base tree, while leaving all the more obscure modules in
> > > > portsland?
> > > 
> > > Ahem, I won't even comment on this, you all know my POV, but if
> > > it should go in, PLEASE as little as possible....
> > 
> > For what it's worth, I agree.  The reason nobody has sat down and figured 
> > out how to do it is because it's not exactly trivial.  I'm sure it would 
> > be relatively simple to bring in the whole kit, kitchen sink and all, but 
> > that's probably the worst possible outcome as practially nobody would be 
> > happy.  It is vital though, that we don't loose any "core" functionality 
> > or the compatabilty problems would also make it useless.
> 
> We _had_ a nice system called base system & ports....

The software world in which base and ports were designed (4?) years ago 
has changed dramatically.  It used to be that everything was in C and 
everything was standalone and easily paritioned into nice seperate 
standalone compoments.

Today, we have a world where a lot of stuff is being integrated beyond 
pipes, extension languages are here and in *demand* and a enough of the 
current versions of the "base" components have evolved to use them.  The 
seperate base+ports system has never been able to cope with that, because 
the base components are increasingly depending on stuff that's 
traditionally been in ports.  Today, the lines are very blurred.

> Now we have to reinvent that again and call it something new, real
> progress...

No, the problems today are mainly because the ports system is free form.  
OK, so components are usually installed under /usr/local, but a big issue 
was made over "Don't tell me what do do with *my* /usr/local", so 
eveything was made so it could just as easily happen to end up in /foo 
instead.  To cope with this would mean obfuscating the "base" build system 
even more.

> Yes, what I want to do is pollute the makefiles a bit so that I can
> build a system without some of the monsters in there. It looks an awfull
> lot like its almost just to throw out contrib and whats depending on
> that... Well not quite, I'd like gcc & friends to be in there, for now...
> All in all I just think its rediculous that we have almost doubled
> the size of of src tree but have gained almost no extra functionality..
> (well Billy Boy has a patent on that one, shit...)

gcc and the entire development suite should be one of the first things 
that should be broken out since a lot of real users don't need it (and 
even run kernel.GENERIC).

gcc, gdb and libg++ are the single biggest users of src/contrib, with 45MB 
between them.

They are the very first things that should go out if we're going to have a 
"remove everything to ports" session (why favour gcc over lcc?).  Followed 
straight after by tcl (why not perl5?), vi (emacs?), groff (not 
necessary), cvs/rcs (prcs? perforce?), gzip and compress (choice includes 
arc,zoo,zip,lha etc), sendmail (choose between qmail, zmail, smail).

Then, building the "base" (what's left of it) will become a case of 
fetching a few binary packages, bootstrapping a couple of compilers from 
source, installing the rest of the packages needed to compile what you've 
chosen, then do a 'make' which will take 5 minutes.

You can't have it both ways.  Just because it suits you to have less code 
and a fragmented system, it doesn't suit me!  IMHO, going down this path 
leads to Linux just with a different kernel - where you get source for 
components but you need a direct telepathic link to the person who 
assembled the distribution over a few months in order to figure out how to 
recreate it.  Have you ever wondered why 99.99% of linux systems are 
installed from binaries and never recompiled?  Here, we do one bootstrap 
install and many then track a branch as they need.

As much as I despise the tcl syntax, it, like perl has become as much a 
part of standard part of "modern unix" as awk, *csh, sed, etc which 
certainly not part of "original" unix.  Unix must evolve with the needs of 
users in mind or NT will run us down just that bit more easily.  Scripting 
languages (such as perl and tcl) are part of what is needed.  Witness the 
mass revival of BASIC as proof that "ideals" are dead.

Anyway..  for a slight change of subject, I wonder what the demographics 
of our installed systems are like?  I would be interested to know what 
sort of percentages the systems that fall under "dedicated 
file/network/etc servers", "ISP servers", "unix hobbyist/fanatic 
toy^H^H^Htools", and "other".

Cheers,
-Peter





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612310036.IAA01892>