OT: YKYBHTLW question.
RyanMcCoskrie
group?
John Varela
It is if you want it to be. All you have to do... and I hope you
do; I've missed it.
--
John Varela
Trade NEWlamps for OLDlamps for email
Gene Wirchenko
>Is "You Know You've Been Hacking To Long When" still posted on this news
>group?
I think it has been quite a while since we have had such a
thread. Mi, mi, mi:
...when someone puffs about a new and "improved" computer system, you
can come up with a probable flaw in under ten seconds.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Robert Billing
> ....when someone puffs about a new and "improved" computer system, you
> can come up with a probable flaw in under ten seconds.
Someone says "Mount Everest" and you think "everest not in fstab".
--
I am Robert Billing, Christian, author, inventor, traveller, cook and
animal lover. "It burned me from within. It quickened; I was with book
as a woman is with child."
Quality e-books for portable readers: http://www.alex-library.com
jmfbahciv
> RyanMcCoskrie <ryan.mc...@NOSPAMgmail.com> wrote:
>
>> Is "You Know You've Been Hacking To Long When" still posted on this news
>> group?
>
> I think it has been quite a while since we have had such a
> thread. Mi, mi, mi:
>
> ...when someone puffs about a new and "improved" computer system, you
> can come up with a probable flaw in under ten seconds.
>
/BAH
jmfbahciv
> Gene Wirchenko wrote:
>
>> ....when someone puffs about a new and "improved" computer system, you
>> can come up with a probable flaw in under ten seconds.
>
> Someone says "Mount Everest" and you think "everest not in fstab".
>
Aw, hell. I didn't understand that one. Translation, please?
/BAH
Ahem A Rivet's Shot
Robert Billing <uncl...@tnglwood.demon.co.uk> wrote:
> Gene Wirchenko wrote:
>
> > ....when someone puffs about a new and "improved" computer system, you
> > can come up with a probable flaw in under ten seconds.
>
> Someone says "Mount Everest" and you think "everest not in fstab".
Then you wonder when fstab became case insensitive.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
grey...@mail.com
/etc/fstab is a list of volumes available at startup. In the _REAL_
operating system. (<Duck>)
--
Greymaus
.
.
...
Joe Pfeiffer
And "mount" is the command that makes the disk's file system visible as
a part of the computer's entire file system.
Charles Richmond
> Gene Wirchenko wrote:
>
>> ....when someone puffs about a new and "improved" computer system, you
>> can come up with a probable flaw in under ten seconds.
>
> Someone says "Mount Everest" and you think "everest not in fstab".
>
Geat idea!!! I'll have to add a file system "everest" now... :-)
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Charles Richmond
The file system from fstab is mounted over a directory that exists in
the file structure, so that it *appears* everything is connected
physically... when actually all the several file systems may span many
physical drives. The directory where you "glue" the new file system...
is known as the "mount point".
Gene Wirchenko
Too much reading of RISKS. I used to be more trusting; now, I am
much more suspicious.
Gene Wirchenko
>Gene Wirchenko wrote:
>
>> ....when someone puffs about a new and "improved" computer system, you
>> can come up with a probable flaw in under ten seconds.
>
>Someone says "Mount Everest" and you think "everest not in fstab".
Someone writes the above and you wonder what is wrong about it.
(That should be a small m in "Mount".)
RyanMcCoskrie
> Robert Billing wrote:
>> Gene Wirchenko wrote:
>>
>>> ....when someone puffs about a new and "improved" computer system, you
>>> can come up with a probable flaw in under ten seconds.
>>
>> Someone says "Mount Everest" and you think "everest not in fstab".
>>
>
> Geat idea!!! I'll have to add a file system "everest" now... :-)
>
Where are you going to get a drive with the volume?
There's no point in calling it everest if it isn't big enough to
qualify.
RyanMcCoskrie
> RyanMcCoskrie <ryan.mc...@NOSPAMgmail.com> wrote:
>
>>Is "You Know You've Been Hacking To Long When" still posted on this news
>>group?
>
> I think it has been quite a while since we have had such a
> thread. Mi, mi, mi:
>
> ...when someone puffs about a new and "improved" computer system, you
> can come up with a probable flaw in under ten seconds.
>
You know you've been hacking to long when...
... You redesign English to be more like C.
... You have a dream that you controll your computer telepathically.
Both of these have happend to me.
PS:
On a vaguely related topic I over dosed on Science Fiction one summer.
jmfbahciv
> jmfbahciv <jmfbahciv@aol> wrote:
>
>> Gene Wirchenko wrote:
>>> RyanMcCoskrie <ryan.mc...@NOSPAMgmail.com> wrote:
>>>
>>>> Is "You Know You've Been Hacking To Long When" still posted on this news
>>>> group?
>>> I think it has been quite a while since we have had such a
>>> thread. Mi, mi, mi:
>>>
>>> ...when someone puffs about a new and "improved" computer system, you
>>> can come up with a probable flaw in under ten seconds.
>>>
>> I do like your tune.
>
> Too much reading of RISKS. I used to be more trusting; now, I am
> much more suspicious.
>
/BAH
jmfbahciv
Mine was I wrote my functional spec and was so glad it was done; then
I woke up. Note that I would not have been a writer even if DEC paid
me a million dollars a day).
/BAH
jmfbahciv
monkey. I get it now.
/BAH
grey...@mail.com
I keep thinking that it would be easier to address a letter to
g...@rathdowney.laois.ie
rather than
George M*
Rathdowney
Laois
Ireland
(snailmail)
Chris Barts
> Joe Pfeiffer wrote:
>> grey...@mail.com writes:
>>
>>> On 2009-06-24, jmfbahciv <jmfbahciv@aol> wrote:
>>>> Robert Billing wrote:
>>>>> Gene Wirchenko wrote:
>>>>>
>>>>>> ....when someone puffs about a new and "improved" computer system, you
>>>>>> can come up with a probable flaw in under ten seconds.
>>>>> Someone says "Mount Everest" and you think "everest not in fstab".
>>>>>
>>>> Aw, hell. I didn't understand that one. Translation, please?
>>>>
>>>> /BAH
>>> /etc/fstab is a list of volumes available at startup. In the _REAL_
>>> operating system. (<Duck>)
>>
>> And "mount" is the command that makes the disk's file system visible as
>> a part of the computer's entire file system.
>
> The file system from fstab is mounted over a directory that exists in
> the file structure, so that it *appears* everything is connected
> physically... when actually all the several file systems may span many
> physical drives. The directory where you "glue" the new file system...
> is known as the "mount point".
The underlying concept is that in Unix, like in Multics and *unlike*
any DEC or Microsoft OS I know of, the filesystem has a single root,
called / in Unix, and everything in the filesystem, regardless of what
physical volume it resides on, can be reached by recursing down into
directories beginning at the root. There's no such thing as a device
specification or a drive letter.
What mount does is attaches a filesystem on a specific physical device
(represented as a special file in the /dev directory) to a specified
'mount point' within the filesystem's tree. A mount point is just a
directory; when the filesystem is mounted, the directory is populated
with the contents of that device's filesystem.
/etc/fstab is a text file that contains predefined mappings between
physical devices and mount points. For example, the line:
/dev/sda7 /home ext3
says that the device /dev/sda7 is to be mounted at the directory
/home. ext3 is the filesystem in use on that device. /etc/fstab is
typically used to list the devices that should be automatically
mounted at boot, plus a few others that will likely be used later on
(the CD-ROM drive in desktop machines, for example).
Tony Toews [MVP]
> Too much reading of RISKS. I used to be more trusting; now, I am
>much more suspicious.
One of my favourite newsgroups. I also quite enjoy The Daily WTF and the Coding
Horror blogs.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/
RyanMcCoskrie
> jmfbahciv <jmfbahciv@aol> wrote:
>
>>Gene Wirchenko wrote:
>>> RyanMcCoskrie <ryan.mc...@NOSPAMgmail.com> wrote:
>>>
>>>> Is "You Know You've Been Hacking To Long When" still posted on this
>>>> news group?
>>>
>>> I think it has been quite a while since we have had such a
>>> thread. Mi, mi, mi:
>>>
>>> ...when someone puffs about a new and "improved" computer system, you
>>> can come up with a probable flaw in under ten seconds.
>>>
>>I do like your tune.
>
> Too much reading of RISKS. I used to be more trusting; now, I am
> much more suspicious.
>
Which newsgroup is that?
Howard S Shubs
RyanMcCoskrie <ryan.mc...@NOSPAMgmail.com> wrote:
> Where are you going to get a drive with the volume?
> There's no point in calling it everest if it isn't big enough to
> qualify.
Bare 1TB drives were $90 a few weeks ago.
--
Don't bother with piddly crap like "gun control".
Life is 100% fatal. Ban it.
jmfbahciv
> Gene Wirchenko <ge...@ocis.net> wrote:
>
>> Too much reading of RISKS. I used to be more trusting; now, I am
>> much more suspicious.
>
> One of my favourite newsgroups. I also quite enjoy The Daily WTF and the Coding
> Horror blogs.
>
like being scared :-).
/BAH
jmfbahciv
Look up MFD [master file directory]. Or find a TOPS-10 system and
type:
DIRECT [1,1]
<snip>
/BAH
sidd
> Which newsgroup is that?
comp.risks
Michael Wojcik
>
> The underlying concept is that in Unix, like in Multics and *unlike*
> any DEC or Microsoft OS I know of, the filesystem has a single root,
> called / in Unix, and everything in the filesystem, regardless of what
> physical volume it resides on, can be reached by recursing down into
> directories beginning at the root.
Windows has been able to do this too, for the past decade or so, using
reparse points; it even provides the mountvol command to create them.
But few people use this feature. And there's still at least one drive
specifier, for the root filesystem, though in practice it can be ignored.
And, of course, even old MS-DOS has had the "join" command (I think in
versions 2 through 5), which could be used to simulate a single
hierarchical filesystem for most purposes. It confused some programs,
though.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
> Charles Richmond wrote:
>> Geat idea!!! I'll have to add a file system "everest" now... :-)
>
> Where are you going to get a drive with the volume?
> There's no point in calling it everest if it isn't big enough to
> qualify.
The main attribute of Mount Everest these days seems to be that it's
where yuppie idiots go to kill themselves and leave lots of trash
lying about. That describes most PC filesystems I've seen, so
"everest" would be a good name for, say, an NTFS filesystem you mount
under Linux for data recovery.
Tony Toews [MVP]
>>> Too much reading of RISKS. I used to be more trusting; now, I am
>>> much more suspicious.
>>
>> One of my favourite newsgroups. I also quite enjoy The Daily WTF and the Coding
>> Horror blogs.
>>
>An acquaintance told me that he didn't read comp.risks because he didn't
>like being scared :-).
Hehehehe Understandable.
CBFalconer
> Gene Wirchenko wrote:
>
>
>> Too much reading of RISKS. I used to be more trusting; now, I
>> am much more suspicious.
>
> Which newsgroup is that?
comp.risks
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Gene Wirchenko
>Gene Wirchenko <ge...@ocis.net> wrote:
>
>> Too much reading of RISKS. I used to be more trusting; now, I am
>>much more suspicious.
>
>One of my favourite newsgroups. I also quite enjoy The Daily WTF and the Coding
>Horror blogs.
While I read The Daily WTF, I think that it has jumped the shark.
There are too many twits posting.
I read Coding Horror occasionally.
Gene Wirchenko
[snip]
>PS:
>On a vaguely related topic I over dosed on Science Fiction one summer.
WUSS! (I have an immumity.)
grey...@mail.com
Disk A: (never did it since Win95)
Chris Barts
First floppy disk? ITYM C:, the first hard disk, or /dev/[hs]da in
Linux terminology.
From my own experience in installing Linux, this is true, and it's
also true that Windows has to be installed first because it demands
the MBR for its own purposes and will stomp on the Linux bootloader if
given a chance.
grey...@mail.com
> grey...@mail.com writes:
>
>>>
>> From memory in installing Linux on M$ machines, M$ liked to be on
>> Disk A: (never did it since Win95)
>
> First floppy disk? ITYM C:, the first hard disk, or /dev/[hs]da in
> Linux terminology.
You are correct, of course.
Frustrating thing in installing Linux, on USB's, say, is that the
device name can change if the order in which it boots changes.
>
> From my own experience in installing Linux, this is true, and it's
> also true that Windows has to be installed first because it demands
> the MBR for its own purposes and will stomp on the Linux bootloader if
> given a chance.
Walter Bushell
wrote:
> > /etc/fstab is a list of volumes available at startup. In the _REAL_
> > operating system. (<Duck>)
The _REAL_ operating system is Duck?
grey...@mail.com
Yes, my homebrew version of Knoppix :)).
Michael Wojcik
I'm not sure what you're getting at.
Floppy-based MS-DOS booted from drive A:. After booting, you could
redirect the loader to a different drive, so external OS utilities and
the reloadable part of command.com would be loaded from B: (the second
floppy drive) or somewhere else, such as a ramdisk.
Hard-drive-based MS-DOS booted from drive C:, the first hard drive.
But I don't see what this has to do with the join command, or creating
a single hierarchical file system.
grey...@mail.com
> grey...@mail.com wrote:
>> On 2009-06-26, Michael Wojcik <mwo...@newsguy.com> wrote:
>>>
>>> And, of course, even old MS-DOS has had the "join" command (I think in
>>> versions 2 through 5), which could be used to simulate a single
>>> hierarchical filesystem for most purposes. It confused some programs,
>>> though.
>>>
>> From memory in installing Linux on M$ machines, M$ liked to be on
>> Disk A: (never did it since Win95)
>
> I'm not sure what you're getting at.
>
> Floppy-based MS-DOS booted from drive A:. After booting, you could
> redirect the loader to a different drive, so external OS utilities and
> the reloadable part of command.com would be loaded from B: (the second
> floppy drive) or somewhere else, such as a ramdisk.
As was corrected, I meant C:
>
> Hard-drive-based MS-DOS booted from drive C:, the first hard drive.
>
> But I don't see what this has to do with the join command, or creating
> a single hierarchical file system.
Just a comment, I can boot Linux , an Unix-type system, from any of
the `drives' in front of me here, HD (any partition), USb stick, USB
HD, CDROM. Even, I belive but havn't tried yet, over the network.
Tony Toews [MVP]
>>One of my favourite newsgroups. I also quite enjoy The Daily WTF and the Coding
>>Horror blogs.
>
> While I read The Daily WTF, I think that it has jumped the shark.
>There are too many twits posting.
I seldom if ever read the comments. Unless they mention MS Access in which case I
post rebuttals to their derogatory comments. <smile>
CBFalconer
>
... snip ...
>
> Just a comment, I can boot Linux , an Unix-type system, from any
> of the `drives' in front of me here, HD (any partition), USb
> stick, USB HD, CDROM. Even, I belive but havn't tried yet, over
> the network.
The reason is simple. Unix files, on any drives, are all children
of \. This simplifies addressing.
Charles Richmond
> grey...@mail.com wrote:
> ... snip ...
>> Just a comment, I can boot Linux , an Unix-type system, from any
>> of the `drives' in front of me here, HD (any partition), USb
>> stick, USB HD, CDROM. Even, I belive but havn't tried yet, over
>> the network.
>
> The reason is simple. Unix files, on any drives, are all children
> of \. This simplifies addressing.
>
Children of "\"??? Don't you mean children of "/"???
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Roland Hutchinson
> CBFalconer wrote:
>> grey...@mail.com wrote:
>> ... snip ...
>>> Just a comment, I can boot Linux , an Unix-type system, from any
>>> of the `drives' in front of me here, HD (any partition), USb
>>> stick, USB HD, CDROM. Even, I belive but havn't tried yet, over
>>> the network.
>>
>> The reason is simple. Unix files, on any drives, are all children
>> of \. This simplifies addressing.
>>
>
> Children of "\"??? Don't you mean children of "/"???
rdh@dinkum:/$ cd /
rdh@dinkum:/$ cd ..
rdh@dinkum:/$ cd ..
rdh@dinkum:/$ pwd
/
rdh@dinkum:/$
Hey, how about that? I'm my own grandpa!
--
Roland Hutchinson
He calls himself "the Garden State's leading violist da gamba,"
... comparable to being ruler of an exceptionally small duchy.
--Newark (NJ) Star Ledger ( http://tinyurl.com/RolandIsNJ )
Lawrence Statton
> Charles Richmond wrote:
>
>> CBFalconer wrote:
>>> grey...@mail.com wrote:
>>> ... snip ...
>>>> Just a comment, I can boot Linux , an Unix-type system, from any
>>>> of the `drives' in front of me here, HD (any partition), USb
>>>> stick, USB HD, CDROM. Even, I belive but havn't tried yet, over
>>>> the network.
>>>
>>> The reason is simple. Unix files, on any drives, are all children
>>> of \. This simplifies addressing.
>>>
>>
>> Children of "\"??? Don't you mean children of "/"???
>
> rdh@dinkum:/$ cd /
> rdh@dinkum:/$ cd ..
> rdh@dinkum:/$ cd ..
> rdh@dinkum:/$ pwd
> /
> rdh@dinkum:/$
>
> Hey, how about that? I'm my own grandpa!
o/~ Many, many years ago when I was twenty-three ...
--L
Walter Bushell
Charles Richmond <fri...@tx.rr.com> wrote:
> CBFalconer wrote:
> > grey...@mail.com wrote:
> > ... snip ...
> >> Just a comment, I can boot Linux , an Unix-type system, from any
> >> of the `drives' in front of me here, HD (any partition), USb
> >> stick, USB HD, CDROM. Even, I belive but havn't tried yet, over
> >> the network.
> >
> > The reason is simple. Unix files, on any drives, are all children
> > of \. This simplifies addressing.
> >
>
> Children of "\"??? Don't you mean children of "/"???
I did think he had it backwards.
Peter Grange
<fri...@tx.rr.com> wrote:
>CBFalconer wrote:
>> grey...@mail.com wrote:
>> ... snip ...
>>> Just a comment, I can boot Linux , an Unix-type system, from any
>>> of the `drives' in front of me here, HD (any partition), USb
>>> stick, USB HD, CDROM. Even, I belive but havn't tried yet, over
>>> the network.
>>
>> The reason is simple. Unix files, on any drives, are all children
>> of \. This simplifies addressing.
>>
>
>Children of "\"??? Don't you mean children of "/"???
Yes "\" is the work of Stan. Condemning all BBC presenters to read
URLs as "www.dah.de.dahForwardSlash..."
--
Pete
Rich Alderson
> Chris Barts wrote:
>> The underlying concept is that in Unix, like in Multics and *unlike*
>> any DEC or Microsoft OS I know of, the filesystem has a single root,
>> called / in Unix, and everything in the filesystem, regardless of what
>> physical volume it resides on, can be reached by recursing down into
>> directories beginning at the root.
> Look up MFD [master file directory]. Or find a TOPS-10 system and
> type:
> DIRECT [1,1]
Not at all the same thing, Barb. If I have two structures DSKA: and DSKB: on a
Tops-10 system, there are two MFDs present, one for each filesystem.
On Unix filesystems, there is no equivalent to DSKA: and DSKB:. Instead, the
equivalents of RPA0: and RPB0: (device names, for you non-Tops-10 unfortunates)
are made available by attaching their contents to named directories in a pre-
existing directory structure (usually, but not always, directly under the root
of the directory tree).
It is as if, in order to use the files on RPA0: (since devices do not have
named filesystems on them), the MOUNT command had to associate them with a
directory on DSKB: (the usual first-mounted structure).
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
jmfbahciv
> jmfbahciv <jmfbahciv@aol> writes:
>
>> Chris Barts wrote:
>
>>> The underlying concept is that in Unix, like in Multics and *unlike*
>>> any DEC or Microsoft OS I know of, the filesystem has a single root,
>>> called / in Unix, and everything in the filesystem, regardless of what
>>> physical volume it resides on, can be reached by recursing down into
>>> directories beginning at the root.
>
>> Look up MFD [master file directory]. Or find a TOPS-10 system and
>> type:
>
>> DIRECT [1,1]
>
> Not at all the same thing, Barb. If I have two structures DSKA: and DSKB: on a
> Tops-10 system, there are two MFDs present, one for each filesystem.
And one can be defined to be the root equivalent of a UNIX system
area.
>
> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
Which is an absence of a feature, IMO, with Unix.
>Instead, the
> equivalents of RPA0: and RPB0: (device names, for you non-Tops-10 unfortunates)
> are made available by attaching their contents to named directories in a pre-
> existing directory structure (usually, but not always, directly under the root
> of the directory tree).
>
> It is as if, in order to use the files on RPA0: (since devices do not have
> named filesystems on them), the MOUNT command had to associate them with a
> directory on DSKB: (the usual first-mounted structure).
>
That makes moving packs from one system to another a tad dicey. The
reasons people would do this was in cases of disasters; this probably
wouldn't occur anymore becuase computer systems are so cheap and can
be bought off the shelf.
/BAH
Bill Pechter
>Rich Alderson wrote:
>> jmfbahciv <jmfbahciv@aol> writes:
>>
>>> Chris Barts wrote:
>>
>>>> The underlying concept is that in Unix, like in Multics and *unlike*
>>>> any DEC or Microsoft OS I know of, the filesystem has a single root,
>>>> called / in Unix, and everything in the filesystem, regardless of what
>>>> physical volume it resides on, can be reached by recursing down into
>>>> directories beginning at the root.
>>
>>> Look up MFD [master file directory]. Or find a TOPS-10 system and
>>> type:
>>
>>> DIRECT [1,1]
>>
>> Not at all the same thing, Barb. If I have two structures DSKA: and
>DSKB: on a
>> Tops-10 system, there are two MFDs present, one for each filesystem.
>
>And one can be defined to be the root equivalent of a UNIX system
>area.
>
>>
>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
>
>Which is an absence of a feature, IMO, with Unix.
>
>
Which as you say is your opinion.
The flexibility is the capability of expanding any part of the tree by
adding in a new drive and moving a segment of the data to it and mounting
it on the now empty directory (that used to hold the data).
In the VMS days all you could do is refer to it by logical names
SYS$MAINT --> could be DBA0:[sysmaint] or DRA0: or DBA1: ...
The flexibility to rearrange this (sometimes with the system live) was one
of the amazing things I saw with Unix.
Add in the *BSD's symbolic links and you can recover from problems without
rebooting the system.
Add in the current capability in software raid and you're light years
ahead of what was around in the '70's and early '80's for keeping systems
up.
VAXclusters still seem a little bit slicker than the Unix equivalents --
but that's because it was designed in to VMS in the V3/V4 days instead
of being grafted on.
Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org
Charles Richmond
> Rich Alderson wrote:
>>
>> [snip...] [snip...] [snip...]
>>
>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
>
> Which is an absence of a feature, IMO, with Unix.
>
In a sense, there *is* an equivalent to DSKA: and DSKB:. While it's
true that the "user" does *not* normally access disks by logical name,
in Unix there are physical volumes (disks) on which filesystems are
created. All the different filesystems are "mount"ed somewhere on
the directory tree-structure which begins with the root (/) directory.
Peter Flass
Also, packs aren't (re)movable anymore.
Rich Alderson
> Rich Alderson wrote:
>> Not at all the same thing, Barb. If I have two structures DSKA: and DSKB:
>> on a Tops-10 system, there are two MFDs present, one for each filesystem.
> And one can be defined to be the root equivalent of a UNIX system area.
I'm not quite certain what you are saying here. On Tops-10 (and TOPS-20, for
that matter), structures[1] are independent of one another. The structure from
which the OS is booted is generally the login structure, but that does not make
it the equivalent of a Unix-style root directory, because the semantics are
different.
>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
> Which is an absence of a feature, IMO, with Unix.
Yes and no. There have been times over the last 32 years when I would have
loved to have the seamlessness of a Unix filesystem on my PDP-10 OS, and not
have to worry about the fact that things were on separate devices. There have
also been times in the last 25 years when I would have liked to separate the
parts of a Unix filesystem and refer to them by name.
>> Instead, the equivalents of RPA0: and RPB0: (device names, for you
>> non-Tops-10 unfortunates) are made available by attaching their contents to
>> named directories in a pre-existing directory structure (usually, but not
>> always, directly under the root of the directory tree).
>> It is as if, in order to use the files on RPA0: (since devices do not have
>> named filesystems on them), the MOUNT command had to associate them with a
>> directory on DSKB: (the usual first-mounted structure).
> That makes moving packs from one system to another a tad dicey.
I don't see that that follows in any way, shape, or form.
I have multiple disks on a Unix box, mounted to different mount points under
the root directory. I need to move one or more to another box running the same
(or compatible) version of Unix, so I unmount them from the first box, cable
them to the second and mount them, and they're up and running.
I have multiple structures on a Tops-10 box, each composed of one or more
disks. I need to move one or more structures to another Tops-10 box, so I
unmount them, cable the drives to the second system, mount them appropriately,
and they're up and running.
Neither is any dicier than the other.
> The
> reasons people would do this was in cases of disasters; this probably
> wouldn't occur anymore becuase computer systems are so cheap and can
> be bought off the shelf.
Oh, my dear, disasters happen all the time, as do upgrades of equipment (which,
from one point of view, *is* a disaster). Disks get moved, filesystems get
mounted, and life goes on.
Notes for the Unix crowd:
[1] In these systems, structures consist of one or more physical disks over
which is overlaid a single filesystem, rather like logical volumes in
modern Unix implementations. Unlike Unix, a physical disk (or structure,
to carry on the LV parallel) cannot be partitioned.
Scott Lurndal
>Rich Alderson wrote:
>> jmfbahciv <jmfbahciv@aol> writes:
>> Not at all the same thing, Barb. If I have two structures DSKA: and DSKB: on a
>> Tops-10 system, there are two MFDs present, one for each filesystem.
>
>And one can be defined to be the root equivalent of a UNIX system
>area.
>
>>
>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
This is not true. The only difference between DSKA:/DSKB: (or DRA0: on VMS)
and Unix is that Unix replaces the prefix with a path element. For example, if
you had two disks (DSKA: and DSKB:) with unix filesystems on them, each disk
would have an MFD (or in Unix parlance, Superblock, Directory Blocks and Inodes)
and the disks would be grafted into the filesystem tree at an arbitrary point.
For example,
/dska/fred/barney will access a file in the directory "fred" named "barney" on DSKA:
/dskb/joe/sample will access a file called 'sample' in directory 'joe' on DSKB:
/root/betty/wilma/dskb/joe/sample Just grafts lower in the tree.
>
>Which is an absence of a feature, IMO, with Unix.
The feature is there, and much more flexible in unix.
scott
Scott Lurndal
sure they are. Think E-SATA, USB, or hot plug drive trays.
scott
Howard S Shubs
Peter Flass <Peter...@Yahoo.com> wrote:
> Also, packs aren't (re)movable anymore.
They're not packs these days. They're... flash memory, or entire
removable disks, or a few other things.
--
Don't bother with piddly crap like "gun control".
Life is 100% fatal. Ban it.
Charles Richmond
> In article <h2j65l$n6o$1...@news.eternal-september.org>,
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> Also, packs aren't (re)movable anymore.
>
> They're not packs these days. They're... flash memory, or entire
> removable disks, or a few other things.
>
If you can get some of the older drives that use the large disk packs,
then *yes*, packs can still be removable. You just have to interface the
older drive to the computer you have now.
ArarghMai...@not.at.arargh.com
<fri...@tx.rr.com> wrote:
>Howard S Shubs wrote:
>> In article <h2j65l$n6o$1...@news.eternal-september.org>,
>> Peter Flass <Peter...@Yahoo.com> wrote:
>>
>>> Also, packs aren't (re)movable anymore.
>>
>> They're not packs these days. They're... flash memory, or entire
>> removable disks, or a few other things.
>>
>
>If you can get some of the older drives that use the large disk packs,
>then *yes*, packs can still be removable. You just have to interface the
>older drive to the computer you have now.
The trick is, that unless the drives are SCSI, finding a controller
card for a PC.
Does there exist a (E)SMD controller card for a PC?
Or, even better yet, a controller card for a Diablo 44 disk drive?
I have lots of packs that I would love to be able to read for these
drives.
--
ArarghMail907 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
jmfbahciv
> In article <h2i54...@news5.newsguy.com>, jmfbahciv <jmfbahciv@aol> wrote:
>> Rich Alderson wrote:
>>> jmfbahciv <jmfbahciv@aol> writes:
>>>
>>>> Chris Barts wrote:
>>>>> The underlying concept is that in Unix, like in Multics and *unlike*
>>>>> any DEC or Microsoft OS I know of, the filesystem has a single root,
>>>>> called / in Unix, and everything in the filesystem, regardless of what
>>>>> physical volume it resides on, can be reached by recursing down into
>>>>> directories beginning at the root.
>>>> Look up MFD [master file directory]. Or find a TOPS-10 system and
>>>> type:
>>>> DIRECT [1,1]
>>> Not at all the same thing, Barb. If I have two structures DSKA: and
>> DSKB: on a
>>> Tops-10 system, there are two MFDs present, one for each filesystem.
>> And one can be defined to be the root equivalent of a UNIX system
>> area.
>>
>>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
>> Which is an absence of a feature, IMO, with Unix.
>>
>>
>> /BAH
>
> Which as you say is your opinion.
Exactly, but based on experience keeping a "system" up and running
no matter what hardware broke.
> The flexibility is the capability of expanding any part of the tree by
> adding in a new drive and moving a segment of the data to it and mounting
> it on the now empty directory (that used to hold the data).
But this is all based on the assumption that the "system" will remain
the same. At times, two "systems" had to be run on the same hardware
system. If a site named the system packs of two systems uniquely,
on -10 could "run" both system's packs on one machine if, and when,
the fit hit the shan. This involved maintaining a master set of
access files which would set up the system search lists of each
system for the users who used them.
>
> In the VMS days all you could do is refer to it by logical names
> SYS$MAINT --> could be DBA0:[sysmaint] or DRA0: or DBA1: ...
>
> The flexibility to rearrange this (sometimes with the system live) was one
> of the amazing things I saw with Unix.
but this doesn't keep the users separated to logical system search lists.
>
> Add in the *BSD's symbolic links and you can recover from problems without
> rebooting the system.
Sure. There are pros and cons to both approaches.
>
>
> Add in the current capability in software raid and you're light years
> ahead of what was around in the '70's and early '80's for keeping systems
> up.
>
> VAXclusters still seem a little bit slicker than the Unix equivalents --
> but that's because it was designed in to VMS in the V3/V4 days instead
> of being grafted on.
>
Grafting was always a PITA. :-)
/BAH
jmfbahciv
> jmfbahciv wrote:
>> Rich Alderson wrote:
>>>
>>> [snip...] [snip...] [snip...]
>>>
>>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
>>
>> Which is an absence of a feature, IMO, with Unix.
>>
>
> In a sense, there *is* an equivalent to DSKA: and DSKB:. While it's
> true that the "user" does *not* normally access disks by logical name,
> in Unix there are physical volumes (disks) on which filesystems are
> created. All the different filesystems are "mount"ed somewhere on
> the directory tree-structure which begins with the root (/) directory.
>
physical device name. And things were more complicated with system
search lists, job search lists, etc.
/BAH
jmfbahciv
I also think that's a big bug.
/BAH
jmfbahciv
> jmfbahciv <jmfbahciv@aol> writes:
>
>> Rich Alderson wrote:
>
>>> Not at all the same thing, Barb. If I have two structures DSKA: and DSKB:
>>> on a Tops-10 system, there are two MFDs present, one for each filesystem.
>
>> And one can be defined to be the root equivalent of a UNIX system area.
>
> I'm not quite certain what you are saying here. On Tops-10 (and TOPS-20, for
> that matter), structures[1] are independent of one another. The structure from
> which the OS is booted is generally the login structure, but that does not make
> it the equivalent of a Unix-style root directory, because the semantics are
> different.
>
>>> On Unix filesystems, there is no equivalent to DSKA: and DSKB:.
>
>> Which is an absence of a feature, IMO, with Unix.
>
> Yes and no. There have been times over the last 32 years when I would have
> loved to have the seamlessness of a Unix filesystem on my PDP-10 OS, and not
> have to worry about the fact that things were on separate devices. There have
> also been times in the last 25 years when I would have liked to separate the
> parts of a Unix filesystem and refer to them by name.
Yup. Each approach has its pluses and minuses.
>
>>> Instead, the equivalents of RPA0: and RPB0: (device names, for you
>>> non-Tops-10 unfortunates) are made available by attaching their contents to
>>> named directories in a pre-existing directory structure (usually, but not
>>> always, directly under the root of the directory tree).
>
>>> It is as if, in order to use the files on RPA0: (since devices do not have
>>> named filesystems on them), the MOUNT command had to associate them with a
>>> directory on DSKB: (the usual first-mounted structure).
>
>> That makes moving packs from one system to another a tad dicey.
>
> I don't see that that follows in any way, shape, or form.
>
> I have multiple disks on a Unix box, mounted to different mount points under
> the root directory. I need to move one or more to another box running the same
> (or compatible) version of Unix, so I unmount them from the first box, cable
> them to the second and mount them, and they're up and running.
>
> I have multiple structures on a Tops-10 box, each composed of one or more
> disks. I need to move one or more structures to another Tops-10 box, so I
> unmount them, cable the drives to the second system, mount them appropriately,
> and they're up and running.
Now think of those packs, which you are moving, as the system packs of
the system (you are removing them from). What you would like is to
have the users who use the broken system to be able to login and
not see any differences. So your ACCT.SYS and AUXACC.SYS assigns
each user's job and system search lists appropriately. It's a
plan that was used in case a hardware system couldn't run.
>
> Neither is any dicier than the other.
>
>> The
>> reasons people would do this was in cases of disasters; this probably
>> wouldn't occur anymore becuase computer systems are so cheap and can
>> be bought off the shelf.
>
> Oh, my dear, disasters happen all the time, as do upgrades of equipment (which,
> from one point of view, *is* a disaster). Disks get moved, filesystems get
> mounted, and life goes on.
>
> Notes for the Unix crowd:
>
> [1] In these systems, structures consist of one or more physical disks over
> which is overlaid a single filesystem, rather like logical volumes in
> modern Unix implementations. Unlike Unix, a physical disk (or structure,
> to carry on the LV parallel) cannot be partitioned.
>
The front end packs were kind of partitioned. :-) I would expect that
partitioned packs would have been implemented if their capacities had
been a huge as the ones today are.
/BAH
jmfbahciv
Just a note: Your constraint here is having to run similar software.
On many systems, this couldn't be possible. One system may have
been set up to run "old" or modified software that had to be isolated
from all other systems.
/BAH
Ahem A Rivet's Shot
jmfbahciv <jmfbahciv@aol> wrote:
> But this is all based on the assumption that the "system" will remain
> the same. At times, two "systems" had to be run on the same hardware
> system. If a site named the system packs of two systems uniquely,
> on -10 could "run" both system's packs on one machine if, and when,
> the fit hit the shan. This involved maintaining a master set of
> access files which would set up the system search lists of each
> system for the users who used them.
These days you'd either drop the drives into spare hardware or run
up a virtual machine on some underloaded box and mount them on that.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Howard S Shubs
Charles Richmond <fri...@tx.rr.com> wrote:
> If you can get some of the older drives that use the large disk packs,
> then *yes*, packs can still be removable. You just have to interface the
> older drive to the computer you have now.
RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
How come they never had a NewHampBus? Or an RIbus? mass-centric!!!
Roland Hutchinson
> In article <h2jt76$6pu$1...@news.eternal-september.org>,
> Charles Richmond <fri...@tx.rr.com> wrote:
>
>> If you can get some of the older drives that use the large disk packs,
>> then *yes*, packs can still be removable. You just have to interface the
>> older drive to the computer you have now.
>
> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>
> How come they never had a NewHampBus? Or an RIbus?
Mass conservation law, of course.
jmfbahciv
> In article <h2jt76$6pu$1...@news.eternal-september.org>,
> Charles Richmond <fri...@tx.rr.com> wrote:
>
>> If you can get some of the older drives that use the large disk packs,
>> then *yes*, packs can still be removable. You just have to interface the
>> older drive to the computer you have now.
>
> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>
> How come they never had a NewHampBus? Or an RIbus? mass-centric!!!
>
/BAH
Howard S Shubs
Roland Hutchinson <my.sp...@verizon.net> wrote:
> Howard S Shubs wrote:
>
> > In article <h2jt76$6pu$1...@news.eternal-september.org>,
> > Charles Richmond <fri...@tx.rr.com> wrote:
> >
> >> If you can get some of the older drives that use the large disk packs,
> >> then *yes*, packs can still be removable. You just have to interface the
> >> older drive to the computer you have now.
> >
> > RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
> >
> > How come they never had a NewHampBus? Or an RIbus?
>
> Mass conservation law, of course.
I like this one better than Barb's. Prefer Mass taxes over other
states? right. :-D
Charles Richmond
> In article <h2jt76$6pu$1...@news.eternal-september.org>,
> Charles Richmond <fri...@tx.rr.com> wrote:
>
>> If you can get some of the older drives that use the large disk packs,
>> then *yes*, packs can still be removable. You just have to interface the
>> older drive to the computer you have now.
>
> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>
> How come they never had a NewHampBus? Or an RIbus? mass-centric!!!
>
So you have to be an electronics engineer... there are people like that.
jmfbahciv
> In article <h2midq$ul6$1...@aioe.org>,
> Roland Hutchinson <my.sp...@verizon.net> wrote:
>
>> Howard S Shubs wrote:
>>
>>> In article <h2jt76$6pu$1...@news.eternal-september.org>,
>>> Charles Richmond <fri...@tx.rr.com> wrote:
>>>
>>>> If you can get some of the older drives that use the large disk packs,
>>>> then *yes*, packs can still be removable. You just have to interface the
>>>> older drive to the computer you have now.
>>> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>>>
>>> How come they never had a NewHampBus? Or an RIbus?
>> Mass conservation law, of course.
>
> I like this one better than Barb's.
Yup. You guys are better at punning. :-)
> Prefer Mass taxes over other
> states? right. :-D
>
/BAH
Gene Wirchenko
>Howard S Shubs wrote:
>
>> In article <h2jt76$6pu$1...@news.eternal-september.org>,
>> Charles Richmond <fri...@tx.rr.com> wrote:
>>
>>> If you can get some of the older drives that use the large disk packs,
>>> then *yes*, packs can still be removable. You just have to interface the
>>> older drive to the computer you have now.
>>
>> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>>
>> How come they never had a NewHampBus? Or an RIbus?
Is there a difference in transit systems between the states?
>Mass conservation law, of course.
Does that apply to black holes like the Big Dig?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Walter Bushell
Gene Wirchenko <ge...@ocis.net> wrote:
The money went somewhere, if we knew but where. I have to figure that
much of the money was taken away by politicians.
Quadibloc
> And "mount" is the command that makes the disk's file system visible as
> a part of the computer's entire file system.
Of course, people mounted magnetic tapes on computers under other, non-
UNIX, operating systems as well, so that one's a generic term.
John Savard
jmfbahciv
> Roland Hutchinson <my.sp...@verizon.net> wrote:
>
>> Howard S Shubs wrote:
>>
>>> In article <h2jt76$6pu$1...@news.eternal-september.org>,
>>> Charles Richmond <fri...@tx.rr.com> wrote:
>>>
>>>> If you can get some of the older drives that use the large disk packs,
>>>> then *yes*, packs can still be removable. You just have to interface the
>>>> older drive to the computer you have now.
>>> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>>>
>>> How come they never had a NewHampBus? Or an RIbus?
>
> Is there a difference in transit systems between the states?
>
>> Mass conservation law, of course.
>
> Does that apply to black holes like the Big Dig?
>
/BAH
Bill Pechter
Nope... you still can do it since the programs are referenced by path and
usually you can mount one on (for example) /u0/apps/application name
and the other on /u1/apps/application name.
Adjust one or two environment variables (not quite the same as VMS's
system wide logicals) for the users running on /u1 rather than /u0 and the apps
can often run on the same box.
>
>>
>> In the VMS days all you could do is refer to it by logical names
>> SYS$MAINT --> could be DBA0:[sysmaint] or DRA0: or DBA1: ...
>>
>> The flexibility to rearrange this (sometimes with the system live) was one
>> of the amazing things I saw with Unix.
>
>but this doesn't keep the users separated to logical system search lists.
Well the search list is pretty much dependant on the user's own PATH variable.
You can code one that gets picked up at login time based on userid or group.
The flexibility's all in there...
>> VAXclusters still seem a little bit slicker than the Unix equivalents --
>> but that's because it was designed in to VMS in the V3/V4 days instead
>> of being grafted on.
>>
>Grafting was always a PITA. :-)
Yup... Microsoft's seeing the PAIN of backward compatibility.
Unix's minimum system design seems to have less of a problem with
Unix compatibility in Linux.
>
>/BAH
Bill Pechter
Same on Unix/Linux.
echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/pechter/bin
Here's my system search list. /usr/local/bin then the system defaults of
/bin /usr/bin /usr/X11R6/bin and /home/pechter/bin (stuff in my own
binary directory).
No difference.
$ which trn
/usr/local/bin/trn
$ which ls
/bin/ls
put a small shell script in /usr/local/bin called ls and it gets called first.
This script gets the arguments from the command line and prints the date
then does the ls directory list with args passwd. (quick and dirty and
none too secure and no special error trapping etc.)
$ cat /usr/local/bin/ls
#! /bin/sh
OPTS="$*"
date
/bin/ls $OPTS
$ which ls
/usr/local/bin/ls
Now to run it...
$ls .
Mon Jul 6 12:36:23 EDT 2009
Algorithms_DataStructures.pdf
ca_setup.exe
<partial dir listing snipped>
# rm /usr/local/bin/ls
$ which ls
/bin/ls
Bill Pechter
>> Rich Alderson wrote:
>>> jmfbahciv <jmfbahciv@aol> writes:
>>>
>>>> Chris Barts wrote:
>>>
>>>>> The underlying concept is that in Unix, like in Multics and *unlike*
>>>>> any DEC or Microsoft OS I know of, the filesystem has a single root,
>>>>> called / in Unix, and everything in the filesystem, regardless of what
>>>>> physical volume it resides on, can be reached by recursing down into
>>>>> directories beginning at the root.
>>>
>>> equivalents of RPA0: and RPB0: (device names, for you non-Tops-10
>>> unfortunates)
>>> are made available by attaching their contents to named directories in
>>> a pre-
>>> existing directory structure (usually, but not always, directly under
>>> the root
>>> of the directory tree).
>>>
>> reasons people would do this was in cases of disasters; this probably
>> wouldn't occur anymore becuase computer systems are so cheap and can
>> be bought off the shelf.
>>
>
>Also, packs aren't (re)movable anymore.
No? My external USB drives (1tb on one) are. They look like scsi drives
to the hardware and auto config.
Seem removable to me. Just the pack, heads and electronics are in 1 unit.
Bill Pechter
Howard S Shubs <how...@shubs.net> wrote:
>In article <h2jt76$6pu$1...@news.eternal-september.org>,
> Charles Richmond <fri...@tx.rr.com> wrote:
>
>> If you can get some of the older drives that use the large disk packs,
>> then *yes*, packs can still be removable. You just have to interface the
>> older drive to the computer you have now.
>
>RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>
>Don't bother with piddly crap like "gun control".
>Life is 100% fatal. Ban it.
Oh... so you have a Firewire or USB -> SDA-> Massbus adapter 8-)
Like to get one of those myself.
Actually, the Sata/USB/Firewire stuff sure reminds me of Digital's
Storage Architecture.
Roland Hutchinson
That's just the law of Universal Gravitation. As Mark Twain, or someone
sufficiently like him for this purpose, observed, the nation is sloped
towards the west, and everything that isn't tied down sooner or later rolls
into California.
Peter Flass
> jmfbahciv wrote:
>
>> Gene Wirchenko wrote:
>>> Roland Hutchinson <my.sp...@verizon.net> wrote:
>>>
>>>> Howard S Shubs wrote:
>>>>
>>>>> In article <h2jt76$6pu$1...@news.eternal-september.org>,
>>>>> Charles Richmond <fri...@tx.rr.com> wrote:
>>>>>
>>>>>> If you can get some of the older drives that use the large disk packs,
>>>>>> then *yes*, packs can still be removable. You just have to interface
>>>>>> the older drive to the computer you have now.
>>>>> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>>>>>
>>>>> How come they never had a NewHampBus? Or an RIbus?
>>> Is there a difference in transit systems between the states?
>>>
>>>> Mass conservation law, of course.
>>> Does that apply to black holes like the Big Dig?
>>>
>> A lot of that money went to California.
>
> That's just the law of Universal Gravitation. As Mark Twain, or someone
> sufficiently like him for this purpose, observed, the nation is sloped
> towards the west, and everything that isn't tied down sooner or later rolls
> into California.
>
"All the nuts and fruits" wound up there.
Larry Elmore
> Roland Hutchinson wrote:
>> That's just the law of Universal Gravitation. As Mark Twain, or
>> someone sufficiently like him for this purpose, observed, the nation
>> is sloped towards the west, and everything that isn't tied down sooner
>> or later rolls into California.
>>
>
> "All the nuts and fruits" wound up there.
Don't forget the flakes!
Roland Hutchinson
Watchit, bud -- yer talkin 'bout my home state.
(Goddknows where I picked up this 'Jersey accent -- though I gots my
suspishions.)
Anyhoo, the flakes didn't roll in; they blew into .ca.us on an insubstantial
puff of wind. Just thought I'd set that straight, for the record, like.
Bill Marcum
>
>
> In article <h1vne...@news6.newsguy.com>, jmfbahciv <jmfbahciv@aol>
> wrote:
>
>> > /etc/fstab is a list of volumes available at startup. In the _REAL_
>> > operating system. (<Duck>)
>
> The _REAL_ operating system is Duck?
And now, let us read from the books of Matthew, Mark, Luke ... and Duck!
jmfbahciv
You are talking about now. I was talking about how things were done
back then. The SYS: areas were not necessarily the same across all
systems at one site.
>
> Adjust one or two environment variables (not quite the same as VMS's
> system wide logicals) for the users running on /u1 rather than /u0 and the apps
> can often run on the same box.
But which users? YOu would have to spend a lot of time "setting" up
the users who "moved" to the new system (usually unbeknownst to each
user). There were tried and true methods to do this on the -10s.
I did say that these methods aren't necessary today, IFF, you can
buy a new system off the shelf.
>
>
>>> In the VMS days all you could do is refer to it by logical names
>>> SYS$MAINT --> could be DBA0:[sysmaint] or DRA0: or DBA1: ...
>>>
>>> The flexibility to rearrange this (sometimes with the system live) was one
>>> of the amazing things I saw with Unix.
>> but this doesn't keep the users separated to logical system search lists.
>
> Well the search list is pretty much dependant on the user's own PATH variable.
> You can code one that gets picked up at login time based on userid or group.
> The flexibility's all in there...
On -10s, there could be different system search lists for each user,
different user search lists automatically set up at login time,
and different user search lists that could be changed during every
login session.
And then there were the apps that changed their search lists with
code.
Users could also change any of the above search lists with a user
command.
>
>>> VAXclusters still seem a little bit slicker than the Unix equivalents --
>>> but that's because it was designed in to VMS in the V3/V4 days instead
>>> of being grafted on.
>>>
>> Grafting was always a PITA. :-)
>
> Yup... Microsoft's seeing the PAIN of backward compatibility.
> Unix's minimum system design seems to have less of a problem with
> Unix compatibility in Linux.
That's becuase they were smart enough to keep the monitor pure and
not allow apps to tramp their code into the monitor without
strict rules and constraints. That's why we had UUOs and JSYSes.
/BAH
jmfbahciv
> jmfbahciv wrote:
>
>> Gene Wirchenko wrote:
>>> Roland Hutchinson <my.sp...@verizon.net> wrote:
>>>
>>>> Howard S Shubs wrote:
>>>>
>>>>> In article <h2jt76$6pu$1...@news.eternal-september.org>,
>>>>> Charles Richmond <fri...@tx.rr.com> wrote:
>>>>>
>>>>>> If you can get some of the older drives that use the large disk packs,
>>>>>> then *yes*, packs can still be removable. You just have to interface
>>>>>> the older drive to the computer you have now.
>>>>> RA60 connected to MacBook Pro via MassBus! yeah, that'll work. :->
>>>>>
>>>>> How come they never had a NewHampBus? Or an RIbus?
>>> Is there a difference in transit systems between the states?
>>>
>>>> Mass conservation law, of course.
>>> Does that apply to black holes like the Big Dig?
>>>
>> A lot of that money went to California.
>
> That's just the law of Universal Gravitation. As Mark Twain, or someone
> sufficiently like him for this purpose, observed, the nation is sloped
> towards the west, and everything that isn't tied down sooner or later rolls
> into California.
>
me that they doubled the amounts on all the bills for the Big Dig. I
never verified her claims.
/BAH
jmfbahciv
> Larry Elmore wrote:
>
>> Peter Flass wrote:
>>> Roland Hutchinson wrote:
>>>> That's just the law of Universal Gravitation. As Mark Twain, or
>>>> someone sufficiently like him for this purpose, observed, the nation
>>>> is sloped towards the west, and everything that isn't tied down sooner
>>>> or later rolls into California.
>>>>
>>> "All the nuts and fruits" wound up there.
>> Don't forget the flakes!
>
> Watchit, bud -- yer talkin 'bout my home state.
>
> (Goddknows where I picked up this 'Jersey accent -- though I gots my
> suspishions.)
>
> Anyhoo, the flakes didn't roll in; they blew into .ca.us on an insubstantial
> puff of wind. Just thought I'd set that straight, for the record, like.
>
/BAH
jmfbahciv
/BAH
Charles Richmond
> Larry Elmore wrote:
>
>> Peter Flass wrote:
>>> Roland Hutchinson wrote:
>>>> That's just the law of Universal Gravitation. As Mark Twain, or
>>>> someone sufficiently like him for this purpose, observed, the nation
>>>> is sloped towards the west, and everything that isn't tied down sooner
>>>> or later rolls into California.
>>>>
>>> "All the nuts and fruits" wound up there.
>> Don't forget the flakes!
>
> Watchit, bud -- yer talkin 'bout my home state.
>
> (Goddknows where I picked up this 'Jersey accent -- though I gots my
> suspishions.)
>
> Anyhoo, the flakes didn't roll in; they blew into .ca.us on an insubstantial
> puff of wind. Just thought I'd set that straight, for the record, like.
>
This reminds me of the Southern California language "VALGOL". It has an
error message: "Like... I just can't deal with that". You have the
looping construct: "For i =like 1 to oh say 100". For more on this
advanced language, see:
http://www.indwes.edu/Faculty/bcupp/things/computer/VALGOL.html
Bill Pechter
They don't have to be now. They just need to be a compatible revision
of the OS with the same binary and library format.
You can mount and run RHEL3 binaries on RHEL4.
Outside of system commands for disk checking and filesystem mounting
the rest of it's all done with the path command.
>But which users? YOu would have to spend a lot of time "setting" up
>the users who "moved" to the new system (usually unbeknownst to each
>user). There were tried and true methods to do this on the -10s.
>I did say that these methods aren't necessary today, IFF, you can
>buy a new system off the shelf.
>
>/BAH
Nah... about 15 minutes for about 100 users if they environment is
standard.
in a startup script like /etc/profile something like this can be done:
for user in `cat list of users`
do
set new PATH
done
All done on the fly at login time... assuming they've got no special
settings... or at the bottom of the users own local profile you can force
it to do something similar.
PATH=Newpath:$PATH which puts the new path first followed by the original.
Rich Alderson
> Rich Alderson wrote:
>> I have multiple disks on a Unix box, mounted to different mount points under
>> the root directory. I need to move one or more to another box running the
>> same (or compatible) version of Unix, so I unmount them from the first box,
>> cable them to the second and mount them, and they're up and running.
> Just a note: Your constraint here is having to run similar software.
Similar only in a restricted sense: Some variants of Unix have different
filesystem designs which do not play well (or at all) together. This is not
something that can be fixed on those systems by using newer (or older)
software.
> On many systems, this couldn't be possible. One system may have
> been set up to run "old" or modified software that had to be isolated
> from all other systems.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Lawrence Statton
> Just a note: Your constraint here is having to run similar software.
> been set up to run "old" or modified software that had to be isolated
> from all other systems.
I would venture a guess that modern Unix systems support more foreign
file structure formats than tops10 or TOPS-20 did.
Roland Hutchinson
> jmfbahciv <jmfbahciv@aol> writes:
>
>> Rich Alderson wrote:
>
>>> I have multiple disks on a Unix box, mounted to different mount points
>>> under
>>> the root directory. I need to move one or more to another box running
>>> the same (or compatible) version of Unix, so I unmount them from the
>>> first box, cable them to the second and mount them, and they're up and
>>> running.
>
>> Just a note: Your constraint here is having to run similar software.
>
> Similar only in a restricted sense: Some variants of Unix have different
> filesystem designs which do not play well (or at all) together.
Sing it!
> This is not something that can be fixed on those systems by using
> newer (or older) software.
I'm trying to live with current releases of Mac OS X and Ubuntu. The only
halfway[1] reasonable file system that both can readily be induced to
reliably read and write seems to be FAT32. What a pain!
[1] for sufficiently[2] small values of 0.5
[2] by "sufficiently" we here mean "vanishingly"
Roland Hutchinson
It's not even clear to me that modern Unix systems have a notion of "native"
filesystem.
Lawrence Statton
> Lawrence Statton wrote:
>
>> jmfbahciv <jmfbahciv@aol> writes:
>>> Just a note: Your constraint here is having to run similar software.
>>> On many systems, this couldn't be possible. One system may have
>>> been set up to run "old" or modified software that had to be isolated
>>> from all other systems.
>>
>> I would venture a guess that modern Unix systems support more foreign
>> file structure formats than tops10 or TOPS-20 did.
>
> It's not even clear to me that modern Unix systems have a notion of "native"
> filesystem.
In terms of installed-base, the most popular is likely e2fs. Of course,
JFS, XFS, and MacOS-X's native "hfs" are very popular too. Of course,
as an unabashed Unix apologist, I consider this "pick the tool that fits
your needs, not the tool we demand you use" to be a Big Win, not a Lose.
--L
Roland Hutchinson
I need a case-sensitive file system that preserves Unix permissions and
timestamps can be reliably read and written by both OS X and Linux, and that
has long filenames and a hierarchical directory structure.
Got one?
Bernd Felsche
>Lawrence Statton wrote:
>> jmfbahciv <jmfbahciv@aol> writes:
>>> Just a note: Your constraint here is having to run similar
>>> software. On many systems, this couldn't be possible. One
>>> system may have been set up to run "old" or modified software
>>> that had to be isolated from all other systems.
>> I would venture a guess that modern Unix systems support more
>> foreign file structure formats than tops10 or TOPS-20 did.
>It's not even clear to me that modern Unix systems have a notion of
>"native" filesystem.
A nattive would be anything that doesn't operate in user space.
--
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ / ASCII ribbon campaign | The growth of knowledge depends
X against HTML mail | entirely on disagreement.
/ \ and postings | -- Karl Popper
Ahem A Rivet's Shot
Roland Hutchinson <my.sp...@verizon.net> wrote:
> Lawrence Statton wrote:
>
> I need a case-sensitive file system that preserves Unix permissions and
> timestamps can be reliably read and written by both OS X and Linux, and
> that has long filenames and a hierarchical directory structure.
>
> Got one?
They won't both do ffs ?
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Peter Flass
>
> I'm trying to live with current releases of Mac OS X and Ubuntu. The only
> halfway[1] reasonable file system that both can readily be induced to
> reliably read and write seems to be FAT32. What a pain!
>
Does OS X support HPFS?
jmfbahciv
> jmfbahciv <jmfbahciv@aol> writes:
>
>> Rich Alderson wrote:
>
>>> I have multiple disks on a Unix box, mounted to different mount points under
>>> the root directory. I need to move one or more to another box running the
>>> same (or compatible) version of Unix, so I unmount them from the first box,
>>> cable them to the second and mount them, and they're up and running.
>
>> Just a note: Your constraint here is having to run similar software.
>
> Similar only in a restricted sense: Some variants of Unix have different
> filesystem designs which do not play well (or at all) together. This is not
> something that can be fixed on those systems by using newer (or older)
> software.
We had cases where a "bug" had been taken advantage of. So users who
needed that bug on a system could not be easily moved to another
system which required the bug to have been fixed, especially if
it was a monitor bug. An app "bug" could be invoked with careful
path settings and isolating those users to their own structure.
The solutions used really depended on the site: how their operators
worked, the distribution of the TTYs and users, etc. All very
interesting problems to solve :-)
/BAH
jmfbahciv
/BAH
Bernd Felsche
>> Lawrence Statton wrote:
>>
>> I need a case-sensitive file system that preserves Unix permissions and
>> timestamps can be reliably read and written by both OS X and Linux, and
>> that has long filenames and a hierarchical directory structure.
>>
>> Got one?
> They won't both do ffs ?
ffs can stand for a lot of things FFS!
Depends if the spec. is open and legally unencumbered.