auto refresh-keys

MFPA expires2010 at
Wed Jun 16 19:03:19 CEST 2010

Hash: SHA512


On Tuesday 15 June 2010 at 1:46:30 AM, in
<mid:4C16CD66.7000509 at>, Daniel Kahn Gillmor wrote:

> On 06/14/2010 07:54 PM, MFPA wrote:
>> On Monday 14 June 2010 at 6:19:58 PM, in
>> <mid:4C1664BE.1080500 at>, Daniel Kahn Gillmor wrote:
>>> The goal, again, is to avoid auto-refresh from chewing
>>> up too much space on the local disk.

>> Although, of course, the certifications are all part
>> of OxDECAFDAD.asc and therefore are still dowmloaded
>> and consume bandwidth. With isks in excess of a
>> terabyte, why bother expending the extra CPU cycles to
>> conserve a little disk space?

> Your disks might be in excess of a terabyte.  The large
> majority of mine aren't.

I actually meant they are inexpensive and readily available, not that
I have (or need) that size.

> Even if mine were, given that
> i'd like to see GnuPG easily available on mobile
> telephones and similar devices, i think disk space is a
> relevant metric.

I wasn't thinking of mobile phones etc. In that scenario, disk space
is scarce, and so is memory. Also, mobile internet speeds (the real
speed, not the "up to" quoted by the network) are generally very slow
compared to ADSL, although usually quicker than dialup.

> disk I/O is a regular source of bottlenecks. Writing
> useless material to disks in any regular fashion is
> behavior to avoid.


> Plus, if we can demonstrate that GnuPG cares about
> minimizing costs to the user in terms of disk space, we
> also stand in a better rhetorical position to encourage
> development (or adoption) of alternate keyserver fetch
> requests that could apply similar minimization
> heuristics to bandwidth.

What sort of alternate fetch requests do you envision? Fetch-minimal?

- --
Best regards

MFPA                    mailto:expires2010 at

Editing is a rewording activity


More information about the Gnupg-users mailing list