This is a quick and most probably dirty installation of VMware View Client with PCoIP support on Fedora system. As VMware has recently released package that is publicly available for Ubuntu systems it is now relatively easy to get it working.

Extract the package. I’ve used “/opt/vmware/view-client” which would allow me to keep my system clean. If you are going to extract the contents elsewhere, you should change -C “/opt” and –xform=’s|usr|vmware/view-client|g’accordingly.

As I promised, there will be more posts related to the Fedora 16 configuration on a Thinkpad X220. This one will be about the seamless docking/undocking of the notebook from the dock.

It seems that this is largely still a grey area and is something that rarely seems to work as expected, so I had to hack it away, because this one was one of the biggest problems that I face every day because I take the notebook every day at work and dock it so I’m able to use is as a regular desktop PC and in the afternoon I take it with me at home (one never knows for sure where he’ll end up the next day – at work or at a customer’s site🙂

What I was aiming was achieving effortless X setup and display switching under the following conditions:

1. When booting the notebook – should work as expected – show KDM on external display when docked and on local LVDS display when not

2. Proper switching when docking / undocking the notebook and there is active user X session

3. Proper switching when docking / undocking the notebook when KDM is active

4. Proper switching when the notebook is docked / undocked during it was suspended

To achieve this I’ve ended up with a simple bash script that verifies the current configuration (docked / undocked) and switches the display accordingly. What was left was to put it in the all appropriate places, so that it gets executed on all of the above listed conditions. So first about the script – it still a work in progress, but is mostly working properly. I’ll update it here when it becomes more polished. Bare in mind that this was written with KDM in mind, although it shouldn’t be so difficult to be adapted for GDM or other login manager.

Only one thing to be noted here – the script needs to be executed only during the resume process, but because of some problems that I had during resuming on local display when system was suspended on the dock I had to add the hook also during suspend state and force the X server to be switched over the local display in case the machine is undocked while suspended.

EDIT:

You’ll also need to disable the KDE display management systems, so it does not ask you every time for display reconfiguration because a new display was detected. The only thing that should be done is to stop the service itself like this:

That’s all – there still some quirks that should be polished and may be the script must be made some more general – like defining some variables at the beginning, but I’ll do that later. In general it just works, is quite simple to implement I think and finally the dock is out of my way🙂

So here I am – sitting in front of my new laptop – Lenovo Thinkpad X220. The date is November 8, 2011 which happens to be the release date of Fedora 16 codenamed “Jules Verne”. It’s 11:00pm, everybody are already asleep and it’s quite and peaceful in my home (thanks to my son that rarely happens🙂 – it’s time to start with that perfect setup that I’ve had in my mind for quite some time now. I suppose that this is not going to be a short post – so if you are in same state of mind – thrilled, excited and willing to start that Fedora setup any minute now – this is the time to go grab a cup of coffee, tea or beer maybe🙂 I’m going to describe all the specific things that I’ve done during the install (leaving the boring stuff behind🙂

The Hardware (4291-2WG)

Intel i5-2540M

1 x 4GB memory

12.5” HD Premium Display (the one with the IPS panel)

320GB 7200 HDD

80GB Intel mSATA SDD

Wireless – Intel 6205

Video – Intel HD 3000

720p webcam, fingerprint reader, bluethooth

9 cell battery

Thinkpad Ultrabase 3 + DVD Burner

Some thoughts about the hardware – first of all I had some doubts about my choice, but after I’ve received the package – they are *all* gone. What where my main concerns:

Display size would be too small – that turned out to be fine by me, but still I had to do some tricks to further “improve” it

Lack of USB3 ports – not a dealbreaker in the end as you can always stick an additional ExpressCard that sits flush in the laptop (like this one) whenever you get the need of USB 3.0 speeds

The IPS panel would suffer from ghosting – there is a huge thread about that, but the issue was actually addressed by Lenovo in the mid of August and after I’ve received mine I’ve even didn’t bother to check whether it has the new or old panel – the screen is (almost) perfect and is miles away from those TN panels. It has some bleeding from the bottom bezel though noticeable at boot time or at the console (when the screen is almost black), but that is not something that you’ll notice during your day to day work.

One more remark about the hardware that I’ve choose – if you don’t have the option to order a customized device (like me) you can get all available options from the so called “tabook” – Personal Systems Reference Lenovo® ThinkPad ® Notebooks. Truly a must read if you are in a position of deciding what Thinkpad to buy.

The Installation

So, enough about the hardware itself – lets get it rolling. You’ll need a boot media first. A couple of options here, but as I wanted to go with the latest and greatest of the available technology I’ve decided to go with UEFI boot on the machine (I really wasn’t able to find any major benefits of using UEFI instead of BIOS BOOT, besides maybe the possibly faster boot times) with got me to the first part of this setup.

1. Preparing bootable media (USB Stick)

I’ve decided to continue using 64bit OS despite the numerous problems that I had with some proprietary software/packages, so I’ve downloaded the Fedora-16-x86_64-netinst.iso. From the Fedora documentation – the are not UEFI bootable media by default – you’ll need the installation ISO file readily downloaded somewhere (on the preinstalled Windows 7 perhaps? or boot the Fedora Live CD image), mount it and extract the UEFI bootable image located under /images/efidisk.img on the iso itself. The Network installation iso contains that file also so you can stick with it. After that you can put it on whatever USB stick you’ve got (the image is around 140MB) using dd:

REMARK: You’ll need to enter BIOS settings (F1) and select as boot method either only UEFI or at least select UEFI as preferred boot method. After that pressing F12 at boot time will allow you to select the USB stick as temporary boot device.

2. Booting the installation

Nothing special here – I used the Intel SSD of course for the system installation, creating EFI, BOOT and SYSTEM partitions. If everything is correct the Fedora installer will know that it was booted from UEFI and will create GPT table instead of MBR on the SSD, which will automatically be also aligned to the 2048 sector which is exactly at 1MB. To verify that, you can do the following. First select “Review and modify partitioning layout” during the installation setup and then check that the EFI partition is created:

You could also verify the alignment and the partition table format from command line after the disk was formatted:

What packages are you going to install is entirely a matter of personal taste, but for me – the most important was to switch the default Desktop Environment that is going to be installed from GNOME to KDE. Also I’ve removed almost all packages in the Base System -> Hardware Support section that were not needed anyway on my system.

The Problem

So as I mentioned in my earlier post I had lots of troubles getting GPS locking lately on my N900 which I regularly use for tracking when running. After switching and trying all apps that I was able to find – GPS Recorder, GPS desktop widget, Marble, eCoach and OVI Maps I’ve come to the conclusion that the problems is not in the applications, but rather the GPS device. Initially my thoughts were that it was completely broken as hardware, as I’ve used it quite often and it was always working as expected until recently when it completely failed on me.

The Fix

In the end after lots of searching I’ve found a fix that proved me wrong that it is HW issue, but rather a software one. The only thing that I’ve done was to switch the server used by the A-GPS from the original supl.nokia.com to supl.google.com – works like a charm, locks in a matter of seconds – even inside my apartment🙂 Just go to Settings -> Location on your device and change the Location server

So today I’ve woke up and went for my morning run. I’ve decided to use Marble for tracking on my N900 this time, as eCoach has failed me the couple of times and was not able to produce proper tracks. Everything went smoothly and I’ve got a nice track, which I saved after I’ve finished. Marble supports only KML files, so when I got home, I knew I must convert it to GPX prior to uploading it to mapmytracks.com (one of the best sites I’ve seen for analyzing your tracking data).

The conversion

Using guidelines from the Marble/Tracking page I’ve used the following command:

Please bare in mind that I’m running this on a Fedora 14 install which misses the gpsbabel GUI. I was able to find packages for F15/F16 so if you are using one of those you should have it in the Fedora Repositories.

Having the file converted I’ve tried to upload it to mapmytracks.com, but this is where the things got ugly. The following error was thrown at me:

Warning: Division by zero in /var/www/vhosts/mapmytracks.com/httpdocs/assets/php/modules/classes/gpx.php on line 103Warning: Division by zero in /var/www/vhosts/mapmytracks.com/httpdocs/assets/php/modules/classes/gpx.php on line 103Warning: Division by zero in /var/www/vhosts/mapmytracks.com/httpdocs/assets/php/modules/classes/gpx.php on line 103

The Problem

After short investigation I’ve found that my other (eCoach) gpx tracks were having the attribute for each trackpoint () and the converted file was missing them. The google search resulted in nothing of a help that would allow me to inject the timestamps inside this trackpoints, so the logical continuation was to do it myself🙂

The Fix

For the purpose of this task, a simple perl script was created. You’ll need Date::Parse perl module (perl-TimeDate package on Fedora 14):

The only argument that this script takes is the input gpx file, generated with gpsbabel and the output is thrown on stdout. What that script does is it takes the initial time when the gpx file was generated and injects <time></time> values from it, increasing it after every trackpoint with one second. Of course this is not perfect as the timestamps are shifted in time and are not the real values, but at least that allows me to insert the file and analyze it on MapMyTracks. Maybe I’ll post update on that script that will take also as input the KML file, where the time when the files was saved is used, and reverse it back to the first trackpoint. That should give more accurate gpx files.

It seems that I’ll be using this half-baked solution for uploading my tracks, as it works and generates pretty detailed track (one trackpoint per second), unlike eCoach that does this at best every 2 seconds (and does not work on my device🙂. Here is the final result on MapMyTracks.

So today I’ve got a little bored of my o-so-serious-monochrome-desktop and decided to change it a little bit. And here I am surfing my best site for desktop “candies”🙂 – kde-look.org.

The icons

First I’ve found some pretty good-looking and as it seems quite complete set of icons. Of course I’ve installed them directly through systemsettings->Application Appearance->Icons – it is as easy as that. Just search for kfaenza. Here is a sample screenshot from my desktop with the this iconset:

They may resemble some other OS to some extent, but I do not care – they are nice in the end.

The wallpaper

After that I’ve searched for something different and new and found one little nifty plasmoid package that makes wonders🙂 – The Wallpaper Clock plasmoid. What this plasmoid is supposed to do is to sit in the background as a sort of dynamic wallpaper showing current date and time. It has lots and lots of themes and all of them looking great.

The plasmoit itself depends on plasma-scriptengine-python (as I’m installing this on Fedora 14), and you’ll need to install it if you don’t have it already. Initially I’ve tried installing the package which I’ve downloaded through the plasmoid GUI (“install from local file”), but that failed miserably. So I did it the old way:

EDIT: I’ve done this on another Fedora 14 install and this time I’ve used the “Download new plasma widgets” searched for “wallpaper clock” and directly installed it – it worked like a charm. Still if you have problems, you can try the manual install. You can verify that everything is working as expected by running it manually in separate window:

$ plasmawallpaperviewer --wallpaper clock

/EDIT

And that’s all. After that you can find it sitting under your wallpaper configuration:

As you’ll see adding themes is completely integrated into the plasmoid configuration itself (under “Get New Wallpapers”) and are very fresh and fun. Please note that some of the themes are only for registered users.

This is mostly a note to self – if you need to mass change the TTL value for a zone in named, when for example you need to change the IPv4 addressing scheme for your DNS servers, here is a simple way to do it. The script assumes that you have the "; Serial" comment after the serial number of the zone. The script runs inside the primary zone folder:

The latest N900 update (PR1.2) is already history – some are happy (like me) others are completely devastated. I, like many others, decided to make full reset of the device, as was abusing it allot. This meant that the new firmware together with the latest eMMC contents was reflashed. After that I’ve started fresh to reconfigure my device, and following the KISS approach, I wanted to restore only the apps that I really use. Having that in mind there was one thing that really bugged me – MfE. It was used only to sync my Google Calendars through nyevasync and in order to be always in sync I had to enable autoconnect WiFi – that way the calendar was able to sync on the given interval of time. But staying always online drains the battery allot. Maybe this is the biggest power drain source together with the 3G connectivity. Clearly a solution that connects-syncs-disconnects would be greatly appreciated. Below you’ll find the way I did it.

The first thing I’ve needed was an alternative to MfE – I don’t like the sync-only-one calendar with google and the fact that I have a Exchange Mail account that just sits in my Modest configuration. As always the maemo community helped and thanks, thanks, thanks to lorelei from maemo.org – I was able to use Erminig for that purpose. The application in the current stage is quite feature complete IMHO. It offers syncing in both directions for local calendars to/from Google calendars and supports *multiple* calendars. The other great thing about Erminig is that you can sync from command line🙂 which opens the path to quite simple script implementing the connect-sync-disconnect philosophy. The script itself is quite simple. It respects the situations in which the WiFi was already active – it drops the connection only when it was initiated from the script itself:

All that is left now is to save that script somewhere and invoke it in certain interval of time – how you’ll do it – it’s up to you. You can invoke it manually through X-terminal and tools like “Desktop Command Widget” or automate it with tools like Alarmed and fcron.

MfE comment: As you can see the MfE can be forced to sync from command line also, so if you prefer it, but still would like to minimize your wifi usage and optimize battery life – just comment erminig sync line and uncomment the MfE one.

Warning: the script is it’s infancy and although it makes some state checks it may misbehave.