Lucas' playground

This is a paper review for the course CS 268

J.H Saltzer, D.P. Reed, D.D. Clark, “End-to-end arguments in system design”, ACM Transactions on Computer Systems, Vol. 2, No. 4, November 1984, pp. 277-288

At a time when internet was emerging, this paper not only justifies some of the early design decisions that were taken at the time, but also provides a general justification for the “end-to-end argument”, as the authors name it. This argument, basically, advocates “moving functionality upwards in a layered system, closer to the application that uses the function”. It is first acknowledged that this idea had already been widely used, but in an intuitive way, without formal discussion nor recognition. The end-to-end argument is a very general one; it transcends networking systems, with many applications in other computer engineering domains. The authors even provide examples of usage of this argument in more general settings, an example being error-recovery over the phone, with a person asking its correspondent to repeat his sentence if there has been a problem on the line.

The argument’s justification is that if a function can be implemented completely only by the application standing at the end points, it is not possible to provide the function as a feature of the communication system. The function, in an incomplete version, might still be provided by the communication system, but only as a performance enhancement – which, the authors insist, remains an important aspect to consider when designing a system. After a review of different functions of distributed applications, such as delivery guarantees, secure transmission, in-order reception, the paper provides another very insightful example, outside of the networking domain: the RISC processor architecture.

Written more than 15 years ago, this paper has proved to be very influential. The end-to-end argument has received maybe the best justification through the exponential development of internet, made possible in large part because of its usage of this argument.

This is a paper review for the course CS 268

David D. Clark, “The Design Philosophy of the DARPA Internet Protocols”, Proc. SIGCOMM ‘88, Computer Communication Review Vol. 18, No. 4, August 1988, pp. 106-114

This paper, written over twenty years ago by David D. Clark, who had at that time the architectural responsibility for TCP / IP in the DARPA Internet Program, tries to answer the following question: why has internet been designed the way it has? The author identifies one fundamental premiss : the goal was to design “a packet switched communications facility in which a number of distinguishable networks are connected together using packet communications processors called gateways which implement a store and forward packet forwarding algorithm”. From there, he presents a list of desired features, and shows how the priorities given to the different elements of this list shaped the design decisions at the time. He also explains why these priorities were given that way; for example, that survivability in the face of failure was given a higher priority over accountability seems natural when one thinks about the fact that its primary intended use was for the military.

It is very interesting to read this paper today, 22 years later, to see how things have evolved. Some of the thoughts are still completely relevant nowadays, while other, in my opinion, have taken a different turn – the first thing that comes to mind is the quasi-monopole of TCP over any other type of service, even when considering delay-sensitive applications.

A strong idea that emerges from this paper, and is probably one of the main reasons of the persistence of this original design of internet, is the wide flexibility it has offered from the beginning. The author introduces the concept of “realization” to describe what we could call a particular snapshot of the internet. It is a fact that there have been completely different realizations throughout the last two decades, but yet, thanks to its amazing flexibility, the fundamental ideas and protocols behind internet haven’t had to evolve that much.

As part of my internship at Open Systems, I had to develop on linux boxes without graphical user interface. I had therefore to setup an appropriate development workflow, whose central piece was, of course, the editor. After seeing a colleague performing some “magic” in Vim, I decided that this was going to be my editor of choice. As I litterally started from zero, I thought it would be nice to share the resources that I found the most useful in learning Vim, and this is what this blog post is about.

First, some very basic notes on command line text editors. Vim (Vi IMproved) is, as its name suggests, the descendent of an editor called Vi. From what I’ve understood, Vi is no more in use nowadays, and Vim offers great improvements (e.g. redo something you undid) over Vi. There is a famous rivalry between Vim and Emacs, a competing editor, which I haven’t tried, but which might be an interesting alternative. I have to say, Vim is not intuitive for absolute beginners: you can’t just fire it up and expect to be able to edit your file. If you want a very simple and easy to use text editor, I can think of nano (a pico clone), which is far more intuitive than Vim.

Vim has a steep learning curve, but once you’re acquainted with it, you’ll find that the commands aren’t difficult to remember, and it will save you a ton of text edition time. Another advantage is its wide deployment. It is, as far as I know, a more or less standard tool in every POSIX-compliant operating system – including, for example, Mac OS X.

The most important thing to get at the beginning: Vim is a modal editor, where the two “most important” modes are

1. command mode: this is the “default” mode, the one you are in when you start Vim. It is the mode where you can the most effectively view and manipulate the document.
2. insert mode: where you actually can type some text! Switch to insert mode by pressing i from the command mode. Return to command mode by hitting ESC

A very deconcerting error, and certainly one you’ll make when you start (I can’t count how many times this happened to me) is to start typing something while in command mode. As nearly every key is associated to a command in this mode, this triggers a pseudo random batch of commands, and you will be totally lost! So beware, and learn to use undo (described below)

Here are the very, very few basic commands you need to know to get your head out of the water. You can open a file by typing vim file_name. Once you’re in Vim (in command mode):

• :q exits the program
• :q! exits the program and discards changes
• :w saves the file
• ESC exits from insert mode and switches to command mode
• i switches to insert mode (you can then type some text)
• u undo

Now here’s the list of the resources that helped me the most:

• Why, oh WHY, do those #?@! nutheads use vi? – an essay which explains the philosophy behind Vi/Vim. This is the article that convinced me to try it.
• in your terminal, type vimtutor – it launches an interactive Vim tutorial, and it is an absolute MUST!
• Vim Novice Tutorial Videos – Nice screencasts, might be a little long for some of you, but it’s fun and requires zero previous knowledge.
• Vim Tips Wiki – One of my favorite Vim resource. It contains an impressive amount of information, in the form of a wiki.
• Vim Recipes – These “recipes” offer a result-oriented approach to Vim. It’s like a giant FAQ. It answers questions in the form “How do I navigate between files”, “How can I search / replace text?”, etc…
• Vim as Development Environment – A programmer explains how he sets up Vim (with topics such as syntax highlighting, …).
• Splits and multi-file editing – having several files open side by side was one of my primary needs. This explains how to do it.
• Graphical vi-vim Cheat Sheet and Tutorial – I love nice cheat sheets. This one is certainly one of the nicest you can find for Vim.
• Michael Goerz’s Refcard – Another cheat sheet. Not really for beginners, but a good reference once you are already experienced.

I’m using PHP for my semester project @ EPFL, and I stumbled upon a curious bug when trying to serialize an object (using PHP’s serialize()):

Node no longer exists

First I thought it was because of an infinite recursive loop (object A contains object B who in turn contains object A again, and so on), but in fact, infinite recursivity is allowed with serialize()!

Therefore, the problem was elsewhere: it ended up being an issue with SimpleXML, as explained here. SimpleXML’s parser creates strange, unserializable, “built-in objects”.

Until you try to serialize them, you never realize they aren’t just strings. An explicit cast solves the problem.

// isn't serializable.
$track->URI = $first_track->location;

// resolves the problem!
$track->URI = (string)$first_track->location;

Welcome on my blog.

I’m experimenting a lot of stuff on the web and with computers in general, and quite often I spend hours discovering, configuring and trying to understand some obscure geeky stuff.

I have decided to start blogging to share some informations I think could be useful to some people. I spend a lot of time on Google trying to find various tutorials, explanations, tips, and I thought it would be great to share some of that knowledge.

Don’t expect every post to be interesting: rather than a generalistic, regular blogging style, I’m willing to talk about very different, specific things in a random fashion. I expect people that come here to have a very specific and precise interest in a single topic, and eventually finding this blog through Google.