Bye bye browser, bye bye search

There is an app for everything! Or at least for nearly everything. This means, traditional search (google, bing, …) will face some changes. We will not use search anymore to find cheap offers for a flight, a product review, or whatever else. For things that we do more or less frequently we will have an app do this. Hipmunk, expedia, tripadvisor, and many many more. These dedicated apps will be our starting point, at least from our mobile and from the tablet. As a result, search and related advertising might see a problem.

This also includes the desktop. For many things which we have been doing in the browser, we see more and more dedicated apps popping up: evernote, wunderkit, and many others give you an app for your desktop. As someone who has never been a big fan of doing everything in the browser, I am very happy to see us switching back from the browser to apps.

Open and the social net

It is interesting to see how the social networks (facebook, twitter, google+,…) are evolving when compared to the original Internet: The social networks are a closed box, it is not really possible to connect one network to another. In contrast, IP networks or applications like email are designed open. Thus, any company (or private user) can connect to the Internet and communicate via open protocols. Or one can run its own email server that connects to other email servers via well-defined protocols.

Now, I know, that the user base of social networks to some extend is their capital. Hence, a lock-in maybe be wanted to a certain degree. However, when compared to the history of the Internet, I wonder whether this lack of interoperability etc. will hinder innovation and evolution. Based on its open architecture the Internet (and the PC) evolved quickly and provided a great platform motivating and fostering others try new ideas. Now, the APIs around the social networks also allow such new ideas, but they seem to focus on the “around”. Hence, the access to the core network is limited.

Overall, I wonder whether this closed architecture will hinder evolution and innovation in the long run. Maybe, once their usage patterns and applications stabilize, we can find a way to deeply interconnect the different social networks. This might also allow one to choose a social networks based on criteria such as privacy and functionality and reduce the pressure of being in one particular network just because everybody else is there, too.

Side notes:

1. I know that companies in the social network world are highly innovative companies. Running their own systems allows them to deploy new ideas quickly. Note, that my thoughts are more general.

2. This is not meant as a call for standardization: standardization processes as we know them today maybe too heavy-weight for this fast-moving area.

Time to move out of the browser

Some thoughts on the browser and  the OS: I believe that its is time to move applications out of the browser. There are too many things that we do inside our web browser, that we could do otherwise easier, better, and at less CPU load and network traffic.

The mobile devices show us the way to go: There are little apps for everything. With the App store for MAC OS, Apple also brings this concept to the desktop and laptop (Note, that Linux essentially had an App store since the first days: apt, yast, yum, and whatever they are called).

To me, the core benefit of these App concept is that I get a little application that is tailored to the goals of the application. Hence, it does not have to deal with the limitations of the browser in terms of languages, html, java script, ajax, flash, lack offline support, and until recently the lack of right clicks. It is just so nice to have a couple of little windows (standalone): one for email, one for notes (I love Evernote), one for Blog writing (such as Windows Live Writer).

In Google Chrome and especially Chrome OS we see Google addressing some of the issues by deeply integrating the OS and the browser. However, stuff still seems to be bound to the browser (and html etc.). Now, I know that html forms a great platform abstraction layer (you can view it essentially on all systems, throw in a mobile site of your stuff and it can be conveniently viewed on smartphones, too) and also forms a second “narrow waist” above IP (there is a HotNets paper on this). However, all this loading, rendering, scripting, is just too inefficient (sure, Ajax etc. help you with it, but still, this is quite a beast).

So, what does this mean for the browser and the OS. From my point of view, the OS (or services on top it), need to provide two features: (1) a Just In Time Compiler (a nice JIT compiler, best with Hotspot support) and (2) a html renderer. Both shall be common services shared across multiple active applications. The Compiler shall handle the efficient execution of all the scripted high level languages we are using today: JavaScript, Python, Flash (and all other Adobe stuff), etc.. Additionally, it can deal wit the byte code of Java, C# (and .Net in general), and all the other stuff. LLVM, .Net, and the new Java core show that this can be done nicely. The apps may use html inside for visualization where appropriate (see Evernote etc.). Hence, the html renderer will parse their html as well as normal web browsing sessions.

I believe that it is important to make both the renderer and the JIT essential services of an OS. Using java shows how heavyweight it is to startup a such a compiler just for a single little application. Similar effects can be noticed when starting up all the different browser you have installed (especially, as many of them are not only html renderer but also JIT compilers for JavaScripte etc.). Furthermore, all this sandboxing and protection that modern browser do, they often tend to double functionality that is provided by the OS anyway.

What does this mean for the OS: looking at the JIT aspects maybe it is time to make Singularity (One of my favorite papers – or better series of papers) or Java OS reality. From the html renderer perspective, I believe chrome OS is on a good may, they just have to hop more on the App concept and leave the browser behind.

Flying with Swiss / Changing in Zurich

Commonly, I use London, Amsterdam, or Frankfurt as hub when flying to the US. This time I was booked on Swiss and changed planes in Zurich (Stockholm-> Zurich –> San Francisco). It was my first time connecting in Zurich and I have to admit that I was a bit nervous: I was scheduled for to have only one hour to change planes in Zurich. Based on my experience from major hubs I was not expecting that I could make it on time to my flight to the US.

And then the plane even was delayed 10 minutes when we arrived in Zurich…

But, somehow, everything went smooth: short queues, quick but precise security checks, and I nicely boarded 15 minutes before takeoff (what seems to be normal in Zurich). That is nice! Service is great with Swiss as always, just the screens are not really not good (at least mine).

So, I finally found some time to watch the “Social Network” Movie. Now, I like it, but they really make him look like an idiot. I am not sure if he deserves this.

P.S. Matt Welsh: I do not like your the way they dressed you in the movie. And I hope that you have had a couple of more people in your class, at least in the undergrad ones.

TinyOS and Cooja

A little HowTo on running TinyOS applications in the Cooja emulation / simulation environment.

1. Cooja is included in the Contiki CVS Git. Hence, make sure you have a recent cvs checkout git clone / checkout / branch /… of Contiki on your system. See http://www.sics.se/contiki/download.html for installation instructions.
   2011-03-27: update: contiki is now on Git.
2. Compile your tinyos application with “make telosb”
3. In your Contiki installation, go to tools/cooja/ and run “ant”. This requires you to have java and ant installed. After compilation it will greet you with an empty simulation environment.
   
4. Hit File –> New Simulation to configure your simulation run.
   
5. Press create and you will see your initial setup.
   
6. Now it is time to add some sensor nodes. Hit mote types –> create mote type –> sky mote type and select the image (main.exe) of your tinyos application by hitting browse.
   
   
7. Hit open and create and next specify the number of sensor nodes you need with that application image. You can add other application by repeating the steps 6 and 7. Hit create and add to make the sensor nodes appear.
   
8. Play with select visualizer skins to customize the sensor visualizations. I prefer mote ids, leds, and radio traffic.
   
9. Activate the radio logger (Plugins –> radio logger) and place all windows conveniently on the screen.
   
10. Press start to see the action. Check the timeline to see packets sent and received and also the Leds. Check the loggers to see radio packets and serial communication.
    
11. Cooja has many other features such as serial sockets, debugging, etc. I will leave it to you to explore them. Please keep in mind that some functionality in Cooja is specific for Contiki and will not work (or only partially) with TinyOS.

Funny bug in TinyOS sequence numbers

RandomC (in lib) and UniqueSendC (in chips/cc2420/unique) are both wired the MainC.SoftwareInit. On my system it seems that that UniqueSendC is initialized first and hence without a seeded random number generator. As a result, all nodes have the same initial DSN. This leads to funny effects when nodes start to transmit simultaneously, as 802.15.4 ACKs are bound to the DSN only.

Contacting tinyos-devel on this, Phil proposed the following fix: “The trivial change is to have init() post a task that initializes the sequence number”. Now, this is really a nice and simple fix (and I tried it: it works).

Cooja and TinyOS

After some fixing (thanks to Joakim and Fredrik here at SICS) Cooja and MspSim now run TinyOS fine once again: Timers do not do funny stuff anymore and serial communication (via socket) now passes the CRC check of the TinyOS tool chain.

SigComm Summary

As usually at SigComm, all papers where really good. It was hard to pick my three favorite ones, here are the ones I have chosen today (Tomorrow this might look different):

1. Efficient Error Estimating Coding: Feasibility and Applications (BEST PAPER): “Without actually correcting the errors in the packet, EEC enables the receiver to estimate the fraction of corrupted bits in the packet, which is perhaps the most important meta-information of a partial
   packet.” The paper shows how this information can be used for video streaming etc. where it is not so important that all bits are received correctly. Hence, EEC is somewhere between ECC (error correction codes) and CRCs on the other hand.
2. SourceSync: A Distributed Wireless Architecture for Exploiting Sender Diversity: “SourceSync enables concurrent senders to synchronize their transmissions to symbol boundaries, and cooperate to forward packets at higher data rates than they could have achieved by transmitting separately. The paper shows that SourceSync improves the performance of opportunistic routing protocols.” Ok, this is cool: in classic opportunistic networks we exploited receiver diversity, now we do the same with the senders. I am wondering if this would also work for Wireless Sensor Networks. However, the tight synchronization requirements (down to the symbol level) seem to make it at least challenging.
3. Understanding Block-level Address Usage in the Visible Internet: “We have little information about the edge of the network. Decentralized management, firewalls, and sensitivity to probing prevent easy answers and make measurement difficult. Building on frequent ICMP probing of 1% of the Internet address space, we develop clustering and analysis methods to estimate how Internet addresses are used.” This paper gives interesting insight in the edge, i.e., end hosts, of the Internet. I like this paper for a special reason: all measurements they do is to ping 1% of the Internet addresses. From this simple information they then smartly draw their conclusions. 

Clean Slate Network Architecture

Listening to the SigComm talks, I realized that there are two playgrounds where people can apply tons of clean slate research to today’s networks and (still) do everything new and shinny : Data centers and Wireless Sensor Networks…

3nd Session of Green Networking WS

1. Breathe to Stay Cool: Adjusting Cell Sizes to Reduce Energy Consumption: Adapt cell coverage (and even big others bigger and turn off some) according to network load to make cellular networks more energy efficient. Interesting, this seems to align well with work going on at Ericsson and probably others.

2. Reducing energy consumption in IPTV networks by selective pre-joining of channels: How to safe energy in IPTV networks, but results are not really promising. But a very nice talk, as always from Jon Crowcroft.

3. Energy Proportionality of an Enterprise Network: Build power models for your network infrastructure and use SNMP to measure the current configurations and operation modes (traffic rates etc.) to estimate the overall power consumption. Use this information to optimize your network.