smashedbug.com, tech music and geek news

After the SCO vs IBM controversy wound down, the FUD (fear, uncertainty and doubt) put out by Microsoft seemed to be at a lull (perhaps they were focusing on getting their Windows Vista gorilla ready for umm.. beta testing..).

But it appears that they are back! Hurrah.

Officials of the Commonwealth of Massachusetts have proposed a new policy that mandates the use of open standards. In particular, the policy recommends the use of the OpenDocument format — a format designed to allow productivity suites (such as OpenOffice, StarOffice, Microsoft Office, etc..) to utilize this format as their native format and as an extension, a compliant OpenDocument application could read and write documents from other products.

It largely makes sense. This is similar logic to how the Internet functions. For example, web pages written to open standards can be displayed on a wide range of browsers from different vendors, on different platforms, etc. The core files are supported by a wide range of editing tools that can interact and read each others web page (HTML/CSS) files. As a result of these open standards, there is healthy competition. Extend this out further to the rest of the Internet and many technologies such as TCP/IP, DHCP, DNS, e-mail (SMTP/POP/IMAP), file transfer (FTP, HTTP, Bittorrent, P2P), network cabling, wireless are all built on open standards and as a result, it is possible to have millions of very different computers and devices communicating with each other with ease.

On the Fox News website, there is an article titled Massachusetts Should Close Down OpenDocument which argues that open formats are bad. While this is clearly Microsoft FUD (the author, Jim Prendergast, is executive director of Americans for Technology Leadership — a Microsoft founded organization) I– I believe it is important to outline the issue to provide a “fair and balanced” view on the topic.

Officials in the state have proposed a new policy that mandates that every state technology system use only applications designed around OpenDocument file formats

False. They promote the use of open standards. OpenDocument just happens to currently be the leader in open productivity suite formats and has the most support by existing applications (OpenOffice, StarOffice, KOffice with Abiword, Gnumeric and others following).

The policy promises to burden taxpayers with new costs and to disrupt how state agencies interact with citizens, businesses and organizations.

False. The reluctance of Microsoft to support open standards has caused this to happen. If Microsoft Office supported an open standard format, there would be no need to change. The fact that alternatives exist and are making inroads on Microsoft’s Office monopoly indicates this is the correct move — the government needs to provide equal access to this information and should not be able to mandate the use of a closed format that is only fully supported on a closed operating system (Windows).

Worse, the policy represents an attack on market-based competition, which in turn will hurt innovation. The state has a disaster in the making.

False. Mandating the continued use of a vendor specific, patent-encumbered file format has killed market-based competition. The use of an open format provides an opportunity to rejuvinate competition (right now OpenDocument has more productivity suites that provide full support for it than Microsoft Offices’ file formats).

Until now, Massachusetts’ citizens and government agencies have been well served by a competitive, merit-based procurement process for technology services. Agencies can turn to the marketplace—often to small state-based systems integrators—and receive bids for the best solutions at the best price to meet specific needs.

“I need a program to open up .XLS and .DOC formats with macros..” .. exactly what are your options besides Microsoft Office?

The proposed policy throws out this system, and instead makes the blind pre-determined selection of applications using the largely immature, rarely deployed OpenDocument technology.

Once again, its not exclusively OpenDocument technology. Thats the nice thing about open standards.. they do get updated and change to accomodate the marketplace without the risk of litigation (patent infringement, etc..) that is a common practice by Microsoft and other anti-open standard supporting entitites.

I really hope to see Massachusetts sticking with their plan and using open standards. The use of open standards and the interoperatability it provides has many exciting consequences (particularly the creation of automated tools that can generate these formats from a wide variety of data sources w/o the need to purchase and maintain an expensive and complex office suite).

As you may recall, back in May I was involved in a Windows network deployment. At the time, there was much touting of the almighty “MSI” format that would ease administrative woes. As you may remember, the almighty MSI format turned out to largely be a PITA. Only a very small subset of my software was provided in MSI format, I was unable to consistently create MSI files and certain vendor provided MSI files simply did not work as anticpated.

As a result, instead of having an environment where all software was based on MSI packages so I could centrally validate files and distribution, the environment ended up consisting of a handful of different methods including MSIs, network based installs and CD based installs. As a result, a significant segment of the software requires manual installation on each computer — luckily with the use of rdesktop, this isn’t a major issue, but it does require a significant amount of time and is prone to errors and no validation of the installed sources.

So how does this compare to FreeBSD’s method?

Software installed on FreeBSD is located in the ports system. The ports system includes over 13,400 titles. This includes everything from basic utilities to services (web server, ftp server, mail, print, file servers, etc..), desktop environment, games, etc. Utilizing the portinstall command, it will install the software and any dependencies the software requires, automatically (compare this to certain Windows applications that require you to download and install additional software before the application will install).

Once installed, the software is fully managed. When the ports are updated, use of the portversion command will quickly provide a list of software that has a new version. With the portupgrade command, the software can be updated simply and easily.

This is great for a single system, but how about multiple systems — lets say a small network of a few dozen computers or perhaps thousands of systems throughout the world? Piece-of-cake.

When a port is installed, configuration options are set that may impact what aspects of the software are installed. Once this is complete, it is possible to package up all the files that the port installed into a compressed file called a package (pkg_create). A one line command can create a package for each application installed on the system.

Once the packages are created, there is a lot of flexibility for updating other systems. This could involve setting up a push or pull deployment depending on the requirements. If a pull setup is desired, it is a simple matter of configuring the dependant/slave systems to point to your packages and grab the packages on a regular interval (daily, weekly, monthly). A push system might involve the use of rsync/ssh to login to the remote system and run the pkg_add command to update the software. Very straight forward.

As all software is controlled by ports and packages, it is simple to do authenticity checks to verify files that belong to a package have not been changed or altered. This is generally done during the periodic script (ie nightly script) and addressed in a report or forward to a logging server that may generate a master report (depending on the complexity of the network).

How about if you have a unique piece of software that does not have a port? Unlike MSIs, ports are fully documented at freebsd.org and can be easily created, basing a new port off an existing port’s files. Once the port is created, it is easy to have it build the package and receive all the benefits of the port/package management system.

Needless to say, I think the FreeBSD method is very cool. Use of ports allows me to synchronize as many servers as I want without too much additional effort. The Windows method when used with MSIs provides a similar level of flexibility (though the full use of MSIs seems to require a domain environment to be fully effective) but unfortunately, MSIs are not widely and consistently produced and as a result, multiple software distribution methods require much more overhead and most methods outside of MSIs and ports/packages do not allow for easy rollback which could cause significant issues if a deployment causes issues (conflicts, corruption, etc..).