NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/arch/11815

Text File | 1992-12-21 | 5.3 KB | 115 lines

Newsgroups: comp.arch
Path: sparky!uunet!think.com!ames!pacbell.com!UB.com!quack!dfox
From: [e-mail] (David Fox)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Message-ID: <[e-mail]>
Organization: The Duck Pond public unix: [phone], log in as 'guest'.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: 21 Dec 1992 01:41:34 UTC
Lines: 104

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (David Fox) writes:
>
>|>>|>> So far, the most "open" system I can think of is a 386 running DOS:
>|>>|>> - systems available from all sorts of people
>|>>|>> - CPU's available from (at least) AMD, Intel, IBM, and Cyrix
>|>
>|>shell out to the various software writers to try those compilers out.
>|>With Unix, one can get gcc for free, including source.
>
>In the old days you used to get C free with the O/S. In fact it was the biggest
>selling point about ten years ago when a compiler was something few people could
>afford.

Yes that's apparently true, but I wasn't around in the 'old days'.  Many
Unixes include a compiler as part of the OS, but it's not exactly free, as
the price for the OS is jacked up accordingly.

>Yep now there is a closed system. Or rather it was intended to be. IBM did not
>expect nor intend the clone market to exist. It is noticable that their

No, but they did allow some openness.  The architecture was designed (or
was it accidental? :) ) to allow or make easier the existence of clones,
much in contrast to the macintosh.  Of course I consider this a good thing;
one interesting product of all this is that when you want a Mac peripheral
(like a hard drive) it costs easily three times as much as an equivalent
peripheral for IBM architecture-based machines.

>graphics (in a sensible place) and high capacity disks. IBM confined it's
>inovation to the keyboard layout.

Is that innovation?  The F-keys belong on the left where God intended
them to be! :)

>WARNING: terminal cannot home cursor
>WARNING: terminal cannot move cursor to lower left of screen
>WARNING: terminal cannot scroll backwards
>-  (press RETURN)
>
>Name
>     dd - copy and convert data
>
>
>Note the warnings caused by sysop hackery since my last login. Let us hope that
>MSdos never has a dd command. A CONVERT command perhaps.

Notwithstanding the warnings, which have to do properly with your man(1)
not dd, dd isn't just a conversion tool, although it can be used nicely
for that.

Until recently I didn't know what a dd was.  I was using DOS, and doing a
lot of file transferring over many years on DOS-based Bulletin Board
Systems.  We went through various file-transfer protocols and settled on
Zmodem with file recovery.  Before then, if the transfer was interrupted,
you had no choice but to resume the download in its entirety.

More recently, I was on a unix system getting a file with a version of
sz that didn't have file recovery (no -r switch).  The transfer was
interrupted, and I was dreadful, about to face a long session of re-
downloading the file (which was about one megabyte).  In desperation,
I contacted the system administrator, who informed me on how to use
dd, including the skip= parameter.  I tried it - calculated the
number of blocks to skip (not difficult) and wrote the remainder to
another file, and downloaded that, reconstructing the file on my
end.  Needless to say, I was pretty impressed.  I thought to myself,
"What have I been missing all these years with MS-DOS?"

dd is also extremely useful when splitting a large file across floppies,
something that MS-DOS doesn't do by itself, although many authors have
developed proprietary methods to do this and other (unrelated) things.

That's essentially what I use dd for - I rarely need the conversion
facilities, actually.

>Let us also hope that a future CONVERT command would consider *THESE*
>conversions an irrelevance!

What would it do, look at the incoming byte stream and become convinced
that it is ascii or ebcdic?  How?

Most MS-DOS users don't get data on 9-track tapes in EBCDIC anyway.  Heck,
they can't even use their tape drive for things other than what the manu-
facturer's proprietary program allows them to use it for.


>A little though could elimintate the need for this command entirely. The
>apparent purpose of the command is to match device capabilities. This would
>argue for attributes to be applied to the device:-

dd has many uses - you're emphasizing some and I'm ephasizing others, of
course.  The format-matching capabilities wouldn't get used much by MS-DOS
users, sure.  But it could have other uses.  For instance, dd is how I
copy disks in Unix all the time.  With MS-DOS, I have to use diskcopy, and
that program isn't intelligent enough to do the copy in a single pass! (DR-
DOS's version can, of course, and that's one reason I started to use DR.)
With dd, I can simply send an image of a 1.2 meg floppy to a 1.44 meg floppy
- MS-DOS has never been able to do that.

>thinking in which simple and straightforward tasks are reduced to mystic
>cabalistic rites whose mysteries are to be known but to the few.

Maybe but what is the alternative?  Macintosh?  Where you have to use
a mouse to drag a file to a trashcan because 'rm' or 'del' is too
arcane a command for people to use?