Weirldy enough I did not do much pure software stuff (probably because I already code quite a lot for my research), but spent a lot (I mean, most) of my spare time on more hardware or hardware-oriented things, mostly in the scope of hackEns, the ENS hacking club we founded in October 2010.

Among other projects, we built a RepRap 3D printer, a Mendel one, in early 2011, with a first successful print on April, 22nd, 2011.

hackEns’s Mendel 3D printer

A friend and I quickly started the replication process, building two Prusa i1 printers in August-September 2011 using plastic parts printed just-in-time with the Mendel. We continued the replication process with Jacques-Henri Jourdan, who slowly built a Prusa i2 starting early 2012, with a first successful print in late 2012, using plastic parts printed with my Prusa i1. That’s a beautiful chain of 3 generation of 3D printers. Over the builds, we have been amazed by the progressive technological improvements and the true capacity of the machine to auto-improve itself. During summer 2012 I almost reprinted all my printer plastic parts (the original ones were a little dirty and had clear defects that affected print quality), progressively transforming my Prusa i1 into a Prusa i2. One of the most striking things is that a 3D printer can produce better parts than the ones it is made of (and I’m not just talking about upgrades, but also about the print quality).

My Prusa 3D printer

What’s also amazing is how fast the software side of 3D printing is evolving. Slicing, which is the operation of transforming a 3D object description in a printer-friendly list of commands, is definitely a non trivial task, both on the fundamental algorithmic side and on the engineering side. Indeed, it is done by slicing the object into successive layers along the Z axis and then computing where plastic should be deposited on this 2D layer, which requires a lot of geometrical computations and careful coding to correctly handle edge cases. Skeinforge was the first software I used to slice my objects, which was later improved upon in a fork known as SFACT. However these python-based approaches were quite slow overall (partly because of the language itself, partly because of the design decisions such as a complete modularity which might not be the best for such a software), and a few months later a new candidate appeared, Slic3r, developed from scratch in Perl with speed and efficiency in mind, and is now regularly evolving with better core algorithms and GUI features.

The possibility to print objects and the availability of 3D sensors such as Kinect (and software such as Kinect Fusion) has pushed replication possibilities way further than what we could have dreamed of 10 years ago. And for the hackers, it is now possible to build complex 3D objects from scratch, without having to painfully machine wood or metal by hand or with super-expensive CNC tools. If Thingiverse (or should we call it Makerbot Thingiverse now ?) is full of cute or pretty designs, it has also become a home for DIY hobbyist and hackers. Coming from a pure CS background with little engineering knowledge, we were able to develop a hexacopter (a multirotor unmanned aircraft with 6 engines) frame from scratch, printing it with our 3D printers and flying it (but I’ll tell you more about this project soon).

hackENS’s hexacopter being assembled

The only sad thing overall is that some people are trying to leverage the interest in 3D printing technologies to make a lot of money by selling crappy printers. The number of 3D printer crowdfunding attempts which were started on Kickstarter is just unbelievable, often promising things that cannot be achieved with the technology they are using (like printing super huge objects which are not hollow without a proper heating chamber) or just trying to sell existing designs at crazy prices. It’s also sad how Makerbot is getting all the good press while at the same time they are going further and further away from the open source approach, but that’s another story.

This is why we, at hackEns, started working towards setting up such an installation on one of the fronts of our school dormitories in Montrouge, France (right outside Paris). The first step was obviously to design a working module to lighten each window, producing enough light intensity to do something impressive while still remaining cheap enough to deploy over the whole building (which is basically 6 floors with 8 windows on each floor, so 48 modules altogether). Let’s note that due to the specific structure of the building, our best call is to put the lights outside on the floor of the small balconies we have, as opposed to the previously mentioned projects where the lights were on the inside of the buildings.

Here is how the current module performs :

The module is remotely controlled from my laptop, which is connected to another computer through ssh, which is itself connected through an USB-to-serial wire to a RS485 transceiver which dispatches the commands to the light modules on the bus.
Our current control scheme is to use a tiny PIC10F per window to control each color component through PWM (given the output power of the LEDs, we actually use some transistors in the middle to do the power amplification). The PIC receives its orders on the RS485 bus. Note that since RS485 is limited to 32 receivers, we will actually use 2 RS485 buses with 24 receivers on each bus. The protocol we use on RS485 is quite simple, basically mentioning on a few bytes the module identifier and the three R/G/B components, with a few extra details for correct synchronization.

We tested a bunch of various high power LEDs, from simple 5mm high power LEDs to 3W StarLEDs through some very nice SuperFlux LEDs. Each kind of LEDs had its pros and cons, let’s list a few. The simple ones were really too direction, with a viewing angle of about 15°, so that it is almost impossible to melt the red/blue/green colors into something else. The superflux ones were pretty cool, produced quite nice melted colors, but were really not powerful enough (especially on the red side) so that we would need something between 5 or 10 of them to do something cool, leading to a lot of extra issues and requiring a lot more of PCB space. The StarLEDs are definitely the best on most aspects, a single StarLED produces awesomely bright colors, and a simple sheet of bakery paper is enough to ensure perfect color melting (which is already pretty good, except on the borders of the lightning area, due to the 3 single-color LEDs inside the StarLED being 0.5mm or so away of each other). The only issue with the StarLEDs is that they consume a lot of current, being powered at about 3V/1A. This leads to power supply and security issues, since we do not want to have wires with 50 amps running all over the front of the building. We intend to solve this issue by splitting the power supply scheme into a tree (with one or two branches per floor) and by powering each floor with higher voltages and lowering them to 12V or 5V with a switched-mode power supply on each floor.

The next milestones are to evaluate some cheap StarLEDs from Hong Kong, then to produce a prototype PCB and then to scale up to the building.

There are still a few issues right now, namely the fact that we need to find a cheap way to enclose our hardware to make the whole thing weatherproof, the fact that we need to get the approval of all the people living behind the windows we want to lighten, the approval of our lovely administration, and we need to find the money to find it. While the first three issues are pretty much a matter of time, any help on the financial side is obviously welcome. More specifically, if you know a company which could either provide financial support or hardware support (especially on the StarLED side, which are about 12 euros per LED, and which make it for more than 90% of the project budget), your help is more than welcome.

Window module prototype

The BeagleBoard-xM is a 8.25×8.25 cm board, powered by an ARM Cortex A8 CPU and relying on 512MB of RAM. It features, among other things, a microSD slot, a serial port, an ethernet port, an HDMI output, a S-Video port, 4 USB-A ports, 1 miniUSB OTG port and stereo input/output. There is basically all you need to build a simple desktop computer. Just plug in an USB keyboard, an USB mouse, an RJ-45 wire and your HDMI wire and boot it. Well, almost.

Before being able to run anything useful, you have to first power the board and then build a microSD card with an useful distribution on it.

First tip : connect your BeagleBoard-xM to your computer through the serial port. Buy an usb-to-serial adapter if needed, buy the serial wire if needed, but do not try to get things working blindly. You definitely won’t be able to debug any bootloader problem without a working serial link, and you’ll most likely waste much more time than you’d need to go to your local hardware shop and buy the required bits.

Now, let’s insert the provided microSD card into the slot, and move on.

TL;DR here : don’t try to power your BeagleBoard using USB OTG, use a regulated 5V DC power supply instead
Powering the board might seem easy, given that there is an USB OTG slot through which you can definitely feed power to the board to get it running (LEDs blinking), but there are two caveats. The first issue is that a single USB host port cannot supply enough power to the board to get it running smoothly. The most obvious symptom of this problem is that the board simply won’t boot (the bootloader will load the ramdisk and uncompress the kernel and hang there, or it might even start the bootsequence but will fail at some point with no obvious reason, or it might even reach the second issue, but even without the second issue it won’t be able to finish the bootsequence). As advised on some forums, you can use a Y-shaped USB wire like those you can get for 2.5″ USB external hard drives. This will enable you to give enough power to feed the BeagleBoard.
Yet, you will still encounter the second problem, which is that the kernel will panic at some point during the bootsequence, exhibiting a problem somewhere inside a musb_interrupt call. This seems to be because of a bug in the OTG module of the kernel used on the test system, which makes it impossible to boot with something plugged into the USB OTG port, so you’ll have to power your BeagleBoard using an external 5V power supply. We used a 2 amp regulated DC power supply for that purpose. Since it could only deliver 4.5V and 6V outputs, we had to use a 5V/1amp voltage regulator.

We were then able to boot on the test system, got a nice prompted, logged on, assessed the fact that we had a basic system, ran the mandatory testled tool, and halted to move on to the second part : setting up a complete system.

This is where the fun really begins, because most howtos are about the original BeagleBoard (non -xM), especially on the eLinux wiki, and that can be quite confusing. We’ll use Ångström distribution, which is a simple GNU/Linux distro targetted at embedded hardware, such as the BeagleBoard. This choice was made based on the fact that the Debian ARM packages are compiled for a more generic kind of ARM CPUs, on the fact that the current Ubuntu poorly performs on BeagleBoard-xM (it does not fully support the board’s CPU and downclocks it badly), and that the other competitors (Android, Maemo/Mer, Meego) did not look that great.

Basically, all you have to do to setup the microSD card is to follow the excellent instructions from Trey Weaver, with a few extra tips.

First, to be on the safe side, you can get all the files you need from the Ångström BeagleBoard demo fileserver : mkcard.txt, MLO, u-boot.bin, uImage, modules.tgz and the Angstrom-Beagleboard….tar.bz2 rootfs. You do not need to go through Narcissus.

Next, make SURE that the first file you copy to the boot filesystem is MLO, otherwise it won’t be able to boot (the bootloader has to be the very first bytes of the filesystem).

Next, when looking at other howtos, ignore all the bits about pressing the USER button, or about halting the autoboot to set the bootloader options : you do not need either. Indeed, the BeagleBoard-xM has no NAND flash to store the bootloader options, so doing the saveenv command of the bootloader will just make it hang. Instead, if you want to specify your own bootloader options, you have to produce a boot.scr file. To do so, install the mkimage tool (it’s packaged in debian and ubuntu as uboot-mkimage, it originally comes from OpenWRT bootloader u-boot which we use here). Then create a file (let’s call it boot_cmd for instance) containing the boot commands you want ; a basic command file is the following :
setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait'
mmc init
fatload mmc 0 0x80300000 uImage
bootm 0x80300000 Build the boot.scr file from it :
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Beagleboard-xM boot script" -d boot_cmd boot.scr
Now all you have to do is to copy boot.scr to the boot partition (i.e. alongside the MLO, u-boot.bin & uImage files) and reset your BeagleBoard.
This can be useful to specify the video mode to use, for instance I use the following bootargs to get correct rendering on my LCD :
setenv bootargs 'console=ttyS2,115200n8 omapfb.mode=dvi:1360x768MR-16@60 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait'

You should now be able to put your microSD into your BeagleBoard and get it running fully (I have a few initial hiccups with the microSD not being recognized or so at this point, I just moved it back and forth to my laptop and it worked beautifully since then). You should get a working GNOME environment (after a nice gdm prompt).

Let’s note that Ångström uses opkg package manager, which works in a pretty straightforward way, with install/remove/update/upgrade commands. Note that you have to use the list command to search packages, i.e. you need to do opkg list opencv to look for opencv-related packages, and not opkg search opencv as you would do with apt.

I was very pleased to see that opencv was installed by default (I guess, or at least I did not have to install it after performing an initial opkg upgrade), that my Logitech webcam was recognized from scratch and that I could use mplayer tv:// without any more tinkering to use it.
The current image does not come with a build chain, so you have to install the required bits to build your own apps. I believe all you need is to install the task-native-sdk package to get everything (gcc, g++, make, binutils…) setup. I guess I only had to install git, vim,pkgconfig and cmake by hand to feel home once that was done.

I am now investigating some issues related to building stuff using OpenCV, similar to those described here on Stack Overflow. I’ll keep you updated.

The school season started extremely fine with a lot of motivation from a few friends and I about getting a robot built for the next Eurobot French national contest. Soon after, another guy announced his will to create a hackerspace inside the school, quickly gathering a lot of interest from other students. We soon founded hackEns, a hacking group with various goals, from getting a Fab Lab running with the required tools and a RepRap 3D printer to building musical instruments from leftover wood pieces, through building our robot, hacking a PS-2 keylogger or fixing the broken light & sound hardware lying around. We even have a place (well, it’s in the school’s basement) where we can freely work.

Months later, the group is definitely not dead. We hosted the build of a Huxley RepRap of two artists from a nearby school, our own Mendel RepRap is almost done, our robot is nearing the prototyping step and we have a few new projects in line, from building a RC car with a thermal engine to setting up a Blinkenlights-like project on one of our school’s dormitories. I’ll try to cover our latest activities and findings over time. Keep posted, it’s gonna be legen… wait for it… dary !

• Plugged the camera through USB, restarted it
• Checked that it was detected with gphoto2 --auto-detect
• Checked the capabilities with gphoto2 -a
• Looked at the config options with gphoto2 --list-options
• Found the /main/status/shuttercounter option
• Ran gphoto2 --get-config=/main/status/shuttercounter
• And here it is : 27781 shutter actuations

That number seems quite reliable, since I can have about 15000 of those pictures on my hard drive disks and I used to drop about 2 pics on 3 in my early days (I’m a lot softer on the shutter now, after experiencing the joys of picture sorting ).

Good to know I’m still far from the 100.000 actuations expected shutter life for 450D’s.

Well, thanks gphoto2 for your simplicity !

You can find the source in BloGit git repo, and see an example at BloGit example. To use the source, you first have to pack it (using the pack script), which will merge the raw_post and raw_produce, producing a single post script (which I also included at the end of this post), which you can simply put in an empty directory and run it. It will unpack the other script (produce), initialize the git repo, and set the hooks. It’ll then prompt you for your post title and then open an editor for you to set your post contents. Save the file, and you’re done with your first post : check the index.html file which has been produced in the same directory. You can write your own stylesheet in the blogit-style.css file. Further posts can be done with the same post script.

Yet, the best way is probably just to use the usual git workflow. To initialize the repo and all, run post --unpack, and to post post --raw or git commit --allow-empty (when using git commit, leave a blank line between the subject line and the rest of the post). You can also amend existing commits (using git commit --amend), use the GIT_AUTHOR_* environment variables to change the author, and so on. Since merge commits are skipped by the html generator, it should work just great for multi author blogging !

PS : I know this is JUST a git log pretty printer, and that the whole thing is pretty much trivial. I also know that using versionned files to store the posts would allow a lot of extra bonuses (such as automatically adding “Updated on …” mentions based on the commit log of each single file). I just thought the idea was fun There are probably a lot of things to improve, or a lot of smart git features to use there that I overlooked. Feel free to leave a line

#!/usr/bin/env python
"""
 bloggit
 Author : Guillaume "iXce" Seguin
 Email  : guillaume@segu.in (or guillaume.seguin@ens.fr)
 Copyright (C) 2010 Guillaume Seguin
 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
 as published by the Free Software Foundation; either version 2
 of the License, or (at your option) any later version.
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street, Fifth Floor,
 Boston, MA  02110-1301, USA.
"""
import subprocess, os, sys
import base64, bz2
CONTENTS_FILE = "POST_CONTENTS"
repo = os.path.dirname (os.path.abspath (__file__))
os.chdir (repo)
if not os.path.exists (os.path.join (repo, ".git")):
    subprocess.call (["git", "init"])
produce_path = os.path.join (repo, "produce")
produce_script = bz2.decompress (base64.b64decode ("""
QlpoOTFBWSZTWQf3J2wAAV//gFxQAYB6b/p/f+fe7r///+pQBd42u22yaV13O6AGigNBIy
aIp7Sn6DJiSaeSeo00PykD1M1B+inpA03qQDU0AJk0mhqNPRGgAGjQaAGgADTQDQEajUYp
im2RT9U9RkGTQZAZG1DIAAAcaMmRhGIBhNBgE0GgZMmjJkMIDCRQTQmCaJtI1GjT1GmhqA
0yPUNDQbUNDQepWIWGfa4d31kD+Y5Rb4yaILtfQ2R3ruai19rArmVtHwltw/M/SKgVz+HG
mewWVLlaRGi+TgiYISYkD6/fECu/rM0N4r5GtcYW1QTuePdDZ+sPg4zb9+44SCBIOFkkg0
x55udVuK1GAeJhbulbdkEl+jz2G9vfcAh34ns8FhgJwKe1v5KFIdM2Eyyw0GMr3CL7ZNzK
RBUsFKRqwtgoNy9FHvVS66uV+heJbKHRXDHFf4J1zs3cj8oXsMfU5N+644WGdjzvLX1aap
AI6VwBnkLDzalqgjQuC2soFnZlK5GCZb80ra1gw5fh4rnD8GUmm6eUSa5mYoiFgrwmamRK
zCz9yuRcozq5UKJtbq3sBSN1gjHDQ9z2BK7Dw2KcWMHm491MdO2B62ZoUOzKwCqoREREHo
ZjLn2p0HiWYoMBQRP8YCAzIgZUc2PJZaZrY/lODrob1VQg4U9L1ZRXpNBCelwBoEqUbFCs
BJpOCKGs54vnVO1AQDU6v9X0lEnEHuE1nlsy5pNWawCEYImSZc/AdREPAKBrlp73jcCryL
OAdFJcMZqdVjjE5gIfQY4Qjju9UdOBBmuXjz6uZhpsc3LhrDg1BQGoL4GyiDRmpTkImmc9
YlDd26K11qaiVDQ4wwITIEMyxMiLi274jeFlLrj8BpnXU87qMq6z2VQs6RN74sifuXfw7d
bOOm9bexNvdsxPvZDgG0cmUYClTHvcCFAMAdL+/IndGLRmvh7w/Bni8LAUfWdAcRyR4NDu
d49goYEMqHwDJLLa4vSbQRLptFdWVLzfSggKVzGtJIX1laSjr8I2BUTyiovpeiiyNQZu5Y
xresZCItgNp6ArbjFsCdRdgrgsw9tcrCa1Djq7A7ItXvGBWWs9IP0iIEAqnJ8xcH6Do9+1
UNVwkrSI5yC/J0ACce0NqBmWdEXp0KBIBWawoxJI66zSW55iEHoFRC0m8pYQICMFCcrrbT
Lg5yvtsbQNwVvMipGYYYTGs+czVBOZBcoWGD+l1xRtlbVMDwM0OpEVa3YMa1Ax/SosYOB4
WQVhQejJLSsL7hmrQh6V/tgUDTQ1C5tNdUOZckY4G+CyuDeTOgkEyPE+YjKpYtTRnMzumS
KImpjWQIAaLK2djnoVkRq5F+Sglu77bey0552SggnVQj0jKnFwwvhT3Y6oFpO4b8hmb1t7
A3yKE74eX6aqvJ7fP5wjXYonDYwumjqnrlv3obv7WsTxFpxVYpHCErmRUKGvwPUiSRWYMn
FZIzt0eUPDxJrGAamFrkeX3WwB0CmC/Jls/DLFV7uiPSiVaMNxy1GXfqziuzlXVsk2mQw2
AeNj5+QtDUFuUCZKDGMagNGpxIx/46nKSJsbprNPXGqzJVxVcglKGV5VysJDCqgRinuNbX
ChqDzZ6JXB8Rz0VF8aK+NMxXupulQOr1U6XP19can5uVqG7fs6Sa3Kq51jGOK9jDQ6fZf4
zXLr884Wq67SW+YyPk5OB1G0WmA1s8OiKQRBccciEMujm6A2LMvcIDogVk2GRbzgYrapcB
VDXEsgM9FJCQrvwaVw3C6i0FlYbnwXoJqe3bYlAjrGTVnqOSOpUOWcFXUdVlKmeOahYuhi
mEIgcCiiFMPnz5r1hXukd6HApZVuGq1kxn8DgWUiEMcRm+5FDm1Y7cFNuOVzIkcaRHdWGj
vESnObg+IQwh5zNAYUb6CROYdEATsATAW/EnFc9IJTEQfCce8EymZ4uNSNoi3DgvNBNkxt
jAmszFZUqNLNxxkjqWcA+gkju1U2gyzjAujsieBpM9X37TNq17LCRv6ToL1MIOJeWVwUiB
6MrbOTHwIixlYyW5xO7y/+LuSKcKEgD+5O2A==
""".strip ().replace ("\n", "")))
if not os.path.exists (produce_path):
    open (produce_path, "w").write (produce_script)
    os.chmod (produce_path, 0755)
for hook in ("post-receive", "post-commit"):
    hook_path = os.path.join (repo, ".git", "hooks", hook)
    if not os.path.exists (hook_path) \
     or os.path.realpath (hook_path) != produce_path:
        if os.path.lexists (hook_path): os.remove (hook_path)
        os.symlink (produce_path, hook_path)
if "--unpack" in sys.argv:
    print "Unpack only"
    raise SystemExit
if "--raw" in sys.argv:
    p = subprocess.Popen (["git", "commit", "--allow-empty"])
    p.communicate ()
else:
    title = raw_input ("Post title ? ")
    editor = "vi"
    if "VISUAL" in os.environ:
        editor = os.environ["VISUAL"]
    elif "EDITOR" in os.environ:
        editor = os.environ["EDITOR"]
    contents_path = os.path.join (repo, CONTENTS_FILE)
    if os.path.exists (contents_path):
        os.remove (contents_path)
    ret = subprocess.call ([editor, contents_path])
    if ret == 0 and os.path.exists (contents_path):
        contents = open (contents_path).read ()
        os.remove (contents_path)
    else:
        print "A problem occured while editing the contents file"
        raise SystemExit
    p = subprocess.Popen (["git", "commit", "--allow-empty", "-F", "-"],
                          stdin = subprocess.PIPE)
    p.communicate ("%s\n\n%s" % (title, contents))
if p.returncode == 0: print "New post successfully added"
else:
    print "Couldn't add new post"
    sys.exit (1)

For a few weeks now a couple of friends and I have been working on a media player for Maemo 5 with some extra bonuses (mostly track scoring and track prediction). Now that we have something pretty much functional, I was willing to produce some .deb packages for easy installation. I knew it wouldn’t be an easy task — and it definitely wasn’t.

Since I had no Scratchbox setup in the first place (64 bits distro, etc.), I first tried the py2deb/PyPackager approach, which let’s you create .deb packages directly on the tablet for python apps. Sadly, this approach requires you to sort your source tree in a very strict manner, which is as it will be on the device. Since I plan to rebuild my package often and I don’t want to work in an uglily organized environment, this is not the solution.

I thus set a debian virtualbox and installed Scratchbox on it, and tried to use a very simple cdbs build system, using python-distutils.mk (I already had a distutils build system working), and then building the .deb with dpkg-buildpackage. Sadly, for an unknown reason (to me) this was putting the python libs into /var/lib/pyshared/, which is definitely not in the n900 PYTHON_PATH, plus the package did not include the empty __init__.py files in the packages (it seems they were removed by python-support which is used by python-distutils.mk and are meant to be reconstructed upon install, though they weren’t), which lead to a completely broken package.

The next attempt I made was to use sbdmock, which is used by the official maemo.org autobuilder. Sadly, while it was successfully building other packages, it never succeeded at building my package because “pyversions”, which is required by python-distutils.mk, was missing (seems this is a known problem — though this might actually be fixed now and I might just be lacking the right builddep).

Instead of try to do it right, I should probably have done it fast. Since I’m using a debian-based distribution on my laptop, all I had to do was :

• Install python2.5 in the right prefix (/usr), restore the /usr/bin/python symlink to python2.6
• Write a simple homemade debian/rules file which runs distutils and then sorts everything to the right package prefix (this is actually even easier if you only have one package since there is no sorting involved ; I included a sample one at the end of the post)
• Specify Architecture: all in debian/control (since this is a full python package, it should run on any platform)
• Run dpkg-buildpackage. Enjoy !

Let’s note that there is something called stdeb which might be easier than this process. Too bad I only found it now

Sample debian/rules :

#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif

configure: configure-stamp

configure-stamp:
dh_testdir
touch configure-stamp

build: build-stamp

build-stamp: configure-stamp
dh_testdir
$(MAKE)
touch build-stamp

clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
rm -rf $(CURDIR)/debian/mymediaplayergui
rm -rf $(CURDIR)/debian/python-mymediaplayer
-$(MAKE) clean
dh_clean

install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
$(MAKE) install DESTDIR=$(CURDIR)/debian/python-mymediaplayer
mkdir -p $(CURDIR)/debian/mymediaplayergui/usr/bin
mkdir -p $(CURDIR)/debian/mymediaplayergui/usr/lib/python2.5/site-packages
mkdir -p $(CURDIR)/debian/mymediaplayergui/usr/share
mkdir -p $(CURDIR)/debian/mymediaplayergui/usr/share/applications/hildon
mv $(CURDIR)/debian/python-mymediaplayer/usr/bin/maemotunes.py \
$(CURDIR)/debian/mymediaplayergui/usr/bin/
mv $(CURDIR)/debian/python-mymediaplayer/usr/bin/mymediaplayergui.py \
$(CURDIR)/debian/mymediaplayer/usr/bin/
mv $(CURDIR)/debian/python-mymediaplayer/usr/lib/python2.5/site-packages/mymediaplayergui \
$(CURDIR)/debian/mymediaplayergui/usr/lib/python2.5/site-packages

binary-indep: build install
dh_testdir
dh_testroot
dh_installchangelogs
dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb

binary-arch: build install

binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure

After spending quite a bunch of time trying to tell X to just ignore, I took the easy way and… switched to Ubuntu. But yesterday, I asked drago01 (maintainer of Compiz packages in Fedora) about the issue, and he immediately recognised the problem, calling it the “Ghost TV problem”. According to him and Adam Jackson (ajax), this is a screw up from hardware vendors. The graphics chipset thinks there is that TV plugged while there is definitely none.

Anyway, he also pointed me to the fix. 4 lines in xorg.conf and you’re done (this is actually my whole xorg.conf )

Section "Monitor"
Identifier "TV1"
Option "Ignore" "1"
EndSection

The bold parts are all about the money that gets wasted by ads on a free web service. Let’s review the initial assertions and the conclusion :

For a company employing 10,000 people with an average loaded cost of $50/hour

Users would thus waste 1 hour and 34 minutes

In total, the cost of having employees look at and occasionally click on distractions costs the company $1.2 million per year.

What’s wrong here ? Well, first I guess that the main problem is that the stunning effect of the article is that $1.2 million per year, which looks huge at first sight, but if you look a little more, this $1.2 million a year is for a 10.000 employees company, so that’s actually $120 per employee per year, which is, as specified, about 2 hours and a half of work of that employee over the whole year.

Now let’s get around the fact that the employees sometimes have to go pee. I’d say that’s easily 5 minutes lost a day in non productive hygiene stuff, at least, which amounts for a total of about 20 hours a year per employee lost, which gives an awful $1012 per year per employee, or for our test company $10.1 million a year. Urgh ! Guess it’s about time to get the WC outside of the work area and have your employees swipe out & back in when they get there, to remove this illegitimate 1 grand you are giving out to each employee each year for nothing but pee !

If we also include the fact that anyway the employees won’t be 100% productive all the time, which leads to even more wasted money, that $1.2 million a year starts looking a little bit ridiculous. That’s the whole problem with that article, they used that 10.000 fold factor to have some significantly stunning figures to give, while completely omitting to mention how that scaled to.

Based on some rough estimations (about 3 weeks of holidays, working 5 days a week, 8 hours a day), our company is spending about $100.000 a year on each employee, or a total of $1 billion a year on human resources (on just those working in front of a computer screen). Two conclusions : that “wasted” time amounts for just 0.12% of the company HR expenses in that field, and that company is huge : 10.000 employees working on a computer, it must either be a large IT company or a really large non-it company, and in both cases, even if they probably don’t rely on free services (that would be silly), $1.2 million is probably just pocket money for them…

Don’t get me wrong, stupid wastes should be avoided as much as possible, but please, pretty please, don’t try to hold your point using huge scale factors. Numbers lie, but when the lies are unveiled, the liars just look like fools. It just doesn’t help and could be avoided, especially when there are other much more robust arguments (here against ad-powered free services) around.