One of the biggest issue with distributed database is to find the right model to store your data. On a recent project, I decided to use a registry model. The registry idea The idea behind writing a registry is to have an easy way to both store and view data. For a given device that has a {UUID} id: I will access “/device/{UUID}/”. Any properties will be stored in “/device/{UUID}/properties/”.

This is now on the wiki.

Changes are: Removed references to the FAQ and the M2MP protocol. Added explanations on how to handle the deployment of multiple versions. Added a quick note on how to use the jazzlib library for gzip compression. The TC65Dev now is on the wiki.

The world is full of good surprises. If you joined the NoSQL gang like me, chose Cassandra to store your data and you distributed your system among different datacenters. Wouldn’t it be great to interconnect all your nodes on a virtual private network with no single point of failure? Well, TINC does just that. In fact, it does a little bit more because it’s able to establish a meshed network if hosts can’t directly contact each other (in case of a routing issue, a NAT firewall, etc).

This has moved to the javacint wiki

Update 2012-03-25: It turns out, it’s just some object oriented C: Kaspersky Lab experts now say with a high degree of certainty that the Duqu framework was written using a custom object-oriented extension to C, generally called “OO C” and compiled with Microsoft Visual Studio Compiler 2008 (MSVC 2008) with special options for optimizing code size and inline expansion. Source If you missed it in the news, you should definitely read this: The Mystery of the Duqu Framework.

I’m a huge fan of all the cloud technologies. I’ve been working on a M2M project on top of cassandra and I can really say I love this distributed database. I’d like to give my feedback on this great database. Easy management Cassandra doesn’t require any kind of manual management for complex operations like sharding data accross node restore a crashed server or put a new or a previous disconnected node back into the cluster.

On my spare time, I manage a handful of servers. And even if it’s not really my job, I try to do it well and efficiently. All of them work on Debian because it’s simple to manage. I started using cron-apt a few years ago. I started by upgrading everything automatically, this was a big mistake. I switched to only sending mails on available upgrades and doing the upgrade manually. But this is also quite painful because 95% of the time, it consists in typing “apt-get dist-upgrade -y” and waiting and I have lots more interestings things to do.

I’ve been testing btrfs for some months now. One of the most interesting features of this file-system is its snapshoting capabilities. Before that I was using rsnapshot. The issue with rsnapshot is that its lowest atomic level for snapshotting is the files themselves using hard-links. So any database table where one row is changed is copied completely. Btrfs as you might guess will only copy the modified chunks (I don’t know the atomicity of them [but who cares?

I bought the Kindle. It might sound strange considering I already have an iPad, but I couldn’t help myself to buy a “e-ink” enabled device. The user experience around the Kindle is OK but not great, because it’s not a touch screen. The real amazing thing is the sync between amazon, the kindle and all the other possible devices. There’s the sync when you buy a book. It appears instantly on the device.