Older blog entries for Raphael (starting at number 35)

Features and remote controls

Jimmac posted a very interesting journal entry about “more features” and a comparison with remote controls. I thought about it a bit and started typing a comment to his blog, but as it grew longer and longer I decided to move it here so that I have a bit more space…

This nice comparison with a remote control made me think about how I use mine. The device that controls my TV (and VCR) has a little flip hiding the “advanced” buttons. I do not have a photo of my remote control, but I found one that is reasonably similar. The top part until the red power button can be opened to reveal more buttons.
(photo of a remote control)

The basic buttons such as channel selection, volume and start/stop for the VCR are always visible. If you lift the flip, you get extra buttons for selecting input sources (e.g., DVD player or camera) or outputs, changing the parameters of the display and other exotic stuff. As it turns out, two of the “advanced” buttons on my remote control are as worn out as the channel and volume selection buttons that are among the “normal” buttons. So I am very glad that these buttons exist, otherwise the device would have been far less useful to me. On the other hand, I understand that they are hidden under a flip because some other people (whether they are a majority or a minority is irrelevant) would probably never use them. Even myself, I do not need to see all buttons all the time.

The comparison with this little device that I use almost every day is very interesting to me. And I take some lessons from it: the designers of this device could not predict which buttons I would use most frequently. They modeled this device for a slightly different class of users, yet I enjoy using it because the “advanced” buttons that I need are still within reach when I need them.

In case you cannot guess where I’m heading yet, let me add that the “advanced” buttons are not visible by default so that they do not confuse those who do not need them, but they are easily discoverable and once you get to them, they look and behave exactly like the other buttons. I do not need to open my TV and flip a few DIP switches to get to the advanced options. Translated in the GNOME or GIMP world, this means that I would have a default set of features that I can play with but also some advanced settings that are easily accessible from the application without having to resort to some other obscure tool such as a gconf editor.

I do not really need to have “everything at my fingertips” and be confused by huge configuration dialogs for every little feature. In fact, I prefer to have the less frequently used options hidden away, as long as there is an easy way to access them whenever I need them. It is essential for these advanced options and features to be discoverable, so the dialog that contains the basic options should give a visible hint that more stuff exists but is hidden (using an expander for the dialog or an “advanced options” button or whatever).

Also, even if I do not use some of the other “advanced” buttons on the remote control, I do not think that I would have bought that TV set if I had not seen that these options were available.

Update: moved the image and its description up a bit.

Syndicated 2005-12-14 09:18:15 from Raphaël's Last Minutes

Resurrecting GIMP metadata

It has been a long time since I last updated the metadata code in GIMP CVS. It is annoying how real life gets in the way… In fact, my contributions to the GIMP have been almost nonexistant in the last months, except for some minor contributions to the help pages. But I will take advantage of the Christmas break to get back to that metadata code.

First I have to fix some outstanding issues with the model (based on XMP) so that it is easier to link the model and the GUI. Currently, opening the File->Properties window leads to an ugly collection of empty widgets. Once the model and the GUI are correctly linked, it should be possible to have correct values displayed in these widgets and to update the model when the values are edited by the user.

Once this first step is done, it should be much easier to work on the remaining parts: adding pretty widgets in the properties window, converting to and from EXIF and IPTC, and eventually moving some of the code currently residing in gimp/plug-ins/metadata/ into a library so that plug-ins could link this code directly instead of using some functions through the PDB. I will write more about this once the first step is done.

Syndicated 2005-12-07 04:20:35 from Raphaël's Last Minutes

Unmaintainable Code?

How To Write Unmaintainable Code

Two days ago, I enjoyed reading the collection of tricks titled How To Write Unmaintainable Code and I mentioned it to a colleague. We both had fun reading it and commenting on some entries, but then forgot about it.

The Mysterious JSP Bug

Yesterday, he came to me to check if I could help him debug an application. That was a bit of JSP code that I had written some time ago and that he extended. Note that I seldom write JSP or even Java - he is a much better Java programmer than I am. The problem was that after his modifications, the JSP page did not produce the expected results. That page was supposed to display some results after submitting a form, but it didn’t. There was a rather large amount of code in that page, but I will spoil the fun for you by quoting only the part that caused the problem (of course he initially thought that the problem came from a completely different part of the code):

    String submit = request.getParameter("submit");
    if (submit == null) {
        /* if the user did not confirm, go to the exit page */
        %><jsp:forward page="./SomeExitPage.jsp" /><%

Nothing very fancy in that code. Now, since he was testing a modification of that code, he was not sure that the form submission would always be correct. So he did the obvious thing and commented out some parts of the code that were not ready yet for testing, including the one that I just mentioned. That part of the code now looked like this:

    String submit = request.getParameter("submit");
    // if (submit == null) {
    //     /* if the user did not confirm, go to the exit page */
    //     %><jsp:forward page="./SomeExitPage.jsp" /><%
    // }

Nothing unusual, right? Just commenting out a few lines that are not ready yet. Well, this is wrong! I found out that the problem was precisely there: the unexpected results that he got were just the contents of the exit page. The problem did not come from some other part of the code that we were looking at. It came from the lines that were commented out.

Why? Well, it should have been obvious: the scope of the JSP tags <...> and <jsp:.../> is evaluated before the language-specific features such as comments, etc. As a result, the <jsp:forward.../> was not commented out. On the contrary, it was now unconditionally included, since the if condition had been removed. That was a nasty trick!


The bug was fixed quickly, but we thought again about one of the interesting examples in “How To Write Unmaintainable Code”, specifically the one titled “Code That Masquerades As Comments and Vice Versa”.

Syndicated 2005-11-24 11:29:40 from Raphaël's Last Minutes

Visited countries

Following the meme started on planet.debian.net (but one week late), here is a list of countries that I have visited…

Rather dense in Europe, but unfortunately not much outside of it. I am planning to change that.

North America is shown as one big piece, but to tell the thruth, my visits to Canada have been limited to Quebec (plus one airport stop that doesn’t count) and my visits to the US include only CA, AZ, NV and UT (plus DC and IL if you include airports). Note that the isolated red dots (islands) around Hawaii are incorrect and came as a side effect of selecting the US, but most of the other ones are correct.

Update: Two months later, I managed to fix the title of this entry. It turns out that NewsBruiser gets sometimes confused with its authentication cookie and displays the unhelpful error message “Error: I don’t think you meant to enter that as the title.” if you put anything in the title. Submitting an entry without title worked, though. Solution: go to the configuration page, select “Security”, re-enter your password and enable or disable the authentication cookie. After that, you can enter titles again. <sarcasm>Why didn’t I think of this obvious solution before?</sarcasm>

Syndicated 2005-09-22 13:02:42 from Raphaël's Last Minutes

ADSL adventures, part 2

Once I managed to get the necessary information for configuring my Speedtouch 350 DSL modem (see part 1), the next logical thing to do was to start using it. Or at least try to.

The first problem was that Belgacom apparently never sent me the letter containing the user name and password that I was supposed to use for accessing their services. After spending a few minutes on the phone (that music sounds familiar) I got a login and password that I could use. Well, that’s what I thought. I learned later that what I got was not the login/password pair that I asked for, but just a pair of passwords (for PPPoE and for POP). No login. Doh!

My second call to the support center (ah, that music again!) was barely more successful: this time I got a user name and a (new) password, but again I discovered later that the user name that I got was incomplete (last characters missing).

The third call was more interesting. After 20 minutes of music (I really know it by now), a technician told me about the missing characters in my user name and asked me to try logging in while he was monitoring their side of the DSL line. This time, the PPP authentication was successful but then the PPP connection went down immediately after that. Strange! The modem re-tried a few seconds later, with the same results. And again, and again… After a few more minutes of debugging, he told me that he was resetting their card and asked me to power-cycle my modem. I did that and when the line came back, the connection worked and I was able to access the Internet. Oh joy! But I also noticed something else while looking at the system log of the modem: the connection speed after the reset had dropped from 3 Mbps to 1 Mbps. I mentioned that to the guy, who said that it was normal. Ah well, at least the ADSL connection was usable so I was happy (after wasting two hours on that).

According to a colleague who had a similar experience, the reason why my line went down immediately after a successful authentication was related to the 3 Mbps. By default, the DSL access is configured for 384K/3M up/down. But the offer that I had accepted had a cap at 1 Mbps (apparently, because I never got the letter with the details of the offer). Although the telco part of Belgacom handling the DSL access was happy to let me in with 3 Mbps, the ISP part of the company was not happy with that and dropped the connection immediately. That could make sense, but I am still wondering why the access line had not been configured correctly on their side in the first place and why it took so long for the problem to be identified. Ah well, at least I can use my connection now… And I am glad that I could do all the tests using the built-in web interface of the modem over Ethernet instead of USB. I’m wondering what would have happened if they had required me to use some Windows software for configuring the stuff.

Syndicated 2005-08-04 08:21:06 from Raphaël's Last Minutes

I have moved to blogs.gnome.org. I don't know yet if I will update that blog more frequently than this diary. We'll see...

Long time no write.... My last diary entry was almost one year ago!

Playing with LILO and Slashdot

This morning, I loaded the Slashdot home page and... Oops! What's there in the story at the top of the page? Three links to my LILO pages. Ouch! This is going to hurt... Welcome to the Slashdot effect! Quick look at the logs of the web server: since this morning, the server has already seen more than 20,000 visitors making more than 300,000 requests. And many people in the US are still in bed at this time. All these downloads are going to suck a significant amount of bandwidth...
Playing with LILO is fun. It is also interesting because it encourages good programming practices. Testing a modified boot screen requires a reboot of the PC, and any fatal error in the program is likely to prevent the computer from booting at all. So I take the time to re-read my code before rebooting. This reminds me of the good old time when I was programming in Z80 assembler on my ZX Spectrum.

Playing with the Linux kernel

Yesterday, I had to run some tests at work with a modified version of the Linux TCP stack. The goal was to change the initial size of the congestion window and to run some performance tests on a dedicated network (with high bandwidth*delay product). Of course, there is no /proc interface for changing that, because this would violate the standards. So I decided to add my own. I had never looked closely at the Linux kernel code before, and I never touched the TCP stack.
It took me a while to find the file that I had to change, but find, grep and emacs are very useful tools. Once I found the file (net/ipv4/tcp_input.c), it was really easy to change the way the cwnd was initialized. Half an hour later, I had created two new interfaces in /proc/sys/net/ipv4 and everything was working. I even added a new option in net/ipv4/Config.in to make these features optional. By reading or writing to the pseudo-files in /proc, I could dynamically alter the behavior of the TCP stack and make it standards-compliant or not.
This was a very interesting experience for me, because I have been working on free software for a long time, but still I did not expect that it would be so easy to add a new feature to something as complex as the TCP stack of Linux. Of course, I only had to do a very small change that was limited to a few files, but it was interesting for me to see how easy it was to understand how the /proc interfaces work and how the kernel configuration works, considering that it was the very first time that I looked at it. So I have to congratulate the kernel hackers for all this nice work.

There is a pointer to the improvements for TCP in the Ericsson Eifel license that I mentioned. The first paragraph contains a reference to the Internet-Draft that describes the Eifel algorithm. Mind you, this is a draft and not yet an RFC.
In the References section of the draft, there is a link to a paper that gives a bit more information about why the Eifel algorithm could be useful for TCP.
Oh and by the way, I come from the french-speaking part of Belgium, not from France. ;-)

I just saw your AskAdvogato message in which you ask how to keep ants out without killing them. Although killing them is usually the easiest solution (using boxes with small ant-sized holes containing a poison that the ants eat), the best way to keep them out is to make it hard for them to get in. If it is not possible for you to seal all openings in your house, you can try to smear grease in their path, or to use chalk or talc powder around the openings through which the ants enter your house. They hate these things because it makes it harder for them to walk, and they give up after a while... or find another opening that you had forgotten. Good luck!

More patents usable in free software...

Following the example set by Raph with his royalty free license for using his patents in free software (released under the GPL), there is now a similar license granted by Ericsson for some proposed improvements of the TCP protocol (the Eifel algorithm). More power to free software!

That license allows GPLed software to include the proposed improvements to the TCP stack, as well as any operating system that is entirely Open Source. So this covers Linux, FreeBSD, OpenBSD and NetBSD, among others.

(Disclaimer: I work for Ericsson and I contributed to the wording of that license, but I am currently only speaking for myself, not for my employer.)

David O'Toole writes:

[...] Looking at stuff like this makes me get just a tiny bit upset about how badly the linux world is dragging its political feet with respect to improving the interface. I'm not talking about making all the OK buttons respond to the Enter key (currently my biggest pet peeve about GNOME, and it's slowly being fixed---recent GIMP etc.)

I'm talking about the imaging model. I don't want to criticize X unfairly. The X Window System was brilliant for its time and in its environment. But it simply does not support what people want to do now well enough to continue. Fast vector imaging, transparency, high-resolution monitors, antialiasing. Yes, you can implement software on top but there's no standard and it's slow.

The first defense I hear all the time is network transparency. I respond: who cares.

Well... I, for one, care very much about the network transparency of X. I am currently typing this from a Solaris machine on which I have other windows displayed remotely from a Linux machine and other Solaris machines. Not only some XTerms and Emacs that could also work over telnet/rsh/ssh, but also graphical applications like Purify, Quantify, Netscape, XMMS and some other goodies. They are all on the same LAN so speed is not really an issue. Without X's ability to display anything anywhere, writing and debugging my programs would be much harder.

So maybe I am among the 1% of people who really use the remote displays and would not be satisfied with text-based remote logins. This does not mean that nothing should be done for the other 99% who would like to get a much better performance from the applications that are running on the local display.

I don't think that it is necessary to throw X away and to start again from scratch. The DGA extension (available on OpenWindows and XFree86) proves that you can get decent performance out of X, although this requires some specific code that is rather ugly and not easy to write and maintain. Most programmers do not want to write some additional code for specific X extensions, and indeed they should not be required to do so.

But it would be possible to get a better performance while keeping the X API. Imagine that someone modifies the shared X library (libX11.so) so that if the client connects to the local server, all X calls which are normally sent to the X server over a socket would be translated into some optimized drawing operations accessing the video buffer directly. The shared X library would more or less contain some bits of the server code (actually, a stub could dlopen the correct code). If the X client connects to a remote server, then the X function calls would fall back to the standard X protocol. All clients that are dynamically linked to that modified library would automatically benefit from these improvements without requiring any changes to the code. So it can be done without throwing away the benefits of X. Actually, I believe that some people are working on that for the moment...

26 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!