Linux

Lin·ux: computer operating system, named for Linux kernel, written 1991 by Linus Torvalds of Finland. Posts in this category pertain to the Linux operating system.

How To Synchronize Google Calendar With KDE-PIM (Part 2)

Filed in LinuxTags: Google Calendar, KDE-PIM, Kubuntu, Synchronization

This guide has been moved to the Tutorials section, but will remain here for historical reference. Please refer to the KDE-PIM-GCal Sync: GCalDaemon Tutorial for any future updates to this guide.

In my previous post, I detailed how to use OpenSync, MultiSync, and KitchenSync to synchronize Google Calendar with KDE-PIM.

The reason that I do not use this method to synchronize KDE-PIM with my Google Calendar is three-fold:

  1. If you notice on the Google Calendar group member configuration dialogue, you will see the statement: Please note that currently the password is stored as plain text in the plugin configuration file. That means that your gmail password is stored in plain text. Granted, the configuration file is located in the home directory, which is protected; even still, I would prefer not to leave the password in clear text.
  2. The plugin appears to be limited to a single calendar. I use at least four different calendars, and would like to synchronize all four.
  3. The synchronization is would like to add an event to either KDE-PIM or Google Calendar, and have the synchronization take place without my intervention. (I know, I could set up a cron job and msynctool or something to automate it.)

Fortunately, GCalDaemon provides all the functionality that I need for Google Calendar synchronization.

Part 1: What is GCalDaemon?

From the GCalDaemon web site:

GCALDaemon is an OS-independent Java program that offers two-way synchronization between Google Calendar and various iCalendar compatible calendar applications. GCALDaemon is primarily designed as a calendar synchronizer but it can also be used as a Gmail notifier, Address Book importer, Gmail terminal and RSS feed converter.

Part 2: GCalDaemon Installation Prerequisites

The first two requirements for GCalDaemon should seem obvious:

  • A Gmail account
  • An iCal-compatible calendar application (KDE-PIM in our case)

The only package dependency is Java Runtime, version 1.5 or later. Install either of the following packages (but not both):

  • sun-java6
    (Sun's Java Runtime)
  • openJDE-6-jre
    (open-source Java runtime)

Part 3: GCalDaemon Installation

These instructions are generally based on the GCalDaemon web site's installation instructions. They do require use of the command line, but aren't anything too painful.

Begin by downloading the latest Linux installation ZIP file.

Unzip this archive under the '/usr/local/sbin' directory. Assuming you downloaded the ZIP file into ~/downloads/, then:

cd /usr/local/sbin

unzip ~/downloads/gcaldaemon-linux*.zip

chmod -R g+w /usr/local/sbin/GCALDaemon

chmod 755 /usr/local/sbin/GCALDaemon/bin/*.sh

Test your setup by trying to run the password-encoding script:

/usr/local/sbin/GCALDaemon/bin/password-encoder.sh

If you see something like the following, then GCalDaemon is successfully installed:

Your Google password: _

We will run the password encoder script later, during configuration; so for now, hit ENTER to exit the script.

Part 4: iCalendar File Setup

We will use the file-based synchronization scheme, explained by the following diagram (provided by the GCalDaemon web site):

File-based synchronization using GCalDaemon

The key to this synchronization scheme is to have an iCal calendar file that is read/written by both GCalDaemon and KDE-PIM.

First, create the iCal file using KDE-PIM:

  1. In Kalendar view, select "Add Calendar".
  2. In the dialogue that appears, choose "Calendar in Local File".
  3. In the Resource Configuration dialogue:
    • Under "General Settings" give the calendar file a name (for this guide, we will assume the file is named "test")
    • In "Location" browse to the location you wish to store the file (this guide will assume "~/calendars/")
    • Under "Calendar Format" ensure "iCalendar" is selected

You will now see your new calendar appear in KDE-PIM. If you want, add a sample event in your calendar.

Now that the calendar file is created, we can configure GCalDaemon to synchronize this file with Google Calendar. To do so, you have two options: editing the configuration file directly, or using the Configuration Editor application.

If you are only synchronizing one calendar file, either method is equally easy. I did find, however, that configuring multiple calendar files to synchronize (I have four) was much easier using the Configuration Editor.

This guide will first explain how to edit the configuration file directly, and then how to run the Configuration Editor.

Part 5a: GCalDaemon Configuration (Editing the Configuration File)

Using the command-line instructions above, run the Password Encoder script:

/usr/local/sbin/GCALDaemon/bin/password-encoder.sh

At the prompt, enter your gmail password. The script will return the result of encoding the password. Take note of this result; you will need it shortly.

GCalDaemon gmail password encoder

Go to Google Calendar, and copy the iCal URL for your calendar's Private Address on the Calendar Settings page.

Google Calendar settings iCal URL

Now you are ready to edit the configuration file. Using the editor of your choice (e.g. Kate), open the /usr/local/sbin/conf/gcal-daemon.cfg file. Edit as follows:

  1. Set the 'file.enabled' property to 'true'
  2. Set the 'file.google.username' property to your Gmail address
  3. Set the 'file.google.password' property to your encoded password
  4. Set the 'file.private.ical.url' property to iCal URL, without protocol and hostname

The following screenshot details the above instructions:

GCalDaemon configuration file

Save and close the file. Everything should now be configured.

Part 5b: GCalDaemon Configuration (Configuration Editor)

GCalDaemon doesn't provide a KMenu shortcut for the Configuration Editor. (You can create one, but doing so it outside the scope of this guide.) To launch the Configuration Editor, use the command-line to run the Config Editor script:

/usr/local/sbin/GCALDaemon/bin/config-editor.sh

This script will run the Configuration Editor, which looks something like the following:

GCalDaemon Configuration Editor

The GCalDaemon website has a nice guide for how to configure using the Configuration Editor (note: the method I describe uses the Offline-Enabled mode). Please see the GCalDaemon guide for screenshots. Also, This guide by MakeTechEasier does a nice job of explaining how to use the Configuration Editor.

To configure:

  1. Select the second tab (HTTP Synchronizer) and disable the HTTP-based synchronizer.
  2. Select the third tab (File Synchronizer) and enable the file-based synchronizer.
  3. Enable the 'dial-up connection' mode (second checkbox on this page)
  4. Click on the 'Google Accounts' button.
  5. Register your Google Account (note: if you have already configured using the previous method, you will already see your Google account listed): Click on 'New Account', type in your Gmail address and password (twice), then click on 'Verify' button.
  6. After the verification, click on the 'OK' button in the "Verify" dialogue.
  7. Back in the File Synchronization tab, ensure the tab (at the bottom) that corresponds to your Gmail account is selected, and click on the 'New' button (bottom left). The Google Calendar Synchronization dialogue will appear. Configure as follows:
    • Google Account: Your Gmail account should be selected; if not, select it from the drop-down menu
    • Google Calendar: paste in the Private URL for your Google Calendar (which you noted previously, in Part 5a)
    • iCal File: paste in the file location for your local iCal file, used by KDE-PIM (which you created previously, in Part 4)
  8. Click "OK" to be returned to the File Synchronization tab. You will now see the file-synchronization information for your Google Calendar and local iCal file.
  9. (Note: if you want to set up multiple calendar-file synchronizations, simply repeat the above steps iin the File Synchronization tab for each calendar to by synchronized. In my case, I have four separate file synchronizations defined here.)
  10. Close the Configuration Editor.

GCalDaemon is now fully configured.

Part 6: Running GCalDaemon

Start GCALDaemon by running the "standalone-start.sh" script:

/usr/local/sbin/GCALDaemon/bin/standalone-start.sh

GCalDaemon is now running. You should now see your Google Calendar events in KDE-PIM. Verify the two-way synchronization by adding an event to your calendar in KDE-PIM. Depending on the polling frequency in gcal-daemon.cfg, it may take a few minutes for your new event to appear in your Google Calendar.

It would probably be a good idea to set this script to be started at session startup. (Again, doing so is outside the scope of this guide.) If this script is running, GCalDaemon will continuously poll both your Google Calendar and your local iCal file, and keep both in synch.

If, however, you don't want to leave the script running, you can use the one-time synchronize script whenever you want to synchronize your calendars. This script will run the synchronization and then exit:

/usr/local/sbin/GCALDaemon/bin/sync-now.sh

That's it! Your calendars will stay perpetually synchronized (if you use the always-running script) or will synchronize on command (if you use the one-time synchronization script). Again, the setuip is more involved than using OpenSync, but in the end, maintaining synchronized calendars is easier and more secure using GCalDaemon.

How To Synchronize KDE-PIM with Google Calendar

Filed in LinuxTags: Google Calendar, KDE-PIM, Kubuntu, Synchronization

This guide has been moved to the Tutorials section, but will remain here for historical reference. Please refer to the KDE-PIM-GCal Sync: OpenSync Tutorial for any future updates to this guide.

As a follow-up to my previous post, I was asked a question regarding how to synchronize KDE-PIM with Google Calendar using OpenSync. This post will explain how to use the Google Calendar plugin for OpenSync. In my next post, I will explain what I believe to be a better way to synchronize KDE-PIM with Google Calendar, using GCalDaemon.

This guide will assume that the synchronization will take place between Google Calendar and KDE-PIM.

Installing the OpenSync Google Calendar Plugin

(Caveat: this guide is purely theoretical, in that I have not actually followed the steps in practice, to perform a real-life synchronization. I prefer using GCalDaemon, which I will explain later in this post.)

Assuming OpenSync, MultiSync, and KitchenSync are installed and working, in order to synchronize Google Calendar, install the following plugin:

  • opensync-plugin-google-calendar
  • (OpenSync plugin for Google Calendar)

The rest of the instructions are pretty similar to the original guide.

Configuring the OpenSync Google Calendar Plugin Using msynctool (Command Line)

We will use msynctool, which we previously installed, to set up the synchronization via the command line. I found the msynctool manpage documentation to be incredibly helpful. To set up the synchronization via msynctool, at the command line type the following:

msynctool --addgroup GCal

msynctool --addmember GCal google-calendar

msynctool --addmember GCal kdepim-sync

You have just created a group called “GCal” that contains two members: a Google Calendar and KDE-PIM. The KDE-PIM member requires no configuration; however, the Google Calendar member does require configuration - namely, the gmail credentials and private feed URL of the calendar to by synchronized. To see the group configuration, at the command line type the following:

msynctool --showgroup GCal

The command will return information that member 1 (google-calendar) is not configured, and that member 2 (kdepim-sync) does not require configuration. To configure google-calendar, type the following at the command line:

msynctool --configure Gcal 1

The “1" at the end of the command indicates “member 1", which is google-calendar (if you followed the above instructions). This command brings up the configuration file for the google-calendar member of the “GCal” group. Optionally, you can edit the file (using Kate or your editor of choice), by opening the file directly.

Currently, the OpenSync configuration files are located in:
~/.opensync-0.22/.
If you followed the previous guide, and already have another sync group configured, then this group’s configuration files should be found in:
~/.opensync-0.22/group2/
If you defined google-calendar as member 1, then the google-calendar configuration files should be found in:
~/.opensync-0.22/group2/1/.

In this directory, open and edit the barry-sync.conf file. You will only need to edit one line, as indicated by the instructions in the file. The line to edit begins with “Device” and should look something like:

<url>
http:[email protected]/private/full
</url>
<username>[email protected]</username>
<password>PASSWORD</password>

Edit to add your gmail credentials, as follows:

  • [email protected]: Replace with your gmail address
    (Be sure to replace both instances: in <url> and in <password>.)
  • PASSWORD: Replace with your gmail password

Edit, save, and close the configuration file, and your synchronization group should be ready to go. To verify using msynctool, type the following at the command line:

msynctool --showgroup GCal

This time, the command should return the configuration information you just entered.

Now comes the moment of truth: performing the synchronization. First, make sure that KDE-PIM is not running (otherwise the process will generate errors). Again using msynctool, at the command line type the following:

msynctool --sync GCal

That’s it. You should see the synchronization process in the command shell, and once the process completes, you should see your KDE-PIM (Kalendar) calendar events on your Google Calendar, and vice versa.

Configuring the OpenSync Google Calendar Plugin Using KitchenSync (GUI)

To begin, go to KMenu -> Utilities -> KitchenSync, which will launch the KitchenSync application.

The process of creating groups and group members is pretty straight-forward. (Note: if you have already created a sync group in the previous step, you will see this group displayed within KitchenSync.) To configure:

  1. Click the “Add Group” button.
  2. Assign a name to the group in the dialogue that appears, and click “OK”. The Configure Synchronization Group dialogue will appear.
  3. Select the object types to be synchronized. Since our focus is Google Calendar, we will select only "events" and de-select "Contacts", "Notes", and "To-Dos".
  4. At the bottom of the dialogue, click “Add Member”. The Select Member Type dialogue appears.
  5. Select "Google Calendar” and click “OK”. The configuration dialogue will appear. Enter the information as follows:
    • Name: leave as-is, or customize to your needs
    • Username: your gmail username (full gmail email address)
    • Password: your gmail password
    • Calendar URL: the event feed URL for the Google Calendar you wish to synchronize<. Replace "USER" in "[email protected]" with your gmail username.
  6. Again click “Add Member”. The Select Member Type dialogue appears.
  7. The second member is KDE-PIM. Select “KDE Desktop” and click “OK”.
  8. Click “OK” again, and you will be returned to the main screen.

You should now see the group you just configured, along with two links: “Synchronize Now” and “Configure.”

Click “Synchronize Now” (or, click the “Synchronize” button on the toolbar), and the synchronization should commence, with indications of its progress. At this point, you should see the synchronization progress indication, and once the process completes, you should see your KDE-PIM (Kalendar) calendar events in your Google Calendar, and vice versa.

Again, I can't confirm that this method works; but if anyone would like to try, and report, please let me know.

Synchronizing a BlackBerry in Linux

Filed in LinuxTags: Amarok, Blackberry, KDE-PIM, Kubuntu, Synchronization

This guide has been moved to the Tutorials section, but will remain here for historical reference. Please refer to the BlackBerry-Linux Sync Tutorial for any future updates to this guide.

We recently switched our mobile carrier, from Sprint to AT&T. That change meant new phones, and at my wife's insistence that I get something other than the boring, basic phones I had always used, I got a BlackBerry Curve.

I have mainly used my PDA (an iPaq Mobile Companion rx5915) as a GPS Navigator, so it would be nice to be able to use the PIM features of the BlackBerry. Unfortunately, RIM (the manufacturer of the BlackBerry) has been less-than-friendly to Linux users, and has not provided proper drivers to allow Linux to support the BlackBerry. Fortunately, however, the Linux community has come through to provide options. As a result, my BlackBerry now communicates with my laptop and synchronizes with KDE-PIM (a better-than-Outlook PIM replacement for Outlook). Oh, and as a bonus, I can transfer music to the BlackBerry's microSD card using Amarok.

Here's how:

Part 1: BlackBerry microSD Card Mounting

My first step was to install a microSD card (I used a 2.0GB card). As this Linux App Finder tutorial explains, the following two settings must be configured under Settings -> Options -> Media Card on the BlackBerry:

  • Media Card Support: On
  • Mass Storage Mode Support: On
  • Auto Enable Mass Storage Mode When Connected: Yes

Upon connecting the BlackBerry to the laptop via USB, Kubuntu Hardy natively recognized the microSD card as removable media, and mounted it. The BlackBerry itself, however, indicated the following warning:

USB charging current is not sufficient. Verify that your handheld is connected to a powered USB charging source and that the proper USB driver is installed.

(Interestingly, the BlackBerry still seemed to charge via the USB connection.) Not to worry; we will address this issue a bit later.

Part 2: Managing microSD Card Media With Amarok

Since I was following along with the tutorial, I went on to part 2, which explained how to use Amarok to manage music on the microSD card. I skipped the first section regarding using Amarok to transcode from FLAC to MP3 on-the-fly, as I rip my CDs as MP3 anyway. Moving on to the next section, regarding how to configure Amarok:

  1. Go to Settings -> Configure Amarok -> Media Devices.
  2. The BlackBerry SD card should already be listed, but if it isn't, click "Autodetect Devices." Mine shows up as Name: sdb1.
  3. Amarok won't pre-select a device type. Use "Generic Audio Player."
  4. Click the Configure button (three interlocked, blue gears) to configure the connection.
  5. Set the song location to:
    /BlackBerry/music/%artist/%album/%title.%filetype
  6. Set the podcast location to:
    /BlackBerry/music/podcasts/
  7. Click OK to finish, and then exit the Configure Amarok dialogue.
  8. From the main Amarok window, click the Devices tab.
  9. At the top of the sidebar, you should see the newly configured media device. Click "Connect" and you should see the directory structure of the BlackBerry's microSD card. Open the "Blackberry" folder, and you should see directories for Music, Pictures, Ringtones, System, and Videos.
  10. Create a playlist in the right-hand pane (you may need to return to the Collection tab to do so), and then highlight and drag the songs from the playlist into the Music folder in the device pane. Doing so will create a transfer queue in the device pane.
  11. Once you have created a transfer queue, click the "Transfer" button (next to the "Connect" and "Disconnect" buttons at the top of the device pane) to transfer the music to the BlackBerry's microSD card.

That's it! Your music is ready for listening on the BlackBerry, using the installed media player.

Part 3: BlackBerry - KDE-PIM Synchronization: Package Installation

Now, onto the more important task of configuring the BlackBerry itself for communication and synchronization with Linux. The Linux.com article Syncing Your BlackBerry on Linux provided a great start.

While RIM does not officially support synchronization between the BlackBerry and Linux, the Barry Project comes to the rescue. Begin by installing the necessary packages.

(Note that the installation instructions in both the Linux.com article and on the Barry project web site may not be up-to-date. For Ubuntu users, no compilation is required. Barry developers now provide .DEB packages that are current through Ubuntu 7.10. The packages should handle the necessary dependencies, making installation much more simple that before.)

My installation method may not be the best or most efficient, but it worked for me. Here's what I did:

First, install OpenSync and related plugins. Using the package manager of your choice (which, from within Kubuntu, would be Adept Manager), install the following packages:

  • libopensync0
    (OpenSync framework)
  • opensync-plugin-kdepim
    (OpenSync KDE-PIM plugin)
  • opensyncutils
    (OpenSync command-line utilities)
  • kitchensync
    (KDE OpenSync GUI)

You may find other OpenSync plugins useful; for example, I also installed the following:

  • opensync-plugin-file
    (OpenSync plugin for file sync)
  • opensync-plugin-google-calendar
    (OpenSync plugin for Google Calendar)
  • opensync-plugin-syncml
    (OpenSync plugin for SyncML)

Once you have OpenSync and related plugins installed, ensure you have the libusb packages installed. The current package available in the Ubuntu repositories is:

  • libusb-0.1-4

Next, install the MultiSync package and its related plugins. MultiSync is another GUI for performing PIM synchronization. I won't go in detail on its use here; we are mainly installing it for its msynctool command-line utility. Install at least the following packages:

  • multisync
    (PIM synchronization tool)
  • multisync-tools
    (command-line utilities for multisync)

Note: if you want to use the full plugin suite avaliable for MultiSync, just install the following package:

  • multisync-plugin-all
    (complete suite of plugins for MultiSync)

Finally, install the appropriate packages for Barry, from the Barry project Sourceforge site. Download files for the current version (Barry-0.12) are here. Download and install the following packages:

  • libbarry_0.12-1_ubuntu710_i386.deb
    (The main Barry library): must be installed first
  • barry-util_0.12-1_ubuntu710_i386.deb
    (Command-line Barry utilities)
  • barrybackup-gui_0.12-1_ubuntu710_i386.deb
    (GUI for BarryBackup utility)
  • libopensync-plugin-barry_0.12-1_ubuntu710_i386.deb
    (OpenSync plugin for Barry)

You now have all the needed packages installed.

Part 4: BlackBerry - KDE-PIM Synchronization: Communication and Backup

You are now ready to verify communication between Kubuntu and the BlackBerry. Connect the BlackBerry via USB. At this point, you will still see the message on your BlackBerry regarding insufficient power for USB charging. We are about to resolve that issue. Open a terminal, and type the following:

btool -t

If the command returns a list of databases found on the BlackBerry, congratulations! Kubuntu sees and can communicate with the BlackBerry. You should also notice that the warning about insufficient power for USB charging has disappeared from your BlackBerry.

If that step was successful, the next step is to backup the data on your BlackBerry. To do so, we will use the Barry Backup utility that we recently installed. In the terminal, type the following:

barrybackup

You should now see the GUI for the Barry Backup utility. Since the BlackBerry is connected, and Kubuntu recognizes it, the PIN field should be pre-populated with your BlackBerry's PIN. (Note: you should copy this PIN, as you will need it in later steps.)

Click the "Backup" button, and the utility will backup all of the database data on your BlackBerry. The progress bar will display the progress of the backup process. Once complete, this backup will be available (via the "Restore" button), should you need to restore your data for any reason.

Part 5a: BlackBerry - KDE-PIM Synchronization: Synchronizing Calendar and Contacts via OpenSync and msynctool (command line)

And finally, the moment we've been waiting for: synchronizing KDE-PIM calendar and contacts with the BlackBerry.

Synchronization of calendar and contacts will take place via OpenSync. OpenSync requires the definition of a sync group, which consists of sync members. Think of the group as the synchronization profile, and the members as the two sources to be synchronized. In our case, our profile will consist of KDE-PIM and our BlackBerry.

The next steps can be carried out either via the command line using msynctool, or through a GUI using the KitchenSync application. I will first give the command-line instructions, and then take a look at KitchenSync.

We will use msynctool, which we previously installed, to set up the synchronization via the command line. I found the msynctool manpage documentation to be incredibly helpful. To set up the synchronization via msynctool, at the command line type the following:

msynctool --addgroup Blackberry

msynctool --addmember Blackberry barry-sync

msynctool --addmember Blackberry kdepim-sync

You have just created a group called "Blackberry" that contains two members: a BlackBerry and KDE-PIM. The KDE-PIM member requires no configuration; however, the BlackBerry member does require configuration - namely, the device PIN, and flags for synchronization of Calendar, Contacts, or both. To see the group configuration, at the command line type the following:

msynctool --showgroup Blackberry

The command will return information that member 1 (barry-sync) is not configured, and that member 2 (kdepim-sync) does not require configuration. To configure barry-sync, type the following at the command line:

msynctool --configure Blackberry 1

The "1" at the end of the command indicates "member 1", which is barry-sync (if you followed the above instructions). This command brings up the configuration file for the barry-sync member of the "Blackberry" group. I'm not terribly comfortable with file editing via the command shell. If you're the same, then note that you can save and exit the file editor in the shell, and then edit the file (using Kate or your editor of choice), by opening the file directly.

Currently, the OpenSync configuration files are located in:
~/.opensync-0.22/.
If you have only configured one synchronization group, then that group's configuration files should be found in:
~/.opensync-0.22/group1/
If you defined barry-sync as member 1, then the barry-sync configuration files should be found in:
~/.opensync-0.22/group1/1/.

In this directory, open and edit the barry-sync.conf file. You will only need to edit one line, as indicated by the instructions in the file. The line to edit begins with "Device" and should look something like:

Device 123A4567 1 1.

The parameters are as follows:

  • Device: begin device configuration
  • 123A4567: your BlackBerry's PIN
  • 1: Sync Calendar (Yes: 1, No: 0)
  • 1: Sync Contacts (Yes: 1, No: 0)

Edit, save, and close the configuration file, and your synchronization group should be ready to go. To verify using msynctool, type the following at the command line:

msynctool --showgroup Blackberry

This time, the command should return the configuration information you just entered.

Note: I actually created two separate synchronization groups: BlackberryCalendar and BlackberryContacts. I wanted to separate the two sync groups, mainly for troubleshooting purposes. (Synchronizing my calendar was more critical for me. I have over 2,000 contacts in KDE-PIM, and haven't wanted to tackle that synchronization yet.)

Now comes the moment of truth: performing the synchronization. First, make sure that KDE-PIM is not running (otherwise the process will generate errors). Again using msynctool, at the command line type the following:

msynctool --sync Blackberry

That's it. You should see the synchronization process in the command shell, and once the process completes, you should see your KDE-PIM (Kalendar/Kontact) calendar events (if you synchronized calendars) and contacts (if you synchronized contacts) on your BlackBerry, and vice versa.

Part 5b: BlackBerry - KDE-PIM Synchronization: Synchronizing Calendar and Contacts via OpenSync and KitchenSync (GUI application)

The process of defining and configuring synchronization groups and group members, and performing the synchronization can take place using a GUI application. To do so, go to KMenu -> Utilities -> KitchenSync, which will launch the KitchenSync application.

The process of creating groups and group members is pretty straight-forward. (Note: if you have already created a sync group in the previous step, you will see this group displayed within KitchenSync.) To configure:

  1. Click the "Add Group" button.
  2. Assign a name to the group in the dialogue that appears, and click "OK". The Configure Synchronization Group dialogue will appear.
  3. Select the object types to be synchronized. (Note: with the current version of Barry, only Calendar (Events) and Contacts object types are supported.)
  4. At the bottom of the dialogue, click "Add Member". The Select Member Type dialogue appears.
  5. To be consistent we will make the BlackBerry the first member. Select "Barry OpenSync plugin v0.12 for the BlackBerry Handheld" and click "OK". The configuration file will appear. Enter the configuration as before.
  6. Again click "Add Member". The Select Member Type dialogue appears.
  7. The second member is KDE-PIM. Select "KDE Desktop" and click "OK".
  8. Click "OK" again, and you will be returned to the main screen.

You should now see the group you just configured, along with two links: "Synchronize Now" and "Configure."

Click "Synchronize Now" (or, click the "Synchronize" button on the toolbar), and the synchronization should commence, with indications of its progress. Once again, at this point, you should see the synchronization process in the command shell, and once the process completes, you should see your KDE-PIM (Kalendar/Kontact) calendar events (if you synchronized calendars) and contacts (if you synchronized contacts) on your BlackBerry, and vice versa.

Summary

And that's it! To summarize, at this point you should be able to do all of the following within Kubuntu:

  • Charge your BlackBerry via USB
  • View and transfer files to/from your BlackBerry via USB Mass Storage mode
  • Manage music on your BlackBerry using Amarok
  • Synchronize KDE-PIM Contacts and Calendar events with your BlackBerry

If you have any comments, questions, or suggestions, please let me know in the comments.

Update 1: Added instructions for installation of msynctool and fixed a mis-spelling; thanks theZoid from UbuntuForums.org!

Linux: Rumors of Its Demise are Greatly Exaggerated

Filed in LinuxTags: Windows

Scott Spoonauer of LaptopMag seems to be spending quite a bit of time trying to insinuate that Linux has missed its opportunity for widespread adoption. For example:

  • Spoonauer claims that the window of opportunity for Linux (as a desktop client) has closed, maybe for good. He gives some examples of the closing window of opportunity, such as BestBuy opting for the WinXP version of the EeePC instead of the Linux version, Wal-Mart "pulling" Linux PCs from store shelves and opting for internet-only sales, and Dell thus far being the only "major" PC vendor to offer pre-installed Linux.
  • After getting slammed in the comments to his previous blog post, Spoonauer then goes about trying to defend his premise regarding the window of opportunity closing, but conceding that he may have been premature in proclaiming a "death knell" for desktop Linux.
  • Spoonauer then attempts to portray some objectivity by interviewing some analysts who essentially say, "not so fast." Their conclusions are that the BestBuy decision has no real bearing on the future opportunity of Linux, and that Microsoft is making concessions with respect to licensing in order to fend off a legitimate threat from Linux.
  • But the Spoonauer goes right back to his premise, interviewing yet another expert in attempt to discount EeePC Linux sales. Here, the premise is basically that while the Linux EeePC has sold over one million units worldwide, it has only sold about 100,000 in the US, which the expert claims have all gone to existing Linux geeks.

Others are picking up on the meme, and refuting it. See Linux Watch and Linux Solutions. Let's do the same, shall we?

As I have already pointed out, Microsoft's dual actions in extending the end-of-life for Windows XP and in offering pennies-on-the-dollar licensing for ULCPCs is a de facto concession of the threat of Linux. These actions are a stop-gap gambit to avoid loss of market share, and are neither sustainable nor viable, long-term.

OEM licensing (presumably, Windows and Office) accounts for 95% of Microsoft's revenues. Thus, Microsoft finds itself in a no-win situation in the ULCPC market: either concede the market to Linux, and thus generate no revenue due to no OEM licensing, or else give away OEM licenses (essentially for free) and thus generate no revenue from the OEM licenses they do procure.

The Linux business model is entirely different. With a few rare exceptions (SLED, Xandros, etc.), Linux distributions do not make money by selling OEM or end-user licenses for use of their OS; rather, the Linux business model is to give away the software and then make money by selling support contracts.

So, extrapolating the current environment several years: Microsoft continues to generate no revenues by giving away OEM licenses and offering support for an otherwise end-of-life operating system, while the Linux revenue stream is entirely unaffected. Linux is positioned to win any protracted desktop market share battle of attrition.

The second fatal flaw in Spoonauer's argument is the inherent assumption that US market share will continue to dictate the adoption rate for desktop Linux. While this assumption may hold true today, it is quickly being invalidated.

While Microsoft has entrenched itself in the various sales channels in the US (retail outlets, vendor online sales, etc.), it is quickly losing its grip outside of the US, due to increasing open source (and, in some cases, anti-Microsoft) trends, especially in Europe and Asia - not to mention the growing computer-user market in third-world countries.

Government agencies, educational institutions, and others are moving desktop installations wholesale from Windows to Linux, by the thousands and tens of thousands. Each one of these desktop Linux installations directly impacts Microsoft's bottom line.

In short, the jury may still be out regarding the ability of Linux eventually to realize its full potential - and market share - but if Windows remains the only viable threat to Linux desktop market share, Then the Linux window of opportunity will remain open in perpetuity. Microsoft's business model will ensure it.

Microsoft Concedes Linux Threat

Filed in LinuxTags: Computers, Geekery, Windows

Consider two recent bits of news from Microsoft:

  1. Microsoft extends life of Windows XP for Ultra-Low-Cost PCs
  2. Microsft Vista successor Windows 7 rumored to be released in 2009

What do these mean? Two things: Microsoft recognizes that Vista has not been well-received in the market, and Microsoft recognizes an emerging threat from Linux.

Consider the various markets for computers: enterprise (corporate) systems, high-end (gaming, graphic design, etc.) systems, standard consumer systems, and ultra-low-cost PC (ULCPC) systems. Other niche markets also exist, as well.

Even more than a year after its release, Vista has not been well-received in any of these markets. By all accounts, the corporate adoption rate has been dismal. Due to hardware/software compatibility issues, users of high-end systems likewise have stuck with Windows XP. ULCPCs do not meet the system requirements for Vista. The other niche markets include MacOS and Linux users who don't use any version of a Microsoft operating system.

This scenario leaves the standard consumer system market as the only viable growth option for Vista. This market includes the pre-configured computers purchased through retail outlets or manufacturers' direct-sale web sites. The vast majority of Microsoft's claimed, more than one hundred million Vista license sales come from this market. However, consumer backlash against pre-installed Vista has led to a resurgence of sorts in sales of Windows XP installation media. Windows Vista has trailed Windows XP in these so-called boxed-copy sales from the week Vista was released - and many of those XP copies are being installed over pre-installed Vista.

Microsoft's business model for Windows depends upon the operating system becoming a commodity - that is, for the average computer user, Windows equals computer use, and computer use means Windows.

In this model, corporations standardize on Windows, and follow the upgrade path defined by Microsoft: when Microsoft releases a new OS, corporations dutifully upgrade their systems all at once. In the consumer market, the business model assumes first that users will view the operating system as an unchangeable part of the computer, and second, that those users will replace their systems every 2-3 years, by purchasing another pre-configured computer at retail.

Similar to Microsoft's Office business model, in which Microsoft ensured product lock-in by creating an environment in which their proprietary document format was used by 99% of productivity suite users, Microsoft's Windows business model ensured product lock-in by creating dependency on Windows-only third-party applications and by creating an environment in which consumers could only purchase PCs with Windows pre-installed.

Previous threats to this business model have been relegated to servers, high-end systems, and certain niche markets: Linux is incredibly popular in the server market, MacOS owns the market of those for whom their computer is a fasion statement or status symbol, the computer-geek market often favors GNU/Linux, etc.

However, the emergence of the nascent ULCPC market poses a serious threat to Microsoft's Windows business model. ULCPCs appeal to lower-income PC owners in the US and Europe (the largest PC markets), but are also being targeted at impoverished and third-world communities - especially as an educational tool for children in those communities (see: OLPC and similar projects). These ULCPCs open up a market segment that could, theoretically, dwarf either the corporate or consumer market segments; not to mention, the ULCPC would have an impact on at least the consumer market segment, given its attractive price.

This emerging market would not threaten Microsoft's business model, were it not that almost all such PCs currently come pre-installed not with a Microsoft operating system, but rather with GNU/Linux. These PCs favor Linux for two reasons:

  1. Hardware capability: ULCPCs, due to their hardware specs, are better-suited to running Linux. In almost all cases, they cannot run Vista at all. In most cases, though many are capable of running XP, they perform better under Linux.
  2. Cost: Linux distributions are almost all free; Windows requires licensing - a cost which directly impacts the bottom-line cost for the consumer, and which is counter-intuitive to a product positioned as "very low cost."

Thus, the ULCPC market segment poses a serious threat to Microsoft's market share. This short-term threat, if realized, would have long-term impact on Microsoft's Windows business model.

Should Linux-based ULCPCs become the norm, then what is potentially the largest market segment would be brought up in an environment in which Microsoft Windows is not equivalent with computer use. If the ULCPC brings the computer to those segments of the world population that could not otherwise afford a computer, then this entire population would be brought up in this non-Microsoft Windows environment.

Currently, one of the most popular ULCPCs is the EeePC, sold by Asus. This computer has proven to be popular: sales are expected to be around four million units for 2008 - and while Asus now makes a Windows XP model, the EeePC originally only came pre-installed with Linux. Granted, Asus expects the XP model to take up about 60% of expected 2008 sales, but that still leaves 40% - or nearly two million units - of those sales for Linux-based units.

Microsoft has conceded that increasing Linux pre-installation poses a threat to its Windows market share, due primarily to the ULCPC market. (Linux pre-installation in the consumer market segment, while not insignificant, still remains a niche. It may yet pose a threat to Microsoft's dominant market share, but that outcome will take significant time.) Note that, in order to break into the ULCPC market, Microsoft had to make two important concessions: Microsoft first had to offer discount XP licenses to ULCPC manufacturers, and then had to extend the end-of-life date for XP at least another year.

Microsoft has found itself caught in an untenable situation: take reduced profits (due to licensing discounts) on OEM sales of a product the company wants to end-of-life (Windows XP), in order to prevent a potential hemorrhage of market share, meanwhile trying to cut losses on the product into which the company has most heavily invested in the past seven years, but which has been mostly rejected by the market (Windows Vista) - all while being forced to put all long-term hope in a product the company must now rush to get out the door early in order to stem the tide (Windows 7).

Microsoft is facing a complete upheaval of its operating-system business model. Could this scenario be the reason that Microsoft is all of a sudden so interested in buying Yahoo?

Linux Survives PWN 2 OWN Contest; Mac, Vista Fall – and What It Means For You

Filed in LinuxTags: Computers, Geekery, Windows

Head-to-head-to-head, Vista vs. MacOS vs. GNU/Linux in the PWN 2 OWN contest at CanSecWest 2008:

Three targets, all patched. All in typical client configurations with typical user configurations. You hack it, you get to keep it...

Each has a file on them and it contains the instructions and how to claim the prize.

Targets (typical road-warrior clients):

  • VAIO VGN-TZ37CN running Ubuntu 7.10
  • Fujitsu U810 running Vista Ultimate SP1
  • MacBook Air running OSX 10.5.2

...Once you extract your claim ticket file from a laptop (note that doing so will involve executing code on the box, simple directory traversal style bugs are inadequate), you get to keep it.

The contest took place over three days, the challenge - and the cash prize - diminishing each day:

Day 1: March 26th: Remote pre-auth

All laptops will be open only for Remotely exploitable Pre-Auth vulnerabilities which require no user interaction. First one to pwn it, receives the laptop and a $20,000 cash prize.

The pwned machine(s) will be taken out of the contest at that time.

Day 2: March 27th: Default client-side apps

The attack surfaces increases to also include any default installed client-side applications which can be exploited by following a link through email, vendor supplied IM client or visiting a malicious website. First one to pwn it receives the laptop and a $10,000 cash prize.

The pwned machine(s) will be taken out of the contest at that time.

Day 3: March 28th: Third Party apps

Assuming the laptops are still standing, we will finally add some popular 3rd party client applications to the scope. That list will be made available at CanSecWest, and will be also posted here on the blog. First to pwn it receives the laptop and a $5,000 cash prize.

All three laptops survived the first day, as none of the contestants attempted any hacks.

However, day two brought the first successful attack: the MacBook Air was compromised in a matter of minutes. The attack vector was the Safari web browser. The contestant instructed the MacBook Air user to navigate to a specially designed web page using Safari. The attack reportedly took less than two minutes:

Charlie Miller, who was the first security researcher to remotely exploit the iPhone, felled the Mac by tapping a security bug in Safari. The exploit involved getting an end user to click on a link, which opened up a port that he was then able to telnet into. Once connected, he was able to remotely run code of his choosing.

And finally, day three saw the second successful attack, as the Vista laptop was compromised. This time, the attack exploited a reportedly cross-platform vulnerability in Java:

"The flaw is in something else, but the inherent nature of Java allowed us to get around the protections that Microsoft had in place," he said in an interview shortly after he claimed his prize Friday. "This could affect Linux or Mac OS X."

That means that in the end, only the GNU/Linux laptop (running Ubuntu) was left standing.

What is the moral of the story here? Well, in my opinion, there are two:

  1. Don't believe the Apple/Mac hype from Steve Jobs or his army of Apple fanboys. According to the two winning contestants, the Mac was the easiest of the three targets. Those who claim that Apple is inherently more secure have been proven to be making a baseless claim.
  2. More importantly, remember that the single, weakest link in security is the user (this means you). The successful attacks were accomplished by exploiting vulnerabilities not in the OSes themselves, but in standard-install and popular third-party apps (web browser, Java). A security-ignorant user can have his Mac box compromised, just as a security-aware user can safely use his Windows box.

So, as a user, what can you do to protect yourself? Many things - and these apply regardless of which Operating System you choose:

  1. Always operate behind a hardware firewall. Even if you only have one computer using your broadband internet connection, set it up behind a router. These devices are cheap (less than $100 for a wi-fi router, and $50 or less for an ethernet-only router), and provide the lion's share of protection you need for your computer.
  2. Never run as root (administrator). All operating systems have the ability to set up and use accounts with non-admin privileges. Linux and MacOS do so by default. Windows notoriously hasn't in the past, but one of the best changes in Vista - annoying though it may be - is the User Account Control, allowing a user to operate without admin rights, until explicitly elevated. If you are still using WinXP (or older), set up an account with admin privileges, but also an account without admin privileges. Use the non-admin account on a regular basis.
  3. Stay away from the internet's red-light district. While it is true that any web site can be hacked, most internet-based exploits are found on adult web sites, warez (software-pirating) web sites, and other "black-hat" (malicious computer hacking) web sites. Avoid them, and you will limit your exposure.
  4. Never, ever, open unsolicited email attachments. Surprisingly, email remains a viable attack vector, even though this basic rule has been preached for over a decade. If you receive an email attachment you didn't request or weren't otherwise expecting, do not open it. Period.
  5. Use web scripts judiciously. Use ActiveX even more suspiciously. Most browser-based attacks take advantage of JavaScript (cross-platform), the Java Runtime Environment (JRE, also cross-platform), or ActiveX (IE-, and thus, Windows-only). If you use Firefox, use the No Scripts plugin. If you use Internet Explorer, set ActiveX controls to require explicit authorization.
  6. Keep your third-party apps to a minimum. If you must use them, keep them updated. Another common attack vector is vulnerabilities discovered in third-party apps (e.g. QuickTime, Adobe Flash, Skype, etc.). If you don't need them, don't use them. Don't have them running by default. If you must have them, ensure that their browser plugins are configured not to launch/run automatically.

There is, as always, more (avoiding phishing, etc.); but the above list should provide the bulk of protection. Learn to modify your computer-use behavior, bearing in mind that you cannot place ultimate trust in your operating system to protect you.