My only concern is about licensing. As stated on the web site, the choice of a license if let to each author. Some designs may therefore not be free “as in freedom” or open source, although all must be free of charge (free “as in beer”). So, be careful when chosing a design!

209.237.230.104 - - [03/Jan/2006:18:44:19 +0900] "GET /~lenglet HTTP/1.0" 301 324 -
209.237.230.104 - - [03/Jan/2006:18:44:20 +0900] "GET /~lenglet/ HTTP/1.0" 200 31782 -
209.237.230.104 - - [03/Jan/2006:18:44:20 +0900] "GET /atom.xml HTTP/1.0" 404 282 -
209.237.230.104 - - [03/Jan/2006:18:44:21 +0900] "GET /rss.xml HTTP/1.0" 404 281 -
209.237.230.104 - - [03/Jan/2006:18:44:21 +0900] "GET /index.xml HTTP/1.0" 404 283 -
209.237.230.104 - - [04/Jan/2006:16:47:22 +0900] "GET /~lenglet HTTP/1.0" 301 324 -
209.237.230.104 - - [04/Jan/2006:16:47:22 +0900] "GET /~lenglet/ HTTP/1.0" 200 31782 -
209.237.230.104 - - [04/Jan/2006:16:47:23 +0900] "GET /atom.xml HTTP/1.0" 404 282 -
209.237.230.104 - - [04/Jan/2006:16:47:23 +0900] "GET /rss.xml HTTP/1.0" 404 281 -
209.237.230.104 - - [04/Jan/2006:16:47:23 +0900] "GET /index.xml HTTP/1.0" 404 283 -

This looks exactly like the hits I recently got from Feedster's crappy robot which was looking for RSS feeds from my web page. I had to send an email to Feedster, which they quickly responded to, and they soon stopped hitting our server.

Are they back with a revenge? Or have they sold the code of their buggy robot to someone else? Anyway, 209.237.230.104 is none of their addresses: it belongs to United Layer, an ISP which is probably hosting the robot that generates the hits I observed.

I have addedd yet another entry in my Apache .htaccess configuration file to deny any access to 209.237.230.104... When will these people learn how to respect standards, including the Robots Exclusion Standards?!

Here is the special cryptic link that they asked me to put into my blog to be able to “claim” control of my weblog RSS feed in the Feedster search engine (do not click that link: it is not meant to be clicked).

By the way, the web interface for user registration is also buggy and unusable because the registration form, when submitted, points to a nonexistent page. I guessed that only the host name of the latter URL was wrong, and should be feedster.com instead of feedster.net. I have therefore simply configured my system to resolve the feedster.net host name to the same IP address as feedster.com, so that the form points to feedster.com instead: this made the registration form work nice! To make my web browser access feedster.com instead of feedster.net, I have simply added the following line to my /etc/hosts file in my Linux system (64.95.116.10 is the IP address of feedster.com):

64.95.116.10    feedster.net

In addition, forms are present twice in the login page, for no reason.

Those are strong signs of “web site rot”...

Special note to the person who registered my web page into Feedster yesterday: this is nice to you, but you should have better registered my real RSS feed URL (at http://www.csg.is.titech.ac.jp/~lenglet/rss.xml) instead of my web page (at http://www.csg.is.titech.ac.jp/~lenglet/), because the result is a lot of hits to unexistent URLs from the dumb Feedster robot, cf. an extract of our web server's logs:

...
64.95.116.1 - - [08/Dec/2005:12:49:33 +0900] "GET /~lenglet HTTP/1.1" 301 336 -
64.95.116.1 - - [08/Dec/2005:12:49:33 +0900] "GET /~lenglet/ HTTP/1.1" 200 27650 -
64.95.116.1 - - [08/Dec/2005:12:49:34 +0900] "GET /atom.xml HTTP/1.1" 404 294 -
64.95.116.1 - - [08/Dec/2005:12:49:34 +0900] "GET /index.xml HTTP/1.1" 404 295 -
64.95.116.1 - - [08/Dec/2005:12:49:34 +0900] "GET /rss.xml HTTP/1.1" 404 293 -
64.95.116.1 - - [08/Dec/2005:13:17:48 +0900] "GET /~lenglet HTTP/1.1" 301 336 -
64.95.116.1 - - [08/Dec/2005:13:17:48 +0900] "GET /~lenglet/ HTTP/1.1" 200 27650 -
64.95.116.1 - - [08/Dec/2005:13:17:49 +0900] "GET /atom.xml HTTP/1.1" 403 298 -
64.95.116.1 - - [08/Dec/2005:13:17:49 +0900] "GET /index.xml HTTP/1.1" 403 299 -
64.95.116.1 - - [08/Dec/2005:13:17:49 +0900] "GET /rss.xml HTTP/1.1" 403 297 -
...

So if you could correct the URL of my feed in your Feedster account, or do anything to stop those wrong accesses, it would be very nice, thanks.

Here is why I say above that Feedster's robot is dumb:

1. It does not respect the Robots Exclusion Standards, which consists for web robots such as Feedster's to access a file named robots.txt on every accessed web server to check if its accesses are welcome. Not only Feedster's robot does not respect this standard, which is disrespectful, but also it accesses feeds every 30 minutes, which I consider excessive.
2. It seems to incorrectly interpret <link rel="alternate".../> elements in HTML page headers. For instance, my XHTML web page, which has been accessed every 30 minutes by Feedster's robot, contains such elements in its header which seem to be incorrectly interpreted by the robot. This leads to accesses to unexistent URLs (as shown in the web logs above with the 403 HTTP error codes): it should have accessed /~lenglet/atom.xml instead of /atom.xml, etc.

For information, here are the <link rel="alternate".../> elements in my web page headers:

<link rel="alternate" type="application/atom+xml" title="Atom 0.3" href="./atom.xml">
<link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="./rss.xml">
<link rel="alternate" type="application/rss+xml" title="RSS 1.0" href="./index.xml">

I am certain that accesses by Feedster's robot to /atom.xml, /index.xml and /rss.xml are due to its interpretation of those <link rel="alternate".../> elements, because since I have denied any access to my web page to the robot it does no more try to access /atom.xml, /index.xml and /rss.xml. Here are the lines that I have added into my root .htaccess file, to specifically deny access to my web page to Feedster's robot:

<Limit GET>
order allow,deny
deny from 64.95.116.1
allow from all
</Limit>

Now, I still get accesses from Feedster's robot every 30 minutes, but those accesses are now denied and I am now getting those lines in our web server's logs:

...
64.95.116.1 - - [08/Dec/2005:14:01:02 +0900] "GET /~lenglet HTTP/1.1" 403 298 -
64.95.116.1 - - [08/Dec/2005:14:20:14 +0900] "GET /~lenglet HTTP/1.1" 403 298 -
...

When they will have corrected my feed's URL, I will probably re-enable access for that robot, but still they should correct their robot implementation...

In addition, they publish many interesting in-depth articles about design on their web site, some articles concerning web design. Article number 83, titled “Secrets of good hypertext”, is about how to put good hyperlinks in web pages.

Today, I have tried to polish the hyperlinks in my blogs's articles according to this article, but this still requires some work.

In the nanoblogger Debian GNU/Linux package, plugins are installed in the /usr/share/nanoblogger/plugins/ directory. In order to enable/disable plugins, it is therefore necessary to rename files in that directory, e.g. for the tidy.sh plugin:

sudo mv /usr/share/nanoblogger/plugins/makepage/tidy.sh \
        /usr/share/nanoblogger/plugins/makepage/tidy.off

The problem with that method is that when the nanoblogger package is updated, the tidy.sh file is reinstalled in /usr/share/nanoblogger/plugins/makepage/ along with the tidy.off file, which re-enables the plugin. To make the renaming permanent accross package updates, one must use Debian's diversion mechanism:

sudo dpkg-divert --divert /usr/share/nanoblogger/plugins/makepage/tidy.off \
    --rename --add /usr/share/nanoblogger/plugins/makepage/tidy.sh

This renames the tidy.sh file into tidy.off, and in all subsequent updates of the package the new tidy.sh files will also be renamed automatically.

To re-enable the plugin, simply remove the diversion:

sudo dpkg-divert --divert /usr/share/nanoblogger/plugins/makepage/tidy.off \
    --rename --remove /usr/share/nanoblogger/plugins/makepage/tidy.sh

I use it for my own bibliography, cf.: the summary, the detailed view with abstracts, and the pretty-printed Bibtex file.