home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0094.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  2.3 KB  |  46 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <1991Sep2.214221.26606@uunet.uu.net> djm@eng.umd.edu (David J. MacKenzie) writes:
  4. >You can get bits by multiplying bytes by 8, of course, but that's a
  5. >silly unit of measurement since you can't allocate individual bits
  6. >in a file.
  7.  
  8. Your STRAW MAN argument about allocating individual bits would perhaps
  9. be "silly", but I did not make that argument.  I did note that not all
  10. file sizes (expressed as number of bits) are exactly divisible by 8,
  11. which would make the 8-bit byte rather a silly unit of measure.  And
  12. other-size bytes more appropriate for such systems aren't necessarily
  13. any more useful.  While a 9-bit byte may be ideal for an 18-bit system,
  14. what would you use on a 60-bit system?
  15.  
  16. I don't think there is a large advantage to using bit sizing, although
  17. it does permit CORRECT, PRECISE information to be given in all cases.
  18. However, the argument that 1024 8-bit bytes is somehow an optimum unit
  19. of measurement for file sizes needs to be shot down.  It's just one of
  20. many possible arbitrary choices.  Most users of AT&T UNIX are
  21. accustomed to 512 8-bit bytes and most users of BSD are accustomed to
  22. 1024 8-bit bytes.  (I agree with the fellow who criticized the biased
  23. preference poll that was conducted.)  That doesn't make either of
  24. these "natural" or "best".  Instead of selecting one arbitrarily, it
  25. would make more sense to allow it to fit the system characteristics
  26. (i.e., use the system's minimum disk block size, which could be any
  27. positive size, and typically is either 512B or 4096B), or to allow the
  28. user to scale the units according to his own needs.
  29.  
  30. If a single size is nonetheless selected for the standard, it must
  31. make technical sense -- since many important systems allocate files
  32. in integral (perhaps odd) multiples of 512B, and those units can be
  33. used to correctly and accurately express sizes of files on systems
  34. that allocate in integral multiples of 1024B, while the reverse is
  35. NOT TRUE, obviously 512B would be better than 1024B for a standard
  36. that must accommodate both kinds of systems.  But flexibility would
  37. be better yet.
  38.  
  39. I must say that attempts to force "solutions" based on popularity
  40. polls rather than careful reasoning about the actual relevant
  41. factors is disgusting.  Demagogues would do us all a favor by staying
  42. out of the standardization process.
  43.  
  44. Volume-Number: Volume 24, Number 95
  45.  
  46.