OLS Paper Nearly Complete!

I have managed to do it again. I’ve overloaded myself w/ too much to do, with too little time. Thankfully my biggest near-term concern is nearly complete. My OLS paper is almost finished. The paper is on the genetic-library in the Linux kernel. It will be very useful for people to learn about the genetic-library and hopefully show how beneficial it is.

The biggest problem I have encountered is a regressions in performance results on the Zaphod CPU plugin. I was getting only 1%. Thankfully, my co-author, Peter Williams, was able to track down a bug in the run-delay calculation, and get the results back up to the >3% that I was originally seeing. I also noticed a trend towards the Zaphod plugin doing very well in higher CPU loads.

The best news I have gotten from doing this paper is stellar results in the Anticipatory I/O scheduler. On average, I was seeing 8.72% improvement, and up to 23.22% improvement in the random write workload.

The next thing I need to look at is a combination of RAID’d and unRAID’d disks. I was seeing huge fluxations in results on Anticipatory (which should not be used on RAID’d disks in the first place). I am theorizing that because the genetic-lib is per I/O scheduler, that it bounces back and forth for tuning for the individual SCSI disk, and then tries tuning for the RAID’d disks. Which one is tunes for depends on which one is getting more I/O. I will have to granularize the genetic-lib to operate on a per-disk basis. Thankfully there has been some support put into the kernel recently.

Watch http://linuxsymposium.org for updates.

I will hopefully have some time to do some more development work on the genetic-library soon, and a new version coming out soon.

Future of Software

After listening to Jon “Maddog” Hall give a speech on open source in emerging countries, I thought about a point that he touched on that was very interesting. In the future, the current model of closed sourced proprietary software will not work. Because of open source software, business models will have to change.

Before we look at the future, we need to look at the past. Back in the 1960’s all software was essentially open. It was developed by small software houses creating very specific software tailored to the customer’s needs. The customer kept the source code, and could make changes to it as needed. It was not until the 1980’s and the development of micro-computers when software companies started packaging general software that all customers might be able to use. Because the software was not for any specific customer, they closed the source to protect trade secrets and other IP. This practice of general software has continued to the present day. The problem with this current closed-source model is that if a customer wants a specific change, a bug fix, a new feature, or a new language, it is very difficult to get closed source software companies to make the changes in a cost effective and timely manner. Most of the time, it’s not in their “best business interest” to make the change. So customers have no option to get the change they need.

Now bring in open source software. If a customer uses open source software they have the freedom to make a change if they want. They have the freedom to get a timely bug fix, to support a obscure language, or tailor the software to their specific needs. To hire a developer may cost them money, but they have the business option to do so. Most of the time, it is far cheaper to hire a developer to tailor open source software to their needs then to buy the proprietary software in the first place. Now the customer has software that does exactly what they want.

I believe that open source software will continue to get better and better to rival anything that Microsoft puts out (arguably already does). Why would customers want to pay exorbitant amounts of money for sub par in-flexible software. I believe that as more and more customers move to using open source software, that the software model will move back to the one that existed in the 1960’s. Customers will hire software houses to take open source code, and tailor it to their specific needs at a fraction of the cost. They can keep the changes and update the code base as needed. The current closed-source software model will not be able to exist.

Greater Productivity Innovation: E-Mail or Instant Messaging?

Consider what has increased productivity more, email or instant messaging. While email has done away w/ paper memos and snail mail, I would argue that it has decreased productivity because it is so effective. Now we get information overload with the shear ease of getting added to the CC line. The greatest abuse of a company’s time is employees trying to wade through their inbox. Over the past five-years we have progressed to this information overload. Remember the days when getting an email was so infrequent that it was possible to still get a “You got mail.” sound byte or a pop-up. I know I did away w/ those mail indicators years ago.

Now consider the benefits of getting instant information via the telephone call. It was targeted at one individual who could actually help, and there was not the delay of an employee getting to an email in the inbox ocean. Instant messaging improved on the idea of the telephone by increasing the number of conversations that could happen simultaneously, while also saving time on looking up a number and dialing. I know that instant messaging has reduced the number of telephone calls I receive to virtually zero, and allowed me to get targeted questions w/o bothering other people on the CC list. While instant messaging still has drawback of chatty friends, in a pure business environment, it is the greatest productivity innovation in the past 30 years.

Capitalism includes programmers

Every time I fly back to Michigan to visit family, I get asked about all the programming jobs being moved over to India. I do see it happening at IBM where more, and more jobs are being moved to India and China.

My response every time is the same. If you are a good programmer, you will always have a job, regardless of what gets moved to India. Good programmers are hard to find whether it’s in the US or in India. And at the risk of angering anyone in India, I do not believe that there is a high level of quality code coming from India. That is not to say that India will not develop their programming skills, but today I much rather have code from the US.

To be honest, it does not really bother me that corporations are moving jobs to save money. This is the type of capitalism that made our country. Would it not be hypocritical to naysay it now?

Putting aside the humanistic views, moving programmers overseas is not that different from corporations moving manufacturing to China to reduce cost. What is the difference between high volume, low quality code and high volume, low quality parts?

Next Entries »