From owner-cvs-usrbin Mon Dec 30 16:36:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA02833 for cvs-usrbin-outgoing; Mon, 30 Dec 1996 16:36:25 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA02825; Mon, 30 Dec 1996 16:36:16 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id IAA01892; Tue, 31 Dec 1996 08:36:05 +0800 (WST) Message-Id: <199612310036.IAA01892@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 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 In-reply-to: Your message of "Mon, 30 Dec 1996 23:11:37 +0100." <199612302211.XAA00711@ravenock.cybercity.dk> Date: Tue, 31 Dec 1996 08:36:04 +0800 From: Peter Wemm Sender: owner-cvs-usrbin@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [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