---
created_at: '2015-03-08T14:41:36.000Z'
title: Operating system research – 16 years perspective (2008)
url: http://vyodaiken.com/2008/10/07/operating-system-research-14-years-perspective/
author: luu
points: 51
story_text: ''
comment_text: 
num_comments: 8
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1425825696
_tags:
- story
- author_luu
- story_9165700
objectID: '9165700'

---
[Source](http://vyodaiken.com/2008/10/07/operating-system-research-14-years-perspective/ "Permalink to Operating system research &#8211; 16 years perspective &#8211; keeping simple")

# Operating system research &#8211; 16 years perspective &#8211; keeping simple

[

![keeping simple][1]

# keeping simple

## [tech and business @vyodaiken on twitter][2]

* [Distributed consensus, paxos, raft, etc.][3]
* [Simulation of Paxos][4]
* [The RTLinux patent 5,995,745][5]
* [Practical State Machines][6]
* [Notes on Security and Common Criteria][7]
* [Download code][8]
* [Papers and talks][9]
    * [process algebras][10]

# Operating system research – 16 years perspective

Posted on October 7, 2008 by [yodaiken][11] in [academics][12], [operating systems][13] | 5 Comments

(links and dates fixed March 15 2015 – thanks to [Luu][14] and [pm90 ][15]at [news.y.combinator][16] for digging this up)

October 2008: It’s somewhat funny and somewhat sad to read [this thread][17] on the old USENET. Starting out with Andy Tanenbaum’s proposed list of accepted truths (most of which I thought wrong at the time)

> GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
> 
> * – The client-server paradigm is a good one
> * – Microkernels are the way to go
> * – UNIX can be successfully run as an application program
> * – RPC is a good idea to base your system on
> * – Atomic group communication (broadcast) is highly useful
> * – Caching at the file server is definitely worth doing
> * – File server replication is an idea whose time has come
> * – Message passing is too primitive for application programmers to use
> * – Synchronous (blocking) communication is easier to use than asynchronous
> * – New languages are needed for writing distributed/parallel applications
> * – Distributed shared memory in one form or another is a convenient model

and then [Rob Pike’s refutation][18] entitled “Andy Tanenbaum hasn’t learned anything”. A key point that comes up later in the discussion is Tanenbaum’s (incorrect) assertion that a “factor of two” performance loss is nothing to worry about. The date of the discussion is interesting, because in a few years the Linux Tsunami washed away most of the landscape of this discussion. As for my [contribution][19] it is very disturbing to see that I have not learned much about those topics in the last 14 <del>16</del> 23 years. (updated again in 2015)

It is clear that Rob Pike was right on many more issues than AST, but that seemed clear at the time too.

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

Distributed shared memory – an idea that never made any sense to me.

[edited to reflect the passage of time][ and again to add the Pike/Presott/Thompson/Winterbottom text]

* [ast][20]
* [micorkernels][21]
* [operating systems design][22]
* [os][23]
* [pike][24]
* [plan9][25]
* [tanenbaum][26]

←[ Previous post][27]

[Next post →][28]

#### 3 Comments on Operating system research – 16 years perspective

1. ![][29] dannyquist // [October 7, 2008 at 8:38 pm][30] // 

“most of which I thought wrong at the time”

Is that to say your opinion has changed? If so what to?

2. ![][31] admin // [October 8, 2008 at 7:45 am][32] // 

Nah, I’m just trying to take credit for being right back then and not needing to wait 14  
more years to see that e.g., microkernels were a silly idea.

3. ![][31] admin // [June 9, 2010 at 12:51 am][33] // 

This note has suddenly attracted a lot of attention – and there I thought OS research was over.

#### 2 Trackbacks & Pingbacks

1. [Bookmarks for March 8th from 13:03 to 16:25 : Extenuating Circumstances][34]
2. [Lazy Reading for 2015/03/15 – DragonFly BSD Digest][35]

Comments are closed.

#### Recent Posts

* [informal methods applied to networks and timeouts][36]
* [Current reading: meltdown and spectre edition][37]
* [Quicksort without pseudo code and building code against functional specifications][38]
* [Types considered harmful II][39]
* [Bad ideas in type theory][40]
* [Current reading August 2017][41]
* [The crackpot Google manifesto][42]
* [Google Manifesto shows that many programmers are bad at logic][43]
* [Sorting and groups][44]
* [C compiler developers are hostile to C programming][45]
* [Current reading: July 8 2017][46]
* [The C standard versus C and the mother of all hacks.][47]
* [The C standard committee effort to kill C continues][48]
* [Types considered harmful][49]
* [Basic math for basic algorithms][50]
* [undefined behavior and the purpose of C][51]
* [Computer Science as a scholarly discipline.][52]
* [Current reading][53]
* [Understanding Paxos and Distributed Consensus][54]
* [Chang-Maxemchuk atomic broadcast][55]

#### Pages

* [Distributed consensus, paxos, raft, etc.][3]
* [Simulation of Paxos][4]
* [The RTLinux patent 5,995,745][5]
* [Practical State Machines][6]
* [Notes on Security and Common Criteria][7]
* [Download code][8]
* [Papers and talks][9]
    * [process algebras][10]

#### tags

[apple][56] [automata][57] [big data][58] [computer science][59] [data center][60] [distributed consensus][61] [embedded][62] [fault tolerance][63] [formal methods][64] [free software][65] [google][66] [green computing][67] [ibm][68] [innovation][69] [intellectual property][70] [ip][71] [manufacturing][72] [modularity][73] [non-determinism][74] [ntp][75] [open source][76] [operating systems][77] [patents][78] [paxos][79] [processor architecture][80] [ptp][81] [real-time][82] [recursion][83] [software][84] [software engineering][85] [software patents][86] [software security][87] [specification][88] [state machines][89] [sun][90] [synchronization][91] [technology][92] [timekeeper][93] [timestamp][94] [time synchronization][95] [undefined behavior][96] [venture capital][97] [verification][98] [virtualization][99] [women in computer science][100]

#### Archives

Archives Select Month January 2018  (2) December 2017  (1) November 2017  (1) September 2017  (1) August 2017  (3) July 2017  (3) June 2017  (4) January 2017  (1) December 2016  (2) October 2016  (1) September 2016  (2) August 2016  (7) June 2016  (2) May 2016  (1) April 2016  (2) March 2016  (1) February 2016  (4) January 2016  (6) December 2015  (2) November 2015  (8) October 2015  (6) September 2015  (3) August 2015  (1) July 2015  (3) March 2015  (4) November 2014  (1) October 2014  (5) September 2014  (7) July 2014  (2) June 2014  (3) May 2014  (2) April 2014  (8) February 2014  (2) January 2014  (7) December 2013  (5) January 2013  (2) November 2012  (1) August 2012  (1) July 2012  (2) May 2012  (1) April 2012  (1) March 2012  (1) February 2012  (3) January 2012  (1) December 2011  (1) October 2011  (5) September 2011  (3) August 2011  (1) July 2011  (4) June 2011  (2) May 2011  (1) March 2011  (5) November 2010  (9) October 2010  (6) September 2010  (2) August 2010  (1) July 2010  (1) June 2010  (2) May 2010  (2) April 2010  (5) March 2010  (7) February 2010  (8) January 2010  (8) December 2009  (3) November 2009  (11) September 2009  (3) August 2009  (4) July 2009  (11) June 2009  (4) April 2009  (11) March 2009  (5) February 2009  (2) January 2009  (5) December 2008  (3) November 2008  (7) October 2008  (4) September 2008  (6) August 2008  (1) July 2008  (1) June 2008  (1) May 2008  (3) April 2008  (5) March 2008  (2) February 2008  (1) January 2008  (8) December 2007  (4) November 2007  (5) October 2007  (8) September 2007  (7) August 2007  (8) July 2007  (2) June 2007  (4) May 2007  (5) April 2007  (3) March 2007  (6) February 2007  (6) January 2007  (3) December 2006  (4) November 2006  (5) October 2006  (3) September 2006  (2) August 2006  (2) June 2006  (3) May 2006  (4) April 2006  (1) March 2006  (3) February 2006  (1) January 2006  (5) December 2005  (5) April 2005  (1) February 2005  (1) January 2005  (1) December 2004  (6)

#### Meta

* [Log in][101]
* [Entries RSS][102]
* [Comments RSS][103]
* [WordPress.org][104]

Copyright © 2018 | [MH Corporate basic by MH Themes][105]

[1]: http://www.yodaiken.com/wp-content/uploads/2016/10/cropped-gps2.png
[2]: http://www.yodaiken.com/ "keeping simple"
[3]: http://www.yodaiken.com/distributed-consensus-paxos-raft-etc/
[4]: http://www.yodaiken.com/paxos-simulation-horrible-lua-code-terribly-written-ugly-lua-code-that-simulates-paxos-multi-proposer-the-file-paxos-data-has-the-configuration-we-try-for-multiple-sizes-of-the-set-of-acc/
[5]: http://www.yodaiken.com/the-rtlinux-patent-5995745/
[6]: http://www.yodaiken.com/about/
[7]: http://www.yodaiken.com/notes-on-security-and-common-criteria/
[8]: http://www.yodaiken.com/download-code/
[9]: http://www.yodaiken.com/papers-and-talks/
[10]: http://www.yodaiken.com/papers-and-talks/failure-to-communicate-process-algebras-draft/
[11]: http://www.yodaiken.com/author/yodaiken/
[12]: http://www.yodaiken.com/category/academics/
[13]: http://www.yodaiken.com/category/systems/operating-systems/
[14]: https://news.ycombinator.com/user?id=luu "luu"
[15]: https://news.ycombinator.com/user?id=pm90 "pm90"
[16]: https://news.ycombinator.com/item?id=9165700
[17]: https://web.archive.org/web/20081220201639/http://fred.cambridge.ma.us/c.o.r.flame/msg00000.html
[18]: https://web.archive.org/web/20110816173017/http://fred.cambridge.ma.us/c.o.r.flame/msg00025.html
[19]: https://web.archive.org/web/20081218144848/http://fred.cambridge.ma.us/c.o.r.flame/msg00064.html
[20]: http://www.yodaiken.com/tag/ast/
[21]: http://www.yodaiken.com/tag/micorkernels/
[22]: http://www.yodaiken.com/tag/operating-systems-design/
[23]: http://www.yodaiken.com/tag/os/
[24]: http://www.yodaiken.com/tag/pike/
[25]: http://www.yodaiken.com/tag/plan9/
[26]: http://www.yodaiken.com/tag/tanenbaum/
[27]: http://www.yodaiken.com/2008/10/06/doing-business-with-avayas-bizzare-business-model/
[28]: http://www.yodaiken.com/2008/10/16/future-of-the-data-center/
[29]: http://0.gravatar.com/avatar/0fb5d171b11d89878351cdd7d5534506?s=30&d=mm&r=g
[30]: http://www.yodaiken.com/2008/10/07/operating-system-research-14-years-perspective/#comment-53
[31]: http://2.gravatar.com/avatar/e88cd4265ba1683ca92e5b9b46dee30c?s=30&d=mm&r=g
[32]: http://www.yodaiken.com/2008/10/07/operating-system-research-14-years-perspective/#comment-54
[33]: http://www.yodaiken.com/2008/10/07/operating-system-research-14-years-perspective/#comment-55
[34]: http://danhon.com/2015/03/08/bookmarks-for-march-8th-from-1303-to-1625/
[35]: http://www.dragonflydigest.com/2015/03/15/15717.html
[36]: http://www.yodaiken.com/2018/01/16/informal-methods-applied-to-networks-and-timeouts/
[37]: http://www.yodaiken.com/2018/01/04/current-reading-meltdown-and-spectre-edition/
[38]: http://www.yodaiken.com/2017/12/20/quicksort-without-pseudo-code/
[39]: http://www.yodaiken.com/2017/11/30/types-considered-harmful-ii/
[40]: http://www.yodaiken.com/2017/09/15/bad-ideas-in-type-theory/
[41]: http://www.yodaiken.com/2017/08/20/current-reading-august-2017/
[42]: http://www.yodaiken.com/2017/08/16/the-crackpot-google-manifesto/
[43]: http://www.yodaiken.com/2017/08/10/google-manifesto-shows-that-many-programmers-are-bad-at-logic/
[44]: http://www.yodaiken.com/2017/07/22/sorting-and-groups/
[45]: http://www.yodaiken.com/2017/07/17/c-compiler-developers-are-hostile-to-c-programming/
[46]: http://www.yodaiken.com/2017/07/08/current-reading-july-8-2017/
[47]: http://www.yodaiken.com/2017/06/26/the-c-standard-versus-c-and-the-mother-of-all-hacks/
[48]: http://www.yodaiken.com/2017/06/16/the-c-standard-committee-effort-to-kill-c-continues/
[49]: http://www.yodaiken.com/2017/06/10/types-considered-harmful/
[50]: http://www.yodaiken.com/2017/06/09/basic-math-for-basic-algorithms/
[51]: http://www.yodaiken.com/2017/01/05/undefined-behavior-and-the-purpose-of-c/
[52]: http://www.yodaiken.com/2016/12/22/computer-science-as-a-scholarly-discipline/
[53]: http://www.yodaiken.com/2016/12/08/current-reading/
[54]: http://www.yodaiken.com/2016/10/01/understanding-paxos-and-distributed-consensus/
[55]: http://www.yodaiken.com/2016/09/02/chang-maxemchuk-atomic-broadcast/
[56]: http://www.yodaiken.com/tag/apple/
[57]: http://www.yodaiken.com/tag/automata/
[58]: http://www.yodaiken.com/tag/big-data/
[59]: http://www.yodaiken.com/tag/computer-science/
[60]: http://www.yodaiken.com/tag/data-center/
[61]: http://www.yodaiken.com/tag/distributed-consensus/
[62]: http://www.yodaiken.com/tag/embedded/
[63]: http://www.yodaiken.com/tag/fault-tolerance/
[64]: http://www.yodaiken.com/tag/formal-methods/
[65]: http://www.yodaiken.com/tag/free-software/
[66]: http://www.yodaiken.com/tag/google/
[67]: http://www.yodaiken.com/tag/green-computing/
[68]: http://www.yodaiken.com/tag/ibm/
[69]: http://www.yodaiken.com/tag/innovation/
[70]: http://www.yodaiken.com/tag/intellectual-property/
[71]: http://www.yodaiken.com/tag/ip/
[72]: http://www.yodaiken.com/tag/manufacturing/
[73]: http://www.yodaiken.com/tag/modularity/
[74]: http://www.yodaiken.com/tag/non-determinism/
[75]: http://www.yodaiken.com/tag/ntp/
[76]: http://www.yodaiken.com/tag/open-source/
[77]: http://www.yodaiken.com/tag/operating-systems/
[78]: http://www.yodaiken.com/tag/patents/
[79]: http://www.yodaiken.com/tag/paxos/
[80]: http://www.yodaiken.com/tag/processor-architecture/
[81]: http://www.yodaiken.com/tag/ptp/
[82]: http://www.yodaiken.com/tag/real-time/
[83]: http://www.yodaiken.com/tag/recursion/
[84]: http://www.yodaiken.com/tag/software/
[85]: http://www.yodaiken.com/tag/software-engineering/
[86]: http://www.yodaiken.com/tag/software-patents/
[87]: http://www.yodaiken.com/tag/software-security/
[88]: http://www.yodaiken.com/tag/specification/
[89]: http://www.yodaiken.com/tag/state-machines/
[90]: http://www.yodaiken.com/tag/sun/
[91]: http://www.yodaiken.com/tag/synchronization/
[92]: http://www.yodaiken.com/tag/technology/
[93]: http://www.yodaiken.com/tag/timekeeper/
[94]: http://www.yodaiken.com/tag/timestamp/
[95]: http://www.yodaiken.com/tag/time-synchronization/
[96]: http://www.yodaiken.com/tag/undefined-behavior/
[97]: http://www.yodaiken.com/tag/venture-capital/
[98]: http://www.yodaiken.com/tag/verification/
[99]: http://www.yodaiken.com/tag/virtualization/
[100]: http://www.yodaiken.com/tag/women-in-computer-science/
[101]: http://www.yodaiken.com/wp-login.php
[102]: http://www.yodaiken.com/feed/
[103]: http://www.yodaiken.com/comments/feed/
[104]: https://wordpress.org/ "Powered by WordPress, state-of-the-art semantic personal publishing platform."
[105]: https://www.mhthemes.com/

  [*RSS]: Really Simple Syndication

