Posts

Showing posts from January, 2017

Jim Gray's Advice for Authors of Rejected Conference Papers

Jim Gray was a pioneer in database systems and Turing award winner, but he was also a truly nice guy who went out of his way to support other researchers. When I was working at Microsoft Research, I wrote him email complaining about a paper being rejected, and got this reply from him: From: Jim Gray Sent: Tuesday, July 04, 2000 1:51 AM To: Jim Larus Cc: Michael Parkes Subject: RE: Visit? well, the <omitted> paper is in good company (and for the same reason). The B-tree paper was rejected at first. The Transaction paper was rejected at first. The data cube paper was rejected at first. The five minute rule paper was rejected at first. But linear extensions of previous work get accepted. So, resubmit! PLEASE!!! We did, and the paper was published. But, I value Jim's response more highly than the paper, and since then I have added to his list. My favorite is that T im Berners-Lee's paper on the World-Wide Web was rejected as a full paper at Hypermedia &#

Rebooting Computer Security

The NY Times asked the wrong question about the Obama administration’s response to Russian hacking of the November US election ( " U.S. Reacting at Analog Pace to a Rising Digital Risk, Hacking Report Shows" ) .  The question is not why did it took 16 months to develop a response, but what could the US have done to prevent it? The disturbing answer is nothing. Computers are fundamentally insecure, and this sad situation is not going to change quickly. As someone who has spent his entire career computer science research, it pains me greatly to admit that Donald Trump is right when he told reporters “ You know, if you have something really important, write itout and have it delivered by courier, the old-fashioned way. Because I'll tell you what: No computer is safe."  Computers’ original sin is that they run software that is written by humans. People make mistakes at a predictable rate – roughly 10-20 defects per thousand lines of code. Testing can find and el

Reflections on SPIM

SPIM is a program that I wrote during my first year (1990) as a professor at the University of Wisconsin Madison, when I was starting as an assistant professor. It a software simulator for the MIPS processor, a RISC computer that was quite popular at the time, and which was subsequently crushed by Intel x86 computers. Originally I wrote Spim to help my students in a compiler class, who would otherwise have to generate code for the far more complex x86 processors (x86 won that battle, but subsequently added enough registers to make code generation simpler). Subsequently MIPS and Spim were used by David Patterson and John Hennessy in their undergraduate computer architecture textbook (and in several other authors' books), which isn't that surprising since John was the architect of the MIPS processor. Over the past 25 years or so, Spim has probably been used by a majority of computer science undergraduates in one class or another. I am still actively maintaining Spim, which is

Who Am I?

I am James Larus, a professor and dean of the School of Computer and Communications Sciences (IC) at EPFL (École Polytechnique Fédérale de Lausanne), one of the two Swiss federal technical universities, along with ETH Zurich, and one of the world's top computer science departments. I am an American, with no obvious connections to Switzerland, so how did I end up in this position? The answer can be summed in two cliches: "it is not what you know, but who you know" and "you have to be in the right place at the right time." After Martin Vetterli, the previous dean, left to head the Swiss National Science Foundation (and, as of Jan. 1 2017, to return to EPFL as its president!), EPFL starting looking for a new dean of IC. I knew an earlier dean, Willy Zwaenepoel, as a colleague who worked on similar research early in my career, and the head of the recruiting committee, Babak Falsafi, was a student at the UW Madison, where I started my career. They asked if I woul