From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8f7f959101c16201a81884c7ffa3e205@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] design clairvoyance & the 9 way From: Geoff Collyer In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 8 May 2003 18:12:40 -0700 Topicbox-Message-UUID: a58d77ae-eacb-11e9-9e20-41e7f4b1d025 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() )