You’re writing some C code that you just managed to compile. You are able to get it to build without errors, and you’re ready to run. But then, something disastrous happens:

$ gcc main.c -o out
$ ./out
Segmentation fault

Great. Your application dies without so much as an explanation as to why. Nobody likes to debug code, but it has to be done at some point. If you compiled with the -g flag to gcc or g++, your program will have some debugging information included that special programs, like gdb, can use to assist you in solving the problem.

Nemiver is a graphical tool that can be used to take advantage of debugging information that uses gdb as a backend. It provides all of the features that the terminal-based gdb provides, but in a more sophisticated GUI interface that follows the code as it is executed. This means you can run code line-by-line, add breakpoints, view pointers, variables, memory registers, and see the call stack. In addition, you are also able to attach to a program over a network; so if your web server application goes down, you can run it over-the-wire with Nemiver to try to solve the problem.

Read the rest of Debugging with Nemiver

With the Ubuntu 8.04 release a few days away, there comes a time when one needs an end-all reference to the system. The time is now, and if you’re an Ubuntu user and liked the original cheat sheet, then do we have a surprise for you:

Click the preview above to download your PDF copy. This sheet is free to modify and redistribute for your own needs; we just ask that you keep the FOSSwire logo on the page. License: Creative Commons Attribution-Share Alike 3.0 Unported.

If you haven’t seen the previous sheet or would like one with more general Linux and Unix commands, see the original.

Translations:

• Spanish
• Russian
• Italian: (PDF) (ODT) (credit)

As always, we’re open to more translations and fixes. Enjoy!

There are times when you find a game that for some reason just doesn’t work well with Compiz. It may flicker over other windows, become distorted, or it may crash. The real fix for these comes in new X.Org drivers in the works, but for now the best solution is to suspend Compiz while you run a game.

Let’s think of a way to do this. First, we’ll obviously want to start Metacity and replace Compiz. Then, we want the game to run. And when we’re done, Compiz should start up again. The most logical script would be this:

#!/bin/bash
metacity --replace
game_name
compiz --replace

If you try to run the script above, you’d notice that Metacity would start, but nothing else would happen. This is because the commands are run synchronously, that is, when one finishes the next starts. Metacity will never finish unless you stop it. So, let’s make it run in the background:

#!/bin/bash
metacity --replace &
game_name
compiz --replace

The ampersand makes Metacity run in the background, allowing other commands to run. We then can run the game. The game shouldn’t be run in the background, however, because Compiz would immediately replace Metacity again.

At the end of the script, we start up Compiz again. This is where you don’t want to run the script in a terminal for once, because as soon as you close the terminal Compiz will quit. So, let’s make a menu item for it. I’m a big fan of StepMania, so I’m going to run the version I have installed in my home directory:

#!/bin/bash
metacity --replace &
cd ~/bin/stepmania
./stepmania
compiz --replace

If you run a command that requires a path, make sure to put the full path name in or your script may not run. We then add a menu entry in the Games menu:

Now whenever I decide to play StepMania, all desktop effects will be shut off. When I am finished, they will be switched back on again. This can be applied to almost any situation where Compiz needs to be off in your own scripts.