[TUHS] Less -- was Termcap vs terminfo

[TUHS] Less -- was Termcap vs terminfo

[Doug McIlroy]

> 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

[TUHS] Less -- was Termcap vs terminfo

[Jacob Ritorto]

>
> Less is the epitome of modern Unix decadence.


agree


> Besides the
> maddening behavior described above, why, when all screens have a scroll
> bar,
> should a pager do its own scrolling?


in lieu of X scrollbars, there's also terminal multiplexers like tmux or
screen.  Also, there's the case of working directly on a character cell
terminal or console (rare these days, I admit, but I still do it frequently
enough to occasionally get caught without a scrollback buffer and lose
important stuff).  Hence my use of tmux et al..

So, yeah, agree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150111/9e46e5e8/attachment.html>

[TUHS] Less -- was Termcap vs terminfo

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4912 bytes --]


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] Less -- was Termcap vs terminfo

[Dave Horsfall]

On Sun, 11 Jan 2015, Brantley Coile wrote:

> We are re-evoloving system software [...]

I know it was a typo, but I still like it :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] Less -- was Termcap vs terminfo

[Brantley Coile]

:)

And I guess we evo love it again, too.  :)

Sent from my iPad

> On Jan 11, 2015, at 4:27 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Sun, 11 Jan 2015, Brantley Coile wrote:
>> 
>> We are re-evoloving system software [...]
> 
> I know it was a typo, but I still like it :-)
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] Less -- was Termcap vs terminfo

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6587 bytes --]

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>

[TUHS] Less -- was Termcap vs terminfo

[random832]

On Sun, Jan 11, 2015, at 00:20, Doug McIlroy wrote:
> 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?

The console screen doesn't, and the one in an emulator can't be
controlled by the pager. The real question is why a pager should be
executed at all in an xterm. Except xterm has no ability to search in
scrollback, and its buffer may not be large enough for some very large
manpages.

[TUHS] Less -- was Termcap vs terminfo

[Jacob Ritorto]

On Mon, Jan 12, 2015 at 2:38 PM, <random832 at fastmail.us> wrote:

>
>
> On Sun, Jan 11, 2015, at 00:20, Doug McIlroy wrote:
> The console screen doesn't, and the one in an emulator can't be
> controlled by the pager. The real question is why a pager should be
> executed at all in an xterm. Except xterm has no ability to search in
> scrollback, and its buffer may not be large enough for some very large
> manpages.


srsly, this is why we have tmux.  or even good old screen, in a pinch.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1

each program small and good at its one own thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/56648ae7/attachment.html>

[TUHS] Less -- was Termcap vs terminfo

[cowan]

> each program small and good at its one own thing.

I don't think it's sensible to apply this dictum to editors and viewers.
We don't, for example, have separate programs for inserting text, deleting
text, replacing text, scrolling a view up, scrolling a view down, and so
on.  Less is really a sort of ed without the ability to modify its buffer.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Some people open all the Windows; wise wives welcome the spring by moving
the Unix.  --Advertisement for Unix Book Units (U.K.)
(see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif)

[TUHS] Less -- was Termcap vs terminfo

[Kurt H Maier]

Quoting Jacob Ritorto <jacob.ritorto at gmail.com>:

>
> srsly, this is why we have tmux.  or even good old screen, in a pinch.
>
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1
>
> each program small and good at its one own thing.

If the "one thing" is "fix the broken design of another program" it's often
a better idea to just fix the original program.

khm

[TUHS] Less -- was Termcap vs terminfo

[random832]

On Mon, Jan 12, 2015, at 14:44, Jacob Ritorto wrote:
> srsly, this is why we have tmux.  or even good old screen, in a pinch.
> 
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1
> 
> each program small and good at its one own thing.

In principle, the functions "detachable terminal session", "terminal
session multiplexer", and "terminal with scrollback", and "translator
from a common VT100 superset to whatever the hell the user is using"
could be four separate programs.

[TUHS] Less -- was Termcap vs terminfo

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Mon, Jan 12, 2015 at 3:34 PM, <random832 at fastmail.us> wrote:
>
>
> In principle, the functions "detachable terminal session", "terminal
> session multiplexer", and "terminal with scrollback", and "translator
> from a common VT100 superset to whatever the hell the user is using"
> could be four separate programs.



​To quote Rob and Brian from the "cat -v" paper: [
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf]

​

Separate programs are not always better than wider options; which is better
depends on the problem.
Whenever one needs a way to perform a new function, one faces the choice of
whether to add a new option
or write a new program (assuming that none of the programmable tools will
do the job conveniently). The
guiding principle for making the choice should be that each program does
one thing. Options are appropriately
added to a program that already has the right functionality. If there is no
such program, then a new
program is called for. In that case, the usual criteria for program design
should be used: the program should
be as general as possible, its default behavior should match the most
common usage, and it should cooperate
with other programs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/fb4d7542/attachment.html>

[TUHS] Less -- was Termcap vs terminfo

[Jacob Ritorto]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

Just noticed that Garrett is doing things to less.  Maybe talk to him?
http://garrett.damore.org/2014/09/modernizing-less.html
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150114/f08e42cf/attachment.html>