Re: Adding a 'D - date' option in 'cat'

From: Bill Vermillion <bv_at_wjv.com>
Date: Thu, 7 Sep 2006 12:23:25 -0400
On Thu, Sep 07, 2006 at 12:00 ,
freebsd-current-request_at_freebsd.org moved his mouse, rebooted for
the change to take effect, and then said:

> Date: Thu, 7 Sep 2006 01:08:18 -0400
> From: Garance A Drosihn <drosih_at_rpi.edu>
> To: bv_at_wjv.com, freebsd-current_at_freebsd.org

> At 11:09 PM -0400 9/6/06, Bill Vermillion wrote:

> >That's pretty much the basic Unix philosophy - a lot of small
> >programs that can be chained together to do almost anything you can
> >imagine, instead of putting all the POSSIBLE needed options into
> >each program that MAY or MAY NOT need it.

> Well, the proposed option to `cat' is already dead, but just
> as an aside:

Good - from my POV.

> Notice what happens when some issue like this comes up.  The
> unix philosophy is supposedly to champion lots of small utility
> programs.  An issue like Julian's comes up, where no *small*,
> well-designed utility can get the job done.  What does everyone
> suggest?  Why, "Just load up a turing-complete multi-megabyte
> executable like Perl [which FreeBSD won't even include in the
> base OS because it's too much of a hassle], and then write/debug
> your own perl script which can handle your job!".

Perl was taken out for good reason - and was documented as to why.
It just grew and grew and grew until it was truly bloated.  Many of
the scripts used to compile/install FBSD used Perl, and those were
all re-written to be shell scripts.   I've installed BSD on very
small machines - basically used as firewalls - and Perl was
absolutely NOT NEEDED.  Putting a sysmlink from /usr/bin/bin
pointing to /usr/local/bin/[current Perl version] was a good idea,
and this way and the /usr/local/bin/use.perl let you choose which
one to use.

> Uh, perl is not a small utility program.  The fact is that unix
> doesn't really deliver on it's own philosophy.  Unix wizards
> constantly punt user questions off to *massive* programs which
> have a billion options.  There is something very inconsistent
> in that.

I don't see that.  But then again I moved to Unix in 1983 - and got
away from all the bloat and crap that others but in their OSes.
And my first contact with BSD type systems was in NeXTStep - which
had a lot of BSD in it - and when running at a command line it was
just like BSD for the most part.

And after spending many years supporting Unix [not BSD] System III
[and one earlier] and System V.X environment, I've come to truly
appreicate the lean-ness of FreeBSD and it's consistant design
philoophy - which >usually< follows the man 7 hier quite well.

The last Sys V.x system I worked on daily - with sometimes long
hours - were a small amount of SGIs for an ISP years ago.  

We moved from IRIX to FreeBSD 2.7 [or some nearby version] on Intel
chips that were clocked slower than the RISC chips on the SGIs,
and from the Netscape Web Servers to Apache and found drastic
performance improvement. 

Not everyone needs a system with all the bells-and-whistles ever
invented and many want a sysstem that can be made small and compact
and eliminate things not needed.  That last small BSD I installed
was on an 800MB drive that left me 400MB user space.   So many
other OSes just give up when given something that small.

I'm not a Unix guru - but have been working with it long enough as
a system-admin-for-hir to appreciate the lean-and-mean approach.
And as an aside the kernel in a server I'm just building up
with 6.1-RELEASE has a kernel that is larger than the total
distribution of my first Unix based system - a Xenix system on
a 68000. That was so BSD like [an early Xenix] that when you
compiled thins from places such as alt.sources.unix all you had to
do was specify the system as CSRG compliant and all went well.

Bill

-- 
Bill Vermillion - bv _at_ wjv . com
Received on Thu Sep 07 2006 - 14:23:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC