Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!uwm.edu!news-peer.gsl.net!news.gsl.net!news.mathworks.com!uunet!in3.uu.net!192.220.251.22!netnews.nwnet.net!Symiserver2.symantec.com!news From: tedm@agora.rdrop.com Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: PPP Masquerading in FreeBSD Distributions? Date: 4 Dec 1996 08:45:58 GMT Organization: Symantec Corp. Lines: 82 Message-ID: <583do6$4t2@Symiserver2.symantec.com> References: <Pine.BSF.3.91.961127181207.9864B-100000@darkstar> <32A16888.2781E494@FreeBSD.org> Reply-To: tedm@agora.rdrop.com NNTP-Posting-Host: shiva2.central.com X-Newsreader: IBM NewsReader/2 v1.2.5 In <32A16888.2781E494@FreeBSD.org>, "Jordan K. Hubbard" <jkh@FreeBSD.org> writes: >Charles Mott wrote: >> I have neither the experience nor inclination needed for submitting code >> to the FreeBSD Central Committee (or should I say Politburo?). For those >So please don't hurl around epithets like "politburo" just because we're >unwilling to further engage in bad software engineering practices which >we've learned to avoid the hard way. If you're willing to support this I just want to interject something here that you both seem to forget - the whole point of FreeBSD is that the source is available and compilable. If C Mott wants to create a NAT solution then what is wrong with putting it in the ports section as a TAR file? Is it really necessary for everything on the damn CD to be installable with pkg_add? Are we coding for men or babies? While it's nice to have a single command to install various packages and their sources into Unixes, some provision has to be made for the wealth of patches and software out there that is specifically "Do it yourself/roll your own" on the CD. For example, take Ingres. A long time ago, Ingres was available as a port on the FreeBSD 1.1 CD. Julian I think did it. That program disappeared when the move went to 2.x, obviously because Julian got busy with other things, some major change occured that meant work had to be done digging in the Ingres source, etc. etc. etc. However, what happens when someone wants to go compile Ingres on 2.1.6 today? Well, they have to reinvent all the fixes that Julian had to put into the source, plus make any additional fixes needed. Since the 1.1 ports aren't generally available anymore, the likelyhood is that they will never know that Julian even did anything with it to begin with! Wouldn't it be much better to have a separate directory on the CD labeled "stuff that came in off the Internet that probably works with X version of FreeBSD, but no guarenteees that it works today, but it is here in case you want to have a wack at it or see what someone else came up with while having their wack at it" In the case of NAT, as a System Admin I know that Cmott's solution works on 2.1.5, and if I were to decide to use it I'd set up a 2.1.5 server, run the Cmott NAT stuff on it and stuff the entire thing into a golden can that no one would touch. I wouldn't care if FreeBSD went to version 200.1.5 that machine would _never_ be upgraded!!! In my opinion, someone who wasn't comfortable with putting a bunch of kernel patches into their system and recompiling it shouldn't be running NAT in the first place in any case! I'm not advocating busting up the submittal process here. All I'm saying is that the only reason that I buy a FreeBSD CD (other than to help fund development of the OS) is so I don't have to go chasing all over the Internet looking for this and that, or trying to find something on a server that doesen't exist anymore. As FreeBSD grows in popularity there are going to be more folks that are going to want to produce one-shot applications, guarenteed for only a specific release of FreeBSD, and who aren't interested in the slightest in guarenteeing their code after the release of that particular version of FreeBSD. The thing that is important to understand is that there is nothing inherently wrong with this - as long as the code works on that version it's not that much trouble to set up a special machine to run just that application, if it's that important. After all, is there some software god up there that will strike you down dead if you _don't_ go rushing out at the drop of a hat to upgrade to every new version of operating system or program that comes out? Is there some cosmic balance that will be disturbed if en-masse all the users of a particular software package were to politely tell the manufacturer of that package to go to hell when the manufacturer decides they need a quick cash infusion and so shoves something half-baked out the door and slaps a new version number on it? Is it a requirement for software users to salivate and bark like dogs when they see a commercial for a software package that is identical to the old package except that it has a few bugs fixed and thus has a version number generated from some arbitrary number like the number of planets in the solar system, or the number of years since some ancient prophet died in the Middle East? Sheesh!!!! ;-) The goal in these cases should not be to integrate these projects into a continuing effort of the operating system, rather the goal should be to make these projects available as case studies for future people that may want to work on them someday.