Habemus plus vis computatoris quam Deus

One of the things that's always been a minor peeve to me on LiveJournal (and then, later, on Dreamwidth) is the Forrest Gump box-of-chocolates nature of the Quote button.  (You never know quite what markup you're going to get.)  For LiveJournal, I long ago found a Greasemonkey script called LiveJournal Blockquote, which made the Quote button consistently generate a <blockquote> tag.  But it doesn't work on Dreamwidth (and appears to have vanished from userscripts.org anyway).

That's why I wrote an improved version today, called LJ Quote Fix.  It works on both LiveJournal and Dreamwidth, should work on any site based on the LiveJournal codebase, and has provisions for customizing and styling your quote markup using CSS (though at this time there isn't a UI for it, other than Greasemonkey's 'Edit' button.)

By default, it formats quotes like this.  (Well, mostly like this, anyway.  If you're reading this in my style, the light-blue background comes from my journal's custom CSS.)

Bruce Schneier is one of eight designers of Skein, an entrant for the NIST SHA-3 competition.  It's extremely robust, and has proven very difficult to attack.

Which is why a group of very clever cryptanalysts invented a completely new type of cryptanalytic attack to use against Threefish, the block cipher underlying Skein.  The crypto community is still trying to figure out how the new attack changes the crypto landscape.

Brilliant as it is, though, the new "known-key distinguisher attack" still didn't really work.  It was able to distinguish between a reduced-round — 57 of 72 rounds — Threefish ciphertext and a random permutation, but doesn't actually recover any key bits, requires that the attacker be able to manipulate both plaintexts and keys "in a structured way", and is only marginally faster than a brute-force attack.  Even then, it can only distinguish Threefish ciphertext, and doesn't actually affect Skein itself (yet).  Further, Schneier and the other Skein designers were able to identify a way to block the new attack by changing a single constant in Threefish's key schedule, which prevents the attack from being able to distinguish between Threefish ciphertext and random permutation beyond 33 of 72 Threefish rounds, and have made that change as a second-round tweak permitted by the NIST.

Still, it illustrates a point:  Both cryptography and cryptanalysis only get better over time.  When you run into a problem where none of the existing tools work, the truly clever cryptologist devises a new tool.

Finally, things have progressed from bang-head-on-wall to ... well, progress.

First of all, I've solved PART of the issues with the Mayhem G3 laptop.  I'd previously checked the fans and heatsinks, and they looked fine ... from the outside.  Yesterday, at the suggestion of a friend, I partially disassembled the laptop in order to replace the heatsink themal compound.  (A good call; what was there was mostly gone.  It's now been replaced with a fresh layer of Arctic Alumina.)  And, so long as I had the heatsink assembly out anyway, I disassembled it for a thorough cleaning.

The Mayhem's CPU heatsink is basically a fan-pressurized plenum assembly with fine copper-fin heat exchangers at either end, connected via heat pipes to the CPU.  The inside surfaces of both heat exchangers were totally blocked by a layer of dust so thick and dense that it had formed what amounted to a 1/8" layer of solid felt.  NO WONDER the previous owner had reported that it had begun "crashing" at increasingly-short random intervals; it had no cooling airflow whatsoever, and was going into emergency thermal shutdown to avoid destroying its CPU.

With its heat exchanger cleaned and new thermal compound, the Mayhem is now stable running Windows XP Pro, and has been up for two days without a hiccup; I even stress-tested it playing Halo for about twenty minutes, which was driving it into thermal shutdown within about two minutes prior to the cleanup.  (I will note, however:  If you value your sanity, don't ever try to play Halo — or probably any FPS — with a trackpad.  Just don't.).  So, one problem licked; I know the hardware is sound.  Next, I get to re-tackle the problem of getting it to boot under Linux with ACPI enabled.  (Which may now be a solved problem — it is entirely possible that what was happening was it was getting as far as loading the ACPI code, detecting thermal overtemperature condition, and immediately halting.)  With a 100GB hard disk (well... about 94 real GB), I have it partitioned 45GB and 45GB with a roughly 4GB swap partition, and I'll be leaving the XP installation in place and installing Gentoo dual-boot.

Given this success, I went on to also disassemble the M5309 laptop, which I'd been trying to reinstall for the Dread Pirate Bignum (who has decided to name it Post-Dated Check Loan) until it became unable to successfully compile anything, and replace its heatsink thermal compound as well.  (Which turned out to also be a good call; it was that horrible grey waxy stuff, and very little of it was still between the heatsink and the die.)  I then set out to try a new clean install, which not only exhibited no further problems with failed compilations, but successfully recompiled gcc on the very first try — always a good stresstest of a system.  But it still wouldn't build glibc.

And this was where things REALLY got interesting.

( Beware; here be deep geekery. )

Now, with that all figured out, Post-Dated Check Loan is happily compiling away, installing a complete clean system from scratch.  So Pirate is going to have her laptop after all in another day or two.  (We should probably buy her a new battery at some point though; the one we got with the laptop is down to 29% of its original 4400mWh capacity.)

Then, assuming I can sort out the processor speed control issue on the Mayhem laptop, I just need to source a screen from it somewhere.  (It requires a Quanta QD15LT01 15.4" WXGA active-matrix TFT LCD.  I can find one for about $60 used and asserted to be in good condition, about $77 for a "100% compatible" knockoff with a high-glare gloss surface, or $95 for the genuine article.  Saving $18 for a knockoff screen that I already know will have a glare problem just doesn't seem like a good idea.  But whichever I buy, it's going to have to wait on budget.)

"Security researchers at antivirus vendor Intego have discovered spyware attached to freely downloadable Mac applications. The malware is difficult to detect."

Via SecurityWire.

I currently have two Microsoft Natural 4000 ergonomic keyboards.  That's this one:

This keyboard has a few minor functional glitches, but has one major, glaring flaw:  Rather than proper double-shot key caps that will outlast the keyboard, the Chinese company that manufactures it for Microsoft marks the key caps using cheap, poor-quality decals.  There isn't even any kind of protective coating over them.  These decals wear off completely in a matter of a few months of normal use, a problem which Microsoft initially covered under warranty, but — presumably after learning that it wasn't just a few isolated cases, it was happening on ALL OF THEM — has now ingeniously and permanently solved by simply declaring it to be normal expected wear.  (Bite me, Microsoft.)

(Suggestion, by the way:  If you buy one of these keyboards anyway, which I wouldn't advise, you might want to do something like give all the key caps a couple of coats of lacquer clearcoat or polyurethane before using it for the first time.)

Now, I've been looking around online for replacement key cap label sets.  And sure enough, I found two different types, one of which looks perfect for the purpose.  That would be this product:

Only $9.95 per set!  Keyboard restored to full usability, and better than new contrast and visibility, expecially in low light!  Win!

There's just one problem.  No domestic shipping options except UPS.  MINIMUM $11.24 shipping for a $9.95 non-fragile item that probably weighs under two ounces, from New Jersey to New Hampshire.  LOSE.

Two or three of those would probably fit into a USPS Priority Mail flat-rate box or envelope, and ship anywhere in the US for $4.95.  The store even offers USPS Priority Mail shipping, and even, for that matter, USPS First Class.  But only on international orders.

At a shipped cost of $21.19, it would be more cost-effective for me to go and buy one of these Adesso ergonomic keyboards brand new from Amazon.com, for $33.24 with free shipping, and have a brand new keyboard AND a still-usable spare.

Shipping fail:  You have the right product, at the right price, but it's not worth your customers' money to buy it because you don't offer a realistic shipping option for it, because after all, one size UPS carton fits all.  Except that it doesn't.

UPDATE:  I now have to add that when I contacted the vendor, Baron Bob, to ask why there were no domestic USPS shipping options, they responded that they were actually one of the trial businesses chosen by the USPS to beta the flat-rate "If it fits, it ships" service before USPS officially announced the service.  However, they ended up choosing not to offer USPS shipping on domestic orders because, in their words, "it sucked", not least the fact that — as probably anyone who has tried to use package tracking on a USPS Priority Mail item knows — USPS package tracking is all but completely useless.  Not only do you not get any tracking progress updates while your USPS package is in transit, you're lucky if they even update it after delivery to show that your package was delivered.

"Trust me when I tell you this," Paul told me, "customers do not like the answer "I can't really tell you where your package is.""

Given this information, I'm assuming that they offer USPS shipping on international orders only because for international shipping, FedEx and UPS are an even worse nightmare.

Anyway, I will declare that the folks at Baron Bob are stand-up guys.  Not only did Paul, the office manager there, offer to ship an order of key cap stickers via USPS for me to make the purchase cost-effective, he gave me a (completely unrequested and unexpected) coupon code for a 15% discount on the order.  That's called good customer service, folks.

(Are you paying attention here, Microsoft?  Among other companies I could name?)

As if mass cybersquatting, monetizing its customers' domain name ideas through its shell subsidiary Domains By Proxy, locking customers' domains to keep them from transferring to other registrars, actively conspiring in the theft of its own customers' domains, intentional violation of ICANN rules and regulations in order to extort additional money from customers, or many other complaints (some of which probably qualify as fraud) weren't sufficient reasons to avoid GoDaddy, it is now reported that GoDaddy stores customer account passwords in clear and will use them, without your knowledge or consent, to access private servers hosted with them.

Further, it transpires that GoDaddy just got hit with a class action suit by its own employees, alleging theft of employee bonus commissions, defrauding employees of overtime pay, violation of federal Fair Labor wage and hours standards, and wrongful termination of whistleblowers.

Just as an aside, it seems GoDaddy isn't the only hosting company storing customer passwords in the clear.  Rackspace does it too.

...that having temporarily switched back from a 28" 1920x1200 LCD monitor (Hanns.G HG281DP) to a 20" 1600x1200 CRT (Sony GDM500PS) while my LCD monitor gets sent back for repair under warranty, I am realizing that I had really lost touch with how much better the LCD monitor is.  By comparison, the Sony is dim and fuzzy, has poor contrast and too much screen-face glare, and seems to take forever to warm up from sleep mode.  I need to see if I can get the refresh rate up, too; the 60Hz that is optimal for the LCD produces subliminal flicker on the CRT.

(Of course, really I need a more capable video card in this machine too.  When I built it, the Matrox G450 was one of the best video cards available for what I needed.  That's now rather far from true.  And when money permits, I really need to continue phasing out all of our CRTs for LCDs...)

Security researchers at Matousec have discovered an attack which defeats almost all existing Windows antivirus software.

The method, called an argument-switch attack, can be used against Windows security programs that use a technique called System Service Descriptor Table (SSDT) hooking.  All of the 35 applications tested by Matousec featured this technique, including products from BitDefender, F-Secure, Kaspersky and Sophos, as well as McAfee and Trend Micro.

"We tested the most widely used security applications and found out that all of them are vulnerable," Matousec said in a paper outlining its research, published on Wednesday.  "Today's most popular security solutions simply do not work."

SSDT hooking is used by many — though not all — antivirus programs as part of their mechanism for detecting and blocking attacks already running on the system.  The technique involves modifying the contents of the SSDT.  The company's research focused on kernel-mode hooks, though the attack is also effective against user-mode hooks, Matousec said.

"The results can be summarised in one sentence: if a product uses SSDT hooks or another kind of kernel-mode hook on a similar level to implement security features, it is vulnerable," the company said.

[...]

The bypass does not have a 100 percent success rate.  However, if a system is running multiple processors or multicore processors, the attack is more reliable, according to Matousec.

"Today, multiprocessor (systems) or multicore processors are very common hardware in desktop computers," the company said in a statement.  The attack can be run successfully from restricted user accounts, it added.

My main server has two ZFS disk pools, one consisting of a pair of mirrored 80GB boot disks, the other an array containing (currently) eleven 300GB disks.  (There were twelve, but one failed.  This is why hot spares are your friend.)  Today, I decided to move my MySQL databases from the main array onto the mirrored boot pair to get better database performance.  So I shut down the required daemons and started tarring up the databases ready to move them.

...Then, part-way through, I changed my mind about how I wanted to do it, killed the job, and killed it the wrong way, inadvertently blowing away half the /var/mysql directory.  Including the grant tables.

"Oops."

Now, fortunately, being a prudent and careful sort except for the times when I shoot myself in the foot, I have backups.  In particular, I have a full backup of all the databases, including the grant tables, current as of 0330 this morning, except for the Bacula catalog, which is current as of 0950.  But I can't use Bacula to restore them, because the Bacula catalog is blown away.

( Here's how to fix a blunder like this one. )

Recently I was given 3GB of DDR333 memory for babylon5, my Linux workstation, which has been getting by with 768MB for the past eight years or so.  There's no disputing it was much zippier with the new memory, except that ... well ... stability issues appeared.  The machine started locking up or crashing periodically for no apparent reason.  Compiles started randomly failing.  I rebooted the machine and ran memtest86+ on it for half a day, but mermtest86+ didn't find anything wrong.  Then I found that I couldn't recompile BRLCAD, which had stopped working — a major annoyance, because I'd been intending to use it to create a 3D model for the planned rebuild of my desk.  (It's a really nice steel-framed desk that would have been around $1200 new if I'd paid full price for it — which I didn't; I paid $200 — but the current top, made of several pieces of 1" particle board that don't actually fit together all that well, has been gradually deteriorating over the fifteen years I've owned it and is starting to get into fairly bad shape.)  Then I tried to update gcc from 4.3.4 to 4.4.3, to see if it would compile BRLCAD, and discovered that I couldn't bootstrap gcc.  The build kept dying with internal compiler errors.

Now, gcc has always been a sensitive indicator of memory problems.  It's one of the best memory subsystem stress-testers you'll ever find, because it really bangs hard on the memory.  It won't specifically locate problems, but it'll show up the existence of memory problems that normal diagnostics won't find because they don't stress the memory subsystem enough.

So I shut down babylon5, pulled all the memory, and examined it closely.  I made the interesting discovery that the three modules are not precisely identical.  All three are Crucial 1GB DDR333 DIMMs, but two are part number CT12864Z335.Y16TY, while the third is part number CT12864Z335.K16TY.

I don't know (and haven't been able to find out) what the difference is, but acting on a hunch, I put only the matching two modules back in and fired back up.  Today, gcc-4.4.3 bootstrapped on the first try without a hitch.  Shortly after, BRLCAD recompiled on the first try using the newly-built gcc-4.4.3.  So now, I guess I get to contact Crucial and see if I can get the third memory module replaced under its lifetime warranty.

Unfortunately, BRLCAD still won't start.

(I have at least figured out that the problem appears to be DRI-related, though.  BRLCAD is dying with the error "mged: ../common/texmem.c:936: get_max_size: Assertion `log2_size != 0' failed", if that's familiar to anyone.  driconf also dies on startup, with the same error, implying it's something that both BRLCAD and driconf call — possibly something in MesaGL.  Any suggestions for fixing it would be welcomed.)

(Update:  I've traced it as far as glxinfo/glxgears.  It looks to be an OpenGL/dri problem with x11-drivers/xf86-video-mga.  I really need to get a newer video card into this machine, something with a more current — and better supported — chipset and DVI or HDMI out.)