Category: Open Source

Libvirt vs Virt-Manager on Lenny and Lucid

I ran into this random problem with virtualisation recently. For some reason, I just could not manage the LVM storage pools on my virtualisation server from my workstation. My workstation was running on Kubuntu 10.04 and my server was running Debian 5.04 using virt-manager and libvirt on each.

This was a very weird problem because I could access the LVM if there were no allocated logical volumes in them. However, the moment there was anything in them, virt-manager would fail to start the storage pool. This was a really weird problem because I did not have this problem on some of my other installations.

After spending days digging into it, I found out the cause of the problem.

It seems that the libvirt people changed the protocol in version 0.5.0 and swapped the colon delimeter to a comma delimeter. The workstation had a newer version of virt-manager while the server had the older version of libvirt. So, all I had to do was upgrade the libvirt from lenny-backports and that fixed the problem entirely.

The reason why I had not seen this in some other machines is because of the hardware was different. On this particular server, the harddisk was not seen as /dev/sdaX but parked under /dev/blocks/XXX:X instead. So, that is why the confusion with the “:” (colon) came into the picture between the two different versions.

Stress.

Advertisement

Speaking at BarCamp KL

Should have named it Software instead of Layers!I gave a short 30-minute talk at BarCamp KL today. The title of the talk was “Open Source Hardware – non-Arduino”. My objective was to basically make people aware of Open Source Hardware and that we exist and it is not all about Open Source Software only. My secondary objective was to generate some interest in this area among the different people in Malaysia. I basically structured my talk and whipped together some slides in 5-minutes around the title – “Open Source Hardware”.

Hardware
First, I started by defining why Arduino is not Open Source Hardware. This falls squarely into the realm of embedded software programming. While you can work very closely with the hardware, you are still limited by the capabilities of the hardware. The actual layer that I talked about allows you to design the hardware itself. So, one is no longer limited by the hardware layer at all.

Hardware is further broken up into layers:

  • System – SystemC is the primary language used at this level to stitch up the software guys who code in low-level C/C++ and the hardware guys who talk a different language. It is mainly used for modeling rather than actual design.
  • RTL/Gate – Verilog and VHDL are the primary languages used at this level. This code can actually be translated directly into gates through a process called synthesis. This is the main area of work done by most digital designers.
  • Transistor – SPICE is the main language used. It allows you to model actual transistors by feeding in parameters such as gate length-width, source-drain sizes and dopant parameters. This is primarily the realm of analogue designers.

Source
Hardware design is similar to software work in a way. The flow is similar and the skill-set required is also similar. In software the general activities are: code, compile, debug and test. In hardware, the general activities are: code, synthesise, debug and test. The bulk of the difference is the process of translating code into hardware.

In software, the compilation takes the code and outputs a binary blob that contains the software bits. In hardware, the synthesis process takes the code and outputs a bunch of logic gates. These gates can then be mapped into real hardware implementations and plopped onto an electronic board.

Open
Of course, there are lots of open source hardware designs out there, mostly found on OpenCores.

I gave a guy the example of the Arduino. If you work with Open Source Hardware, you can actually build a super Arduino – take an open source AVR core and couple it with a ethernet core, a crypto core, a video core and then you’ve got a souped-up Arduino without the limitations. You have just opened up a whole new market.

There, a quick talk on Open Source Hardware.

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.

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.

Activating XenServer

I have recently been experimenting with Xen after spending a year with OpenVZ. I decided to try out XenServer instead of community Xen because of the commercial support available. XenServer is available for free but with certain limitations controlled by license.

However, I stumbled into problems activating the XenServer license. Turns out that if you wish to activate it, you can use the self-service page that they provided. Unfortunately, that page requires a certain file that can only be obtained by using XenCenter, which only runs on Windows.

It took a few days of looking for information on how to generate that file without XenCenter to no avail till I finally contacted Citrix on their forum and was asked to contact them directly. They told me that they will generate the license for me manually and they will put in a request to make available a non-XenCenter way of gathering the information required to generate the license.

I thought that it was pretty dumb for a virtualisation company to force its users to use Windows. However, since they were nice to me, I would give their product a chance. So, after waiting for a week, I finally received my license in the mail.

The license that they gave me is valid for a year and this buys me time because I think that I will move over to community Xen at some point. I do not wish to go through this hassle of generating manual licenses each year. This brings to mind the whole concept of licensing Open Source Software, which I shall write about later today.

Debian stable comes with Xen 3.2 at the moment while unstable has Xen 3.4, which has many more advanced features while XenServer comes with Xen 3.3. The next version of Debian is due to be released some time this year or early next year. So, I think that once Squeeze stabilises, I will migrate over to community Xen instead.

I think that controlling software distribution through licensing is dumb.