wheeee… 8)

What can I say.. Many people recommended this book for me, but unfortunately it’s hard to get in reasonable price. If anyone wants to get a copy, and you should, I recommend you order from Borders.

The book, although the main content has been written over 20 years ago, gives a humane point of view in the area of project management and organizations. It was almost shocking to me to discover that the same problems that DeMarco and Lister pointed out in our way of industry is are still completely valid today; the lack of humane aspect in organizations.

The main message which I received from the book was that it’s crucial for companies to invest in “human capital”; the well-being and comfort of the people who work for them. Human capital is something that does not have any direct measurable value in money, but the value comes from greater productivity and results; happy people get more done in less time.

It was striking that as a team manager I have sometimes questioned my decisions whether or not I should do “as it’s always done” or should I try to find out some other solution which is more pleasant for the subordinates the decision affects. This book clearly clears all the questions from my head; do a decision that show you care for your people and invest on human capital and in the end you always end up with better results.

After reading the book I feel I’ve matured as a manager as I now clearly have a clear approved guidance to concentrate on the most important asset of any organization: the human capital.

• Time daemon (timed)
• Mode Control Entity (MCE)
• Sharing Framework
• Non-Graphics-Feedback (NGF)
• Profiles
• Qt style APIs (QmSystem)

Arjan van de Ven explains:

Recently we have been evaluating these features and feel that these  technologies, as integrated into MeeGo, haven’t reached the maturity that we want to commit them into MeeGo 1.2 core.

As a result we are proposing to, for MeeGo 1.2, not include these  components in the official architecture diagram or the compliance spec since either means a compatibility commitment going forward as well as a requirement for everyone who makes products with the MeeGo brand to include these components. As these things mature going forward, we hope that for MeeGo 1.3 we can put a much more mature policy layer as part of the core architecture and compliance set.

He also notes that the components are not removed, but as the result of removing them from the compliance specification not all MeeGo 1.2 products have to include them.

On follow-up Jussi Liukkonen points out:

I would consider this a prudent approach. APIs we cannot comfortably commit to, we should not commit to. And these APIs have not settled yet.

However, the functionalities these components implement are quite important for actual products. I expect we’ll see a number of 1.2 based products, more or less relying on these implementations.

These components are mostly driven by Nokia. This move just might be a test for Nokia to see if they are truly engaged to MeeGo in the future. If Nokia does the necessary work to keep them for 1.3 and truly shows the motivation and engagement then the components will be available in the future, too.

On the other hand if Nokia drops the ball completely and stops maintaining these components I’m not sure if Intel is willing to drag them along alone. By removing these components from compliance specification Intel can drop them in the future if no one is left to maintain and develop them further.

Here’s the first episode, if you’ve missed it:

You can follow the quest of SteelRat on our YouTube Channel. Stay tuned!

Nomovok’s strategy and direction however does not change. We continue to commit our selves on MeeGo and that direction seems very strong in long term.

Unfortunately at this moment our situation is pretty hard. To be honest the past few weeks have been filled with uncertainty and confusion. We are actively searching for new ventures and we believe strongly in the potential of MeeGo.

I am certain though real talent always has demand and talent we sure have

Qt 4.7.2 has now been released. This is a maintenance release which contains bug-fixes based on feedback and contributions since the Qt 4.7.1 release back in November. It also marks the official release of Qt Quick.

See the full announcement for more details.

I’m a big FLOSS supporter and MeeGo and Qt are the main interest of mine. More information about me is found from my homepage and LinkedIn profile.

I hope to enlighten you in the future with some insight about multi touch and gesture related matters through this planet, so stay tuned for updates..

Last weekend I had to recover an eCryptfs encrypted home directory created with ubuntu jaunty installer from a backup. I thought that it would go smoothly, after all I had written down the recovery passphrase when I installed the system some time a go. Well, it wasn’t all that smooth.

After like 1,5 hours or so I finally had the backup decrypted and I thought that it would be useful to others, too, if I share my findings as I discovered from emergency googling that others are struggling from the same problem and no one has provided any complete solution.

The backup was on external USB HDD, but it should not matter as long as you have your old encrypted .Private somewhere at hand.

First you need to make sure ecryptfs-utils is installed:

$ sudo aptitude install ecryptfs-utils

Create a directory where the backup is opened:

$ cd /mnt
$ sudo mkdir OldHome

Then create a symbolic link to your backup of your old .Private:

$ sudo ln -s /media/3e8ea0ac-xxxx-xxxx-a35a-8ff17406fdb8/home/user/.Private OldPrivate

Now, here’s the part that was missing from all the instructions. At least Ubuntu is using filename encryption to hide the real filenames. You need two keys for accessing: one for accessing the file content and one to decrypt the filenames to be meaningful. To get the key do:

$ sudo ecryptfs-add-passphrase --fnek
Passphrase:

Enter the recovery passphrase: the long one you had to manually write down to a piece of paper when you installed the system. Then you should have a similar output as the following:

Inserted auth tok with sig [xxxxxxxxxxxxxxx] into the user session keyring
Inserted auth tok with sig [yyyyyyyyyyyyyyyy] into the user session keyring

Now, write down the second signature [yyyyyyyyyyyyyyyy].

Now you are ready to decrypt the backup:

$ sudo mount -t ecryptfs OldPrivate OldHome/
Passphrase:
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [xxxxxxxxxxxxxxx]: yyyyyyyyyyyyyyyy
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=yyyyyyyyyyyyyyyy
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=xxxxxxxxxxxxxxx
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [df3c98e4c85db0c5] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? : no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs

Now you are able to access the decrypted backup in OldHome directory and you also have correct filenames.