Sean O'Donnells Weblog
I have been using a Linksys WRT54GS as my home Wifi router for quite some time, and up until recently it has been working splendidly. I flashed it with Sveasoft's firmware when I received it, was delighted with the additional options that provide, and other than upgrading the firmware every so often it has required no time or attention. In the last month I began to experience connection timeouts, generally poor latency and my laptops Wifi connection would intermittently time out. I spend a lot of time working on remote systems so this began to drive me slowly insane. I determined that the laptop itself was not at fault as using Wifi in other locations was trouble free. Plugging directly into my cable modem revealed that the connection itself was fine. So the problem was the Wifi router itself. At first I assumed that the router itself was simply old and dying. Rebooting it would generally give me at least a half hours grace before it began to act up again. I began looking for a replacement, but somewhere along the way I found this page on the DD-WRT wiki. It turns out that older versions of the router set a fairly small limit on the maximum no of connections , and time them out very slowly.
In the time since I originally got the router DD-WRT seems to have advanced far beyond the capabilities of the Sveasoft firmware. I upgraded to it, made a few changes to the IP Filter settings as suggested on the wiki, and its like I have a brand new Internet connection, everything is snappy and swift. Thank you very much to the makers of DD-WRT. One word of caution, at the bottom of that wiki page is a suggestion to overclock the CPU to help with a bug with large file transfers, it did not work for me and required me to hard reset the router to recover, so back up your configuration before trying it.
It all began when Ravi Mohan invited his readers to compare Ron Jeffries and Peter Norvigs attempts at building a Soduku solver. You really should read both attempts, as they are very educational, but to save time its pretty clear that Norvig wins by a wide margin. Many Test Driven Development fans took umbrage at the comparison and rushed to Rons defense. The most eloquent argument in Ron's defense I have found is Vlad Levins "TDD is not an algorithm generator". While well written Vlad's argument rings hollow to me, he seems to believe that an "Algorithm" is not normal code, that it is some sort of special case, and as such TDD is not the tool of choice as it is everywhere else.
Well, first lets ask , what is an algorithm?
Wikipedia's definition of Algorithm:
In mathematics, computing, linguistics, and related disciplines, an algorithm is a finite list of well-defined instructions for accomplishing some task which, given an initial state, will terminate in a defined end-state.
A finite list of well-defined instructions, this sounds like software. The definition is all embracing with little room for exceptions and special cases . There are well known and commonly used algorithms, such as QuickSort, that get taught in "Algorithms" Courses in "Algorithms" text books. But the truth of the matter is all code implements an algorithm of some sort. Those found in the text books are simply a list of algorithms that are generally useful in many projects, and so are worth teaching and passing on. When we develop something new, we take some of the well known algorithms, and mix them with something new, algorithms of our own creation.
TDD is presented as resulting in better more reliable code, which translates to better more reliable algorithms. And the contrast between Norvigs and Jeffries results shows that this is simply not the case. The cry of "Not an algorithm generator" is equivalent to saying you should not use TDD to write code if you don't already know how you are going to write it, if you are trying to solve a difficult problem for the first time do not use TDD.
I do not actually believe this to be the case. I am a fan of TDD and use it whenever possible, However I am also not adverse to sitting back and mulling over a problem for an hour or two in the middle of coding, call that design up front if you will, but Norvig's solution proves that this can also generate good results.
The real problem here is that TDD generated obviously inferior results in this case, and while Norvig did well, he did not provide a Methodology, after reading Norvig's article I know how to solve sudoku, but I don't think I can solve a completely different problem in a Norvig like fashion.
This is a challenge not only to TDD, but to the Norvig's of this world too. If TDD on its own cannot be relied upon to provide great results then there is something we are missing. Perhaps Agile needs a new practice, perhaps the Norvig's of this world need to document their thinking practices. I don't care where the answer comes from, but I want someone to teach me to think like Norvig.
Watching this sent a shiver up my spine. We have not been to the moon in a very long time. Since Concorde was retired we no longer have supersonic passenger aircraft. It almost feels like all of our technology is being focused inward. Where are the great dreams of exploration. Where are the moon bases? As a species we need to get off planet. More on NASA's plans to return here
We have not been to the moon in my lifetime. The last manned landing was in 1972, 35 years ago. Concorde first flew in 1969. Manned flight has been stagnating for far too long. I recently read Warren Ellis's Ministry of Space and felt a certain pang of jealousy. I was jealous I did not live in an age where we had boldly marched into the stars. With Burt Rutan's team winning the XPrize in 2004 and NASA looking serious about a return to the moon, maybe I will live in that time after all.
Mark Pilgram tells it like it is in a wonderful and delicious rant. I've already written about the low esteem in which I hold flash in general. Apollo, Silverlight, Flex and friends sink far below that.
From johnlittle.org, It would appear that Dell are about to offer supported, pre-installed Ubuntu on their machines. This is a huge step forward for Linux, I am a little cautious until I see the machines showing up on dell.com, but it does make sense that they are choosing Ubuntu as Michael Dell is already reported to be Ubuntu (at the time of writing it shows him as running Ubuntu Feisty on a Dell Precision M90). Hopefully with a manufacturer as big as Dell on board more and more hardware manufacturers will be forced to provide good (and with luck open) drivers for the platform.
Press release and video interview with Mark Shuttleworth on Dells website.