Re: [9fans] design clairvoyance & the 9 way

[Geoff Collyer <geoff@collyer.net>]

This is a somewhat rambling discussion, but I'll throw in my 2 cents
on several, perhaps related, topics.

The conventional monolithic, one-machine-does-it-all `desktop' PC
already seems like a throwback to 1960's mainframe (S/360) thinking
(except that pre-XA 370s were too small to run Netscape!).  Laptops,
PDAs, ipaqs, ipods, and increasing use of wireless technologies
suggest that `the future of the desktop PC' may not matter a great
deal.

30 years ago it looked like we'd never be rid of the IBM 360/370
architecture and accompanying IBM software.  It's still with us, but
isn't the plague on computing it once was.  20 years ago, one could
say ``All the world's a VAX'' with a straight face; no more.  15 years
ago, one could say ``All the world's a Sun'' with a straight face; no
more.  All the world may look like an x86 PC today, but This Too Shall
Pass.  And that's ignoring the embedded-systems market: the software
in your printer, router, firewall, wireless widget, and perhaps your
car is almost certainly not Windows 2000 and the processor is likely a
MIPS or ARM chip or 68000 ASIC, not an x86.  So far, at least, in the
history of computing, no single architecture dominates forever (it
just seems that way).

I'm not sure what advantage one could obtain from an
`architecture-dependent' kernel.  There might be a slight performance
gain, but given the speed, and rate of increase, of modern processors,
who cares?  Wait a week or a month and you can buy the performance
gain without changing any code.  A kernel dedicated to a single
architecture would likely be less clean than one intended for broader
use, and the history of manufacturers' operating systems dedicated to
particular architectures isn't encouraging; these systems tended to be
strangely designed (to be polite) and lacking in function, which isn't
too surprising, since they existed mainly to sell hardware, and so had
to be just good enough to help sell machines.

There are other reasons than raw computing power to want multiple
processors.  The one I like best is the ability to absorb load while
remaining responsive.  An MP terminal holds up under load.  If you've
ever used a Unix workstation running X, you've probably seen the
machine ignore your mouse movements and keystrokes when it gets busy.
Plan 9 terminals are less prone to this, but with an extra processor,
it virtually never happens.  MP cpu servers are pleasant places to do
heavy work since they too degrade gracefully under load.

Furthermore, the supposed complexity in Plan 9 due to support for
multiprocessing seems to be mainly getting locking right, which is
worth doing even with just one processor.  I don't believe that we pay
a huge cost in code complexity or performance for SMP support.

Central file storage simplifies backup and retrieval.  The more places
you have files stored, the more care it takes to ensure that they are
really getting backed up, and the more places you may have to look
when you can't remember where you stored something.  Of course, google
now sells an appliance to index and search one's files...

I suspect that programmer ability matters more than choice of
language.  I've been looking at an MP3 decoder.  It's 8,000
non-comment lines of C, many of them duplicated (dup -t1 reports that
26% of the source is redundant).  Functions ramble on for hundreds of
lines.  The code is littered with unexplained magic numbers.  None of
this is encouraged by C: functions are easy to write and cheap to
call; enum or even #define provide easy ways to declare manifest
constants.  (For sheer humour value, though, one has to look to
sendmail:

; funclen *.c | sort -nr | sed 20q
2627	main.c:152,2779	main()
2510	srvrsmtp.c:338,2848	smtp()
2301	deliver.c:1251,3552	deliver()
1468	readcf.c:2130,3598	setoption()
782	daemon.c:147,929	getrequests()
754	daemon.c:2010,2764	makeconnection()
746	map.c:4066,4812	ldapmap_parseargs()
712	deliver.c:70,782	sendall()
673	queue.c:3783,4456	readqf()
661	recipient.c:444,1105	recipient()
620	parseaddr.c:941,1561	rewrite()
590	savemail.c:760,1350	errbody()
588	queue.c:322,910	queueup()
583	collect.c:289,872	collect()
575	readcf.c:88,663	readcf()
571	mime.c:99,670	mime8to7()
538	deliver.c:4988,5526	mailfile()
533	milter.c:564,1097	milter_open()
513	queue.c:1738,2251	run_work_group()
502	deliver.c:4444,4946	putbody()
)