Over the past last month or so, I have been working on creating the hardware and the software needed to be able to boot/reboot/hard reboot my computers at home. The reason I need this is that I am going away for a few months, away from my computers, and I would like to be able to keep on reverse engineering nvidia’s ptherm.

A possible software-only solution is to use Wake-On-Lan to boot up the computer remotely, ssh to connect to the computer, grub-reboot to select the kernel to boot on at the next reboot and finally, the watchdog to reboot the computer when it crashes. If it seems to you like a pain to use, I definitely agree!

So, a hardware-based solution seems more interesting! The standard solution to solve this issue is called IPMI. The interesting features are:

• Being able to cut the power down and put it back up again;
• Read back some of the state (Power & disk LEDs for instance);
• Having a serial console.

However, I don’t have an IPMI-ready motherboard as they are usually used on servers. I thus decided to make myself an equivalent. The only thing that was worrying me was that I had to be able to control that from the internet. So, one machine had to be up and running! I decided to buy a Raspberry Pi as it was the cheapest and lowest-power consumption computer I could get with an ethernet port and a few General Purpose Input/Output (GPIO).

Using those GPIOs, I can control a custom-made circuit board to cut the power, press the power switch and read the power led state but the real question was about the user interface to wrap those GPIOs. I decided to make a web-based user interface because it was more demo-able and also could be updated in real time for displaying logs and the power LED state.

Hey. Been a while. Since the last time I posted, I graduated from two universities and moved to London. Life passes fast, huh? But hey, this is not a rant about the weather, food, cultural differences, the superficiality of relationship in big cities, expensive hockey rinks or whatever. Note how I’m not even pretending any more that I’m gonna tell you in the next post about that super cool thing I’m working on at the moment!

Instead, I’m gonna tell you about paper lanterns! Hey! Hey, no, wait! Hold on, don’t leave! Just a sec! We’re not speaking about your average paper lantern here! The goal of this project is to combine traditional and modern, handcrafted and digital, in short… to make a bunch of programmable paper lanterns!

As a new proud user of Octopress I missed the comment section that I used to have on our previous blog (powered by Django). However, I knew something could be done and months later, I finally did something about it :).

So, let me introduce you to Wt Comments:

Wt Comments is a project that was written in order to allow users to comment on static websites (such as http://www.mupuf.org). The goal was to create a secure, minimal and self-standing binary that would serve user’s comments as needed. These comments are to be stored in a JSON file.

I wanted a program that would run under a specific UID (using FCGI or a built-in http server) and that would provide strong separation between code and data in order to limit the risks posed by this service to the system. I decided to write this project in Wt, a C++ Web Framework that I have been looking into using for a while now, because it satisfied all my pre-requirements and allowed the usage of hardware and gcc security features such as the NX bit and canaries.

The program has been written with portability in mind. However, it is currently limited to Linux due to one simple function (getExeDirectory()). Feel free to send me patches ;)

Hey, it’s been a while since my last post about the Arduide. Here are some highlights of the past months.

Arduino Leonardo

Contrarily to last time, where it took a long time to get my hands on an Arduino Uno, an new contributor sent me some patches to support the new Arduino Leonardo. A big round of applause to Jefferson Delfes for bearing my comments and a few round trips before inclusion. The work included compilation flag fixes and a new way of uploading firmwares. As always, please test and report bugs!

A month ago, I was in Nürnberg, attending the X.org Developer Conference (XDC2012) as a Nouveau developer.

As you may have probably seen, the website has changed quite dramatically. The reason for this change is because we moved mupuf.org to a new server with a bigger storage space.

Hello readers,

While I’m a bit (actually very) late on my review of damn-whats-its-name-again (yes, that late) Tomoyo Linux, I wanted to share a couple of things with you. As you may know, I’m currently studying in a MSc degree of Research in Computer Science (woohoo). Which implies I read papers on a regular basis, and am asked as part of my studies to summarise and present these papers.

In one of my lectures (on the management of large collections of described data), I was asked to review a survey on the performance of Meta-Search Engines. Sounded interesting… Was much more than expected!

Introduction

To many people out there, parallel programming may not sound very useful, and actually pretty complicated. However, everybody expects processors to have several cores and software to make use of them. The whole purpose of parallel programming is to leverage the capabilities of multi-core processors, but this comes with a cost: we need to rethink our way of programming, moving from the old single-threaded or “a thread per task” programs to applications that describe their work-flow in tasks that can be concurrently processed: what is called task-based programming.

This may sound difficult, but it is necessary to produce code that can actually use several cores, and also scale properly (ie. keep a decent performance level) from single-core processors to computer grids with hundreds of cores. The problem of multi-thread apps made by hand is that often, threads are planned per task, but even worse, the number of logical threads in the program is not equal to the number of physical threads on the CPU, but to the number of tasks, which is fixed. This means the program does not scale at all, unless thread pools are created and managed by hand, which means a huge code overhead for the thread pool management system. Besides, this means you still have to do load balancing between threads on your own, which is again a difficult task.

To the difference of multi-threaded apps with synchronisation code, the goal here is to leave all thread management and task assignment to a specifically built library. In this article, I am going to explain the very basics of Intel Threading Building Blocks, most likely one of the most efficient and simple multi-core programming libraries in the wild.

A month ago, I was in Chicago, attending the X.org Developer Conference (XDC2011) as a Nouveau developer.

CMus is so far my favourite audio player. It is gapless, powerful, scriptable and console-based.

The latter is both an advantage and an inconvenient. Indeed, when procrastinating by browsing the web, I often find myself willing to watch flash-based videos. So, I need to find what console runs CMus to stop the music. I usually launch it in the first console of yakuake, a quake-like terminal for KDE, but stopping the music requires multiples actions.

I could have used KDE’s global keyboard accelerators to send a pause/unpause request to CMus, but I’m far more geeky than that. Instead, I decided to build a remote control to physically add a physical giant button.

While this idea was appealing for the sake of it, I wasn’t fully satisfied. So long for just sending commands, what about receiving data from the computer too? What about displaying visual information to a screen too?

As I know you like videos, here is the video of the current state of the project: