I've written before of how much I liked the British SF magazine Interzone. Sadly I decided not to renew my subscription last year, as the focus of my reading has been changing and I've not had enough time to keep on top of it. (This is a consequence of my experiment with goodreads, and I'll write more about that sometime.) Back in October 2012 TTA Press reformatted both Interzone and its sister publication Black Static into a half-size, semi-hard backed shape. The size is similar to the US stalwards Analog and Asimov's, but the cover is harder and glossier and it has a flat spine. I really like the new look, and it's a bit of a shame I didn't complete at least a calendar year's worth of them. I will probably pick up the odd issue now and then, when a name I recognise catches my eye. Perhaps one day I'll have the time and inclination to read short fiction regularly again. I'd still wholeheartedly recommend it (and Black Static) if short fiction is your thing.

I went crazy again and upgraded my laptop from 32 to 64 bits. This was a rather complex problem, and in retrospect it may have been easier to simply reinstall. But it was a good exercise and a good test of the new multi-arch support, which, I gotta say, works surprisingly well. A few other people wrote their own procedures already, but I made my own in my wiki (which, incidentally, I am thinking of using to replace this blog which I can't seem to upgrade to even Drupal 7...).

Wow, today was pretty crazy in terms of the travel we managed to pack into one day. This morning, Zoe woke up at about 5:30am and jumped into bed with me for a snuggle and another half hour nap. After that we got up. Zoe had been eyeing off the egg cups in the house, and so I'd wanted to do soft-boiled eggs for breakfast. So we doused ourselves in mosquito repellent and raided the chicken coop. I don't think I've ever cooked soft-boiled eggs in my entire adult life, and today wasn't an exception. They came out hard-boiled. Zoe still ate them anyway, she just couldn't do the toast soldier thing. I need to buy some egg cups for home and we can try again. I hear the Thermomix can do boiled eggs. After breakfast and a shower, I got stuck into packing up and cleaning the house, and Zoe watched TV. At 8am she turned off the TV and declared she wanted to play in the yard. It was nice to see that she wanted to do something more than just veg out in front of the TV, without prompting. I had us all packed up by about 8:30am and we were only 5 minutes from where the barge docked, so we drove over to the other end of the island to take a look at the place at high tide. It was quite different from the two days before in the afternoon at low tide. The stick that we'd walked out to was barely above the waterline. Then we drove back to wait in the queue for the barge. The barge journey back was uneventful and we made it back home by 10am, which was about the time I was expecting, and rendezvoused with my girlfriend, and did a fast unpack and repack. We then headed to the airport, arriving comfortably with enough time to check our luggage and get some lunch to take onto the plane. Zoe was great for the flight down. She watched Brave on the in-flight WiFi entertainment on my phone, and got to fit the whole movie in before we landed, but this meant she skipped a nap. By the time we got to Melbourne Airport, she was in the post-tired manic state, but we weren't in any particular rush, so we had a very roundabout trip to baggage claim, and then after we'd acquired some Myki cards, caught a taxi to our accommodation in South Melbourne. After we'd unpacked and settled in, and I'd gotten some supplies from the local convenience store, we caught a tram into Bourke Street to go to Chinatown for dinner, after checking out the view from the observation deck on the 28th floor. We found a great dumpling place, and Zoe really enjoyed the pork dumpling and noodle soup that I ordered for her. She kept alternating between eating the noodles with her training chopsticks and the broth with one of the big spoons. She was getting really over-tired and over-stimulated by this point, so it was quite a bit of cat-herding to get to Chinatown, and more so getting back to a tram to come back. We got home, Zoe had a quick shower and went to bed without a peep. Her room is nice and dark, so I'm hoping that she'll have a bit of a sleep in tomorrow. (Wishful thinking). I'm really quite pleased with how smoothly today's travel went. Everything went off without a hitch.

I was super sad to know that Paco de Lucia passed a few days ago. It was shocking to know that he was so young (only 66 year old, if I am not mistaken). To share some of his fine work with his frequent collaborators John McLaughlin and Al Di Meola to people that may not otherwise know him or his work, I offered on a Facebook post to upload a bootleg of a show of the Guitar Trio (John McLaughlin, Paco De Lucia and Al Di Meola) with the entire performance (possibly out of order, as that is a bootleg, after all) ripped from a broadcast to Dutch TV station. This performance includes the exceptional Paco de Lucia prominently and the show has many songs from the "Friday Night in San Francisco" record, including the magnificent (IMVHO) "Mediterranean Sundance". The credits of the video are, of course, of the musicians. I only ripped, deinterlaced (remember, analog TV it was interlaced), denoised, encoded, and uploaded the video to youtube.

Following my blog post on the topic, I played a bit with various options. But let s explain my use case (which might be quite specific). I need to deal with three main sources of events:

• the Zimbra instance from my lab. It provides a CalDav interface.
• the ICS export from my University s teaching timetable.
• a calendar for personal stuff. I don t want to use my lab s Zimbra for that.

Additionally, I follow some ICS feeds for some colleagues and other events.
I tend to access my calendar mostly on my computer, and sometimes on my N900 phone. None of the web interfaces I looked at enabled me to (1) manage different calendars hosted on different CalDav servers; (2) subscribe to ICS feeds; (3) provide a CalDav interface to synchronize my phone. I ended up using a radicale instance for my personal calendar, which was extremely easy to set up. It s unfortunately a bit slow when there are many events (1600 since 2010 in my case), so I ended up importing only future events, and I will probably have to cleanup from time to time. I switched to using IceDove with the Lightning add-on to manage all my calendars and ICS feeds. It s unfortunately slower and less user-friendly than Google Calendar, but I ll live with it. On my N900, I used syncevolution to synchronize my various CalDav calendars. It works fine, but understanding how to configure it is rather tricky due to the number of concepts involved (templates, databases, servers, contexts, ). The synchronization is quite slow (several minutes for the 400-events Zimbra calendar), but works. I also wanted a way to export my calendars to colleagues (both in a free/busy version, and in a full information version). I quickly hacked something using ruby-agcaldav (which is not packaged in Debian, and required quite a few dependencies, but it was easy to generate packages for all of them using gem2deb the situation with other languages did not look better).
The resulting script is:
require 'agcaldav'
require 'date' cal = AgCalDAV::Client.new(:uri => 'LABCALDAVSERVER', :user => 'xx', :password => "xx")
ev = cal.find_events(:start => '2014-02-01', :end => '2200-01-01') cal = AgCalDAV::Client.new(:uri => 'RADICALESERVER', :user => 'xx', :password => "xx")
ev2 = cal.find_events(:start => '2014-02-01', :end => '2200-01-01') limit = (Time::now - 7*86400).to_datetime # create new empty calendars
ncpriv = Icalendar::Calendar.new
ncpub = Icalendar::Calendar.new (ev + ev2).each do e
next if e.end < limit # drop old events to keep the calendar small # build event for the free/busy calendar
pe = Icalendar::Event.new
pe.start = e.start
pe.end = e.end
pe.klass = "PRIVATE"
pe.transp = e.transp
ncpriv.add(pe) # build event for the calendar with event information
pube = Icalendar::Event.new
pube.start = e.start
pube.end = e.end
pube.transp = e.transp
if not e.klass == "PRIVATE"
pube.summary = e.summary
pube.location = e.location
end
ncpub.add(pube)
end # export free/busy calendar
fd = File::new('xx.ics', 'w')
fd.puts ncpriv.to_ical
fd.close # export calendar with event information
fd = File::new('yy-Zeeh9bie.ics', 'w')
fd.puts ncpub.to_ical
fd.close
So, mostly everything works. The only thing that doesn't is that I haven't found a way to subscribe to an ICS feed on my N900. Any ideas?

It is the first of these which I have recently been attempting and I think Phil Karlton might have a good point.
What are we talking about?Web browsers are pretty complex beasties but the basic concept is pretty easy to understand. They fetch a bunch of files that make up a web page and render those source files into something suitable for human consumption.

It is also intuitive that fetching all the files that make up a web page, every time you browse to a new page, might be wasteful, especially if most of the files had not changed from the previous page.

In order to address this browsers hang onto copies of these files in case your browsing needs them again, this is known as a source file cache. Caches are a widely used technique throughout many aspects of computer technology but the basic idea is that they trade one resource for another.

In this case we are trading local storage space (memory or disc) for access time. This type of trade may give large benefits due to the large differences in access times (sometimes known as latency) between local and network resources.

For example, if the source files that make up a web page are a Megabyte in size accessed with a 2013 era PC with a 10Mbit connection to the Internet:

• Accessing the data from main memory will take approximately 20 s (millionths of a second).
• The same data retrieved from a hard disc drive will take 4,000 s to arrive, around 200 times longer.
• If we were to retrieve the data from a fast web server and assuming the network connection is in perfect working order, the data will roll in 1,200,000 s later, or around 300 times more slowly than disc and a unfathomable 60,000 times slower than memory.

From this example it becomes startlingly obvious why a source cache is so desirable. I have greatly simplified the browsers operation here as they usually implement many layers of additional caching in other areas to make the browsing experience subjectively smoother.

And before the observant reader suggests that we could just make the network faster it ought to be mentioned that due to fundamental physical constraints, like the speed of light, it would be unlikely that the average practical network reply will ever drop much below 150,000 s [1] or some 40 times slower than disc. Still a worthwhile gain.
Knowing the cost of everything and the value of nothingHaving shown the benefits it might be nice to think there are no downsides to caching, this is not the case, as I mentioned we are trading storage for time and as in any trade one must expect there to be overheads.

In the case of a browser we face several obstacles. Firstly not every file that goes to make up a web page can be cached. The HTTP specification contains an entire section on caching which contains numerous rules and operations to ensure that only objects that should be cached are and determines for how long they can be kept before going "stale".

A great deal of this complexity comes from just how desirable caching is to network providers. Many ISPs will have web proxy servers to cache requests for all users to reduce their bandwidth usage, or increasingly, to implement content filtering according to the local government censorship rules. The browsers cache must know how to interact with these proxies without getting erroneous results.

Then comes the problem alluded to in the section title. A browsers cache cannot grow indefinitely. Eventually a system would run out of memory and disc if a browser kept every file. To deal with this the cache is limited sometimes by the number of files it holds, but more commonly by size both in memory and on disc.

The caching structure used by a web browser is hierarchical in that it will first evict (move) files from memory to a backing store (disc) and when the disc cache size limit is exceeded files are evicted to the next tier. Which in this case, will involve deleting the local copy (invalidating) and requiring performing a fetch from the network if the file is needed again.

When the cache size is exceeded the decision is made about what to remove from the cache using a cache strategy or algorithm. The aim of this decision is to discard the data that will not be required again for the longest time.

If we had a blue box with a madman inside, who we could persuade to bring our browsing history back from the future, implementing b l dy's algorithm might be possible. Failing a perfect solution we are reduced to making a judgement based on the information available to us.

This involves computing a cost for replacing each entry in the cache and evicting those with the lowest values. The selected algorithm has a large impact on the effectiveness of the cache and often needs fine tuning for the task at hand.
Never has so little been measured so muchHaving established that caching is useful and that we need to make decisions on what to keep it follows that those decisions must be based on information. This information consists of two main groups:

• A series of metrics about the cache state such as the number of objects and their cumulative size currently being stored in memory.
• Information about each object, known as metadata, this includes things like the objects individual size, how long until it becomes stale and when it was last used.

Maintaining all of this information is a significant part of the overheads involved with caching and a compromise must be struck between having the necessary information to make good caching choices and the cost maintaining that data.
Cache metricsMost cache implementations maintain at least some basic metrics, at the very least how much storage is being used so a decision on if evicting entries from the cache to reclaim space is necessary.

It is also common to keep a record of how well the cache is performing. The cache efficiency (the hit rate) is usually measured as the ratio of successful accesses provided from the cache (a cache hit) to the total number of requests to the cache.

A perfect cache would have all hits and no misses (a hit rate of 1) while using as little storage as possible (but as already noted that requires a special madman). The hit rate can be used to automatically change the behaviour of the eviction algorithm, perhaps using more storage if the hit rate drops too low or changing the eviction frequency.
MetadataEach object must carry with it the data necessary to regain its state when retrieved from the cache. This information is essential for the correct operation of the cache but in of itself provides no direct value.

In the case of browser source data this includes all the headers sent in the original network fetch. These headers are themselves just metadata sent along with the object by the web server which must be preserved.

Two particularly useful value for making a good eviction decision are how long it has been since the object was last used and how many times it has been used. This is because an object that was cached a long time ago and then never used again is much less valuable than one that has recently been repeatedly used.
An ImplementationIt is all very well talking about the general solution but a full understanding can only be gained by examining a real implementation. The NetSurf cache was chosen as it is a suitably small amount of code but still demonstrates all the major design features.
InterfaceThe cache deals with all source data and provides the browser with a single unified object request interface regardless of if the source data can be cached or not. This is useful to hide the implementation details allowing for changes without affecting the rest of the browsers code.

The implementation effectively consists of two lists of objects, those that can be cached and those that cannot. Each object on these lists is reference counted against one or more users and while there is at least one user the source data is maintained in memory.

Objects determined to be non cached are always directly fetched from their source and are immediately released once they have no users remaining.

For cacheable objects an attempt is made to fulfil the request in descending order:

1. from objects already in memory.
2. from the backing store.
3. from a network fetch.

Irrespective of the source of the data the remaining operations on the object (determining freshness etc.) are exactly as if the request had been fulfilled from the network. This approach means the use of the cache is transparent to the object users.
WriteoutObjects are placed in the backing store asynchronously to any other operations. When an object has been fetched from the network a background task is scheduled for when the browser is otherwise idle.

This writeout task constructs a list of all cacheable objects not yet in the backing store, associates a cost value with each object and then proceeds to write those objects to the backing store in highest to lowest value order.
CleaningA periodically scheduled task deals with ensuring the cache is cleaned. This consists of destroying stale objects and arranging fresh objects are not using more memory than the configuration permits.

Memory usage is reduced within the cleaning task by discarding the source data for objects already held in the backing store (where the data can be retrieved relatively cheaply)

Additional memory may be recovered by simply discarding unused objects held only in memory. These objects are usually those which have only recently become unused otherwise the writeout task would have committed them to the backing store.

The most recently used objects are statistically likely to be used again soon, because of this there is a high risk of a cache miss associated with discarding these objects. In order to mitigate this undesirable effect the cleaning heuristic favours using more memory than configured for short periods rather than discarding from memory.
Backing storeThe backing store is a simple key-value database. Each source data object and its metadata (its headers etc.) is associated with a unique key (the URL used to fetch it). The backing store is simply required to store and retrieve the object data associated with the given URL.

The backing store implementation in NetSurf is pluggable, this flexibility is required for dealing with the greatly varying capabilities and limits of the various systems the browser is required to execute on.

A novel aspect of this backing store interface is that if an implementation returns the wrong object it is not considered an error and is simply treated as a cache miss. This is possible because the metadata contains the URL of the stored object enabling object verification.

This behaviour is permitted because techniques which significantly improve key-value store performance (principally key hashing) become available if they are not required to always give the correct answer.

The backing store is also required to manage its size within the configured limits and deal with any filesystem behaviour details.

The reference backing store is trivial in that it performs a hash operation on the input URL, encodes the result with base64url encoding and uses that as the object filename. The length of the hash can be configured allowing use of the reference implementation in any situation where using the filesystem as a database is acceptable.

The reference backing store default hash is SHA-1 yielding almost unique [2] 160 bit key values stored in much the same way as the git DVCS. Note we are not using this hash for its cryptographic properties and at worst a collision will result in the cache being a tiny amount less efficient.
ConclusionHopefully this has shown what a browser source file cache is, why it is useful and a basic understanding of how they are implemented.

I will admit I have glossed over some of the more challenging aspects especially in relation to actually implementing the cache strategy but I hope that the reader will forgive those omissions of detail in a quest for a little more clarity of the general principles.

I would like to thank John-Mark Bell for implementing the NetSurf cache and to Melodie Parry for proof reading and providing feedback.

[1] Speed of light is 3x10^8m/s earth circumference is 4x10^7m, divide circumference by speed gives 133,000 s which gives longest round trip time from anywhere on surface of earth to point furthest from. So assuming a whole megabyte can be transferred in one round trip and allowing for some overhead the lower bound estimate of 150,000 s looks reasonable.

[2] Mathematically speaking this hash would allow us to say that with the current estimated 1x10^11 URLs on the internet the likelihood of a collision is still vanishingly small (at least 1x10^-15)

I ve been issuing a lot of x.509 certs and OpenVPN user configurations lately, and I came across something that has reduced the complexity quite a bit. It seems that OpenVPN configuration files can now include data inline. So rather than generating and distributing the following for each user:

• a configuration file
• a chain of CA certs
• a client certificate
• a client key
• a tls HMAC authentication file
• the OpenVPN client

one may distribute to users just the following:

• a configuration file with data inline
• the OpenVPN client

This process and the process of creating new users/certificates is automated by the fine people who develop OpenVPN itself and the OpenVPN AS management software. It is good to know that if you are unable to use this service, the process is at least much less complicated these days. One thing to keep in mind is that some platforms do not support all OpenVPN configuration file options. One in particular that has been giving me trouble is the dev and dev-type options. If your configuration file (.ovpn or .conf) is intended for use with Tunnelblick on OSX, be sure to set dev to either tun or tap, and be sure not to use the dev-type option. It seems that the tuntap code on OSX does not support arbitrary names for the devices; the device names must be generated by the kernel.

I m trying to self-host my calendar setup, and I must admit that I m lost between all the different solutions. My requirements are:

• (A) manage my own personal calendar using a reasonably modern web interface (probably on my own CalDAV server)
• (B) display a dozen public ICS calendars in the web interface. Organizing those public calendars in a tree would be great.
• (C) display several caldav calendars (from two different instances of zimbra), preferably in RW mode
• (D) provide ICS links with a secret token that allow me to provide a full view of my calendar to some people (except for private events, where I should just be marked busy )
• (E) provide ICS links with a secret token that allow me to provide a busy/available view of my calendar to some people
• (F) export something usable on my n900. MFE would be great since that is already known to work.
• (G) easy to setup (Debian packages available in wheezy or wheezy-backports, especially for the server part)
• (H) preferably lightweight. I don t need a full groupware application. I can ignore the other bits if really needed.

It does not seem to be possible to find a single framework doing all of the above. AFAIK:

• Owncloud does A, D, G
• Baikal does A. not sure about the rest.
• For (B), an alternative is to script the download of the ics and then upload it to the CalDAV using cadaver. But that sounds quite low-level for such a trivial use case.
• I ve looked at using IceOwl (and Thunderbird+Lightning) with a CalDAV server such as Radicale. That would solve A (using iceowl instead), B, C. But which CalDAV servers support D, E, F ? Radicale does not do any of those, apparently.

What did I miss?

Today was yet another busy day. Zoe seems to have taken to waking up at around 5:30am instead of her normal 6:00am (or a bit later when I'm really lucky). Not sure what that's all about. I did get her to go back to bed until about 6:55am, and then she was happy to just come and snuggle in bed with me for a bit instead of play games on her Nexus 7. After that we had a leisurely start to day, making porridge with strawberries in the Thermomix, and then biked to Kindergarten. Somehow it still managed to be 8:45am by the time we got there. I was expecting it would be closer to 8:30am. Drop off looked like it was going to be clingy, but then she just waved me off, so that was nice. I had an appointment at the podiatrist at 11:40am, and that was back near Kindergarten, but further away from home, so I had this grand plan of cycling over there, and then twiddling my thumbs for a bit before Kindergarten pickup. That left me with only a couple of hours at home to work on my taxes before I had to leave again. I managed to make those couple of hours productive though, so that was good. I biked to the podiatrist, had my appointment, and then it was 1pm and I still needed lunch, so I decided to grab some at a cafe near the Kindergarten. I chilled out there for a while catching up on social media on my phone, and then headed over to the Kindergarten, but was still quite early, so I just hung out on one of the couches they have out by the front door, out of sight of the kids. The Kindergarten has an A-frame whiteboard out the front that they use to broadcast messages to parents at drop off and pick up time. One of the teachers came out to write something on it while I was sitting out there, and another parent reacted rather negatively to it as it was being written, so I had to go see it for myself. Apparently a child had a suspected gastro bug (he'd thrown up a couple of times). It was interesting observing the reactions of a few mothers as they trickled in for pick up. It's been a while since a gastro bug has gone through the household, so I guess the news didn't evoke a particularly powerful reaction in me. I'm going with the "suspected" and that hopefully Zoe didn't come into contact with patient zero. I guess time will tell. I certainly hope she doesn't come down with anything between now and Sunday, with all the travel we're doing. I had an accident report to sign today. Apparently a large wooden block hit Zoe in the head while they were packing up a tower they'd made. She had a bit of a lump on her head, but otherwise seemed fine. Zoe had a nap today, of unknown length, but woke up naturally as I entered the room. She took a fair while to get going though, and was grumpy and uncooperative getting on the bike. I ended up having to do it the "hard way" and we had a fabulous ride back with her doing a tired cry all the way. All the way until we passed a playground, when she snapped out of it and declared she wanted to have a play. I'd booked myself in for a haircut at 3pm, and a make up swim class at 4:45pm (to cover our absence this Saturday due to our Melbourne trip) so playing in the playground seemed like the perfect way to fill the gap. It was even on the way to swim class. So after I had my haircut, we popped home, grabbed her swim gear, and biked back to the playground for a bit. Then we went to swim class. This was her third one at her new level, and her progress continues to go very well. It's really exciting watching her. Zoe took her time leaving the pool, so we didn't get home until after 5:30pm and I hadn't started dinner yet. I whipped it up while Zoe watched some TV, and I managed to recoup all of the lost time after dinner and still get Zoe to bed at a reasonable hour. Bedtime itself went nice and smoothly. I used the canned goodnight video I asked Sarah to make for the first time tonight, and it was well received and I think defused any potential issues. I'm hoping she'll sleep well tonight, as her mosquito bites don't seem to be actively giving her trouble any more.

My right ankle has never been quite right ever since I sprained it in 2008. The ankle is always a bit enlarged, sometimes more so after running. With all the running I've been doing back in Brisbane, I had this niggling concern in the back of my head that I might be doing myself some long term damage, so last year I packed myself off to see a physiotherapist that was within walking distance of home. He declared that I had blown out two of the ligaments in my foot from the sprain, and that my calf was compensating for it a bit. The swelling was just scar tissue. He gave me a bunch of exercises to do, and I had some electrotherapy on my calf for a few weeks and I went on my way. I think I'm supposed to do the exercises every time before I run, but that hasn't happened. It's hard enough to make the time to run, without having to prepend a bunch of exercises as well. One of my neighbours works for my FootDr, so I asked her if they did video run gait analysis, because I was interested in seeing if there was anything I could do to improve my running gait. They did, and so I finally got around to making an appointment for today. The appointment wasn't as interesting as the one I had in the US, in that there was no fluoroscopy, just manual examination, but there was the video run gait analysis on the treadmill, which was not something I've had before. I was pleased that my running shoes (New Balance 940's) were deemed correct for my situation. The guy at Sports Basement obviously did a good job of fitting them to me. I was advised to refresh the shoes, though, so I lashed out on a pair of 940 v2's today. My health insurance also paid pretty generously for orthotics, so I'm going to get a pair for them to add to the ankle stability. The results of the run gait analysis were that, surprise surprise, I am rolling inwards a bit more on my right ankle than my left. Interestingly, my left calf was bigger than my right one, so I was advised to stick with the physiotherapy exercises (yay). So with the orthotics, new shoes, and forcing myself to do my physiotherapy exercises, I'm pretty satisfied that my continued running isn't likely to do too much damage to my body. The podiatrist concurred that because I'm currently pain free, everything should be good. I just had to live with the fact that my right ankle is going to always be a bit swollen.

Nir Eyal Automatic customers: How to design user habits at WordCamp San Francisco 2012: I came across this video by Nir Eyal about his model for analyzing and designing user engagement through habits. Successful services, he says, develop habits through triggers, actions, rewards and investments. A trigger is some kind of prompt that suggest an action promising a reward, these can be external (Twitter notification) or internal (boredom). Promising because our brains are wired for the thrill of search, of promise, rather than results. That s why we keep reloading the Twitter feed hoping for good tweets this time. Then comes the investment. Asking users to devote effort (following friends) in exchange of further rewards (better content) loads the value and triggers that will get the user to come back: direct messages, replies, suggested content. Or, simply put: the more you use Twitter, the more triggers and rewards you create, the more you hook yourself. This is really interesting as it is not limited to technology, the science behind it is actually nothing new. I m curious to see how this can be applied to Free Software and personal projects. Check out the abridged version linked above, and the longer workshop as soon as you have the time.

TL;DR: Do not enable net.ipv4.tcp_tw_recycle. The Linux kernel documentation is not very helpful about what net.ipv4.tcp_tw_recycle does:

Enable fast recycling TIME-WAIT sockets. Default value is 0. It should not be changed without advice/request of technical experts.

Its sibling, net.ipv4.tcp_tw_reuse is a little bit more documented but the language is about the same:

Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. Default value is 0. It should not be changed without advice/request of technical experts.

The mere result of this lack of documentation is that we find numerous tuning guides advising to set both these settings to 1 to reduce the number of entries in the TIME-WAIT state. However, as stated by tcp(7) manual page, the net.ipv4.tcp_tw_recycle option is quite problematic for public-facing servers as it won t handle connections from two different computers behind the same NAT device, which is a problem hard to detect and waiting to bite you:

Enable fast recycling of TIME-WAIT sockets. Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation).

I will provide here a more detailed explanation in the hope to teach people who are wrong on the Internet. As a sidenote, despite the use of ipv4 in its name, the net.ipv4.tcp_tw_recycle control also applies to IPv6. Also, keep in mind we are looking at the TCP stack of Linux. This is completely unrelated to Netfilter connection tracking which may be tweaked in other ways¹.

About TIME-WAIT state Let s rewind a bit and have a close look at this TIME-WAIT state. What is it? See the TCP state diagram below²: Only the end closing the connection first will reach the TIME-WAIT state. The other end will follow a path which usually permits to quickly get rid of the connection. You can have a look at the current state of connections with ss -tan:

$ ss -tan   head -5
LISTEN     0  511             *:80              *:*     
SYN-RECV   0  0     192.0.2.145:80    203.0.113.5:35449
SYN-RECV   0  0     192.0.2.145:80   203.0.113.27:53599
ESTAB      0  0     192.0.2.145:80   203.0.113.27:33605
TIME-WAIT  0  0     192.0.2.145:80   203.0.113.47:50685

Purpose There are two purposes for the TIME-WAIT state:

• The most known one is to prevent delayed segments from one connection being accepted by a later connection relying on the same quadruplet (source address, source port, destination address, destination port). The sequence number also needs to be in a certain range to be accepted. This narrows a bit the problem but it still exists, especially on fast connections with large receive windows. RFC 1337 explains in details what happens when the TIME-WAIT state is deficient³. Here is an example of what could be avoided if the TIME-WAIT state wasn t shortened:

• The other purpose is to ensure the remote end has closed the connection. When the last ACK is lost, the remote end stays in the LAST-ACK state⁴. Without the TIME-WAIT state, a connection could be reopened while the remote end still thinks the previous connection is valid. When it receives a SYN segment (and the sequence number matches), it will answer with a RST as it is not expecting such a segment. The new connection will be aborted with an error:

RFC 793 requires the TIME-WAIT state to last twice the time of the MSL. On Linux, this duration is not tunable and is defined in include/net/tcp.h as one minute:

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                                  * state, about 60 seconds     */

There have been propositions to turn this into a tunable value but it has been refused on the ground the TIME-WAIT state is a good thing.

Problems Now, let s see why this state can be annoying on a server handling a lot of connections. There are three aspects of the problem:

• the slot taken in the connection table preventing new connections of the same kind,
• the memory occupied by the socket structure in the kernel, and
• the additional CPU usage.

The result of ss -tan state time-wait wc -l is not a problem per se!

Connection table slot A connection in the TIME-WAIT state is kept for one minute in the connection table. This means, another connection with the same quadruplet (source address, source port, destination address, destination port) cannot exist. For a web server, the destination address and the destination port are likely to be constant. If your web server is behind a L7 load-balancer, the source address will also be constant. On Linux, the client port is by default allocated in a port range of about 30,000 ports (this can be changed by tuning net.ipv4.ip_local_port_range). This means that only 30,000 connections can be established between the web server and the load-balancer every minute, so about 500 connections per second. If the TIME-WAIT sockets are on the client side, such a situation is easy to detect. The call to connect() will return EADDRNOTAVAIL and the application will log some error message about that. On the server side, this is more complex as there is no log and no counter to rely on. In doubt, you should just try to come with something sensible to list the number of used quadruplets:

$ ss -tan 'sport = :80'   awk ' print $(NF)" "$(NF-1) '   \
>     sed 's/:[^ ]*//g'   sort   uniq -c
    696 10.24.2.30 10.33.1.64
   1881 10.24.2.30 10.33.1.65
   5314 10.24.2.30 10.33.1.66
   5293 10.24.2.30 10.33.1.67
   3387 10.24.2.30 10.33.1.68
   2663 10.24.2.30 10.33.1.69
   1129 10.24.2.30 10.33.1.70
  10536 10.24.2.30 10.33.1.73

The solution is more quadruplets⁵. This can be done in several ways (in the order of difficulty to setup):

• use more client ports by setting net.ipv4.ip_local_port_range to a wider range,
• use more server ports by asking the web server to listen to several additional ports (81, 82, 83, ),
• use more client IP by configuring additional IP on the load balancer and use them in a round-robin fashion,
• use more server IP by configuring additional IP on the web server⁶.

Of course, a last solution is to tweak net.ipv4.tcp_tw_reuse and net.ipv4.tcp_tw_recycle. Don t do that yet, we will cover those settings later.

Memory With many connections to handle, leaving a socket open for one additional minute may cost your server some memory. For example, if you want to handle about 10,000 new connections per second, you will have about 600,000 sockets in the TIME-WAIT state. How much memory does it represent? Not that much! First, from the application point of view, a TIME-WAIT socket does not consume any memory: the socket has been closed. In the kernel, a TIME-WAIT socket is present in three structures (for three different purposes):

1. A hash table of connections, named the TCP established hash table (despite containing connections in other states) is used to locate an existing connection, for example when receiving a new segment. Each bucket of this hash table contains both a list of connections in the TIME-WAIT state and a list of regular active connections. The size of the hash table depends on the system memory and is printed at boot:

   $ dmesg   grep "TCP established hash table"
   [    0.169348] TCP established hash table entries: 65536 (order: 8, 1048576 bytes)
   

   It is possible to override it by specifying the number of entries on the kernel command line with the thash_entries parameter. Each element of the list of connections in the TIME-WAIT state is a struct tcp_timewait_sock, while the type for other states is struct tcp_sock⁷:

   struct tcp_timewait_sock  
       struct inet_timewait_sock tw_sk;
       u32    tw_rcv_nxt;
       u32    tw_snd_nxt;
       u32    tw_rcv_wnd;
       u32    tw_ts_offset;
       u32    tw_ts_recent;
       long   tw_ts_recent_stamp;
    ;
   struct inet_timewait_sock  
       struct sock_common  __tw_common;
       int                     tw_timeout;
       volatile unsigned char  tw_substate;
       unsigned char           tw_rcv_wscale;
       __be16 tw_sport;
       unsigned int tw_ipv6only     : 1,
                    tw_transparent  : 1,
                    tw_pad          : 6,
                    tw_tos          : 8,
                    tw_ipv6_offset  : 16;
       unsigned long            tw_ttd;
       struct inet_bind_bucket *tw_tb;
       struct hlist_node        tw_death_node;
    ;
   

2. A set of lists of connections, called the death row , is used to expire the connections in the TIME-WAIT state. They are ordered by how much time left before expiration. It uses the same memory space as for the entries in the hash table of connections. This is the struct hlist_node tw_death_node member of struct inet_timewait_sock.
3. A hash table of bound ports, holding the locally bound ports and the associated parameters, is used to determine if it is safe to listen to a given port or to find a free port in the case of dynamic bind. The size of this hash table is the same as the size of the hash table of connections:

   $ dmesg   grep "TCP bind hash table"
   [    0.169962] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
   

   Each element is a struct inet_bind_socket. There is one element for each locally bound port. A TIME-WAIT connection to a web server is locally bound to the port 80 and shares the same entry as its sibling TIME-WAIT connections. On the other hand, a connection to a remote service is locally bound to some random port and does not share its entry.

So, we are only concerned by the space occupied by struct tcp_timewait_sock and struct inet_bind_socket. There is one struct tcp_timewait_sock for each connection in the TIME-WAIT state, inbound or outbound. There is one dedicated struct inet_bind_socket for each outbound connection and none for an inbound connection. A struct tcp_timewait_sock is only 168 bytes while a struct inet_bind_socket is 48 bytes:

$ sudo apt-get install linux-image-$(uname -r)-dbg
[...]
$ gdb /usr/lib/debug/boot/vmlinux-$(uname -r)
(gdb) print sizeof(struct tcp_timewait_sock)
 $1 = 168
(gdb) print sizeof(struct tcp_sock)
 $2 = 1776
(gdb) print sizeof(struct inet_bind_bucket)
 $3 = 48

So, if you have about 40,000 inbound connections in the TIME-WAIT state, it should eat less than 10MB of memory. If you have about 40,000 outbound connections in the TIME-WAIT state, you need to account for 2.5MB of additional memory. Let s check that by looking at the output of slabtop. Here is the result on a server with about 50,000 connections in the TIME-WAIT state, 45,000 of which are outbound connections:

$ sudo slabtop -o   grep -E '(^  OBJS tw_sock_TCP tcp_bind_bucket)'
  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
 50955  49725  97%    0.25K   3397       15     13588K tw_sock_TCP            
 44840  36556  81%    0.06K    760       59      3040K tcp_bind_bucket

There is nothing to change here: the memory used by TIME-WAIT connections is really small. If your server need to handle thousands of new connections per second, you need far more memory to be able to efficiently push data to clients. The overhead of TIME-WAIT connections is negligible.

CPU On the CPU side, searching for a free local port can be a bit expensive. The work is done by the inet_csk_get_port() function which uses a lock and iterate on locally bound ports until a free port is found. A large number of entries in this hash table is usually not a problem if you have a lot of outbound connections in the TIME-WAIT state (like ephemeral connections to a memcached server): the connections usually share the same profile, the function will quickly find a free port as it iterates on them sequentially.

Other solutions If you still think you have a problem with TIME-WAIT connections after reading the previous section, there are three additional solutions to solve them:

• disable socket lingering,
• net.ipv4.tcp_tw_reuse, and
• net.ipv4.tcp_tw_recycle.

Socket lingering When close() is called, any remaining data in the kernel buffers will be sent in the background and the socket will eventually transition to the TIME-WAIT state. The application can continue to work immediatly and assume that all data will eventually be safely delivered. However, an application can choose to disable this behaviour, known as socket lingering. There are two flavors:

1. In the first one, any remaining data will be discarded and instead of closing the connection with the normal four-packet connection termination sequence, the connection will be closed with a RST (and therefore, the peer will detect an error) and will be immediatly destroyed. No TIME-WAIT state in this case.
2. With the second flavor, if there is any data still remaining in the socket send buffer, the process will sleep when calling close() until either all the data is sent and acknowledged by the peer or the configured linger timer expires. It is possible for a process to not sleep by setting the socket as non-blocking. In this case, the same process happens in the background. It permits the remaining data to be sent during a configured timeout but if the data is succesfully sent, the normal close sequence is run and you get a TIME-WAIT state. And on the other case, you ll get the connection close with a RST and the remaining data is discarded.

In both cases, disabling socket lingering is not a one-size-fits-all solution. It may be used by some applications like HAProxy or Nginx when it is safe to use from the upper protocol point of view. There are good reasons to not disable it unconditionnaly.

net.ipv4.tcp_tw_reuse The TIME-WAIT state prevents delayed segments to be accepted in an unrelated connection. However, on certain conditions, it is possible to assume a new connection s segment cannot be misinterpreted with an old connection s segment. RFC 1323 presents a set of TCP extensions to improve performance over high-bandwidth paths. Among other things, it defines a new TCP option carrying two four-byte timestamp fields. The first one is the current value of the timestamp clock of the TCP sending the option while the second one is the most recent timestamp received from the remote host. By enabling net.ipv4.tcp_tw_reuse, Linux will reuse an existing connection in the TIME-WAIT state for a new outgoing connection if the new timestamp is strictly bigger than the most recent timestamp recorded for the previous connection: an outgoing connection in the TIME-WAIT state can be reused after just one second. How is it safe? The first purpose of the TIME-WAIT state was to avoid duplicate segments to be accepted in an unrelated connection. Thanks to the use of timestamps, such a duplicate segments will come with an outdated timestamp and therefore be discarded. The second purpose was to ensure the remote end is not in the LAST-ACK state because of the lost of the last ACK. The remote end will retransmit the FIN segment until:

1. it gives up (and tear down the connection), or
2. it receives the ACK it is waiting (and tear down the connection), or
3. it receives a RST (and tear down the connection).

If the FIN segments are received in a timely manner, the local end socket will still be in the TIME-WAIT state and the expected ACK segments will be sent. Once a new connection replaces the TIME-WAIT entry, the SYN segment of the new connection is ignored (thanks to the timestamps) and won t be answered by a RST but only by a retransmission of the FIN segment. The FIN segment will then be answered with a RST (because the local connection is in the SYN-SENT state) which will allow the transition out of the LAST-ACK state. The initial SYN segment will eventually be resent (after one second) because there was no answer and the connection will be established without apparent error, except a slight delay: It should be noted that when a connection is reused, the TWRecycled counter is increased (despite its name).

net.ipv4.tcp_tw_recycle This mechanism also relies on the timestamp option but affects both incoming and outgoing connections which is handy when the server usually closes the connection first⁸. The TIME-WAIT state is scheduled to expire sooner: it will be removed after the retransmission timeout (RTO) interval which is computed from the RTT and its variance. You can spot the appropriate values for a living connection with the ss command:

$ ss --info  sport = :2112 dport = :4057
State      Recv-Q Send-Q    Local Address:Port        Peer Address:Port   
ESTAB      0      1831936   10.47.0.113:2112          10.65.1.42:4057    
         cubic wscale:7,7 rto:564 rtt:352.5/4 ato:40 cwnd:386 ssthresh:200 send 4.5Mbps rcv_space:5792

To keep the same guarantees the TIME-WAIT state was providing, while reducing the expiration timer, when a connection enters the TIME-WAIT state, the latest timestamp is remembered in a dedicated structure containing various metrics for previous known destinations. Then, Linux will drop any segment from the remote host whose timestamp is not strictly bigger than the latest recorded timestamp, unless the TIME-WAIT state would have expired:

if (tmp_opt.saw_tstamp &&
    tcp_death_row.sysctl_tw_recycle &&
    (dst = inet_csk_route_req(sk, &fl4, req, want_cookie)) != NULL &&
    fl4.daddr == saddr &&
    (peer = rt_get_peer((struct rtable *)dst, fl4.daddr)) != NULL)  
        inet_peer_refcheck(peer);
        if ((u32)get_seconds() - peer->tcp_ts_stamp < TCP_PAWS_MSL &&
            (s32)(peer->tcp_ts - req->ts_recent) >
                                        TCP_PAWS_WINDOW)  
                NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
                goto drop_and_release;
         
 

When the remote host is in fact a NAT device, the condition on timestamps will forbid allof the hosts except one behind the NAT device to connect during one minute because they do not share the same timestamp clock. In doubt, this is far better to disable this option since it leads to difficult to detect and difficult to diagnose problems. The LAST-ACK state is handled in the exact same way as for net.ipv4.tcp_tw_recycle.

Summary The universal solution is to increase the number of possible quadruplets by using, for example, more server ports. This will allow you to not exhaust the possible connections with TIME-WAIT entries. On the server side, do not enable net.ipv4.tcp_tw_recycle unless you are pretty sure you will never have NAT devices in the mix. Enabling net.ipv4.tcp_tw_reuse is useless for incoming connections. On the client side, enabling net.ipv4.tcp_tw_reuse is another almost-safe solution. Enabling net.ipv4.tcp_tw_recycle in addition to net.ipv4.tcp_tw_reuse is mostly useless. And a final quote by W. Richard Stevens, in Unix Network Programming:

The TIME_WAIT state is our friend and is there to help us (i.e., to let old duplicate segments expire in the network). Instead of trying to avoid the state, we should understand it.

---

1. Notably, fiddling with net.netfilter.nf_conntrack_tcp_timeout_time_wait won t change anything on how the TCP stack will handle the TIME-WAIT state.
2. This diagram is licensed under the LaTeX Project Public License 1.3. The original file is available on this page.
3. The first work-around proposed in RFC 1337 is to ignore RST segments in the TIME-WAIT state. This behaviour is controlled by net.ipv4.rfc1337 which is not enabled by default on Linux because this is not a complete solution to the problem described in the RFC.
4. While in the LAST-ACK state, a connection will retransmit the last FIN segment until it gets the expected ACK segment. Therfore, it is unlikely we stay long in this state.
5. On the client side, older kernels also have to find a free local tuple (source address and source port) for each outgoing connection. Increasing the number of server ports or IP won t help in this case. Linux 3.2 is recent enough to be able to share the same local tuple for different destinations. Thanks to Willy Tarreau for his insight on this aspect.
6. This last solution may seem a bit dumb since you could just use more ports but some servers are not able to be configured this way. The before last solution can also be quite cumbersome to setup, depending on the load-balancing software, but uses less IP than the last solution.
7. The use of a dedicated memory structure for sockets in the TIME-WAIT is here since Linux 2.6.14. The struct sock_common structure is a bit more verbose and I won t copy it here.
8. When the server closes the connection first, it gets the TIME-WAIT state while the client will consider the corresponding quadruplet free and hence may reuse it for a new connection.

Piston, an Openstack-in-a-box vendor[1] are a sponsor of the Red Hat[2] Summit this year. Last week they briefly ceased to be for no publicly stated reason, although it's been sugggested that this was in response to Piston winning a contract that Red Hat was also bidding on. This situation didn't last for long - Red Hat's CTO tweeted that this was an error and that Red Hat would pay Piston's sponsorship fee for them.

To Red Hat's credit, having the CTO immediately and publicly accept responsibility and offer reparations seems like the best thing they could possibly do in the situation and demonstrates that there are members of senior management who clearly understand the importance of community collaboration to Red Hat's success. But that leaves open the question of how this happened in the first place.

Red Hat is big on collaboration. Workers get copies of the Red Hat Brand Book, an amazingly well-written description of how Red Hat depends on the wider community. New hire induction sessions stress the importance of open source and collaboration. Red Hat staff are at the heart of many vital free software projects. As far as fundamentally Getting It is concerned, Red Hat are a standard to aspire to.

Which is why something like this is somewhat unexpected. Someone in Red Hat made a deliberate choice to exclude Piston from the Summit. If the suggestion that this was because of commercial concerns is true, it's antithetical to the Red Hat Way. Piston are a contributor to upstream Openstack, just as Red Hat are. If Piston can do a better job of selling that code than Red Hat can, the lesson that Red Hat should take away is that they need to do a better job - not punish someone else for doing so.

However, it's not entirely without precedent. The most obvious example is the change to kernel packaging that happened during the RHEL 6 development cycle. Previous releases had included each individual modification that Red Hat made to the kernel as a separate patch. From RHEL 6 onward, all these patches are merged into one giant patch. This was intended to make it harder for vendors like Oracle to compete with RHEL by taking patches from upcoming RHEL point releases, backporting them to older ones and then selling that to Red Hat customers. It obviously also had the effect of hurting other distributions such as Debian who were shipping 2.6.32-based kernels - bugs that were fixed in RHEL had to be separately fixed in Debian, despite Red Hat continuing to benefit from the work Debian put into the stable 2.6.32 point releases.

It's almost three years since that argument erupted, and by and large the community seems to have accepted that the harm Oracle were doing to Red Hat (while giving almost nothing back in return) justified the change. The parallel argument in the Piston case might be that there's no reason for Red Hat to give advertising space to a company that's doing a better job of selling Red Hat's code than Red Hat are. But the two cases aren't really equal - Oracle are a massively larger vendor who take significantly more from the Linux community than they contribute back. Piston aren't.

Which brings us back to how this could have happened in the first place. The Red Hat company culture is supposed to prevent people from thinking that this kind of thing is acceptable, but in this case someone obviously did. Years of Red Hat already having strong standing in a range of open source communities may have engendered some degree of complacency and allowed some within the company to lose track of how important Red Hat's community interactions are in perpetuating that standing. This specific case may have been resolved without any further fallout, but it should really trigger an examination of whether the reality of the company culture still matches the theory. The alternative is that this kind of event becomes the norm rather than the exception, and it takes far less time to lose community goodwill than it takes to build it in the first place.

[1] And, in the spirit of full disclosure, a competitor to my current employer
[2] Furthering the spirit of full disclosure, a former employer

comments

I realised yesterday morning that I will have biked up Hawthorne Road at least once a day for 5 days in a row by tomorrow (unless it happens to rain). It's not a bad hill, really, it has a sort of a stair-step gradient. There's a short, gentle incline, just to get your heart going, then there's a flat bit, to recover, then there's a less friendly incline, which is both more unfriendly and longer. Then you get to the top, gasping for breath, before there's a short decline and usually a red traffic light. This morning I had the bright idea of leaving the bike trailer at Kindergarten, so it made the journey home much more pleasant, as was the aforementioned climb up Hawthorne Road in the afternoon. I spent the day doing Debian stuff, but unfortunately didn't result in a package upload to show for it. Library packages are tricky, and I'm far from experienced or competent at maintaining them. Zoe didn't nap today at Kindergarten, and wasn't too worse for wear for it. When we got home, Zoe wanted to make a crown for Mummy like the one she made at Playgroup last week. Unfortunately we didn't really have any good crown-sized paper, so I made a little crown out of some surplus Letter-sized paper, and then Zoe decided to do some painting. The painting devolved into a lot of hand painting of her cardboard box rocket, inside and out. We managed to keep the mess to a minimum. After we cleaned up, Zoe watched a bit of TV, and my girlfriend came over and together we all made a vegetable stir fry for dinner. After dinner we walked down to the Hawthorne Garage to get some unwanted cardboard fruit boxes, to help with packing for our two night trip to Coochiemudlo Island later this week. Bedtime went pretty smoothly. Zoe managed to get a bunch of insect bites yesterday, which was the cause of a 4am wake up this morning. They're still giving her grief, so I'm expecting some sort of disturbance overnight tonight.

This morning I noticed some parking bays reserved for car charging in a car park at the corner of Sydney Rd and Glenlyon St in Brunswick (near Aldi). One of the parking spots was occupied by a Plug-in Prius from GoGet [1]. I didn t even realise that you could get a plug-in Prius in Australia. The charging station is run by Charge Point [2]. The charging points are about 1.5m high and the cable is about 3cm thick (about as thick as the pipe used for filling a car with petrol), so it would charge a car much faster than could be done with a regular power point. One big problem with the Charge Point web site is that they don t give any information on pricing. They sell home charge points (which I guess means just an all-weather two-phase power point) but don t give a price for that. They sell charge points that can be used by commercially but don t give a price for them either. Also their infrastructure for billing is apparently based on companies installing charge points and setting a price for the service. Some charge points may offer free service (I guess staff car parks and some government agencies) and others will charge varying rates none of which is available on the web site. Apparently they have an online portal which gives information on such things to registered users so you have to register to discover what it costs. Of course hardly anyone is going to register before discovering the price, not even when registration is free. But while registration is free the web site demands the make and model of the electric car, so presumably one has to spend $40,000 or more on a vehicle before discovering the price and availability of charging it. Charge Point can be used as an example of how not to design a web site that promotes a service, or at least how not to promote a service that is aimed at saving money (electricity is significantly cheaper than petrol so it s of interest to people and organisations that want to save money). The Charge Point site seems to be better suited to showing that the concept can work than convincing people that they should sign up for it. It seems to me that the best thing that they could do would be to prominently display the average cost of all non-free charge points that are open to the public along with an explanation of the price of driving a desirable car (such as a plug-in Prius or a Nissan Leaf) with such an electricity cost. The contact section on the web site only has a link for careers . I don t think it s possible to get widespread use of electric vehicles without getting better information out there. It appears that Charge Point is relying on councils to do the work of promoting their business by installing their stations and reserving car parking as Moreland council has done in this case.

• [1] http://www.goget.com.au/
• [2] http://www.chargepoint.com.au/

I am happy to announce the release of OASIS v0.4.2. OASIS is a tool to help OCaml developers to integrate configure, build and install systems in their projects. It should help to create standard entry points in the source code build system, allowing external tools to analyse projects easily. This tool is freely inspired by Cabal which is the same kind of tool for Haskell. You can find the new release here and the changelog here. More information about OASIS in general on the OASIS website. Here is a quick summary of the important changes:

• Change BSD3 and BSD4 to BSD-3-clause and BSD-4-clause to comply with DEP5, add BSD-2-clause.

BSD3 and BSD4 are still valid but marked as deprecated.

• Enhance .cmxs supports through the generation of .mldylib files.

When one of the modules of a library has the name of the library, ocamlbuild tends to just transform this module into a .cmxs. Now, the use of a .mldylib fix that problem and the .cmxs really contains all modules of the library.

• Refactor oasis.cli to be able to create subcommand plugins.
  • Exported modules starts now with CLI.
  • Display plugins in the manual.
  • Design so that it is possible to be thread-safe.
  • Try to minimize the number of functions.
  • Make better choice of name and API.
  • A subcommand plugin 'dist' to create tarball is in preparation, as a separate project.
• Remove plugin-list subcommand, this command was limited and probably not used. A better alternative will appear in next version.
• Sub-command setup-dev is now hidden and will soon be removed.

I have published a quick intermediate version 0.4.1, a few days after the previous release. This was a bug fix related to threads. I also decided to skip the release of last month. I was in the US at this time and didn't have time to work enough on OASIS (christmas vacation and a travel to the US). This month I am back on track. This new version doesn't feature a lot of visible changes. I mostly work on the command line interface code, in order to be able to create external plugins. A first external plugin is almost ready, but need some more polishing before release. This first plugin project is a port of the script that I have used for a long time and that was present in the source code of oasis (oasis-dist.ml). It will be a project on its own and have a different release cycle. The point of this plugin is to create .tar.gz out of an OASIS enabled project. I also must admit that I am very happy to see contributors sending me pull-request through GitHub. It helps me a lot and I also realize that the learning curve to enter OASIS code is steep. This last point is something I will try to improve.

So finally I did it, I managed to ride the 2-wheeler in Bangalore roads!. Officially I've got a license to drive 2 and 4 wheelers back in 2011 but I was never confident enough to ride the vehicle on road and in traffic. Partially this is because I don't own a vehicle and I've never practiced driving, and partially because of road and traffic conditions in India I was bit afraid to do so. So today morning my roommate and me planned to go to temple in the early morning. We got up at 530 in the morning and we were ready to drive to Mahalaxmi Layout at 615. Since during this time traffic is very less I asked my roommate shall I drive and he agreed!. So I drove the bike from Malleshwaram to Mahalaxmi Layout and it was fun. I did had hick up in uphill driving as my mind was not co-ordinating well with breaks and gear. I did have hickups in first gear too but I guess this will be alright once I get hold of things. I'm still not having enough confidence to drive during the peak hours because people are not at all following traffic rules. They just change the lane without any hints or just come to middle of road from side roads without looking at other side to see if there is a vehicle is coming from other side of the road (yes they don't have courtesy to wait). And finally they can shout at persons who is actually following rules. In general very less people have traffic discipline in India. But I will adapt to this once I start driving so I'm now all set to get my 2 wheeler soon and ride on!

I vote for Martinique.

Today was a pretty good day. I've found that I quite enjoyed it. Zoe woke up a bit early, around 5:30am. She decided that despite the ridiculous heat, she wanted porridge for breakfast, with cherries in it, so we pitted the cherries and threw it all into the Thermomix to cook while she got dressed. After breakfast and the obligatory bit of TV, we biked over to Playgroup. Zoe's got a few toys that she's taken a liking to, and immediately sought them out. She also seems to really enjoy just running the length of the hall after Playgroup is all done and everything has been packed away and most of the kids are gone. Today the craft activity was making paper crowns, and she wanted to that immediately upon arrival. After we got home, while I was preparing lunch, she blinged it up a bit more with some stuff from home. She took a 2 hour nap after lunch, and I did some more work on my taxes, and then, because it was still stupidly hot, we biked over to Colmslie pool for a swim. Zoe's swimming progress continues in leaps and bounds. She's had one lesson at her new level, and she's started with a kickboard and is doing strokes, so I borrowed a kickboard from the pool, and she did really well with it. We also just fooled around with the kickboard a bit. I took it to the bottom of the pool and launched it out of the water with its own buoyancy, and Zoe tried standing on it under water like a skateboard. The sinkies were also popular again. We grabbed a few things for dinner from the Hawthorne Garage on the way home, and I managed to get Zoe to bed a little bit early. I thought I was going to have a smooth bedtime, but unfortunately, as is a common occurrence at the moment, after lights out, she started crying for her mother. It took about 15 minutes to get her from near-hysterical to calm and drowsy. I'm starting to think I might need to either shorten or eliminate the afternoon naps. One of her complaints recently has been that she's had trouble sleeping at bedtime. That said, she still seems to get to sleep relatively quickly once she gets into the right frame of mind.