Moving Away From Open Source

This entry over at IT world discusses some of the forces behind users that fully intend on using an open source application and make the jump over to the proprietary software world instead. It seems counter-intuitive that any user would will give up something that is free just to pay for it. But as the entry states, there are many reasons users do this. Open source applications tend to have a lack of support, lack of features, and lack of documentation. Oddly enough, there are some open source applications that share the same qualities as their proprietary counterparts. They both have a great feature set, documentation, etc. But like all software, the subtle differences can simply make one application better than the other.

The biggest stumbling block is installation and initial configuration of open source applications as far as I'm concerned. Proprietary installation and configuration procedures are generally a more enjoyable procedure. This is the first step to using any application and is important to get right because it gives the user an impression of what the rest of the application experience is going to be like was it actually gets installed if ever.

More Linux help for Windows users

Just further proof that if you are a Windows user, there is light at the end of the tunnel toward using an entirely open source computing environment.

A good entry, targeted toward Windows users, explains how software is installed on Linux distributions. A great introduction to package managers.

ECP update

Over the last week or so, the ECP development team has been fixing several issues brought about by the ECP user community. One issue that has been resolved I'd like to point out.

The problem here is that during the ECP installation procedure, any existing Libvirt domains will be imported into the database. Obviously, the machine table must already exist in the database. When the user hits the "/install" url, the installer is run. The user may perform this action even after all the ECP database tables have been defined. This way, any Libvirt machines that have been created by some other machines may be imported.

One of the problems with this method is that sometimes, the machine import functionality is executed before the machine database table exists. Another requirement of the machine import functionality is that the local machine database record has been inserted into the machine database table. This is needed to determine what hypervisors are available on the local machine.

The fix made in this case was to check in the machine table exists. ECP cannot execute this functionality without it. Second, ECP will no longer assume that the local machine exists in the database. It will now check for both the machine table and the local machine record. If either is false, no machines will be imported. In this case, the "/install" url can always be reloaded once the required tables and records have been created.

So, how do we end up in a situation like this in the first place? Shouldn't the ECP installation functionality always ensure that the required data exists before it is needed? This is a perfectly valid concern and the installer does work this way. The table creation is the first task executed by the installer. Then, important records such as the local machine are inserted. The only way this ordering can be altered is if some extension functionality "hooks" into the installer. The hooks have a choice as to the order in which the "hooked" method is executed. The original invocation may happen before the new functionality or after. It is entirely the responsibility of the extension module to ensure that nothing is interrupted in the original behaviour.

That being said, there are several extension modules distributed along with ECP and we'll be keeping a close eye on those as usual. If anyone has noticed a potential defect in a core extension module, feel free to report it here.