Subject: Re: Y2K is over

From: [email-masked]
Date: Thu, 20 Jul 2000 11:22:37 -0700

> balance sheet
>
>     value of 1.6 G bytes
>       ($200 IBM 20Gb drive, y2k)              $12
>
>     value of 50 hours programming
>       ($100 per hour, y2k)                  $5000
>
>     net gain (loss) to society
>       from the Zimm Buddism
>       ("every byte is sacred"):            ($4988)
>
> The 2nd millenium is over.  Save programmers, not bytes.

This is a misleading comparsion.  There are circumstances where bytes can
be extremely costly, such as in the new wave of wireless devices, smart
cards, and other forms of portable electronics where every byte counts,
both for storage and for transmission.  Not all uses of signatures will
have access to a 20 GB hard drive and megabit data transmission rates.

Furthermore, although any given optimization may save only a few bytes,
the net result of multiple such choices based on a philosophy of space
savings can add up to a substantial percentage reduction.

This is especially true when contrasted with the philosophy that space
doesn't matter any more.  The end result of that philosophical approach
would be something like XML, with ascii rendering of data and verbose
tags to identify each field.  PGP's signatures are probably 1/3 the size
you'd get if you used straightforward XML to represent the data.

So, yes, the second millennium is over, but no, there are still situations
where saving bytes makes sense.

Having said that, you can still look at the various optimizations
in the OpenPGP spec to see which give you the most space-saving bang
for the programmer-effort buck.  Obviously using untagged binary data
is the biggest win.  Beyond that, some of the optimizations, like the
string-to-key iteration count, are probably a lot more effort than they
are worth, since they're not used much.

Hal

---

From: Tom Zerucha <[email-masked]>
Date: Thu, 20 Jul 2000 20:25:10 -0400

> be extremely costly, such as in the new wave of wireless devices, smart

You miss the biggest point.

Value of 50 hours programming - $5000.

value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE.

Assuming it will be installed on more than 416 drives it is cheaper to
pay a programmer to shrink the application.

You may have noticed this if you had to upgrade CPU, Memory, or Disk
when going from Windows 3.1 to Windows 2000.

(and if you use a Palm Pilot's ram as an example the cost goes way up)

---

From: Paul Koning <[email-masked]>
Date: Fri, 21 Jul 2000 10:14:32 -0400 (EDT)

>>>>> "Tom" == Tom Zerucha <[email-masked]> writes:

 Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, [email-masked] wrote:
 >> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive,
 >> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k)
 >> $5000 > > net gain (loss) to society > from the Zimm Buddism >
 >> ("every byte is sacred"): ($4988) > > The 2nd millenium is over.
 >> Save programmers, not bytes.
 >> 
 >> This is a misleading comparsion.  There are circumstances where
 >> bytes can be extremely costly, such as in the new wave of wireless
 >> devices, smart

 Tom> You miss the biggest point.

 Tom> Value of 50 hours programming - $5000.

 Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE.

Um, no.

Right now drives are about $10 per GB.  So 0.6 MB cost less than a
penny.  It takes nearly a million drives to break even.

Not only that, but the cost of extra programming is not just time
spent, but also quality reduced, which can be a lot more expensive.
In fact, if it introduces just one more bug that causes 1% of the
users $1 worth of extra hassle, you've already paid for the extra
bits.

	paul

---

From: Tom Zerucha <[email-masked]>
Date: Fri, 21 Jul 2000 11:32:28 -0400

This is getting a little off topic, but I think OpenPGP has a
programming philosophy of elegance and simplicity, so it isn't too far
off.  So I apologize in advance but will still respond ;).

> penny.  It takes nearly a million drives to break even.

And it drops each year.  Just wait and we will all have 10GHz
processors with a terabyte drive connected by high speed optical...

The cost of Palm RAM is around $4000/GB.  And it doesn't have a hard
drive port.  The cost of extra kilopackets on the VII if you don't
have unlimited is quite high.

If you want to embed something in 1M devices, the difference between a
$15 and a $20 chip will pay for a lot of engineering time.

In one sense your argument says that the US cars of the late '60s and
early '70s were optimal because steel and fuel were cheap and getting
cheaper, so 4-5K pounds wasn't a problem and maybe an asset in an
accident.

> spent, but also quality reduced, which can be a lot more expensive.

This assumes it reduces quality.  Normally collapsing a complex (and
big) interface into something which is both smaller and simpler
increases quality.

In my experience, the number of bugs is inversely proportional to the
complexity of the system, and simple systems don't produce a lot of
extra bytes.

In the original context, I think the argument was "We could add this
feature although it will take extra memory".  Arguing your point, we
shouldn't add such extra features because the cost won't simply be the
extra memory, but the programmer, tester, and fixup time due to bugs
or other incompatibilities said feature would introduce.

Also, such things tax other programmers who want to interface with the
software.  That extra byte might cause hundreds of other programmers
hours of grief.

> users $1 worth of extra hassle, you've already paid for the extra

There is a point of diminishing returns, but I know of very little
software that isn't 60% extra junk and gratuitous changes when new
versions come out with all the problems you note - and I am not even
talking about actual bugs.  Bloat is something that is anti-quality -
more interfaces, more code, more structures, more bytes that can be
misinterpreted.

Most of this applies to W32, less so for Mac, far less for Unicies
where you get complaints about being too simplistic to be usable.

The desire to reduce memory requirements is an indirect way to prevent
bloat, and as such is probably inefficient or even wrong in some cases.