Buffalo Ships DD-WRT

Looks like Buffalo is doing the right thing – shipping dd-wrt with its routers. While I have been a fairly loyal Buffalo customer and own several of their routers, honestly, I have been running all of them on dd-wrt. The only reason why I have been buying Buffalo is because they are the cheaper option to running dd-wrt than say, Linksys. So, by shipping dd-wrt on its routers, it will make life easier for me in the process.

DD-WRT is an Open Source project that provides firmware for running wireless routers. These firmware are based off a Linux kernel, which gives them a lot of power and functionality. For example, it can support VLANs, advanced firewall and routing capabilities and much more, on commodity hardware. Most of its features are available on premium commercial hardware.

I will not buy any router unless it supports dd-wrt. In Malaysia, this essentially limits my choices to Linksys and Buffalo. Buffalo wins on price because the features will be the same as long as they both run the same firmware. But why this obsession with running Linux dd-wrt on routers? It is all a question of control. I like having control over my hardware – including my routers.

For example, I configured my router to dynamically route all web traffic from my network via a transparent proxy server. This benefits all the machines running in my home network as I would not need to configure each machine individually. Everything is automagically cached in my proxy server. So, when I watch a YouTube clip, I can keep watching it again and again without having to reload it from the Internet. I also like the built-in PPPoE and dynamic DNS clients. I use it to maintain the connection to this very blog. Without it, you would not be able to find my blog at all.

If I did not have dd-wrt running on my router, trying to get these feature would be a chore, if it was at all possible.

The question then is why did Buffalo not do it from the start. I think that they have finally realised the advantages of using dd-wrt instead of building and maintaining their own firmware. You need a lot of resources to do that. It would be far easier for them to just customise a dd-wrt firmware with their logos and stuff while leaving all the hard work to the people who are actually passionate enough to work on it. In addition, they may want to consider hiring some permanent staff to contribute to the dd-wrt stack.

All in all, open source actually works better as long as people can change their mind-set on keeping everything to themselves.

The Plan

Alright, I have just created a bunch of repositories on Gitorious for the purpose of managing my multiple projects. My long-term plan is to create an entire stack – from the hardware system all the way to the operating system and application software. The ultimate goal is to be able to run Android on an entirely open stack.

At the moment, the AEMB is the world’s smallest and fastest multi-threaded 32-bit RISC embedded processor. I plan to make some changes to it – integrating some of the ideas that I have had previously such as:

  • Threads – increasing the thread count to four in hardware and to unblock the threads so that they are not interlocked.
  • Compiler – make an LLVM compiler back-end to divorce ourselves from the existing GCC compilers in order to integrate atomic operations.
  • Startup – integrate an in-cache execution environment during pre-boot stage to take off some of the hardware load.
  • Kernel – write a small nano-kernel that abstracts away much of the hardware stuff in order to allow higher level code to integrate better with it.

There is a lot of work involved and I am open to participation – particularly on the software side. If anyone is interested, that is.

Understanding your Compiler

I just came across this set of slides on source code optimisation and I have to agree with the lesson to take away – that is to understand how your compiler works. I do this very often as I have to work with really low-level code at the microprocessor level. So, I need to understand how the compiler works in order to generate the correct sequence of codes.

I thought that I should share this piece of gem here.

The key thing to remember is that the compiler will always generate code depending on what it thinks you are trying to do. While early optimisation is the root of all evil, coders need to help the compiler along by writing code in such a way as to make it easy for the compiler to figure out what it is that we want it to do. If we left everything to be decided by the compiler, we would ultimately end up with code that works, but not optimally.

This is a particularly big problem in the embedded world.

The only way to learn how the compiler works is to decompile and disassemble code – not by reading the above slides only. I primarily work with GCC compilers and I always compile it with the -g flag turned on to generate debugging symbols. This makes it much easier for objdump -dSC to give me human read-able assembly output. Do this for different code paths and we will soon begin to understand how the compiler interprets our code.

Then, the only issue that matters is the purpose for optimisation – size, speed or power.

WordPress on PostgreSQL

PostgreSQL rocks!I thought that I should plug this WordPress plug-in. It is a PostgreSQL compatibility layer for WordPress. I have to say that it seems to work as advertised thus far – this blog runs on it.

I have been trying to find a useful compatibility layer for moving various web applications over to PostgreSQL for quite some time now. I experimented with SQLRelay and it seemed to work fine stand-alone but I had a lot of trouble trying to get it to work with FastCGI on Lighttpd. Setting the appropriate environment variables seemed to do nothing for it.

The reason for this switch is numerous, mainly due to standards compliance and stability. However, the recent takeover of Sun by Oracle did it for me. I do not see how MySQL is going to survive the exercise unscathed. I just hope that the compatibility layer works well enough to sustain this blog for a long time.

Licensing Open Source Software

Disclaimer: I am not a lawyer.

I have recently been approached by several people with regards to the licensing of open source software (OSS). Proprietary companies have no problems stealing open source software for their use but when it comes their turn to sell their solutions, they try to get away with hiding the OSS. This is not only wrong but is actually illegal.

I have been personally told to breach the GPL and I have pretty much told my boss – over my dead body. Just because it is an instruction from the top does not absolve me of the action. I will still be the one responsible for installing DRM onto our GPL derived product.

I have come to realise that most people have many misconceptions on OSS because they tend to lump all OSS together in one homogeneous fold. Unfortunately, there are over 60 different OSI approved open source licenses at the time of writing and they are as heterogeneous as can be. However, they all have exactly one thing in common and one thing only.

I need to make this one thing very clear – OSS licenses are all distribution licenses – they only come into effect when you decide to give away your product whether paid or otherwise.

On one extreme, you have the extremely permissive OSS licenses such as BSD and gang. What this license essentially means is that you are pretty much free to do whatever you want with it, including using it in commercial products without giving away your source code. However, you will need to mention in your product and documentation that you are using the BSD code and that the original authors are exempt from all liabilities.

This is one of the easiest OSS licenses to use in proprietary products. Just take the code, do what you need with it and then sell it. All you need to do is to mention that you have used that code and promise that you will never sue the original authors. That’s it!

On the other extreme, you have the extremely viral OSS licenses such as GPL and gang. This is the license that Steve Balmer calls a cancer because it is infectious. It is very clear in the language that any software that contains GPL code must be at least as free as the GPL and no distribution rights can be taken away from the customers.

This essentially means that if you use GPL code in your product, you cannot do anything that will prevent your customers from using that code in whatever way that they like. GPL3 has very specific language that nullifies patents and attacks digital rights management. In fact, you cannot even stop your customer from reselling your product ad verbatim if they want to.

One misconception that most people in Malaysia have is that OSS is a development license – meaning that if they do not make changes to the original code or develop it, there is no need to open source it. This is only true for LGPL and gang, which require all changes, modifications and additions to the original code to be given away as LGPL. However, it is untrue for either of the previous extremes.

The trouble with most proprietary businesses in Malaysia is that they do not comprehend OSS. OSS licences do not prohibit you from charging money for your products. In fact, you are encouraged to charge money for it so that you have clear proof of distribution, which means that the OSS license can be clearly enforced. You will find open source companies worth billions of dollars amongst the Fortune 500.

Professionally, I always recommend that my clients stay away from GPL code unless they know exactly what they want to do with their products. There is nothing wrong with GPL except that staying away from it gives us flexibility to decide on whether or not to distribute our source code later – once there is a clear business case for it either way.

I was recently told by a colleague that he was informed by legal that we should give away our GPL derived code but practically, we would not need to. That is the kind of legal-doublespeak that makes me hate lawyers.