HOWTO: Resetting a Communicator 9500 to factory defaults

(This is the result of googling arround for sometime)

If you happen to have a Nokia Communicator 9500, you might want to reset it to factory defaults. You have two options to accomplish that and here is how:

* Remove the battery.
* Place it back.
* For as long as the Nokia handshake is visible on the PDA screen, keep CTRL-SHIFT-F pressed. After a while a menu is displayed asking whether you want to reset to factory defaults or not.
Use Rebooter, the excellent freeware utility of Roman Keller; available for download from SymbianGear.com.

Άπλυτο φως…

Στο αρχείο.
Στο αρχείο επίσης.

Πως γίνεται σε αυτή τη χώρα και το κόκκαλο κερδίζει το μαχαίρι…

(ref)

More fun with message threading

When I try to write email-related code and the result fails my expectations, I use my plan B: Write it in c-client. I suppose the fact that I do not start with c-client from the beginning is a result of suffering from the “Not Invented Here Syndrome“.

The other day I was trying to decipher the semantics of Thread-Index: and Thread-Topic: since it seems that Microsoft has not placed any public information on them. Apostolos suggested that Thread-Index: takes BASE64 values, to which I replied negatively. After all, decoding

AcdyY+a08VX8xfobTsy61v9NHPZ7QA==

using perl -MMIME::Base64 -ne ‘print decode_base64($_);’ does not produce anything meaningful.

However I dug a little bit more, following this piece of advice from the imap-protocol list:

“Look at the evolution source code, it contains quite a bit of
information on this.”

camel-exchange-folder.c from the Evolution Exchange package reveals the following gem:

/* A new post to a folder gets a 27-byte-long thread index. (The value
 * is apparently unique but meaningless.) Each reply to a post gets a
 * 32-byte-long thread index whose first 27 bytes are the same as the
 * parent's thread index. Each reply to any of those gets a
 * 37-byte-long thread index, etc. The Thread-Index header contains a
 * base64 representation of this value.
 */

[ Update: Message Threading in Public Folders ]

Enough with trying to work with Thread-Index: then! JWZ has documented a very effective algorithm for message threading and c-client implements it (read docs/draft/sort.txt from the source code distribution):

SEARCHPGM *spg;
THREADNODE *thr;
:
spg = mail_newsearchpgm();
thr = mail_thread(ds, "REFERENCES", NIL, spg, 0);
walk_thread(thr, NIL);

(You are advised to read docs/internal.txt.)

The “REFERENCES” argument to mail_thread() instructs it to use jwz’s algorithm. The other option is to use “ORDEREDSUBJECT” (or as draft-ietf-imapext-sort-19.txt calls it: “poor man’s threading”). walk_thread() just prints the edges of the graph (actually it is a tree):

void
walk_thread(THREADNODE *thr, THREADNODE *prev)
{
        if (thr) {
                if (prev) {
                        printf("%d %d\n", prev->num, thr->num);
                }

                if (thr->next) {
                        walk_thread(thr->next, thr);
                } else {
                        printf("%d NIL\n", thr->num);
                }

                if (thr->branch) {
                        walk_thread(thr->branch, prev);
                }
        }

        return;
}

You may wish to use the output of the above routine (slightly modified) and feed it to dot, so that you can have an image display of the threads in the email collection that you study.

What is left to discuss a little bit more, is the THREADNODE structure: You can go from a THREADNODE to its first child via the next pointer (thr->next in the above example). If the THREADNODE has two children, then the second is a branch of the first (thr->next->branch). It if has three, the third is a branch of the second child (thr->next->branch->branch) and so on.

Trying to make use of Outlook’s Thread-Index: header

tl;dr Finally the format of the Thread-Index: header is documented!

Recently I was in a situation where I had to reconstruct a thread of email messages using the Thread-Index: header which is used by Microsoft’s products, instead of the standard way of threading using Message-Id:, References: and In-Reply-To:

The truth is that I was really frustrated, thinking that Microsoft was breaking the standards using custom headers that do not begin with X- but as Dan Bernstein points out:

“822 promised that the IETF would never define field names beginning with X-. It did not prohibit use of non-X names by other organizations.”

Which means that Microsoft is allowed to add Thread-Index: (and Thread-Topic:) without breaking any standards. On the other hand Microsoft does not document anywhere (at least anywhere I looked and I looked plenty) how Thread-Index: is calculated and how it can be decoded to be made useful by any other application, any other than Outlook that is.

After some experimenting and a little bit of reverse engineering I’ve reached to the following results:

Thread-Topic: preserves the original subject of the thread, that is the Subject: but stripped from any Fw: or Re: prefixes.
Thread-Index: is used in a way similar to In-Reply-To: and References: Assuming that the first message in a thread has a:
```
Thread-Index: AcdyY+a08VX8xfobTsy61v9NHPZ7QA==
```
and the next in thread:
```
Thread-Index: AcdyY+a08VX8xfobTsy61v9NHPZ7QAAAiXbA
```
while a third one:
```
Thread-Index: AcdyY+a08VX8xfobTsy61v9NHPZ7QAAAiXbAAAXP5fw=
```
and a fourth one:
```
Thread-Index: AcdyY+a08VX8xfobTsy61v9NHPZ7QAAAiXbAAAXP5fwAABGXGw==
```
the pattern that decides the threading seems obvious; I have not yet found out what the single or double equal sign suffix means.

If only Microsoft could make such simple information available! Think of all the lost work hours! Only after I had resolved my problem did I find out about these guys, who had arrived on similar conclusions about the usage of Thread-Index:

Update #1: You may be interested to read the next episode.

Update #2: Yes, I keep refusing the BASE64 explanation. This is because what the BASE64 value decodes to is something either meaningless, or without known semantics.

Update #3: From the GNOME documentation: The value is apparently unique but has no meaning we know of. That is why I refuse the BASE64 explanation. It looks like a BASE64 string and it can get decoded into a string of bytes that one can represent as a number. But the questions remain unanswered: How is the first 27-byte long value chosen? Why every “next” value in a thread 5 bytes longer than the previous one? How are these 5 bytes chosen? The decoded value of an undocumented BASE64 string remains undocumented, hence it may not even be a BASE64 string at all (and may only coincidentally look like one).

The example Thread-Index: headers are taken from the MediaDefender Defenders site

city

Τιμάμε τα στέκια μας: Σήμερα το City κλείνει 19 χρόνια λειτουργίας.

Να τα εκατοστήσετε παιδιά.

Having fun with the MNIST database

The MNIST database of handwritten digits, available from this page, has a training set of 60,000 examples, and a test set of 10,000 examples. It is a subset of a larger set available from NIST.

It consists of four files that store data in a simple file format (idx format) which is documented in the MNIST database homepage. I wrote this C program to be able to extract the descriptions of handwritten digits of a certain value separately (eg. only the 0s or only the 1s). The text output is pretty simple and closely resembles the format of a PGM file. It is describes the grayscale pixel values of the image in decimal ASCII. Pixel values range from 0 to 255.

As a bonus, there is the opportunity to extract the images in portable graymap file format (PGM) image files.

This program was written with these guys mostly in mind.

[download mnist.c]

Πειρατικό λογισμικό – Ελεύθερο λογισμικό

Η BSA “τρέχει” μια καμπάνια στον Τύπο (ή τουλάχιστον είναι η δεύτερη Κυριακή που τη βλέπω στην Καθημερινή), που πάει κάπως έτσι:

ΠΕΙΡΑΤΙΚΟ ΛΟΓΙΣΜΙΚΟ:
ΔΕΝ ΠΛΗΡΩΝΕΤΕ ΤΙΠΟΤΕ ΓΙΑ ΝΑ ΤΟ ΒΑΛΕΤΕ.

ΠΛΗΡΩΝΕΤΕ 1000 ΕΥΡΩ ΓΙΑ ΝΑ ΤΟ ΒΓΑΛΕΤΕ.

Είναι νομίζω μια καλή ευκαιρία για τους υποστηρικτές του ελεύθερου λογισμικού να κάνουν μια ανάλογη καμπάνια:

ΕΛΕΥΘΕΡΟ ΛΟΓΙΣΜΙΚΟ:
ΔΕΝ ΠΛΗΡΩΝΕΤΕ ΤΙΠΟΤΕ ΓΙΑ ΝΑ ΤΟ ΒΑΛΕΤΕ.

ΔΕΝ ΧΡΕΙΑΖΕΤΑΙ ΝΑ ΤΟ ΒΓΑΛΕΤΕ.

Φαντάζομαι όμως πως δεν υπάρχουν οικονομικοί πόροι τέτοιοι για αντίστοιχες καταχωρήσεις στον Κυριακάτικο Τύπο.

Και με την ευκαρία: Μπορεί να έχουμε συνδέσει την έννοια του πειρατικού λογισμικού με την παράνομη διακίνηση και χρήση του εμπορικού-κλειστού λογισμικού, αλλά είναι εύκολο να καταλάβει κανείς πως η πειρατική χρήση είναι φαινόμενο που συμβαίνει και στο ανοιχτό λογισμικό (όταν δεν τηρούνται οι όροι της άδειας χρήσης, αναδιανομής, κ.ο.κ.).

ΤΣΜΕΔΕ #3

Με δεδομένο πως η διοίκηση του ΤΣΜΕΔΕ αποτελείται κατά τα 3/5 από Μηχανικούς, δηλαδή από ανθρώπους που ξέρουν από συστήματα αναμονής, είναι απορίας άξιο πως κανείς δεν έχει ασχολήθεί με το workflow των ουρών στο Ταμείο. Και μη σκεφτεί κανείς κακή ή ελλειπή μηχανογράφηση. Η διαχείριση ουρών και το indexing εγγράφων είναι προβλήματα για τα οποία υπάρχουν λύσεις αίωνες τώρα.

(#2) (#4)

$#random – a local mailer that returns a random EX_*

I found myself in a situation where I needed a local mailer that was required to return random exit values⁰ for email directed to certain users. Luckily, most of the job can be done via your .mc file:

MAILER_DEFINITIONS
Mrandom,        P=/opt/bin/random,
                F=lsDFMqbE,
                S=ruleset_noop, R=ruleset_random,
                T=DNS/RFC822/X-Unix,
                A=random $u

LOCAL_CONFIG
C{Random} adamo yiorgos admin system operator
Kcomp arith

LOCAL_RULESETS
Sruleset_noop
# This ruleset does nothing

Sruleset_random
# EX__BASE == 64 and EX__MAX == 78. EX_OK == 0, so we mask it to 79.
R$*             $: $1 . $(comp r $@ 64 $@ 79 $)
R$* . 79        $@ $1 . 0

LOCAL_RULE_0
R$={Random}  < $=w . > $*        $#random $: $1

When $#random is called, ruleset_random is called with $1 (the username) as an argument and returns $1.number, where number is a random number between EX__BASE (64) and EX__MAX (78) or zero. Therefore, the $#random binary is executed with $1.number as an argument.

/opt/bin/random can be as simple as this shell script¹:

#!/bin/sh
# This is an example (non) delivery agent and is not considered safe to run on a 
# production server.
status=`echo $1 | sed -e 's/.*\.\(.*\)$/\1/'`

while read x
do
        # noop
done

exit $status

A random EX_* value is returned to the sender of the email, assuming s/he has emailed a local user contained in class $={Random}.

[0] – Valid sendmail exit codes (EX_*) are defined in sysexits.h.
[1] – In my case I wrote the mail delivery agent in C, as I needed to do a few more stuff prior to calling exit().

The 5 minute effect

– Έλα μωρέ! Αυτό είναι 5 λεπτά για εσένα

Λάθος! Πέντε λεπτά είναι για εσάς που με ρωτάτε. Για εμένα είναι όλος εκείνος ο χρόνος που χρειάστηκε να ασχοληθώ, να διαβάσω και να πειραματιστώ μέχρι να ξέρω να απαντήσω σε πέντε λεπτά. Και όλος εκείνος ο χρόνος που θα χρειαστώ για να συγκεντρωθώ ξανά στη δουλειά μου.