Absolutely include concepts here - as Pukku said - being knowledgeable and skilled in a concept can outweigh a specific technology and it is good subject matter for interview questions. Not only that, but it's good hit-word fodder for automatic resume crawlers.
As a thought - for placement and highlighting, there's a lot of rows in the sample resume, filled with very few items - Languages, Frameworks, Compilers, Debuggers, Tools and OS - all of which have 1-2 items. That seems like a lot of resume real estate for not a lot of information. I'd find a way to condense this. Knowing a bit about software, for example, I'd offer the questions:
- the tools related to the Qt framework, are these the standard for how to develop products with Qt, is there a very very high chance that if you know the Qt framework you are working with these tools? If so, then remove the row about tools.
- IMO (open to debate) - a "cc" type compiler for C/C++ is par for the course - certainly not everyone has specifically used "gcc", but most have used something similar. If the candidate is an absolute whiz with gcc and can address all sorts of C-to-machine-code issues that are unique to the compiler, then say something like "gcc Expert" - if not, skip it.
- OS - keep it, but be cautious about being overly specific. If you've used OpenSUSE 11.4, I'd expect you'd be perfectly qualified for 11.5 or even 12, and probably wouldn't have a problem with 9 or 10, either. And I'm going to bet that you'll be OK on almost any flavor of Linux - so telling me OpenSUSE 11.4 makes it feel very specific, and I'm not sure you want that.
Most managers are smart enough to realize things like that - that a person who's worked on gcc won't have a problem with another similar compiler, that a "Linux guy" is pretty good on almost any Linux/Unix product (but will probably complain bitterly about Windows!), and that someone who's worked in Qt probably can handle analogous frameworks and products - but realize that driving down into tight detail here just isn't so valuable.
I'd go with shooting for 3 rows of technology/list of details pairs, unless you are so far along in your career that your massive breadth of technical knowledge is a cornerstone of your skill set. I'd aim for something more like:
Languages & Frameworks: C, C++, Qt
Development tools: GCC, GDB, Valgrind, SVN
OS: Linux (OpenSUSE)
Concepts:: UML, Design patterns, Socket programming, Data structures
I killed off Makefiles and Unit Testing. Makefiles because they are a standard part of how you use a C/C++ compiler, so I'd think if you were to claim you knew how to compile in GCC, you'd be claiming you knew how to build or edit makefiles. And Unit Testing because it's a standard part of many software development lifecycles and what I consider the basics for being a software developer - so too basic to be a standout on a resume. Data structures is a bit problematic as well - but I wasn't sure at what level we are talking about. If it's simply knowing the data structures that come up in a programming 101 class (array, list, tree, etc) and the various typical optimal uses for them and how to barebones create them and manipulate data within them, then skip it. If it's a deeper working knowledge of them and perhaps coupling that knowledge with Design Patterns, then include it.
Realize that often there's a story to be told on a resume. If the candidate, for example, didn't just do unit testing, and makefiles but in a personal project found an awesome and fascinating way of using the two together to bootstrap his own automated unit test suite that was initiated on every compilation using a sophisticated set of makefiles -- well, wohoo!, let's talk about it - but what matters here is not the raw skill, but the project - put it in as a personal project in the experience section with a single sentence on the cool part of this work using the relevant key words.
This is where it comes down to wanting to fit as many good things about the candidate as possible onto a page, while making sure you make the resume easy enough for a manager to read. The stuff you call out at the top can't just be a raw list for the sake of completeness, it should give the interviewer enough of a sense of the strengths of the candidate that the two can have a productive conversation.