size in kbytes?

[Richard G. Riley]

Re: size in kbytes?

On 2006-03-30, Eric Sosman <esosman@acm-dot-org.invalid> wrote:[color=blue]
> Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
> last-minute bug-fixing before product release, and one of the Q/A
> people reported a bug in the installation phase. The documentation
> said installation required X megabytes of available disk space, so
> the Q/A engineer decided to make sure it would actually work. He
> filled a disk with garbage files until only X megabytes of free
> space remained, then tried to install. The installation failed for
> lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
> you can see where this is going: the documentation (and the install
> program) wanted X * 1048576 bytes, while the disk on the test machine
> had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
> can make a difference.[/color]

Sounds more like there was simply not enough temp space for the
workings of the install process. Or did the QA guy, incorrectly, use
1000 as 1 k? Which is, of course, incorrect in all HD/RAM standards for
any system I have ever used.

[Skarmander]

[OT] Re: size in kbytes?

Martin Jørgensen wrote:[color=blue]
> Jordan Abel wrote:[color=green]
>> On 2006-03-30, Martin Jørgensen <unoder.spam@sp am.jay.net> wrote:
>>[color=darkred]
>>> Hi,
>>>
>>> I allocate some memory of size_t but want to express:
>>>
>>> printf("Total amount of allocated memory is: %lu bytes.\n", (unsigned
>>> long) total_mem);
>>>
>>> in kilo-bytes. So is method 1 or 2, the correct one? I've seen both
>>> explanations using google:
>>>
>>> 1)
>>> printf("Total amount of allocated memory is: %lu kb.\n", (unsigned
>>> long) total_mem/1024);
>>>
>>> 2)
>>> printf("Total amount of allocated memory is: %lu kb.\n", (unsigned
>>> long) total_mem/1000);[/color]
>>
>>
>> Method 1 probably meets user expectations better, and will be more
>> consistent with the way other tools on most systems express amounts of
>> memory. And, actually, you should use "B", not "b" for bytes, "b" is
>> bits. Probably the best solution is to write "KiB" and use 1024.[/color]
>
> Strange, because you know: I believe that I tried many programs on
> various systems over the years... And AFAIR I can't think of one single
> program using "KiB" for output.[/color]

I'm not surprised. "KiB" was introduced in 1999 and is only slowly gaining
momentum. I have seen it once or twice in programs, but I'll probably never
hear someone pronounce it. Although, you never know.
[color=blue]
> Therefore I won't use "KiB" - I guess there are people out there who
> don't even know what KiB is.[/color]

Well, unless context is clearly provided, people won't know what (or rather
how much) KB is either, so in comparison that's a relatively minor problem.
[color=blue]
> I still don't know whether to use 1024 or 1000, but I think I'll write KB
> after the number...[/color]

This exact attitude will definitely put you in alignment with the mainstream
approach.

S.

[Jordan Abel]

Re: size in kbytes?

On 2006-03-30, Eric Sosman <Eric.Sosman@su n.com> wrote:[color=blue]
>
>
> Jordan Abel wrote On 03/30/06 12:39,:[color=green]
>> On 2006-03-30, Eric Sosman <esosman@acm-dot-org.invalid> wrote:
>>[color=darkred]
>>> Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
>>>last-minute bug-fixing before product release, and one of the Q/A
>>>people reported a bug in the installation phase. The documentation
>>>said installation required X megabytes of available disk space, so
>>>the Q/A engineer decided to make sure it would actually work. He
>>>filled a disk with garbage files until only X megabytes of free
>>>space remained, then tried to install. The installation failed for
>>>lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
>>>you can see where this is going: the documentation (and the install
>>>program) wanted X * 1048576 bytes, while the disk on the test machine
>>>had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
>>>can make a difference.[/color]
>>
>>
>> But when you hit "properties " on the disk drive, it will tell you the
>> amount of free space in units of 1048576 bytes. Your "trouble" is
>> imagined, and you're QA engineer is an idiot.[/color]
>
> Mr. Abel, you may insult me all you like, because
> I'm here to defend myself or ignore you or cave in to
> your onslaught as I deem proper. Hurling names like
> "idiot" at a conscientious Q/A engineer whom you've
> never met or exchanged a word with is another matter.[/color]

What reaction did this QA person get from the programmers who wrote the
installer?
[color=blue]
> For the record, the system in question reported
> available disk space in units of bytes. I was there;
> you were not.[/color]

Unless it reported available space in units of 1000000 bytes, it was
still not a bug.
[color=blue]
> Also for the record, there's a difference between
> "you're" and "your." Learn the difference and apply
> your knowledge, and your prose will gain an appearance
> of authority. Perhaps.[/color]

It was a typo.
[color=blue][color=green]
>> Incidentally, it is impossible to predict _exactly_ the amount of
>> space that will be needed, to the byte, because the size of each file
>> is rounded up to an unknown [well, known, but varies by system and
>> even by drive] power of two, and directories also take up space, so
>> the whole attempt is flawed, and it would probably have failed
>> anyway.[/color]
>
> Mr. Abel, I was there; you were not. When I gave the
> installation procedure the X * 1048576 bytes it wanted, lo!
> the product installed just fine. So much for "probably
> would have failed anyway."[/color]

It's possible that it rounded its result up. It _is_ impossible to know
it exactly, because it can depend on whether directories in the
installation path already existed, what block size the filesystem uses
[you deny it uses one at all, but i'd like proof if you really think
that], and any number of other factors.
[color=blue]
> For the record, the system in question did not round
> file sizes up to powers of two.[/color]

To _any_ power of two? Your filesystem is apparently magic.

a 1-byte file doesn't take up 512 bytes or more on disk? What about
space needed for its filename, etc, in the directory? Does a file with
a name seven letters long take a byte less on disk than one with a name
eight letters long? If you have a million 1-byte files, that will only
take a megabyte, or, at least, will take a megabyte less space than
a million 2-byte files? I seriously doubt that.
[color=blue][color=green]
>> Say what you will about the 1024-based units, but with the SOLE
>> exception of the number printed on the box that the drive comes in,
>> it's internally consistent.[/color]
>
> Herein you are right: A mis-measurement is consistent
> with itself. However, he who calibrates a meter stick by
> measuring it against itself does surprisingly little to
> advance the cause of knowledge.[/color]

And he who complains that a meter stick is 9.3% longer than a yard, and
that you should report yards as meters to accomodate people using the
imperial system, does even less. 1000000-byte megabytes are as
out-of-place on computers as feet, yards, and miles are elsewhere.

[David Resnick]

Re: size in kbytes?

Jordan Abel wrote:[color=blue]
> On 2006-03-30, Eric Sosman <Eric.Sosman@su n.com> wrote:[color=green]
> >
> >
> > Jordan Abel wrote On 03/30/06 12:39,:[color=darkred]
> >> On 2006-03-30, Eric Sosman <esosman@acm-dot-org.invalid> wrote:
> >>
> >>> Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
> >>>last-minute bug-fixing before product release, and one of the Q/A
> >>>people reported a bug in the installation phase. The documentation
> >>>said installation required X megabytes of available disk space, so
> >>>the Q/A engineer decided to make sure it would actually work. He
> >>>filled a disk with garbage files until only X megabytes of free
> >>>space remained, then tried to install. The installation failed for
> >>>lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
> >>>you can see where this is going: the documentation (and the install
> >>>program) wanted X * 1048576 bytes, while the disk on the test machine
> >>>had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
> >>>can make a difference.
> >>
> >>
> >> But when you hit "properties " on the disk drive, it will tell you the
> >> amount of free space in units of 1048576 bytes. Your "trouble" is
> >> imagined, and you're QA engineer is an idiot.[/color]
> >
> > Mr. Abel, you may insult me all you like, because
> > I'm here to defend myself or ignore you or cave in to
> > your onslaught as I deem proper. Hurling names like
> > "idiot" at a conscientious Q/A engineer whom you've
> > never met or exchanged a word with is another matter.[/color]
>
> What reaction did this QA person get from the programmers who wrote the
> installer?
>[/color]

Sounds like a good QA guy to me. He read the requirements and
constructed a test based on his reading of them. If you believe
that no reasonable end users (and many end users are not
reasonable) would interpret the documentation as the QA guy did,
well, I think you are wrong. I've had bugs assigned to me by
QA I thought were based on bizarre reading of requirements docs,
but this one wouldn't make me blink. No call to say he is an idiot.

-David

[Pedro Graca]

Re: size in kbytes?

Martin Jørgensen wrote:[color=blue]
> I still
> don't know whether to use 1024 or 1000, but I think I'll write KB after
> the number...[/color]

Your best option would be to let the user decide:

/* read config values from initialization file, or command line
* switches, or environment variables. */
config->user.unitsiz e = 1728;
config->user.unitdes c = " great gross bytes";

/* ... */

printf("Total amount of allocated memory is: %lu%s.\n",
(unsigned long) mem / config->user.unitsiz e,
config->user.unitdesc) ;


--
If you're posting through Google read <http://cfaj.freeshell. org/google>

[Jordan Abel]

Re: size in kbytes?

On 2006-03-30, David Resnick <lndresnick@gma il.com> wrote:[color=blue]
> Jordan Abel wrote:[color=green]
>> On 2006-03-30, Eric Sosman <Eric.Sosman@su n.com> wrote:[color=darkred]
>> >
>> >
>> > Jordan Abel wrote On 03/30/06 12:39,:
>> >> On 2006-03-30, Eric Sosman <esosman@acm-dot-org.invalid> wrote:
>> >>
>> >>> Does the inaccuracy cause trouble? Yes! At a PPOE I was doing
>> >>>last-minute bug-fixing before product release, and one of the Q/A
>> >>>people reported a bug in the installation phase. The documentation
>> >>>said installation required X megabytes of available disk space, so
>> >>>the Q/A engineer decided to make sure it would actually work. He
>> >>>filled a disk with garbage files until only X megabytes of free
>> >>>space remained, then tried to install. The installation failed for
>> >>>lack of sufficient space, and the Q/A engineer filed a bug. I'm sure
>> >>>you can see where this is going: the documentation (and the install
>> >>>program) wanted X * 1048576 bytes, while the disk on the test machine
>> >>>had only X * 1000000 bytes available. Yes, Virginia, a 4.9% error
>> >>>can make a difference.
>> >>
>> >>
>> >> But when you hit "properties " on the disk drive, it will tell you the
>> >> amount of free space in units of 1048576 bytes. Your "trouble" is
>> >> imagined, and you're QA engineer is an idiot.
>> >
>> > Mr. Abel, you may insult me all you like, because
>> > I'm here to defend myself or ignore you or cave in to
>> > your onslaught as I deem proper. Hurling names like
>> > "idiot" at a conscientious Q/A engineer whom you've
>> > never met or exchanged a word with is another matter.[/color]
>>
>> What reaction did this QA person get from the programmers who wrote the
>> installer?
>>[/color]
>
> Sounds like a good QA guy to me. He read the requirements and
> constructed a test based on his reading of them. If you believe
> that no reasonable end users (and many end users are not
> reasonable) would interpret the documentation as the QA guy did,
> well, I think you are wrong. I've had bugs assigned to me by
> QA I thought were based on bizarre reading of requirements docs,
> but this one wouldn't make me blink. No call to say he is an idiot.[/color]

It's still not a bug. I hope that the response was to put a clarifying
sentence in the documentation, rather than to change the installer to
use 1000000 instead.

[David Resnick]

Re: size in kbytes?

Jordan Abel wrote:[color=blue]
> On 2006-03-30, David Resnick <lndresnick@gma il.com> wrote:[color=green]
> > Sounds like a good QA guy to me. He read the requirements and
> > constructed a test based on his reading of them. If you believe
> > that no reasonable end users (and many end users are not
> > reasonable) would interpret the documentation as the QA guy did,
> > well, I think you are wrong. I've had bugs assigned to me by
> > QA I thought were based on bizarre reading of requirements docs,
> > but this one wouldn't make me blink. No call to say he is an idiot.[/color]
>
> It's still not a bug. I hope that the response was to put a clarifying
> sentence in the documentation, rather than to change the installer to
> use 1000000 instead.[/color]

I believe it is a documentation bug (at least where I work, we can
and do file defects against documentation). I also think it was
maybe a bug not to pad the required disk space a bit more, which
would have made the 4% difference moot, as any other process
mucking with the disk during the install could quite easily push
the thing over the edge.

-David

[Stephen Sprunk]

Re: size in kbytes?

"Martin Jørgensen" <unoder.spam@sp am.jay.net> wrote in message
news:s01tf3-9ha.ln1@news.td c.dk...[color=blue]
> Nils O. Selåsdal wrote:[color=green]
>> Depends on your definition of kilobyte
>> http://en.wikipedia.org/wiki/Kilobyte[/color]
>
> What would you use and why? What's "normal" ?
>
> I think 1024 is more correct...?[/color]

"kilo" officially means 1000; the official prefix for 1024 is "kibi".
However, common use is to use the standard prefixes to mean powers of 2 for
things measured in bytes (except hard drive packaging) and powers of 10 for
things measured in bits. This is officially incorrect, but it's pervasive.

So, Ethernet is 10Mb/s, which is 10,000,000 bits/sec, whereas 16MB of RAM is
16,777,216 bytes. However, a "300GB" hard drive will be 300,000,000,000
bytes (roughly), not the 322,122,547,200 bytes most consumers expect, though
your OS will report the size as 279GB (following common use).

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***

[Jordan Abel]

Re: size in kbytes?

On 2006-03-30, Stephen Sprunk <stephen@sprunk .org> wrote:[color=blue]
> "Martin Jørgensen" <unoder.spam@sp am.jay.net> wrote in message
> news:s01tf3-9ha.ln1@news.td c.dk...[color=green]
>> Nils O. Selåsdal wrote:[color=darkred]
>>> Depends on your definition of kilobyte
>>> http://en.wikipedia.org/wiki/Kilobyte[/color]
>>
>> What would you use and why? What's "normal" ?
>>
>> I think 1024 is more correct...?[/color]
>
> "kilo" officially means 1000; the official prefix for 1024 is "kibi".
> However, common use is to use the standard prefixes to mean powers of 2 for
> things measured in bytes (except hard drive packaging) and powers of 10 for
> things measured in bits. This is officially incorrect, but it's pervasive.
>
> So, Ethernet is 10Mb/s, which is 10,000,000 bits/sec, whereas 16MB of RAM is
> 16,777,216 bytes. However, a "300GB" hard drive will be 300,000,000,000
> bytes (roughly), not the 322,122,547,200 bytes most consumers expect, though
> your OS will report the size as 279GB (following common use).
>
> S[/color]

To summarize: Don't use "K". If you use "k", use 1000. Don't use 1000.
Use 1024. If you use 1024, use "Ki" and NOT "k". Don't use "b", that
means bits. "%lu KiB",(unsigned long)(x/1024) is the right way, "%lu \
kB",(unsigned long)(x/1000) is the wrong way, and none of the other ways
make any sense at all.

Any disagreement?

[Mark McIntyre]

Re: size in kbytes?

On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
<stephen@sprunk .org> wrote:
[color=blue]
>"Martin Jørgensen" <unoder.spam@sp am.jay.net> wrote in message
>news:s01tf3-9ha.ln1@news.td c.dk...[color=green]
>> Nils O. Selåsdal wrote:[color=darkred]
>>> Depends on your definition of kilobyte
>>> http://en.wikipedia.org/wiki/Kilobyte[/color]
>>
>> What would you use and why? What's "normal" ?
>>
>> I think 1024 is more correct...?[/color]
>
>"kilo" officially means 1000;[/color]

indeed. Except in computing, where, since the dawn of time, it has
meant 1024.
[color=blue]
>the official prefix for 1024 is "kibi".[/color]

That is absolutely the very first time I've ever heard anyone claim
that and be serious. I'm aware of the IEC attempt to standardise, but
frankly nobody in the world uses these aburd francisations.

And by teh way given Wikipedia's record on correctness, the only way
I'd rely on it now is if I could cross check against a copy of the
Encyclopedia Britannica...
gd&r

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

Re: size in kbytes?

On 30 Mar 2006 21:36:25 GMT, in comp.lang.c , Jordan Abel
<random832@gmai l.com> wrote:
[color=blue]
>To summarize: Don't use "K". If you use "k", use 1000. Don't use 1000.
>Use 1024. If you use 1024, use "Ki" and NOT "k". Don't use "b", that
>means bits. "%lu KiB",(unsigned long)(x/1024) is the right way, "%lu \
>kB",(unsigne d long)(x/1000) is the wrong way, and none of the other ways
>make any sense at all.
>
>Any disagreement?[/color]

Make mine a large one, barman.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Re: size in kbytes?

Mark McIntyre <markmcintyre@s pamcop.net> writes:[color=blue]
> On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
> <stephen@sprunk .org> wrote:[/color]
[...][color=blue][color=green]
>>the official prefix for 1024 is "kibi".[/color]
>
> That is absolutely the very first time I've ever heard anyone claim
> that and be serious. I'm aware of the IEC attempt to standardise, but
> frankly nobody in the world uses these aburd francisations.
>
> And by teh way given Wikipedia's record on correctness, the only way
> I'd rely on it now is if I could cross check against a copy of the
> Encyclopedia Britannica...
> gd&r[/color]

Ok, quoting the Britannica article on "byte" (Encyclopaedia Britannica
2006 Ultimate Reference Suite DVD):

Because a byte contains so little information, the processing and
storage capacities of computer hardware are usually given in
kilobytes (1,024 bytes) or megabytes (1,048,576 bytes). Still
larger capacities are expressed in gigabytes (about one billion
bytes) and terabytes (one trillion bytes).

It's true that the metric system claimed the "kilo", "mega", et al
prefixes as powers of 10 before they were used in computing. It's
also true that, in most computing contexts, it's far more useful to
work with powers of 2 than with powers of 10. If there's blame to be
assigned for the resulting confusion, it probably goes to the computer
science folks who started mis-using the existing prefixes.

I did hear 65536-byte memories being referred to as "65K" in the late
1970s; these days, I think they'd almost universally be referred to as
"64K".

The "kibi" "mebi" et al prefixes seem like a reasonable way to deal
with the conflict, but the use of "kilo" for 1024, "mega" for 1048576,
etc., is probably too entrenched to be eliminated -- so we'll probably
just have to deal with the confusion until the end of time.
(Introducing an improved standard in 1999 seems not to be best way to
have it catch on.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jordan Abel]

Re: size in kbytes?

On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> Mark McIntyre <markmcintyre@s pamcop.net> writes:[color=green]
>> On Thu, 30 Mar 2006 14:37:21 -0600, in comp.lang.c , "Stephen Sprunk"
>> <stephen@sprunk .org> wrote:[/color]
> [...][color=green][color=darkred]
>>>the official prefix for 1024 is "kibi".[/color]
>>
>> That is absolutely the very first time I've ever heard anyone claim
>> that and be serious. I'm aware of the IEC attempt to standardise, but
>> frankly nobody in the world uses these aburd francisations.
>>
>> And by teh way given Wikipedia's record on correctness, the only way
>> I'd rely on it now is if I could cross check against a copy of the
>> Encyclopedia Britannica...
>> gd&r[/color]
>
> Ok, quoting the Britannica article on "byte" (Encyclopaedia Britannica
> 2006 Ultimate Reference Suite DVD):
>
> Because a byte contains so little information, the processing and
> storage capacities of computer hardware are usually given in
> kilobytes (1,024 bytes) or megabytes (1,048,576 bytes). Still
> larger capacities are expressed in gigabytes (about one billion
> bytes) and terabytes (one trillion bytes).
>
> It's true that the metric system claimed the "kilo", "mega", et al
> prefixes as powers of 10 before they were used in computing. It's
> also true that, in most computing contexts, it's far more useful to
> work with powers of 2 than with powers of 10. If there's blame to be
> assigned for the resulting confusion, it probably goes to the computer
> science folks who started mis-using the existing prefixes.
>
> I did hear 65536-byte memories being referred to as "65K" in the late
> 1970s; these days, I think they'd almost universally be referred to as
> "64K".
>
> The "kibi" "mebi" et al prefixes seem like a reasonable way to deal
> with the conflict, but the use of "kilo" for 1024, "mega" for 1048576,
> etc., is probably too entrenched to be eliminated -- so we'll probably
> just have to deal with the confusion until the end of time.
> (Introducing an improved standard in 1999 seems not to be best way to
> have it catch on.)[/color]

My solution is to abbreviate it as "Ki" but pronounce it as "kilo" in
the privacy of my own home. And/or abbreviate "KiB" further to "K".

[Stephen Sprunk]

Re: size in kbytes?

"Jordan Abel" <random832@gmai l.com> wrote in message
news:slrne2ok0o .21gm.random832 @random.yi.org. ..[color=blue]
> On 2006-03-30, Stephen Sprunk <stephen@sprunk .org> wrote:[color=green]
>> "kilo" officially means 1000; the official prefix for 1024 is "kibi".
>> However, common use is to use the standard prefixes to mean powers
>> of 2 for things measured in bytes (except hard drive packaging) and
>> powers of 10 for things measured in bits. This is officially incorrect,
>> but it's pervasive.
>>
>> So, Ethernet is 10Mb/s, which is 10,000,000 bits/sec, whereas 16MB
>> of RAM is 16,777,216 bytes. However, a "300GB" hard drive will be
>> 300,000,000,000 bytes (roughly), not the 322,122,547,200 bytes most
>> consumers expect, though your OS will report the size as 279GB
>> (following common use).[/color]
>
> To summarize: Don't use "K". If you use "k", use 1000. Don't use 1000.
> Use 1024. If you use 1024, use "Ki" and NOT "k". Don't use "b", that
> means bits. "%lu KiB",(unsigned long)(x/1024) is the right way, "%lu \
> kB",(unsigned long)(x/1000) is the wrong way, and none of the other ways
> make any sense at all.
>
> Any disagreement?[/color]

Personally, if it were my code I'd conform to popular usage (kilo=1024)
unless it were in a context where it actually mattered (it almost never
does), and then I'd add a config option for the pedants.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***

[Richard Bos]

Re: size in kbytes?

"Stephen Sprunk" <stephen@sprunk .org> wrote:
[color=blue]
> "Martin Jørgensen" <unoder.spam@sp am.jay.net> wrote in message
> news:s01tf3-9ha.ln1@news.td c.dk...[color=green]
> > Nils O. Selåsdal wrote:[color=darkred]
> >> Depends on your definition of kilobyte
> >> http://en.wikipedia.org/wiki/Kilobyte[/color]
> >
> > What would you use and why? What's "normal" ?
> >
> > I think 1024 is more correct...?[/color]
>
> "kilo" officially means 1000; the official prefix for 1024 is "kibi".[/color]

Theoretically. I've never seen them used except by official publications
of engineers' associations and the writings of dorks who think they're
kewl.

Richard