This probably isn’t applicable to the Latest and Greatest, but for the Ubuntu 8.04 version used by EMC…
gconftool -s --type=bool /apps/panel/global/tooltips -enabled false
The Smell of Molten Projects in the Morning
Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
This probably isn’t applicable to the Latest and Greatest, but for the Ubuntu 8.04 version used by EMC…
gconftool -s --type=bool /apps/panel/global/tooltips -enabled false
Just got a nice thank-you email from the mumble organization after filling out a survey form…
Thank you for taking the mumble Survey survey. Your input is very valuable to us in designing our program.
<Delete or replace with a closing such as “Sincerely,”>
<Delete or replace with an image of a signature>
<Delete or replace with a text representation of a signature (e.g. “John Smith”), the title corresponding to signature (e.g. “President”), and the site name>
OK, I appreciate their intent, but … it’s still a bit off-putting.
Hint: always include yourself on the email list, perhaps as a BCC, when you’re setting up a new bulk response. Sometimes what you see on the proofreading screen isn’t what goes out over the wire.
And I’m pretty sure that the “Survey survey” was put out by their Department of Redundancy Department…

This Tenergy automatic NiMH charger is typical of the breed: pick a charging current to match the cell / pack capacity, then stand back and let it determine full charge.
The instruction sheet reads thusly:
Pop quiz: what charging current should you use for a battery pack made from nominal 2300 mAh cells?
I thought so, too, but consider this graph (the full post is there):

The actual capacity is more like 1600 mAh, not 2300 mAh. Do you set the charge current based on the wildly overoptimistic cell rating or the actual measured capacity?
As you might expect: charge based on the actual measured capacity, because that’s what the battery can handle.
The higher rate actually worked with new cells, but as the packs aged the charger would sometimes grossly overheat them. Bad for the packs, not to mention a bit scary.
The lower rate worked perfectly, although it took me a while to figure that out.
For what it’s worth, this is the charger I hacked a magnetic grapple onto the thermocouple. Much more convenient and considerably more durable than ptui tape.
Memo to Self: One careful measurement is worth a dozen optimistic ratings.
A bit of searching produces this useful PHP routine, which almost worked. Two tweaks got it all the way there:
The changes, with line numbers in parens (line 347 was line 345 before the first change, OK?):
76: // force timezone
77: date_default_timezone_set("America/New_York");
347: $this->mboxhnd = fopen($this->mboxfn,'w');
After that, run the script as directed to convert the entire maildir tree in one fell swoop.
cp -a /from-wherever/Mail/ /tmp cd /tmp php maildir2mbox.php Mail ll mboxfiles
The output files appear in the mboxfiles directory adjacent to the top-level maildir directory. Don’t use the -e parameter, which would add a .mbox suffix to each file.
Evolution’s import “feature” is a major pain, as you must import the converted files One. MBOX. File. At. A. Time. Sheesh.
Rather than that, just slide the whole mboxfiles structure into place. Some case changes were in order for my setup, which may be due to historic considerations:
Then put the mboxfiles directory somewhere on the NFS server and fiddle the Evolution directory structure:
cp -ap mboxfiles /mnt/nfs-place/mail/ cd ~/.evolution/mail mv local local.base ln -s /mnt/nfs-place/mail/ local
Evolution will build all its indexes when it first sees the new files, so it’s all good.
So I thought I’d try Evolution, the Gnome email / calendar / messaging Borganism, which can allegedly support maildir files. Installation went swimmingly, but (at least at first glance) it can’t. More on this later.
Evolution uses the Gnome keyring to store passwords, which is (of course) different from and incompatible with the KDE keyring. The principle seems to be that when you sign on / log in / whatever, the Gnome keyring’s login keyring automagically unlocks, giving Evolution access to the POP3 password used for your ISP. Except that didn’t work; Evolution uses the default keyring, not the login keyring.
Evolution / Gnome evidently creates a default keyring entry by scraping up a password from somewhere unknown to me. The only way to clear it, at least in XFCE, without installing the entire mumble Gnome desktop, is to simply delete the keyring file… at which point, the keyring manager will ask you for a password and recreate the file.
rm ~/.gnome2/keyrings/*
Come to find out that the new cut-n-paste handler in Inkscape 0.47 collides mightily with (among other things) Clipman 1.1.3, the xfce4 clipboard manager, as mentioned in bugs 487653 and 418242.
Seeing as how I depend on Clipman, the least-disruptive course of action seems to be downgrading it to 1.1.1, which required some fiddling with the Arch Build System.
I have a build tree set up in /var/abs/local, so…
cd /var/abs/local cp -r /var/abs/extra/xfce4-clipman-plugin/ . cd xfce4-clipman-plugin
The PKGBUILD file tells us that source tarballs are available at
source=(http://archive.xfce.org/src/panel-plugins/${pkgname}/1.1/${pkgname}-${pkgver}.tar.bz2)
md5sums=('2ba70c6bd710e2a18cba5add66d297dc')
Go there, get the md5 sum for the 1.1.1 package, then edit the PKGBUILD to suit:
pkgver=1.1.1
... snippage ...
md5sums=('0884207cabd3a3a94c86b919bbf1617b')
Remove the existing package, build & install the new / old one:
sudo packman -R xfce4-clipman-plugin makepkg -s sudo pacman -U xfce4-clipman-plugin-1.1.1-1-i686.pkg.tar.xz
Then edit /etc/pacman.conf to ensure Clipman remains obsolete:
IgnorePkg = xfce4-clipman-plugin
Restart the panels:
xfce4-panel -r
And it seems to work just fine…
Doc for this is pretty good: building custom ABS packages and downgrading packages. The trick was finding the backlevel versions, which stumped me until I dug into the PKGBUILD file.
It’s worth nothing that this conflict isn’t unique to Arch Linux: the same problem is affecting other distros, too. What is unique to Arch is that it’ll distribute the fix earlier than anybody else, too, because as soon as the upstream versions change, they’re in the Arch repositories.
Memo to Self: remember to un-wedge Clipman when Inkscape gets its act together. Fortunately, pacman reports which packages it’s ignoring.
In the unlikely event you’re keeping track of this, slashing the total volume of email made Kmail much more competent: it hadn’t trashed an index file in, oh, weeks…
Until it happened again.
I don’t know that 30 days of email is magic, but 64 MB worked much better than 3 GB. The offending folder has all of 6 MB and 280 files, which puts a pathetic upper bound on Kmail’s good behavior.
Anyhow, Kmail still screws up its indexes, but … it’s better than it was.
You’d think this would be an important thing to get right, but the KDE apparat has far more important things to worry about. Eye candy, as nearly as I can tell.
I use Kmail because it’s one of the few email readers that stores messages in maildir format. That’s important with large email collections, because mbox, the other choice, tucks all the messages into a single honkin’ big file (perhaps one file per folder). That doesn’t work well with a daily backup strategy, because each message changes the file and triggers a backup of the whole thing. Maildir format means backing up only the new messages, which makes far more sense.
But, if this blank email thing continues, it’s time to move on…