You can now find me at http://akatkinson.posterous.com. I trust my vast readership will go ahead and update their bookmarks accordingly (or alternatively wait for the redirect from akatkinson.com to update in their DNS and not notice a thing).

Thank you.

One of the most effective techniques throughout all areas of computer science is caching, and that is just as true in networking…

Recently companies have started providing CDROMs of entire Web sites to speed Web browsing. When browsing these Web sites, all the Web browser has to do is check the modification date of each file it accesses to make sure that the copy on the CDROM is up to date. It only has to download files that have changed since the CDROM was made. Since most of the large files on a Web site are images, and since images on a Web site change far less frequently than the HTML text files, in most cases very little data has to be transferred.

I have no recollection of ever encountering this, seeing as I was all of fourteen at the time this was written; maybe that’s why I find it amusing. It’s certainly a great example of Sneakernet in action, and it also illustrates just how much the web’s changed since, and and how unbelievably static is was in its original form.

As they say: never underestimate the bandwidth of a 747 full of tapes. Or, in this case, a postie bike.

Is it not that significant? Could Google do just as well? Or is this a significant moment in computer science history? I mean, while a game of Jeopardy isn’t the equivalent of the Turing Test, it’s impressive in its own right.

The CAP Theorem is the distributed systems version of the classic engineering maxim of “Good, fast, cheap: pick two”. Briefly stated, it declares that any distributed system may only have two of the following properties: consistency; availability; partition tolerance. It makes perfect sense when you think about it, as it’s logically impossible to remain both consistent and available in the case of the system becoming partitioned due to node failure/disconnections etc.

The case raised by Hale is that, for any distributed system, partition tolerance is not something that can simply be chosen. That is, disconnections and node failures etc are guaranteed to happen at some point in time. They are simply an annoyingly constant fact of life for anyone involved in the field. Therefore, any real-world distributed system must support some kind of fault-tolerance, otherwise it’s useless.

This means that the distributed systems designer is left to decide the following: given that system failures will occur, and your system may become partitioned, is your system going to degrade by sacrificing consistency, or availability? It depends on the system requirements as to which should be chosen, however it’s the unfortunate face that you simply can’t preserve both.

Given this, Hale suggests that a better way to think about handling failure is by using yield and harvest. Yield is defined as the impact of unavailability on handling incoming requests (related to but different to uptime), and harvest is a measure of how much of the required data is available to fulfil a request (ie. if a request needs to data from two servers, one of which is unavailable, the harvest will be only 50%).

Hale’s point is that you can choose which of these will be affected in the case of system failures and partitions. Is it better for some requests to be dropped in the interests of preserving accuracy (harvest), or can we handle a lower harvest in the interests of maintaining responsiveness? Again, the system requirements determine the answer.

I find this a very useful way to think about how a system is going to degrade when faults occur. After all, if you design something to be scalable (increase throughput as nodes are added) it makes perfect sense to consider how a system will degrade/scale down as nodes are lost. It can only be beneficial to be completely clear on the choices and tradeoffs involved, and that, ultimately, you can’t have your cake and eat it too when it comes to consistency and availability.

• Started out living in Napier, NZ, finished up in Brisbane, Aus. Miss some things about Napier, but no regrets. Brisbane is a fantastic place to live, and I’m not moving again in a hurry.
• Started out working as a lecturer at EIT, finished up as an engineer at Merge Gaming. Found that I was happy with the career change. No regrets at all.
• Also found that (thankfully) I still had my coding chops, and that I enjoy building software.
• Started learning about all the neat stuff that’s been happening in the industry that I missed due to a myopic focus on my PhD.
• Oh yes, officially (finally) graduated in April with a doctorate.
• Presented a paper at ACSW2010 in Brisbane in January.
• Started learning about web design and development, something I’d always done my best to maintain a militant ignorance about. Remedial education in HTML, CSS, Javascript. Always wanted to learn Python, so getting into Django. Turns out it’s all actually pretty fun.
• Started a little web project that I’d like to get finished over the summer.
• Haven’t got out mountain biking as much as I’d have liked, but discovered some nice trails around Mt Coot-tha. They’re not a jot on what I had on my doorstep this time last year though *sigh*.

So overall, it’s been a great year with a lot of change, all of which has thankfully turned out to be positive. Hopefully 2011 will be slightly less hectic but just as productive.

My answer (paraphrased) was that yes of course it, but the main hurdles would be the extra training and support students would required, particularly new students who find learning to program difficult enough.

Overall though, I think this is a simple yet effective way to tackle a widespread problem.

It also has related tutorials covering Pthreads, OpenMP, and MPI.

(via HN)

However the main thrust of the article is how banal and formulaic the vast majority of academic writing is, and it’s pretty much a plea for academic researchers (but could be just as easily applied to business writing/management-ese in my opinion) to inject some passion, creativity, and purpose into their writing.

Those other words, the long-form prose, the writing skills you should have learned in your “breadth” training, when instead somebody made you start focusing on your specialty: those are the only sword you are afforded, with which you might, possibly cut your way free.

Speaking as someone who’s worked in this area, and not that long ago struggled through the thesis-writing process which took far, far longer that it should have (and that, I admit, I did my best to make conform to the standards of academic prose that Tozier lambasts), this article really hit home.

Let’s be honest: anyone who’s been involved in any sort of research knows that academic conference and/or journal papers generally aren’t what you’d classify as page-turners. There’s a formula, the author(s) try to over-complicate things and obfuscate the flaws in the research, and generally try to stake their claims of originality, novelty, and significance in the driest way possible.

And who’s to blame them? We’ve all heard of publish or perish, and any writing which strays beyond the accepted norms will probably have a higher likelihood of being criticised by a referee, so there’s no wonder we have the current status-quo.

After reading this blog I remembered the best thesis I’ve read, which is Andrew Tridgell‘s, of Samba fame. His PhD thesis was actually very engaging and extremely readable. Consider the first couple of paragraphs in his first chapter:

My first introduction to the problem of parallel sorting came from a problem in the implementation of an automatic speech recognition training program. A set of speech data needed to be normalized in order to be used as the input to a recurrent neural network system and I decided that a quick-and-dirty way of doing this would be to sort the data, then sample it at regular intervals to generate a histogram.

This is a terribly inefficient way of normalizing data in terms of computational complexity but is a quite good way in terms of software engineering because the availability of easy to use sorting routines in subroutine libraries makes the amount of coding required very small. I had already used this technique in the serial version of the speech recognition system so it seemed natural to do the same for the parallel version.

With this in mind I looked in the subroutine library of the parallel machine I was using…

You want to read more don’t you? The guy is telling a story of how his thesis was formulated and the experiences which led to his PhD work. After a beginning like this you just want to read more. Tridgell’s writing is not exactly what you’d call traditional academic prose, however it would be very hard to argue that he doesn’t communicate his research any less effectively; many would agree that it’s a great improvement.

Tozier’s article is, I think, essential reading for any researcher looking to publish their work, and in particular those that are just starting out in the field. There’s nothing wrong with doing your utmost to write well, to create something readable and engaging, and going beyond the bare-minimum that’s required as dictated by the expected norms. And who knows, it might even actually benefit your IF!

I’m a big fan of using LaTeX for preparing any kind of significant document (ie. > 3 pages), and have used it for, among other things, two theses and several research papers. I’ve generally used LyX, or when that didn’t do what I needed it to, plain old LaTeX markup in gEdit (with plugins).

I have briefly tried some of the others on this list, namely Kile and Texmaker, but it wasn’t apparent to me that they’d be that much simpler or faster to use than what I was already using, so your mileage may vary. In any regard this is a great starting point for those getting started using LaTeX and looking for a decent editor.