Saturday, 29 December 2007

Copying whole partitions preserving hidden files and attributes

How do you easily and coherently copy a whole large and complex directory, preserving attribution, hidden files etc? Good old cp -a could not be enough in this case (hidden files would be skipped), and maybe you don't want to use dd (e.g. you could like to move a ReiserFS partition to an ext3 partition). The trick is hidden in the Debian tips , but can be applied to any Linux (and probably Unix) distribution. Since I got crazy yesterday trying to find it again, after using it to move partitions from my old hard drive to a new one, I repost it here:
find . -depth -print0 | cpio --null --sparse -pvd /new/directory
That's it. A 1:1 copy of your filesystem hierarchy is deposited in the new directory. It saved my day.

Tuesday, 11 December 2007

Removal of Ogg Vorbis and Theora from HTML5

This blog post made some noise recently.

Let's see. HTML 5 is the next revision of the old and beloved HTML. Such a spec is still under development and, among other things, should specify (or at least suggest) what the standard media formats of the Web should be. HTML5 in fact specifies a

Thursday, 1 November 2007

A Linux user fights Mac OS X Leopard. Days 2-4

In the previous post, I wrote about my very first (3 hours) impressions on using Mac OS X, comparing it with the operating system I mostly used before, that is Linux.

Some day has passed, I used Leopard a bit more, and now it's time for some new random thought.

Of dock and stacks. I begin to have problems with the dock. I figured out that nothing like an application menu is easily available on this thing. I tried to "emulate" that by using stacks, but this does not really work. Stacks are an OS X Leopard innovation. Basically, if you drop a folder on the dock, this will show up as single icon. Clicking on it , you see the content of the folder, stacked. See here for example.

There are several problems with stacks. First, the stack icon is basically a superimposition of individual icons of things in the stack. A very bad idea. For example, my Documents folder is represented in the dock by a .zip dull icon, because the first file OS X sees is a zip file. Of course, I cannot customize the icon appearance. Nothing in that icon tells me it's my Documents folder.

Compare it with KDE standard behaviour, where you can place additional menus at will on your panel. Kubuntu uses it to have a standard "Places" menu where you have links to your home folder, the network computers, storage media and other users folder. No Finder clicking needed. See this screenshot for example. Also XFCE implements that. In this, for usability, Linux desktop environments beat OS X hands down.

So, to have an application stack, you have to put your applications in a given folder, then drag this folder on the dock, and you'll find yourself with a crippled menu-like thing that doesn't allow for menu hierarchy, with incomprehensible icons. Don't like that, and the neat visual effects make me cry even more: instead of an awesome-looking menu-like thing, we have a crippled thing that just looks awesome.

The Dock seems also subtly buggy ; it lost application links on me at least a couple of times. Hope it gets fixed soon.

I like the fact that an active application is evidenced on the dock, instead of taking space of an application bar. It seems a bit inconsistent from time to time (now Firefox for example brought another icon of itself on the dock, with a bright spot underneath, instead of adding the spot on the icon I launched it from), but maybe it's me not understanding its logic.

Finder. It seems me and this thing cannot be friends. It's such a retarded file manager that makes Windows Explorer look cool. Tree view is available, but why can only you switch from tree view to icon view to the three-panes view? In Konqueror I have available a tree view of my folders on the left, like the Bookmarks panel of a browser, and then the main icon view of the currently selected folder. So you can have nice previews and you can easily navigate the tree, all in once. Windows too, if I remember correctly, allows this.

If there is a free, decent OS X file manager let me know.

Open source applications. I mostly use open source software, and it is of course repackaged for Mac OS X too. Sadly, OS X looks a bit of a neglected platform for open source, which is very strange given its Unix foundations. I installed Firefox, Thunderbird, VLC, FreeCiv, Celestia, Inkscape, NeoOffice, aMSN and Gimp. Mixed results. Firefox and Thunderbird seem to work perfectly. Java and Flash support is installed by default, which is a good good thing. aMSN also integrates nicely, and is visually much better on OS X than on Linux.

GTK applications, like GIMP and Inkscape, are another story. They work fine, provided the X server is on, but using a GTK app on OS X is tiring. I am accustomed to mix and match look-n-feels on Linux, so aestethics is not the problem. The problem is the mixmatch of two paradigms: the "menu-bar-always-on-top" of native OS X and the "menu-bar-is-in-the-window" of almost all other operating systems. Mixing widget appearance is fine; mixing usability paradigms is an hell.

I think Apple should give the users the possibility to configure OS X so that the menu follows the application. I don't know if it does; it can be some advanced setting, but it has to be made easy. OS X forces its paradigms on the user and applications, disregarding anything away from this paradigm. It would also be nice if other operating systems can follow the OS X paradigm at user will, but the default is not the OS X one, so it's Apple that has do to that first. Good to think different, bad to force everyone to think like you.

I noticed also that OS X packages are left behind in terms of stability and being up to date. Celestia and GIMP crashed on me quite often -GIMP regularly when I try to draw. The GIMP binary is a 2.4 release candidate -no 2.4 final binary is available. Freeciv 2.1.0 is unavailable for OS X, and 2.0.9 doesn't start at all -it shows the initial screen, then silently dies. OpenOffice is unavailable unless in the reincarnation NeoOffice, which is behind at version 2.2. On Linux, most of these packages are rock solid and up to date. I will have to try MacPorts soon, that probably can improve the situation, but it's not an easy install and it's OK only for power users.

Don't know who's in fault here, but the situation could improve.

iTunes. I wanted to play an mp3 folder from a DVD-r. So I inserted the disk and dragged the folder on iTunes. That bitch, instead of simply playing, copied all the mp3s in the Music folder, reorganized them on her way, and only after begun playing. Didn't. Ask. Me. Anything. This is an insult -I never asked you to copy a file, let alone to copy in a location I didn't told you and to reorganize them as you (not me) find pleasurable!! It's incredible such a totalitarian approach is default behaviour. iTunes should at the very least have asked if I wanted to copy-and-reorganize folders, or not. I didn't touch it anymore. I hope someone can point me to a better music player.

Terminal. Didn't use it a lot, but it's OK. Its default appearance is terrible, but it can be customized and has true ARGB transparency. It also has tabs, which are a really useful thing. It seems thing are not color-coded as much as in Linux, which is a bit sad, but not essential.

Spaces. Spaces is Mac OS X Leopard implementation of virtual desktops. Virtual desktops are something I simply cannot live without. Unix had it from decades, and I'm extremly happy to see them implemented by default and easily activable. Only little drawback is they lack a clickable preview on the menu bar or the dock. Virtual desktops lose a bit of usability if you can't see what's in them. Again, KDE (but also GNOME) here lead the pack.

Network management. As far as I can see, wireless and DHCP connections Just Work. Good.

Suspend. I still haven't understood what happens when I close the lid. Does it go to suspend-to-ram or suspend-to-disk? Can I choose? Can I freely bring the laptop with me without shutting it down? Probably it's just me not being accustomed to laptops, but OS X should give me a better control on this. However it works seamlessly, something that I doubt is on Linux.

Login screen. I haven't figured out a way to change the login screen background. Also, when choosing the picture login avatar, OS X doesn't rescale it if it's larger than the default, but allows only you to zoom it in. A minor detail, however.

General impressions. This review was much on the negative side, but it's a simple selection effect. What I had to say in detail was on the negative. There is a positive side, of course. OS X is a usable and decent workplace, and beats standard Windows most of time. Aestethically, it's really pleasant and day to day work can be done. The problem for me is that there is not much to be enthusiast about. If the OS X interface was one of the Linux desktop managers, it would probably be considered cool but not really superior.

What really I dislike of OS X is its "totalitarian" approach. Do you want a different skin for the window manager, an application menu, a different menu layout? Too bad, you can't. If you like the OS X way, all is fine. If you don't, Apple simply does not care. I know that third-party applications can overcome most of these limitation, but it's simply wrong that I have to look for third party, unsupported apps to do things that every other OS allows me to do by default.

Linux surely is still behind in terms of overall usability. Hardware support has incredibly improved but it's still flaky here and there, there are inconsistencies, things are not as perfectly polished as they should be. And Linux must be installed by hand, thus putting users in the realm of the unknown. However, from the interface productivity and usability point of view, Apple in my opinion has no more the high ground. They are more or less equal; strenghts and weaknesses being differently distributed but quantitatively not much different. It seems to me that now Apple has as much to learn from open source desktops as open source desktops learned from it.

Tuesday, 30 October 2007

A Linux user fights Mac OS X Leopard. Day 1

So, I finally have a laptop. I bought a brand new Macbook Pro Santa Rosa yesterday morning. I choose it as a laptop mainly for the hardware combination: decent screen width (15"), low weight (2.4 kg), good battery life (4-5 hours). Definitely not a cheap gadget, but once in a lifetime...

This Macbook is my first meeting with the Mac OS world. I have used DOS and Windows machines like everyone, and it's almost four years I use almost exclusively Linux on the desktop, both at home and in my laboratory (Gentoo at home, Kubuntu at work). So for me the Mac OS is the new thing, but I guess my perspective is a bit different from the usual Windows-to-Mac transition.

To be honest, I plan to install Gentoo Linux on the Macbook quite soon. No prejudice against Mac OS, but I like to run an open source operating system, and the customizability of Linux cannot be surpassed. But I want to dip my toes in Mac OS.

I fired up the feline beast and used it for about three hours yesterday. These are just my very very first impressions, so take them for what they are. Biased, ignorant, emotion-loaded.

0) Boot time. Incredibly fast. Being accustomed to minute-long Linux boots, I'm very impressed.

1) The graphics. Shiny, smooth and slick as much as possible. Everyone knows that. I like the icon design, even if it's maybe a bit too detailed -maybe equally good but less baroque icons could be made. On the contrary, the folders icons are so minimal to be almost useless. The "special effects" are light (nothing as fancy as CompizFusion can get) but well made, and Exposé is something really useful, as I found using Beryl/CompizFusion. A pleasure for the eye.

2) Finder. I have some beginner perplexity on the usability of Mac OS X Finder. To me, the finder sounds like a retarded concept. I understand it must be something like a desktop manager mixed with a file manager, but worse. For example, I expect that right clicking on the desktop brings up a menu. Ok, let's forget right mouse buttons in the Mac world. Apple+click. Well, it does nothing. To get to what we would call the desktop menu, you need to get to the Finder. Why?

The file managing part also looks quite terrible me. The Itunes-like preview is cool but pretty useless. The system seems at first sight to go to every length possible to hide what for me is a basic information: filesystem hierarchy. I want to see where is everything. I want control. I want to reconstruct paths of my things blindly. OS X seems to mangle this all. I am sure that applications are not in a folder like my music and pictures are. So, why putting them together? What's gained by doing that? And I'm sure the "Pictures", "Documents" and "Music" folders are somewhere in my filesystem hierarchy, they are not dangling. Why don't you show me where they are attached?

Actually, you can see it all clicking on "Macintosh HD". Still looks like a bit dumbed down information, but at least now I know there's a Unix-like hiearchy with Users/Massimo/ being my home folder. Good! That's what I like. Why don't you allow to show me a damn old good folder hierarchy tree on the left, Mr.Finder, instead of "Places"?

Problem is, I am accustomed with Konqueror. Konqueror, the default KDE file manager, is probably one of the applications that hooked me definitely to Linux. It's incredibly easy to use, customizable and powerful at the same time. It's one of that open source miracles that should be advertised much more. I am accustomed to switch between filesystem hierarchy tree view, list view, my storage media, Windows connections etc. all at one mouse click. I can split the Konqueror window in two, with two completely different locations together, or I can use tabs. Or both. I have immediate access to ftp, sftp and smb connections. I'm not sure Finder manages half of this all; I'll look for it.

3) Accessing to applications. Mac OS X , as far as I can see now, has no concept of an application menu. You get the dock, or you have to look for the application in the Applications folder, which mixes everything together. What if there are things that you don't want to see everyday in the dock, but you want to find easily when needed? Probably there's a way out, but I've still not found it (nor read about it).

4) Application menus. This is a well known Mac idiosyncracy: application menu bar is on the top of the screen. Period. I suspect there's some usability theory behind that, and after fifteen minutes it becomes indeed not so bad. Unless you have a little window on the bottom right of the screen and you need a menu on the top left, in which case you have to move the mouse in diagonal through more than half screen. Why, oh why?

5) Installing applications. I still believe that THE way to install applications on a system is using a package manager. Luckly Mac OS X has at least three available, so this will be no problem. However, I didn't dislike the .dmg approach too much. Download a disk image, copy application to Application folder, voilà. Easy enough (and much better than Windows), but I would like a lot to have an official package manager. Imagine looking for "Office" on a search bar, finding office apps you like (maybe even ones you would have never suspected about!), clicking on them, and voilà -they get downloaded from the net and installed. On Linux, this is commonplace. For proprietary apps, a PayPal button could be easily added.

6) Safari. Used it the time needed to download and install Firefox, so I can't really comment on it.

This is enough now, but I'd like to hear about opinions by Mac users and Linux users too. I'm sure I'm missing a lot of the picture, so I'm open for advices!

Tuesday, 18 September 2007

chm2pdf 0.0.3 is out!

Sorry for the long delay, but this little script is not dead. chm2pdf
0.0.3 is out: now with image support! (Intra-pdf links still dead, anyway. But I had suggestions on how to solve them.)

Download it here.

The script logic changed quite a lot, and it is still very rough
around the edges (0.1 is still -relatively- far). I'd like everyone of
you to test it as much as possible, since it is very likely that bugs
and quirks will occur. My knowledge of the CHM file format is
tentative at best.

Let me know how it works for you.

As for the xtopdf collaboration, I have to reconnect myself with the xtopdf developer to see. I'd like to have chm2pdf in a decent state (0.1) before, anyway.

Monday, 6 August 2007

chm2pdf merges with xtopdf ?

xtopdf is a neat collection of Python utilities currently in development whose aim is to convert every sensible document format into a PDF file. Nice project. I'm currently beginning talks with its main developer to see if my little chm2pdf can find a space in there..

In the meantime chm2pdf already recieved 31 downloads! Really unexpected success but only a little feedback...

Thursday, 2 August 2007

Announcing chm2pdf

Again in the world of interconverting formats, but this time it is something little I did myself. I had the necessity to print a CHM file but printing it page-by-page is of course painstaking. How I would have liked a PDF of that file... but how?

Well, I scratched my itch and I wrote a very little and raw, but functional CHM to PDF command line converter. You can find it here and it's called, quite obviously, chm2pdf. It is a small Python script that glues together chmlib (via pychm), pdftk and htmldoc. Installation and usage should be straightforward. Functionality is still pretty limited (images are still not converted, for example) but hey, it's version 0.0.2 ...

Let me know what do you think about it and drop me a mail for any feedback.

Monday, 30 July 2007

A little problem of GIMP printing and Kubuntu

Usually printing with GIMP is a no-brainer. Once you've installed Gimp-Print, you're ready to go.

On Kubuntu 7.'04 I found a tiny bug that can make things quite difficult. It happens that GIMP cannot find your printer -even if you correctly configure CUPS and Gimp-Print from the GIMP-Print gui. When you try to print using the default setting of "(Default printer)" you'll get the following error: "lp: Error - no standard target available".

For some reason, GIMP doesn't understand which printer is the default printer. What you have to do is:

- Setup your model of printer etc. on GIMP-Print correctly
- Have a look in /etc/cups/ppd and look for the .ppd files. There should be one corresponding to the name you gave the printer(s) when you installed. For example, I have a single file named HP_Laserjet_1300.ppd. Remember that filename.
- In the GIMP-Print dialogue, look for "Setup printer..." and click. Another dialogue will open. Now check the "Custom command" button and write the following line:

lp -s -d name_of_your_printer -oraw

and substitute name_of_your_printer with the filename you found before, without the .ppd extension. So if your filename is "myprinter.ppd" the line will be "lp -s -d myprinter -oraw".

Click "OK". Now you should be able to print. Try to see if you can save the settings -it seems it did it, but somehow after a reboot I had to do this again from scratch. Let me know.

Thursday, 19 July 2007

Installing the new Oxygen icons under KDE 3

KDE 4 is coming, and it is bringing a truckload of improvements and goodies. Among these, there is the brand-new Oxygen icon theme. Oxygen will be the default icon theme of KDE 4 and it is going to be damn good. Look at the preview to have an idea by yourself.

With a strange move for an open source project, KDE 4 is quite secretive about the new icon theme. The plan is to present the whole suite together, keeping Oxygen as a "novelty", so, even if Oxygen is being currently developed and most icons are already done, there are no official downloads provided for Oxygen. Moreover, the KDE 4 developers somehow "discourage" using Oxygen on a KDE 3 system.

However, Oxygen is open content (Creative Commons Attributions-Share Alike and LGPLv3 dual-licensed) and it is online in the KDE 4 SVN repository. So nothing legally prevents you to download and try the current Oxygen development version on your system.

It is not straightforward to obtain a KDE 3 -installable theme from the KDE 4 SVN repository, however someone (as often happens in the OSS world) has done the dirty work for you. After a bit of googling I found a handy script that automatically downloads the latest revision of Oxygen icons, converts them (using Inkscape for that purpose, so check you have it installed) and packages it as a theme (that is a single .tar.bz2 file) in your home directory.

The script is a bit slow, but works: basically just download the file from the webpage above, unzip it, open a shell, enter in the directory, run ./ as a normal user and wait. When it has finished, just look for the Control Center in your KDE menu and go through Appearance and Themes --> Icons --> Install new theme and open the oxygen-icon-theme.tar.bz2 file in your home directory created by the script. Voilà, theme installed.

How does it looks? Really professional and cool. I must admit however that it can look somehow out-of-place on a common KDE 3 system, so probably KDE 4 developers are right -to fully experience Oxygen, better wait KDE 4 at the end of the year. However, here is some screenshot for your pleasure: 1 , 2 , 3 , 4

Saturday, 30 June 2007

The best GNU GPL vs BSD comparison ever

Ok, this is not my work. But it deserves to be shared. Here is an OSNews comment about GPL vs BSD :

If you want to give your software away for free, use BSD. If you want to share your software, use the GPL.

Software under the GPL is not free. Microsoft office is not free, you have to pay Microsoft money. The Borland developer tools are not free, you have to pay Borland (or whatever they're called these days).

Lastly, software released under the GPL is not free: if you choose to copy and paste GPL code into your own program you have to share it. This is how you pay for GPL code. This is a very egalitarian idea: I share my code, and if you use it in your own program, you pay me back by sharing your code or else you ask me to relicense the code under a different license to suit your needs (which was always possible).

To make sure no-one can escape sharing (after all, this is how they're paying to use the software), GPL v3 requires the following

(a) You make the source code available

(b) You don't use patents to prevent people from using your code, which would effectively block code-sharing despite (a)

(c) You don't use DRM to prevent people from using your code, which would effectively block code-sharing, like (a)

The GPL is no more viral than any commercial license, the only difference is in how you pay to use the software. And it's always worth remembering that you don't have to share until you distribute the source-code (and as corporations are legal entities, you can give a copy to all your 1000-odd co-workers without legally distributing it). It's further worth remembering that if this is a problem, you can always ask the original author to re-license their work under a commercial license if you would rather not share.

This GPL is viral/evil/not-as-cool-as-BSD thing is rubbish. It does what it sets out to do: encourage people to share code. There's no excuse for "accidentally" using GPL code in your own software, just as there's no excuse for "accidentally" installing a pirated copy of MS Office on your friends PC. Both place value on software, and if you choose to use it in a certain way, then you have to pay for them: the only difference is in how you pay.

From Bryan Freeney.

Just an additional opinion: A lot of people bash GNU GPL because they feel it's too much restrictive. Disliking the actual concept of copyright, I feel sympathetic about them. However, what they often fail to grasp is that GPL is a licence made to mimick, in the copyright world, what would be a copyleft world. It is surely paradoxical the fact that the GPLv3 restrictions mean more freedom, but it's true, if you count the other's freedom as much as your one.

Thursday, 21 June 2007

How to open Thunderbird links in Firefox (or any other browser) under Kubuntu

I prefer Kubuntu over Ubuntu, because I just love KDE, while I can't stand the "dumb-it-down-at-all-costs" philosophy of Gnome. Nonetheless, I use a lot of GTK/Gnome apps in my desktop, and two I can't live without are the Mozilla's Firefox and Thunderbird.

However, Kubuntu sets Konqueror as the default browser. Not a wise choice IMHO (Konqueror is good but not as good as Firefox for a browser; it kicks ass as a file manager, by the way) but that's it. This means that when you click an URL in Thunderbird, it will open Konqueror. And there is no obvious setting to change it.

You have two strategies to let Mozilla Thunderbird play nice with Firefox under Kubuntu/KDE. The first -and more drastic, since it changes global settings- is to change your default browser to Firefox. To do that (straight from the Mozilla Zine:

* Open kcontrol (KDE configuration center).

* Go to "Components -> Components chooser -> Web browser".

* Check "The following browser", and type in "firefox" ("mozilla" for Mozilla).

If you don't notice the "Web browser" component:

* Go to "Components -> File association -> text -> html".

* Select "Add..." under "Application Preference Order".

* Write the command firefox %U (mozilla %U for Mozilla) and select OK. You need "%U" so you can load URLs that are non-local files.

Alternatively, you can change the setting only for Thunderbird. This is a bit more obscure, but even faster to do:

* Close Thunderbird.

* Find your Thunderbird prefs.js file -from the Linux shell, try using locate prefs.js | grep thunderbird.

* Edit the prefs.js, adding the following line at the bottom:

user_pref("", "/usr/bin/firefox");
* Reopen Thunderbird, et voilà it should work.

Thursday, 17 May 2007

EPS to PDF : how to avoid clipping

Again, the fancy world of interconverting formats. I had to convert a bunch of Encapsulated Postscript (.EPS) files (generated by Inkscape) into PDF pages, for work. No problem, I initally thought, there is ps2pdf that will help me.

Problem is, ps2pdf has the nasty habit to use a fixed page size by default, clipping everything that goes beyond the limits of the page. No matter if most of the drawing is outside the page: ps2pdf will silently and mercilessly cut most of it.

Added to this, ps2pdf documentation is bad by almost any standard. The problem is that ps2pdf is a script that relies on GhostScript, so ps2pdf docs are (mostly) GhostScript docs.

After almost 90 minutes of googling, I found what I needed. To convert an arbitrary EPS file into a PDF page of your standard GS page size, just type:

ps2pdf -dEPSFitPage file.eps file.pdf

Saturday, 24 March 2007

Bygfoot: an open source soccer manager game

I've never been a lot into gaming, so the relative lack of good Linux games never bothered me much. The only game I really loved was Civilization, and Freeciv is, for me, a perfect replacement for it. Sport games were usually the ones I disliked more. Nevertheless I remember myself playing a game called "Soccer Manager" on a DOS box when I was 10-12 years old. I enjoyed it, since it was a purely micromanagement thing. In that game you played the character of a football manager that decides the team formation, sells and buys players looking at their age and skills, maintains the stadium etc. You don't actively play football, like in "Sensible Soccer": you manage the football team.

It came to me as a nice surprise when I only recently discovered Bygfoot, a free soccer management game, was available on Linux. I decided to give it a spin and come back to my childhood memories.

Free Image Hosting at

Bygfoot is actively maintained and has recently hit release 2.1, with new features added at each release. It is based on the GTK toolkit. You can find precompiled packages for Bygfoot for Windows as well for most Linux distributions and there are official FreeBSD ports. The game has one playing as a manager of a football team, training the players, buying and selling them, contracting loans, maintaining the stadium, and so on. Teams can be promoted or relegated, and a player can be fired if their skills are not up to scratch.

I played some days with Bygfoot and my reactions are mixed. There is a lot of positive to say. The GUI is overall very well thought, elegant and simple; anyone that already played a soccer manager should master most basic game's controls in less than half an hour. I've tested versions from 1.8 to 2.1 on different machines and I'm pleased with the visible fast progress of development, both in terms of functionality and user interface. The number of teams available is enormous, thanks to many contributors, albeit the names are not 100% real due to "copyright problems" (I don't really understand that one, since it baffles my mind on how someone can have copyright on the names of players in a soccer team, but so says Wikipedia). The latest versions of the game are quite stable (the 1.9.2 version available on Ubuntu Dapper had a horrible memory leak, however) and at a casual look seem quite bug-free and fast.

Free Image Hosting at

On the other hand, the gaming experience is nice but not impressive. It must be said that Bygfoot is eerily addictive, at least at the beginning, and the game is well thought up to be both playable and challenging at first. However the game itself becomes repetitive too rapidly. There are not that much options to gain money apart from improving the stadium and waiting for people to come in or selling your players. Exchanging players with other teams, as far as I've seen, is not possible (if I'm wrong, tell me please!). The idea of the "Youth academy" is nice, but players coming from there take an excruciatingly long time to improve their skills as to be significant players. The recent addition of betting is nice but doesn't really spice up the game. More often than not the game is a repetitive "play match-play match-play match-substitute injured player-play match" with little or no user interaction.

Overall, Bygfoot is a good free soccer manager makes for a fun and well done casual game to play here and there, let's say, in breaks at work. However it is still not at the point to be a real challenge to spend your night with.

Thursday, 15 March 2007

Matlab-like interactive search in your Bash command history

You probably already know that to navigate forward and backward in time your command line history, you use arrows. Arrow up: previous command. Arrow down: next command. What if you have to navigate more?

For example, suppose you yesterday looked at a text file. You don't remember its name, but you know you used "cat" to see it. And now you want to see it again. Normally you should have to (a)use the up arrow a lot until you meet the command you wanted or (b)use some trick like cat ~/.bash_history | grep cat and then copy-and-paste the right command.

Good, but it could be better. The science package Matlab for example has a nifty feature that allows you to search in your Matlab command line intelligently, autocompleting the first characters you have typed with matching lines of your command line history. This means that you type "cat" on your command line, by using the up and down arrows you navigate only the history of commands beginning with "cat". A kind of interactive grep on the go. Nice, isn't it?

For some reason this really useful feature is not enabled by default on most Unix distributions I am aware of, but it is really easy to activate it on Bash. Look for a file called .inputrc in your home directory. If you haven't it, look for /etc/inputrc instead (you of course have to be root to edit this one). Open it with your favourite text editor and look for these lines:

"\e[5~": beginning-of-history
"\e[6~": end-of-history

Comment them with a "#" character in front of them:

#"\e[5~": beginning-of-history
#"\e[6~": end-of-history

Insert these lines below the ones you just commented:

"\e[5~": history-search-backward
"\e[6~": history-search-forward

Save and exit. To make the changes have effect you probably have to login again. Now pressing Page-Up and Page-Down should autocomplete the first characters you type with the corresponding commands in the history. Once you get accustomed to this feature, you'll never want to come back.

Wednesday, 14 March 2007

Small Linux tip: Companion controllers and USB hardware

Browsing the Gentoo forums I stumbled on an odd problem with one of these "easy-but-who-the-hell-would-have-thought-of-this" nasty solutions.

Symptoms: You connect a USB hardware (e.g. an USB scanner) and nothing happens. It seems it is not recognized. But you know that your scanner/printer/whatever works and it should work with Linux! (This often happens with SiS motherboards)

Solution: Check you have OHCI/UHCI support enabled. If not, enable it. Try modprobe ohci-hcd and/or modprobe uhci-hcd as root. If even this doesn't work, chances are you compiled your kernel by yourself (most distros should include OHCI): check in your kernel config you have OHCI enabled.

Rationale: The problem is that a USB 2.0 controller card is often coupled to OHCI (or sometimes UHCI) controllers, to deal with low or full speed devices, while the EHCI controller keeps the high speed devices for himself. The hardware switches controllers depending on the attached device. So if you only have EHCI drivers and your scanner switches to the OHCI/UHCI controller, there won't be a driver for that controller -and therefore, your PC cannot communicate with what's attached there. You can read the full explanation here, look for "USB 1.1. "Companion Controllers"".

Sunday, 11 March 2007

gTwitter 0.1: a Linux client for the Twitter social network

Twitter is among the last fads of social networking. For whose of you that don't know, Twitter is something in between a blog and an IM. It leaves you post a brief, SMS-like message (maximum 150 characters) that your Twitter friends can almost instantaneously read. Twitter is the place for every small idea, activity, thought you would like somehow to share, but that is not worth a blog post and you don't want to engage in a direct conversation about. It can be labeled among the best ways Internet has to distract you and make you absolutely non productive, but it is admittedly fun and somehow addictive.

Twitter has a relatively nice web interface, but it is often best used with a dedicated client. This is usually a small application, more like a desklet or widget, that periodically reads new "tweets" from your friends and allows you to instantaneously post a new one when you urge to. The most popular Twitter client is the Mac OS X Twitterrific, and there are analogous clients for Windows.

GNU/Linux and other free systems until a few days ago had little choice. This was even stranger and sadder given how simple the Twitter API are. I was just pondering about writing a Twitter client when I see that the 0.1 version of gTwitter, the first free, Linux-friendly Twitter client I am aware of.

I immediately downloaded the source code tarball .tar.gz and tried it. gTwitter is written in C# with Mono, and needs a few dependencies (The latest GNOME development packages (gtk+-2.8), A full Mono Development stack (mono 1.1.x, gtk-sharp-2.0, etc.) and the Cairo graphics library (cairo 1.0.x) ). On my stable Gentoo Linux box it compiled extremly quickly and without a hitch with the usual source tarball procedure:

  • download the gTwitter .tar.gz
  • unzip gTwitter:

    tar -xzvf gtwitter-0.1.tar.gz
  • enter the gTwitter source directory:

    cd gtwitter-0.1
  • configure the source code:

  • compile:
  • now become root (or use "sudo" on Ubuntu) and install:

    make install
  • exit the root shell by typing exit and just type:


    to run the program.

    Free Image Hosting at

    I played with gTwitter on my Linux box a bit and, despite its alpha status (just version 0.1, folks!) it seems to be perfectly usable for the main basic tasks of Twitter: reading and posting "tweets". The application is very small and fast and starts fantastically quickly. The GUI is very clean, and borrows a bit from Twitterrific: despite being GTK/Gnome based, integrates quite well in my KDE desktop. If you wanna see it in action , you can see a gTwitter screencast here.

    Of course, being a 0.1 release, it is still a bit rough around the edges. A notification area icon is, in my opinion, the first feature to implement, so that one can keep an eye on new tweets without having to open/activate gTwitter. A composite-enabled UI would be really cool, and the gTwitter author (Nil Gradisnik) tells on his blog that it is already in the works. Making the whole GUI smaller would also be nice, so to have gTwitter working effectively as a small, unobtrusive widget.

    Anyhow, gTwitter is a little but well implemented and promising application for Linux and other free software users that engage in this social network. I would advice twitters to give it a try without hesitation, and keep a look on its developments.

  • Wednesday, 7 March 2007

    Polar heart rate monitors on Linux

    Do geeks keep fit? Well, if you are a self-trainer, or you simply like to keep fit, you may find a heart rate monitor useful. Personal heart rate monitors often are thought to output their data on a Windows machine. Can you keep fit on Linux?

    The answer is: yes, but it's not that easy (but hey, mind exercise is still exercise!). In general, it seems the best supported heart rate monitors are the ones from Polar, so I will focus on that ones.

    Polar Viewer is a Polar (and Ciclosport, actually) heart rate monitor application that has been now integrated into Sports Tracker from the version 2.0. It seems the best choice for heart rate monitoring on Linux: it supports a quite wide range of Polar models, is integrated in a self-training application, it's currently updated and looks polished. As the Sports Tracker page says, "you can easily create diagrams and statistics for specific time ranges and sport types." and, if you feel coding, "all the application data is stored in XML files. So it should be easy to access it with other tools or to write importers and exporters for other applications.". Note: it depends on Mono. Another GTK application similar to Polar Viewer is Polar Scope.

    On the KDE side of things, I found a small application, KPersonalTrainer, that can help you sync with your Polar monitor. According to the description:

    KPersonalTrainer was developed to keep track of data collected by a heart rate monitor like the Polar Watches, or just any other watch.

    When you have added an exercise information is saved in a file and presented in a table. A calender is shown to give you an overview of the finished exercises.

    KPersonalTrainer also has an option, Weekly Reports, where you can keep track of your progress.

    This first version of the program has all the basic functions, and more advanced functions are planned for future releases, for example show diagrams of different data.

    . Unfortunately, the last update is of more than a year ago, but I guess you can poke the developer if you need an update.

    I found other attempts at using Polar heart rate monitors under Linux. They seem to be decidedly more hackish, but may be nonetheless interesting. A program to decode the sound data recorded by Polar S410 has been written: however keep in mind that it is a .tar.gz that needs to be compiled by hand and comes from the 2004. A Linux software for the Polar s710 that works via the serial IR interface exists and is updated. The author of this program also owns the (admittedly not so crowded) polar-linux forum.

    Last but not least: if you are really into the geeky thing, why don't you build a Linux-based heart rate monitor yourself? You only need a Linux PC, a soundcard and some circuit bending skills. Circuit schematics are ready for you to download, software is provided. Happy hacking.

    Create a Linux ram disk to use with an application

    If you have plenty of RAM memory, it may be useful to create a temporary RAM disk to use for fast file read-write of an application. Often guides tell you how to create an initial ram disk for the Linux boot, but what about building a ramdisk for everyday use?

    It's matter of just four commands. First, create the device:

    mknod -m 660 /dev/ram b 1 1

    Then, give the dimension you want to the new ramdisk, let's say, 4k. You do it by filling it with the right amount of zeroes:
    dd if=/dev/zero of=/dev/ram bs=1k count=4k

    Then it's just matter of creating your mountpoint:

    mkdir /mnt/ramdisk

    and mounting it as an ext2:
    mount -t ext2 /dev/ram /mnt/ramdisk
    That's it.

    Monday, 5 March 2007

    Busybox: a lifesaver for your Linux system

    Sometimes it just happens. You do something bad with, let's say, the glibc, and suddenly you discover your command line is unusable. Even simple commands like "ls" die with a segmentation fault or similar errors. Nothing works. More often than not, chrooting won't help. Everyone would panic, unless you know you have a lifesaver: a statically linked BusyBox.

    This little free software miracle contains stripped down but fully usable versions of many common UNIX utilities into a single small executable. A command line in a box. Its supported commands (actual support depends on compile configuration) include:

    [, [[, addgroup, adduser, adjtimex, ar, arping, ash, awk,
    basename, bbconfig, bunzip2, busybox, bzcat, cal, cat, catv,
    chattr, chgrp, chmod, chown, chroot, chvt, cksum, clear, cmp,
    comm, cp, cpio, crond, crontab, cut, date, dc, dd, deallocvt,
    delgroup, deluser, devfsd, df, diff, dirname, dmesg, dnsd,
    dos2unix, dpkg, dpkg_deb, du, dumpkmap, dumpleases, e2fsck, echo,
    ed, eject, env, ether_wake, expr, fakeidentd, false, fbset,
    fdflush, fdformat, fdisk, find, fold, free, freeramdisk, fsck,
    fsck_minix, ftpget, ftpput, fuser, getopt, getty, grep, gunzip,
    gzip, halt, hdparm, head, hexdump, hostid, hostname, httpd,
    hwclock, id, ifconfig, ifdown, ifup, inetd, init, insmod,
    install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute,
    iptunnel, kill, killall, klogd, lash, last, length, less, ln,
    loadfont, loadkmap, logger, login, logname, logread, losetup, ls,
    lsattr, lsmod, lzmacat, makedevs, md5sum, mdev, mesg, mkdir,
    mke2fs, mkfifo, mkfs_minix, mknod, mkswap, mktemp, modprobe,
    more, mount, mountpoint, mt, mv, nameif, nc, netstat, nice,
    nohup, nslookup, od, openvt, passwd, patch, pidof, ping, ping6,
    pivot_root, poweroff, printenv, printf, ps, pwd, rdate, readlink,
    readprofile, realpath, reboot, renice, reset, rm, rmdir, rmmod,
    route, rpm, rpm2cpio, run_parts, runlevel, rx, sed, seq, setarch,
    setconsole, setkeycodes, setlogcons, setsid, sha1sum, sleep,
    sort, start_stop_daemon, stat, strings, stty, su, sulogin, sum,
    swapoff, swapon, switch_root, sync, sysctl, syslogd, tail, tar,
    tee, telnet, telnetd, test, tftp, time, top, touch, tr,
    traceroute, true, tty, tune2fs, udhcpc, udhcpd, umount, uname,
    uncompress, uniq, unix2dos, unlzma, unzip, uptime, usleep,
    uudecode, uuencode, vconfig, vi, vlock, watch, watchdog, wc,
    wget, which, who, whoami, xargs, yes, zcat, zcip

    Quite impressive, isn't it? You can call busybox in various ways. The simplest is calling busybox directly with the wanted command as an argument:

    busybox ls /

    for example. But you can also enter a busybox shell by typing:

    busybox sh

    This starts a barebones shell that gives you access to all busybox commands, and allows you to have a working command line (On Gentoo Linux, you can have the same by calling /bin/bb, that is called the "rescue shell" in the docs). Another possibility is to symlink commands to the busybox binary. So, if /bin/ls is a symlink pointing to busybox, busybox will know the symlink called and execute ls. This of course has little sense when rescuing a system, but it is often used when busybox is the actual shell of an embedded or very lightweight Linux system.

    Having a static busybox (static is important: you want it to be resilient to borked libraries) installed could make the difference between crying in front of a dead Linux that needs to be reinstalled and being able to grin while telling again the geeky story about how you happily rescued your system. Install it now, before it's too late.

    Merge PDF files on Linux

    Sometimes you need to merge PDF files made by someone else in a single file together. Your Windows or Mac user fellows will do probably by using Adobe Acrobat or the like. On Linux you don't need the Adobe software (although you can have it if you like). You can do it by the command line -it's Linux after all, isn't it?

    The first method is by using convert , directly from the ImageMagick toolkit. You probably already have this one installed on your favourite Linux distribution; if not, almost every known Linux distribution has a package for it. Even if you don't need to edit PDF files you should have it, it is a wonderful swiss army knife for command line image processing. The syntax for merging PDF files is simple:

    convert file1.pdf file2.pdf file3.pdf out.pdf

    (that is, the last file name is the output file name). This usually works quite correctly, but 1)it is slow 2)I found sometimes has issues with image resolution. So I looked for another solution, and I found pdftk. The name stands for "PDF ToolKit", and really it is. It is a free (open source under the GNU GPL), wonderful command line utility that with a bit of magic allows you to manage PDF files from the command line. It works on Linux, Windows and Mac. pdftk can merge PDF documents, split PDF pages into a new document, rotate PDF Pages or Documents, decrypt and encrypt, fill PDF forms, apply a background watermark or a foreground stamp, burst a PDF Document into single pages... whatever.

    The syntax for merging with pdftk is almost as simple:

    pdftk file1.pdf file2.pdf file3.pdf cat output out.pdf

    You just need to add the magic "cat output" between the input pdfs and the output file name. In comparison with convert, it is truly fast and in my experience gives better results. And it may come handy for when I have to work with PDF files in other ways. Also, KDE users may find nice PDF Concat, a Kommander script that acts as a simple pdftk frontend to merge PDFs.