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

On Jan 11, 2015, at 12:20 AM, Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: hottest bar, of 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(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

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=tm… 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.