home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0097.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.6 KB
  1. From:  Dominic Dunlop <domo@tsa.co.uk>
  2.  
  3. In article <754@longway.TIC.COM> gwyn@smoke.brl.mil (Doug Gwyn) fulminates
  4. > The ANSI magtape format is simply inappropriate.  UNIX archives were
  5. > designed to be single files, making it simple to transport them by
  6. > means other than magnetic tape.  In this modern networked world, for
  7. > the most part magnetic tape is an anachronism.  Any archive format
  8. > standard for UNIX should not depend on the archive supporting
  9. > multiple files, tape marks, or any other non-UNIX concept.
  10.  
  11. Er.  As Jason Zions points out in <770@longway.TIC.COM>,
  12. > A significant branch of the UNIX(tm)-system and POSIX research community
  13. > believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks
  14. > are among the leaders here. I feel only slightly squeamish about accusing
  15. > them of having only a hammer in their toolbelt; of *course* everything
  16. > looks like a nail!
  17.  
  18. The network as a featureless data stream is another example of the same
  19. ``traditional'' thinking in the UNIX community.  Actually, the
  20. datagram-based schemes favoured in the US (oversimplifying grossly, we
  21. Europeans have a preference for connection-based systems which do deliver
  22. streams) can provide nice record boundaries, which could in turn be used to
  23. delimit labels for the proposed tape archive format (after adding some
  24. reliability and sequencing).  Just because the format is based on IS 1003
  25. for labelled magnetic tapes does not mean to say that it cannot be used on
  26. other media, networks among tham.  After all, tar's a format for blocked
  27. magnetic tapes, but that hasn't stopped us moving tar archives over
  28. networks.
  29. -- 
  30. Dominic Dunlop
  31.  
  32. Volume-Number: Volume 20, Number 96
  33.  
  34.