No, do not use gdb­m. Prob­a­bly not bdb ei­ther.

TDB al­lows for con­cur­rent writes. So, if you want to store some da­ta in a file in your ap­pli­ca­tion/­tool/­com­mand/what­ev­er, and there is a chance that you need con­cur­rent writes... TDB is re­al­ly the on­ly rea­son­able choice I know.

You can even have dis­trib­uted TDB­s.

I found out about TDB while writ­ing a per­sis­tant cache for a lit­tle tool (a qmail plug­in). Since by its na­ture it would have con­cur­rent writes all the time, I was aim­ing for some­thing like mem­cached, or its disk-based ver­sion... but TDB solves the prob­lem nice­ly and ef­fort­less­ly.

So, if you need a flat DB (a.k.a anony­mous blobs with a sin­gle in­dex, a.k.a a hash in a file)...

The on­ly cur­rent soft­ware I wrote that some peo­ple ac­tu­al­ly use is called RA-­Plu­g­in­s. It's a se­ries of prog­gies you plug in your SMTP server's con­ver­sa­tion, and do di­verse things with it, like re­ject­ing mes­sages that fail cer­tain cri­te­ri­a, check­ing the sta­tus of the re­cip­i­en­t's ac­coun­t, what­ev­er.

In­ject­ing this stuff in the mid­dle of SMTP is good be­cause it means you will re­ject the mes­sages be­fore they get in­to your serv­er. But... I am run­ning out of ideas, so... have any you can spare? :-)

You can see the cur­rent plug­in list here and the on­ly ideas I have left are:

• A plug­in that calls back to the sender's email serv­er and tries to email him, ala mil­ter-sender to catch forged sender­s.

• A plug­in to au­­towhitelist in spa­­mas­sas­sin those ad­­dress­es to which you send mail.

• A plug­in to keep an ac­­count of how many con­nec­­tions you hold to each IP, and lim­it them. (Not cur­ren­t­­ly pos­si­ble)

If you un­der­stand what I wrote, and have any ideas... feel free to post them as com­ments and/or email me with them!

I am play­ing with CMake. Specif­i­cal­ly, I am try­ing to re­place the sim­plis­tic hand­made Make­files for my RA-­Plu­g­ins projec­t.

The parts about de­tect­ing li­braries and con­di­tion­al­ly com­pil­ing plug­ins based on what you have were sur­pris­ing­ly easy!

Un­til I ran in­to ... man pages.

Here is a Make­file that would build all the man­pages for the plu­g­in­s:

MANPAGES=plugins-ra.8 authchecks.8 rcptchecks.8
man: \$(MANPAGES)
%.8: %.man.txt
      txt2man -t \${basename $< .man.txt} < $< > $@

As you can see... triv­ial. All I need to do in or­der to add a man page is add what­ev­er.8 to the list, and it will be cre­at­ed from what­ev­er.­man.tx­t.

But... how does one do that us­ing CMake?

I start­ed think­ing of us­ing a FILE (GLOB *.­man.tx­t) and then a FORE­ACH over that, and then... then what? Re­al­ly, I am stumped. I am a new­bie, though, and get­ting the big, dif­fi­cult stuff done is enough to switch. I should gen­er­ate these be­fore dis­tri­bu­tion any­way.

So, I wrote a wee Make­file.­man­pages and added this for CMAKE:

ADD_CUSTOM_TARGET ( manpages make -f Makefile.manpages )

But I am cu­ri­ous about find­ing the cmakeish way.

Hav­ing run­ning sta­tis­tics on your sys­tems is al­ways a good idea.

Since I am a qmail freak, I have been us­ing the ven­er­a­ble qmailm­rt­g7 for a long while.

In fact since I use my couri­er pop3/imap serv­er with tcpserver, I can even use qmailm­rt­g7 to give me stats about POP3 and IMAP, which it susu­al­ly does­n't.

But... qmailm­rt­g7 is kin­da lame. In part it is lame be­cause it us­es mrt­g. In part it is lame be­cause it's one opaque thing.

Munin, based on rrd­tool is much nicer to look at than mrt­g, and has a much more rea­son­able ar­chi­tec­ture.

Then, I found qm­rtg which is much nicer than qmailm­rt­g7, and al­so has a much nicer ar­chi­tec­ture.

So, why not make a qmunin based on qm­rtg which will mar­ry them?

Well, that's an idea.

It's not even very hard to do :-) I should prob­a­bly do it and pub­lish it.

I wrote Lin­ux/U­nix ap­pli­ca­tions for ten years be­fore I wrote my first man page.

I used all the ex­cus­es:

• My app has in­­ter­ac­­tive help

• My app is for pri­­vate use

• Some­one will write it even­­tu­al­­ly

But of course there are on­ly two rea­sons not to write man pages.

• You think the man pages are ob­­so­lete.

This is what the FSF thinks. So, they give you in­fo pages. And they put, at the bot­tom of each man­page some warn­ing about how that may look like the doc­s, but the re­al docs are the in­fo pages.

Then they don't pro­vide a de­cent in­fo read­er out­side of emac­s. But hey, who cares. On KDE, just use a in­fo: URL.

• You hate writ­ing man pages.

Which is per­fect­ly un­der­stand­able, since this is how a man page looks like (and yes, I know it's spe­cial­ly ug­ly ex­am­ple):

.de }1
.ds ]X \&\\*(]B\\
.nr )E 0
.if !"\\$1"" .nr )I \\$1n
.}f
.ll \\n(LLu
.in \\n()Ru+\\n(INu+\\n()Iu
.ti \\n(INu
.ie !\\n()Iu+\\n()Ru-\w^G\\*(]X^Gu-3p \{\\*(]X
.br\}
.el \\*(]X\h^G|\\n()Iu+\\n()Ru^G\c
.}f

And it is even pos­si­ble that for some man pages you need to write such a thing.

But for the av­er­age pro­gram? Just take some­thing like tx­t2­man and be hap­py.

I wrote man pages for each of my qmail-spp plug­ins in a few min­utes. Al­though they prob­a­bly are lack­ing in their man-­pa­ge­ness in mat­ters of style, they are ok.

And they are not hard to write at all (full):

NAME

  authchecks

DESCRIPTION

  This plugin is meant to be used on the AUTH command and does two things:

  1. Logs the user (see LOGGING)

  2. If the user is authenticated, it sets QMAILQUEUE "/var/qmail/bin/simscan-nospam",
  which is probably not what you want, but is what I use right now ;-)

And there is no rea­son why your pro­gram, be it KDE-based or not, should not have such a thing.