Five short years ago I wrote an article about my desire for a Nokia N900. I was extremely enthusiastic about the device, which I saw as the future of computing and a sign of things to come. I also said:
Personally I think Linux usage overtaking Windows on personal computing devices is inevitable, and this is how it’s going to happen (although the capabilities of the N900 will have to move down to a much lower price point first). We’ll see if I’m right in 5-10 years time.
It’s now 4 years and 4 months later. I was right about Linux overtaking windows on personal computing devices, but I was wrong about how, and it happened far more quickly than I could have imagined.
In what could only fall firmly into the first-world problems category, I’m currently suffering a dilemma as to what laptop I should buy. My requirements are common – a good balance of power, performance and portability. I’ve decided the specification I should go for is:
Intel Core i5 (4th generation, Haswell)
13″ display, resolution at least 1920×1080
I think these specs make for the best price / performance balance on most of the laptops I’ve priced up.
Received the following error when running puppet after upgrading to Mavericks:
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- puppet/util/command_line (LoadError)
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
from /usr/bin/puppet:3:in `<main>'
Solution is to symlink the packages to the new ruby 2.0.0 directory:
I wanted nice, concise instructions on changing the boot order in Ubuntu 13.04, which uses Grub 2. Being a newbie focused OS however, Googling “ubuntu boot order” results in SEO blogs with lots of fluff, and then the actual instructions start out with “install package from ppa”…
What the hell, I just want to change the boot order!
Python is a fantastic tool to know, and despite being a beginner I find myself using it more and more for everyday tasks. Bash is great for knocking together quick scripts, but when you want to something a little more complex such as interfacing with APIs or other systems over a network, you really need a more fully-featured programming language.
The topic of this post, however, is the kind of task that bash is perfect for. Thanks to mysqldump, a database backup script can be written in a few lines and dump/restores are easily automated. So why on earth would we do this in Python? Continue reading →
if [ -e $COMP ]; then
echo "Please supply a competition_id"
On first read it looks backwards – “if exist $COMP then exit”, and the programmer clearly wanted to do the exact opposite. However it actually works as desired. Mostly.
If no argument is supplied, $COMP will be a blank string, i.e. “”. Thus [ -e $COMP ] will parse to [ -e ], which returns 0 (effectively true). It’s basically like saying “does nothing exist”.
This is because the -e argument tests whether a file exists. So if an argument is supplied, [ -e $COMP ] will return 1 (effectively false), which does what the programmer intended UNLESS the argument supplied is a valid file path.
In this case a number was expected, so sure it’s unlikely to fail in this way, but it’s still an incredibly bad way to test if an argument is set. Not to mention confusing to read!
The correct way to test this by the way would be to use -z, which simply tests if a string’s length is zero:
if [ -z "$COMP" ]; then
echo "Please supply a competition id"
Or better still, use getopts. For more info run ‘man test’ from a bash terminal.
Had this problem when trying to start a newly created VM and install from certain ISO files. Some ISO images would work and others would not.
Removing the ISO image allowed the VM to start but obviously there was no OS image to install from.
The error message is generic and not very helpful, but if you do encounter it check that the ISO is readable by the Xen server. In our case it was on an NFS share but the permissions were read-only to all but the owner…. so a simple `chmod a+r *.iso` fixed it!
I was having this problem on Ubuntu 12.04 (precise), but most of the Google results pointed to a bug in Hardy. However there are other causes of this problem.
In my case it was a previously-created share with a different user ID – Nautilus couldn’t create the share because there was already a share file with the same name owned by a different user.
The directory is /var/lib/samba/usershares. You should already have write access assuming you’re a member of the sambashare group (which the gui should handle for you), so all that remains to be done is remove the offending share with the same name as the one you’re trying to create.
alex@al4:~$ cd /var/lib/samba/usershares/
alex@al4:/var/lib/samba/usershares$ ls -lah
drwxrwx--T 2 root sambashare 4.0K Jul 25 12:33 .
drwxr-xr-x 5 root root 4.0K May 1 10:40 ..
-rw-r--r-- 1 2046297271 2046296576 142 Oct 25 2011 music
-rw-r--r-- 1 2046297271 2046296576 128 Feb 7 17:13 videos
alex@al4:/var/lib/samba/usershares$ sudo rm music
[sudo] password for alex:
alex@al4:/var/lib/samba/usershares$ sudo rm videos
After doing the above, Nautilus was able to recreate the shares without trouble.
In implementing the Percona Monitoring Plugins for Redis on our Cacti server we discovered that they don’t support authentication. This creates a problem when your servers require authentication to issue the “INFO” command.
The Percona templates use ss_get_by_ssh.php to fetch the data, and there are functions specific to Redis in this file. So I added a variable to store the password, and modified the redis_get function to run an AUTH command on the socket before INFO. Continue reading →
I previously posted about this on previous versions of Ubuntu, but despite updating the instructions for 11.10 the instructions are once again obsolete. It seems Intel changes the name of its wifi kernel module every release…
On my Dell E4300 with “Intel Corporation WiFi Link 5100” (as reported by lspci), the module name is now “iwlwifi”. This means the kernel options you add to /etc/modprobe.d should be against this module rather than iwlcore (11.04) or iwlagn (11.10).