However, the one-click install at DreamHost suffers from a severe problem which is that they do not provide ftp/scp access to upload pictures. This means that uploading a huge photo album is *painfully* slow a process, since the only available option is to manually upload each file using HTML forms.

In my free time, I’ve created an application to upload pics there, as a way to exercise my python programming skills and as my first peek at PyGTK programming. In case you give it a try, the program requires the PyGTK and mechanize python modules be installed in the system. It has only been tested on my gentoo linux box. Should work on other linux distros and bsd, probably also for mac os. Will *not* work on Microsoft Windows as it is (contributions to this regard will be welcome). UPDATE: peter at majorsilence dot com has kindly provided a patch that makes it work on windows.

An option to overcome the need for such a software utility is to install ZenPhoto normally (as opposed to using DreamHost’s one-click installation) and to upload the files using any scp client (e.g. WinSCP).

Disclaimer: this software is in ultra initial development state and may do horrible things to your albums. Software comes with no warranty. Please check the attached license terms.

Download zpu (ZenPhoto Uploader) version 0.1 here.

Download zpu (ZenPhoto Uploader) version 0.2 here.

Please leave a comment here if you download it - whether successful or not.

I had the idea of building ourlooks.com after watching this thought-provoking talk by Luis von Ahn, where he explains some of his research activities. The basic idea behind the talk is: we can automate tasks which computers can’t nowadays solve by making humans work for us. And humans will work, and they will do it for free, as long as they have an incentive to do so. More interestingly, this incentive is having fun. So, von Ahn has built several games that people seem to enjoy - and while playing, they solve interesting problems, such as recognizing the objects inside an image or collecting general knowledge (e.g., bananas are yellow and cars have four wheels).

I thought about other ways this idea could be applied, and this is how ourlooks.com was conceived. One thing that computers can’t do is to tell you how you look, especially in terms of how other people perceive your personal image. So I decided to create a game that, while being played, served to rank people in categories such as looking pretty, trustworthy, and others.This initial idea is what later on derived into what ourlooks.com is today.

Sadly, ranking user’s looks was not a 100% new idea. Most notably, the people at hotornot.com have been making millions of dollars since they were the first site (at least the first that got to be widely known) where users could vote on other people’s personal image. There exist nowadays tons of clones, devoted to rating cats, nude bodies, similarity to celebrities, and many others. However I thought that ourlooks.com would be an interesting experiment as it was significantly different: instead of hosting a popularity contest, it could become a useful tool to assess your personal image (you can have your own opinion on whether this is true or not).

Picture ratings

In ourlooks.com, every user-submitted picture is automatically rated in the following categories: pretty, trustworthy, happy, intelligent, funny and hot. All kinds of combinations are theoretically possible: someone can be hot but not pretty, or funny and not look intelligent.

The rating mechanism works in the following way. When a visitor enters the site, a question is displayed, followed by two pictures belonging to two different users. There exists one question for each of the previous categories. The question serves to tell the user what is the category under evaluation: “Who looks more intelligent?”, “Who is the hottest?”. Based on the votes from people, every picture gains or loses points in the corresponding category.

Most sites ask the viewers for a direct numeric rating of each picture. This adds more variability as the marking standards of viewers are different. By asking the viewer to vote over two pictures, ourlooks.com just captures the preferences of the voters and generates the scores indirectly. Also, comparing two pictures should more convenient for the user: selecting a numerical value requires more mouse movement than just clicking one of two pictures.

ourlooks.com uses a mechanism that resembles that of the ELO rating system used to rate chess players. When a low-rate picture (weak) is prefered by the voter in front of a highly rated one (strong), it will gain many points. Conversely, a strong photo will not gain much for an easy win in front of a weak opponent. This makes every picture’s rate to be quickly adjusted after a few votes. Allegedly, since I have not formally done any research on this.

Every picture that the user uploads is rated independently. For example, the following pictures are of the same user. Each photograph is obviously to be rated very differently.

Picture search engine

Besides the obvious ability to show top performers in each category, the site includes a unique feature: the search engine, which can be used to locate pictures depending on the ratings in each category. To my best knowledge, this is the first site user search engine that can take into account the looks of the people.

The user can specify the characteristics that he or she expects from results. For example, the first result of a query for “very pretty but rather unhappy” people returns these pictures in the first results:

And “happy, trustworthy” returns these results:

MySpace widget

The last feature that I added to the site is the “myspace widget”. Every user has the chance to include a picture in their myspace (or similar) profile that points to ourlooks.com. The picture is dynamically updated with the current ratings. However this is something that the users generally have not put into use. I guess they’d rather keep the results private.

Conclusions

The ourlooks.com site has now gathered around 500 registered accounts, and users have uploaded around 1000 pictures. Interestingly, most of the users are women. I guess women have a higher tendency to be worried about their looks. Either this, or the text ads I used to promote the site were unwittingly targeted to women.

For now the site is a small club, so I am happy to receive feedback from users. Too bad that I can’t dedicate much time to make it grow in features.

Akismet works very well for me. As of now, it has already blocked 192 comments in less than three days, and it has never had a single false positive (where it would have marked a legitimate comment as spam) or a false negative (failing to identify a spam comment as such).

For now all the spam I’ve been receiving is in form of links to online casinos. I guess the recent poker-related entries have attracted spambots to my site.

I’m very thankful to my friends for having pointed me to Akismet :)

We are testing our techniques on an anonymized copy of the traffic that traverses the link that connects (at least part of) the Technical University of Catalonia (UPC) network to the Internet. This guarantees the privacy of the users but it still lets us observe the trends and main characteristics of the traffic (i.e. number of flows, packets per second, total bandwidth usage) .

To inspect the traffic we are using CoMo and appmon (a network monitoring tool produced in the LOBSTER European project). This application analyzes the input traffic stream and can identify several popular applications or protocols that use most of the bandwidth nowadays (p2p, http, smtp..). It outputs a per-application aggregate rrdtool graph plus a list of the addresses that are consuming the most resources (note that the IP addresses are anonymized).

• two decks of COPAG cards
• 300 cheap casino-like chips in a metal case

I highly recommend the set of poker chips that I bought. Even though they are not the real thing, they look like and feel like real casino chips for a fraction of the cost. The set has cost me around 30€, shipping costs and sturdy-looking metal case included. Casino quality chips are made of clay and cost around $1 per chip, which I’m not willing to pay. The chips I have are made of plastic, with a metal insert to give them some wheight (11.5 gram). They stack well and they are not too slippery, which was my primary concern.

300 chips is ok for games with 4 to 5 people. If you plan on hosting 8 to 10 people games, I’d recommend buying the 300 chip set plus a 600 or 800 piece one, instead of a single one with 800 or 1000 chips. This is because the 300 chips together sum around 3.5Kg, which is approaching the limit of wheight that I can comfortably carry on foot, and I’ll occasionally be taking the chips with me. Believe me, playing with chips is a whole new experience compared to betting with bits of cheap Italian pasta :)

Besides the chips, I bought a couple of blue-colored COPAG decks for around 10€ each. If I could go back in time, I’d buy a blue one plus a red-colored one instead of two blue-coulored ones, since they can get mixed easily. But I’d still go COPAG, as the reviews I read on www.homepokertourney.com indicate that this brand has almost top-quality cards for half the price you’d have to pay for KEM cards, which are supposed to be the best. Pros: durable, they return to original shape after being bent. Cons: they feel too thin and slippery for many people (but I’m now used to it) and graphics on the card not as nice as they could be.

By the way, my linuxholdempoker.com experiment has failed, as it has still not caught any visitor from Google since I registered the domain. I’m trying with linux-poker.net instead, and this will be my last experiment on the subject.

85.17.3.200 - - [24/Sep/2007:07:56:38 -0700] “POST
/blog/2007/09/02/lautoescola-del-racc-canvia-una-molt-
bona-aplicacio-web-per-un-software-amb-llicencia-altament-
restrictiva/trackback/ HTTP/1.1″ 200 412 “-” “-”


I solved the issue by blocking this particular IP address, which was the same for all the posts, with an apache .htaccess configuration file:

order allow,deny
deny from 85.17.3.200
allow from all

From now on, his requests will be failing with a 403 Forbidden error:

85.17.3.200 - - [25/Sep/2007:06:02:23 -0700] “POST
/blog/2007/09/02/lautoescola-del-racc-canvia-una-molt-
bona-aplicacio-web-per-un-software-amb-llicencia-altament-
restrictiva/trackback/ HTTP/1.1″ 403 710 “-” “-”

Good riddance! Since I added this filter, the boot has keept retrying every 20 minutes, though. Perseverance is a virtue, but this IP address filter is not going away :) I hope the bot does not come back from a new address. If it does I’ll add CAPTCHA based protection to this site.

Fa cosa d’unes setmanes, però, l’accés a l’aplicatiu web va deixar de funcionar. Els encarregats del seu manteniment em van confirmar que l’accés havia quedat suprimit i des d’aleshores els estudiants havien d’usar un programari que hauria de demanar a l’oficina del RACC. Immediatament vaig recelar d’aquest software: segurament no em funcionaria sobre linux (almenys no sense barallar-me amb el Wine, cosa que no tinc massa ganes de fer). I no em permetria conservar les preferències o històrics d’errors entre els diversos PCs que uso: el de casa, el de la feina, i el portàtil.

Per culpa seva m’he hagut de muntar una màquina virtual amb vmware, instal·lar-hi windows… i tot plegat per trobar-me un programari amb una llicència (EULA) molt restrictiva, per no dir abusiva:

• només pots instal·lar el programa una sola vegada, i en un sol PC.
• el programa té una validesa de 4 mesos, després caduca.
• solament pots fer cada test 5 vegades (un amunt un avall, no recordo ara exactament) i prou. Un límit completament arbitrari!

Només puc que dir: quina llàstima! Un mal canvi. I amb aquest mal canvi desapareix una molt bona raó per la qual recomanava l’autoescola del RACC als coneguts.

Sort que els mateixos del RACC m’han donat molt bones notícies per una altra banda :-)

You do not want to bother your colleagues by shifting the problem to them - they already sent you their PDFs and you initially forgot to ask them to embed the fonts. Furthermore, you’d rather use free software that is available in your mainstream linux distribution. Preferably a command-line program which you can call from a makefile or a script.

Well, then, this is The Command:

$gs -dSAFER -dNOPLATFONTS -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sPAPERSIZE=letter -dCompatibilityLevel=1.4 -dPDFSETTINGS=/printer -dMaxSubsetPct=100 -dSubsetFonts=true -dEmbedAllFonts=true -sOutputFile=output.pdf -f input.pdf

It took a lot of time, almost ate up all my workstation’s memory but it did work. Credit goes to this guy. Further useful information here.

In CoMo, every packet has a reception timestamp. How packets are stamped depends on the actual sniffer that receives the packet. For example, DAG cards have their own clocks to stamp each packet. In libpcap, it is the kernel (in my case, the linux kernel) that marks the packets according to the local time.

While developing for the upcoming CoMo 2.0 release, I added strict checks that packet stamps for each packet should monitonically increase - that is, no packet timestamp can be lower than the previous. I expected this to be a reasonable constraint to impose on sniffers. I was wrong: libpcap did in fact feed CoMo with what I believed to be unordered packets.

In order to confirm this issue, I wrote the following program:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#include <pcap.h>
#include <err.h>
 
static void processpkt(u_char * data,
    const struct pcap_pkthdr * h,
    const u_char * buf)
{
    static double last_ts = 0;
    static int pkt_count = 0;
    double ts = h->ts.tv_sec +
        ((double) h->ts.tv_usec) / 1000000;
    if (last_ts == 0)
        last_ts = ts;
    if (ts < last_ts)
        printf("pkt #%d: ts decreased! %f to %f\n",
            pkt_count, last_ts, ts);
    pkt_count++;
    last_ts = ts;
}
 
int main(int argc, char **argv)
{
    char errbuf[1024];
    struct bpf_program prog;
    pcap_t *pcap = pcap_open_live(argv[1], 2048, 1, 0, errbuf);
    if (pcap == NULL || argv[1] == NULL)
        errx(1, "error opening interface %s", argv[1]);
    if (argv[2]) { /* we have a filter expression */
        int i = pcap_compile(pcap, &prog, argv[2], 0, 24);
    if (i < 0)
            errx(1, "error compiling filter expression "
                "`%s': %s\n", argv[2], pcap_geterr(pcap));
    i = pcap_setfilter(pcap, &prog);
        if (i < 0)
            errx(1, "error applying filter expression: %s\n",
                        pcap_geterr(pcap));
    }
    for (;;) {
        pcap_dispatch(pcap, 100, processpkt, NULL);
    }
}

The program receives two input parameters: the network interface to read from, and optionally the filter to apply to packets. For each packet that reaches the processpkt() function, it will check that packet timestamps increase, and output a warning if this is not the case.

Running this code yields the following results in our development box:

$gcc check_libpcap_timestamps.c -o check_libpcap_timestamps -lpcap
$sudo ./check_libpcap_timestamps eth0
pkt #23: ts decreased! 1184677973.006962 --> 1184677973.006952
pkt #28: ts decreased! 1184677973.007341 --> 1184677973.007328
pkt #38: ts decreased! 1184677973.007968 --> 1184677973.007952
pkt #43: ts decreased! 1184677973.008328 --> 1184677973.008322
pkt #48: ts decreased! 1184677973.008588 --> 1184677973.008577
pkt #53: ts decreased! 1184677973.008846 --> 1184677973.008830
(...)


Which confirms that packets returned by libpcap have non-increasing timestamps. Weird! Some joint research & problem debugging with Diego Amores revealed the following interesting threads, and especially this one that includes a post from Guy Harris to the tcpdump-workers mailing list which explains how libpcap gets the timestamps:

[Outgoing packets' timestamps are] assigned whenever the packet is supplied, by the networking stack, to whatever piece of code time-stamps the packet; that’s before the first bit is even put onto the network.
(…)
[Incoming packets' timestamps are] assigned whenever the packet is supplied, by the device driver or networking stack, to whatever piece of code time-stamps the packet; that’s after the lat bit is received.
In other words, the time stamps aren’t extremely precise measurements of when the first, or last, bit of the packet was put onto the network; the imprecision includes time spent passing the packet through the networking code and the driver code, as well as, possibly, through the networking card. It might also, for incoming packets, include interrupt latency.

The idea that incoming and outgoing packets are stamped this way made us think that maybe incoming packets have increasing stamps, and outgoing packets too, but when buffered together and returned by libpcap, there is no garantee that the timestamps increase. We confirmed this by doing the following:

$sudo ./check_libpcap_timestamps eth1 "src 192.168.0.1"
(no warnings, ctrl+c'd)
$sudo ./check_libpcap_timestamps eth1 "dst 192.168.0.1"
(no warnings, ctrl+c'd)
$sudo ./check_libpcap_timestamps eth1
(tons of warnings)

If we ask libpcap to process only either incoming or outgoing packets, timestamps are always increasing. As a conclusion, this has no impact on a passive network monitoring system that uses libpcap to capture packets, because a network interface will be used only to receive packets. However, in the case of CoMo, users may want to monitor active NICs, so I ended up relaxing the restriction that packet timestamps should increase, and merely issue a warning.