Open Warrior

For those of you who don’t know, Linux distribution Linspire has signed a deal with Microsoft.

The deal, like Novell and Xandros before it includes office document compatibility, instant messaging interoperability and collaboration on digital media. Again the big ticket part of the deal inlcudes patent covenants from Microsoft for customers operating the Linspire desktop.
http://www.techcrunch.com/2007/06/14/linspire-joins-microsofts-any-one-but-red-hat-group/

The official letter released by Linspire is available here:
http://www.linspire.com/linspire_letter.php

I’ve been thinking about this issue quite a bit today. My first reaction, like many others, was negative. However, I’ve put a bit more thought into it and now see how it can benefit the linux community while still staying true to open source philosophies (if not in the short run, then at least in the long run).

I have no doubt that including proprietary software in linux distributions will allow for better integration with proprietary systems and software, thereby increasing linux’s market share. Now that’s all very good, but I don’t think the community’s outcry is about market share. It’s more about denying users their freedom and “giving in to the enemy,” an argument which I believe to be valid. However, in my experience most first time linux users aren’t that concerned about their freedom. Usually they’re just fed up with Windows and are looking for an alternative, as was the case for me. But as people start using linux and free software (as in free speech), they start to understand the values of free software. Slowly these ideals grow in the mind of the free software user, and (hopefully) eventually turn them into free software advocates.

I believe that as long as there are movements such as the Free Software Foundation and linux distributions which remain true to open source philosophies (as I suspect debian always will), there will always be a truly free option when it comes to computing. And new users who come to believe that freedom in software is important, will ensure that the open source philosophies live on.

From my observations free software adoption usually follows a timeline which goes something like:
1. Use proprietary software
2. Use a mixture of proprietary software and free software
3. Start to understand the value of free software.
4. Switch to only free software and encourage others to use it and contribute to the community.

Deals such as those that commercial linux vendors make with Microsoft speed up the transition from only proprietary software use to a mixture of free software and proprietary software. Thereby speeding up the adoption of only free software.

Of course, there is always the risk that in the future the pool of free software users that believe in and encourage the free software philosophy will become diluted by those who know nothing of it. In the event that this happens people will stop seeing the need for open source software and start developing only proprietary software. Yet once again, the free software movement will pick up as remaining free software advocates fight for software freedom, and the cycle will repeat itself. Hopefully though, free software advocates will be successful in preventing this scenario from ever taking place.

A problem exists when it comes to package management. How does one resolve dependencies without an internet connection?

Package management has made the installation of linux software very easy. Tools such as dpkg, apt-get, yum and yast allow for the installation of packages with minimal hassle. No longer does one have to worry about configuring, compiling and installing with the familiar

~$ ./configure && make
~$ make install

Binary packages make it easy to distribute linux software, especially to people who aren’t very familiar with linux and want an easy solution for installing packages. However there is one problem with binary packages and general linux software installation…dependencies. Before I knew much about linux package management I would frequently run into dependency hell where every package had a long list of dependencies, and every dependency had dependencies, and it would go on forever[1]. Fortunately, most dependency issues nowadays are resolved by package management systems which just fetch the dependencies online and install them, without the end user having to worry much. But here arises a problem, especially in the developing world where internet access is scarce and expensive. What if the end user does not have internet access? It then becomes very hard to install linux software because there’s no easy way to resolve dependency issues. On several occasions I’ve driven to houses of friends who don’t have internet access to give them linux software binaries to install, only to get there to find they’re missing some crucial dependency making my trip a complete waste of time.

So I’ve come up with a solution, easypkg. Easypkg sets out to bridge the gap created when trying to install linux software when there’s a lack of internet access. At the moment it’s just an idea and I haven’t even started working on it, but I plan on starting soon because I see a definite advantage that can be gained from software of this type. I plan on first developing it for debian based systems first, and then if I see need, expanding it to others.

easypkg packages will be built in such a way that every package contains:
1. A standard debian binary package, and
2. The source code for (all) possible dependencies.
3. A dependency checking scheme

Here’s the logic. Debian binary packages are very quick and easy to install and therefore the main program which is being packaged will be in deb binary format. For the deb binary there maybe 1, 2 or even 10 dependencies. Some systems will have some of the dependencies installed, and other systems will have none of the dependencies installed. Because deb binary packages can get rather large it does not make sense to include all dependencies in binary form since the size of the easypkg package could become extremely large. Source code other other hand is usually nothing more than a couple of text files and generally quite small in size. Therefore, even if the source code for all the dependencies is included in the easypkg package, the final size will not be much greater than the size without it.

The dependency checking scheme will simply contain a logical way to check for dependencies on the host system.

An easypkg installation will then work as follows. The user has an easypkg package and tries to install it. The installation then start by checking for all required dependencies based on the dependency checking scheme. If it finds that a dependency is missing it adds it to a list of missing dependencies. Once the missing dependency list has been created, all the missing dependencies are compiled and installed. Then another dependency check takes place. If the dependency check passes then all missing dependencies were installed properly, and the installation of the deb binary can proceed as normal.

[1] See http://en.wikipedia.org/wiki/Dependency_hell for a detailed description of dependency hell.

A couple of months ago I had the idea to start up a site, openwarriors.org, which I would use to highlight “individuals committed to open source.” So I went ahead and registered the domain, uploaded a placeholder index page (which is still there) and waited for the right time to get started on the project.

Now that I’m on a seven week holiday I have the time to get started on my openwarriors.org project. However last night I started doubting the project, the reason being that if it becomes successful I won’t be able to sustain it, one because of the bandwidth costs and two because of the time that I’d need to put into it.

Since I’ve really been getting into open source hacking in recent times I decided to make my ventures into it’s world the focus of openwarriors.org and thus (for now) scrapping the original idea. So, I’ve started this blog on iblog.co.za and named it openwarriors.org. In this blog I will detail my experiences with open source hacking, primarily focusing on KDE and specifically KDE4. And thus I announce my holiday project: in order to get a good feeling for Qt and KDE4 development I’m going to develop a KDE4 Financial Calculator. For this project I’ll detail my setting up of KDE4 for development, the resources I use to learn how to create KDE4 applications and any other interesting things I might run into while experimenting.

However KDE won’t be the only focus of this blog, anything which I find interesting relating to open source software will be posted here, so keep a look out…