Welcome to my blog. Have a look at the most recent posts below, or browse the tag cloud on the right. An archive of all posts is also available.
Debian/Ubuntu index | Misc. index | Emacs index | Books queue | Article queue | Technorati Profile
This is a limited-access IkiWiki. You should be able to add comments in the "Discussion" pages, but not create page randomly like you can usually do in wikis. For more personnal comments, write to neumann@lostwebsite.net.
I'm a big fan of GNU Emacs. It's a very good programming editor but tends to be much more then that once you start digging into its feature and extensions people have spent a lot of time to write.
This makes Emacs quite unique in the world of generic text editor. Emacs users very often have their editor fired and ready to go. It might be because they always have a file to edit; programmers do that. It might also be because they use some Emacs extensions to fill-in for other programs like their IRC or mail client, like I do.
For me Emacs is always on. I can use it for most of my editing tasks by using the remote controller gnuclient.
What I could not use it for, and which annoyed me, was that I couldn't edit files owned by root inside Emacs opened as my current use.
Luckily, somebody on Planet Emacsen lead me to discover you can use TRAMP to edit files using the 'sudo' method. TRAMP enables you to access remote files from inside Emacs, like on an FTP or SFTP server, for instance. The 'sudo' access method, in that case, is just a twist of the concept, allowing you to edit files as another user on your own system.
TRAMP comes standard with Emacs 22. I personnaly use Emacs 23.something on all the computers I use, so I have not personally tested it on Emacs 22 but I have the feeling it should work fine.
To open a file as root, for example, do:
M-x find-file, /sudo::/etc/motd
And, TA-DA, it might work out of the box like that!
Yes, might. On my systems, I prefer to use ZSH. The prompt I use, and a ZSH-specific feature, conflict with TRAMP default configuration. TRAMP loads a shell with sudo in background and needs to see the shell prompt to make sure its able to send editing commands. So to be able to use TRAMP, I had to change the prompt for Emacs, or make TRAMP recognize my active prompt.
Changing the prompt is easier than it look, and can be made into a special-case for Emacs. TRAMP set the TERM environment variable to 'dumb' when it loads the shell. Since the dumb terminal mode is not something I use or want to use, I just did something like this in root's .zshrc:
if [ $TERM = "dumb" ]; then ... unsetopt zle PS1='$ ' fi
'$' being the cannonical UNIX shell prompt. The unsetopt
zle disables the feature that might conflict with ZSH.
Small update. I have added a Book queue page. I hope I'll find the motivation to keep it up to date.
I also want to maintain an Article queue to queue up the academic article I want to read. This one will be harder to maintain.
Posted Mon Aug 25 20:38:08 2008Hello, world
I would just like to point out that my company has a blog.
As it is custom to say in that situation, please note that I don't necessarily agree with everything that is written there.
Posted Fri Feb 1 08:58:09 2008This is for the record. As I write this entry, I no longer use this technique.
For no particular reason, I've always wanted to receive emails directly on my computer through SMTP. For readers not familiar with how SMTP works, let's just say that SMTP is a postman able to deliver your emails to the post-office, but that is also able to deliver emails directly to your door.
People have got used to get their emails through a Post-Officile Protocol (POP3). You can also use IMAP for the same purpose but it doesn't really fit my metaphor so I will not talk about it. The SMTP postman can also knock to your door (port 25) and deposit the mail right at your computer if you let the rest of the Internet know you want to receive your mail that way (through MX records).
Using a cheap ISP with a dynamic IP address is like changing the door address every so often. Nobody out in the Internet really knows where you live at any point. You can mitigate that by using an handy dynamic DNS service, which I do, but it's not like having a permanent home with a domain that everyone knows about.
Also, Sympatico, my ISP, blocks port 25. That means nobody will every be able to knock at my door. I can't let the whole Internet know that I should receive mail at port 10025 for example.
There are some service that can receive mail for you then route it to the correct port. The prices vary with the features provided by the service. I have not seriously considered paying for something that I can find no practical advantages to.
Nonetheless, I still wanted to receive mail from the Internet directly on my small network, without needing to switch to another ISP.
I successfully received mails from the wide Internet yesterday.
What you need is:
- An Email Service Provider that lets you use procmail and a dumb SMTP sender.
- A SMTP server listening on an alternative port that is not blocked by your ISP.
- A simple procmail hack.
The provider
I use HCOOP. It it my Hosting Provider, and Email Provider, and Pretty-Much-Everything Provider. It's quite cheap and very flexible. It doesn't have any big uptime guarantees and expects a below average knownledge of Apache and DNS configuration but I can deal with that. In fact, I love to deal with that.
So the provider was not a problem for me. Other hosting solutions might not provide you with the possibility of using procmail at all.
The SMTP server
I use Postfix on the receiving computer. It defaults to port 25 of course. All I needed to do in order to make use another port was to edit the /etc/postfix/master.cf file, find the line describing the SMTP service, and change the service the port number you want Postfix to listen on for SMTP requests.
The dumb SMTP server
Some places call that a nullmailer. This is a SMTP client that is just meant to send a mail to an SMTP host.
My provider already had ssmtp installed. I also looked at esmtp for inspirations. There are probably several variants of such software out in the Internet.
The procmail hack
I did not find this verbatim on Internet, but I'm pretty sure you can find several variants of that through Google.
:0wc
| formail -k -X "From:" -X "Subject:" -X "To:" -n 3 -s \
/usr/sbin/ssmtp -Cssmtp.conf your@email.com
This rule basically tell procmail to send all mail through a pipe starting with the formail program. formail is used to format a mail message before further processing. The switch I pass it tells it to remove all headers but From and Subject from the mail before calling ssmtp. ssmtp.conf is the configuration file for ssmtp. I won't paste it here since it's quite trivial and anybody interested in using it will figure out what to write there from the manual page.
This is probably not an exhaustive shopping list of how I got it done, but without those basic blocks, you wont get it done.
Once I got that working. An avanlanche of problems and potential problems made me realize that this was way much troubles that it was worth.
- It meant that I needed to keep the receiving computer running at all time, and I don't have the infrastructure for that. I have no UPS and no backup system
- That computer as limited capacity so I could not have used it has an store for emails, at least, not for every long. So I needed to send the mail to a computer that is more capable inside the network. That means I need to learn to configure Postfix, something I would certainly enjoy but that I don't think is worth spending time on.
- Finally, the the formail command line I describe above is probably incorrect since the email I was receiving were partially munged, in various ways.
In short, such acrobatics with emails was too much trouble for me. It doesn't mean I could not have made it work, but that the energy needed to make it work correctly was too much for the value of the end-result I was after. I write this entry as a statement to say that I will spend time trying working on this again, unless I find a reason better than "It'd be cool!".
Posted Sun Jan 27 13:47:27 2008Wow, Tom Dryer, is certainly the mose useful blogger on Planet Ubuntu Users.
He has found a way out of the main problem I have with KDE 4.0: the "huge taskbar". My current setup has shown me how to perfectly function without a taskbar.
I could even live without shortcut buttons or desktop switcher and only ever use keyboard shortcuts. The only thing I can't live without yet is the system tray.
So thank you Tom. You will make me retry KDE 4.0.
In the meantime, I would like to ask what the Planet Ubuntu Users would like me to blog about. I know I have many subjects I could blog about but it seems to me there is a lot of good informations everywhere already. I don't like duplicating efforts if I feel it will benefit nobody. On the other hand, if someone explicitely ask questions, it gives me more of a reason to write about something because I know at least the person that asked the question will read.
Posted Tue Jan 22 13:06:44 2008New year
Happy year 2008. I would like to say that blogging more often is not one of my formal resolve for the year.
I will be happy if I consider I'm still blogging by the end of the year. All my other attemps at blogging regularly have failed.
KDE 4.0 has been released
Everyone following tech blog know that KDE 4.0 has been released this friday. I'm quite happy about that since I've been a KDE user since I'm full time on Linux. What has changed over the years is that I'm not longer a strong KDE advocate. I will always prefer KDE over GNOME, but I can't say I would argue strongly for KDE against GNOME. Both a 2 very complete and excellent desktop environment.
The following is my opinion on KDE 4.0. I have tested the Ubuntu Gutsy remastered LiveCD for KDE 4.0. I'll admint it's probably not a complete experience of KDE 4.0, but what I've seen is enough for me to say that I will not use KDE 4.0 until a while.
I don't understand people saying they don't like KDE because it looks too much like Windows. I don't really care about how my system look if there is a good operating system under the hood.
The look of the environment for me is not a good reason to dislike a desktop environment, be it GNOME or KDE. I've got good reasons to dislike GNOME, and most people probably have good reasons to dislike KDE.
Both environment can be themed to change several aspects of their graphical appearance. Also, you can change components of the system until you find the look that suits you. Once that is done, you are left with what really matters in the environment: the quality of the software suite. That is, I believe, the only worthy point of comparison.
The subject has already beaten to death so I'll keep the following short. This is not an exhaustive list of my opinions about KDE.
The good: it's KDE 4.0
KDE 4.0 is the next step for the KDE environment. It will get all the development and all the cool apps. If I stick to KDE in general, I will eventually use KDE 4.x, but maybe not KDE 4.0.
The bad
Unstability
I expected nothing else of KDE 4.0. It's a dot-zero release and thus as many shortcomings and bugs.
When I tried the SuSE LiveCD for KDE 4.0, I badly wrecked my system to the point I had to shutdown my virtual machine. Don't ask me what happened, I don't remember. It was with an older version anyway.
With the Ubuntu LiveCD, Gwenview crashed twice, one time right at the moment it was starting.
This is not unexpected. I'm used to living on the edge with very recent software so I am familiar with applications crashing. Sometimes I will even fire-up the debugger and try to fix the problem.
Lack of KMail
I'm a KMail user. I know I could use KDE 3.5 KMail in KDE 4.0 yes, but I can also run KMail in KDE 3.5.8 too if there is not more reasons to switch to KDE 4.0.
The ugly
There is one thing that keeps me from using KDE 4.0 right now. If someone instructs me how to fix that, I'm a taker.
The huge taskbar
It's huge. Like, 5 times the size I would want it to be. To maximize screen real estate, I have configured my KDE 3 kicker to be minuscule. It's current 630 pixel wide, and just 30 pixel high, on a 1600x1200 19 inch screen. There is no taskbar, just the system tray, a small set of shortcuts icons, the clock and the desktop switcher. I've become used to switching between tasks using Ctrl+Tab and other shortcuts.
I'm not gonna install KDE 4.0 packages and run a KDE 4.0 session on my system until this taskbar can be shrinked to the size I want.
Posted Sun Jan 13 23:17:58 2008On life right now
Oh boy, I'm dead tired.
Christmas vacations are closing in. Tomorrow my girlfriend, my daughter and I are going to see our parents and grand-parents which live a little east from where I live. It's a three hour drive, a short trip, but we plan to stay 10 days. Parents will know that this require to pack-in a lot of stuff, mostly for the baby.
I find it ironic that a 12 pound baby requires to carry as much stuff as two grown adults. And that's just "life support". We don't carry much extra things around.
Luckily my girlfriend is better than me at organizing, otherwise we would end up with pretty much everything missing.
It's unlikely you will see technical post here until I get back.
Projects
I have not had time to think much about the idea I was to write about some posts ago. My goal is to keep this blog on a technical blog, so I will try to summarize that idea here instead of waiting to have time for a bigger post.
I have started playing around with the little known ptrace syscall on Linux. My idea is to code a programmable variant of strace.
strace is a tool that allows you to see what system calls a program do on the Linux kernel. System calls are the functions in the kernel that can be used by the user program to do things. You might already know that it's not the GNU Libc that write on the disk. The kernel does. The libc, and other libraries, uses system calls to tell the kernel to write on the disk. That means if you know what system calls a program use, you get a pretty good idea what it is doing.
That's strace, in short. I could write a whole article with example and such but I'm sure there are better writes that already did so go it Google.
Since I've started coding under Linux, I've always found strace to be one of the most useful development tool available. It's actually useful beyond programming tasks. I have used it more than often to get more useful error message from malfunctioning programs.
What annoys me with strace though, is that it's sometimes very painful to extricate information from the thousands of calls done by a program. There is a lot of noise in a strace output.
With a programmable strace, I would like to be able to intercept just the information what I want, and do the interpretation of the data programmatically.
The most striking example of what I think is to track file descriptor leak. There are few system calls out there that return file descriptors. File descriptors are a limited resources to the process, and if they run out, the process will probably cease working.
Determining that file descriptor leak happen is easy. All you have to do is count the number of files in /proc/pid/fd.
Finding what is leaked, what it was used for and in what circumstance the file descriptor is leaked might be more complex. That is usually something I manage to accomplish with strace.
It would be faster to write a small program in an high-level language that could trap the system calls that return file descriptors and log what happens.
That's the idea that made me think about that project. That and the fact that it would be fun to code that.
What I need to investigate further is if I can do more than simply spy the program. If you can change return values of system calls, you can submit programs to a lot of strange error conditions. It would be easy to simulate a full hard-drive, for example, without needing to patch the GNU Libc. All that would be needed is a short program telling what to return when a child program calls the write system call.
That text is probably confusing as hell to users, and non-developers. Don't worry. If I find the idea implementable and useful, and if the projects takes off, I will certainly blog about it again.
Posted Fri Dec 21 22:44:43 2007I have posted a Debian bug about the problem I have had with VMWare and the Awesome window-manager.
Turns out that the shortcuts only works when the mouse is not over the VMWare virtual screen. That means it is less annoying than I first expect, but still annoying nonetheless.
JD was nice in installing VMWare to diagnose the problem. I know some developer who would not have bothered to install such a big piece of proprietary software to debug a problem which probably annoys just one person, me, in the whole world.
VMWare is a critically important tool for us at work. I'm not gonna get into details of why and how we use it. It will be better left as the subject of another post. I don't feel I need to justify the bug I posted, but it is very important for me that I'm able to use this tool efficiently in my development environment.
Posted Fri Dec 14 09:39:43 2007awesomeness in a package
I had a overly involved articles to write about an idea for a project I have. Unfortunately, I have had no time to sit and write about it.
Instead I decided I would try Julien Danjou's Awesome Window Manager.
First I must say that I felt weird installing awesome through apt-get (apt-get install awesome). One would expect that awesomeness would have been harder to install. It also feel strange to write about. Then I realized you could also install happy in Debian. There is no funny or sad yet though.
I have something for the potential effiency of tiling window manager. I somehow feel that if I can get used to one of them, I'll be terribly efficient around my desktop. Whenever I try one of them, I usually come back to my sense. Getting used to that whole new key map usually take more patience than I have.
Objectively, awesome is a nice window manager. It's sober and fast. It took a short while for me to be able to know enough keys to find my way around it.
Mod4
awesome uses the 'Mod4' modifier by default. Once I got awesome started, it struck me that I did not know what "Mod4" was. Turns out that on my setup, 'Mod4' is bound to the Windows key. It is a nice thought from the other to get that key to some use.
Zsh job control
Zsh, my current shell, does not do job control the same way I remembered Bash did. If you fire a shell in X, start a graphical app, then logout from the shell, Zsh will tell all the application to shut themselves down. I tried Bash, and apparently it does not do that, or it is being smarter with it.
Floating windows
I knew it because I once used Ion, but I would like to point out that Awesome, just like Ion, can also deal with floating window just fine. Awesome is also pretty smart about small pop up window, and displays them as floating window instead of tiling them just like applications window. I vaguely remember not seeing that with other window manager although I could be wrong.
Thunderbird/IceDove
This ** program doesn't like being tiled. It seems I have to run it in a full screen window.
System tray
Being a minimalist wm, Awesome doesn't have anything that can hold system tray applications. This doesn't mean much too me at work, but it's a big drawback for my computer at home, on which I run several applications that feel at ease in a system tray. Pidgin is probably the best example of such application.
I know there are probably some ways to hack around it, just like there are some alternatives to Pidgin, but that means using up more of the little patience I have.
VMWare
Really annoying bug. VMware console shortcut keys don't work when VMWare is run with Awesome. It certainly deserves a bug report as it is the reason I can't be using Awesome. I see tiling wms as a way to free myself from the mouse by using mostly the keyboard. VMWare being one of my main work tools, I cannot afford to switch to a wm that would keep me from using it in a efficient way, even if the wm is generally efficient for everything else.
After I write this, I will logout from Awesome back in my KDE setup where VMWare shortcut keys work.
Posted Wed Dec 12 10:17:05 2007Hello, Planet Debian Community,
I see my feed got merged to the Debian Community English Planet feed. I did not expect it to pull my old posts, but that's good enough.
I was looking audience because I had big troubles pushing myself to update my blog when I knew the only reader I had was the Google Bot. I write this blog to improve my writing and possibly argumentation skills so it's hard to improve without any audience or reactions.
I will mostly blog about what I do with Debian and Ubuntu here. I'm not a DD or a Ubuntu Developer in anyway. I'm only marginally involved with both, but I work on projects derived of both of distributions at work. I would like that work to be open and public and but it's not and so I cannot really talk about it.
But, I still learn a lot doing what I do at work. What I learn is mine and I will share it through this blog.
If you think my writing is strange, it's mostly because I'm not a native english speaker/writer. My native language is french as my name may let you think. I'm open to advices to improve my writing.
Posted Mon Dec 3 10:54:59 2007