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