On Jan 11, 2015, at 12:20 AM, Doug McIlroy <doug(a)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