Αγαπητέ κ. Μπεκίρη

Αγαπητέ κ. Μιχάλη Μπεκίρη,

Το σταθερό τηλέφωνο του σπιτιού μου το έχω για να επικοινωνώ με τους ανθρώπους που εγώ επιλέγω και για να μπορεί να με βρει ο κόσμος με τον οποίο έχω τακτικά επικοικωνία. Δεν το έχω όμως για κανένα από τους παρακάτω λόγους:

• Για να με καλείς ότι ώρα σου κατέβει με σκοπό να μου παρουσιάσεις το μεγαλεπήβολο “σχέδιο” που έχεις για τη σωτηρία του κόσμου
• Για να με καλεί ο αυτόματος τηλεφωνητής σου το μεσημέρι παίζοντας μια κασέτα χωρίς εγώ να μπορώ να κλείσω τη γραμμή

Δεν υπάρχει κανένας λόγος να απασχολείς τη γραμμή του σπιτιού με άχρηστες αηδίες όπως αυτές που λένε οι κασέτες του αυτόματου τηλεφωνητή σου. Αν ήθελα να ακούσω τις ακατάσχετες βλακείες που αραδιάζεις στην κασέτα (νομίζοντας ότι τις πιστεύει κάποιος ή ότι πραγματικά επειδή τις άκουσα θα έρθω σε εκλογικό οργασμό και θα σε ψηφίσω με στραβά μάτια) θα ερχόμουνα να τις ακούσω σε μια από τις “εκδηλώσεις” που οργανώνει το επιτελείο σου, ρυπαίνοντας τη πόλη μας με κάθε δυνατό τρόπο.

Το σημερινό δεκάλεπτο τηλεφώνημα της κασέτας σου ήταν το τελειωτικό χτύπημα. Άμα σε ψηφίσω ποτέ να μου γράψεις.

FOSSCOMM presentation about to start :)

This is being typed as we are preparing for the FreeBSD presentations of FOSSCOMM!

More on the event later, when we have more interesting things to do :-)

xmalloc() considered harmful

I’ve seen many places where xmalloc() and xfree() are used as replacements for the standard malloc() and free() functions (most of the time, to call abort() or print debugging/log messages to some file.

The most recent example of these macros was the source of an HTTP proxy server.

My short comment to this sort of macros is:

If you feel inclined to add debugging and/or logging support to malloc() and free(), then BY ALL MEANS steer clearly and far away from such ugly “hacks”.

There are various reasons why using the C preprocessor to wrap malloc() is silly and will turn around and bite you in the end:

• You do not really have any sort of control about what malloc() function is called by already compiled, “object” code.
• You will probably have to resort to even more ugly preprocessor hacks to handle the portability aspects of this code. Some systems define their internal malloc() function as void *malloc(size_t); others use int as the size argument; some may typedef size_t using compile-mode specific hacks (i.e. to support “large files” or a segmented memory model).
• You will probably miss some of the entry points to the system malloc() code, i.e. the posix_memalign() function; once you do, there are two possibilities: you will either print bogus traces/logs or you will misinterpret some of the traced data and consider it a bug—when, in reality, there is no bug in the allocator, but in the wrappers you wrote.

Before you embark on the “journey” of the xwrapper() functions, make sure that you spend a considerable amount of time pondering the following:

Do you really think you can outsmart the platform vendor, who has spent a lot of time testing and verifying the system malloc() implementation?

NTP Pool Servers

NTP, the Network Time Protocol, is a very useful and easy way of keeping the clock of many systems synchronized. ISC, the Internet Systems Consortium maintains a list of NTP servers that form a public pool of servers that you can use for your own systems too.

More information about the “NTP pool servers” can be found at:

http://ntp.isc.org/bin/view/Servers/NTPPoolServers

The sample ntp.conf file of that page is not 100% right for use with FreeBSD though, since our rc.d scripts specify the location of the driftfile in /etc/defaults/rc.conf:

# grep drift /etc/defaults/rc.conf
ntpd_flags="-p /var/run/ntpd.pid -f /var/db/ntpd.drift"

The rest of the sample ntp.conf file is ok though, so you can start with:

# cat /etc/ntp.conf
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server pool.ntp.org

Then, enable the ntpd service in your /etc/rc.conf file:

ntpd_enable="YES"

Before you fire up ntpd for the first time, it’s a good idea to manually synchronize the system clock at least once, so that ntpd will not start with a huge time-difference to recover from (which may inhibit ntpd from starting at all, in some cases). The ntpdate utility can do that, but please make sure you understand all the ramifications of running it with the -b and -v options (which will step the system clock instead of gradually slewing it):

# ntpdate -v -b pool.ntp.org

You should see something like:

# ntpdate -v -b pool.ntp.org
17 Apr 08:07:50 ntpdate[85166]: ntpdate 4.2.0-a Tue Apr 11 03:40:32 EEST 2006 (1)
17 Apr 08:07:54 ntpdate[85166]: step time server 216.221.85.115 offset 0.211012 sec

Now, you can safely start the ntpd daemon, to keep the clock sychronized at all times:

# /etc/rc.d/ntpd start
Starting ntpd.
#

All set. Now you can use ntpq to query & monitor your NTP synchronization daemon :-)

After you let ntpd run for a while, you can query its status with ntpq (NTP “query” utility) and see how well your new ntp.conf setup works:

# ntpq
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+allanon.amazing 81.2.90.116      2 u   58   64  377  102.379  242.506 113.880
+server1.medigli 192.36.144.23    2 u   55   64  377  135.605  225.324 106.716
+topaz.conuropsi 193.2.4.6        3 u   62   64  377   81.529  220.863 163.234
*ns2.national-ne 130.207.244.240  2 u   65   64  372  195.683   76.388 179.670
ntpq>

NOTE: The delay, offset, and jitter, column are displayed in milliseconds, so values like 76.388 above are quite fine for most desktop users. The meaning of the first column characters ('+' and '*' above are explained in the ntpq manpage:

• ‘+’ = (candidate) The peer is a survivor and a candidate for the combining algorithm.
• ‘*’ = (peer) The peer has been declared the system peer and lends its variables to the system variables.

If all this sounds strange, you can always find more information about the way ntpd and ntpq work in their manual pages:

$ man ntpd
$ man ntpq