From mboxrd@z Thu Jan 1 00:00:00 1970 From: clemc@ccc.com (Clem Cole) Date: Mon, 12 Jan 2015 10:32:47 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: 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 wrote: > > On Jan 11, 2015, at 12:20 AM, Doug McIlroy 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: