Category: Howto

Raspberry Pi

Raspberry Pi Logo

It’s Christmas time, which means that there is a pause from school and a pause from work as well (the office is closed). So I finally had enough time to set up the Raspberry Pi board I ordered few weeks ago. And it’s fantastic! I was really surprised how easy it was to set it up and get everything to work properly. Due to its popularity there are guides and howtos everywhere.

I would like to use mine as a sort of all-around home server for backups, file sharing, and git for now. But there is so much more you can do with the Pi :). The best thing, at least for the purposes I plan to use mine for, is its compactness and the most importantly complete lack of any noisy mechanical parts, such as fans or hard drives. That’s the killer feature for me. I mean, I sure have a drawer full of old hardware that would make a machine usable for just copying backups. Unfortunately, I don’t have a basement with ethernet and I wouldn’t survive with a cluster of coolers going 24/7 in my apartment. Additionally it consumes much less power than a regular PC does.

Get One

Two models of Raspberry Pi exist at the moment. Model A and B. The most notable differences between the two are the amount of memory (model B has 512MB while model A only 256MB), B also has one additional USB port and an ethernet (RJ-45). The full spec and comparison of the two is available on Wikipedia. I don’t know if model A is available already, but even if it was, go for model B. The ethernet port and an additional USB make a big difference. You don’t have to bother to buy an external USB hub or ethernet dongle.

Raspberry Pi Model B (Image comes from: http://www.raspberrypi.org/faqs)

Raspberry Pi Model B Illustration (http://www.raspberrypi.org/faqs)

As far as I know, you can get this board from two manufacturers — RS and Farnell. I got mine from RS, because Farnell stopped shipping these things to Czech Republic just a couple of days before I ordered it. My brother has his one from Farnell and they are almost identical, with only few cosmetic differences. The prices are also about the same. From RS it cost me roughly £31 with shipping to Czech Republic included.

However this is not everything you’ll need to set it up. No accessories is supplied with the board. You will need a power supply, a SDHC card to boot from, possibly a HDMI to DVI cable to plug it into a display, an ethernet cable to connect it to the network. These things cost me additional £17. I purchased a Samsung phone charger with micro-usb and a 16GB Class10 SDHC card from ADATA. Pay attention to what you’re buying, because not everything will be compatible with the Pi. There is a neat list of verified peripherals on the elinux.com wiki. You can have a problem with a power supply that is not able to provide current at least of 0.7A. There have been some problems with certain SD cards, so make sure to check the list. Raspberry Pi also comes without a case, so it might be a good idea to get one. There is a ton of cases available from different vendors. I liked this metal one.

I use the board without a head and access it over ssh, but you might need a display, a keyboard, and a mouse to handle the installation — for instance to click through some settings or install sshd. It works really nice with a monitor as well. I’m running Fedora 17 Raspberry Pi Remix on it at the moment, which comes with XFCE.

Wokring Raspberry PiRaspberry Pi in a case

Set It Up

As I said earlier, it is very easy to start with Raspberry Pi. Basically, all you need to do is to prepare the SD card. You need to copy one of the prepared OS images to the card and that’s it. The hardest thing is probably choosing the distro. You have a number of options available. There is, again, a list of available distributions on elinux.com. The “default” is Raspbian, which is a port of Debian Wheezy. I myself am used to Fedora, so I started with that one. Arch is also available, Gentoo ARM, OpenWrt or even Android. And the best thing is you can experiment with those really easily. If you have a spare SD card, you can reinstall your board as often as you want :).

To install Raspberry Pi on Linux, all you will need is the OS image and the dd command. You will copy the image to the card and that’s it. Note that the following command doesn’t reference a partition device (e.g. /dev/sde1), instead it uses directly the card device (/dev/sde).

dd bs=1M if=/path/to/rpfr-17-xfce-r2.img of=/dev/sde

When this is done, you can plug everything in and try it out. Just make sure you have connected everything before, you plug in the power. Raspberry Pi doesn’t have an off switch, so it will boot right away. If you encounter any problems, make sure to check the beginners guide and the troubleshooting advice.

Useful Links


If you liked this post, make sure you subscribe to receive notifications of new content by email or RSS feed.
Alternatively, feel free to follow me on Twitter or Google+.

Advertisements

Brief GDB Basics

In this post I would like to go through some of the very basic cases in which gdb can come in handy. I’ve seen people avoid using gdb, saying it is a CLI tool and therefore it would be hard to use. Instead, they opted for this:

std::cout << "qwewtrer" << std::endl;
DEBUG("stupid segfault already?");

That’s just stupid. In fact, printing a back trace in gdb is as easy as writing two letters. I don’t appreciate lengthy debugging sessions that much either, but it’s something you simply cannot avoid in software development. What you can do to speed things up is to know the right tools and to be able to use them efficiently. One of them is GNU debugger.

Example program

All the examples in the text will be referring to the following short piece of code. I have it stored as segfault.c and it’s basically a program that calls a function which results in segmentation fault. The code looks like this:

/* Just a segfault within a function. */

#include <stdio.h>
#include <unistd.h>

void segfault(void)
{
	int *null = NULL;
	*null = 0;
}

int main(void)
{
	printf("PID: %d\n", getpid());
	fflush(stdout);

	segfault();

	return 0;
}

Debugging symbols

One more thing, before we proceed to gdb itself. Well, two actually. In order to get anything more than a bunch of hex addresses you need to compile your binary without stripping symbols and with debug info included. Let me explain.

Symbols (in this case) can be thought of simply variable and function names. You can strip them from your binary either during compilation/linking (by passing -s argument to gcc) or later with strip(1) utility from binutils. People do this, because it can significantly reduce size of the resulting object file. Let’s see how it works exactly. First, compile the code with striping the symbols:

[astro@desktop ~/MyBook/code]$ gcc -s segfault.c

Now let’s fire up gdb:

[astro@desktop ~/MyBook/code]$ gdb ./a.out
GNU gdb (GDB) Fedora (7.3.1-48.fc15)
Reading symbols from /mnt/MyBook/code/a.out...(no debugging symbols found)...done.

Notice the last line of the output. gdb is complaining that it didn’t find any debuging symbols. Now, let’s try to run the program and display stack trace after it crashes:

(gdb) run
Starting program: /mnt/MyBook/code/a.out 
PID: 21568

Program received signal SIGSEGV, Segmentation fault.
0x08048454 in ?? ()
(gdb) bt
#0  0x08048454 in ?? ()
#1  0x0804848d in ?? ()
#2  0x4ee4a3f3 in __libc_start_main (main=0x804845c, argc=1, ubp_av=0xbffff1a4, init=0x80484a0, fini=0x8048510, 
    rtld_fini=0x4ee1dfc0 , stack_end=0xbffff19c) at libc-start.c:226
#3  0x080483b1 in ?? ()

You can imagine, that this won’t help you very much with the debugging. Now let’s see what happens when the code is compiled with symbols, but without the debuginfo.

[astro@desktop ~/MyBook/code]$ gcc segfault.c 
[astro@desktop ~/MyBook/code]$ gdb ./a.out 
GNU gdb (GDB) Fedora (7.3.1-48.fc15)
Reading symbols from /mnt/MyBook/code/a.out...(no debugging symbols found)...done.
(gdb) run
Starting program: /mnt/MyBook/code/a.out 
PID: 21765

Program received signal SIGSEGV, Segmentation fault.
0x08048454 in segfault ()
(gdb) bt
#0  0x08048454 in segfault ()
#1  0x0804848d in main ()

As you can see, gdb still complains about the symbols in the beginning, but the results are much better. The program crashed when it was executing segfault() function, so we can start looking for any problems from there. Now let’s see what we get when debuginfo get’s compiled in.

[astro@desktop ~/MyBook/code]$ gcc -g segfault.c 
[astro@desktop ~/MyBook/code]$ gdb ./a.out 
GNU gdb (GDB) Fedora (7.3.1-48.fc15)
Reading symbols from /mnt/MyBook/code/a.out...done.
(gdb) run
Starting program: /mnt/MyBook/code/a.out 
PID: 21934

Program received signal SIGSEGV, Segmentation fault.
0x08048454 in segfault () at segfault.c:9
9		*null = 0;

That’s more like it! gdb printed the exact line from the code that caused the program to crash! That means, every time you try to use gdb to get some useful directions for debugging, make sure, that you don’t strip symbols and have debuginfo available!

Start, Stop, Interrupt, Continue

These are the basic commands to control your application’s runtime. You can start a program by writing

(gdb) run

When a program is running, you can interrupt it with the usual Ctrl-C, which will send SIGINTR to the debugged process. When the process is interrupted, you can examine it (this is described later in the post) and then either stop it completely or let it continue. To stop the execution, write

(gdb) kill

If you’d like to let your program carry on executing, use

(gdb) continue

I should point out, that in gdb, you can abbreviate most of the commands to as little as a single character. For instance r can be used for run, k for kill, c for continue and so on :).

Stack traces

Stack traces are very powerful when you need to localize the point of failure. Seeing a stack trace will point you directly to the function, that caused you program to crash. If your project is small or you keep your functions short and straight-forward, this could be all you’ll ever need from a debugger. You can display stack trace in case of a segmentation fault or generally anytime when the program is interrupted. The stack trace can be displayed by a backtrace or bt command

(gdb) bt
#0  0x08048454 in segfault () at segfault.c:9
#1  0x0804848d in main () at segfault.c:17

You see, that the program stopped (more precisely was killed by the kernel with a SIGSEGV signal) at line 9 of segfault.c file while it was executing a function segfault(). The segfault function was called directly from the main() function.

Listing source code

When the program is interrupted (and compiled it with debuginfo), you can list the code directly by using the list command. It will show the precise line of code (with some context) where the program was interrupted. This can be more convenient, because you don’t have to go back into your editor and search for the place of the crash by line numbers.

(gdb) list
4 #include 
5
6 void segfault(void)
7 {
8   int *null = NULL;
9 *null = 0;
10 }
11
12 int main(void)
13 {

We know (from the stack trace), that the program has stopped at line 9. This command will show you exactly what is going on around there.

Breakpoints

Up to this point, we only interrupted the program by sending a SIGTERM to it manually. This is not very useful in practice though. In most cases, you will want the program stop at some exact place during the execution, to be able to inspect what is going on, what values do the variables have and possibly to manually step further through the program. To achieve this, you can use breakpoints. By attaching a breakpoint to a line of code, you say that you want the debugger to interrupt every time the program wants to execute the particular line and wait for your instructions.

A breakpoint can be set by a break command (before the program is executed) like this

(gdb) break 8
Breakpoint 2 at 0x4005c0: file segfault.c, line 8.

I’m using line number to specify, where to put the break, but you can use also function name and file name. There are multiple variants of arguments to break command.

You can list the breakpoints you have set up by writing info breakpoints:

(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep n   0x00000000004005d8 in main at segfault.c:14
2       breakpoint     keep y   0x00000000004005c0 in segfault at segfault.c:8

To disable a break point, use disable <Num> command with the number you find in the info.

Stepping through the code

When gdb stops your application, you can resume the execution manually step-by-step through the instructions. There are several commands to help you with that. You can use the step and next commands to advance to the following line of code. However, these two commands are not entirely the same. Next will ‘jump’ over function calls and run them at once. Step, on the other hand, will allow you to descend into the function and execute it line-by-line as well. When you decide you’ve had enough of stepping, use the continue command to resume the execution uninterrupted to the next break point.

Breakpoint 1, segfault () at segfault.c:8
8		int *null = NULL;
(gdb) step
9		*null = 0;

There are multiple things you can do during the process of stepping through a running program. You can dump values of variables using the print command, even set values to variables (using set command). And this is definitely not all. Gdb is great! It really can save a lot of time and lets you focus on the important parts of software development. Think of it the next time you try to bisect errors in the program by inappropriate debug messages :-).

Sources

Fedora 17 Tweaks

I finally had a moment to perform the annual desktop re-install to upgrade the OS on my primary computer. It’s always a little bit of pain, because I pretty much rely on that machine and I want to have everything in place and ready to use. I upgraded from Lovelock to Beefy Miracle which took me from Gnome 3.0 right to 3.4. Things moved forward a lot during the past year! Lots of people hate Gnome Shell, but I’m ok with it – despite the occasional segfault. It’s definitely not perfect, but I like the idea of using the SUPER key for switching between applications. I have bindings for switching workspaces and after all, I end up using vim, chromium and terminal anyway :).

There are always some post-installation tweaks I like to do, to make the system fit my personal needs more. Here they are, maybe someone could use them as well.

Gnome Tweak Tool

This is the first thing to install to a fresh Fedora 17 or probably any distribution using Gnome 3 desktop. For some reason, the designers decided, that normal users don’t like to change fonts or window manager themes and they moved all this “things for advanced users” to gnome-tweak-tool. To install it, use the following command

 $ su -c 'yum install gnome-tweak-tool'

This will add Advanced Settings icon to the application picker in activities overview (that comes up after you hit the windows key). The application allows you to fine-tune various parts of Gnome, such as font sizes, icons on the desktop, enable or disable extensions etc.

Gnome 3 - Advanced Settings

Gnome 3 – Advanced Settings in Application Menu

Gnome Tweak Tool

Gnome Tweak Tool

Clearlooks in Gnome 3.4

What surprised me the most is lack of Clearlooks theme in Fedora 17. I got used to that theme too much over the years! Luckily for me, there’s a port for Gtk 3 called Clearlooks-Phenix! To install this theme you need to download and unpack Clearlooks-Phoenix 2, which is suited for Gtk 3.4. After that, copy the contents of the archive either to /usr/share/themes to make it available for all users or ~/.themes just for yourself. There are more detailed install installing instructions available directly on the project’s website. Here’s a series of commands, that will do that

$ wget http://jpfleury.indefero.net/p/clearlooks-phenix/source/download/master/
$ unzip clearlooks-phenix-master.zip
$ mv clearlooks-phenix-master Clearlooks-Phenix
$ su -c 'cp -r Clearlooks-Phenix /usr/share/themes'
Clearlooks-Phenix theme preview in Fedora 17

Clearlooks-Phenix theme preview in Fedora 17

Nautilus Loading Too Long

I have this problem with Nautilus on my installation. When the file browser starts, cursor changes to the loading circle one and stays like that for 20 seconds. The application on the other hand seems to be loaded and fully usable. Fortunately, there is a simple workaround to this problem. To fix this, simply edit /usr/share/applications/nautilus.desktop, find line that contains StartupNotify=true (131 on my system) and change the value to false.

Nautilus Loading Issue

Nautilus keeps up the loading cursor for 20 sec

Nautilus executable config

Nautilus executable config options

Multiple Workspaces with Two Screens

Another thing that bothers me on Gnome 3.4 is that, there are no workspaces on the secondary screen. The designers assume, that if you have two monitors, you use workspaces on the primary one and “pin” some windows to the secondary screen, that will stay there all the time through the context switching. I prefer to have this the other way though (i.e. so the workspaces change on the secondary screen as well). This can be easily altered by issuing this command:

 $ gsettings set org.gnome.shell.overrides workspaces-only-on-primary false

The situation is also described in the following articles:

Blue Faces in Flash Player

This issue is caused by combination of Adobe Flash player and nVidia proprietary drivers. And for some reason, the colors are messed up in flash videos. I guess, that Linus was right (again). To fix this, you need turn off the hardware acceleration in flash player settings. Right click on the flash video, chose Settings and untick the Enable Hardware Acceleration option. You need to restart your browser for the change to take effect.

Corrupt colors in flash

This is just annoying

The normal colors

Right click + Settings, untick and restart your browser

Logging Screen Background

I personally don’t like fireworks that much 😛 and since they’re the default background of Beefy Miracle, the wallpaper is also present behind the logging screen. You can change the default wallpaper by editing

 # vim /usr/share/backgrounds/beefy-miracle/default/beefy-miracle.xml

and changing the paths to wallpapers for different screen sizes. I like the blue Gnome stripes. For that one, you can set the path to /usr/share/backgrounds/gnome/Stripes.jpg.

Keyboard Layout Resets to US on Logout

I don’t know what’s causing this and I didn’t find a complete workaround either. Every time I log off from my account, the keyboard layout is reset to English(US), despite the settings where the default is Czech. The workaround for this is to remove the English(US) from layout settings completely and keep only Czech. I can live with that, but it can be pretty annoying to other people I guess.

Other Useful Links


If you liked this post, make sure you subscribe to receive notifications of new content by email or RSS feed.
Alternatively, feel free to follow me on Twitter or Google+.

Custom Kernel on Fedora

Why would someone want to have a custom kernel? Well, maybe you like the cutting-edge features or maybe you want to hack on it! Anyway, this post explains step-by-step, how to download, build and install your custom kernel on Fedora. I’ll be building kernel from the mainline tree for i686.

Warning: Keep in mind that if something goes wrong you might end up irreversibly damaging your system! Always keep a fail-safe kernel to boot to, just in case!

1. Getting the kernel tree

Linux kernel tree is developed using git revision control system. There are a LOT of different versions and different trees of the kernel maintained by various people. The development tree is linux-next, Linus’ mainline is called simply linux, there is also linux-mm which had a similar purpose as linux-next today. You need to pick one and clone it locally. In this how-to, I’ll stick with the linux tree from Linus that is at least a tiny bit more stable than linux-next. Use the following to get the source:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

2. Patching the source

Since this is really bleeding-edge code, there might be some problems with compilation or other bugs. Now is the time to patch the tree to resolve all these issues. Also if you want to hack a little and do some of your own changes to the kernel, now is the time! Don’t be afraid, it’s not that hard …

3. Configure the kernel

Kernel is a pretty big piece of software and it provides a shitload of  configuration options. Various limits and settings can be adjusted in this phase. You can also decide, what parts of kernel such as what drivers will be included in your build. Like I said, there is a lot of options and a couple of ways of setting them:

$ make config     # Go through each and every option by hand
$ make defconfig  # Use the default config for your architecture
$ make menuconfig # Edit the config with ncurses gui
$ make gconfig    # Editing with gtk GUI app

Sometimes, the kernel is built with an option that it saves it’s configuration in /proc/config.gz. If this is your case, you can copy it inside the tree and use make oldconfig. This will ask only for the new features, that were not present in the previous version.

$ zcat /proc/config.gz > .config
$ make oldconfig

On Fedora, the configuration of currently installed kernels can be found in the /boot directory:

$ ll /boot/config*
-rw-r--r--. 1 root root 123540 Mar 20 17:31 /boot/config-2.6.42.12-1.fc15.i686
-rw-r--r--. 1 root root 125193 Apr 21 15:54 /boot/config-2.6.43.2-6.fc15.i686
-rw-r--r--. 1 root root 125204 May  8 14:23 /boot/config-2.6.43.5-2.fc15.i686

4. Build it

When you’re done configuring, you can advance to the build. The only advice I can give you here to take advantage of -j option that make offers if you’re on a system with multiple cores. To build the kernel using 2 jobs per core on a dual-core processor use:

$ make -j4

It will significantly improve the build times. Either way, it will take some time to build, so it’s time to get a coffee!

5. Installation

Result of successful build should be a bzImage located in arch/i386/boot/bzImage and a bunch of built modules *.ko (kernel object). It’s vital to point out, that bzImage isn’t just a bzip2-compressed kernel object. It’s a specific bootable file format, that contains compressed kernel code along with some boot code (like a stub for decompressing the kernel etc).

Anatomy of bzImage (source: wikipedia.org)

To install the new kernel, rename and copy the bzImage to boot and install the modules by writing:

# cp arch/i386/boot/bzImage "/boot/vmlinuz-"`make kernelrelease`
# make modules_install

The modules will be installed to /lib/modules. Also a file called System.map will be created in the root of kernel source tree which is a symbol look-up table for kernel debugging. You can place it into /boot along with the image:

# cp System.map "/boot/System.map-"`make kernelrelease`

The file contents looks like this:

$ head System.map
00000000 A VDSO32_PRELINK
00000040 A VDSO32_vsyscall_eh_frame_size
000001d5 A kexec_control_code_size
00000400 A VDSO32_sigreturn
0000040c A VDSO32_rt_sigreturn
00000414 A VDSO32_vsyscall
00000424 A VDSO32_SYSENTER_RETURN
00400000 A phys_startup_32
c0400000 T _text
c0400000 T startup_32

6. Initramfs

When all the files are in place, you need to generate the initial ramdisk (initramfs). The initial filesystem that is created in RAM is there to make some preparations before the real root partition is mounted. For instance if you’re root is on a RAID or LVM, you’ll need to pre-load some drivers etc. It usually just loads the block device modules necessary to mount the root.

There’s an utility called dracut, that will generate this for you.

# dracut "" `make kernelrelease`

This will generate the image and store it into /boot/initramfs-kernelrelease.img. To inspect the file use

# lsinitrd /boot/initramfs-kernelrelease.img

7. Bootloader Settings

In the final step, before you can actually boot the new kernel is to configure your bootloader and tell it that the new kernel is there. There was a transition between Fedora 15 and Fedora 16 from GRUB 0.97 (nowdays known as grub-legacy) to new GRUB2 so I’ll explain both.

grub-legacy

In the old version (which I am currently using on F15) you need to edit the /boot/grub/menu.lst file and add new entry with paths to your kernel and initrd. The entry might look like the following:

title Fedora (2.6.41.10-3.fc15.i686)
      root (hd0,0)
      kernel /boot/vmlinuz-3.1.0-rc7 ro root=UUID=58042206-7ffe-4285-8a07-a1874d5a70d2 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=cz-us-qwertz rhgb quiet
      initrd /boot/initramfs-3.1.0-rc7.img

grub2

In grub2 you should be able to do this automatically by this command

# grub2-mkconfig -o /boot/grub2/grub.cfg

After this step you can reboot and let your machine chew on some fresh meat directly from the developers! Probably as fresh as it’ll ever get! Boot up and enjoy ;-).

Sources


If you liked this post, make sure you subscribe to receive notifications of new content by email or RSS feed.
Alternatively, feel free to follow me on Twitter or Google+.

Fun with netcat

Ever heard of nc? It’s a simple utility that is able to connect to a remote host via TCP or UDP socket and send data. Basically it’s a command line interface to the BSD socket API. The manual page says

The nc (or netcat) utility is used for just about anything under the sun involving TCP, UDP, or UNIX-domain sockets.  It can open TCP connections, send UDP packets, listen on arbitrary TCP and UDP ports, do port scanning, and deal with both IPv4 and IPv6.

And why am I writing a whole post about this? Because it’s insanely powerful tool for development of network apps. It can be used to try out what you need to pass to the socket in order to get some data. RFC‘s are good, but when it comes to basic understanding of some protocol they’re pretty useless. I mean who wants to read a 60+ page RFC full of technical implementation details. These are also pretty hard to understand sometimes. With netcat, you can try contacting the server yourself first with your keyboard! This is the most amazing part, you simply write the messages that your program needs to send. For example if you’re programming an http client you can write your own request like this

astro@desktop:~$ nc www.google.cz 80
GET /
HTTP/1.0 302 Found
Location: http://www.google.cz/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Date: Sun, 18 Sep 2011 21:32:24 GMT
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block

The only thing you need to write is GET / and the server will respond to your http GET request. This is much more convenient than reading hundreds of RFC’s before you start even thinking about programming an http client. Other than that it works exactly the same way as cat (and no, not the furry one). Everything you pass to it, it will pass along to the remote server.

This way you can test almost all text protocols that work over TCP or UDP. Just recently I did a pop3client and netcat helped me to track some bugs as well.

Sources

nVidia CUDA on Linux (Fedora 15)

I recently updated my desktop with a new graphic card from nVidia — a pretty low-end GT440. It’s actually my first nVidia card. I owned three ATI Radeon cards (Sapphire 9550, 9600Pro and HD2600XT) before. The main reason for this was, that I needed CUDA enabled card in order to be able to work on my school project (I study computer graphics). On top of that, Gnome 3 has some issues with ATI drivers and the HD2600XT is like 5 years old today :-P. Anyway, I recently installed the nVidia CUDA SDK on Fedora 15 and I made a little howto along the way.

Installing gcc

One of the biggest issues in with CUDA is that it officially supports only gcc of version 4.4 and earlier. That’s a bummer, especially on Fedora, where there is gcc-4.6 by default and you need to compile the older version yourself. I posted series of steps to compile gcc from sources in a separate article Multiple Versions of gcc on Fedora 15.

Drivers

There is something called Developer Drivers for Linux available from the nVidia website. I don’t know what it is or how is it different from the original drivers, but I couldn’t make them work. The installation kept dying with some error with kernel headers.

Good news is, that you don’t need them. At least I was able to compile and run the CUDA SDK without installing these only with the standard nVidia proprietary driver (version 285.05.09). If you’re running them, you’re fine. In case you have the noveau open-source drivers you need to get rid of them and install the nVidia proprietary driver.

There is one little thing you need to do if you chose not to install the developer drivers: make a symlink for libcuda.so like this

su
cd /usr/lib
ln -s nvidia/libcuda.so libcuda.so

CUDA Toolkit

This is pretty straight-forward. Download and run shell script from the nVidia download page. Choose what’s closest to your distro. In this case it’s Fedora 13. Fedora 15 is officially unsupported due to the lack of old gcc. But we have sorted this earlier, so it’s fine to use the F13 pack.

wget http://www.nvidia.com/object/thankyou.html?url=/compute/cuda/4_0/toolkit/cudatoolkit_4.0.17_linux_32_fedora13.run
sudo sh cudatoolkit_4.0.17_linux_32_fedora13.run

In case you’re prompted with question where to install the toolkit, just hitto keep the defaults.

GPU Computing SDK

Installing the SDK is as easy as the toolkit. Download and run the script from nVidia homepage. This time you won’t need root permissions, because it will install into your home folder.

Setting System Path

The tricky part is here, now you need to make sure all  the libraries and tools are present in the correct environment variables. Edit your ~/.bashrc file and add the following:

# CUDA
export PATH="$PATH:/usr/local/cuda/bin"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib"

Reopen your shell and you should be able to run the nvidia C compiler. Make sure by trying this

 nvcc --version

The last step is trying to compile all the examples in the SDK. Change to that directory and simply run make.

 cd /NVIDIA_GPU_Computing_SDK
 make

Everything should be working. There will be a lot of warnings during the compilation, but we just have to ignore that …

Sources

Multiple Versions of gcc on Fedora 15

This post describes a way of building and installing additional versions of GNU gcc compiler on Fedora 15. The version shipped with Lovelock is gcc 4.6.1 which can sometimes be too new. Some apps such as nVidia CUDA SDK requires a specific version of compiler for some reason. In this howto I’ll be installing gcc-4.4.6.

Notice: There is an official installation guide that will help you if something doesn’t work (or I forgot to mention something here).

1. Getting the Source

I guess, nobody will be surprised when I say, that the first step is to obtain the sources. Go to http://gcc.gnu.com, pick a mirror and download the version you need. The best option is usually downloading the package with all languages included (e.g. gcc-4.4.6.tar.gz). We will unpack the archive and rename the directory to source/. It is also recommended to build the binaries into a separate directory from the sources, so we’ll create a build/ folder too:

 $ tar xzf gcc-4.4.6.tar.gz
 $ mv gcc-4.4.6/ source/
 $ mkdir build/

2. Configure

Now we have everything in place, we need to configure the build. Change into the build/ directory and call the configure script:

 $ cd build/
 $ ../source/configure --prefix=/opt/gcc4.4.6 \
                       --program-suffix=-4.4

As you can see, there are some parameters. --prefix option says where should be the gcc installed after the build. We will install it separately into the /opt directory, so it will be easily removable in the future only by deleting the respective directory. --program-suffix will be added to the name of the executable (in this case gcc-4.4), so it doesn’t collide with other installed versions of gcc on your system.

Warning: Be careful with the --program-suffix option. You might have to make some symlinks to use the compiler in some vendor Makefiles. It will be explained later in this post.

Optionally you can add --enable-languages=c,c++ to choose what languages support will be compiled. For more options, refer to the official guide above.

In case the configure script fails, you probably don’t have all the necessary packages installed to perform the build. See what’s missing and install it with yum. For me the following was enough:

 $ su
 # yum groupinstall "Development tools"
 # yum install mpfr-devel

The full list of prerequisites can be found here.

3. Build

The build is fairly simple, if you see some warnings, feel free to ignore them. To build gcc write the following inside the build/ directory:

 $ make

Now is the time to get some coffee, because it will take a while to build.

4. Installation

Installation is also quite easy. You can install gcc by writing

 $ su
 # make install

Then check whether the installation was correct and everything is in place

 $ /opt/gcc4.4.6/bin/gcc-4.4 --version

5. Using alternate compiler

Using the alternate compiler is a little tricky. You can it to your system path by appending this line to your ~/.bashrc file.

export PATH="/opt/gcc-4.4.6/bin:$PATH"

The alternate compiler is available through gcc-4.4 name (as we defined in the configuration phase). That is cool for your Makefiles, but some vendors hardcode compiler name into their Makefile which doesn’t help at all. If this is your case, the best way to get things to work is to make symlinks to the alternate gcc and append the directory to the begining of $PATH  string. Here are example symlinks for gcc and g++:

su
cd /opt/gcc-4.4.6/bin
ln -s gcc-4.4 gcc
ln -s g++-4.4 g++

Note, that the system look-up in the $PATH folder is sequential, so if you append the directory to the front of the variable, it will have higher priority. If you need to use the newer compiler again, simply remove the directory from path by commenting out the line in ~/.bashrc. Remember, you can always find out version of your current gcc by writing

 $ gcc --version

Sources

Learning Ruby

I always wanted to learn Ruby. It became so popular over the last couple of years and I hear people praise the language everywhere I go. Well, time has come and I cannot postpone this anymore (not with a clear conscience anyway). So I’m finally learning Ruby. I went quickly over the net and also our campus library today, to see what resources are available for the Ruby newbies.

Resources

There is a load of good resources on the internet, so before you run into a bookstore to buy 3000 pages about Ruby, consider starting with the online books and tutorials. You can always buy something on paper later (I personally like stuff the old-fashioned way — on paper more). Here is a list of what I found:

That would be some of the online sources for Ruby beginners. And now something on paper:

  • The Ruby Way by Hal Fulton — Great, but sort-of-a big-ass book. Just don’t go for the Czech translation, it’s horrifying
  • Learning Ruby by Michael Fitzgerald — A little more lightweight, recommend ford bus-size reading!

I personally read The Ruby Way at home and the Learning Ruby when I’m out somewhere. Both of them are good. These are the books that I read (because I could get them in the library). There is a pile of other titles like:

Just pick your own and you can start learning :-).

Installation

Ruby is interpreted language so we will need to install the ruby interpret. On Linux it’s fairly simple, most distributions have ruby packed in their software repositories. On Fedora 15 write sudo yum install ruby. On Debian-based distros sudo apt-get install ruby. If you are Windows user, please, do yourself a favor and try Ubuntu!

To check whether the ruby interpret is available go to terminal and type

 $ ruby --version

Hello Matz!

The only thing that’s missing is the famous Hello World :-)! In Ruby the code looks something like this:

#!/usr/bin/env ruby

puts "Hello Matz!"

Summary

From what I saw during my yesterdays quick tour through Ruby, I can say, that it’s a very interesting language. I’d recommend anyone to give it a shot! I definitely will.

Update: Stay tuned for more! I’m working on a Ruby language cheat sheet right now.

Sources

Building Ogre3D from Sources on Fedora 15

This is a little walk-through the whole build process of Ogre 3D rendering engine. It’s primarily for users of Fedora GNU/Linux distribution or any similar distro that uses rpms and yum. I chose the variant using cmake, so first thing you want to do is install cmake.

 $ su -c 'yum install cmake cmake-gui'

After that there are also some prerequisites, that you need to install. For the Cg package you’ll need to enable rpmfusion nonfree repositary by writing

 $ su -c 'yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

Then install the dependencies using

 $ sudo yum install gcc-c++ libXaw-devel freetype-devel freeimage-devel \
                    zziplib-devel boost-devel ois-devel Cg doxygen \
                    cppunit-devel

Some of them are optional, but I like to install them all, just in case. Since the hard-drive space is no longer an issue, it could save you from having to build it all over again. After that proceed to downloading the latest version of Ogre3d source and unpack it somewhere.

 $ cd ~/Downloads
 $ tar xjf ogre_src_v1-7-3.tar.bz2

This will extract the sources into a new directory. Let’s rename it to source. Then we’ll need another directory where all the binaries will be places. Let’s call it build. After that run cmake.

 $ mv ogre_src_v1-7-3/ source/
 $ mkdir build
 $ cmake-gui

In the gui set both paths to the source and to the build directory and hit Configure button, leave the defaults (Unix Makefiles and Use default native compilers).

CMake example (building Ogre3D) CMake

Check the Advanced and Grouped check-boxes and make sure you have installed everything you might need. If you compile ogre without some features here, you’ll need to do it all over again (I did it 4 times when I compiled Ogre for the first time). You should have installed zzip, zlib, freeimage, freetype, boost, opengl, X11, and ois. If you don’t, I highly recommend to install those libs and hit configure again. When you’re done, hit Generate.

At this point, we’re done with the cmake, you can close the window and get back to your terminal window. Now we proceed to the building process itself. Change to the build/ directory and run make to compile Ogre3D and wait.

 $ cd build
 $ make

There will be percentage coming up as the library builds. It takes (on my machine) a solid half-hour to build, so feel free to go get some coffee. The only thing left is installing the compiled library to your system using the classic

 $ su -c 'make install'

Enjoy your Ogre!

Sources

String Generation for Brute-force Attacks

Everyone knows what a brute-force attack is. One of the most trivial (and yet pretty useful) methods of cracking passwords and breaking access keys. The idea is simply trying all possible sequences of input characters, until you guess the right combination. The thing is, that it might take some time. Actually, sometimes it might take literally ages, due to large number of possible outcomes. The faster our machines (and algorithms!) get, the lesser time it takes to break in using brute-force attack.

One of the key components in this technique is an algorithm that generates the input combinations. It’s run every time in the main loop. Well, the loop is pretty much generate a password, try it and try again. This article will present a couple of simple implementations of string sequence generators in various languages.

Python implementation

Here is code for a most basic example in Python. It’s a simple recursive function that is able to generate strings up to infinite length. I use a list instad of string in this example, because strings in python are immutable. You need to convert it to string ("".join(list)).

def next(string):
    if len(string)
        string.append(chr(0))
    else:
        string[0] = chr((ord(string[0]) + 1) % 256)
        if ord(string[0]) is 0:
            return list(string[0]) + next(string[1:])
    return string

Download the whole example from github.

This example is simple. It tries every possible combination which takes it’s success rate up to 100 percent. You just can’t miss anything if you try them all, right? But a lot of the characters from ASCII table are non-printable, weird and people don’t use them for passwords. So you spend a great amount of time by trying out combinations that are extremely unlikely to ever occur. It would be pretty awesome if there was some way of saying what characters can be part of a password string and use only them. The number of possible outcomes lowers a lot by this optimization while the chance to miss is still almost zero. I made a some alternations to the next() function above:

import string
ALLOWED_CHARACTERS = string.printable
NUMBER_OF_CHARACTERS = len(ALLOWED_CHARACTERS)

def characterToIndex(char):
    return ALLOWED_CHARACTERS.index(char)

def indexToCharacter(index):
    if NUMBER_OF_CHARACTERS
        raise ValueError("Index out of range.")
    else:
        return ALLOWED_CHARACTERS[index]

def next(string):
    if len(string)
        string.append(indexToCharacter(0))
    else:
        string[0] = indexToCharacter((characterToIndex(string[0]) + 1) % NUMBER_OF_CHARACTERS)
        if characterToIndex(string[0]) is 0:
            return list(string[0]) + next(string[1:])
    return string

This snippet above works only with printable characters (as specified in python’s string module). You can also change the subset of characters it works with by changing the value of ALLOWED_CHARACTERS constant. The whole source is again available at github.

Next time I’ll look into a C implementation of the technique and a comparison of speed between the two languages.