Date: Tue, 26 Nov 1996 16:58:58 -0500 From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com To: "INTERNET:hackers@freefall.freebsd.org" <hackers@freefall.freebsd.org> Subject: NON-DELIVERY of: hackers-digest V1 #1665 Message-ID: <199611261703_MC1-BC4-D83C@compuserve.com>
next in thread | raw e-mail | index | archive | help
Sender: owner-hackers-digest@freefall.freebsd.org
Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by dub-img-1.compuserve.com (8.6.10/5.950515)
id QAA08733; Thu, 21 Nov 1996 16:40:08 -0500
From: <owner-hackers-digest@freefall.freebsd.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by smyrno.sol.net (8.8.3/8.8.3) with ESMTP id PAA00838; Thu, 21 Nov 1996 15:21:04 -0600 (CST)
Received: (from root@localhost)
by freefall.freebsd.org (8.7.5/8.7.3) id MAA16671
for freebsd-hackers-digest-outgoing; Thu, 21 Nov 1996 12:59:49 -0800 (PST)
Date: Thu, 21 Nov 1996 12:59:49 -0800 (PST)
Message-Id: <199611212059.MAA16671@freefall.freebsd.org>
To: freebsd-hackers-digest@FreeBSD.ORG
Subject: hackers-digest V1 #1665
Reply-To: hackers@freefall.freebsd.org
Errors-To: owner-hackers-digest@freefall.freebsd.org
Precedence: bulk
hackers-digest Thursday, 21 November 1996 Volume 01 : Number 1665
In this issue:
Re: socket.h
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
New mailing list - CVS-Alert???
Re: Who needs Perl? We do!
Re: socket.h
Pentium Pro status
Re: WordPerfect 7.0 for FreeBSD :-)
Re: Disk Striping
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: New mailing list - CVS-Alert???
Re: Who needs Perl? We do!
ft/QIC/Travan support
Re: Who needs Perl? We do!
Re: Pentium Pro status
Re: Who needs Perl? We do!
----------------------------------------------------------------------
From: Lee Crites <adonai@jump.net>
Date: Thu, 21 Nov 1996 11:23:06 -0600 (CST)
Subject: Re: socket.h
On Wed, 20 Nov 1996, Bill Fenner wrote:
> I'd strongly reccommend "Unix Network Programming", by Richard Stevens, as
> a reference for networking programs like this.
I'm *very* glad to see this reference given. I've been lurking on several
of the FreeBSD lists for about a week or so (we are starting an isp
company, and will be using FreeBSD as the os). I've done unix programming
for about a decade, and have found Richard Stevens' books to be invaluable
references. I fear many people might pass over his book(s) because of
the price, opting for the cheap(est|er) ones. But a cost/usage puts them
as some of the best values I have...
Lee
------------------------------
From: roberto@keltia.freenix.fr (Ollivier Robert)
Date: Thu, 21 Nov 1996 18:30:36 +0100
Subject: Re: Who needs Perl? We do!
According to Michael Smith:
> There is no way that Perl 4 would be retained. Perl's size is not a real
> issue; people just need stop thinking that 5M is "big" 8)
It is not just 5 MB of source. It is just that we have to carefully
separate what's in the base Perl tree and what will be added after by the
administrator.
Fortunately, Perl has everything we need for that but it is tricky to do it
right. The @INC path is by default:
Base Perl tree
1. /usr/local/lib/perl5/i386-freebsd/5.00308
2. /usr/local/lib/perl5
We'll have to find the proper place for them in /usr/lib{exec,data}/perl
and /usr/share/perl because it has a mixture of .so (binary) and .pm/.al
(text). Or we could keep all these in /usr/lib/perl (much easier
even if it probably violates hier(7) a bit).
Add-on packages
3. /usr/local/lib/perl5/site_perl/i386-freebsd
4. /usr/local/lib/perl5/site_perl
5. .
- --
Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996
------------------------------
From: Darius Moos <moos@degnet.baynet.de>
Date: Thu, 21 Nov 1996 18:25:57 -0100
Subject: Re: Who needs Perl? We do!
Hi,
following this discussion the last days, i was wondering if anyone
got "undump" compiled ?
I've searched the archives and Nate said "it's not hard" but i can not
figure it out on my own.
The ports for TeX in FreeBSD-2.1.5 does not have it.
The unexec-function of emacs is also not trivial to get to compile.
Any help how to compile undump is highly appreciated.
TIA
Darius Moos.
------------------------------
From: Gary Clark II <gclarkii@main.gbdata.com>
Date: Thu, 21 Nov 1996 11:44:06 -0600 (CST)
Subject: Re: Who needs Perl? We do!
sos@FreeBSD.org wrote:
- --SNIP--
>
> If we are going to have all this **** in the base distribution I want
> names on a list of people _REPONSIBLE_ for each and every package, so
> I know _EXACTLY_ who to yell at when it fails or falls to far
> behind. Otherwise core is going to get bashed over and over for not
> doings thing right. I'll take my share of bashing, but _NOT_ because
> somebody decided to make (favorit program de jur) part of the base system.
I am the Perl person unless someone stands forth. I brought 4.036 in
back in 2.0 and have been waiting for the wrangling to be done with before
I bring in 5.003/4. I have no problem doing this. I also need to
"REMOVE" the current info in the tree and update to the latest. No
big deal, except for the flamage I would catch.
> Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Next point, people are jumping on Perl about how we have so few system
utils based on it it should go, where are the utils based on TCL?
(And as for incompatiable versions... Do all the ports work with
our version of TCL?)
Gary
- --
Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company
gclarkii@GBData.COM | Member of the FreeBSD Doc Team
Providing Internet and ISP startups mail info@GBData.COM for information
FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii
------------------------------
From: Gary Clark II <gclarkii@main.gbdata.com>
Date: Thu, 21 Nov 1996 11:50:11 -0600 (CST)
Subject: New mailing list - CVS-Alert???
Hello,
I would like to propose a new mailing list. It would be called cvs-alert
and wuold be for those times that someone makes a commit that requires
either massive changes to way something is done or re-compiles
of programs.
Lets face it, when someone is getting all of the lists or a large sub-portion
it can be hard to catch little messages at the end of commits telling
you to do this or that.
Yea or Nay?
Gary
- --
Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company
gclarkii@GBData.COM | Member of the FreeBSD Doc Team
Providing Internet and ISP startups mail info@GBData.COM for information
FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii
------------------------------
From: Richard Wackerbarth <rkw@dataplex.net>
Date: Thu, 21 Nov 1996 11:53:49 -0600
Subject: Re: Who needs Perl? We do!
>In reply to Richard Wackerbarth who wrote:
>>
>> >Am I hearing a volounteer here ??
>> > or is there silence again this time ??
>>
>> I suggest that you reconsider your (core) willingness to delegate.
>> I AM doing some chores which, I assure you, some of the "customers"
>> consider important.
>
>You are ??
Yes, but perhaps YOU are one of those that think that "writing new code"
is the only worthwhile contribution. :-(
>> I HAVE volounteered to take on some things and been rebuffed in my efforts.
>
>Really, maybe what you wanted to do, wasn't what needed to be done ??
Oh! I think that there was some concensus that it NEEDS to be done. It is just
that the "core" is unwilling to delegate the responsibility to me.
>> In any case, by delegating certain areas, you are defacto adding those
>> individuals to the (now expanded) "core".
>
>No, I'm not, core is big enough allready, but we need core to be more
>of a governing/directionshowing entity, instead of a poor workhorse..
The Board of Directors still get blamed when the company goes bankrupt.
The upper level managers are also viewed in poor light.
>Like it or not, there has to be rules (like in the real world out
>there), and they should be followed. If we have X developers working
>in Y different directions, we have lost the game. So if one want's
>to participate, one has to follow the rules, simple as that...
Yes, but your "rules" have to take into consideration the fact that this is
(almost exclusively) unpaid labor. If you do not generate a situation where
an individual gets to work onan area that he desires, he can easily choose
to simply not contribute.
Don't get me wrong. I am all for rules. However, they cut both ways. To be
successful, you need to take into consideration reasonable goals and deadlines.
But be careful, if you make the rules too unworkable, you eliminate too many
participants. If, as it appears to some of us, you have one set of rules
for insiders
and another set for outsiders, you decrease the desirability of participation.
Remember that the only real attribute that distinguishes many to the two
populations is that the "insiders" got to this project first (and then
locked the
door?)
>> My comment about dodging the
>> consequences by attempting to distance yourself from the problem still
>> applies.
>I guess we should stop here as we are not going anywhere, and I'm
>using valuable time trying to explain things, where I should be
>producing code/fixes, which btw is considerably more rewarding than
>this....
Perhaps you should consider that in the light of your " we need core
to be more of a governing/directionshowing entity..." statement.
Successful managers often do not have time for "doing" the nitty-gritty.
They MUST delegate.
------------------------------
From: nik@blueberry.co.uk (Nik Clayton)
Date: Thu, 21 Nov 1996 18:21:09 +0000
Subject: Re: socket.h
Lee Crites writes:
> On Wed, 20 Nov 1996, Bill Fenner wrote:
> > I'd strongly reccommend "Unix Network Programming", by Richard Stevens, as
> > a reference for networking programs like this.
>
> I'm *very* glad to see this reference given.
In which case you'll probably be overjoyed with this URL
http://www.noao.edu/~rstevens/
All sorts of useful information from the man himself.
N
- --
- --+=[ Blueberry Hill Blueberry New Media ]=+--
- --+=[ http://www.blueberry.co.uk/ 1/9 Chelsea Harbour Design Centre, ]=+--
- --+=[ WebMaster@blueberry.co.uk London, England, SW10 0XE ]=+--
- --+=[ Ten-Thousand-Dimensional Web in Heaven and Net on Earth ]ENTP
------------------------------
From: Steven Wallace <swallace@ece.uci.edu>
Date: Thu, 21 Nov 1996 10:55:36 -0800
Subject: Pentium Pro status
I wanted some input regarding Pentium Pro machines.
Has anyone had any problems with the hardware and/or using it with
FreeBSD?
Are there any problems with the PP chipset(is the latest Orion II or something?)
I remember hearing about PCI problems with the chipset. Someone
told me they still have problems in orion II. Is this true?
What motherboards for Pentium Pro are good and reliable?
What about multiprocessor support? Does anyone have FreeBSD hacks to
support multiple processors? How well is it working?
Thank you,
Steven Wallace
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 12:47:18 -0700 (MST)
Subject: Re: WordPerfect 7.0 for FreeBSD :-)
> Second, what you should tell Coral to do is send us a copy of the
> Linux version and we'll try to certify it for use under FreeBSD. I
> don't think that Coral should be pushed to do a FreeBSD version until
> we have a better idea of the size of our market since pushing them to
> do a port and then seeing it sell badly would be worse than no port at
> all. It would only screw us for a second chance.
>
> I would be happy if vendors with Linux versions of their products
> would give us a chance at certifying it under the emulator and,
> if it works, listing it as supported under FreeBSD as well (we
> will also have to improve our Linux library support, but that
> would be a natural side-effect of the certification process also).
More important, FreeBSD'ers who buy Linux products to run on FreeBSD
should make it clear to the people that are selling the products that
they intend to run them on FreeBSD.
The only real "certification process" that has any meaning is the port
validation the manufacturer does following a port prior to release;
anything you do short of that will not gain you someone to talk to
when you call their support department with a problem.
Notifying them of your intent to use the product under FreeBSD should
encourage them to run certification by informing them there is a
market, and possibly even encourage them to do a native port. If
each FreeBSD sale counts as a false Linux sale, then FreeBSD will be
proportionately less desirable a port in the ratio (k1 + n) : (k2 - n).
Since k1 was enough for a Linux port, making sure the numbers reflect
reality will only help FreeBSD, not hurt Linux. A marketing decision
is only as good as the information you give it.
I suspect that there are enough FreeBSD users of Linux Mathematica (a
heavily discussed topic at various times) to make it worthwhile to
have a native port. I'm sure this is true for some of the software
running under IBCS2 as well (Informix or one of the other databases,
especially).
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Jaye Mathisen <mrcpu@cdsnet.net>
Date: Thu, 21 Nov 1996 12:15:12 -0800 (PST)
Subject: Re: Disk Striping
Uh, by definition, isn't striping spreading the load across spindles?
I realize it's a tad more complicated than that, but the essence is the
same.
On Thu, 21 Nov 1996, michael butler wrote:
> Date: Thu, 21 Nov 1996 14:51:56 +1100 (EST)
> From: michael butler <imb@scgt.oz.au>
> To: "Darrin R. Woods" <dwoods@netgazer.com>
> Cc: hackers@freebsd.org
> Subject: Re: Disk Striping
>
> Darrin R. Woods writes:
>
> > I just got my news server up and running INN (thanks to everyone that
> > helped), but now I'm looking for a better way of dealing with it. I've got
> > 3 Fast/Wide 4gb disks to hold news. It would be a lot easier (and better
> > performance) if I could stripe (or span) the /var partition accross the 3
> > disks instead of having to guess as to how to partition each drive and into
> > what sizes.
>
> With "only" three drives, you don't want to stripe across them.
>
> There are four activities which consume disk resources:
>
> i) maintenance of the active and history files
> ii) maintenance of the overview hierarchy
> iii) writing out the articles themselves
> iv) scribbling to /var/log/news
>
> Whilst the latter is comparatively "cheap" as it simply extends an existing
> file (writes deferred by caching), the first three are best spread across
> separate spindles for the best resultant performance. Striping or
> concatenation will hurt more than help,
>
> michael
>
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 13:00:51 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> I think that there's a very important line to be drawn between "I
> don't think I need it in the system" and "It should not be in the
> system".
>
> The former is fine, and probably applies to a lot of people. Then
> again, it can also be applied to 90% of the system for 90% of users -
> the point being that when you aggregate everything that people
> want/need, you cover prettymuch everything.
>
> My point is that there are a sufficient number of people that consider
> Perl a 'should-have' to justify its inclusion on those grounds.
[ ... ]
> I'm still open to argument on this; I just haven't heard a counter
> that holds up under scrutiny.
How about "because no important system component depends on it"?
My main argument against inclusion of additional software in the same
class as PERL ("foundation sotware upon which layered components are
built") has been that it increases the complexity of the dependency
graph.
Over time, if a tool exists, people will use it to create expedient
(not necessarily "optimal", not necessarily "elegant", but not
necessarily "incorrect", either) soloutions to problems.
If these soloutions adddress *real* problems, then you have created
a dependency, and damaged the ability to create a "minimal system"
without the additional software on which the tool is layered.
You can think of this as an argument for a tools environment
"microkernel", if you insist on an analogy.
This is why I argue against TCL scripts.
It's why I argue against bash-specific shell scripts, like "configure".
It's why I argue against non-bmaked source inclusions, which would add
a dependency on GNU make.
This is *not* a "bloat/anti-bloat" argument. It is a complexity
argument.
I have absolutely no problem with an "admin tools" package requiring
"perl component", and installing PERL as part of the install of the
tools package.
But encouraging an increase of complexity in the "minimal system you
can create" is, IMO, a bad idea.
Regards,
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 13:09:31 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> It's not a question of whether _everyone_ needs it, but whether a
> sufficient number of people need it. I think that so far the evidence
> indicates that this is the case.
Not _everyone_ needs an appendectomy.
But perhaps a _suficient_ number of people need them, so we should
remove everyone's appendix at age 6.
> I'm entirely in agreement with the basic principle, but I strongly
> believe that we need to incorporate mature and ubiquitous tools in
> as seamless and standard a fashion as possible.
This is a different argument entirely... it is a complaint that the
installation dependency process is insufficiently seamless.
Whether it is or not is less important than the fact that if you
wish to add layered dependencies (like PERL) for service extension,
it is the responsibility of the peple doing the adding to fix the
tools so that the added services appear to be standard system
components.
This is an issue in layered software installation, not an issue of
"system services which should be standard".
No one is arguing that PERL should not *seem standard* for those
packages/ports which depend on it, only that the *seeming* and the
*being* should remain seperate.
Regards,
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Richard Wackerbarth <rkw@dataplex.net>
Date: Thu, 21 Nov 1996 14:29:20 -0600
Subject: Re: New mailing list - CVS-Alert???
>Hello,
>
>I would like to propose a new mailing list. It would be called cvs-alert
>and wuold be for those times that someone makes a commit that requires
>either massive changes to way something is done or re-compiles
>of programs.
>
>Lets face it, when someone is getting all of the lists or a large sub-portion
>it can be hard to catch little messages at the end of commits telling
>you to do this or that.
>
>Yea or Nay?
Nay .. I thought that was one of the purposes of "current" and "stable".
Whether it is a separate list of not, the value relies heavily on the
committer posting a message. That IMHO is the present weak link. Another
list would not help.
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 13:20:48 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> So, for me perl is needed and sed/awk (and even sh) could go
> away. Perl does it all much better. (Implicitly invoke your own smiley
> before getting wound up about this, though I am essentially serious, I
> never use any of the above any more and it's been quite a few years
> since I worked on a system that didn't have perl).
Actually, you use sh to run /etc/rc* each time you boot. It is a
minimal system component, mostly because the data and the procedure
for system startup have not been sufficiently abstracted. If they
had, you could replace the startup procedure with a binary and throw
/bin/sh away.
This is assuming you replace system components in /etc, /bin, and so
on with non-shell-script versions.
I have been arguing loudly for each change I see which moves the
system in the direction of seperating procedure from the data on which
it acts, and will continue to do so for the forseeable future.
> I've always felt that we should have a modular install mechanism like
> Sun used to have in 4.1.3 (not sure about Solaris, never installed it
> personally). Each module was self contained, there was a base system
> and then you added things like the man module, which included all the
> man binaries and the pages. We could have perl module, which included
> perl and all the perl scripts. As long as the scripts are something
> can be left out (which currently they could be) then that'd work. If
> you could live without the adduser script etc then you wouldn't need
> to install that module.
Or SCO Xenix, the end-all, be-all of install dependency graph reduction.
...
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Poul-Henning Kamp <phk@critter.tfs.com>
Date: Thu, 21 Nov 1996 21:45:06 +0100
Subject: ft/QIC/Travan support
We have a pretty out of date driver for QIC tapes.
Anybody interested in improving it ?
- --
Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox.
whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc.
Future will arrive by its own means, progress not so.
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 13:32:44 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> Am I hearing a volounteer here ??
>
> The reason I am picky about what goes in and what does not, is simply
> that core is the entity that is going to get blamed/flamed/kicked when
> things are not up to snuff. There is only so much we can have on
> our platters, if things are not going to melt down. I (me personally)
> think we have reached if not exceeded that limit allready, and getting
> even more things into the game, be it small things or huge systems
> need a _LOT_ of consideration.
> What we should do is delegate _RESPONSIBILITY_ of certain areas of
> the system (ports is sortof allready delegated) to individuals or
> groups that take this _SERIOUSLY_ and does a job at it.
> Now the problem is to find these individuals or groups, as each
> time it gets to that, all of a sudden NOBODY is left of the
> horde that screamed for some or other feature.
[ ... ]
> Am I hearing a volounteer here ??
> or is there silence again this time ??
I volunteer (again) to fix the VFS.
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Snob Art Genre <ben@narcissus.ml.org>
Date: Wed, 20 Nov 1996 12:54:07 -0800 (PST)
Subject: Re: Pentium Pro status
On Thu, 21 Nov 1996, Steven Wallace wrote:
>
> I wanted some input regarding Pentium Pro machines.
> Has anyone had any problems with the hardware and/or using it with
> FreeBSD?
>
> Are there any problems with the PP chipset(is the latest Orion II or something?)
> I remember hearing about PCI problems with the chipset. Someone
> told me they still have problems in orion II. Is this true?
>
> What motherboards for Pentium Pro are good and reliable?
>
> What about multiprocessor support? Does anyone have FreeBSD hacks to
> support multiple processors? How well is it working?
>
> Thank you,
>
> Steven Wallace
I'm using a PPro-200 with the 440FX chipset, I don't remember its
nickname. I've had no problems with it at all.
Ben
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 13:46:01 -0700 (MST)
Subject: Re: Who needs Perl? We do!
In reply to sos@FreeBSD.org who wrote:
> In reply to Richard Wackerbarth who wrote:
> >
> > >Am I hearing a volounteer here ??
> > > or is there silence again this time ??
> >
> > I suggest that you reconsider your (core) willingness to delegate.
> > I AM doing some chores which, I assure you, some of the "customers"
> > consider important.
>
> You are ??
>
> > I HAVE volounteered to take on some things and been rebuffed in my
> > efforts.
>
> Really, maybe what you wanted to do, wasn't what needed to be done ??
Actually, given your previous statement:
| The reason I am picky about what goes in and what does not, is simply
| that core is the entity that is going to get blamed/flamed/kicked when
| things are not up to snuff. There is only so much we can have on
| our platters, if things are not going to melt down. I (me personally)
| think we have reached if not exceeded that limit allready, and getting
| even more things into the game, be it small things or huge systems
| need a _LOT_ of consideration.
There is too much "damage control" and too little "consideration" taking
place for an unbiased conclusion that what Richard volunteered to do
"wasn't what needed to be done".
> No, I'm not, core is big enough allready, but we need core to be more
> of a governing/directionshowing entity, instead of a poor workhorse..
> Like it or not, there has to be rules (like in the real world out
> there), and they should be followed. If we have X developers working
> in Y different directions, we have lost the game. So if one want's
> to participate, one has to follow the rules, simple as that...
Be careful that in elevating the process to this level, you do not
make the process into the product. Process is a tool, not a boundry...
it seems to me that you are using it as a brake to thwart an increase
in complexity, when in fact the complexity is an artifact of the
process. If the process did not require single-threading through a
non-reentrant "need a _LOT_ of consideration" mutex, I think you
would get a much higher concurrency. The Linux process is an example
of one with a higher concurrency, though I think it is also hitting
its sociological and architectural limits. It just happens that
Linux's limits are about 10 times further out than FreeBSD's because
of their difference in process. Not that FreeBSD can elect a godlike
Linus of their own, and get all the lieutenants to swear fealty to his
vision... that's simply not an organization option because of the way
organizations evolve.
On the other hand, I can build a complex system, like a grandfather clock,
put it in place, and with one motion cause it to operate. I don't need
to replace my water clock one gear at a time, only using gears which fit
the old water clock, thus limiting my ability to build the best grandfather
clock I can build.
There is something to be said for revolution instead of evolution when
you are attempting to build an organization to use as a vehicle to get
you to a goal.
Regards,
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
End of hackers-digest V1 #1665
******************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261703_MC1-BC4-D83C>