Shocker. Installing Gutsy 64-bit now to replace Windows 2003 Server. The installer looked pretty good. I was impressed by the option to create software raid partitions and encrypted partitions. I thought to myself: it can’t be this easy.
Yeap, sadly, it wasn’t. Upon first boot, gutsy crapped out on me and dumped me into the rescue shell. The issue:
fsck.ext3: No such file or directory while trying to open /dev/mapper/md0_crypt
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
This is precisely the same issue as this guy was seeing in debian:
dm-crypt on raid does not play nicely
Conclusion: at the moment crypt on raid doesn’t work in ubuntu/debian releases. (You can probably make it work based on the article above.)
Install Java 6 like this: (Note: the package is in multiverse)
sudo apt-get install sun-java6-jdk
/etc/jvm, add this line to the top of the list:
Thanks to the above step, the
java executable will find the right version of java. You can confirm this with
java -version. However, setting
JAVA_HOME is a completely different matter.
These commands will detect set and verify
What is Bazaar?
Bazaar is a distributed version control system that Just Works and adapts to the workflows you want to use.
I read about this a few months back, but I quickly dismissed the idea. I simply didn’t think it was feasible. Or useful to me. Until I read this on the Bazaar homepage:
The purpose of decentralized revision control systems is to break the chain between the developer and the server. This is done by moving the RCS data from the central server down to the developer. This is done by making a Bzr branch something that is like both a repository and a working tree.
Logically combining the RCS data with the working tree means that when you branch from somebody else, you end up with a repository of your own. That means you can commit in your branch without needing to ask for permission from the person you branched from. It’s almost as if you copied their SVN repository and made a SVN repository of your own.
Now I get it. It’s really cool. I remember the days when I used to do a lot of work offline (on the train). It was always difficult to group my changes into separate commits. Based on the VCS I was using at the time, I would develop tools to make changesets so that I can perform distinct commits when getting back online.
With Bazaar the problem simply doesn’t exist. When you check out a ‘branch’, your local copy becomes a repository by itself. You can commit to this local repository while offline. Then when you want to merge into your online project, you can push out your local commits. It’s brilliant.
Flood ping. You specify the list of addresses on the command line. To generate the list of IP adresses you can use the
-g flag and targets with netmask or significant bits like this.
fping -g 192.168.11.0/24
I backup my svn repositories using
svnadmin dump. From a dump like that a repository can be fully restored at any location via
I’m playing with the idea of hosting some of my repositories on Google, but then I won’t be able to use
svnadmin dump, my trusty backup method. However, snvsync looks promising as a suitable replacement.
1. Create a target repository with
svnadmin create some_dir
2. Create a shell script at
some_dir/hooks/pre-revprop-change that does nothing and just exits successfully (
exit 0). Make sure the script is executable.
3. Initialize the target repository with
svnsync init file:///abs_path/some_dir source_repo_url
4. Synchronize to target repository with
svnsync sync file:///abs_path/some_dir. Notice that you don’t specify the source repository here anymore, that’s because the target is tied to the repository used in the initialization step.
Do not commit to the target repository. Always commit to the source, and after that run
svnsync sync on the target, whenever needed.
If you want to mirror a Subversion repository to a complete different remote server, you can use a distributed version control software like Bazaar or Git. Here’s an article how I do this with Bazaar.
In previous Ubuntu releases you could open different Firefox profiles with
firefox -P your_other_profile_name
As of Gutsy Gibbon, you accomplish the same by
firefox -P your_other_profile_name -no-remote