Trying to set up Windows Server 2003 (trial download) to confirm & fix bug 3000 for MediaWiki running under IIS.
[[Wikipedia:Apricot|Apricots]]: YUMMMMMMM! Easy to slice in half and remove the pit, and verrrry delicious. Dried apricots are also nice and last longer in the cupboard.
[[Wikipedia:Peach|Peaches]]: Similar to its smaller cousin the apricot, but IMHO they’re harder to work with. The pitting vs deliciousness ratio is unfavorable.
[[Wikipedia:Blueberry|Blueberries]]: Pretty awesome when you pick them yourself in the forest. Prepackaged, though, I find them kinda… boring and tasteless. Maybe I just got boring mass-produced Chilean blueberries, though.
[[Wikipedia:Blackberry|Blackberries]]: Upside: yum! Downside: full of little crunchy seeds.
1.9.0 final in a day or so, after a few more chances for people to test last-minute regressions.
After 3 hours of poking at samples and documentation and sleep deprivation, I now have a package containing… a changelog file.
(Update: got it working eventually, after scrapping all the files and rebuilding them with dh_make.)
I tossed together a silly WordPress plugin to special-case links into [[leuksman|my wiki pages]] such as my [[gimp mac helper]] tools, as well as to MediaWiki’s bug tracker (eg, bug 1) and SVN repository (r12345 was nice).
SVN anonymous checkout: http://svn.wikimedia.org/svnroot/mediawiki/trunk/silly-regex-linker/
Only useful if you’re me at the moment, but maybe I’ll generalize it for fun.
For a long time I’ve found SSHKeychain an invaluable little app on my Macs, making remote logins with keys relatively painless.
When I upgraded to an Intel-based MacBook last month, I was saddened to find that there wasn’t a Universal release; the last PPC release didn’t run on Intel; and development seems to have stopped altogether. :(
The good news is that it’s open source, and further one of the last code checkins, early in 2006, had been to add Universal binary build support. So I went ahead and built the thing for my own use.
I did though find that it crashed intermittently when waking from sleep. After a little debugging I found the problem; some variables were initialized badly so if all your keychains were locked it would crash. Fun! Easy to fix, though.
I mailed the patch to the dormant developers mailing list and the author, hopefully it’ll get rolled in and other people will get to use it…
1) logging in on local DBs
2) new account creation on local DBs
3) migration-on-first-login of matching local accounts on local DBs
4) migration-on-first-login of non-matching local accounts on local DBs
5) renaming-on-first-login of non-matching local accounts on local DBs
6) provision for forced rename on local DBs
7) basic login for remote DBs
8) new account for remote DBs
9) migration for remote DBs
11) secure login form
12) multiple-domain cookies to allow site-hopping
The English Wikipedia full-history data dump (my arch-nemesis) died again while building due to a database disconnection. I’ve taken the opportunity to clean up dbzip2 a little more and restart the dump build using it.
The client now handles server connections dropping out, and can even reconnect when they come back, so it should be relatively safe for a long-running process. The remote daemon also daemonizes properly, instead of leaving zombies and breaking your terminal.
Using six remote dbzip2d threads, and the faster 7zip decompression for the data prefetch, I’m getting about 6.5 megabytes per second of (pre-compression XML) throughput average, peaking around 11 mb/sec. A big improvement over what I was measuring with the local threads, by a factor of 5 or so. If this holds up, it should actually complete in “just” two or three days…
Of course that’s assuming the database connection doesn’t drop again! Another thing to improve…