Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.unix.wizards
Subject: Re: Size of SysV "block" (really measuring files in bits vs. bytes).
Message-ID: <2804@phri.UUCP>
Date: Sun, 19-Jul-87 21:57:50 EDT
Article-I.D.: phri.2804
Posted: Sun Jul 19 21:57:50 1987
Date-Received: Mon, 20-Jul-87 03:47:49 EDT
References: <218@astra.necisa.oz> <142700010@tiger.UUCP>
Reply-To: roy@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 28


	Somebody, somewhere, some time ago, in some article wrote:

> How about sizing things in terms of number of bits, which is a
> universal measure.

	This unleashed a torrent of silly and not-so-silly articles on the
definition of a byte and cute names for N-bit chunks (to which I confess
contributing), but nobody really addressed this guy's question.  So...

	Yes, clearly bits is a more precise unit of information than bytes.
The problem with reporting file sizes in bits is that most of the time it's
not what people want to know.  What they really want to know is how many
characters long the file is (notice I said characters, not bytes).  If I
took a text file on a vax that was N characters long and moved it to a
DEC-20, it would still be N characters long.  Maybe my Vax uses 8 bits per
character and your DEC-20 uses 7-1/5 bits per character, but I don't want
to know about that (usually).

	On Unix, ls would show a byte count and on TOPS-20, DIR would show
a word count.  These numeric values would be different, but the number of
characters wouldn't have changed.  Well, maybe that's a bad example because
TOPS-20 would turn all the newlines into carriage-return/newline pairs, but
you get the idea.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016