Back in Business

A burned video, a zapped hard drive and a corrupt RAM module later , I have now, finally, got my system running again (and no, my computer was not struck by a lightning).

For the fans of my Emacs package, I just uploaded a new release, and I will continue to provide weekly releases. Unfortunately, it seems, due to a licensing issue, Romain Francoise orphaned emacs-snapshot and its related packages. Therefore, this means I will have to work harder and fix packaging bugs myself, instead of relying on his bug fixes.

A week before I lost my system, I had promised a special Python quiz, in the issue #31 of Ubuntu Weekly News. I have not forgotten my promise. So if you’re one of the lovers my twisted Ubuntu quizzes, get ready for an awesome quiz. Date and time, when the quiz will be held, will be announced, as usual, in the #ubuntu-trivia channel on FreeNode.

On the final note, I would like to mention that will start posting more frequently on my blog. My current roadmap includes some cool tips-and-tricks, fun script recipes, more stuff about Ubuntu. So, stay tuned!

Bad luck

This week I wasn’t really fun. I first lost my video card — I now have a beautiful snow display. Then, I burned a hard drive in an attempt to access some of my data (luckily, it was my younger brother’s hard drive with his Windows installation). However, it won’t whine about it in a blog post; this isn’t my style.

I just wanted to notice the users of my Emacs package that I won’t be able to update it, until I get my system back on.

Tips on Emacs

Update: Please take the content of this post with a grain of salt. I wrote this at a time I was easily impressed. I still think Emacs is great editor, but it is not the only one. Look around, do your own experiments and pick the editor that fits your needs best. Although I don’t like the evangelizing tone of this post, I still believe in its conclusion: mastering an editor is an extremely worthwhile investment if you are doing a lot text editing.

Here a few Emacs tips and some gospel for those who are still using a butter-knife editor. First, the most important skill you must develop is touch typing. This is what make the most difference in your productivity. I found out that Emacs is really pleasant when you are able to type, at a rate above 50WPM. One thing is sure, being able to type fast, make any typing task more pleasant. From my own experience, when you get good with the keyboard, you start spending less time reading about other people achievements and start creating your own cool stuff. And learning to type fast is easy. Find some online typing material and spend 15 minutes per day, working on your typing skills. You will never regret it.

Most IDE do a lot of code generation, because some programmers are too lazy to learn touch typing. So, they need snippets, IntelliSense, automated refactoring, etc. They’re all nice features. But, do they really make you more productive? I don’t think point-and-click programming is really productive. That is where Emacs comes in. Emacs, and also Vim, are different in the way they attack the problem of rapid development. They both try to make editing easier, and this is a truly challenging task.

Emacs gives you the power to make your editor. Some people may argues that, this feature made Emacs an operating system. Yet, it is this flexibility that made Emacs so powerful. Almost all the commands in Emacs are coded with Emacs Lisp — a full programming language built in Emacs. Even the cursor behavior is coded in Emacs Lisp. How many of these point-and-click IDE have you seen, which allowed you to change how you move the cursor? I bet the number is near zero. An example of this power, is a mode called chop. This mode makes your cursor behaves like a binary tree. It allows you to reach any line on your screen in O(log2 n) steps, where ‘n’ is the screen’s height. In plain English, this means you can reach any line, on a 130 lines screen, in less than 7 keystrokes. However in reality, the number steps is much smaller, because Emacs has a full set of other tools for moving your cursor, where you want it.

Now the interesting part, how to get good with Emacs. Learning Emacs is the same thing as learning touch typing. You need to practice a lot and frequently. The first thing you need to master is the keyboard shortcuts. There is a lot of shortcuts, in Emacs. There’s probably more than your brain can hold. But with some training, we will see that Emacs’ keyboard shortcuts are easy to remember. They all follow the same structure. Like touch typing, there’s also tools for learning the keyboard shortcuts. I highly recommend keywiz, which run within Emacs. This tool analyzes all the keyboard shortcut in Emacs, even the one you changed, and generate quizzes about them. Again, same idea as touch typing, practice about 15 minutes per day on a daily basis.

As your journey progresses, you will find the need to change some of the default behaviors of Emacs. This is done by putting stuff in your .emacs — the most precious file of any Emacs user. Trust me, you don’t want to lose this file. So, make sure you do regular backups or use a version control system, like Subversion, to protect it. How to use this file is an art itself. Some people like to keep all their configuration in a single file, some don’t; some others don’t care if it’s messy, some don’t; and so on. Personally, I like to separate the different components into smaller files. And, I like to use customize for the on/off type of settings. But, that is just question of personal taste. There isn’t a better .emacs. The best one will always be yours. You will, although, want to see how the others configured their Emacs. That is normal. We are all curious creatures, after all. A final note about .emacs, don’t spend too much time playing on it. Configuring Emacs is fun and addictive, but it won’t help your productivity by much, if you can’t touch type or use the keyboard shortcuts.

The last, but not the least, thing you need to know, is Emacs Lisp. This is probably… No, this is the greatest feature of Emacs. And, it’s also the hardest to master. Learning a programming language is not the same thing as learning touch typing. Dumb practice won’t help you. You will need to sit down and think. Lisp, and all its parenthesizes, freak most people, who got some programming experience. Unlike some people says, Lisp is easy to learn. There’s nothing exceptional about learning Lisp. You learn it as any other programming language. Get a book, read it attentively, write some code, repeat. That’s my general algorithm for learning programming languages, and it works. I learned several programming languages, including Lisp, this way. One more thing, knowing Lisp do not make you a superior programmer. What makes you a superior programmer is your ability to learn new ideas. So, don’t get caught by this lie from Lisp evangelists.

Emacs is still a great tool, even if you don’t learn Emacs Lisp. In fact, many Emacs users never learn it and are still more productive than the majority of the other editors users. You can always copy-and-paste some Emacs Lisp code found on the web.

However, I haven’t said yet why you should learn Emacs Lisp. The reason is that if you know it, you can add features to your editor, on-the-fly, without even restarting Emacs. Did ever wished your editor had a particular feature? Well with Emacs, when you know Emacs Lisp, you just add it. Emacs evolves with you. So, if you do a lot of programming, you will end with a lot of programming helpers and macros. On the other hand, if you write a lot of web articles, you will probably end up with a lot of text manipulation utilities. It is just beautiful, how Emacs can adapt to your editing needs.

Finally, mastering a good editor is a lifetime investment. You better choose one that can evolve with you or you will end up using many different editors poorly. Remember, that being productive isn’t that important, but the fun of mastering something is. You will smile when you will transform a painful editing task into a trivial one. So, enjoy your journey in the world of Emacs.

Don’t use fake emails

<p>this is the error I get when trying to get your repositories</p>


<p>Please help</p>

I just got this comment, on my post Pretty Emacs. The error message was probably truncated by the HTML filter of WordPress. Unfortunately, when I tried to send an email to the author of this comment, I received a delivery error which told me that the author’s email address didn’t exist. So, I am stuck with a help request from a ghost.

I really care about the errors you get with the packages in my repository. If you stumble on a bug in one of my packages, it is my fault. And it is my responsibility to fix it. So please, don’t fake your email address when you leave a comment.

Daily links posting, not for me.

I disabled the daily links posting feature of I tried it, and I don’t like it. Posting links automatically on my blog doesn’t feel right to me. If I want to share a link, I will do it myself.

Debian Packaging 101 (Part 1)

Making packages for Debian derivatives (like Ubuntu) isn’t really hard. It just required some dedication to learn how the packaging system work. Yet, most users don’t know how to make packages for their distribution. In this series, I will try to give a brief introduction packaging.

First, I would like to tell you that, if you never compiled a program before, this short guide will be useless for you. Therefore, I assume that you know and that you did compile a program before. Also, I will use the term “package” to refer to the compiled program package ready to installed on Debian or its derivatives. And, I will use the term “program” to refer to the software, like “GNU Emacs”.

A package consists of two things: the source code of a program and a debian/ directory which contains information how to build the program. There is different methods to specify the packaging information. The most common one, and the one I will discuss here, is using a tool called debhelper. This tool makes the packaging process easier by abstracting the common packaging tasks into little scripts, run at the build time. The typical directory structure of a package looks like this:


Obviously, this example is simplified, but you get the idea. That are the interesting things for a packager. By the way, GNU Hello a good example of package to study. You get it with:

$ apt-get source hello-debhelper

Here, a quick description of the files in the debian/ directory:

  • changelog: The history of the package’s changes.
  • compat: A file that contains the debhelper version that is used.
  • control: The description of the package and the list of dependencies.
  • copyright: A copy of the licence the program uses.
  • postinst: A post-installation script used to setup things after the package has been unpacked.
  • prerm: Another script that is run before the removal of the package. It usually used to undo the things postinst has done.
  • rules: The instructions how to build the package. This is simply a Makefile.

In more complicated programs, there is usually other files. However, I won’t talk about them in this introduction. Anyway, I am out of time. In the second part of this series, I will explain the tools used to build packages.

Web Design Tips

Today, I been impressed how high my comment has scored on Reddit. So, I taught it would be useful to repost it, here, on my blog for future references.

First, learn how to write proper HTML without any IDE, like Dreamweaver. Or if you do, only use the code view. After that, embrace the web standards, but without becoming a fanatic. Finally, learn how to separate the structure of your web pages from their design with CSS.

In summary, to improve your website you should:

  • Rewrite it or do a heavy clean up job, without Dreamweaver’s design view.
  • Make it pass this test.
  • Fix all the links.
  • Learn how to use the <title /> tag.
  • Remove any animated GIF image and Flash applet (unless it helps to the comprehension of the content).
  • Fix the fonts. Try to use (or at least fallback to) either “web core fonts” or serif/sans-serif.
  • Replace the <font /> tags with their CSS equivalents.
  • Use tags properly (ie. only use <table /> if you really want to make a data table).


Pretty Emacs

Update: If you are using Ubuntu 8.04 LTS “Hardy Heron” or Ubuntu 8.10 “Intrepid Ibex”, use the packages in the PPA of the Ubuntu Emacs Lisp team, instead of the packages referenced here. For Ubuntu 9.04 “Jaunty Jackalope” and newer, use the packages in Ubuntu repositories.

Emacs is my editor of choice. In fact, I should say it’s my framework of choice, but that’s for another post. Until recently, I disliked the poor font backend of Emacs. So, I was always using Emacs within a terminal window to get a decent looking interface. However, this grungy font era is over, since Emacs’s hackers added recently to my favorite editor a XFont backend, thus making possible to use good looking fonts, like Bitstream Vera Sans Mono.

Screenshot of Emacs with XFT support

I made a package that makes the installation, as painless as possible. So, feel free to use it. However, please note that this is an alpha release of Emacs, therefore it should only be used for testing. (From my experience, it’s rock solid.)

Still interested? Then, here the instructions. First, add my repository into your software source list, by adding the following lines to /etc/apt/sources.list:

deb feisty main
deb-src feisty main

If you are running Ubuntu 6.10 (Edgy Eft) or the current development version of Ubuntu (Gutsy Gibbon), change feisty for edgy or gutsy.

Finally, run either apt-get or aptitude to fetch and install the packages:

sudo aptitude update
sudo aptitude install emacs-snapshot emacs-snapshot-el

Now, you need to specify the font you want to use in your Xresources file.

echo "Emacs.font: Monospace-10" >> ~/.Xresources
xrdb -merge ~/.Xresources

Here, I use the default monospace font, but any other monospaced font should work too. For example, if you want to use Lucida Sans Typewriter instead, change Monospace-10 for Lucida Sans Typewriter-10 in the above command.

And that’s it! Now, launch Emacs and enjoy the good looking fonts.

If you need support with the package, just email me at

Update: Il y a, maintenant, une version en fran├žais de ce guide sur le wiki de Ubuntu-fr.

The secret of Ubuntu success

Ubuntu has been my first distribution of Linux. I learned everything I know about Linux, on Ubuntu. However, there is a question that has been bothering me for a while: “Why Ubuntu is so successful?”. It took me some time to find the answer. The answer is simple, we are nice to new comers. We don’t try to prove anything to them; we just help them. (Of course, being the best distribution out there helps :) )

The slogan of Ubuntu, “Linux for Human Being”, took all its meaning when I finally understood that. We are the humans. We aren’t supposed to work for the computers. They are the ones supposed to do the work.

That brings me to the second reason of Ubuntu’s success. We are making Linux works out of the box. Users shouldn’t need to have to read a 10,000-pages manual just to use Linux. Not because I read the manuals, everyone should. Of course, we need all those friendly howtos and guides. They make Ubuntu so much more fun to use.

I think we need to continue in that direction. Sure, translucent windows are cool, but we should always remember the roots of our success.

Understanding Linux File Permissions

File permissions are probably one of the biggest difference between Windows and Unix-style operating systems. They make Linux much more secure when they are well used. However, they can also cause nightmare to the casual Linux administrator.

The first thing you need to know is that a Linux system has two way of classifying users. There is, of course, the user name, but there is also groups. Groups are, strictly speaking, only a way to share permissions between the users. For example, all the member of the admin group on your system is able to use the command sudo. As you probably know, sudo allows you to run a command as another user (by default, the root user).

Let me introduce you to your command-line friends that will help you to manage the permissions of your system.

  • adduser: This command let you add new user on your system. It can also add a user into a group.
  • addgroup: Its name says it all. This command let you add new group on your system.
  • chmod: I believe this is the most widely known Unix command. It is even a verb in the world of server-side technology, like PHP. This command let you alter the permissions of a file. It is a swiss-army knife. Learn it, and use it well.
  • chown: Also a very important command, chown can change the user and group ownership of a file.
  • chgrp: This is chown‘s little brother. Unlike chown, this command can only change the group ownership of a file.
  • groups: Somehow less important but still useful, groups shows you the groups you are a member of.
  • whoami: Don’t know why, but I love the name of this command. Anyway, this command tells you who you are.
  • who: This command shows you who is login on your system. I never use it, since I find w more useful for my usage.
  • w: And here our last little friend, the w command. It displays a list of the logged users like who, but also display their attached process and the uptime of the machine you’re on.

Obviously if you want to learn to use those commands well, you will need to do some homework and read their respective manual pages (with man <command>).

So, how permissions work? First, we need an example:

alex@helios /etc % ls -l
total 1548
-rw-r--r--  1 root   root      2584 2006-11-29 08:40 adduser.conf
drwxr-xr-x  4 root   root      4096 2006-12-13 10:46 apt
drwxr-xr-x  2 root   root      4096 2006-12-17 00:15 cron.d
drwxr-sr-t  5 cupsys lp        4096 2006-11-29 08:51 cups
-rw-r--r--  1 root   root       817 2006-11-29 08:39 fstab
-rw-r--r--  1 root   root       806 2006-12-17 00:15 group
-rw-r--r--  1 root   root      1430 2006-12-17 00:15 passwd
lrwxrwxrwx  1 root   root        13 2006-11-29 08:40 motd -> /var/run/motd
drwxr-xr-x  2 root   root      4096 2006-12-22 23:36 rc0.d
drwxr-xr-x  2 root   root      4096 2006-12-19 12:06 rc1.d
drwxr-xr-x  2 root   root      4096 2006-12-19 12:06 rc2.d
drwxr-xr-x  2 root   root      4096 2006-12-19 12:06 rc3.d
drwxr-xr-x  2 root   root      4096 2006-12-19 12:06 rc4.d
drwxr-xr-x  2 root   root      4096 2006-12-19 12:06 rc5.d
drwxr-xr-x  2 root   root      4096 2006-12-22 23:36 rc6.d
-rwxr-xr-x  1 root   root       306 2006-11-29 08:40 rc.local
-rwxr-xr-x  1 root   root       306 2006-11-29 08:40 rc.local
-rw-r-----  1 root   shadow     873 2006-12-17 00:15 shadow
-rw-r--r--  1 root   root       214 2006-12-02 13:27 shell
-r--r-----  1 root   root       403 2006-11-29 09:10 sudoers

Only the first, third and fourth column are interesting for us, right now. The first column gives us information about the file permissions. The third is the owner of the file and the fourth is the group.

So, what all this mess means? File permissions are like little switches you turn on and off. There is three types of permission: read, write, and execute. There’s also three types of ownership: owner (or user), group, and other. So, 3 times 3 equals 9 switches you can control.

That is exactly what we see in the first column. The first element of this column is the type of the file. A - means it’s a normal file; a d is for a directory and l is for a link pointing to a file. There is several other types of file, but they are much less useful to know for the casual Linux system administrator.

You probably figured that the rest are the permissions. Here a legend of the symbol I will use for the rest of this post:

u - owner
g - group
o - others

r - read
w - write
x - execute

t - file type

As you will see, there is nothing complicated about the first column in the output of the ls -l command. It’s a simple representation of the switches I mentioned earlier. So, let’s decrypt it:


That’s it. Just read it out loud: type, owner, group and others. So, if you see something like -rwxr-xr-x, you can read it as: “a normal file which the owner has the read, write and execute permission and which its group and others has the read and execute permission.” That is extremely verbose, but correct.

You can change the permissions with the chmod command:

alex@helios ~ % ls -l file
-rw-r--r-- 1 alex alex 0 2007-01-01 23:58 file
alex@helios ~ % chmod og+rw file
alex@helios ~ % ls -l file
-rw-rw-rw- 1 alex alex 0 2007-01-01 23:58 file

I won’t go in details here, because it’s quite simple to understand. If you want to know more, The info page of chmod is a great source of information (info coreutils ls).

If you already knew what are permissions, you are probably 1) rolling on the floor laughing, how I gone into the great details of that simple thing, or 2) grumbling that you want a refund because I wasted your bandwidth. So, hold on here the more advanced stuff.

You probably saw numerical (or should I say octal) permissions, like 777. But, do you actually know how to read them? For example, what 645 means? Hopefully, you aren’t trying to remember all of them. I going to give a trick.

As you probably know, each digit represents the permissions of one type of ownership (owner, group and other). One thing you need to know is they are not decimal digits; they are octal digits. So, something like 855 is not a valid permission.

Now, here one interesting property of octal digit: you can write them all as three bits (binary digits) number. Here the full list:

Octal   Binary
0       000
1       001
2       010
3       011
4       100
5       101
6       110
7       111

As you may know, bits are like switches you flip on and off. Sound familiar? Right, they are exactly like permissions. Now imagine that instead of letters, the permissions in the ls -l were shown as binary numbers:

alex@helios ~ % ls -l file
-110100100 1 alex alex 0 2007-01-01 23:58 file

110100100 is a perfectly legit binary number and in octal it is 644. So, what happens if we chmod our file to 644? You certainly deduced it:

alex@helios ~ % chmod 644 file
-rw-r--r-- 1 alex alex 0 2007-01-01 23:58 file

Pretty nice, eh? You been working with the binary system without knowing it. Back to our problem, you need to change the permissions of a file to 645. So, how do you calculate what it means? That is simple, now that you know it’s just a binary number:

Binary  Octal  English
100     4      read
010     2      write
001     1      execute


owner: 6 = 4+2 = read+write
group: 4 = 4   = read
other: 5 = 4+1 = read+execute

So, let’s check if we were right:

alex@helios ~ % chmod 645 file
alex@helios ~ % ls -l file
-rw-r--r-x 1 alex alex 0 2007-01-01 23:58 file

I bet you didn’t know it was that simple. Now, you can show to your geek friends how good you are by calculating any octal permissions in your head.

There is also some special permissions you can use too, like setuid, setgid, and sticky. I won’t cover them here, because they are pretty useless to the casual Linux system administrator.

I hope you enjoyed this introduction, because that’s all folks!