off by one

Categories: pedro | technical

Mon Feb 10 13:04:27 Gnumeric File Reference "unknown workbook" Error:

If you have file references in Gnumeric (you refer to different workbooks using a reference like:


... the references will not resolve unless the other workbooks are opened *in the same gnumeric instance*. This means, for example, that if you open Nautilus, select all the workbooks, and open them in Gnumeric, that your references will not work. Instead, they will all be quoted; that is, they will look like this:


Don't be alarmed -- your sheets have not been changed. Trying to manually remove the "'" will just throw up an error about a referral to an "unknown workbook."

The issue is that, as I said up top, all the sheets must be opened in the same instance of Gnumeric. It's not obvious in any way that open windows of Gnumeric may not be the same "instance" so this can be confusing. The solution is to open one of the documents, or a "new" Gnumeric instance, and then open the linked documents from within a single application instance.

I never used linked sheets in Excel, so I'm not sure if this is typical spreadsheet behavior or not. I'm frankly surprised that the sheets need to be open to be viewed... I think Gnumeric should be able to open linked sheets as long as the paths are right, but that's just me... anyway, HTH, HS (happy spreadsheeting)!

Sat Feb 16 20:46:57 oh yeah!:

Run a sequence of SQL statements in a script and spit the output to a file:

shell> mysql db_name < script.sql >

Thu Oct 11 10:26:21 one less paper cut:

As a vi user who codes in a GNOME environment with sloppy keyboard habits (you'd think there wouldn't be that many of us, but... surprise!), I hate the GNOME default of having F1 bound to the help menu. I'm constantly hitting F1 when reaching for ESC, so I regularly get annoying help windows popping up.

For a long time, I assumed that it was the top-level GNOME help document -- you know, like "how to use GNOME." I'm still not sure if this was ever the case. But today, I noticed that it's actually showing me the help file for GNOME Terminal. I scoffed that I would actually care to read the help file for my terminal emulator.

The irony is that if I had *read* that annoying help file, I might have actually found the answer to my problem. You can disable it (and set a lot of other nice shortcuts) under Edit | Keyboard Shortcuts.

Wed Apr 13 13:28:38 random thought:

Hardware is just software you can't change.

Thu Feb 01 10:39:06 another one from spamblock:

It is trivially easy to block attachments by extension with postfix. This is nothing earth shattering, and people have been doing this for years, but pretty much everyone running postfix should be doing this. And it's so easy that you have no excuse.

Step 1: Create a file header_checks in your /etc/postfix directory. In that file, put a line like this:

/^content-(type|disposition):.*name *=.*\.(exe|pif|com|scr|bat)/ REJECT We cannot accept executable attachments

... run postmap on that file to create header_checks.db.

Step 2: Edit and add a line like this:

header_checks = regexp:/etc/postfix/header_checks

... restart postfix.

Step 3: PROFIT!!!

Seriously, that's it. You can also use a pcre instead of a regexp by using the postfix-pcre package (in Debian/Ubuntu), and changing "regexp" to "pcre" in the line.

Originally from here... but their regexp has a bug in it.

Thu Jan 18 11:12:05 here's one for posterity:

I use postfix with smtp auth for users who use outside clients but still use my smtp server to send out (which is considered relaying).

The standard Debian/Ubuntu way seems to be to use sasl2 along with postfix. But the saslpasswd2 man pages are pretty cryptic -- do I need a "realm"? What about an "appname"? How come no matter what I do, nothing seems to work? There are two answers -- one, saslpasswd2 requires the bare minimum from you, and two, remember that postfix is running in a chroot jail.

1. To add users, just do saslpasswd2 -c and enter the password twice on the interactive prompt. The changes are stored in /etc/sasldb2.

2. The non-obvious catch is that Debian/Ubuntu run postfix in a chroot by default -- so after you add or remove users, you have to remember to copy the /etc/sasldb2 file into the chroot, like this:

cp -a /etc/sasldb2 /var/spool/postfix/etc/

... then it should work!

I have to do this so rarely that every time it comes up, I have long since forgotten and it takes me an hour to figure this out... so perhaps this can be a contribution to posterity -- mine and hopefully yours.

Thu Jan 18 08:52:50 warning: may contain SQL:

from clickolinko

T Sat Jun 03 10:03:37 working on the new server:

alh has a saturday class for a few weeks, so I am home working on the new server. It's the first time that I have built a new server out of mostly top-shelf components. It's an SMP system with two dual-core Opteron 265s, and 4 GB of RAM in a NUMA layout. The motherboard is an ASUS K8N-DL and it fits in most normal ATX cases (most NUMA boards don't).

It's a little crazy, but I'm hoping to get Xen running on here so I can offload some of my poorly managed domains to a virtual server. I'm also hoping to run MythTV on this box and use it as a home media server. And as my web, shell, and network router. Kind of a tall order.

T [Comments] (1) Sun Oct 16 09:04:10 compression:

I had a brainstorm this morning. I've been copying some of my old vinyl records to the computer while I still have a record player. It occurred to me that tracks on the outer grooves of an LP will sound better than tracks on an inner grooves due to the way a record moves. This is old news to some people, but not to me. The issue is that records move at a "constant angular velocity" or CAV for short. This means that the disc always spins at the same velocity. For 12 inch LPs, that velocity is normally 33 and 1/3 rotations per minute.

If you consider that a standard LP is 12 inches, it's radius is 6 inches. Circumference is 2 Pi times the radius (or Pi times the diameter), or 2 * 6 * 3.14, which is 37.7 -- 37.7 inches around the outside groove. If the record spins 33.33 times a minute, and a minute is 60 seconds, then this translates into 20.94 inches per second (37.7 * 33.33 / 60).

By contrast, the inner grooves are only 3 inches away from the center of an LP, giving us a diameter of 6 inches and a circumference of 18.84 inches. Using the same translation to inches per second, we see that the surface of the record at that distance from the center hole is moving at 10.5 inches per second -- essentially half the speed of the outside grooves!

This matters because the more space you use to store image or sound information, the better that representation will be when you play it back -- one way to think of it is that you can draw a more detailed picture on a 3x5 card than you could on a postage stamp -- well, if the outer grooves of a record are like that 3x5 card, then the inner grooves are about half that size! Not a lot of space.

This is also basically true with computers -- the more bits of data you store, the better the representation of analog data (images and sound) can be. That's why we care about the "megapixels" of digital cameras (and that's largely why MP3s don't sound as good as a CD -- they're smaller). The way compact discs avoid the "postage stamp" problem of the inner track of LPs is that their discs spin at "constant linear velocity" (or CLV) -- this means that as the laser moves across the face of the CD, the disc changes speed so that the laser is always scanning the disc at the same speed; when the laser is on the inside "tracks," the disc spins much faster than when the laser is on the outside. The data is more "tightly packed" on the inner rings and more "loosely packed" on the outer rings -- therefore the quality is always constant!

(Incidentally, unlike LPs, CDs read from the middle of the disc out!)

This is not new news at all -- it's just a lightning bolt that hit me this morning. In fact, I'm going to guess that an article very similar to this was in Hi-Fi magazine in about 1984!


Unless otherwise noted, all content licensed by Peter A. H. Peterson
under a Creative Commons License.