Open letter to Maria Johnsen: please, be responsible!

Yesterday morning I was checking out my Twitter feed, when I encountered a rather disturbing one

You can read the whole article here  [1].

For those who don’t know who Maria Johnsen is, and are too busy to read the article: she’s a SEO expert who’s trying lately to promote herself as a cyber security expert.

Whether she’s a good or bad SEO expert is not up to me to say but, as a software developer with a deep interest in cybersecurity, who’s also following lots of researchers and malaware analysts, I felt the moral obligation to write something about it.

Even if I didn’t post anything in the past four years.

Even if I probably have now just one visitor/month  [2].

Why you may ask? Because, if I will manage to convince even one visitor to switch his/her website to SSL/TLS, I know I made the internet a better and safer place, even if just a bit 🙂

Open letter to Maria Johnsen

Dear Maria,

I saw this comment of yours in one of your latest posts


Now, despite what may or may not happened between you and Troy, let us all start to behave like adults, shall we? Thus..

Please stop spreading the misconception that SSL/TLS is not safe by posting links about SSL/TLS malaware attacks, because:

  1. you’re persuading your users that SSL/TLS is unsafe
  2. you’re demonstrating that you didn’t even read that article (which I kinda hope so, otherwise it would mean that you didn’t even understood it)
  3.  last, but not least, you’re making a fool of yourself to the people that have a bit of understanding in cybersecurity/software engineering

I couldn’t find the article you mentioned but, judging by the year (2015) and the topic (SSL/TLS), I’m pretty confident you were talking about the infamous Heartbleed bug in OpenSSL happened in 2014. Quoting from Wikipedia (emphasis mine)

Heartbleed is a security bug in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol […] TLS implementations other than OpenSSL, such as GnuTLS, Mozilla’s Network Security Services, and the Windows platform implementation of TLS, were not affected because the defect existed in the OpenSSL’s implementation of TLS rather than in the protocol itself.

in layman terms: the math behind SSL/TLS is, as of today, secure: it’s just how SSL/TLS was implemented in OpenSSL that had a flaw. And the proof is that other SSL/TLS libraries were unaffected by this bug (and as of today, there are 17 other libraries implements SSL/TLS).

Now, let’s move to the article that supposedly explains how SSL/TLS is unsafe: you got it completely, utterly wrong. And  I don’t even understand how’s that possible, since this paragraph explains it all:


in layman terms: (SSL/TLS) encryption is so good at its job of keeping user’s data confidential, that now even malaware authors are using it to hide their nefarious intents.

Does that mean that SSL/TLS is unsafe? Hell no.

Does that imply that websites using SSL/TLS are unsafe? Hell no.

SSL/TLS is merely a protocol to exchange data in a secure way. Period.

Websites and browsers use SSL/TLS to ensure nobody between the website and your browser (ISP providers, CDN providers, governments, your Company’s IT manager, etc…) can peek into your personal data.

But of course, being SSL/TLS just a protocol, nothing prevents you to write your own software that sends/accepts SSL traffic. Here’s an example. And of course, hackers decided to use it in order to hide the data their malawares exchange.

Does that mean that websites using SSL/TLS are 100% safe? Hell no, never trust anybody selling you the concept of absolute security while saying, few lines below, “governments websites have been hacked too” because indeed, websites can get hacked and, if that’s case, it’s game over for user’s privacy.

But the likelihood to have your privacy stolen is just much more higher if your website does not provide SSL/TLS, because anybody between you and the website can see what you’re doing and, even worse, can manipulate the data without the user, or the website owner,  even noticing that. Why? Because it’s not bloody encrypted! Is it that difficult to grasp? Example: some hotels injected custom advertisements in websites that weren’t SSL-enabled.

So, rather than spreading FUD about SSL/TLS insecurity please, be responsible and do the opposite: promote SSL/TLS anywhere, even if the websites don’t handle sensitive data; in this way you’re saying “nobody will easily read/tamper the data between the website and the user, insert custom content, or perform MiTM attacks”.

Best regards,



Perhaps Maria is good at SEO, judging by the number of followers she has on Facebook, but she also lacks of an understanding of security/privacy and, even worse, she’s not willing to admit it.

There’s no reason to favor non-secure websites against secured ones, and whoever is telling you otherwise, is exposing his/her clients and client’s user base to unnecessary threats.

Her lengthy, whining, childish, overreacting comments against Troy Hunt are a sign of something referred in psychology as Dunning–Kruger effect:

cognitive bias wherein persons of low ability suffer from illusory superiority, mistakenly assessing their cognitive ability as greater than it is. The cognitive bias of illusory superiority derives from the metacognitive inability of low-ability persons to recognize their own ineptitude.

Look ‘ma, I’m an expert.


1: It’s quite a funny reading: 50% of the post is not about SEO/security at all, but rather, she’s self-promoting her book, basically explaining how she knows better about search engines than Google’s, whose search algorithm is primitive 😀 .
2: after posting this article, I actually had a look at my stats and I have to say, after four years of inactivity, I’m impressed I still have visitors stopping by: apparently, my Latex thesis template and how to build an executable library are still interesting. 


Make your own executable shared library on Linux

Hello there, it’s been a long time since my last post 🙂

Since I’m on vacation, and kinda frustrated about my playbook experience, I decided to  statisfy something that always tickled my fancy about shared libraries.

As you may know, under GNU/Linux is it possible to make shared libraries also executable: prominent examples are libc and Qt libraries, as shown in the screenshot below.

libc and libQtCore output

libc and libQtCore output

Those libraries, when executed from the command line, print useful information about the library version itself, the compiler used, processor features, author, copyright and so on .

But how they achieved that? Libraries don’t have an entry point .. or they do?

LD manual to the rescue

Of course the answer is yes, they do .. sort of. If you look at the options you can issue to ld, you will notice that there is the following option:

-e entry

--entry=entry  Use entry as the explicit symbol for beginning execution of your program, rather than the default entry point. […]


So what you will actually do is to define a function, from whithin your library, that will be used as entry point when executed. From there, you can execute your arbitrary piece of code.

The Code

We will start by defining a sample library composed of just one class (I kept everything as simple as possible to improve readabilty), which will do nothing but print “hello lib!”  upon construction:

/* lib/mysamplelib.h */
namespace MySampleLib

class SampleLib


} // namespace MySampleLib

#endif // SAMPLELIB_H

/* lib/mysamplelib.cpp */
#include "samplelib.h"

namespace MySampleLib

    std::cout << "hello lib!" << std::endl;

} // namespace MySampleLib

Then, we will define our custom entry point function in a separate file: this will print “Hello from custom entry point lib!”.

/* lib/dump_function.cpp */


extern "C" void my_dump_function() {
    printf("Hello from custom entry point lib!\n");

We also need a very basic main.cpp file, which prints the usual “Hello World!” and then instantiate a SampleLib object:

/* main.cpp */

#include "lib/samplelib.h"

int main()
    std::cout << "Hello World!" << std::endl;
    SampleLib lib = SampleLib();
    return 0;

For completeness, I will also include the two CMakeLists.txt files used in the project.

/* CMakeLists.txt */
cmake_minimum_required(VERSION 2.8)



add_executable(${PROJECT_NAME} ${SRC_LIST})
target_link_libraries(${PROJECT_NAME} sampleLib)

/* lib/CMakeLists.txt */

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -e my_dump_function")

add_library(SampleLib SHARED ${LIB_SRC})

And now we can finally build and run our app and our library and see the results 🙂

First Attempt

First Attempt

Urg .. What’s going on here?

Compilation and linkage were successful, the executable ran perfectly, but executing the library directly produced a segfault.

The Fix

Let’s try to find out what’s wrong here. We will run readelf to see the if there are some parts in common between the executable, our library, and some other executable library – i.e. libc – . These are the output:

readelf exec

readelf exec

readelf libc

readelf libc

And now, our libSampleLib

readelf samplelib

readelf samplelib

Nice, now we have much more infos about the issue. As you can see the executable, libc, and our SampleLib, all have  an entry point defined. That means that ld processed our command option as we intended.

But, as opposed to the executable and libc, our SampleLib does not have an interpreter section defined. This is normally good when a library gets executed through a regular application, because every application has an interpreter defined. In our case anyway, that missing definition is the reason of our segfault.

So we need to tell the compiler to add an interpreter header. From a quick search on google, all you need is to add the following line inside dump_funcion.c (outside the function body of course)

extern const char elf_interpreter[] __attribute__((section(".interp"))) = "/lib64/";

Recompile all, and now …

Second Attempt

Second Attempt

Awesome, we did it!

But we are serious programmer, aren’t we? Hardcoding the interpreter absolute path is always a Bad Thing™; if you work in a team where everyone may potentially have different setup and machines, that’s even worse.

CMake to the rescue!

With a little help of CMake, we can automate the interpeter path retrival.

Firs we execute readelf on a command that is present in every linux distro, which is “ls” ; then, with a little cmake regexp magic, we extract the path, and finally add a new cmake definition whose value will be assigned to the elf_interpreter[] var inside dump_function.cpp .

The updated CMake file and main.cpp look now like this:

/* lib/CMakeLists.txt */
set(INTERPRETER_DESCRIPTION "Requesting program interpreter:")

execute_process(COMMAND readelf -l /bin/ls
    RESULT_VARIABLE return_value

    message(STATUS "Cannot find a valid ELF interpreter")
    string(REGEX REPLACE
        ".*[[]${INTERPRETER_DESCRIPTION} ([/][^ ].+)[]].*" "\\1"
        _ELF_INTERPRETER_PATH "${result}"

    message(STATUS "ELF interpreter is ${_ELF_INTERPRETER_PATH}")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -e my_dump_function")
add_library(SampleLib SHARED ${LIB_SRC})

/* lib/dump_function.cpp */
/* showing only the relevant line here, too lazy to copy everythin again! */
extern const char elf_interpreter[] __attribute__((section(".interp"))) = ELF_INTERPRETER_PATH;

That’s better 🙂

Further improvements and how to get the code

You can find an improved version of the code shown here on my gitorious repository . I made some modifications to make it prettier and more reusable, such as define a FindELFInterpreter script for that purpose, added a simple macro to retrieve the hash commit/current branch of your source tree (in this case, mine), and embed that info within my_dump_function(). I’ve also added some debug compiler options, and added to the dump function, just to show some other interesting output you may be interested in seeing. Pretty neat, isn’t it? 🙂

Last Attempt

Last Attempt

An other interesting thing to implement could be use cmake feature to create header files through its configure_file() command, and put all of those definitions inside it and include that file whenever you need it, but I leave this as an exercise to the reader, cheers 😉

Thesis Template for LaTeX

Since in my last blog post I was asked for the LaTeX template I was using for my thesis, I’ve cleaned it up a lot, re-ordered the packages inclusion and added some comments which will be useful for who will try it. Since WordPress kindly forbids uploading zipped files, I’ve set up a repository on .

For whose who have never heard about that website, you can click the following link , which will start the download of the zipped folder for you.

The folder will contain the latex source sample, along with a sample bibliography file, an image and a pdf file of that image used to show how to import them, and the final resulting pdf file,

which looks like this screenshot:

I hope you’ll find it useful 🙂

Graduated :)

Just a quick update to say “Hello Again” to everyone; I’ve just graduated in Control Systems so finally I’ve got enough free time to contribute back to KDE, so see you around 😀

For those who are interested a little bit on the subject of my thesis, it’s all about a bunch of graphs and lots of considerations regarding the implementation (and co-simulation) of the so called “Three-Loop Algorithm” for controlling the trajectory of a missile in two dimensions.

Oh, and loooooooooooooots of kudos to Kile’s developers, it’s been a pleasure to see how it improved after the last time I had the chance to use it 🙂

If you want to read more, you can download My Thesis … There’s also an Easter Egg, if you can spot it 😉

(Btw there are a couple of errors I’ve spotted after giving it at the registrar’s office, anyway they’re not that relevant)

Compile KDE from sources (currently 4.8.x) under (K)Ubuntu 12.04

[Update 16/06/2012] : Thanks to Blakpawn (see comments below), the soprano virtuoso backend now compiles again 🙂

As promised a long time ago, finally KDE has (almost) moved to git -kdemultimedia did it a couple of weeks ago- so I can finally write a comprehensive post about how to compile an almost full KDE installation from sources and setup it for your every day work/fun.

I highly recommend you to read all the post before starting with the process; I know it’s kind of tl;dr but I think that if it’s your first time on doing that, you should really have an idea about what you’re about to do. It’s for your own sake, after all 🙂

Also, since I cleaned up a lot the scripts I use, if you encounter some kind of error please let me know so I can fix it!

Ok, let’s start.


Let’s get straight on this: you’re gonna need a lot of space. About 8GB for the sources, plus 15GB for the build. But there’s even more; if you want to compile Qt too, which I do, you need extra 1.4GB for the sources which becomes 3.4GB after the build process (but of course you will “make distclean” it before compiling KDE to save a couple of GB ).

But that’s for the folder where your Qt an KDE sources+build files reside; the partition where you’re going to install all the system files will need about 7GB of free space (again, plus 900MB if you plan to compile and install Qt).

You also need time, so don’t try this guide if you are strict with some sort of deadline of yours. Depending on your computer, KDE compile process alone takes about 10 hours (Qt ~40 min), so take an afternoon/evening free (and let your computer do the looong compile process during the night).

Oh right, Kubuntu 12.04 (or other Ubuntu based distro) is needed of course 😉

Erase every other DE?

Common sense would suggest to keep a stable desktop environment for rescue, if someday something goes terribly wrong and you can run nothing but a terminal console. However, from my personal experience (almost 3 years running KDE self-compiled), I’ve never witnessed any serious crash. Sometimes the build may fail due to XY component requiring a new version of a ZY library, but that’s all. Moral of the story: if you don’t feel comfortable with fixing a possible broken setup from the console (aka grep’ing the build log looking for errors, use vim/nano, lynx if needed etc …) then just play safe and keep your default DE 😉

Brief intro about the steps we are going to walk

There’s nothing hard or difficult with compiling and setting up kde. In fact, the steps are the following:

  • download the compiler + all the required libraries;
  • download Qt sources (optional);
  • download source libraries depending directly on Qt (you don’t need those if you keep Qt version shipped with your distro);
  • download KDE sources;
  • remove your old DE (optional);
  • compile Qt + the libraries directly depending on it (again, you don’t need this if you keep Qt version shipped with your distro);
  • compile KDE sources;
  • finishing touches to make your freshly installed KDE fully functional;
  • compile extra software which depends on Qt, like VLC (again, needed only if you compile Qt);
  • extra task for the brave ones only 😉

Ready? Go!

Step 0: downloading compiler and required libraries

Tha’s really simple: copy and paste this long command in your terminal, and then wait until everything has been downloaded and installed:

sudo apt-get install build-essential libcv-dev libopencv-dev libcvaux-dev libopencv-gpu-dev libwayland-dev libhighgui-dev libjpeg-dev cdbs debhelper cmake git-all bzr libstdc++6-4.7-dev libxml2-dev libxslt1-dev libtinyxml-dev libwpg-dev libbz2-dev shared-mime-info dbus-x11 libxkbfile-dev libgl1-mesa-dev libglu1-mesa-dev mesa-common-dev libxext-dev libical-dev libpng12-dev subversion libsm-dev libxinerama-dev libtiff4-dev libxrender-dev libfontconfig1-dev libboost-all-dev libxcursor-dev doxygen libgif-dev libdbus-1-dev libssl-dev libgpgme11-dev libasound2-dev kdesdk-scripts libpth-dev libjasper-dev ssh libglib2.0-dev libpcre3-dev diffstat libexpat-ocaml-dev libclucene-dev libclucene0ldbl libexiv2-dev quilt libspectre-dev xsltproc libxtst-dev libxdamage-dev libxcomposite-dev libaspell-dev libenchant-dev libsmbclient-dev libopenexr-dev libraw1394-dev libpulse-dev libpci-dev libusb-dev libnm-glib-dev libnm-glib-vpn-dev libnm-util-dev network-manager-dev libgphoto2-2-dev libeet-dev gstreamer0.10-plugins-base libcppunit-dev libgstreamer-plugins-base0.10-dev libssh2-1-dev libiw-dev libxss-dev libslp-dev lm-sensors bluez libbluetooth-dev libgps-dev libxklavier-dev libsasl2-dev acl flex bison libck-connector-dev libmono-2.0-dev libsensors4-dev libxrandr-dev lzma-dev libssh-dev libxft-dev libosip2-dev libeigen2-dev libdvdread-dev libmusicbrainz3-dev libmusicbrainz4-dev libflac-dev libflac++-dev libsndfile-dev libsamplerate-dev libogg-dev libmpcdec-dev libmad0-dev libmp3lame-dev libavbin-dev libavcodec-dev libswscale-dev libcdparanoia-dev mysql-server libmysqlclient-dev libmysqld-dev libtidy-dev libimlib2-dev libnl-dev libexempi-dev libv4l-dev xscreensaver libcfitsio3-dev libindi-dev xplanet libsane-dev libxxf86vm1 libchm-dev libdjvulibre-dev libepub-dev libacl1-dev libvncserver-dev libortp-dev libspeex-dev libotr2-dev libmsn-dev libmediastreamer-dev libmeanwhile-dev libgadu-dev libpilotobjects-dev libhunspell-dev libsvn-dev libarchive-dev libfftw3-dev libtheora0 libvorbisenc2 libxine-dev libxine-xvdr libmtp-dev  libloudmouth1-dev libxine1-ffmpeg libgpod-nogtk-dev libaudio-dev liblcms1-dev libmng-dev libsqlite0 libsqlite0-dev libxmu-dev libgpod4-nogtk libpam0g-dev libffi-dev python-dev libgamin0 libgamin-dev libsearchclient-dev libraptor1-dev librdf0-dev libudev-dev libimlib2-dev liblzma-dev libdmtx-dev libqalculate-dev ruby-dev ruby libreadline-dev libindi-dev libfacile-ocaml-dev libopenbabel-dev libgsl0-dev libopenal-dev libmusicbrainz4-dev libantlr-dev virtuoso-opensource-6.1 virtuoso-opensource-6.1-bin virtuoso-opensource-6.1-common libxvmc-dev libgtk2.0-dev libgtk-3-dev docbook-xsl libxvmc-dev shared-desktop-ontologies libpolkit-agent-1-dev libpolkit-backend-1-dev libpolkit-gobject-1-dev libwrap0-dev libassuan-dev dblatex telepathy-core telepathy-devel telepathy-mission-control-5 libmission-control-plugins-dev libopenjpeg-dev libcanberra-dev libmusicbrainz3-dev libavformat-dev libhighgui-dev libcvaux-dev libzeitgeist-dev libqrencode-dev libglew1.6-dev libgsf-1-114 libgsf-1-common libgsf-1-dev liblcms2-dev libpqxx3-dev libspnav-dev libspnav0 libwpd-dev libwpg-dev libxbase2.0-0 libxbase2.0-dev libwpg-tools libopenvg1-mesa-dev gtk-doc-tools mono-mcs mono-dmcs mono-gmcs

Step 1: downloading Qt sources + libs depending directly on it

Create a folder where put all the sources you’re going to download, i.e. “src” in your Home folder. Open a terminal and type:

$cd ~/src
$ git clone git://

And then, the other libs you need (cd ~/src is omitted to save some space) :

$ git clone git://
$ bzr branch lp:libdbusmenu-qt
$ git clone git://
$ git clone git://

$ git clone

Note: if you don’t build Qt, instead of downloading the sources, just run sudo apt-get install libqjson-dev  and so on (your package manager will help you for the correct lib names 😉 ).

Step 2: downloading KDE sources

Download the kdesrc-build utility from here: and then unpack it inside ~/src ; install the kdesrc-build executable in /usr/local/bin/ , and save my configuration script in your home dir (remove the .doc extension, thanks for the media upload restrictions <.<). kdesrc-build is a very complex and well made script that eases a lot your life: based on the config file options, he’s able to download entire modules source from the kde git repository, update/build/install them without any interaction. I strongly recommend you to open it and have a look to the options available (and adjust the paths too).

In fact, now you just have to type in your console

$kdesrc-build –no-build

And wait until all the sources gets downloaded inside ~/src. If, for any reason, some module fails being downloaded, don’t panic! Just cd to the folder where that module should be downloaded and then issue a “git clone git://” command 🙂

[Fix to build libsoprano_virtuosobackend] : use the following patch -> ; save it as patch.patch inside your kdesrc/soprano folder.

Then, simply type

$cd kdesrc/soprano

$git apply patch.patch

and you’re done 🙂

Step 2: remove your old DE

You don’t need to perform this step if you planned to keep a rescue DE, so feel free to jump directly to Step 4.

Otherwise,  hit CTRL+ALT+F1 to switch to tty1. From this point, we are gonna use only the terminal. Again, I highly suggest you to read the whole post before actually erasing your DE; if you encounter some lengthy commands and you’re afraid to forget some of them, it’s the last chance you have to copy/paste it inside a text file, and rename it i.e. as step$ .  In this way, from the console, a simple “sudo sh step$” will execute all the tedious command for you.

Assuming you have KDE, get rid of it is fairly simple:

$sudo apt-get remove kde-icons-oxygen libqt* libpoppler* poppler-utils libqca2 libqimageblitz4 libsoprano4 libstreamanalyzer0 libstreams0 kdebase-* kdegraphics* kdelibs5-data amarok-common kate-data kde-baseapps-data kde-runtime-data kde-workspace-data kdegames-card-data ksysguardd libakonadi-kabc4 libkipi-data libkonq5-templates language-pack-kde-en oxygen-icon-theme-complete oxygen-cursor-theme

If you have Gnome, I’m sorry but you have to figure it out on your own. I tried once to do that (when Canonical decided to drop the sponsorhip of Kubuntu, I started installing Ubuntu to get familiar with which packages I have to remove), but I failed miserably.. Every time I did an apt-get update, some gnome-related-crap was still installed on my computer, so that’s up to you (and if you successfully do that, drop a comment here so I can update this section 😉 ).

Step 3: compile Qt + libraries depending on it

From the terminal, cd to the folder containing the Qt sources. Qt automatically sets the branch with the current release (at the moment it’s 4.8) so you don’t need to do anything but configuring the sources with the following parameters (assuming to install the libraries in /opt/qt4 ):

./configure -debug -fast -no-separate-debug-info \
-system-libpng -system-libjpeg -system-zlib \
-dbus -webkit -no-phonon -plugin-sql-mysql \
-gtkstyle -developer-build -opensource\
-declarative -script -scripttools \
-reduce-relocations -no-exceptions\
-nomake examples -nomake demos -prefix /opt/qt4 -v

Answer “yes”, and wait ~6 minutes until the configure process gets executed. Then, type “make” and leave your computer compile for about 40 minutes; if everything went right, type

$sudo make install && make distclean

to install the libraries and cleanup the source dir. Before compiling and installing everything else, it’s better to update few environment variables to expose Qt and the various libs we are going compile and install. Type the following lines (again, assume Qt installed under /opt/qt4 and kde installed -not yet- under /opt/kde4) :

export QTDIR=/opt/qt4
export KDEDIR=/opt/kde4
export KDEHOME=$HOME/.kde4
export PKG_CONFIG_PATH=$QTDIR/lib/pkgconfig:$KDEDIR/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/lib:$QTDIR/lib:$KDEDIR/lib:/usr/local/lib:$LD_LIBRARY_PATH
export PATH=/opt/bin:$QTDIR/bin:$KDEDIR/bin:/usr/local/bin:$PATH
export CMAKE_MODULE_PATH=$KDEDIR/share/apps/cmake/modules:$CMAKE_MODULE_PATH
export XDG_DATA_DIRS=$KDEDIR/share:/usr/local/share:/usr/share:$XDG_DATA_DIRS
export MAKEFLAGS=-j6 # instead of “6”, put your number of cpu cores+2 here

Now it’s time to compile the other libraries:

  • cd to QJson source directory, and then type: mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=$KDEDIR .. && sudo make install && rm -rf ../build
  • cd to libdbusmenu-qt source dir, and type again: mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=$KDEDIR .. && sudo make install && rm -rf ../build
  • cd to poppler source dir and point to the last stable tag if you want (i.e. “git checkout poppler-0.19.3″) ; then, type: mkdir build && cd build && ../configure –prefix=$KDEDIR && make && sudo make install && rm -rf ../build 
  • cd to telepathy-qt4 dir and again,  point to the last stable tag if you want (as for poppler, I’ve always compiled from master branch) then type: mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=$KDEDIR .. && sudo make install && rm -rf ../build
  • and now, go to liblastfm dir, point to the last stable tag if you want, and type ./configure –prefix $KDEDIR && make && sudo make install && make distclean

Step 4: compile KDE (!)

This is the simplest step of all the entire post: write this

$sudo kdesrc-build –no-src

hit enter, and go to sleep 🙂

Note: you may have noticed that kdesrc-build can download and build/install the modules in one go; however I keep this two steps decoupled for a couple of reasons:

  • i’d like to update first all the sources before going to sleep and keep my laptop disconnected from the internet during the night (many friends of mine got they console/tv/pc video card burned by a thunder  when they were sleeping/away sooooo let’s try to minimize the risk);
  • for the reason above, you can have quickly notice if some module has been moved/renamed (happened a LOT of times within kde telepathy projects);
  • there is no valid reason to update a module using root privileges at all.

Step 5: compile KDE (!)

“Are you fucking kidding me?” you might say.. Due to an unfortunate circular dependency, the answer is no. Don’t get me wrong: it’s nothing that will block you from loading kde (it’s just polkit-kde-kcmmodules that didn’t compiled because it requires kde-workspace, but kde-workspace in turn requires –optionally– polkit, so everything works fine except that) and gets automatically fixed the second time you rebuild kde,so if you want, you can start use kde right now: it’s just me being nitpick about the need to have everything compiled before going further 😛

To be completely sure about that, type that command:

$sudo kdesrc-build –no-src polkit-kde-kcmodules-1 kdelibs kde-workspace

and wait for finished.

Step 6: finishing touches

Now it’s time to tell the system how to load your self-compiled kde environment. First of all, inform X11 to use kdm:

$sudo nano /etc/X11/default-display-manager

and change the line from /bin/kdm to /opt/kde4/bin/kdm . Then, open kdm.conf file:

$sudo nano /etc/init/kdm.conf

and again, replace all the occurrences of /bin/kdm with /opt/kde4/bin/kdm . At this point, X11 knows how to launch kdm, but kdm itself doesn’t know anything yet about what to do when an user logs in. To fix that, create a kde4.desktop file wherever you want, and put the following lines:

[Desktop Entry]
Name=KDE 4.9 (from trunk)

Save it, copy it into /opt/kde4/share/apps/kdm/sessions/ and give rx permissions. Now kdm knows that it has to execute the script called, when the option “KDE 4.9 (from trunk)” is selected: let’s create it, and add these two lines


Save it, copy it into /opt/kde4/bin/ and give rx permissions. Ok, a script which calls an other script, whoooo! (Reason: Exec and TryExcec lines doesn’t allow run multiple commands, so we have to fake it. If you don’t plan to use ssh, just skip the previous script creation and modify the .desktop file accordingly) is more simple to create:

$sudo cp /opt/kde4/bin/startkde /opt/kde4/bin/

But why do we do that? Because inside we are going to add some extra definitions to run kde properly; if we would add them in kdestart script instead, that file will be overwritten the next time you rebuild kde, losing our definitions. The lines you have to add, right after the comments at the very beginning of the file, are the bunch of exports you’ve already seen in Step 3. The beginning of after that modification will look like this:

# DEFAULT KDE STARTUP SCRIPT ( 4.8.3 (4.8.3) )

export QTDIR=/opt/qt4
export KDEDIR=/opt/kde4
export KDEHOME=$HOME/.kde4
export PKG_CONFIG_PATH=$QTDIR/lib/pkgconfig:$KDEDIR/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/lib:$QTDIR/lib:$KDEDIR/lib:/usr/local/lib:$LD_LIBRARY_PATH
export PATH=/opt/bin:$QTDIR/bin:$KDEDIR/bin:/usr/local/bin:$PATH
export CMAKE_MODULE_PATH=$KDEDIR/share/apps/cmake/modules:$CMAKE_MODULE_PATH
export XDG_DATA_DIRS=$KDEDIR/share:/usr/local/share:/usr/share:$XDG_DATA_DIRS

Good, now we are almost finished. In fact, due to DBus and polkit strictness, you need to copy some files from $KDEDIR to /usr to get everything work fine (aka dialog requiring root password). Let’s fix these last details!

$sudo cp /opt/kde/share/polkit-1/actions/* /usr/share/polkit-1/actions/
$sudo cp /opt/kde4/share/dbus-1/interfaces/* /usr/share/dbus-1/interfaces/
$sudo cp /opt/kde4/share/dbus-1/services/* /usr/share/dbus-1/services/
$sudo cp /opt/kde4/share/dbus-1/system-services/* /usr/share/dbus-1/system-services/

Extra: if you want to configure kde to detect and interact with grub2/burg, you may be interested in reading the developer’s blog. It has a very descriptive tutorial!

Now everything is working: reboot and enjoy kde!

Tadaaa! KTelepathy, dialog for root privileges working :)

Tadaaa! KTelepathy, dialog for root privileges working 🙂
For whose who noticed the “strange” look of the battery applet … yeah, it’s the new Qml version landed about a week ago in master branch 😉

Extra: compile and install VLC

Compiling VLC is really easy; as always, download its dependencies

$sudo apt-get install libavformat-dev libavutil-dev libpostproc-dev liba52-0.7.4-dev libxcb-shm0-dev libxcb-xv0-dev libx11-xcb-dev libsdl1.2-dev libfribidi-dev libmatroska-dev libfaad-dev libtwolame-dev libdca-dev  libmpeg2-4-dev  libtheora-dev libx264-dev libxpm-dev libdca-dev libmpeg2-4-dev libtheora-dev libx264-dev libmpeg2-4-dev libdca-dev libtheora-dev libx264-dev libsdl-image1.2-dev libcddb2 libcddb2-dev libconfig++8 libdirac-decoder0 libdirac-dev libdirac-encoder0 libdvbpsi-dev libffado-dev libffado2 libfluidsynth-dev libfluidsynth1 libjack-dev libjack0 libmodplug-dev liborc-0.4-dev libportaudio-dev libportaudio0 librsvg2-dev libschroedinger-dev libshout3-dev libtar libtar-dev libupnp-dev libupnp3 libupnp3-dev libxml++2.6-2 libzvbi-common libzvbi-dev libzvbi0 libxpm-dev libvdpau-dev libva-dev x11proto-xf86dri-dev x11proto-dri2-dev liblivemedia-dev libdc1394-22-dev libavc1394-dev libportaudio-dev libprojectm-dev libxcb-keysyms1-dev libxcb-composite0-dev libncursesw5-dev

Then download the latest stable tarball from their website, exctract its content and move inside that directory. Type

$mkdir build && cd build && ../configure –enable-libva –enable-xvideo –enable-sdl –enable-avcodec –enable-avformat –enable-swscale –enable-mad –enable-a52 –enable-libmpeg2 –enable-dvdnav –enable-faad –enable-vorbis –enable-ogg –enable-theora –enable-mkv –enable-freetype –enable-fribidi –enable-speex –disable-flac –disable-taglib –enable-live555 –enable-caca –enable-skins2 –enable-alsa –enable-qt4 –enable-ncurses –enable-realrtsp –enable-twolame –enable-real –enable-mozilla –with-mozilla-pkg=xulrunner-plugin –enable-x264 –disable-lua –disable-mozilla –prefix=/opt && make && sudo make install && rm -rf ../build

and create some symbolic link to make it work

$sudo ln -s /opt/lib/libvlc* /usr/lib/
$sudo ln -s /usr/local/lib/libx264.a /usr/lib/
$sudo ln -s /opt/lib/vlc /usr/lib/vlc

Oh, and if you prefer QtCreator over KDevelop, building it is very simple:

$git clone git://
$cd qt-creator && qmake && make && sudo make install && make distclean

That’s all 🙂

Here you go, QtCreator and VLC successfully compiled

Here you go, QtCreator and VLC successfully compiled

Only the brave: Build KDE .. with gcc-snapshot toolchain 😛

To download it, you need to add the corresponding ppa:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test && sudo apt-get update && sudo apt-get install gcc-snapshot

and then make it the default one with the following commands:

sudo update-alternatives –install /usr/bin/gcc gcc /usr/lib/gcc-snapshot/bin/gcc 40
sudo update-alternatives –install /usr/bin/g++ g++ /usr/lib/gcc-snapshot/bin/g++ 40
sudo update-alternatives –config gcc
sudo update-alternatives –config g++

and select from the menu the gcc-snapshot version 😉

Aaand here it is one screenshot from my Devel activity, with some tweaks like using Oxygen Fonts, better (imho) tab style, a less intrusive “current window” shadow.

My KDE Workspace (Devel Activity)

My KDE Workspace (Devel Activity)

Merry Christmas, and a PlasMate surprise for you :) [screencast]

Hello planet,
It’s been a looong time since my last post here. As I wasn’t selected for attending the GSoC this year, I focused myself mostly on passing my last few exams, and finding a teacher for the thesis I’m currently doing.
But, as PlasMate mantainer (along with sebas), I always felt completely unstatisfied about the current codebase and I couldn’t stop thinking about the improvements I had to do1.

Thanks to Giorgios,  who took the responsibilty for keeping the bug count low and implemented a lot of cool features too, I was able to use my little spare time to think about how improve PlasMate codebase.

I started with implementing a small core library which basically:

  • loads a series of language definitions (no more hardcoded values for each language);
  • performs a scan of the plasmate projects dir;
  • loads the projects and reads their specific project settings.

Then, I started implementing a simple plugin structure to make PlasMate more flexible without the risk of  letting the code grow with no  control. The current supported plugins are:

  • DockWidget (surprise! 😛 ) – widgets that can be placed in a QDockWidget, but also in an overlay or in a special “pinnable widget” (yet to be implemented). The File Browser, TimeLine and Previewer in the video all belongs to this type (coming soon: a console to collect the applet output);
  • EditorCreator (blah, i have to rename it to EditorFactory): creates and Editor for the given file, based on its type; for now we have a kate editor and the metadata editor available (coming soon: QtDesigner editor);
  • WebServices – allows PlasMate to interact with online services such as OCS, OwnCloud and others (none done yet, I’m porting the OCS one however).

At this point I’ve also implemented a configuration manager to write plasmate-wide settings,project-specific settings and also plugin-specific settings, so there is just one centralized place which takes care of this kind of stuff 🙂

The library bits and the UI are working quite ok, I can load the old projects and save the project-specific settings, open the source files/edit/preview the changes, but there is still a lot of work to do. The code is hiiiiighly unstable and lives only on my hard drive for now: as soon as I get something more stable, I’ll publish it 🙂

In the meantime, enjoy this video teaser 😛

Or, you can download the video in HQ and watch it later.

And Merry Christmas to all of you!


1: To Igor and the other people I told I was busy with a secret project.. yeah, it’s this one 🙂 When I started developing the kmix applet replacement, I started having the concrete feeling that PlasMate was too much difficult to adapt to my workflow (i.e. no tabs to switch from a source to an other, the problems with the previewer size..) so I finally decided to start its modularization immediately 🙂

Yep, I’m alive && rants

Since my blog is still being visited by ~15 people each day despite I’m not posting anything new in 7 months (oh my god), I think it’s a good idea to give a small update about what I’m doing, and why I haven’t blogged that much lately.
This summmer I wasn’t selected to partecipate to the GSoC event, so I’ve used all this free time to dive into my remaining University subjects, I made a lot of exams and now there are only two to go 🙂

I’ve even started my thesis project, but this is kinda a sad point (and the reason of the && rants stuff)..
I cannot reveal the details, but basically I’m working on a spinoff project made by my Supervisor, and one of my task regards writing a parser for a given file format.

“Where’s the problem, since a parser it’s simple to implement”, you may ask?
Writing a parser for the file format they gave me would be fairly simple, if I could start it from the ground. Unfortunately I cannot, because I have to derive it from an abstract class made my Supervisor, and because other parsers for others file formats already derive from this base class (and I dont want to refactor them, see below why).
This class is written in Java, but basically fails on every concept of object-oriented programming such as:

  • information hiding: this abstract base class has every members declared with a public keyword (plus two public abstract metohds meant to be implemented in the subclasses in order to do the actual parse process)1;
  • design pattern: you would expect some kind of mix between a Strategy/Visitor patter, but the other file format parsers are made of just a single class (derived from the infamous abstract one), with a huuuuuge while(true) loop where all the parsing takes place, and so I have to do the same;

If this is not enough for you, there’s even more!
The global app has to be efficient and fast(why using java, then?), so the Supervisor had the brilliant idea to design the parser in order to convert the various file formats in his brand-new, intermediate, completely undocumented2 file format, and write it back to disk instead to put it in the ram for a faster access:\
Kinda scary, isn’t it?

However there are some projects of mine which pulls me away from the ragged edge of insanity, and my next post (I hope to write it in the next month) will be about one of them 😉
Sorry for my rant, cheers!

1: lol why not using a plain C struct then?
2: how I can tell it’s undocumented? simple, when I asked for the specs of this “file format”, I was told to look at the exsting parsers and do something similar “by inspection”