Be careful when using read_multi with dalli: it may return nil-valued key instead of the correct key.

The issue is tracked here and thanks to this I dropped the read_multi usage in moebooru and used the much simpler (and most likely slower) single fetch (per entry) instead. There’s alternative way to use it – do a read_multi and refetch whatever missing/nil-keyed but apparently I’m too lazy to do it.

Counting takes ages, right. Except it is not. I’ve done this, yes, but on a table with 10+ millions of data (this one has ~400k in mainline danbooru), with multiple data inserted (this one got, uh, one every other week?) and queried every second (see below), and with the required count method not a simple select count(1) on some_table (which is what the example above used for).

It’s still quite slow even on my system. I should switch to Chrome again one of these days. I don’t even use Firefox anymore apart of on this specific system. Oh and Flash also crashes every other minutes in this browser.

Don’t get tricked by the “release” system. Apart of the base system, FreeBSD perfectly qualifies as rolling release. I guess it’s also why the binary package management sucked so badly. You won’t find how to upgrade certain packages using binary method in their Ports’ UPDATING page.

Here’s the example:

20120225:
AFFECTS: users of archivers/libarchive
AUTHOR: glewis@FreeBSD.org
libarchive has been updated to version 3.0.3, with a shared library bump.
This requires dependent ports to be rebuilt.
# portmaster -r libarchive
or
# portupgrade -r archivers/libarchive

You would think the dependent packages got version bump to ensure their proper dependency – but they didn’t. Instead you had to recompile everything depending on it.

Of course, ArchLinux kind of managed to do it but that’s a purely binary rolling release Linux distro. The maintainer worked hard to ensure such kind of thing get handled properly by all their users which mostly use binary packages. FreeBSD on other hand tried to claim capable of both but it really isn’t (unless I missed something).

I’m intending to contact pkgng creator to ask his opinion about this but have yet to do it…

In attempt to learn THE directory service called LDAP, I tried to setup OpenLDAP in Scientific Linux. The install went all right and slapd can be immediately started without much problem. Except that the config is one big mystery and there’s not even a rootpw defined by default. Being a complete newbie in LDAP thingy, I decided to build configuration and all from zero.

…except that it’s not actually trivial. Most examples/tutorials are for OpenLDAP prior to 2.4 which still uses slapd.conf which was obsoleted in favor of configuration in meta-format using LDAP’s ldif. Instead of one nice config, instead we have directories called cn=config etc inside slapd.d. Someone must’ve been into Linux too much (xxx.d – Linux users sure love “modularizing” their configs).

Anyway, the example in manual page of slapd-config doesn’t even work because the include syntax was wrong (should be file:///etc/… instead of /etc/…) and even after fixing that there still an error:

In short, I kind of given up and tried to follow the “Quick Start” from the very same guide. Instead of using slapd.d format, it still uses slapd.conf format despite it being a guide for 2.4. Seems like following a pattern, the config example also spit out error: