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.

Tag: Rants

And kvetching, too

  • Unit Pricing Obfuscation: Nothing Exceeds Like Excess!

    Walmart Tissue Unit Prices
    Walmart Tissue Unit Prices

    What with this being allergy season, my ladies blew through our tissue stockpile in short order and it’s time to reload. Give that we’re just blowing our noses it in, deluxe-edition tissue paper isn’t a priority, but these Wal-Mart unit-price stickers are not nearly as helpful as they could be…

    Hints:

    • The second label is for a shrink-wrapped block of three boxes.
    • The bottom label is for a name-brand tissue that’s unit-priced per sheet.

    Exercises:

    • Which container has the least expensive sheets?
    • The most expensive?
    • Is the 3-pack more or less expensive than a 1-pack?

    Essay: why do you think Wal-Mart does this?

    More unit pricing grumbling.

  • New Tires for the Van: Overtightened Lug Nuts

    The shop spec says the lug nut torque shall be 104 newton·meter or an equally odd 77 lb·ft. Let’s not get into quibbles about the differences between lb·ft and ft·lb here, OK?

    Anyhow, based on the wildly differing and grossly excessive tire pressures left by the guys who installed the new tires, I figured the lug nuts would be over-torqued… as, indeed, they were. My bending-beam torque wrench goes up to 140 n·m and didn’t even come close to breaking those puppies loose.

    So I deployed a manly breaker bar and applied most of my weight to the far end. A back of the envelope guesstimate says they were well over 200 n·m, with a few grunt outliers.

    Yes, the breakaway torque can be higher than the tightening torque, but they were far beyond even that level.

    Lubed the threads, tightened to spec, and it’s all good. I’ll check them next week just to be sure, but sheesh if we had to fix a flat on the road, it would have gotten ugly.

  • Do You Feel Lucky Today?

    Drugs by Nostrum
    Drugs by Nostrum

    Just got a new shipment of dope from our usual mail-order med supplier. The new dope comes in a livid red capsule, a disconcerting change from the previous green.

    So, being an educated and somewhat wary consumer, I check the label to see what’s new. It seems my supplier is dealing from a new manufacturer!

    Hitherto, I’d only encountered the word nostrum in phrases preceded by words like quack. The dictionary definition, at least for some values of dictionary, seems to back that up:

    Noun

    Nevertheless, Nostrum Pharmaceuticals appears to be a legit concern.

    There’s a reason why big companies spend all that money to come up with names that are equally meaningless in all known languages…

  • Kmail: FAIL

    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…

  • Unit Pricing Obfuscation

    The idea behind unit pricing was to simplify comparisons between packages with different quantities: each package would have a price-per-unit value.

    Here are the two shelf labels for two sizes of the lah-dee-dah fluoridating remineralizing mouthwash that our young lady must use for the next few years. The unit price is in the orange block, with some fine print underneath giving the unit. Click for a bigger image; you’ll probably need it.

    Unit Pricing Obfuscation
    Unit Pricing Obfuscation

    Need a bit more help? Here’s the one on the left:

    Price Per Pound
    Price Per Pound

    And the one on the right:

    Price Per Quart
    Price Per Quart

    For those of you in the rest of the world with volumes in liters and weights (uh, masses) in kilograms:

    • 1 pint = 0.5 quart = 1 pound of water

    What’s most interesting is that this only occurs when the package with the larger quantity has a higher per-unit price, as with these bottles.

    This is a perfect example of something that’s technically legal, but definitely not in keeping with the spirit of the law.

    Another interesting situation: if a shelf pricing sticker is missing for one of several similar items, you can be absolutely certain that package is more expensive. A missing shelf price sticker is technically illegal, but I doubt anybody ever gets prosecuted… it’s a simple mistake that could happen to anyone, right?

    Because nothing in a Walmart store is left to happenstance, this is obviously planned and approved at the highest levels.

    It happens elsewhere, too, but we just happened to be in Walmart this morning. Check it out where you shop…

  • The Decline of Literacy: Just Copy The Label

    Spotted these signs on the outside wall of a local Big Box home repair store. It’s not as if I’ve never misspelled anything, but this required consistent effort by two of the three folks who wrote up the signs.

    Which one is correct?

  • KMail: The Blank Email Problem

    Of late, Kmail has been turning email messages into complete blanks: the Subject, From, Date, and body are all completely blank. This is evidently a problem of long standing with Kmail and has something to do with fumbling the indexes that point to the emails within its maildir directory structure.

    The FAQ blandly notes:

    You have empty ‘ghost-mails’ in your inbox (or other folder)

    Symptom: For some reason, certain messages aren’t accessible in KMail. They show up in the message list window but selecting them there results in a blank message window. I can’t open them or reply to them, etc.

    Solution: This problem ist most likely due to corrupted index files, see issue ‘You are loosing mail’ above. So just follow the advice given there.

    Well, yeah, except that rebuilding the indexes more than once a day seems excessive… and the problem is, intermittently, much worse than that.

    I’m running KMail in XFCE, which introduces some complexity, but other folks with the same problem are running it in bone-stock KDE. Surprisingly the recent 4.x upheavals haven’t changed the problem in the least.

    I’ve been keeping the maildir structure on the file server, rather than my local drive, and symlinking to it from my home directory through NFS. That also doesn’t seem to change the symptoms, although putting a heavy load on either the network or the server sometimes increases the number of blank emails.

    Over the last few months I’ve tried a number of things, like tweaking NFS buffer sizes & timings, to no avail. Time to start writing this stuff down…

    With that as prologue, here’s how to recover those blank emails.

    Most important: when you see a blank email, get out of Kmail. Nothing you do within Kmail will help and many things will hurt, so just bail out.

    Fire up a terminal window and cd to the directory representing that email folder. First-level folders have the obvious name, but all the second-level folders are in hidden directories. For example, I have a top-level folder called Bulk Stuff, with one sub-folder (among many) being EMC.

    The directory structure:

    Mail/Bulk Stuff/
Mail/.Bulk Stuff.directory/EMC/

    Yeah, embedded blanks. Sue me.

    Each of those directories has three subdirectories: cur, new, and tmp.

    The problem seems to arise when a new message gets transferred from new to cur, although sometimes existing messages in cur go bad. The index entry seems to point to the wrong place; the actual mail message file is in cur, but the index points off into the bushes somewhere.

    The solution is to manually move the file from cur back to new, then rebuild the offending index. Leaving it in cur and just rebuilding the index does not always work, for reasons I do not understand.

    The easiest way to find the newest messages:

    cd "Mail/.Bulk Stuff.directory/EMC"
ll cur | tail

    This will show the most recent few entries, which will look something like this:

    -rw-r--r-- 1 ed ed 22256 2010-04-19 20:48 1271724492.2194.DbdZD:2,S
-rw-r--r-- 1 ed ed 23513 2010-04-20 13:09 1271783386.2232.jxmG6:2,S
-rw-r--r-- 1 ed ed 20901 2010-04-20 17:10 1271797805.2232.i6fP3

    The last line shows the most recent files hasn’t been read yet, which is a tipoff that something’s wrong. If you have an older message with a rotten index entry, use grep (or some such) to find it.

    Move the file back to new and delete the corresponding index files:

    mv cur/1271797805.2232.i6fP3 new
cd ..
rm ".Bulk Stuff.index*"

    Then fire up Kmail again and it’ll automagically rebuild the indexes. That’ll work fine for a while, then it’ll screw up again.

    I suspect that the problem is related to either the number of messages or the index file size for each maildir directory. I have, in round numbers, 3 GB of mail stashed away. As with anything, most of it is useless , but I occasionally need one of those messages ever so urgently.

    I set up a new maildir structure with only the last 30 days of email transactions, which should be enough to either eliminate the problem or show that Too Many Messages is just another dead end.

    More details on that tomorrow…