Linux puts you in full control. This is not always seen from everyone’s perspective, but a power user loves to be in control. I’m going to show you a basic trick that lets you heavily influence the behavior of most applications, which is not only fun, but also, at times, useful.

A motivational example

Let us begin with a simple example. Fun first, science later.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(){
  srand(time(NULL));
  int i = 10;
  while(i--) printf("%d\n",rand()%100);
  return 0;
}

Simple enough, I believe. I compiled it with no special flags, just

gcc random_num.c -o random_num

I hope the resulting output is obvious – ten randomly selected numbers 0-99, hopefully different each time you run this program.

Now let’s pretend we don’t really have the source of this executable. Either delete the source file, or move it somewhere – we won’t need it. We will significantly modify this programs behavior, yet without touching it’s source code nor recompiling it.

For this, lets create another simple C file:

int rand(){
    return 42; //the most random number in the universe
}

We’ll compile it into a shared library.

gcc -shared -fPIC unrandom.c -o unrandom.so

So what we have now is an application that outputs some random data, and a custom library, which implements the rand() function as a constant value of 42.  Now… just run random_num this way, and watch the result:

LD_PRELOAD=$PWD/unrandom.so ./random_nums

If you are lazy and did not do it yourself (and somehow fail to guess what might have happened), I’ll let you know – the output consists of ten 42′s.

This may be even more impressive it you first:

export LD_PRELOAD=$PWD/unrandom.so

and then run the program normally. An unchanged app run in an apparently usual manner seems to be affected by what we did in our tiny library…

Wait, what? What did just happen?

Yup, you are right, our program failed to generate random numbers, because it did not use the “real” rand(), but the one we provided – which returns 42 every time.

But we *told* it to use the real one. We programmed it to use the real one. Besides, at the time we created that program, the fake rand() did not even exist!

This is not entirely true. We did not choose which rand() we want our program to use. We told it just to use rand().

When our program is started, certain libraries (that provide functionality needed by the program) are loaded. We can learn which are these using ldd:

$ ldd random_nums
linux-vdso.so.1 => (0x00007fff4bdfe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f48c03ec000)
/lib64/ld-linux-x86-64.so.2 (0x00007f48c07e3000)

What you see as the output is the list of libs that are needed by random_nums. This list is built into the executable, and is determined compile time. The exact output might slightly differ on your machine, but a libc.so must be there – this is the file which provides core C functionality. That includes the “real” rand().

We can have a peek at what functions does libc provide. I used the following to get a full list:

nm -D /lib/libc.so.6

The nm command lists symbols found in a binary file. The -D flag tells it to look for dynamic symbols, which makes sense, as libc.so.6 is a dynamic library. The output is very long, but it indeed lists rand() among many other standard functions.

Now what happens when we set up the environmental variable LD_PRELOAD? This variable forces some libraries to be loaded for a program. In our case, it loads unrandom.so for random_num, even though the program itself does not ask for it. The following command may be interesting:

$ LD_PRELOAD=$PWD/unrandom.so ldd random_nums
linux-vdso.so.1 =>  (0x00007fff369dc000)
/some/path/to/unrandom.so (0x00007f262b439000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f262b044000)
/lib64/ld-linux-x86-64.so.2 (0x00007f262b63d000)

Note that it lists our custom library. And indeed this is the reason why it’s code get’s executed: random_num calls rand(), but if unrandom.so is loaded it is our library that provides implementation for rand(). Neat, isn’t it?

Being transparent

This is not enough. I’d like to be able to inject some code into an application in a similar manner, but in such way that it will be able to function normally. It’s clear if we implemented open() with a simple “return 0;“, the application we would like to hack should malfunction. The point is to be transparent, and to actually call the original open:

int open(const char *pathname, int flags){
  /* Some evil injected code goes here. */
  return open(pathname,flags); // Here we call the "real" open function, that is provided to us by libc.so
}

Hm. Not really. This won’t call the “original” open(…). Obviously, this is an endless recursive call.

How do we access the “real” open function? It is needed to use the programming interface to the dynamic linker. It’s simpler than it sounds. Have a look at this complete example, and then I’ll explain what happens there:

#define _GNU_SOURCE
#include <dlfcn.h>

typedef int (*orig_open_f_type)(const char *pathname, int flags);

int open(const char *pathname, int flags, ...)
{
    /* Some evil injected code goes here. */

    orig_open_f_type orig_open;
    orig_open = (orig_open_f_type)dlsym(RTLD_NEXT,"open");
    return orig_open(pathname,flags);
}

The dlfcn.h is needed for dlsym function we use later. That strange #define directive instructs the compiler to enable some non-standard stuff, we need it to enable RTLD_NEXT in dlfcn.h. That typedef is just creating an alias to a complicated pointer-to-function type, with arguments just as the original open – the alias name is orig_open_f_type, which we’ll use later.

The body of our custom open(…) consists of some custom code. The last part of it creates a new function pointer orig_open which will point to the original open(…) function. In order to get the address of that function, we ask dlsym to find for us the next “open” function on dynamic libraries stack. Finally, we call that function (passing the same arguments as were passed to our fake “open”), and return it’s return value as ours.

As the “evil injected code” I simply used:

printf("The victim used open(...) to access '%s'!!!\n",pathname); //remember to include stdio.h!

To compile it, I needed to slightly adjust compiler flags:

gcc -shared -fPIC  inspect_open.c -o inspect_open.so -ldl

I had to append -ldl, so that this shared library is linked to libdl, which provides the dlsym function. (Nah, I am not going to create a fake version of dlsym, though this might be fun.)

So what do I have in result? A shared library, which implements the open(…) function so that it behaves exactly as the real open(…)… except it has a side effect of printfing the file path :-)

If you are not convinced this is a powerful trick, it’s the time you tried the following:

LD_PRELOAD=$PWD/inspect_open.so gnome-calculator

I encourage you to see the result yourself, but basically it lists every file this application accesses. In real time.

I believe it’s not that hard to imagine why this might be useful for debugging or investigating unknown applications. Please note, however, that this particular trick is not quite complete, because open() is not the only function that opens files… For example, there is also open64() in the standard library, and for full investigation you would need to create a fake one too.

Possible uses

If you are still with me and enjoyed the above, let me suggest a bunch of ideas of what can be achieved using this trick. Keep in mind that you can do all the above without to source of the affected app!

1. Gain root privileges. Not really, don’t even bother, you won’t bypass any security this way. (A quick explanation for pros: no libraries will be preloaded this way if ruid != euid)
2. Cheat games: Unrandomize. This is what I did in the first example. For a fully working case you would need also to implement a custom random(), rand_r(), random_r(). Also some apps may be reading from /dev/urandom or so, you might redirect them to /dev/null by running the original open() with a modified file path. Furthermore, some apps may have their own random number generation algorithm, there is little you can do about that (unless: point 10 below). But this looks like an easy exercise for beginners.
3. Cheat games: Bullet time. Implement all standard time-related functions pretend the time flows two times slower. Or ten times slower. If you correctly calculate new values for time measurement, timed sleep functions, and others, the affected application will believe the time runs slower (or faster, if you wish), and you can experience awesome bullet-time action.
   Or go even one step further and let your shared library also be a DBus client, so that you can communicate with it real time. Bind some shortcuts to custom commands, and with some additional calculations in your fake timing functions you will be able to enable&disable the slow-mo or fast-forward anytime you wish.
4. Investigate apps: List accessed files. That’s what my second example does, but this could be also pushed further, by recording and monitoring all app’s file I/O.
5. Investigate apps: Monitor internet access. You might do this with Wireshark or similar software, but with this trick you could actually gain control of what an app sends over the web, and not just look, but also affect the exchanged data. Lots of possibilities here, from detecting spyware, to cheating in multiplayer games, or analyzing & reverse-engineering protocols of closed-source applications.
6. Investigate apps: Inspect GTK structures. Why just limit ourselves to standard library? Let’s inject code in all GTK calls, so that we can learn what widgets does an app use, and how are they structured. This might be then rendered either to an image or even to a gtkbuilder file! Super useful if you want to learn how does some app manage its interface!
7. Sandbox unsafe applications. If you don’t trust some app and are afraid that it may wish to rm -rf / or do some other unwanted file activities, you might potentially redirect all it’s file IO to e.g. /tmp by appropriately modifying the arguments it passes to all file-related functions (not just open, but also e.g. removing directories etc.). It’s more difficult trick that a chroot, but it gives you more control. It would be only as safe as complete your “wrapper” was, and unless you really know what you’re doing, don’t actually run any malicious software this way.
8. Implement features. zlibc is an actual library which is run this precise way; it uncompresses files on the go as they are accessed, so that any application can work on compressed data without even realizing it.
9. Fix bugs. Another real-life example: some time ago (I am not sure this is still the case) Skype – which is closed-source – had problems capturing video from some certain webcams. Because the source could not be modified as Skype is not free software, this was fixed by preloading a library that would correct these problems with video.
10. Manually access application’s own memory. Do note that you can access all app data this way. This may be not impressive if you are familiar with software like CheatEngine/scanmem/GameConqueror, but they all require root privileges to work. LD_PRELOAD does not. In fact, with a number of clever tricks your injected code might access all app memory, because, in fact, it gets executed by that application itself. You might modify everything this application can. You can probably imagine this allows a lot of low-level hacks… but I’ll post an article about it another time.

These are only the ideas I came up with. I bet you can find some too, if you do – share them by commenting!

Prerequisites

Note: e4rat will work only on HDD drives. If you installed your system on a SSD drive, it won’t make any chance. (I will explain this later on, but you may be already uninterested in this article). In case of SSD drives, ureadahead, which is installed with Ubuntu by default, already does it’s best to improve the boot time. Physical HDD drives however, can benefit a lot from e4rat.

Note 2: You need to have your system installed on a ext4 partition in order to use e4rat (which is default in most cases). Furthermore, a kernel not older than 2.6.31 is required. No worries – Ubuntu ships with a suitable kernel since 10.04! Also, e4rat is confirmed to work great with all Ubuntu releases since 11.04 Natty Narwhal.

How does it work?

First, let’s think why does your machine take so much time to boot up. Investigating the boot process, one can learn that if you use a physical HDD drive, most time during startup is spent waiting for your drive to access data (if you wish to investigate it on your own, bootchart is the utility that will help you). This makes a lot of sense, it needs to accelerate the plates, spin them as needed, move other mechanical parts to read information… Because there is lots of physical movement related, the time needed to read a file gets longer. And there can be thousands of files that are required on boot! Things are even worse: if the files are located throughout the whole disk space, much much more seeking for files has to be done (This also explains why the drive can be very noisy on startup!). Luckily, there is no (or almost none) file fragmentation on ext4 filesystems, so at least once the file is found, reading it requires not that much mechanisms movement. But “moving to files” is enough to make your boot take a long time.

First observation that has to be done, is that every time you bootup your system almost the same files are required. This is kind of intuitive, starting Ubuntu on the same machine should require similar stuff every time. What if we could found out what these files are, and somehow move them on the drive close to each other, so that accessing them requires less there-and-back drive movement? Yeah… so this is basically what e4rat does for you.

First, we’ll let e4rat inspect your boot-up, so that it can learn which files are needed to start your system. Then, we’ll use it’s file reallocation tool to move these files in a pattern as optimal as possible. Finally, we’ll let it start before your Ubuntu boots – it will load all the required files at once to RAM (which should take much much less time, because they will be read as a large block of concatenated data), and Ubuntu will continue the boot using the data in RAM – which, because RAM is insanely fast, in case of my Ubuntu 12.04 on ASUS 1225c, takes a total of 2 seconds. Therefore, the boot process should be significantly faster.

Pleas note, that you should re-do this process every time you upgrade your Ubuntu to a new release. This is because a lot of core system files are substituted during upgrade, and many different files will be used to start your system, so for best effects they should be relocated again. This is also the reason why using e4rat on Ubuntu Development version is not advised, as in such case lots of system files are changed with updates on a daily basis… which kills the idea of remembering what has to be preloaded for bootup.

Do you like this trick? If so, let me show you how to install and configure e4rat.

How to enable it?

1. Installing e4rat. First, you need to get e4rat on your system. Unfortunately, it is not available in the Software Center. Therefore, begin by looking at e4rat downloads page. Choose the latest release, and download the .deb file suitable for your system (amd64 for 64-a bit system / i386 for 32 bits). Don’t install the file yet!

The default boot-up aid in Ubuntu is ureadahead. It does a similar job, but it never relocates files. Therefore while it is helpful in case of SSD drives, it does not improve much if a HDD is involved. Because ureadahead conflicts with e4rat, we’ll need to uninstall ureadahead first. The easiest way to do it is running this command:

sudo apt-get purge ureadahead

Note: This will warn you that you are about to remove ubuntu-minimal too. Don’t worry, this will not destroy your Ubuntu. Ubuntu-minimal is just an empty package that ensures all other required packages default for Ubuntu (like ureadahead) are present on your system. Therefore it’s safe to continue.

The next step is to install the e4rat .deb file we downloaded. You can double-click it and the Software Center will help. I prefer running:

sudo dpkg -i e4rat_file_name.deb

Once this is done, we can let it learn about your boot process!

2. Collecting startup files data. This step is about getting e4rat to know what files your system needs to boot up. This is fairly simple, and requires little work.

Start by restarting your system. Wait for the GRUB boot menu to appear (it is possible that you may need to hold the Shift key pressed in order to access this menu). When you will be presented with system selection menu, do not boot your Ubuntu. Instead, use arrow keys to highlight the entry you would normally use (most likely it’s called “Ubuntu” or “Ubuntu, with Linux version-version-version”). Press e to enter edit mode.

Do not be afraid of editing this data! Changes done here are not persistent! Therefore the worst thing that can happen while messing up here (unless you intentionally enter malicious commands) is that your Ubuntu will fail to start – but it will be back to normal next time you start your computer as usually.

The exact contents of what you will see depend on your system version. However, what we are going to edit is common to all of them. Look for a line that starts with:   linux /boot/vmlinuz-…   Use arrow keys to reach the end of this line, and add the following at it’s end:

init=/sbin/e4rat-collect

(Note: This line can be longer than your screen, and it will wrap around – if you are unsure where to add this text, go to one line below the one we would like to edit, and press left arrow key, which should take you to the end of the previous like – right where you need to add the above text).

Then press Ctrl+X, which will start the system using this new argument.

For the next 120 seconds e4rat will be looking which files are loaded during boot. Pro tip: if you open your browser (or any other application you use frequently) within these 2 minutes, e4rat will think the browser’s files are essential to boot, and will pre-load them everytime you start your system – this way your frequently used apps will also start faster!

Once your system is up, make sure everything went right, by testing if file /var/lib/e4rat/startup.log is present. I do it by running:

file /var/lib/e4rat/startup.log

If it says it’s a UTF-8 text file, everything’s fine. If it says there is no such file, you need to redo this step carefully – you must have somehow not launched e4rat-collect.

3. Relocating files.

Now we’ll need to boot up in low-level text-mode. This is because file relocation won’t work, if whole system is running. No worries – again, it sounds scarier than it really is.

To enter it, we’ll do something similar to the previous step. Restart your system, select your OS in GRUB boot menu, and press e to edit it. Look for the same line as previously (the one that starts with   linux /boot/vmlinuz-…  ), but this time we need to add some other text. Type:

single

and press Ctrl+X to boot your system. After few seconds you will see command prompt (if not, press Ctrl+Alt+F1). The following command will start file relocation, according to data e4rat collected:

e4rat-realloc /var/lib/e4rat/startup.log

It can take a long time. Do not worry if it does not finish within several minutes. It needs to move lots of data on your hard drive, and because it’s a slow one, it will take time. If you have little free disk space, this can be even longer. Just be patient, it will finish eventually.

Once it finishes, it will tell you some more or less interesting data about how well was it able to move your files.

It is recommended to run this command multiple times, until it clearly says that No further improvements are possible. Every time you run it, it should take less time, and really, it’s worth to wait – the better the files are located, the faster your system will boot once we finish.

When it says that there is are no further improvements possible, we are done with this step. Do not shut down your computer.

4. Enabling e4rat to preload files every time you start your system.

We are almost done. The last thing that has to be done is modifying the way your Ubuntu starts, so that it can benefit from e4rat. Still in text mode, run:

nano /etc/default/grub

A full-screen text-editor will appear, with a config file open. It’s very intuitive to use. Find a line that starts with  

GRUB_CMDLINE_LINUX_DEFAULT="..."

Leave whatever is between quotemarks, and add  init=/sbin/e4rat-preload . For example, on my system this line looked like that:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

so I changed it into:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash init=/sbin/e4rat-preload"

I hope that’s clear. Press Ctrl+O and then Enter to save the file, then press Ctrl+X to close the editor.

To apply the changes we’ve just made, run the following command:

update-grub

Once if finishes, restart your machine using this command:

reboot

Now your Ubuntu should start normally. Well… almost. If everything went right, it should start faster. If you are lucky, it will start lighting fast (and it will be just as fast on every reboot since now)!

I hope you found this guide useful, and that your system boot time shocked you. If so, thank the people who develop e4rat!

Final note: uninstalling e4rat. If for some reason you want to revert the changes you did with installing e4rat, here are the instructions. First, revert the changes to /etc/default/grub we introduced in step 4. Run sudo update-grub to apply this change. Run sudo apt-get purge e4rat to uninstall e4rat, and sudo apt-get install ubuntu-minimal ureadahead to restore ureadahead. Note that file relocation is not revertable, but you will not suffer from it.

UDS is a part of long-term Ubuntu tradition. Every six months the developers from all over the world would meet in order to plan development for the upcoming release, brainstorm ideas, discuss problems and collaborate in many ways to ensure that next Ubuntu is going to rock. But the event is not (was not?) just about planning. It was a chance for the community to actually meet, to get to know each other, to tighten the bonds within community. I believe this is crucial for being deeply engaged within the community, and for ensuring the relations within community, as well as it’s structure and organisation are well and sound (and isn’t it important to have friends within the community?). We all know that a big number of Canonical employees are working remotely, and I feel that this may be one of the key facts which contributed to the decision of converting UDS into an online meeting. Apparently some folks at Canonical realized that people do not need to meet in order to be productive. Moreover, a very important part of UDS was outside the sessions – people would discuss brilliant ideas during the dinner, some would seek for aid for their team by looking for interested folks, others would flash their mobile device with the help of experienced ones, and finally, some people would teach each other a lot. It is clear that none of these will happen in case of an online UDS.

From what I understood, the idea is to make UDS available to everyone, so that all contributors, regardless of where they live in and how far are they willing to travel, could participate to the sessions. I can, however, see some significant inconsistency here. The first fact is the choice of Google Hangouts for sessions. I agree this is a great handy tool for video conferences, and I use it myself a lot, but it cannot be assumed that everyone is perfectly fine with G+ policy; there indeed are people who do their best to avoid any Google products. We are told that IRC sessions will be provided for these who can’t join videos, but that doesn’t do much sense, because it does not differ at all from remote participation in summits which were real meetings (people who were unable to travel to UDS could use IRC to contact with session participants, the IRC log was displayed live in the room so that everyone could interact with the discussion even if they were miles away – I have participated this way during UDS-Q, and the experience was actually quite satisfying, even though I couldn’t see the faces of people I was speaking with).

I also have to express my doubts about session organisation. While some UDS sessions were indeed held by less than 10 people, many other would grab interest of more (e.g the ones from Community track), resulting in more than 50 developers in the room + at least 20 on the IRC, with at least 30-40 of them participating actively in the discussion. Now, if the point is to let everyone participate, then it means we aim for even more participants. Now please imagine 80-100 people in a single G+ hangout. Even a number like 30 seems bizarre! Either this will end as a huge mess, or only some people will be voiced (which, again, breaks the idea of opening UDS to everyone).

I have also concerns about the way it is said to be organised. The event is going to be two-days long, and it will take place between 4pm to 10pm UTC. Obviously, that means that a big part of the word will be sleeping then, and the other be at work etc. And that, once more, is aganist the principle of opening UDS to everyone. I don’t see any reason why this can’t be a 24h event, with sessions spread more or less evenly, so that those living in Australia can participate too. I also believe that some teams might want to schedule meetings on times that suit their people best, why limit them to few hours, if this is going to be an online event?

The length of the event is also interesting. Two days. Two days of few-hour long discussion. Compare that to traditional 5-day long UDS with sessions from 9am to 6pm. Add the fact that online UDS will take place two times more frequently, and the conclusion is that we’ll need to be 10 times more efficient to discuss all that is needed. Will this be enough time? Luckily, event length can be fine-tuned if needed. Some speculate this may be related to Ubuntu switching to rolling release model.

One of the main problems with how was decision handled is that it was 1) a surprise 2) immediately effective. I opened up Planet Ubuntu on Wednesday and learned that the UDS is next week. A lot of time to prepare discussion topic, isn’t it? At the time of writing this, there is not a single blueprint registered for this UDS. I might go on explaining why this was a terrible idea to announce it this late, but I believe you get the idea. Please also note that Canonical has never notified before about such idea. Until the announcement, everything seemed that the next UDS will take place as usually – this time in Oakland, and I expect there may be people who have already reserved their time. I feel that such crucial decisions need to come with some kind of transitional period.

With all respect to Canonical and their right to manage the money they own (UDS is a really expensive event, every time I try to imagine the amount of money that had to be involved in Copenhagen, my mind suffers stack overflows), I am very skeptical about this decision, both because of the reasons I explained, and because of some that I’d rather not share publicly. Time will tell how it will affect planning, development and community. I hope the lack of such meetings won’t have a major impact.

And please keep in mind that regardless of what changes are done to the way we organize our work, Ubuntu community will always make sure your favorite OS is the best possible! :-)

I am pleased to announce that vModSynth 1.0 is now publicly released and available to download.

What is vModSynth? It’s a modular software synthesizer for Linux. It is not intended to be as convenient as possible, but to resemble the look & feel of a real, analog, modular software synthesizer. See for yourself:

vModSynth allows you to play with a modular synth on your computer. You are free to choose any modules you wish, you can connect them however you want, and you will hear the result immediately. The synthesizer intentionally resembles the look of a modular synthesizer (I was inspired by modules manufactured by synthesizers.com), and it imitates behavior of one.

vModSynth integrates perfectly with external MIDI devices – you can play it with an external keyboard, and you can bind any knob to a knob/slider on your physical device, so that you can actually feel the synthesizer, and modify it’s parameters just as on a real one! You can also connect any external sequencing application, like Rosegarden or harmonySEQ.

 There is a number of modules you can add to your setup. A all-in-one oscillator, some effects, some processing modules, whatever you like. If I continue to develop this project, the number of modules will certainly grow, as creating new ones is very easy.

No limits to the number of modules, the number of connections, loops in connections, you are absolutely free. Just build your own synthesizing path and hear it in action.

The source file can be downloaded here. Compilation is as simple as ./configure && make && make install . A detailed user manual is available in the ./doc directory.

There is also a PPA for Ubuntu 12.04/12.10/13.04 available. To add it an install, use sudo add-apt-repository ppa:smartboyhw/vmodsynth-release && sudo apt-get update && sudo apt-get install vmodsynth . Thanks to Howard Chan for maintaining the PPA!

Questions, ideas, bugs? Please contact me directly, or leave a comment here. I have not yet recognized the level of interest others may have in this piece of software, and I need to investigate whether it makes sense to setup a bug tracker etc. However, if you are interested in contributing to this project, writing new awesome modules or generally helping me make vModSynth a awesome synthesizer, you will be welcome with my arms wide open!

Because of that, some have tried to recreate it to use as a desktop wallpaper. Among several versions that are available, I liked Michał Prędotka’s version most. This version was modified to many different colors by Michael Hall – he has even created a video tutorial on how to make your own color scheme for this wallpaper.

I love the idea of different simple wallpapers that share the design, but vary in colors. But I’m lazy, and I don’t want to change my wallpaper everyday to enjoy another color scheme. Ideally the wallpaper would change automatically. But if the design is identical and only colors change, then it may be neat to change the colors smoothly.

(these images are low-res, and are not meant to be downloaded)

I have written a small script which does that for you. It runs in the background, and every now and then it creates a new shade of color for your wallpaper. This way the color changes smoothly. By default, it takes full day for the colors to repeat (but you can chage the period easily) – it’s yellow in the morning, green near noon, in the afternoon it gets blue, evening is violet, and at night it gets red. You may want the colors to change slower (it may be cool to have the full cycle take a week, this way everyday’s a new color!). If you wish, it will be simple even to modify color selection algorithm as you wish.

You can download the script here. After extracting, simply launch the run file (you may wish to modify the script before). I have also added the script to the list of apps that is started when I login, so that it runs in the background whenever I using my desktop. By default, it refreshes the wallpaper every 10 minutes. This is enough for shade changes to be not noticable.

And of course the Dash and Launcher’s cameleonic features are following the mood of your wallpaper!

I hope you will enjoy this colourful trick!

To those of you thinking “Hey, that app is Ubuntu accomplishments. How does FitBit relate to Ubuntu?”: that’s what a separate collection means. All trophies are grouped in sets – each set may relate to a different community, may be developed by completely different people – and such sets are called collections. You can think about them as of plugins or add-ons. Collections are installed separatelly, and are optional. That means that you are free to install FitBit accomplishments alongside Ubuntu trophies, and that you can also use just FitBit badges and remove default collections that award you for being active in Ubuntu community.

Now why do I consider FitBit trophies a milestone for the project?

Ubuntu Accomplishments System has reached the level on which creating third-party collections is simple and clear. The appearance of FitBit accomplishments symbolises how extensive this platform is, that it can be used to present achievements in areas not limited to Ubuntu. This is the first additional accomplishments collection I am aware of – except for few proofs of concept we did some time ago – and that means a lot to me. This is the ultimate proof that the system is fully capable of integrating with third-parties. As far as I know, it took Matt and Chris about a week to create this collection – and considering the fact that they are busy people and how simple the scripts are – as seen in Matt’s post - it’s clear that making a simple set of third-party trophies is a quick task.

I believe that the power of this platform lurks in it’s extensibility. Imagine what collections others (or you!) may develop:

• Trophies for a local Ubuntu community
• Achivements in a video game
• Accomplishments representing aquired skills in a local diving/basketball/parachuting/etc. club
• Awards for being active in other communities (Kubuntu? Debian? Wikipedia? a MMORPG? DevianArt? or anything you wish)
• Badges for students symbolising awards for their efforts

You get the idea. The sky is the limit.

Now with the Accomplishments System being qiute stable, it’s no pain developing your own collection. Pick up any idea you have, use this guide hop onto #ubuntu-accomplishments or join our mailing list and we’ll make sure you find all the resources you may need to make your own awesome collection.

And kudos to Matt and Chris for their exemplary work ;-)

I’m definitelly looking for another chance to meet great developers from my city and participate in discussions with international experts. That was a great fun!

To my delight, some sessions met with wide interest. Especially the Accomplishments Writing Workshop was attended by many, and results are promising, I was told we can hope to see Ubuntu TV accomplishments soon! We have also found a new use case for Accomplishments, an IT manager expressed interest in using our platform to train employees, he hopes to achieve that by purging default accomplishment collections and installing a collection designed as a tutorial. I’m looking forward results, this sounds as a cool idea! Another great news is that work on UbuntuForums accomplishments is in progress!

We also have quite a good plan concerning how to get Ubuntu Accomplishments to Universe repositories for 13.04. There are some minor things we’ll need to fix, and we’re going to make the daemon a DBus service (I am going to investigate how we can make it starting both as a service and on user login), yet finally we will have all Accomplishment packages pushed into Universe. We think this is a very important step, because with these packages being available in Ubuntu repositories other developers will be much more likely to integrate their applications with our accomplishments system!

Another highlight from our sessions is how we are going to improve the Accomplishments Viewer for 0.4. I am going to work on implementing a wiser search&filter algorithm, that will enable us to add a search bar to the Viewer. We will be also working on visual updates, Martin has volunteered to experiment with rendering a wooden cabinet look for trophies collection. It is possible that we’ll also try our a webkit version of the viewer, but most likely we’ll stay with GTK+, and therefore I will be also trying to improve viewer’s performance and responsiveness. You can also expect new icon templates for trophies, just to increase variety of accomplishments.

Concerning accomplishments collecctions themselves, we have not reached consensus about rewarding user for sustained contributions. We need to investigate ways of awarding the user as he gradually progresses through Ubuntu community, but this involves discussion about core concepts of this system. It turns out that if we want to make Accomplishments more fun, it is very easy to start turning whole community into a game, which should be avoided. We will be continuing this discussion with Jono, as he may have a better idea of the direction this project should be heading towards.

Lastly, we discussed deploying Accomplishments Validation Server and Web Gallery on Canonical servers. Among other actions we’ll take to achieve that, we are going to prepare separate ‘production’ branches for both projects. We will also try desiging a formal accomplishments review process, to ensure that no new accomplishments added to official collections have some insecure code which will be run on these official servers.

Concluding, during this exciting week we have planed our work for the next release, as well as brainstormed ideas on improving general experience with accomplishments. It was a lot of fun, and I am really excited to start working! :-)

I was missing this feature on Unity2D. It turns out that I was not the only one who looked for help in the Internet in this matter – actually some people would like to use this feature. I’m going to give you a hand with that! As Unity2D is no longer developed, we cannot hope such feature will be ever implemented, so I prepared a simple script that patches few Unity files and enables that behavior immediately!

To get and run the script, use the following:

wget http://people.ubuntu.com/~rafalcieslak256/Unity2dBgToggle.sh
chmod +x Unity2dBgToggle.sh
./Unity3dBgToggle.sh

Important notes: This script works for Ubuntu 12.04 only. It modifies some Unity2D files, so if it will complain it cannot apply patches, do not force it to do so. Although I have carefully tested this script on several machines, I cannot guarantee it will work for everyone, especially if you are using other Unity2D mods. Also note that Unity2D updates will revert these changes, you will need to re-run the script.

If anything went wrong, reverting changes is as simple as reinstalling unity-2d-shell package.

Enjoy! ;-)

User-side goodies

• A brand new feature is social portals integration. This allows one to show off the trophy they got, by instantly posting such information on Twitter, Facebook, and whatever else your Gwibber is connected to. When you have accomplished something, just go to trophies details view, and use the big SHARE button. You will be able to edit the default message, and in a single click you can publish it to your friends – show them who has the coolest Ubuntu Trophies! Kudos to SilverFox for her awesome work on this feature!
  
• Publishing your trophies online. This allows you to easily share your achievements with the online service http://trophies.ubuntu.com, which should be deployed soon. Once published there, you can browse your trophies online, make your friends jealous of your collection, and use links to single trophies, which can work as the proof that you actually deserve the trophy. This feature is implemented in 0.3, but temporarily disabled, because it requires trophies.ubuntu.com to be live… we’ll enable it in 0.3.1 as soon as the web service will be ready.
• A slightly more sophisticated MyTrophies view. It now groups your trophies by collections, and allows you to browse sort them by the time of when you have acquired them – helpful when looking for what you’ve just accomplished!
• Ubuntu Accomplishments now successfully works on other distros and Ubuntu Flavors! That includes Kubuntu, Xubuntu, Ubuntu Studio, Lubuntu, Fedora and many more!
• Helpful welcome screen that appears in the viewer, when one has no accomplishment collections installed. It instructs how to install accomplishments collections, instead of being confusingly blank.
• More efficient scripts. By using wise caching tricks, we managed to decrease the time all scripts need to run by up to 60%! That means faster scanning for trophies, and less resource usage.
• An elegant daemon launcher. Up till now starting/stopping the daemon required a complicated command to be run in terminal, now it’s just simple accomplishments-daemon –start! The launcher now also takes care about the pidfile and proper logging – which fixes many bugs some of you have been experiencing.
• Ability to reload accomplishment collections from Viewer’s menu. This is really helpful if you are writing your own accomplishment; instead restarting the daemon, just choose “Reload…” in the Viewer, and your new accomplishment will be refreshed!

Changes in accomplishments collections

• New accomplishments. Thanks to everyone who contributed them!
  • Ubuntu Power Users
  • Gwibber – Added Identi.ca
  • Gwibber – Added Twitter
  • Gwibber – Facebook
  • Ubuntu Youth
  • Change Wallpaper
  • AskUbuntu Organizer
  • AskUbuntu Outspoken
  • AskUbuntu Scholar
  • AskUbuntu Supporter
• A great number of grammar and typo fixes. Thanks to all contributors who found them!
• Several accomplishment scripts were fixed.

Technical changes

These are probably the ones most exciting for us, as for this release we’ve focused on getting the API really stable, and improving the general quality of code. I do know average user will not notice them, but they are important to keep whatever’s behind the curtain in good shape.

At this moment, we’ve done lots of cleaning up, and haven’t yet messed up the code with 0.4 features. If you are interested in getting involved and contributing some code, this is probably the best moment to do so, as the code is now shining! In such case, get in touch with us on #ubuntu-accomplishments, or e-mail me directly.

• Unit tests. All API functions are now automatically tested, this reduces the chances of regressions and unwillingly broken interface. We have now a good collection of tests, that cover pretty much everything that is needed to ensure that on bugs will suddenly emerge in daemon’s API.
• Refactored API. Many things got renamed to use a common naming theme, we took care to use underscore prefixes correctly. There was also some PEP8 refactoring going on, which makes the code a pleasure to read :)
• Improved the way we use twistd framework. Lots of things were fixed in this matter, we no longer use tricky workarounds. That increases stability, and solves some bugs we’ve had with U1 and accomplishment notifications.
• Documentation. Huge amount of work was committed here – all API calls are fully documented, as you can see in daemon’s source or on these pages.

Plus a lot of general bug fixes.

That is pretty much it. Thanks again to everyone who made this release happen!