Andy Tanenbaum hasn't learned anything Subject: Andy Tanenbaum hasn't learned anything From: rob@alice.att.com (research!rob) Date: 6 Apr 92 20:06:28 GMT Approved: comp-os-research@ftp.cse.ucsc.edu Newsgroups: comp.os.research Organization: AT&T, Bell Labs Sender: usenet@darkstar.ucsc.edu The implementers of Plan 9 are baffled by Andy Tanenbaum's recent posting. We suspect we are not representative of the mainline view, but we disagree at some level with most of the "GENERALLY ACCEPTED" truths Andy claims. Point by point: - The client-server paradigm is a good one Too vague to be a statement. "Good" is undefined. - Microkernels are the way to go False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance. - UNIX can be successfully run as an application program `Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application. - RPC is a good idea to base your system on Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expect every application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive. - Atomic group communication (broadcast) is highly useful Perhaps. We've never used it or felt the need for it. - Caching at the file server is definitely worth doing True, but caching anywhere is worthwhile. This statement is like saying 'good algorithms are worth using.' - File server replication is an idea whose time has come Perhaps. Simple hardware solutions like disk mirroring solve a lot of the reliability problems much more easily. Also, at least in a stable world, keeping your file server up is a better way to solve the problem. - Message passing is too primitive for application programmers to use False. - Synchronous (blocking) communication is easier to use than asynchronous They solve different problems. It's pointless to make the distinction based on ease of use. Make the distinction based on which you need. - New languages are needed for writing distributed/parallel applications `Needed', no. `Helpful', perhaps. The jury's still out. - Distributed shared memory in one form or another is a convenient model Convenient for whom? This one baffles us: distributed shared memory is a lousy model for building systems, yet everyone seems to be doing it. (Try to find a PhD this year on a different topic.) How about the "CONTROVERSIAL" points? We should weigh in there, too: - Client caching is a good idea in a system where there are many more nodes than users, and users do not have a "home" machine (e.g., hypercubes) What? - Atomic transactions are worth the overhead Worth the overhead to whom? - Causal ordering for group communication is good enough We don't use group communication, so we don't know. - Threads should be managed by the kernel, not in user space Better: have a decent process model and avoid this process/thread dichotomy. Rob Pike Dave Presotto Ken Thompson Phil Winterbottom

Andy Tanenbaum hasn't learned anything Subject: Andy Tanenbaum hasn't learned anything From: rob@alice.att.com (research!rob) Date: 6 Apr 92 20:06:28 GMT Approved: comp-os-research@ftp.cse.ucsc.edu Newsgroups: comp.os.research Organization: AT&T, Bell Labs Sender: usenet@darkstar.ucsc.edu The implementers of Plan 9 are baffled by Andy Tanenbaum's recent posting. We suspect we are not representative of the mainline view, but we disagree at some level with most of the "GENERALLY ACCEPTED" truths Andy claims. Point by point: - The client-server paradigm is a good one Too vague to be a statement. "Good" is undefined. - Microkernels are the way to go False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance. - UNIX can be successfully run as an application program `Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application. - RPC is a good idea to base your system on Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expect every application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive. - Atomic group communication (broadcast) is highly useful Perhaps. We've never used it or felt the need for it. - Caching at the file server is definitely worth doing True, but caching anywhere is worthwhile. This statement is like saying 'good algorithms are worth using.' - File server replication is an idea whose time has come Perhaps. Simple hardware solutions like disk mirroring solve a lot of the reliability problems much more easily. Also, at least in a stable world, keeping your file server up is a better way to solve the problem. - Message passing is too primitive for application programmers to use False. - Synchronous (blocking) communication is easier to use than asynchronous They solve different problems. It's pointless to make the distinction based on ease of use. Make the distinction based on which you need. - New languages are needed for writing distributed/parallel applications `Needed', no. `Helpful', perhaps. The jury's still out. - Distributed shared memory in one form or another is a convenient model Convenient for whom? This one baffles us: distributed shared memory is a lousy model for building systems, yet everyone seems to be doing it. (Try to find a PhD this year on a different topic.) How about the "CONTROVERSIAL" points? We should weigh in there, too: - Client caching is a good idea in a system where there are many more nodes than users, and users do not have a "home" machine (e.g., hypercubes) What? - Atomic transactions are worth the overhead Worth the overhead to whom? - Causal ordering for group communication is good enough We don't use group communication, so we don't know. - Threads should be managed by the kernel, not in user space Better: have a decent process model and avoid this process/thread dichotomy. Rob Pike Dave Presotto Ken Thompson Phil Winterbottom