[TUHS] Less -- was Termcap vs terminfo

[Clem Cole]

Brantley/Doug - I think you might be amused (or maybe disgusted) when the
3B2 came out.  I pointed out to Dennis that the bootloader was multiple
times of the size of 6th edition kernel and not nearly as easy to
understand.

Indeed, I agree that Pike's railing in "*cat -v considered harmful*" was a
telltale of bad things.  I always thought that many of my siblings at UCB
had lost the spirit of "UNIX Philosophy" of a "single small program doing
one job well" when the Vax "fixed" the address issues of the PDP-11.  It
allowed for sloppiness and programs grew without thought or bound.

Doug, while you describe "less" as the an example of decadence, I think a
better example of same is sendmail.    I have always said that if Eric had
left the SMTPD as a separate program (which is what is was when the TCP/IP
support came to UCB from BBN); sendmail would never have become what it
did.   The primary issue of header rewriting was not something most sites
had issues like UCB did - they just needed an SMTP interface and sendmail
was the SMTPD for 4.3BSD.  So sites picked it up because of that.

Clem

On Sun, Jan 11, 2015 at 2:40 PM, Brantley Coile <brantleycoile at me.com>
wrote:

>
> On Jan 11, 2015, at 12:20 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> >> when you - say - run less to display a file, it switches to a dedicated
> >> region in the terminal memory buffer while printing its output, then
> >> restores the buffer to back where you were to begin with when you exit
> >> the pager
> >
> > Sorry for veering away from Unix history, but this pushed one of the
> hottest
> > of my buttons. Less is the epitome of modern Unix decadence. Besides the
> > maddening behavior described above, why, when all screens have a scroll
> bar,
> > should a pager do its own scrolling? But for a quantitative measure of
> > decadence, try less --help | wc. It takes excess to a level not dreamed
> of
> > in Pike's classic critique, "cat -v considered harmful".
> >
> > Doug
>
> I couldn’t agree with you more, Doug.  That’s why I started my new
> company, South Suite Software.  I want to re-evolve the software on the
> server side.
>
> Besides “man less | wc -l”, there is the following.
>
> - A man of gcc produces more lines than was in Dennis’ 7th Edition
> compiler.
>
> - The number bytes in the C compiler clang's object file on my machine is
> 37,810,480, yet the compiler I use to build our software, Ken Thompson’s C
> from Plan 9, is 280,764 bytes.
>
> - Kernels now measure in the millions of lines.  Even with the various
> device drivers removed from a recent Linux kernel, almost a million lines
> remain.
>
> - The recently hacked NTP protocol weights in at over 200,000 lines.
>
> I could go on.
>
> When Coraid’s management decided to change the base operating system from
> Plan 9 to Solaris, I decided it was time to start a new company dedicated
> to the re-evolution of the system software used in the back end machine
> rooms of the Internet.
>
> I say re-evolution, because the existing code base has accretions that a
> software archeologist could use to study all the problems faced by system
> software since the 1960’s.  Each solution to a temporal problem has been
> entombed in all the code going forward.  Paging in from disk is a good
> example.  The Atlas invented paging to overcome a dearth of local memory by
> swapping out to a magnetic drum.  Today, when an average instruction
> executes in 600 picoseconds, it seems untenable to fetch 4096 bytes from a
> disk in 6,000,000,000 picoseconds.  Most of the code in current Unix-like
> systems still have code that solves problems like this that we no longer
> have.
>
> And the consequences of the current code growth has real ramifications on
> everyone.  The continued improvement in quality of life has always depended
> on advancements of technology that lowered the cost of production.  Thanks
> to Moore’s law, system software has had a free lunch for twenty-five
> years.  Now that free lunch room is closed.  Six years ago Gordon Moore
> said there was two, maybe three Moore cycles left.  Things have gotten so
> small that quantum affects are beginning to dominate.  Intel, reportedly,
> has had problem getting satisfactory 14nm technology yields.  Silicon
> capital equipment manufacturers have halted development on equipment to
> produce larger wafers.  Moore’s law will no longer lower the cost of a unit
> of compute.
>
> In addition, it’s obvious from history that the larger the code is the
> more buggy it is.  Not only is reliably an issue, but so is security.
> Security is compromised by exploiting a class of bugs.  So, if the code is
> larger, and the number of bugs is more, it follows that the number of
> security bugs is also greater.  At one of my previous companies I built the
> PIX Firewall, later sold to Cisco, which was only about 50,000 bytes.  It’s
> simplicity, at least at the time I was involved with it, made it very
> secure.
>
> So now I have started South Suite to produce software that, when added to
> white box hardware, creates easy to deploy, highly efficient, high
> performance appliances at a significantly lower cost.  We are re-evoloving
> system software, skipping all the intermediate steps that are encased in
> all other solutions.  We are doing it in the same culture, the same value
> system, that was at Bell Labs center 1127 and gave us these wonderful
> versions of Unix we all enjoy learning from.  We are even using Bell Labs
> tools from Plan 9 to re-invent the back end server room as if we were back
> at the labs, starting over.
>
> I share the frustration with modern Unix some have expressed on this
> list.  And I’m trying to do something about it.  We on this list are lucky
> enough to know versions of Unix that were simple, clear, general and very,
> very effective.  The performance they extracted from the modest PDP-11
> hardware was amazing.  In whatever way the readers of this list can, we
> should all bring this kind of values to the programming we do.  Together it
> can have a huge affect on the quality of life for everyone.
>
> Thanks for being a part of giving birth to that legacy, Doug.
>
> Thanks everyone for listening to my rant.
>
> Brantley Coile
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/319422f8/attachment.html>