For the past couple of years, the Ubuntu distribution from Canonical has been the the "cool" or, allegedly, "community-focused" distro. It is not the first distro to hold this title. It will not be the last. But there is one consistency that goes along with that title, it does not last. Why does it not last? People forget there is no such thing as a "free lunch."

Linux Distribution Duality

Free development and release, with less restrictive trademark controls, is a great way to drive adoption. It's how Red Hat(R) Linux dominated in the '90s when SuSE(R) and many other distributions had very strict, legal restriction on everything from trademarks to packages. Although OpenSUSE(TM) has become far more open with the acquisition by Novell(R), and Red Hat(R) has made various moves over the years, virtually every major distro breaks into two (2) different forms.

While Red Hat started to offer a three (3) year Service Level Agreement (SLA) on its single release of Red Hat Linux 6.2, SuSE released a separate "enteprise" product in SuSE Linux Enterprise Server (SLES), with a fixed ABI (e.g., patched backports, etc...) and a five (5) year SLA. Enterprises responded, especially the newer crop of database and related vertical products that required ABI compatibility for 5+ years. Sales caused Red Hat to quickly follow suit with its own, initial Red Hat Advanced Server (RHAS) 2.1 product based on the Red Hat Linux 7 series, which has expanded into a three (3) tier Red Hat Enterprise Linux (RHEL) line with 7+ years of support.

Unlike SuSE(R), who vehemently defended their trademarks, Red Hat(R)'s community adoption caused mass redistribution. With no good deed going unpunished, select corporations started abusing the goodwill of Red Hat -- probably the most specific, Cobalt and their Linux/MIPS port (which Red Hat never released), which was blatantly labeled "Red Hat(R) Linux" to extensive misnomers that I still run into today. With Sun's purchase of Cobalt, no trademark usage guidelines could end the misuse (let alone demonizations), and Red Hat introduced another trademark, Fedora(TM), that is now used for all community software redistribution (typically unchanged from its enterprise re-packaged offerings).

Every major Linux distribution has undergone this duality. Mandrake, now Mandriva, in years past and, more recently, the Ubuntu distribution from Canonical.


Ubuntu has a slightly different beginning than most other distributions, as its initial development and eventually fork from Debian was made with funding from wealthy Mark Shuttleworth. The "Spaceman Endowment," as I have called it (playing on his voyage to the International Space Station, ISS, at his own cost), has resulted in a distribution that was funded by the charity of income from Mr. Shuttleworth's wealth. I will be the first to thank Mr. Shuttleworth, among others, who have used their wealth to fund further Linux development, and his Ubuntu project is no exception -- and I hope others do as well.

Unfortunately, some people tend to be a bit rabid in their praise (see later sections). Endowments can fund projects and fund them well, as long as the endowment is sizable enough so the resulting income, interest, gains, etc... can afford the expenses involved. When they do not, new sources of income are required. The reality is that a popularity of a distro can outgrow the sheer charity to support it, especially when issues of ABI compatibility and service level agreements (SLAs) start to become the focus. Some distributions decide to ignore these, while others embrace them. Canonical very much embraces them.

Ubuntu first started to offer a three (3) year Long Term Support (LTS) version. Although it's backport and ABI foundation was (and still is) debated (and I will not introduce any FUD here, as I clearly have a conflict of interest), Canonical is focusing on a full ABI compatible release of five (5) years now, with Service Level Agreements (SLAs). I have now professionally dealt with several Canonical service personnel, and I would not categorize them anything less than knowledgeable peers, as I would expect a commercial Linux entity to hire (although I would more subjectively argue server support mindshare and resulting knowledge may be more proportional to experience and duration of strict ABI product offerings -- but that's clearly my bias, I just wanted to point out they hire experienced professionals). Unfortunately, people seem to think such talent is free (again, see next sections).

The newer moves by Canonical are starting to get their own set of demonizations. Canonical now charges $150/node for unsupported updates (not even e-mail support) in their Ubuntu LTS version of five (5) years. There is already some notes of ambiguity of where the "free updates" end, as the latest clarifications are "at least eighteen (18) months," with different LTS versions available for "free" and with commercial support (free 3 years v. commercial 5+ years?). Furthermore, these are durations which -- unlike Red Hat and SuSE (who have 7+ years of SLAs and/or "Enterprise" products now) -- have not yet to be realized yet. And that is, again, starting to lead to demonizations, especially when SLA costs are compared.

With the popularity of the brand and trademark used in unlicensed versions that violate the Ubuntu trademark guidelines, it will be interested to see where Canonical starts to "draw the line" more publicly on the on Ubuntu(R) trademark when it is threatened by unlicensed redistribution. So far, OEMs such as Dell have had to sign licensing agreements, which have become standard since Sun made it an issue for Red Hat and then Sun found no sanctuary with SuSE after spurning Red Hat on trademark. So we may already be passed this consideration, as Canonical does seem to be enforcing (so far), and no distribution vendor (including Red Hat itself) has missed the lesson of Red Hat - Cobalt and, later, Sun.

But what about the individual who starts to release the commercial, five (5) year Ubuntu LTS management and updated packages to non-subscriptoin/non-SLA customers? Especially if they are not striping off the Ubuntu(R) trademark? Let's say Canonical still allows that, whereas SuSE's history has prevented much of this. I.e., even Red Hat has to deal with the regular issue of even their legitimate customers calling on systems that are CentOS installs, and specific systems not covered by SLAs. But at least they are identified as CentOS. Branding, support and many other considerations will only lead to further "clarifications" by Canonical on Ubuntu.

It will be the abusers that will force these clarifications, just like SuSE, later Novell, and Red Hat have had to do, and Mandriva that would later follow. And it never ends either, with rabid people ready to jump on anything, especially necessary brand-related enforcements that would otherwise open even Microsoft to abuse of them (you laugh, but it's legally true -- you can't "selectively enforce" in the US, EU, etc...). And the naysayers and demonizers will only grow as a result. They will forget Ubuntu has done a lot of good for the community, initially and still significantly on the charity of Mark Shuttleworth, which is always for praise. The rabid advocates that wouldn't listen to us earlier will not when they turn on Canonical, as some already are. And that's when we'll all lose in the message, marketing and related demonizations by rabid advocates are never good for the Linux community.

Sadly enough, it will be Novell and Red Hat employees like myself that will be the first to defend Canonical's clarifications, all while they alleged became "uncool." Just like it happened to Mandrake, formerly Mandriva, only on a much larger scale. Apparently people can't realize that support costs are a reality, and branding sometimes requires vendors name products differently, including using separate trademarks. Red Hat hit that brick wall. SuSE never allowed and Novell has had to fork its own. Canonical is addressing it and will continue to do so. I've already heard the phrase "Ubuntu is not as community focused" or "Ubuntu is more evil than I thought" recently from a few people.

Oh the irony as history repeats itself yet again! They're beyond the naysayers who are Ubuntu users who blast Debian, or the CentOS user who says Red Hat subscriptions aren't worth a dime (oh man, that's my favorite). It goes to the heart of people who want a free lunch, including the branding all the services that cost people in time.

To begin, thanks goes to Kerry Webb for first pointing out the OpenSync (fka Multisync) and Barry software. After a little investigation, I was able to get the solution working with Fedora 8, which I have documented in the following.

0. What is OpenSync (fka MultiSync)?

OpenSync is a desktop to/from device agnostic synchronization backend and optional front-end system that builds upon deprecated developments in the GTK-only (e.g., GNOME) MultiSync project. A nice slideshow introduction is available from Novell .

Although it is only a matter of time before native OpenSync support is in most major open source applications with contact, scheduling and other information commonly used on a PDA, OpenSync is used today as a standalone application. You setup a "Group," typically via a graphical user interface (GUI -- the GTK+ MultiSync GUI is still commonly used for this), and two (2) end-applications and/or devices in each "Group" that you wish to sync. In this blog entry, Evolution (end-user application) and BlackBerry (end-user device) will be utilized.

1. Install Sync packages from Fedora 8 Respository

The Multisync solution is already checked into Fedora 8. Virtually everything you need, except Barry (for BlackBerry support), should be in Fedora. I have not yet investigated why Barry is not in Fedora 8 (maturity, maintainer interest, IP issues, etc...), but I will not speculate further. Barry installation will be covered in step #3.

# yum install multisync multisync-gui libopensync-plugin-evolution2

NOTE: For those running KDE instead of GNOME (and Evolution), the KDE PIM plug-in package is libopensync-plugin-kdepim. Other OpenSync libraries for various end-applications and end-devices can be found in the Fedora repository with yum list | grep -i libopensync . New OpenSync application and device support libraries are being added regularly (e.g., I noted the plug-in for the Mozilla "Sunbird" calendaring system in Fedora 8's Update Testing repository at the time of this blog entry).

2. Additional Development Packages for Barry

The Fedora release model separates "Run-time" (end-user) binary and library packages from "Development" (-devel) header and library packages. For size considerations, the latter required only when software is built against those headers and libraries, but not required for normal user usage or when the software is already built. The -devel packages should not be confused with the full source code for rebuilding the software from scratch, however (these concepts are outside the scope of this blog entry).

One or more of these prerequisites "Development" (-devel) packages may be required, possibly others as these were the ones that were required for myself, to build Barry.

3. Download and build Barry with OpenSync

The Barry project offers various support for BlackBerry devices, including an optional OpenSync library support package. At the time of this blog entry, Barry packages were not included in Fedora 8. But under the SourceForge download page , a source RPM (.src.rpm) package for Fedora 7 not only builds under Fedora 8, but has been tested to work successfully on my Fedora 8 system with my BlackBerry 7290.

This blog entry reflects building Barry with the barry-0.11-1 release for Fedora 7.

# rpmbuild --rebuild --with gui --with opensync barry-0.11-1.fc7.src.rpm

This builds the following binary binary packages in the directory /usr/src/redhat/RPMS/i386 (on Fedora 8 i386 systems).

• barry-debuginfo-0.11-1.i386.rpm
• barry-opensync-0.11-1.i386.rpm
• barry-gui-0.11-1.i386.rpm
• barry-util-0.11-1.i386.rpm
• libbarry-0.11-1.i386.rpm
• libbarry-devel-0.11-1.i386.rpm

The barry-gui and barry-util packages are optional and are not required for OpenSync, and the barry-debuginfo and libbarry-devel are completely optional. The first two are still recommended as they offer backup and various other utilities. In fact, the bidentify utility in barry-util package will return the PIN of your BlackBerry which is necessary for the OpenSync configuration (although it can be found on the BlackBerry itself).

4. OpenSync Configuration and Sync

Plug into your BlackBerry device into any supported USB port on your Fedora 8 system and verify there is a device connection (e.g., as root, running tail -f /var/log/messages prior to connection is always a good move, or using a popular USB view utility is another option). Once connected, use the bidentify program to get the PIN number of your BlackBerry device.

# bidentify
0a1b2c3d, RIM 7200 Series Colour GPRS Handheld
^^^^^^^^ Eight (8) hexadecimal digit BlackBerry PIN

NOTE: Under BlackBerry OS 4.0 (and most latter versions), you can find the PIN of the Device on the Device itself under Options (the "Wrench") and Status.

Now launch the Multisync GUI (this requires GTK+ for those running KDE and not GNOME, XFCE or other GTK+ based desktop solutions), the currently available and supported front-end option (there are other mechanisms and possible future GUI options, but I will not cover them).

# multisync &

Now use the following procedure to setup Evolution software and Blackberry devices for sync:

• Click the Add button (and subsequently type the new Group name), under the top button bar in the window multisync , to create a new Group
• Click the Edit button, below the new Group in the window "multisync, to edit the new Group
• Click Add Member button, on the left of the second window multisync , to add an application/device
• Click Evolution 2.x in the list (and subsequently click the Apply button), in the third window multisync , to add Evolution 2.x sync
• NOTE: If you have alternative AddressBook, Calender and Tasks lists than Personal , you will want to change the defaults of the Evolution library/member.
• Once again, click Add Member button
• Click Barry OpenSync plugin ... (and, again, subsequently click the Apply button), to add BlackBarry sync
• Click the Close button, back in the second window multisync
• Click barry-sync in the list, on the left of the second window multisync
• Enter your BlackBerry's eight (8) hexadecimal digit PIN in the 2nd field on the Device line
  
• Click the "Close" button, in the lower-right corner of the second window multisync

Now the synchronization libraries between Evolution application and BlackBerry are setup, and the configuration should be saved. To attempt a sync, click the Refresh button (yes, I know, I don't appreciate the choice of terminology either, but it may be a non-English translation I can only assume or a poor use of Windows nomenclature).

NOTE: The first time I attempt this, it failed. Exiting the application and re-lauching it (possibly re-reading the new configuration and PIN?) worked, and worked every subsequent time. Also, don't be surprised when you get double entries if both exist in Evolution and on your BlackBerry, and you may need to resolve them (but this is not uncommon with BlackBerry, Palm or Mobile Windows with their official software either). I had no such isses in subsequent attempts.

Again, until OpenSync is directly supported in end-user applications like Evolution, you will still launch the separate MultiSync GUI. This may change as more OpenSync front-ends are made available, or it is directly supported in Evolution itself.