Alas I did not find too many introductions so I thought that I’ll write a bit about my experience with cmake. As I continue to find out more stuff about cmake the post will be updated with new findings.

Read after the fold for an introduction into cmake. We’ll create a build system capable of creating debian or redhat (RPM) packages. It will include advanced stuff as automatically creating and installing documentation, subversion-derived version numbers and creating optional features.

Basic Project Layout

We have a fairly standard project layout (currently using autotools):

All files are stored within a subversion software repository. The final package should include the current subversion revision number in their package description (as well as output it from within the executable) to improve bug report’s quality.

The build system should generate the support library, the binary and utilize Doxygen to generate documentation. All those files need to find their way into automatically build distribution packages (Debian and Redhat packages in our case).

Basic cmake setup

We start with a skeleton cmake file that only tests various standard compile flags. We name our project, search for various default libraries (through find_package) and set various compile flags.

The simple boilderplate text files are also installed. At this time the destination directory is hard-coded, this will change in the future.

project(test-program)
cmake_minimum_required(VERSION 2.6)

# check libs and packages (headers + lib)

# std C libraries
find_package(stdlibs REQUIRED)

# libpthread with pthread.h
find_package(pthread REQUIRED)

check_include_file(argp.h HAVE_ARGP_H)

# additional compiler flags
add_definitions(-Wall -Wextra -pedantic -Werror -std=c99 -D_BSD_SOURCE)

# 'other' documentation files
set(DOC_FILES AUTHORS NEWS README)
set(DOC_PATH "share/doc/testprogram-0.1")
install(FILES ${DOC_FILES}
        DESTINATION ${DOC_PATH})

So far we have the skeleton outline of a cmake project that just sets some compile information about our project and finally installs some documentation. Let’s add some “real” stuff.

Adding support libaries

Our project contains one library that is needed for compilation of the executable file. To build the lib a new CMakeLists.txt was added to /lib and the /lib directory was added to the main CMakeLists.txt by:

add_subdirectory(lib)

The cmake library definition is pretty straightforward: we define the needed source files (through the EXAMPLE_LIB_SRC variable) and add a new shared library named ‘example-lib’ to the build targets. The only “weird” thing is that we have to add the library to the linker flags manually (by setting CMAKE_REQUIRED_LIBRARIES): it would be nice if this could happen automatically.

# sources and linkage

# define the sources
set(EXAMPLE_LIB_SRC  lib_a.c lib_b.c)
add_library(example-lib SHARED ${QKD_APP_SRC})
target_link_libraries(example-lib ${CMAKE_REQUIRED_LIBRARIES})

# additional includes
include_directories(. ..)

# enable gcc specific stuff
if (CMAKE_COMPILER_IS_GNUCC)
    set_source_files_properties(${EXAMPLE_LIB_SRC} PROPERTIES COMPILE_FLAGS "-std=c99 -Werror -Wall -pedantic")
endif ()

set(CMAKE_REQUIRED_LIBRARIES "example-lib;${CMAKE_REQUIRED_LIBRARIES}")

# install
install(TARGETS example-lib LIBRARY DESTINATION lib)

Adding executables

Now we add the executable file to the build. To achieve this we add a CMakeLists.txt to the /bin directory. Within it we define our executeable (consisting of part_a.c and part_b.c) and its compile flags. The include directive states where the compiler should search for header files. With the install command we define it’s final position when being installed as part of a package.

We also add a manual dependency of example-prog upon example-lib. Cmake now always builds example-lib before it attempts to build example-lib. Alas we still had to manually add the example-lib linker flags to CMAKE_REQUIRED_LIBRARIES at the /lib section

include_directories(
    .
    ..
    ${CMAKE_CURRENT_BINARY_DIR}
    ${CMAKE_CURRENT_SOURCE_DIR}
    ${CMAKE_SOURCE_DIR}
    ${CMAKE_BINARY_DIR}
    ${CMAKE_SOURCE_DIR}/bin/
   )

# define the sources
set(EXAMPLE_SRC part_a.c part_b.c)

# define executable
add_executable(example-prog ${EXAMPLE_SRC})
target_link_libraries(example-prog ${CMAKE_REQUIRED_LIBRARIES})
add_dependencies(example-prog example-lib)

# compiler switches

# enable gcc specific stuff
if (CMAKE_COMPILER_IS_GNUCC)
    set_source_files_properties(${EXAMPLE_SRC} PROPERTIES COMPILE_FLAGS "-std=c99 -Werror -Wall -pedantic")
endif ()

# install binaries
install(TARGETS example-program RUNTIME DESTINATION bin)

Test it

This would actually be a good time to test our build system. cmake supports two different ways of separating source code from build programs: out-of-tree builds and in-tree builds. With in-tree builds source code and generated files are always stored within the same project directories. This is the way of building that you might know from autotools. With out-of-tree builds all generated files are placed into a separated directory: this keeps your project directory clean (and you can do interesting stuff as speeding up build time by placing the out-of-tree build directory on a ramdrive/tmpfs). So we will try to do an out-of-tree build:

$ cd $PROJECT_DIRECTORY
$ mkdir build
$ cd build
$ cmake ./..
$ make

This will build all binaries within the build directory. Partey!

Create debian and redhat packages

We won’t distribute a tar-ball or plain pre-compiled binaries to our users but want distribution-specific packages. They provide a better user experience through features as dependency tracking (which other packages must be installed to run this program) or easy package management (install, reinstall, uninstall packages).

cmake provides CPack for package creation. To enable it our main CMakeLists.txt was adapted in the following way:

set(CPACK_PACKAGE_DESCRIPTION "Do the example thingie")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "A longer description about our example app.")
set(CPACK_PACKAGE_NAME "example-app")
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.6), libgcc1 (>= 1:4.1)")

set(CPACK_PACKAGE_CONTACT "Andreas Happe ")
set(CPACK_PACKAGE_VENDOR "Andreas Happe Inc.")
set(CPACK_PACKAGE_VERSION_MAJOR "0")
set(CPACK_PACKAGE_VERSION_MINOR "0")
set(CPACK_PACKAGE_VERSION_PATCH "1")
set(VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")

set(CPACK_GENERATOR "DEB;RPM;")
set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}-${CMAKE_SYSTEM_PROCESSOR}")

include(CPack)

The variables contain package descriptions and version information that will be converted into the new packages meta-information. CPACK_GENERATOR specifies for which output types the generated packages should have. We have chosen DEB (Debian, Ubuntu) and RPM (Redhat, Suse, Fedora) packages to be generated. They should suffice for the vast majority of installed Linux distributions. We also added some package dependencies for debian distributions: this ensures that libc and libgcc1 will be installed with their correct versions before our package is installed.

To finally build our distribution packages just change into the build directory and enter cpack:

$ cd build
$ cpack

The resulting distribution packages will lie within the build directory.

Another advantage is that we can use those cpack variables throughout the whole CMakeLists.txt file. For example: instead of installing documentation files into a fixed directory through:

set(DOC_PATH "share/doc/testprogram-0.1")

we can install them into a properly versioned directory:

set(DOC_PATH "share/doc/${CPACK_PACKAGE_NAME}-${VERSION}")

Add include files to distribution package

Other programs might link against our example-lib but they will need some header files to learn about the lib’s available (exported) function signatures. To install them we add the “include” subdirectory to our build by adding the following to the main CMakeLists.txt:

add_subdirectory(include)

Now we need a “/include/CMakeLists.txt” that specifies which header files need to be installed into our distribution package. As we want this to happen for all existing header files we just add a catchall install statement:

install(DIRECTORY example-lib-headers
        DESTINATION include
        FILES_MATCHING PATTERN "*.h"
                       PATTERN ".svn" EXCLUDE
       )

This installs all “*.h” files (ie. header files) from the directory “/include/example-lib-headers” into the package’s include directory (which will later be installed into the system’s include files directories). Notice the EXCLUDE-pattern: as we are using Subversion as a SCM we do have various internal subversion files lying around in our source code tree. Those include copies of header files. Without this EXCLUDE those copies would also be installed into our distribution package what we do certainly not want.

Add current subversion revision

As all programs our example program contains bugs. To improve bug reports we want to include a reference to the exact subversion release this package was build from. This information should be included within the package meta-information as well as within the compiled program itself

First of all we need to gather the subversion revision information. To achieve this we utilize the Subversion module that is installed with cmake (you can find those modules under /usr/share/cmake/modules*, there are lots of useful tools within that directory). It’s configuration and usage within the main CMakeLists.txt can be seen in the following code snipplet:

find_package(Subversion)
if(Subversion_FOUND)
  Subversion_WC_INFO(${CMAKE_CURRENT_SOURCE_DIR} ER)
  set(SUBVERSION_REVISION ${ER_WC_REVISION})
endif(Subversion_FOUND)

Now we have the current subversion revision stored within the SUBVERSION_REVISION variable and can easily use it to set our packages patch level (the patch level is the most insignificant part of the whole package version):

set(CPACK_PACKAGE_VERSION_PATCH "${SUBVERSION_REVISION}")

To reference this information from within a compiled program we want a header file that contains a #define that acts as a placeholder for the current subversion revision string. To achieve this we utilize the cmake configure_file directive. The directive states a source and a destination file: the source file is read, processed and stored as the stated destination file. During processing all cmake variables can be accessed and output into the destination file, ie.:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cmake/revision.h.in ${CMAKE_CURRENT_BINARY_DIR}/revision.h)

With an config.h.in file of:

#ifndef __REVISION_H
#define __REVISION_H
#define SVN_REVISION "${SUBVERSION_REVISION}"
#endif

The cmake variable SUBVERSION_REVISION is used as value for the SVN_REVISION #define. The #ifndef guards are just thrown in for good style and are not mandatory.

Automatically create man pages/documentation with Doxygen

We can utilize the same configure_file-mechanism to automatically generate documentation through Doxygen. We already have a doxygen file describing the documentation extraction but need to adapt it to the actual build directory, ie:

PROJECT_NAME           = ${CPACK_PACKAGE_NAME}
PROJECT_NUMBER         = ${VERSION}
OUTPUT_DIRECTORY       = api-doc
INPUT                  = ${CMAKE_CURRENT_SOURCE_DIR}

Now we need to include Doxygen within our build configuration. We achieve this through including the following into our main CMakeLists.txt:

# check if doxygen is even installed
find_package(Doxygen)
if (DOXYGEN_FOUND STREQUAL "NO")
    message(FATAL_ERROR "Doxygen not found. Please get a copy http://www.doxygen.org")
endif (DOXYGEN_FOUND STREQUAL "NO")

# prepare doxygen configuration file
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)

# add doxygen as target
add_custom_target(doxygen ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)

# cleanup $build/api-doc on "make clean"
set_property(DIRECTORY APPEND PROPERTY
	     ADDITIONAL_MAKE_CLEAN_FILES api-doc)

# add doxygen as dependency to doc-target
get_target_property(DOC_TARGET doc TYPE)
if(NOT DOC_TARGET)
	add_custom_target(doc)
endif()
add_dependencies(doc doxygen)

# install HTML API documentation and manual pages
set(DOC_PATH "share/doc/${CPACK_PACKAGE_NAME}-${VERSION}")

install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api-doc/html
         DESTINATION ${DOC_PATH}
       )

# install man pages into packages, scope is now project root..
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api-doc/man/man3
         DESTINATION share/man/man3/
       )

First of all we verify that Doxygen is even installed. Afterwards we automatically adopt the Doxygen.in configuration file to our needs (configure_file). This makes sure that generated documentation is always placed within the build directory. To make sure that current documentation is always available we add a custom target called “doxygen” and let the “doc” target depend upon it. The “doc” target will automatically be called after compiling and through the dependence doxygen will be called then too. In addition we add the “api-doc” directory (which will contain all generated files as specified within Doxygen.in) to the lsit of files that should be removed after a “make clean” run.

This is sufficient to create documentation but we also want it to appear within the generated distribution packages. The two install statements at the end achieve exactly that: they install HTML documentation into the official /usr/share/doc/ directory and generated man pages into their corresponding directories.

Add some optional parts

So far our build environment has been pretty monolithic: it always builds everything. Sometimes you do not want that as some features are only needed in special circumstances. As an example we do not want to add header files to the distribution package all the time.

Optional features are supported by cmake through the option statement. An option consists of a variable name and a short description. The user is displayed the option description and if he enables it the option variable is set. A short example illustrates this far better:

option(ADD_INCLUDE_FILES "Add include files to the generated distribution packages")
if (ADD_INCLUDE_FILES)
    add_subdirectory(include)
else(ADD_INCLUDE_FILES)
    message(WARNING "include files will not be included within the distribution packages")
endif(ADD_INCLUDE_FILES)

The include directory is only processed if the user selects the option. But how can an user actually enable an option? cmake provides various user interfaces, i prefer the ncurses-based ccmake:

$ cd build
$ ccmake ./..
# enable the wanted options and build it afterwards..
$ make

I’ve bought myself a Nikon D40 some time ago and finally had enough spare time to shoot some images and post-process them. My environment of choice is Ubuntu Linux so the obvious image management/edit tools were gimp and f-spot.

An first attempt did show some strange behaviour: f-spot did display NEF/RAW images quite different than gimp. It seems as if the (gimp) NEF import step did something to the white-balance and gamma so that imported images did look worse. The worst thing is: while f-spot does display beautiful images it is not able to export them to a more sharable format as JPEG.

GIMP is using ufraw to convert the NEF images, after playing with its parameters I’ve discovered that using a downloaded color profile for the D40 and some custom Gamma and Continuity values does provice a near approximation of the f-spot results. The used values are:

A drawback of using ufraw is it’s slow processing speed. Interestingly using ufraw-batch on the command line does not exhibit this problem, so just use:

ufraw-batch --gamma 0.4 --contuinity 0.02 --wb=camera *.NEF

While not being a problem at all, this is something that should work out-of-the-box, ie. the user should not be irritated by photos being displayed differently between applications.

I am using Skype for most of my online communication, mostly because other people are using it and there are strange firewalls at work preventing most other protocols. Alas there’s no support for Skype out of the box and the skype linux crew is kinda slow (Skype 2.1, anyone?). Enters me who needed some diversion from master thesis writing..

indicator-applet with skype

May I introduce indicator-skype-client.py: it’s a small script, written in two or three hours (most of the time spent upon finding strange bugs in python-indicate). It currently provides a list of unread messages. When a username is clicked the corresponding skype window is opened or created. By clicking on the Skype label its main window is displayed. So far it works.. various updates will follow.

How to install?
Just start the python script while skype is already running. Skype will ask if you want to allow the script to access its data, just answer yes. The script will do the rest. It does not install itself into the user session, so you’ll have to start it if you want skype notifications.

TODOs

• There are various workarounds in the code (for example I needed an empty callback to get things displayed), work out those bugs
• currently there’s a hard refresh every 5 seconds (in addition to incoming message detection). This will have to go and be replaced with a more dynamic scheme.
• detect if an unread conversation was openend within Skype and do not display this conversation
• somehow automatically start the script when Skype or the indication-applet starts

So some things are missing, but the script is already workable. Have fun (and please provide patches if you fix problems (: ).

I just haven’t enough time at my hands to create regular blog posts. This might change after my master thesis will eventually be finished but letting a web page lying dormant ain’t best style.

As I was down with the flu the last days I wrote a small replacement system: it’s just around 150 lines of rails code that captures my twitter feed and allows me to write write longer posts/memos.

The idea is that tweets are aggregated through the day and presented as formatted RSS feed (so there should be no RSS spamming). Longer stuff (as the typical “how did I get x working under Linux” things that happen from time to time) will be integrated with the tweets (yeah, not done yet).

After all coding it was pretty straightforward and fun.. the only drawback is that the RSS feed URL will change, ie. your newsreader will loose my feed.

A friend of mine and I once already managed a server that consisted of virtual machines handled through Xen. Setting up the base hypervisor (the operating system under which the guest virtual machines run) was a major PITA, especially on a remote machine where you do not have access to the boot manager.

Now fast forward to today, I’m using Ubuntu 9.04. Most of the work was done by just installing ubuntu-virtual-server and ubuntu-vm-builder. The former setups a virtual environment (using KVM) with a virtual network hub where the new virtual machines will be connected on a private subnet. Adding a new virtual machine was more or less invoking ubuntu-vm-builder which states the name of the vm, its distribution and size and then starting it with virsh start name-of-the-vm. Afterwards you’re already able to login to the virtual machine through SSH, add some routing rules on the host machine so that the virtual machines are accessable from the internet and you’re done.

Later on I’ve found some other capabilties of the virsh tool: pool and volume management. Alas while it was able to detect and view my LVM partitions I was not able to dynamically attach one volume to a VM, but maybe this will function soon.

Another nice tool is virt-manager. This gtk-application allows to connect to a remote host running ubuntu-virt-machine. You’re then able to monitor and alter the settings of the network, guest virtual machines and volumes from a graphical tool, also there’s a VNC/console forwarding for accessing the remote machine even if the network dies or is misconfigured.

All after all I must say that I’m impressed with the usability progress..

The final presentation of the prototype happened this Wednesday. The last days and nights before that were filled with applying the last fixed but finally it was worth the time. But let the newspapers do the talking: orf, heise, der standard, sueddeutsche, Austrian Telekom News. There was quite good news coverage in german-speaking Europe (and some eastern europe countries) but sadly the news didn’t seem to have jumped over the pond (at least some American physicists were at the presentation so it got noticed anyway).

Feels strange to know that something that big and cutting-edge is finally successfully finished.. and that I’m an unemployed student agai

Only two remote holes in the default install, in more than 10 years!

from its latest changelog (4.3):

Assorted improvements and code cleanup:

• ..
• TCP responses to highly fragmented packets are now constructed without risking corruption of kernel memory.

Erm, colour me confused but a network-triggered memory corruption sounds like a remote hole. At least it shouldn’t have been placed in the ‘code cleanup’ section.

• Compared to PHP, Python or Java there are just too few communication libraries. And even the libraries that exist are lacking fundamental features and almost all of them come without useable documentation. That there is no encryption (SSL or TLS) support in the whole Ruby 1.8 mail libraries is an outright shame. The IMAP library is so clumsy that a web company sells their own (still not perfect library) through their online store and they seem to make a good buck with it.

  On the Java side is just a completly different picture: Lots of libraries, even documented ones are available. After having to touch the TMail (rail’s MIME mail handler library) API using javax.mail is a heavenly gift. And it seems that the TMail generated MIME messages were invalid in a couple of cases. Not the best feature of a support library. Also the chance of finding unsolved known bugs and errors seems to be lot smaller in Java.

• This brings me to another point: I might change my opinion on Java’s constraints on its users. Java tries hard to prevent errors (i.e. the forced exception catching). I always thought that that took too many stylish possibilities away from the user, but by now I must confess that I think that this is exactly what I want from something that I’m using on the network side. I’m a lazy programmer, I want to be reminded and forced to write secure and stable code. This is the quite different to Ruby and Rails ‘make it easy for the programmer’ attitude.
• Background processing is hard. As Ruby on Rails is not multi-thread safe you can’t just spawn a thread if you need to perform some longer running task. Another disadvantage of using a single-process model is that the long running request will occupy one rails worker (i.e. rails cluster process) until it has finished – in our case that costs us around 60MB of memory per long running request, even if it is just waiting for some simple SMTP feedback. If you can find a situation where you can delay the execution of a network related task (and if you don’t you’re not thinking) for two seconds, 6 requests per seconds will DoS a standard rails cluster.

  The only solution that’s actually usable is BackgroundRb. But projects that just change their background communication system just don’t sound to production-grade ready for me. Also the admin start/stop scripts for their background server didn’t work too well for me.

• For a language that interferes it’s object’s attribute types directly from the database the ActiveRecord layer is weak. Don’t get me wrong, I understand that the Simplicity is needed to make it easily usable but I ran into various situations where I’d love to have a full blown ORM behind me. One feature that is needed quite often by our application is inheritance. ActiveRecord only offers single table inheritance, and even there you have to make sure that each row is valid (ActiveRecord should have all needed information to do that by itself BTW) or you will run into problems later on. One problem is, that it tries to abstract too much functionality away from the database while not provided as advanced interfaces by itself. Data integrity handling? Abstracted away by rails, so all databases can be used the same. The drawback is, that the data constraints and relations are fully handled by rails and not passed on to the database. Any process that might produce invalid data (e.g. a faulty rails component) might corrupt the data. Rails is able to handle that cases by itself (due to ducktyping and very few default checks), but access that data with any other framework and it blows up directly into your face.
• Transaction handling. Just try it. Then cry. Also I’m not sure if Transaction handling is even done on database level or in Rails (as done with constraints). If the later is true, it’s acutally not worth anything as soon as more processes try to access the database.

The library and documentation problems where the main reason for me to reimplement the mailing and campaigning backend in Java. The front end is still a Rails application — which is exactly what Rails is for. As I’m no friend of blown-up EJB based solutions I’ve choosen a simple Spring and JPA based solution for that problem.

I’m currently testing the last features and replacing the Ruby code part by part. As soon as I’ve done that another blog post will examine the two implementations, how much time was spent on coding them and how they perform when compared to each other.

I was able to circumvent the other short comings as the iTunesDB which a little painful to use through Linux as well as the limited audio codec choice the firmware offered.

I knew about the alternative firmwares like rockbox and iPodLinux but my earlier attempts where rather frustrating installation was hard, usability not as good as Apple’s and the battery life-span suboptimal.

The day before yesterday I retried rockbox and am very positively surprised: I suspected another cryptic command line installation routine but got a graphical tool (rbutilqt) which allowed a single-click installation. The same tool downloads all needed files and firmwares, also it used for installation of new themes. This is the first advantage above the normal iPod: rockbox has theming support.

The first impression isn’t too impressive for rockbox: it just shows a simple navigation list in a way to small font. I never thought that my iPod’s display would be that high-resolutioned..

The first configuration step was to select a better theme. I don’t want to hear the critics (you know who you are) that will claim that the only good looking and usable themes look like aqua-ish or media player-ish copies. At least they work better than the normal iPod GUI, which in hindsight now looks rudimentary. The theme that I currently use shows details as battery state in percent, estimated rest battery capacity in hours, acute volume information. Apple could copy that. The drawback is that while the ‘Currently playing’-screen is themeable (and some themes are great) the music selection screen is just the list, rendered in a way too small font (which is configurable, but changing it might break some themes). Rockbox could copy Apple’s simple music selection. I use my iPod as a music player, not as a small computer.

Are there other advantages from using rockbox? Quite a few! Crossfading and volume normalization are features that you can easily get used to. Also rockbox supports around 15 different audio formats (compared to the original iPod’s four), of which I use at least ogg and flac regularly. I can also get 10-12h of playback time out of my iPod – I don’t have the times ready for the original firmware as it didn’t really state it.

And desecrating an Apple product is also quite fun..

Yesterday I got time to read the insurance policy  (which is issued by London General Insurance Company Limited), there were some disappointments in it:

CompleteCare – accident protection part:

• While the insurance is world-wide the notebook will only be replaced in some countries. Those include most European ones but the United States are excluded. If an accident happens in one excluded country it is my task to get the notebook to an included country where London’s Insurance agent might do the repair.
• The insurance is limited to three insurance claims
• Buckles and scratches are excluded as well as damages done through fire
• As soon as repair is done by anyone except an accepted agent the insurance warrant is void
• no war or terror related damages will be repaired

CompleteCare – burglary related part:

•  The same country specific limitations occur – so I should be covered but wouldn’t get a new computer if I’m in the U.S.
• The insurance only covers burglaries as long as there was an actually attack (against my person) or housebreaking is involved. If the notebook gets stolen at a airport the insurance won’t hold.
• If I leave the notebook at work it’s not enough if the work room is secured, the notebook must be stored in a safe deposit box or such.

Needless to say that I’m not really impressed.

I do understand that the computer is only replaced in countries where there’s Dell support available but why are the United States excluded?

The burglary insurance is next to useless as long as the “kingston lock security chain” is not a valid protection measure (as noted in the policy). But hey, what do expect of a company with a Ltd. in its name?