Lost in RSX-11M
Pierre
A friend of mine was clearing his shop, and he gave me a PDP11. After
some searches, it appears to be a kind of 11/73 (Mentec SBC M70). It
comes with a hard drive, floppy, 1Mb RAM, and 4 serial ports. I hooked
it to my computer, and after fiddling a bit managed to connect to the
thing.
Now, I'd like to explore the hard drive (DU0:) : it works, else I
wouldn't get RSX loaded, but I don't know if I just lack knowledge or
if the OS lacks commands.
When I try HELP, it goes this way :
Help is available for many RSX-11M commands and utilities.
For help in logging into the system, type HELP HELLO or HELP
LOGIN. You'll need a user-ID and password to log in. Ask
your
system manager.
RSX-11M systems have two major command languages or CLIs: MCR
and DCL. Once you log in, your terminal is set to either
MCR or DCL. (All terminals are set to MCR prior to logging
in.)
The general forms of the HELP command are:
>HELP[/cli] topic [subtopic[s]]
>HELP commandname [switch]
Once you are logged in, you need not include the name of the
CLI
to which your terminal is set.
For information on what further help is available, type
HELP[/MCR] LIST (brackets indicate an optional command line
entry) or HELP/DCL. For a listing of help available on other
topics, type HELP[/MCR] MORE or HELP/DCL MORE. You need not
log in to get help.
So that part is fine. Some HELP commands do produce an output, others
this error message :
>HELP INS
HEL -- Indirect HELP file open error -26.
Do you know what's the cause or meaning ? I think it's a missing file.
I'm in MCR by default. I did these to load DCL :
CLI /INI=DCL
and it works. Now, how can I get a listing of what's on the disk ? If
I try DIR or PIP I get
MCR -- Task not in system
I tried this :
INS $INI/TASK=…PIP
For this result :
>
>PIP whatever
PIP -- This program must be invoked as an MCR function
You know pretty all, I'd love to revive this computer and hook it to
the internet, but I'm stuck at square one.
Pierre
Pierre
> Hello all,
So, as always asking questions triggers more ideas, I found a MCR
manual and digged into the INS command.
> >HELP INS
>
> HEL -- Indirect HELP file open error -26.
>
> Do you know what's the cause or meaning ? I think it's a missing file.
Still no clue on that one.
> I tried this :
> INS $INI/TASK=…PIP
>
> For this result :
>
> >PIP whatever
>
> PIP -- This program must be invoked as an MCR function
So, turns out
INS $PIP
is enough, and now I have more info on the hard drive :
>pip /LI
Directory DU0:[1,1]
29-APR-74 01:57
KITIDENT.DAT;1 1. 10-JUL-85 16:44
EXEMC.MLB;1 138. 10-JUL-85 17:08
ODT.OBJ;1 8. 05-DEC-86 08:59
ANSLIB.OLB;1 277. 14-APR-87 14:19
EXELIB.OLB;1 48. 10-JUL-85 17:08
SYSLIB.OLB;1 241. C 14-APR-87 10:26
VMLIB.OLB;1 16. 10-JUL-85 16:44
RSXMAC.SML;1 283. C 14-APR-87 10:36
PROSYM.TSK;1 17. C 17-FEB-89 10:33
PROSYM.MAP;1 5. 17-FEB-89 10:33
STOP.CMD;1 1. 14-FEB-89 15:03
PRODB.STB;1 1. 23-APR-87 11:06
PRODB.TSK;1 3. C 23-APR-87 11:06
MENCOM.STB;1 1. 23-APR-87 11:16
MENCOM.TSK;1 4. C 23-APR-87 11:16
FCSRES.BLD;1 1. 27-APR-87 10:03
FCSRES.STB;1 3. 27-APR-87 10:03
FCSRES.TSK;1 17. C 27-APR-87 10:03
MOTINI.CMD;4 1. 15-FEB-89 09:52
RSXMC.MAC;1 20. 18-OCT-88 15:15
MADLIB.OLB;2 51. 04-JAN-89 11:45
PRODBSYM.STB;2 1. 04-JAN-89 11:46
FCBDEF.STB;1 1. 04-JAN-89 11:46
MACROS.MLB;1 30. C 26-MAY-87 10:24
PROCOM.LST;1 24. 30-MAR-89 10:26
PROSYM.BLD;1 1. 17-FEB-89 10:33
PROSYM.STB;1 2. 17-FEB-89 10:33
PROCOM.VIR;2 17. C 10-FEB-89 12:17
PROCOM.TSK;4 17. C 24-FEB-89 10:13
PROCOM.OBJ;2 2. 24-FEB-89 10:13
PROCOM.MAC;3 14. 24-FEB-89 10:13
PROCOM.MAP;2 5. 24-FEB-89 10:13
PROCOM.STB;4 2. 24-FEB-89 10:13
PROCOM.BLD;2 1. 10-FEB-89 12:33
PRUNE.CMD;1 1. 17-JAN-95 17:14
LOGIN.CMD;4 1. 22-OCT-92 11:42
Total of 1256./1256. blocks in 36. files
>PIP /FR
DU0: has 199498. blocks free, 122936. blocks used out of 322434.
Largest contiguous space = 64119. blocks
319. file headers are free, 1331. headers used out of 1650.
Questions :
1/ Are those files the expected files on such a system, or do I miss
some ?
2/ If I do miss some, do you think they are elsewhere on the system ?
Here is the output from DEV I think is relevant :
DU0: Public Mounted Loaded Label=RSXM38D Type=RD54
DU1: Loaded Type=RD54
DU2: Loaded Type=RX33
DU3: Offline Loaded Type=unknown
DY0: Offline Unloaded Type=RX02
DY1: Offline Unloaded Type=RX02
MS0: Offline Unloaded
MU0: Offline Unloaded
Pierre
Al Kossow
>> pip /LI
>
try pip /li [*,*]*.*
Johnny Billquist
On 2011-01-25 23:19, Pierre wrote:
> On 25 jan, 22:22, Pierre<simulomb...@gmail.com> wrote:
>> Hello all,
>
> So, as always asking questions triggers more ideas, I found a MCR
> manual and digged into the INS command.
Good.
>>> HELP INS
>>
>> HEL -- Indirect HELP file open error -26.
>>
>> Do you know what's the cause or meaning ? I think it's a missing file.
>
> Still no clue on that one.
.err -26
000346 (-26): %I/O-E-IE.NSF, no such file
.
Which means I guess you are missing LB:[1,2]INS.HLP
>> I tried this :
>> INS $INI/TASK=…PIP
>>
>> For this result :
>>
>>> PIP whatever
>>
>> PIP -- This program must be invoked as an MCR function
>
> So, turns out
> INS $PIP
> is enough, and now I have more info on the hard drive :
What you did the first time was to install the INS.TSK under the name
PIP, which is not the same as the PIP program. :-)
Hard to tell. Yes, some of the files are expected. But if you miss some?
Don't know. You could in some more directories, though.
> 2/ If I do miss some, do you think they are elsewhere on the system ?
> Here is the output from DEV I think is relevant :
>
> DU0: Public Mounted Loaded Label=RSXM38D Type=RD54
> DU1: Loaded Type=RD54
> DU2: Loaded Type=RX33
> DU3: Offline Loaded Type=unknown
> DY0: Offline Unloaded Type=RX02
> DY1: Offline Unloaded Type=RX02
> MS0: Offline Unloaded
> MU0: Offline Unloaded
So you have one more RD54, which probably also have stuff on it. But you
should understand that your system disk also have multiple directories.
There is a lot more on that disk than you have seen so far.
Although, my first question would be: did the system boot all the way
up, or did you stop it during the boot phase, since I would have
expected programs like PIP to be installed if it had booted properly.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
gareth
news:563a6f7d-b229-4874...@p7g2000prb.googlegroups.com...
> A friend of mine was clearing his shop, and he gave me a PDP11.
You lucky, lucky man!
I don't know how well the Green of envious eyes shows up in the
black and white of Usenet, but this year is 30 years since I last worked
on the PDP-11 and was involved in writing device drivers for RSX-11/M.
Oh, well, time for me to $fork off!
Pierre
> Hi.
Hey, thanks for the answers, unblocked a ton of things here !
>
>
> Which means I guess you are missing LB:[1,2]INS.HLP
>
Indeed :
MCR>pip du0:[1,2]*.hlp /li/BR
Directory DU0:[1,2]
BAD.HLP;1
CMP.HLP;1
EDTHELP.HLP;1
ERROR.HLP;1
HELPF.HLP;1
MCR.HLP;1
MCREDT.HLP;1
MCRGENRL.HLP;1
MCRHELP.HLP;1
MCRMOU.HLP;1
PIP.HLP;1
PROCESS.HLP;2
K11HLP.HLP;1
> >> I tried this :
> >> INS $INI/TASK=…PIP
> > So, turns out
> > INS $PIP
> > is enough, and now I have more info on the hard drive :
>
> What you did the first time was to install the INS.TSK under the name
> PIP, which is not the same as the PIP program. :-)
>
Yes, I'm beginning to understand some of this :) Basically, you must
load and name any command prior to execute it, meaning I guess that
disk access is not required to execute the command afterwards ? I have
another question on this, is there a clean shutdown procedure ? So far
I shiver, close my eyes and turn off the main power...
> > DU0: has 199498. blocks free, 122936. blocks used out of 322434.
> > Largest contiguous space = 64119. blocks
> > 319. file headers are free, 1331. headers used out of 1650.
>
> > Questions :
> > 1/ Are those files the expected files on such a system, or do I miss
> > some ?
>
> Hard to tell. Yes, some of the files are expected. But if you miss some?
> Don't know. You could in some more directories, though.
>
> > 2/ If I do miss some, do you think they are elsewhere on the system ?
> > Here is the output from DEV I think is relevant :
>
> > DU0: Public Mounted Loaded Label=RSXM38D Type=RD54
> > DU1: Loaded Type=RD54
> > DU2: Loaded Type=RX33
>
> So you have one more RD54, which probably also have stuff on it. But you
> should understand that your system disk also have multiple directories.
> There is a lot more on that disk than you have seen so far.
I cannot mount DU1 :
>MOU DU1:
MOU - no home block found or structure not supported
I can mount it as /FOREIGN, but no clue on what to do next.
>
> Although, my first question would be: did the system boot all the way
> up, or did you stop it during the boot phase, since I would have
> expected programs like PIP to be installed if it had booted properly.
>
Well done sir.The initial boot phase did end up in XDT, so I logged
out when asked for date & time and relogged (password was same as
login, sometimes you're just in luck). Now that I have PIP and EDT, I
will trace the login sequence to see where it fails : the system was
attached to scientific gear & printer in a lab, I'm pretty sure I'll
find somewhere a related command that fails.
I don't know yet how to enumerate the directories, so I just found
some by reading CMD files that were in [1,2] and so far found :
.sets $LDUIC "[20,17]" ! Standard
software
.sets $LXUIC "[30,17]" ! Extra
software
.sets $APUIC "[40,17]" ! Application
software
.sets $TSUIC "[70,17]" ! Test
software
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol- Hide quoted text -
>
Pierre
Pierre
Thanks Al :
PIP du0:[*,*]*.* /LI
worked like a charm :
Grand total of 117063./117113. blocks in 827. files in 17. directories
Do you know what are the proper settings for the faceplate switches ?
I have three of them :
Clock (3 positions)
Run (2 positions, I figured that one I guess)
Reset (I figured that one)
Pierre
Hans Bachner
Pierre <simul...@gmail.com> wrote:
<snip>
> I have
> another question on this, is there a clean shutdown procedure ? So far
> I shiver, close my eyes and turn off the main power...
<snip>
iirc your're looking for
>run $shutup
Hans.
Lawrence D'Oliveiro
> .err -26
> 000346 (-26): %I/O-E-IE.NSF, no such file
On a semi-related note, anybody have an idea what the significance of the
abbreviation in IE.SDP might be? I remember (from looking at some RSX
documentation once) that it indicated an illegal parameter being passed to a
system call, but I wonder if the letters actually stood for something ...
um, less complimentary ...
Johnny Billquist
> On Jan 26, 10:06 am, Johnny Billquist<b...@softjar.se> wrote:
>> Hi.
>
> Hey, thanks for the answers, unblocked a ton of things here !
Keep asking then. :-)
>> Which means I guess you are missing LB:[1,2]INS.HLP
>>
> Indeed :
>
> MCR>pip du0:[1,2]*.hlp /li/BR
>
>
> Directory DU0:[1,2]
>
> BAD.HLP;1
> CMP.HLP;1
> EDTHELP.HLP;1
> ERROR.HLP;1
> HELPF.HLP;1
> MCR.HLP;1
> MCREDT.HLP;1
> MCRGENRL.HLP;1
> MCRHELP.HLP;1
> MCRMOU.HLP;1
> PIP.HLP;1
> PROCESS.HLP;2
> K11HLP.HLP;1
That was a rather short list. Looks rather stripped.
>>>> I tried this :
>>>> INS $INI/TASK=�PIP
>>> So, turns out
>>> INS $PIP
>>> is enough, and now I have more info on the hard drive :
>>
>> What you did the first time was to install the INS.TSK under the name
>> PIP, which is not the same as the PIP program. :-)
>>
>
> Yes, I'm beginning to understand some of this :) Basically, you must
> load and name any command prior to execute it, meaning I guess that
> disk access is not required to execute the command afterwards ?
Not quite. Installing in RSX is not the same as loading it into memory.
It just makes the task known to the system. There is no real equivalent
in Unix or any other system, so I have a hard time explaining this.
Basically, all tasks that the RSX can run must already exist in the
process tables. INS creates the entry in the process table (or task
table to speak RSX). When you install the task, an entry is created in
the task table, but it is not an active task, so it's more like a
placeholder. Once the entry exists, though, all kind of actions related
to tasks can be done. Such as activating the task, sending messages to
it, block/unblock and so on... Activating a task can be done by typing
"RUN taskname", through system calls, and possibly by your CLI.
The task name (like ...PIP) is actually the identifier for the task. As
such, the closest thing in a Unix system is the PID. All task names must
be unique, and all system calls related to tasks take task names as
their arguments.
With all this said, there are then a few special cases in addition. When
you type a command in MCR (the "shell"), it will try to figure out what
to do with it. One thing it tries to do is to check if the first three
letters of the command you typed matches an installed task with the name
"...xxx". Tasks that are named in such a way are called prototype tasks,
and are not meant to be run in the normal way. Prototype tasks are
handled by MCR in such a way that the prototype task gets cloned for
your use, and the task name is changed to "xxxtnn" where xxx is the same
xxx as the command name. tnn is constructed based on your TTY, so that
if two users run the same command, they will end up with their own
copies of the same task, with their own unique names.
The console terminal, for instance is TT0:. If you type "PIP" on the
console terminal, you'll get a "PIPT0 " task name running on your
terminal, which is a copy of "...PIP".
The system knows where the binary for this task is, so it can be loaded
in from disk if needed. This information was provided when you INStalled
the task with the name ...PIP
Depending on what version of the OS, how the task was built, and so on,
several people might share the RO parts of that image, or everyone have
their own copy. Same goes for any libraries it was linked against.
All shared libraries must also be installed the same way, before the
task is installed, by the way. Same rules apply.
> I have
> another question on this, is there a clean shutdown procedure ? So far
> I shiver, close my eyes and turn off the main power...
As others already mentioned. SHUTUP is the program for this.
However, the RSX file system is not that sensitive, so you are normally
perfectly ok if you just turn off the power.
>>> 2/ If I do miss some, do you think they are elsewhere on the system ?
>>> Here is the output from DEV I think is relevant :
>>
>>> DU0: Public Mounted Loaded Label=RSXM38D Type=RD54
>>> DU1: Loaded Type=RD54
>>> DU2: Loaded Type=RX33
>>
>> So you have one more RD54, which probably also have stuff on it. But you
>> should understand that your system disk also have multiple directories.
>> There is a lot more on that disk than you have seen so far.
>
> I cannot mount DU1 :
>> MOU DU1:
> MOU - no home block found or structure not supported
>
> I can mount it as /FOREIGN, but no clue on what to do next.
Ah. Hmm. Well, you could try looking at the raw data of the first block
or two, and see if that gives any hints what is on the disk, and what
format.
DMP TI:=DU1:/AS/LC/BL:0:2
>> Although, my first question would be: did the system boot all the way
>> up, or did you stop it during the boot phase, since I would have
>> expected programs like PIP to be installed if it had booted properly.
>>
>
> Well done sir.The initial boot phase did end up in XDT, so I logged
> out when asked for date& time and relogged (password was same as
> login, sometimes you're just in luck). Now that I have PIP and EDT, I
> will trace the login sequence to see where it fails : the system was
> attached to scientific gear& printer in a lab, I'm pretty sure I'll
> find somewhere a related command that fails.
Doh! If you end up in XDT at boot time, that means that the system was
never properly set up on the disk. This is not unusual, I have come to
realize over the years. Lots of places that used RSX seem to never have
figured out how RSX actually works.
The system is more or less usable anyway, even when not properly set up.
You might want to try running ACNT, to check what accounts and passwords
possibly exist on the system.
However, if you get prompted for date and time during bootup, this is
perfectly normal. Just answer the question, and it should continue the
system startup.
> I don't know yet how to enumerate the directories, so I just found
> some by reading CMD files that were in [1,2] and so far found :
>
> .sets $LDUIC "[20,17]" ! Standard
> software
> .sets $LXUIC "[30,17]" ! Extra
> software
> .sets $APUIC "[40,17]" ! Application
> software
> .sets $TSUIC "[70,17]" ! Test
> software
To check what directories you have, you can always do
PIP LB:[0,0]*.DIR/LI
Johnny Billquist
No idea. But since Dave Cutler was/is infamous for his vile tounge, I
would suspect that there is some less complementary interpretation... :-)
Johnny Billquist
Pierre
> > Hey, thanks for the answers, unblocked a ton of things here !
>
> Keep asking then. :-)
>
>
>
> > MCR>pip du0:[1,2]*.hlp /li/BR
>
> > Directory DU0:[1,2]
>
> > BAD.HLP;1
> > CMP.HLP;1
> > EDTHELP.HLP;1
> > ERROR.HLP;1
> > HELPF.HLP;1
> > MCR.HLP;1
> > MCREDT.HLP;1
> > MCRGENRL.HLP;1
> > MCRHELP.HLP;1
> > MCRMOU.HLP;1
> > PIP.HLP;1
> > PROCESS.HLP;2
> > K11HLP.HLP;1
>
> That was a rather short list. Looks rather stripped.
There are other HLP files floating around, I'll explore more in the
upcoming days.
keeping this ^ in the thread to up a bit its google score, the info is
precious :)
> > I have
> > another question on this, is there a clean shutdown procedure ? So far
> > I shiver, close my eyes and turn off the main power...
>
> As others already mentioned. SHUTUP is the program for this.
> However, the RSX file system is not that sensitive, so you are normally
> perfectly ok if you just turn off the power.
>
>
That one was more than unexpected, but given the noise, I guess shutup
is appropriate :)
>
> > I cannot mount DU1 :
> >> MOU DU1:
> > MOU - no home block found or structure not supported
>
> > I can mount it as /FOREIGN, but no clue on what to do next.
>
> Ah. Hmm. Well, you could try looking at the raw data of the first block
> or two, and see if that gives any hints what is on the disk, and what
> format.
>
> DMP TI:=DU1:/AS/LC/BL:0:2
>
Did that, the disk seemed filled up with the same sequence of
characters (k m 6 [ iirc, I'll give you more info if it makes sense).
My guess at this point is : this was getting data from some lab gear.
I see only one disk physically installed, is there a notion of
partitions for hard drives ?
> >> Although, my first question would be: did the system boot all the way
> >> up, or did you stop it during the boot phase, since I would have
> >> expected programs like PIP to be installed if it had booted properly.
>
> > Well done sir.The initial boot phase did end up in XDT, so I logged
> > out when asked for date& time and relogged (password was same as
> > login, sometimes you're just in luck). Now that I have PIP and EDT, I
> > will trace the login sequence to see where it fails : the system was
> > attached to scientific gear& printer in a lab, I'm pretty sure I'll
> > find somewhere a related command that fails.
>
> Doh! If you end up in XDT at boot time, that means that the system was
> never properly set up on the disk. This is not unusual, I have come to
> realize over the years. Lots of places that used RSX seem to never have
> figured out how RSX actually works.
> The system is more or less usable anyway, even when not properly set up.
>
So, I edited startup.cmd and got rid of that issue. The logon sequence
is probably not perfect right now, but at least the major commands are
already there and I don't have to fiddle around.
> You might want to try running ACNT, to check what accounts and passwords
> possibly exist on the system.
Did that, only one account on the system (funny to see password in
clear text by the way). When I tried to create a second one the first
question was (n,n) : I assume it wants a home directry for the user ?
Do i simply enter 1,whateverUnused or is there something to do
before ? Also, the default cli is MCR on the current account, is DCL
more amenable ?
>
>
> To check what directories you have, you can always do
> PIP LB:[0,0]*.DIR/LI
>
Worked too. I see almost no programming languages on this box, is
there a way to bring basic/pascal/other ? I found kermit and it works,
I was able to transfer text files from an to the machine. I digged
thrrough DECUS and found a ton of things but still a bit lost there.
Some random questions :
so far I'm using 9600 baud rate, I've seen some documentation on
jumpers to specify an alternate speed but I don't want to mess with my
only means of communication with that system :) is there a simple way
to boost this up a bit ? I don't think the system is as slow as it
seems from tera term !
I want to access the system without being physically hooked to it, do
you have an idea on the software I could use ? I basically want to
telnet/whatever my windows machine and have that connection hooked up
to my rs232 port.
Pierre, spending half time preparing a lecture on cloud computing and
the other half on this :)
Rob Brown
On Thu, 27 Jan 2011 at 10:46 +0100, Johnny Billquist wrote:
> On 2011-01-27 05:28, Lawrence D'Oliveiro wrote:
>> On a semi-related note, anybody have an idea what the significance
>> of the abbreviation in IE.SDP might be? I remember (from looking at
>> some RSX documentation once) that it indicated an illegal parameter
>> being passed to a system call, but I wonder if the letters actually
>> stood for something ... um, less complimentary ...
>
> No idea. But since Dave Cutler was/is infamous for his vile tounge,
> I would suspect that there is some less complementary
> interpretation... :-)
IE.SDP means that the first word of the DPB (Directive Parameter
Block) is invalid. So DP could be the first two letters of DPB. The
S could stand for Size, since the size of the DPB is encoded in that
word. There are other words that start with S as well.
;-)
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
Rob Brown
>> With all this said, there are then a few special cases in addition.
>> When you type a command in MCR (the "shell"), it will try to figure
>> out what to do with it. One thing it tries to do is to check if the
>> first three letters of the command you typed matches an installed
>> task with the name "...xxx". Tasks that are named in such a way are
>> called prototype tasks, and are not meant to be run in the normal
>> way. Prototype tasks are handled by MCR in such a way that the
>> prototype task gets cloned for your use, and the task name is
>> changed to "xxxtnn" where xxx is the same xxx as the command name.
>> tnn is constructed based on your TTY, so that if two users run the
>> same command, they will end up with their own copies of the same
>> task, with their own unique names.
>>
>> The console terminal, for instance is TT0:. If you type "PIP" on
>> the console terminal, you'll get a "PIPT0 " task name running on
>> your terminal, which is a copy of "...PIP".
A good description from Johnny, but here is a nit that I must pick.
There is a small difference here between RSX11M and RSX11M-Plus.
When you boot up, the system should announce which of the two it is,
but I suspect, based on the volume label of your boot disk, that you
are actually running RSX11M V4.2. If you RUN $RMD, the top of the
display shows which operating system you are running.
Johnny described what you see when you are running RSX-11M-Plus. If
you are running M (not M-Plus) then you will see ...PIP (for example)
running. In M, the first simultaneous user of PIP gets the ...PIP
task name. Subsequent simultaneous users get the name Johnny
described: PIPT0 for example.
> I see only one disk physically installed, is there a notion of
> partitions for hard drives ?
Not on regular DEC gear. An RD54 is a full height 5 1/4 inch hard
drive (dates from the late mid-80s), so it ought to be hard to miss.
I think that this is a newer Mentec box, so I would not expect real
RD54s in it anyway. Mentec could have some kind of partitioning
implemented that I and RSX do not know about.
> So, I edited startup.cmd and got rid of that issue. The logon
> sequence is probably not perfect right now, but at least the major
> commands are already there and I don't have to fiddle around.
From your initial description as well as this, I think that
STARTUP.CMD was running some user-written privileged task or loading
some user-written device driver that did not handle your environment.
If you simply remove (comment out with "!") the offending command in
STARTUP.CMD you may find (have found) that the rest can be retained.
>> You might want to try running ACNT, to check what accounts and
>> passwords possibly exist on the system.
>
> Did that, only one account on the system (funny to see password in
> clear text by the way).
Yes. Encrypted passwords in RSX did not appear until 1986 or '87 (and
maybe only in M-Plus. RSX11M V4.2 predates that.
> When I tried to create a second one the first question was (n,n) : I
> assume it wants a home directry for the user ? Do i simply enter
> 1,whateverUnused or is there something to do before ?
This is the UIC --- User Identification Code: two octal numbers from
1 to 377. The first number is the group number, the second is the
member number. Groups 1 to 10 are privileged. The home directory is
named after the UIC, so that most use the terms UIC and UFD (User File
Directory) interchangeably.
> Also, the default cli is MCR on the current account, is DCL more
> amenable ?
Perhaps. I set my CLI to DCL, although I still type some MCR
commands. Most users I know stayed with MCR. Compare:
PIP file/LI vs DIR file
PIP file/BR vs DIR/BRIEF file
PIP file/FU vs DIR/FULL file
PIP file/DE vs DEL file
PIP file1=file2 vs COPY file2 file1
PIP file1/RE=file2 vs RENAME file2 file1
PIP file1/AP=file2 vs APPEND file2 file1
SET /UIC=[123,321] vs SET UIC [123,321]
SET /DEF=[123,321] vs SET DEFAULT [123,321]
SET /SPEED=TI:9600:9600 vs SET TERMINAL/SPEED=9600:9600
SET /DCL=TI: vs SET DCL
SET /MCR=TI: vs SET MCR
MAC file,file=file vs MAC/LIST file
CMP ofile=file1,file2 vs DIFF ofile=file1,file2
DMP ofile=ifile vs DUMP ofile=ifile
So some are better than others.
> Worked too. I see almost no programming languages on this box, is
> there a way to bring basic/pascal/other ?
RSX came with assembler aka MAC (or BIGMAC) and the indirect command
file processor (.CMD files). Over the years, you could buy FORTRAN
IV, FORTRAN 4-Plus, Fortran-77, Basic, Basic-plus-2, C, MUMPS, Pascal,
COBOL, COBOL-81, CORAL-66, C, DIBOL, RPG II. In the 1989 Decus
Library catalogue, I find C, APL, Reese BASIC, FORTH, PASCAL, LISP and
XLISP.
Typically, especially given the size of disks of the day, a system
owner would only install one or two additional languages.
> so far I'm using 9600 baud rate, I've seen some documentation on
> jumpers to specify an alternate speed but I don't want to mess with
> my only means of communication with that system :) is there a simple
> way to boost this up a bit ?
I don't know this Mentec box. On DEC manufactured machines, the
system console speed can only be changed mechanically. If you have a
multiplexer, port speeds can be changed individually by software
command.
In the past I have changed the speed of my system console port, but
eventually I set them all back to 9600, which seems to have been the
preferred speed since the late-80s.
> I don't think the system is as slow as it seems from tera term !
I guess you need a CPU benchmark. A screen paint at 9600 has got to
take about two seconds. Blindingly fast in its day, but much slower
than I like these days.
> I want to access the system without being physically hooked to it,
> do you have an idea on the software I could use ? I basically want
> to telnet/whatever my windows machine and have that connection
> hooked up to my rs232 port.
Don't understand the question. Do you have Ethernet on your PDP-11?
If so, your choices are DECnet or TCP/IP.
Although unsupported and abandoned now, there was, not so long ago, a
DECnet stack for Linux. Do you have on your PDP-11? Perhaps the
easiest way to find out it search for an NCP task file. Try a command
like PIP [*,*]NCP*.*/LI. (SRD [*,*]NCP would be faster if you have
SRD installed.)
Last I checked the only commercially available TCP/IP stack for RSX
was from Process Software. It was very expensive and not supported
even when you did pay them. There is/was an TCP/IP stack for RT-11 (I
think). I have never seen any sign that it was ever ported to RSX, so
either nobody wanted it, or it was hard to do. I have never had time,
myself.
If you don't have Ethernet or DECnet or TCP/IP, then you will want a
terminal server. One of the more recent DECservers (one that will
support TCP/IP) will do. Connect ports on the terminal server to
ports on the PDP-11. Create services on the terminal server so that
incoming connections from the network connect to one of the serial
ports.
> Pierre, spending half time preparing a lecture on cloud computing
> and the other half on this :)
Be sure to keep your priorities straight!
van...@vsta.org
> If you don't have Ethernet or DECnet or TCP/IP, then you will want a
> terminal server. One of the more recent DECservers (one that will
> support TCP/IP) will do. Connect ports on the terminal server to
> ports on the PDP-11. Create services on the terminal server so that
> incoming connections from the network connect to one of the serial
> ports.
I have an old Cisco 2511 somewhere around here. If you're near the San
Francisco Bay Area, you're welcome to it. It would give you 16 async ports,
available via telnet or ssh.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Lawrence D'Oliveiro
Brown wrote:
> Compare [MCR vs DCL]:
>
> SET /UIC=[123,321] vs SET UIC [123,321]
The former version of this one, at least, still worked on DCL under VMS. I
found this in a shell script^H^H^H^command procedure one day. Wasn’t
mentioned anywhere in the DCL documentation that I could find.
Lawrence D'Oliveiro
In message <alpine.LFD.2.00.1...@libra.gmcl.internal>, Rob
Brown wrote:
> CMP ofile=file1,file2 vs DIFF ofile=file1,file2
Interesting that DEC never made the leap to providing a PATCH to go with
CMP/DIFF. In those days, they still looked on output from file comparators
as something for humans to look at, not as something suitable for further
automatic processing...
Johnny Billquist
Um... Sure they did...
Look for /SL in the help text below...
Johnny
.help cmp sw
The CMP switches are as follows:
/BL Specifies that blank lines in both files be included in compare
[/-BL] processing. The /-BL switch is the default.
/CB Specifies that CMP list infile2 with change bars, in the form of
[/-CB] exclamation points (!), to denote which lines do not have a cor-
responding line in infile1. The /-CB switch is the default.
[/CO] Specifies that CMP include comments (that is, text preceded by a
/-CO semicolon (;)) in compare processing. The /CO switch is the
default.
[/DI] Specifies that CMP list the differences between the two files.
/-DI The /DI switch is the default.
/FF Specifies that CMP include records consisting of a single
form-feed
[/-FF] character in compare processing. The /-FF switch is the default.
/LI:n Specifies that n lines must be identical before CMP recognizes a
[/LI:3] match. The /LI:3 switch is the default.
[/LN] Specifies that lines in the output file be preceded by their
line
/-LN number. The /LN switch is the default.
[/MB] Specifies that CMP include all blank and tab characters in a
line
/-MB in compare processing. If you specify the /-MB switch, CMP
interprets any sequence of blank and /or tab characters as a
single
blank character. However, all spaces and tabs are printed in the
output listing. The /MB switch is the default.
/SL[:au] Directs CMP to generate an output file suitable for use as SLP
[/-SL] command input. When you specify the /SL switch, CMP
generates the
SLP command input necessary to make infile1 identical to
infile2.
If a 1- to 8-character alphanumeric symbol is included in
the /SL
switch (au), an audit trail is specified for SLP input. The /-SL
switch is the default.
/SP[:n] Specifies that the output file be spooled on the line
printer. You
[/-SP] can optionally specify the number of files to be spooled.
The /-SP
switch is the default. This switch applies only if you have the
Queue Manager system installed.
[/TB] Specifies that CMP include all trailing blanks on a line in
compare
/-TB processing. The /TB switch is the default.
/VB:nnn Specifies an octal character code for the character you want
to use
[/VB:041] as a change bar. You use this switch with the /CB switch. The
default switch is /VB:041 for an exclamation point.
.
Johnny Billquist
>>
>>> MCR>pip du0:[1,2]*.hlp /li/BR
>>
>>> Directory DU0:[1,2]
>>
>>> BAD.HLP;1
>>> CMP.HLP;1
>>> EDTHELP.HLP;1
>>> ERROR.HLP;1
>>> HELPF.HLP;1
>>> MCR.HLP;1
>>> MCREDT.HLP;1
>>> MCRGENRL.HLP;1
>>> MCRHELP.HLP;1
>>> MCRMOU.HLP;1
>>> PIP.HLP;1
>>> PROCESS.HLP;2
>>> K11HLP.HLP;1
>>
>> That was a rather short list. Looks rather stripped.
>
> There are other HLP files floating around, I'll explore more in the
> upcoming days.
Ah. Ok.
Oh. Just remember I forgot one detail. You can also actually make the
program load into memory permanently. That is what the FIX program do.
If you FIX a task, it will be permanently in memory, so that you never
need to load it. However, you cannot FIX prototype tasks.
>>> I cannot mount DU1 :
>>>> MOU DU1:
>>> MOU - no home block found or structure not supported
>>
>>> I can mount it as /FOREIGN, but no clue on what to do next.
>>
>> Ah. Hmm. Well, you could try looking at the raw data of the first block
>> or two, and see if that gives any hints what is on the disk, and what
>> format.
>>
>> DMP TI:=DU1:/AS/LC/BL:0:2
>>
>
> Did that, the disk seemed filled up with the same sequence of
> characters (k m 6 [ iirc, I'll give you more info if it makes sense).
> My guess at this point is : this was getting data from some lab gear.
> I see only one disk physically installed, is there a notion of
> partitions for hard drives ?
Nah. I can probably not make any better guesses at this point. It might
be that they used the disk as a raw data storage.
>>>> Although, my first question would be: did the system boot all the way
>>>> up, or did you stop it during the boot phase, since I would have
>>>> expected programs like PIP to be installed if it had booted properly.
>>
>>> Well done sir.The initial boot phase did end up in XDT, so I logged
>>> out when asked for date& time and relogged (password was same as
>>> login, sometimes you're just in luck). Now that I have PIP and EDT, I
>>> will trace the login sequence to see where it fails : the system was
>>> attached to scientific gear& printer in a lab, I'm pretty sure I'll
>>> find somewhere a related command that fails.
>>
>> Doh! If you end up in XDT at boot time, that means that the system was
>> never properly set up on the disk. This is not unusual, I have come to
>> realize over the years. Lots of places that used RSX seem to never have
>> figured out how RSX actually works.
>> The system is more or less usable anyway, even when not properly set up.
>>
>
> So, I edited startup.cmd and got rid of that issue. The logon sequence
> is probably not perfect right now, but at least the major commands are
> already there and I don't have to fiddle around.
Aha. I thought you meant that XDT was entered as a part of the boot. If
it happened as a part of executing STARTUP.CMD, then Rob's suggestion to
just comment out the "bad" line is more appropriate, and my comments are
mostly wrong.
>> You might want to try running ACNT, to check what accounts and passwords
>> possibly exist on the system.
>
> Did that, only one account on the system (funny to see password in
> clear text by the way). When I tried to create a second one the first
> question was (n,n) : I assume it wants a home directry for the user ?
> Do i simply enter 1,whateverUnused or is there something to do
> before ? Also, the default cli is MCR on the current account, is DCL
> more amenable ?
As Rob said, the UIC is used both to identify the user, and as the
directory name for the user. The UIC in RSX is the same as the
combination of the gid,uid under Unix, except that uid is local for each
gid. So [1,10] is not the same user as [2,10].
Also, some groups imply that the user is privileged. That concept is
also very different from how Unix treats things. And very different from
VMS, or RSTS/E, or any other OS I've used.
As for CLI, it's a matter of preference, but most users not used to MCR
will probably find DCL easier.
>> To check what directories you have, you can always do
>> PIP LB:[0,0]*.DIR/LI
>>
>
> Worked too. I see almost no programming languages on this box, is
> there a way to bring basic/pascal/other ? I found kermit and it works,
> I was able to transfer text files from an to the machine. I digged
> thrrough DECUS and found a ton of things but still a bit lost there.
There are several Pascal compilers from DECUS, as well as a C.
> Some random questions :
>
> so far I'm using 9600 baud rate, I've seen some documentation on
> jumpers to specify an alternate speed but I don't want to mess with my
> only means of communication with that system :) is there a simple way
> to boost this up a bit ? I don't think the system is as slow as it
> seems from tera term !
It might be that you have to get used to it. ;-)
> I want to access the system without being physically hooked to it, do
> you have an idea on the software I could use ? I basically want to
> telnet/whatever my windows machine and have that connection hooked up
> to my rs232 port.
I have few clues for Windows, sorry. Had it been Linux I would just have
suggested log in to the Linux box, have kermit installed there, and
connect out on the serial line.
> Pierre, spending half time preparing a lecture on cloud computing and
> the other half on this :)
And I suspect you've started to feel that this is more fun... ;-)
Johnny Billquist
Good catch. Yes, the disk label definitely suggests that this is 11M,
and not M-PLUS. So I stand corrected. 11M do not have the same idea of
prototype tasks. Instead MCR is a little more hackish, and makes a copy
of the ...xxx task, in case the ...xxx task is already active.
>> I see only one disk physically installed, is there a notion of
>> partitions for hard drives ?
>
> Not on regular DEC gear. An RD54 is a full height 5 1/4 inch hard drive
> (dates from the late mid-80s), so it ought to be hard to miss. I think
> that this is a newer Mentec box, so I would not expect real RD54s in it
> anyway. Mentec could have some kind of partitioning implemented that I
> and RSX do not know about.
Missed this question, but you're right. DEC didn't do partitioning for
RSX for these drives. The only possible way to get partitions is if you
actually have a larger drive, and the disk controller can present it as
several physical disks, thus partitioning the one actual drive that way.
The M70 by the way, is just a Q-bus CPU card. It's in no way more
special than an 11/73 for instance.
>> So, I edited startup.cmd and got rid of that issue. The logon sequence
>> is probably not perfect right now, but at least the major commands are
>> already there and I don't have to fiddle around.
>
> From your initial description as well as this, I think that STARTUP.CMD
> was running some user-written privileged task or loading some
> user-written device driver that did not handle your environment. If you
> simply remove (comment out with "!") the offending command in
> STARTUP.CMD you may find (have found) that the rest can be retained.
Right.
>>> You might want to try running ACNT, to check what accounts and
>>> passwords possibly exist on the system.
>>
>> Did that, only one account on the system (funny to see password in
>> clear text by the way).
>
> Yes. Encrypted passwords in RSX did not appear until 1986 or '87 (and
> maybe only in M-Plus. RSX11M V4.2 predates that.
Only M-PLUS have encrypted passwords, still to this day.
11M also have a max of is it 6 or 8 characters in the password?
>> so far I'm using 9600 baud rate, I've seen some documentation on
>> jumpers to specify an alternate speed but I don't want to mess with my
>> only means of communication with that system :) is there a simple way
>> to boost this up a bit ?
>
> I don't know this Mentec box. On DEC manufactured machines, the system
> console speed can only be changed mechanically. If you have a
> multiplexer, port speeds can be changed individually by software command.
The M70 is the same, if I remember right. I have one such CPU card
somewhere, but with custom boot roms so I can't use it. But I also have
the manual for the card...
>> I want to access the system without being physically hooked to it, do
>> you have an idea on the software I could use ? I basically want to
>> telnet/whatever my windows machine and have that connection hooked up
>> to my rs232 port.
>
> Don't understand the question. Do you have Ethernet on your PDP-11? If
> so, your choices are DECnet or TCP/IP.
I suspect he is thinking of something like doing telnet to the Windows
box, and the windows box acts as a relay between the tcp port and the
serial port on the PC. And the PDP-11 is then hooked to the serial port
of the PC.
> Although unsupported and abandoned now, there was, not so long ago, a
> DECnet stack for Linux. Do you have on your PDP-11? Perhaps the easiest
> way to find out it search for an NCP task file. Try a command like PIP
> [*,*]NCP*.*/LI. (SRD [*,*]NCP would be faster if you have SRD installed.)
Don't even try it. The DECnet for Linux never worked very well with RSX...
> Last I checked the only commercially available TCP/IP stack for RSX was
> from Process Software. It was very expensive and not supported even when
> you did pay them. There is/was an TCP/IP stack for RT-11 (I think). I
> have never seen any sign that it was ever ported to RSX, so either
> nobody wanted it, or it was hard to do. I have never had time, myself.
And then there is my TCP/IP... :-)
> If you don't have Ethernet or DECnet or TCP/IP, then you will want a
> terminal server. One of the more recent DECservers (one that will
> support TCP/IP) will do. Connect ports on the terminal server to ports
> on the PDP-11. Create services on the terminal server so that incoming
> connections from the network connect to one of the serial ports.
That is one solution, definitely. I used to do that in the past...
Lawrence D'Oliveiro
> Also, some groups imply that the user is privileged. That concept is
> also very different from how Unix treats things. And very different from
> VMS, or RSTS/E, or any other OS I've used.
VMS carried over the idea of “system” UICs, by default being all groups from
1 to 10 (octal), presumably as a backward-compatibility measure with RSX.
For some reason, whenever somebody tried to log in, the job controller
spawned the LOGINOUT program running under UIC [10,40]. Was there any
historical significance to this?
Under RSTS/E, all PPNs (their name for UICs) in group 1 were privileged,
others were not.
Johnny Billquist
Indeed. However, privilege in RSX is actually tied to the terminal. What
happens is if you login to a non-privileged account, part of the process
of logging in is to drop the terminal privilege. This is done by
checking the group part of the UIC. For a "privileged" account, this
drop is not done. There is nothing else to it. So you can easily change
that rule to be something else if you want.
The only other aspect of this is that F11ACP allows access to files
based on the protection mask. The system protection mask is applied to
all access done by someone from groups 1-10. But this is totally
separate from the privilege question.
Note also that tasks can be privileged, separately from terminals. There
is a bit in the task header that tells is the task is privileged or not.
It affects what system calls are allowed, and parameters to them. But a
user on a privileged terminal, running a task without the priv bit set
in the task header, that task can't do more than if a non-privileged
terminal ran it.
And of course, a non-privileged user cannot set the privileged status on
again on his terminal. However, another, privileged user, can set the
priv bit on any terminal, so when you are logged in, you can
instantaneously become a privileged user with the help of an existing,
logged in one. And you can instantly loose your privileges at any time
yourself.
As for [10,40], that UIC have no significance with RSX. The whole group
10 is unused. It is sometimes used as the UIC where you create accounts
for actual, privileged people.
Group 1 (and in M-PLUS also group 3) are the two main groups used by the
system for various things.
Commonly [1,54] is where you find all systems tasks, and that is a UIC
used by some tasks. Also [1,1] and [1,2] are sometimes used by some
tasks. In an unmapped 11M system (a system without MMU), the tasks are
in [1,50] instead. And 11S I think uses [1,64] for the same thing.
In M-PLUS, a few tasks reside in [1,54] and the rest in [3,54]. There is
reason for this too, but I think I'll stop now. :-)
Bill Gunshannon
van...@vsta.org writes:
> Rob Brown <mylas...@gmcl.com> wrote:
>> If you don't have Ethernet or DECnet or TCP/IP, then you will want a
>> terminal server. One of the more recent DECservers (one that will
>> support TCP/IP) will do. Connect ports on the terminal server to
>> ports on the PDP-11. Create services on the terminal server so that
>> incoming connections from the network connect to one of the serial
>> ports.
>
> I have an old Cisco 2511 somewhere around here. If you're near the San
> Francisco Bay Area, you're welcome to it. It would give you 16 async ports,
> available via telnet or ssh.
If he doesn't want it and you are willing I would gladly pay the cost
of shipping to get it. I don't have 16 PDP-11's running at the moment
but I could probaly put 10-12 of those ports to real good use!! :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Hans Bachner
> On 2011-01-28 04:26, Lawrence D'Oliveiro wrote:
>> In message<iht7re$v7g$1...@Iltempo.Update.UU.SE>, Johnny Billquist
>> wrote:
>>
>>> Also, some groups imply that the user is privileged. That concept is
>>> also very different from how Unix treats things. And very different
>>> from VMS, or RSTS/E, or any other OS I've used.
>>
>> VMS carried over the idea of "system" UICs, by default being all
>> groups from 1 to 10 (octal), presumably as a backward-compatibility
>> measure with RSX.
<snip>
>
> The only other aspect of this is that F11ACP allows access to files
> based on the protection mask. The system protection mask is applied to
> all access done by someone from groups 1-10. But this is totally
> separate from the privilege question.
But this is (almost) the only remnant of UIC based protection in VMS -
use the "system" protection mask to access files (or other UIC-owned
objects, like devices) if the UIC group is deemed a "system" group. The
upper limit is still 10 (octal) by default, but can be modified with
SYSGEN parameter MAXSYSGROUP. For some reason which I don't remember it
has been suggested to lower this value to 7 already decades ago.
All other aspects of "privileged" have been completely redesigned for
VMS by using a privilege mask (with rather fine granularity) for each
user / process. And then came rights identifiers, ACLs, protected
subsystems, ...
Hans.
Johnny Billquist
Indeed. And as I note, the concept of privileges in RSX are not really
connected to users.
It's shared between the terminal, and privileged tasks.
File protection is something else, where you have the concept of a
system "group". And that is indeed the same between RSX and VMS.
Lawrence D'Oliveiro
> As for [10,40], that UIC have no significance with RSX. The whole group
> 10 is unused. It is sometimes used as the UIC where you create accounts
> for actual, privileged people.
>
> Group 1 (and in M-PLUS also group 3) are the two main groups used by the
> system for various things.
> Commonly [1,54] is where you find all systems tasks, and that is a UIC
> used by some tasks. Also [1,1] and [1,2] are sometimes used by some
> tasks. In an unmapped 11M system (a system without MMU), the tasks are
> in [1,50] instead. And 11S I think uses [1,64] for the same thing.
>
> In M-PLUS, a few tasks reside in [1,54] and the rest in [3,54]. There is
> reason for this too, but I think I'll stop now. :-)
Why so many different privileged user IDs? DEC’s whole idea seemed to be
that privilege was something to be spread around widely all over the place,
as opposed to the more sensible principle that it is something to be tightly
controlled and used in as few places as possible.
Contrast the *nix approach, where there is only one privileged UID, namely
UID 0. There are lots of system processes using other UIDs, but there is no
privilege attached to them, in fact this assignment of different UIDs is
specifically to contain them from each other, so that a security leak in one
will have as little impact on the rest as possible.
Lawrence D'Oliveiro
> All other aspects of "privileged" have been completely redesigned for
> VMS by using a privilege mask (with rather fine granularity) for each
> user / process.
Unfortunately most of that “granularity” was meaningless, with
processes/users having certain privileges being able to give themselves the
effect of having others. It seemed to be mostly a guard against mistakes,
not malice.
The Linux capability system reinvents pretty much the same idea, with the
same drawbacks.
> And then came rights identifiers, ACLs, protected subsystems, ...
ACLs seem difficult to use correctly without unpleasant surprises. Mandatory
access control seems to be the only thing worth using, though it helps to
have a debugging mode where supposedly-disallowed accesses are granted but
logged, so you can be sure your rules are correct and the system won’t come
crashing down when you engage the mode that actually enforces them. :)
Lawrence D'Oliveiro
> On 2011-01-28 01:45, Lawrence D'Oliveiro wrote:
>
>> By the way...
>>
>> In message<alpine.LFD.2.00.1...@libra.gmcl.internal>, Rob
>> Brown wrote:
>>
>>> CMP ofile=file1,file2 vs DIFF ofile=file1,file2
>>
>> Interesting that DEC never made the leap to providing a PATCH to go with
>> CMP/DIFF.
>
> Um... Sure they did...
>
> /SL[:au] Directs CMP to generate an output file suitable for use as SLP
> [/-SL] command input.
I wasn’t talking about outputting editor commands.
Johnny Billquist
> In message<ihu3sh$mvt$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>> As for [10,40], that UIC have no significance with RSX. The whole group
>> 10 is unused. It is sometimes used as the UIC where you create accounts
>> for actual, privileged people.
>>
>> Group 1 (and in M-PLUS also group 3) are the two main groups used by the
>> system for various things.
>> Commonly [1,54] is where you find all systems tasks, and that is a UIC
>> used by some tasks. Also [1,1] and [1,2] are sometimes used by some
>> tasks. In an unmapped 11M system (a system without MMU), the tasks are
>> in [1,50] instead. And 11S I think uses [1,64] for the same thing.
>>
>> In M-PLUS, a few tasks reside in [1,54] and the rest in [3,54]. There is
>> reason for this too, but I think I'll stop now. :-)
>
> Why so many different privileged user IDs? DEC’s whole idea seemed to be
> that privilege was something to be spread around widely all over the place,
> as opposed to the more sensible principle that it is something to be tightly
> controlled and used in as few places as possible.
Well, as I already pointed out, there isn't really much of any privilege
attached to this. In RSX privilege is a concept that exist in two
places. 1) The terminal. 2) Privileged tasks
Terminals are obviously far from the files. And privileged tasks have no
association with which directory they might reside in, or which owner
they might have. It's an attribute in the task header.
To expand a little more, the privilege attribute of the terminal is also
of limited use. It is used by utility programs to check if privileged
operations should be allowed by the program when run. For example, ACNT
checks that bit to decide if you are just allowed to change your own
password, or if the full account administration menu and functions
should be available.
But maybe more importantly, INS.TSK, which is the only way to run
programs that are not installed, checks this bit. (If you type "RUN
[x,y]FOO", it is actually INS that are invoked, which will then install
FOO temporarily, run it, and then deinstall it again.)
If a task has the privileged attribute in the task header, INS will not
allow you to run the task unless you are privileged. Already installed
programs needs to check for privileges, if needed, themself.
That is all there is.
And tasks that have the privileged bit are allowed to do some system
calls that non-privileged users are not. Such as manipulating other
tasks, get some information, and so on...
> Contrast the *nix approach, where there is only one privileged UID, namely
> UID 0. There are lots of system processes using other UIDs, but there is no
> privilege attached to them, in fact this assignment of different UIDs is
> specifically to contain them from each other, so that a security leak in one
> will have as little impact on the rest as possible.
Look at the mess in the Unix world because of the one privilege "root",
which also means you get all the right if you need any. And the fact
that it is tied to a user, so that if you are logged in as that user
things become very dangerous. A lot of criticism about Unix are based in
this very limited and stupid idea. And a lot of exploits have been done
because of it.
I don't think the Unix security design is anything to bring up as a
"good" example. :-) And Unix itself nowadays seems to strive to get away
from this. Look at capabilities, ACLs, and whatnots...
But as I said before, files and tasks running under these UICs don't
have any privileges just because they were to run under these UICs.
Privilege is not attached to the UIC. And even less to the directory
they reside in.
File protection masks are, though. So assuming you were to run a task
under some system UIC, you would be accessing files using a different
protection mask than if you ran as yourself.
But if you manage to run a program under a specific UIC, which by the
way is not in any way related to where the file is located, then you can
probably do anything else with the system as well, so at that point you
already have access to everything.
Which UIC a task runs under is also decided by your terminal privilege
and the task header, by the way. For normal users, the UIC a task is
installed under is always your own UIC. Privileged users can specify
which UIC they want a task to run with, and an installed task use the
UIC specified at install time. The default UIC for tasks installed by a
privileged user is the UIC specified in the task header.
But please note that in RSX, what I am talking about is directories.
There are no users associated with these directories. The files reside
in [1,54] and [3,54], but there is no user using the UIC [3,54] unless
you decide to create one, but why would you?
[1,54] however do exist as a user. It's initially the only account that
exist, and is basically the account for the system administrator.
Johnny Billquist
Really? So what were you talking about?
Because if you have a file, which you make modifications to, CMP can
then create a command file that you use with SLP, in order to get the
same new file based on the old one.
SLP is not a editor that I'd even dream of using as an editor. No more
than I would use patch(1) as an interactive editor. Yes, it is possible,
but no, I would not enjoy the experience.
Johnny
Lawrence D'Oliveiro
> On 2011-01-29 07:12, Lawrence D'Oliveiro wrote:
>
>> In message<iht7a4$utj$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> On 2011-01-28 01:45, Lawrence D'Oliveiro wrote:
>>>
>>>> By the way...
>>>>
>>>> In message<alpine.LFD.2.00.1...@libra.gmcl.internal>,
>>>> Rob Brown wrote:
>>>>
>>>>> CMP ofile=file1,file2 vs DIFF ofile=file1,file2
>>>>
>>>> Interesting that DEC never made the leap to providing a PATCH to go
>>>> with CMP/DIFF.
>>>
>>> Um... Sure they did...
>>>
>>> /SL[:au] Directs CMP to generate an output file suitable for use as
>>> SLP
>>> [/-SL] command input.
>>
>> I wasn’t talking about outputting editor commands.
>
> Really? So what were you talking about?
Being able to cope with what happens when other patches have already been
applied to the same files.
Being able to apply the patch, or reverse it.
Being able to dry-run a patch, to confirm that it will work before actually
changing any files.
Being able to apply patches across a whole directory tree at once.
Being able to cope with inconsistencies in path names between the the source
of the diff and the place where it needs to be applied.
Being able to do diffs on diffs (yes, I have occasionally needed to do
that).
Johnny Billquist
Well, that is mostly a question then of how advanced the patch utility
is, not about the fact that DEC indeed did provide a patch utility to go
with CMP. :-)
As for the various smart things... Just a few comments.
Yes, it is really annoying that SLP isn't smart enough to handle if the
source don't exactly match the one CMP used to generate the SLP-file
for. Context sensitive diffs would have been wonderful.
Applying a patch, or reverse it... Maybe it could be useful. I've
seldom, if ever, actually used that, but I wouldn't have complained if
it could have done it.
Dry-run a patch? What for? If the patch is not creating a useful thing,
then just delete the resulting file. This is RSX. You have versioned
files. Nothing is lost just because you run SLP to create a patched
version of a file.
Since RSX don't (natively) have directory trees (it's a two level
hirarchy only), it's somewhat meaningless to wish for such a thing.
However, SLP is perfectly happy to patch several files at once. Your
problem is more in the fact that CMP can't compare several files at
once, so you need to concatenate the output files from multiple runs of
CMP into one .SLP file. But after that, you're all set to go.
And since the file system is pretty much flat, complaints about path
name differences don't really apply either.
Diffs on diffs. Not sure what you are aiming at here. CMP can compare
any text files, including files that are meant to use as into to SLP.
Hans Bachner
<snip>
> Why so many different privileged user IDs? DECâ s whole idea seemed
> to be that privilege was something to be spread around widely all over
> the place, as opposed to the more sensible principle that it is
> something to be tightly controlled and used in as few places as
> possible.
This allows the "one person - one user account" approach.
> Contrast the *nix approach, where there is only one privileged UID,
> namely UID 0. There are lots of system processes using other UIDs, but
> there is no privilege attached to them, in fact this assignment of
> different UIDs is specifically to contain them from each other, so
> that a security leak in one will have as little impact on the rest as
> possible.
This does not make life easier. You have one privileged account and
maybe a few dozens people who know the password and use it regularely.
This approach makes it practically impossible to attribute privileged
activities/privilege use to individual users.
Hans.
Lawrence D'Oliveiro
> is ...
Precisely my point: diff(1) and patch(1) go together. It’s come to the point
that every version-control system worth using these days can produce diffs
that can be applied by patch.
> As for the various smart things... Just a few comments.
>
> Yes, it is really annoying that SLP isn't smart enough to handle if the
> source don't exactly match the one CMP used to generate the SLP-file
> for. Context sensitive diffs would have been wonderful.
Absolutely essential for collaborative software development. You’re merging
changes coming from different contributors all the time, you’ve got to have
a version-control system that can cope with that.
> Applying a patch, or reverse it... Maybe it could be useful. I've
> seldom, if ever, actually used that ...
Important for testing the effect of a patch: build with it, build without
it, go quickly back and forth as you please.
> Dry-run a patch? What for?
To make sure it applies cleanly. After all, it could conflict with another
patch.
> If the patch is not creating a useful thing, then just delete the
> resulting file. This is RSX. You have versioned files.
Assuming you can keep track of which ones to delete. Too easy to make
mistakes with a multi-file patch. Also not portable.
> And since the file system is pretty much flat, complaints about path
> name differences don't really apply either.
Just another way in which times have changed. :)
Lawrence D'Oliveiro
> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>
> <snip>
>> Why so many different privileged user IDs? DEC’s whole idea seemed
>> to be that privilege was something to be spread around widely all over
>> the place, as opposed to the more sensible principle that it is
>> something to be tightly controlled and used in as few places as
>> possible.
>
> This allows the "one person - one user account" approach.
Enabling full system privileges on a normal user’s account is completely the
wrong approach.
>> Contrast the *nix approach, where there is only one privileged UID,
>> namely UID 0. There are lots of system processes using other UIDs, but
>> there is no privilege attached to them, in fact this assignment of
>> different UIDs is specifically to contain them from each other, so
>> that a security leak in one will have as little impact on the rest as
>> possible.
>
> This does not make life easier. You have one privileged account and
> maybe a few dozens people who know the password and use it regularely.
No need for that. Consider that, on a default Ubuntu installation for
example, the superuser account isn’t even given a password that allows
logins.
Johnny Billquist
You do know that diff and patch were not developed together? diff
initially only generated output that could be fed to ed. Very much the
same way CMP and SLP work.
It was only later that context sensitive diffs came about, and also a
separate patch program. Patch still recognize ed-style diffs, and pass
them on to ed (atleast on NetBSD).
But nowadays you normally want to use context sensitive diffs, yes.
But version control software today is even more depending upon diff3,
since you normally have three two modified files from the same source,
and you want to merge all of that, and notify about any conflicts.
>> As for the various smart things... Just a few comments.
>>
>> Yes, it is really annoying that SLP isn't smart enough to handle if the
>> source don't exactly match the one CMP used to generate the SLP-file
>> for. Context sensitive diffs would have been wonderful.
>
> Absolutely essential for collaborative software development. You’re merging
> changes coming from different contributors all the time, you’ve got to have
> a version-control system that can cope with that.
Yes. And version control systems where you allow several persons to work
on the same file at the same time require a system that can handle
conflicts... Thus context sensitive diffs, and even more than that (see
diff3). However, this is rather far beyond the original claim that DEC
didn't provide a way for output from CMP to be used to patch files.
>> Applying a patch, or reverse it... Maybe it could be useful. I've
>> seldom, if ever, actually used that ...
>
> Important for testing the effect of a patch: build with it, build without
> it, go quickly back and forth as you please.
I've done a lot of development over a long time, and used a number of
different version control systems, and whatnot, and I have not used it
this way at all. So maybe that is more a result of how you as an
individual work?
>> Dry-run a patch? What for?
>
> To make sure it applies cleanly. After all, it could conflict with another
> patch.
Um... That is already detected and marked by diff3...
>> If the patch is not creating a useful thing, then just delete the
>> resulting file. This is RSX. You have versioned files.
>
> Assuming you can keep track of which ones to delete. Too easy to make
> mistakes with a multi-file patch. Also not portable.
Not portable is definitely true. But then again, very little is portable
anyway, so I fail to see the point of that argument.
Keeping track of versions. Well, yes, some brainwork is required.
However, more brainwork is required if you actually are doing
development. You might as well argue about the problem of keeping track
of which patches you have applied, which you have applied in reverse,
not at all, or had conflicts with, and so on. It's all brain work, and
not entirely trivial.
>> And since the file system is pretty much flat, complaints about path
>> name differences don't really apply either.
>
> Just another way in which times have changed. :)
Well, it's hardly news that RSX is 40 years old. :-)
I have a set of patches for you, if you want RSX to have hierachical
directories. Some limits to apply however, but it mostly works just as
you'd wish for.
Bill Gunshannon
Well, I suppose if the tools available don't meet his needs he could always
port diff and patch, I am sure the community would appreciate it!! :-)
Johnny Billquist
> In article<ii2d7o$1mf$1...@iltempo.update.uu.se>,
> Johnny Billquist<b...@softjar.se> writes:
>> On 2011-01-30 00:32, Lawrence D'Oliveiro wrote:
>>> In message<ii0mfd$giu$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>
>>>> On 2011-01-29 07:12, Lawrence D'Oliveiro wrote:
>>>>
>>>>> In message<iht7a4$utj$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>>>
>>>>>> On 2011-01-28 01:45, Lawrence D'Oliveiro wrote:
>>>>>>
>>>>>>> By the way...
>>>>>>>
>>>>>>> In message<alpine.LFD.2.00.1...@libra.gmcl.internal>,
>>>>>>> Rob Brown wrote:
>>>>>>>
>>>>>>>> CMP ofile=file1,file2 vs DIFF ofile=file1,file2
>>>>>>>
>>>>>>> Interesting that DEC never made the leap to providing a PATCH to go
>>>>>>> with CMP/DIFF.
>>>>>>
>>>>>> Um... Sure they did...
>>>>>>
>>>>>> /SL[:au] Directs CMP to generate an output file suitable for use as
>>>>>> SLP
>>>>>> [/-SL] command input.
>>>>>
Oh, definitely. I at least would not complain. I even have an ANSI C
compiler, so I suspect it shouldn't be that hard to just move the
2.11BSD code over for instance, and make some small adaptation to
whatever OS dependent things that might be in there...
As long as we only deal with text files, things should be pretty
straight forward, I imagine...
Lawrence D'Oliveiro
> As long as we only deal with text files, things should be pretty
> straight forward, I imagine...
That’s another well-established *nix tradition, that as far as possible
system configs should be kept in text files. I don’t recall DEC being fond
of that idea...
Lawrence D'Oliveiro
> But maybe more importantly, INS.TSK, which is the only way to run
> programs that are not installed, checks this bit. (If you type "RUN
> [x,y]FOO", it is actually INS that are invoked, which will then install
> FOO temporarily, run it, and then deinstall it again.)
Why such a complicated, roundabout way of doing things? Every other OS I
know of (including other DEC ones) will happily let you run any executable
without having to go through a separate “install” step.
> Look at the mess in the Unix world because of the one privilege "root",
> which also means you get all the right if you need any. And the fact
> that it is tied to a user ...
No it isn’t. It is tied to a process. Some Linux installs don’t even give
the root user a password by default, so you can’t log into it.
> Privilege is not attached to the UIC. And even less to the directory
> they reside in.
Is there some kind of convention with the login program that, if you login
under a “system” UIC, that it does not drop terminal privileges?
> File protection masks are, though.
So those tasks running under all those different “system” UICs are only
getting their privilege from the fact that they were installed with
privilege?
> Which UIC a task runs under is also decided by your terminal privilege
> and the task header, by the way. For normal users, the UIC a task is
> installed under is always your own UIC. Privileged users can specify
> which UIC they want a task to run with, and an installed task use the
> UIC specified at install time. The default UIC for tasks installed by a
> privileged user is the UIC specified in the task header.
Unix introduced this interesting idea of “set-user-id” and “set-group-id”
mask bits for file modes. Any user could set these on their own binaries, it
wasn’t restricted to those with privileged access.
AT&T even had a patent on the concept (an early example of software patents
... sigh).
glen herrmannsfeldt
>> But maybe more importantly, INS.TSK, which is the only way to run
>> programs that are not installed, checks this bit. (If you type "RUN
>> [x,y]FOO", it is actually INS that are invoked, which will then install
>> FOO temporarily, run it, and then deinstall it again.)
> Why such a complicated, roundabout way of doing things? Every other OS I
> know of (including other DEC ones) will happily let you run any executable
I do remember the problems with insalling KERMIT on the PRO/350.
There is a process to transfer the file, but then you have to
convince the OS to let you execute it.
-- glen
Rob Brown
> In message <ii2d7o$1mf$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
> ... system worth using these days ...
So you are comparing modern systems to a thirty year-old system!
Tell me how good your 1981 VCR is.
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
Rob Brown
> On 2011-01-27 22:13, Rob Brown wrote:
>>
>> Yes. Encrypted passwords in RSX did not appear until 1986 or '87
>> (and maybe only in M-Plus. RSX11M V4.2 predates that.
>
> Only M-PLUS have encrypted passwords, still to this day. 11M also
> have a max of is it 6 or 8 characters in the password?
If 6 and 8 are the only choices, I'll go with 6: two RAD50 words.
Lawrence D'Oliveiro
Brown wrote:
> On Sun, 30 Jan 2011 at 14:34 +1300, Lawrence D'Oliveiro wrote:
>
>> In message <ii2d7o$1mf$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>
>> ... system worth using these days ...
>
> So you are comparing modern systems to a thirty year-old system!
A thirty-year-old system being used now, not thirty years ago.
> Tell me how good your 1981 VCR is.
I didn’t have one.
Johnny Billquist
Hmm. Unix is quickly moving away from that. With property lists, xml,
and god knows how much other muck.
Johnny Billquist
> On Fri, 28 Jan 2011 at 03:07 +0100, Johnny Billquist wrote:
>
>> On 2011-01-27 22:13, Rob Brown wrote:
>>>
>>> Yes. Encrypted passwords in RSX did not appear until 1986 or '87 (and
>>> maybe only in M-Plus. RSX11M V4.2 predates that.
>>
>> Only M-PLUS have encrypted passwords, still to this day. 11M also have
>> a max of is it 6 or 8 characters in the password?
>
> If 6 and 8 are the only choices, I'll go with 6: two RAD50 words.
:-)
Good point. But I don't think the password is stored in R50. It's stored
one byte per char, unless my memory fails me. But the allowed characters
comes pretty close to what R50 allows anyway.
I guess we could read the manual. :-D
Johnny Billquist
> In message<ii0m4o$gdv$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>> But maybe more importantly, INS.TSK, which is the only way to run
>> programs that are not installed, checks this bit. (If you type "RUN
>> [x,y]FOO", it is actually INS that are invoked, which will then install
>> FOO temporarily, run it, and then deinstall it again.)
>
> Why such a complicated, roundabout way of doing things? Every other OS I
> know of (including other DEC ones) will happily let you run any executable
> without having to go through a separate “install” step.
Told you... RSX is not handling this like any other OS I know of. :-)
But it's really not that complicated. But RSX is truly a microkernel.
Things like loading a binary for running it is handled by the OS for
most any other OS I know of. RSX delegates that to an external program.
So, if you want to change something around that, you can do it on the fly...
>> Look at the mess in the Unix world because of the one privilege "root",
>> which also means you get all the right if you need any. And the fact
>> that it is tied to a user ...
>
> No it isn’t. It is tied to a process. Some Linux installs don’t even give
> the root user a password by default, so you can’t log into it.
It is not tied to a process. It is a user - root. The fact that you
might not log in as that user don't change this. It is the *uid* of 0.
Not any *pid*. Traditionally, in the passwd file, you have a user entry
for uid, with the username "root", but that is not strictly needed. The
kernel checks for the numerical value of the uid to allow things.
And any program that needs to do anything more interested needs to run
with an effective uid of 0, which means that this program can do just
about anything.
>> Privilege is not attached to the UIC. And even less to the directory
>> they reside in.
>
> Is there some kind of convention with the login program that, if you login
> under a “system” UIC, that it does not drop terminal privileges?
You cannot login to a UIC for which there is no account entry.
A simple comparision is the uid under Unix. You can create files with
any uid as an owner. That does not make it possible to log in and get
that uid. For this, you need a valid entry in the /etc/passwd
>> File protection masks are, though.
>
> So those tasks running under all those different “system” UICs are only
> getting their privilege from the fact that they were installed with
> privilege?
Sigh. What tasks? There are files owned by those different UICs, or
atleast placed under directories based on those UICs. There are no tasks
running under those UICs. There are very few tasks running normally
under RSX, and of those, even fewer are running with privileges. Those
running without privileges are running under the UIC of whatever UIC the
requester has. Not what UIC they happen to be owned by, or even less
what directory they happen to be in.
>> Which UIC a task runs under is also decided by your terminal privilege
>> and the task header, by the way. For normal users, the UIC a task is
>> installed under is always your own UIC. Privileged users can specify
>> which UIC they want a task to run with, and an installed task use the
>> UIC specified at install time. The default UIC for tasks installed by a
>> privileged user is the UIC specified in the task header.
>
> Unix introduced this interesting idea of “set-user-id” and “set-group-id”
> mask bits for file modes. Any user could set these on their own binaries, it
> wasn’t restricted to those with privileged access.
Yes, I know. In RSX, it's a bit more general. If you install a task, you
can specify exactly which UIC it will run under, not just whatever value
is in the owners field.
> AT&T even had a patent on the concept (an early example of software patents
> ... sigh).
Yes, software patents are bad. Couldn't agree more.
Johnny Billquist
That was probably atleast partly because of another thing. Tasks needs
to be contigous in order to be installed. If you just transfer the file,
chances are that it might not be contigous, and thus not runnable.
The reason for this restriction is that the OS keeps just the start
block and the length around as load information for installed programs.
If the file isn't contigous, this information would not suffice. :-)
Lawrence D'Oliveiro
> On 2011-01-31 00:43, Lawrence D'Oliveiro wrote:
>
>> In message<ii4941$l7a$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> As long as we only deal with text files, things should be pretty
>>> straight forward, I imagine...
>>
>> That’s another well-established *nix tradition, that as far as possible
>> system configs should be kept in text files. I don’t recall DEC being
>> fond of that idea...
>
> Hmm. Unix is quickly moving away from that. With property lists, xml,
> and god knows how much other muck.
I don’t notice that on my Linux system. Maybe you’re thinking of a
proprietary UNIX.
Lawrence D'Oliveiro
> On 2011-01-31 00:53, Lawrence D'Oliveiro wrote:
>
>> In message<ii0m4o$gdv$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> Look at the mess in the Unix world because of the one privilege "root",
>>> which also means you get all the right if you need any. And the fact
>>> that it is tied to a user ...
>>
>> No it isn’t. It is tied to a process. Some Linux installs don’t even give
>> the root user a password by default, so you can’t log into it.
>
> It is not tied to a process. It is a user - root. The fact that you
> might not log in as that user don't change this. It is the *uid* of 0.
> Not any *pid*.
No, it is the effective uid, not necessarily the login uid. So you don’t
have to login as uid 0.
> And any program that needs to do anything more interested needs to run
> with an effective uid of 0, which means that this program can do just
> about anything.
Not really. Lots of interesting things happen on my system under other user
IDs:
ldo@theon:~> ps -ef | grep -vE 'root|ldo'
UID PID PPID C STIME TTY TIME CMD
nobody 912 1 0 Jan29 ? 00:26:56 /usr/sbin/g15daemon
timidity 1285 1 0 Jan29 ? 00:00:00 /usr/bin/timidity -Os -iAD
103 1291 1 0 Jan29 ? 00:00:01 /usr/bin/dbus-daemon --system
106 1318 1 0 Jan29 ? 00:00:02 /usr/sbin/hald
106 1366 1319 0 Jan29 ? 00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
daemon 1402 1 0 Jan29 ? 00:00:00 /usr/sbin/atd
avahi 1430 1 0 Jan29 ? 00:00:07 avahi-daemon: running [theon.local]
mysql 1898 1786 0 Jan29 ? 00:02:45 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-
file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
ntp 2007 1 0 Jan29 ? 00:00:10 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 113:122
postgres 2104 1 0 Jan29 ? 00:00:03 /usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c
config_file=/etc/postgresql/9.0/main/postgresql.conf
postgres 2157 2104 0 Jan29 ? 00:00:33 postgres: writer process
postgres 2158 2104 0 Jan29 ? 00:00:20 postgres: wal writer process
postgres 2159 2104 0 Jan29 ? 00:00:06 postgres: autovacuum launcher process
postgres 2160 2104 0 Jan29 ? 00:00:04 postgres: stats collector process
postfix 2264 2255 0 Jan29 ? 00:00:00 qmgr -l -t fifo -u
www-data 5097 1659 0 Jan30 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 5098 1659 0 Jan30 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 5099 1659 0 Jan30 ? 00:00:00 /usr/sbin/apache2 -k start
postfix 7979 2255 0 15:32 ? 00:00:00 pickup -l -t fifo -u -c
> A simple comparision is the uid under Unix. You can create files with
> any uid as an owner. That does not make it possible to log in and get
> that uid. For this, you need a valid entry in the /etc/passwd
The setuid(2) system call takes a uid, not a username. The kernel knows
nothing about the passwd file, and will happily let you set any value for
this field, depending on your privileges.
Similarly for setgid(2).
>> Unix introduced this interesting idea of “set-user-id” and “set-group-id”
>> mask bits for file modes. Any user could set these on their own binaries,
>> it wasn’t restricted to those with privileged access.
>
> Yes, I know. In RSX, it's a bit more general. If you install a task, you
> can specify exactly which UIC it will run under, not just whatever value
> is in the owners field.
But RSX only allows privileged users to do that, right?
Johnny Billquist
Nope. BSD systems seems to have taken a liking to them.
I haven't really dug into Linux enough to tell how bad it is there, but
I would be surprised if the rot hasn't set in there as well.
Johnny Billquist
> In message<ii7m4s$pa4$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>> On 2011-01-31 00:53, Lawrence D'Oliveiro wrote:
>>
>>> In message<ii0m4o$gdv$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>
>>>> Look at the mess in the Unix world because of the one privilege "root",
>>>> which also means you get all the right if you need any. And the fact
>>>> that it is tied to a user ...
>>>
>>> No it isn’t. It is tied to a process. Some Linux installs don’t even give
>>> the root user a password by default, so you can’t log into it.
>>
>> It is not tied to a process. It is a user - root. The fact that you
>> might not log in as that user don't change this. It is the *uid* of 0.
>> Not any *pid*.
>
> No, it is the effective uid, not necessarily the login uid. So you don’t
> have to login as uid 0.
Effective uid and login uid are both a uid. The basic fact is still that
only uid 0 can do anything in Unix. And that is a problem that is as old
as Unix itself. And no argumentation is going to change that fact.
Note that almost all, if not actually all of the interesting ones in
this list starts by running as root, and only then change it to
something else, since it's s bad thing to be root, but they need to be
root at the start in order to do some stuff. Once the privileged stuff
is done, they can change to some other uid.
This is a hack to try and alleviate the problem in Unix that everything
needs to be root in order to do anything "interesting". It's is not a
security feature that they run as something else later on. It's a hack.
>> A simple comparision is the uid under Unix. You can create files with
>> any uid as an owner. That does not make it possible to log in and get
>> that uid. For this, you need a valid entry in the /etc/passwd
>
> The setuid(2) system call takes a uid, not a username. The kernel knows
> nothing about the passwd file, and will happily let you set any value for
> this field, depending on your privileges.
Yes. But the login program will not let you log in to an account with
that uid, since no account with that uid exist.
And it is the same in RSX. With the addition that in RSX you use UICs
for a lot more, so the fact that you have directories for which there
are no entries in the account database is the norm. And thus, you have a
lot of directories and files for which there are no login user. So there
are not a bunch of "privileged" users, just because there are a bunch of
directories.
That was my point. Why are you moving the target?
And besides, files and directories for "privileged" users are
irrelevant, as no privileged is inferred for a program or directory
based on the owner.
Privilege is inferred by the login process. And privileged and file
protection is inferred from the UIC of the running task. And unless you
have a privileged terminal, the UIC for a task is inherited from
yourself, and you cannot run privileged tasks. Privileged terminals can
install tasks permanently, with other UIC and with privilege.
>>> Unix introduced this interesting idea of “set-user-id” and “set-group-id”
>>> mask bits for file modes. Any user could set these on their own binaries,
>>> it wasn’t restricted to those with privileged access.
>>
>> Yes, I know. In RSX, it's a bit more general. If you install a task, you
>> can specify exactly which UIC it will run under, not just whatever value
>> is in the owners field.
>
> But RSX only allows privileged users to do that, right?
Yes.
Lawrence D'Oliveiro
> On 2011-02-01 04:03, Lawrence D'Oliveiro wrote:
>
>> In message<ii7lfr$ovf$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> On 2011-01-31 00:43, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<ii4941$l7a$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>>
>>>>> As long as we only deal with text files, things should be pretty
>>>>> straight forward, I imagine...
>>>>
>>>> That’s another well-established *nix tradition, that as far as possible
>>>> system configs should be kept in text files. I don’t recall DEC being
>>>> fond of that idea...
>>>
>>> Hmm. Unix is quickly moving away from that. With property lists, xml,
>>> and god knows how much other muck.
>>
>> I don’t notice that on my Linux system. Maybe you’re thinking of a
>> proprietary UNIX.
>
> Nope. BSD systems seems to have taken a liking to them.
> I haven't really dug into Linux enough to tell how bad it is there, but
> I would be surprised if the rot hasn't set in there as well.
If you know of any likely instances, please mention them. Because I have
administered a whole bunch of different Linux systems, starting from the
days of Red Hat 9, through various versions of SuSE, a couple of Gentoo
setups, to Debian (Stable for my clients, Unstable for myself). Oh, and a
little netbook running Ubuntu somewhere. And I have yet to find anything in
/etc I couldn’t handle with a text editor.
Bob Eager
BSD has the password database, but that's trivial. It's driven from a
master password file which is a text file. You just run pwd_mkdb if you
edit it. But usually you use tools that hide all that.
--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
*lightning protection* - a w_tom conductor
John Wallace
> On 2011-01-27 22:13, Rob Brown wrote:
>
>
>
>
> >>> With all this said, there are then a few special cases in addition.
> >>> When you type a command in MCR (the "shell"), it will try to figure
> >>> out what to do with it. One thing it tries to do is to check if the
> >>> first three letters of the command you typed matches an installed
> >>> task with the name "...xxx". Tasks that are named in such a way are
> >>> called prototype tasks, and are not meant to be run in the normal
> >>> way. Prototype tasks are handled by MCR in such a way that the
> >>> prototype task gets cloned for your use, and the task name is changed
> >>> to "xxxtnn" where xxx is the same xxx as the command name. tnn is
> >>> constructed based on your TTY, so that if two users run the same
> >>> command, they will end up with their own copies of the same task,
> >>> with their own unique names.
>
> >>> The console terminal, for instance is TT0:. If you type "PIP" on the
> >>> console terminal, you'll get a "PIPT0 " task name running on your
> >>> terminal, which is a copy of "...PIP".
>
> > A good description from Johnny, but here is a nit that I must pick.
> > There is a small difference here between RSX11M and RSX11M-Plus. When
> > you boot up, the system should announce which of the two it is, but I
> > suspect, based on the volume label of your boot disk, that you are
> > actually running RSX11M V4.2. If you RUN $RMD, the top of the display
> > shows which operating system you are running.
>
> > Johnny described what you see when you are running RSX-11M-Plus. If you
> > are running M (not M-Plus) then you will see ...PIP (for example)
> > running. In M, the first simultaneous user of PIP gets the ...PIP task
> > name. Subsequent simultaneous users get the name Johnny described: PIPT0
> > for example.
>
> Good catch. Yes, the disk label definitely suggests that this is 11M,
> and not M-PLUS. So I stand corrected. 11M do not have the same idea of
> prototype tasks. Instead MCR is a little more hackish, and makes a copy
> of the ...xxx task, in case the ...xxx task is already active.
>
> >> I see only one disk physically installed, is there a notion of
> >> partitions for hard drives ?
>
> > Not on regular DEC gear. An RD54 is a full height 5 1/4 inch hard drive
> > (dates from the late mid-80s), so it ought to be hard to miss. I think
> > that this is a newer Mentec box, so I would not expect real RD54s in it
> > anyway. Mentec could have some kind of partitioning implemented that I
> > and RSX do not know about.
>
> Missed this question, but you're right. DEC didn't do partitioning for
> RSX for these drives. The only possible way to get partitions is if you
> actually have a larger drive, and the disk controller can present it as
> several physical disks, thus partitioning the one actual drive that way.
>
> The M70 by the way, is just a Q-bus CPU card. It's in no way more
> special than an 11/73 for instance.
>
> >> So, I edited startup.cmd and got rid of that issue. The logon sequence
> >> is probably not perfect right now, but at least the major commands are
> >> already there and I don't have to fiddle around.
>
> > From your initial description as well as this, I think that STARTUP.CMD
> > was running some user-written privileged task or loading some
> > user-written device driver that did not handle your environment. If you
> > simply remove (comment out with "!") the offending command in
> > STARTUP.CMD you may find (have found) that the rest can be retained.
>
> Right.
>
> >>> You might want to try running ACNT, to check what accounts and
> >>> passwords possibly exist on the system.
>
> >> Did that, only one account on the system (funny to see password in
> >> clear text by the way).
>
> > Yes. Encrypted passwords in RSX did not appear until 1986 or '87 (and
> > maybe only in M-Plus. RSX11M V4.2 predates that.
>
> Only M-PLUS have encrypted passwords, still to this day.
> 11M also have a max of is it 6 or 8 characters in the password?
>
> >> jumpers to specify an alternate speed but I don't want to mess with my
> >> only means of communication with that system :) is there a simple way
> >> to boost this up a bit ?
>
> > I don't know this Mentec box. On DEC manufactured machines, the system
> > console speed can only be changed mechanically. If you have a
> > multiplexer, port speeds can be changed individually by software command.
>
> The M70 is the same, if I remember right. I have one such CPU card
> somewhere, but with custom boot roms so I can't use it. But I also have
> the manual for the card...
>
> >> I want to access the system without being physically hooked to it, do
> >> you have an idea on the software I could use ? I basically want to
> >> telnet/whatever my windows machine and have that connection hooked up
> >> to my rs232 port.
>
> > Don't understand the question. Do you have Ethernet on your PDP-11? If
> > so, your choices are DECnet or TCP/IP.
>
> I suspect he is thinking of something like doing telnet to the Windows
> box, and the windows box acts as a relay between the tcp port and the
> serial port on the PC. And the PDP-11 is then hooked to the serial port
> of the PC.
>
> > Although unsupported and abandoned now, there was, not so long ago, a
> > DECnet stack for Linux. Do you have on your PDP-11? Perhaps the easiest
> > way to find out it search for an NCP task file. Try a command like PIP
> > [*,*]NCP*.*/LI. (SRD [*,*]NCP would be faster if you have SRD installed.)
>
> Don't even try it. The DECnet for Linux never worked very well with RSX...
>
> > Last I checked the only commercially available TCP/IP stack for RSX was
> > from Process Software. It was very expensive and not supported even when
> > you did pay them. There is/was an TCP/IP stack for RT-11 (I think). I
> > have never seen any sign that it was ever ported to RSX, so either
> > nobody wanted it, or it was hard to do. I have never had time, myself.
>
> And then there is my TCP/IP... :-)
>
> > If you don't have Ethernet or DECnet or TCP/IP, then you will want a
> > terminal server. One of the more recent DECservers (one that will
> > support TCP/IP) will do. Connect ports on the terminal server to ports
> > on the PDP-11. Create services on the terminal server so that incoming
> > connections from the network connect to one of the serial ports.
>
> That is one solution, definitely. I used to do that in the past...
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
Are the two of you deliberately ignoring RSX11D and IAS just to upset
me? If I remember rightly they had encrypted passwords, at least by
the early 1980s (if you call bit inversion, or something along those
lines, encryption).
Rich Alderson
Not for a quarter century or so. The program "sudo" has been around about
that long, and is used at educated sites to allow multiple accounts to do
the appropriate admin tasks, with logging of who/what/when.
--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
Lawrence D'Oliveiro
<261c477c-3bdf-4eed...@f21g2000vbg.googlegroups.com>, John
Wallace wrote:
> Are the two of you deliberately ignoring RSX11D and IAS just to upset
> me?
I’m curious about IAS. What exactly was different in that?
John Wallace
central.gen.new_zealand> wrote:
> In message
> <261c477c-3bdf-4eed-ae11-47d6fed6c...@f21g2000vbg.googlegroups.com>, John
>
> Wallace wrote:
> > Are the two of you deliberately ignoring RSX11D and IAS just to upset
> > me?
>
> I’m curious about IAS. What exactly was different in that?
I haven't actually seen IAS for over twenty years but did have the
pleasure of being a user and occasionally manager for a few years on
an 11/70 (and before that, RSX11D on an 11/40 for a while).
Passwords not in cleartext, passwords stored slightly obfuscated in
one of the standard system files (not the same way as on 11M/11M+). I
do know which file but can't remember the exact details; there aren't
many places so it's left as an exercise to the student...
Johnny Billquist
NetBSD now have a whole bunch of files in binary, for which you have
tools to create the binary files based on the text file. Makes you have
to remember to run the creation program after you've edited the file, or
else confusion begins.
But you also have systems calls that now use proplists, and some stuff
is also almost impossible to set up by hand by editing config files,
such as bluetooth, or even wifi stuff.
Point-and-click tools required. :-(
Johnny Billquist
[...]
> Are the two of you deliberately ignoring RSX11D and IAS just to upset
> me? If I remember rightly they had encrypted passwords, at least by
> the early 1980s (if you call bit inversion, or something along those
> lines, encryption).
:-)
Actually, to be honest, I have never worked on 11D or IAS, so I can't
say anything about it (apart from making educated guesses based on my
knowledge of 11M).
I would love to hear more on 11D and IAS. Feel free to contribute.
Bob Eager
Ah well. I just use FreeBSD. As I said, it all seems to just happen
usually, since one would use (e.g.) 'pw' to create or update a user, and
that edits the text files and updates the binary.
Johnny Billquist
Another thing that I read is that device drivers under 11D (and I assume
IAS) were normal, scheduled tasks. In 11M, device drivers are pieces of
code that do not have a task context. They are scheduled in the kernel
more like a kernel thread, to use modern speak.
Well, I assume device driver tasks was privileged tasks, so "normal" is
maybe saying much, but they were tasks, with task context, scheduling
among other tasks, and so on...
But I don't have much more detail on that. But it was one of the reasons
for 11M. A redesign of device drivers to make them more lightweight.
Johnny Billquist
> Hans Bachner<Ha...@Bachner.priv.at> writes:
>
>> Lawrence D'Oliveiro<l...@geek-central.gen.new_zealand> wrote:
>
>>> Contrast the *nix approach, where there is only one privileged UID,
>>> namely UID 0. There are lots of system processes using other UIDs, but
>>> there is no privilege attached to them, in fact this assignment of
>>> different UIDs is specifically to contain them from each other, so
>>> that a security leak in one will have as little impact on the rest as
>>> possible.
>
>> This does not make life easier. You have one privileged account and
>> maybe a few dozens people who know the password and use it regularely.
>> This approach makes it practically impossible to attribute privileged
>> activities/privilege use to individual users.
>
> Not for a quarter century or so. The program "sudo" has been around about
> that long, and is used at educated sites to allow multiple accounts to do
> the appropriate admin tasks, with logging of who/what/when.
sudo does not really solve the Unix problem of everything needs to be
root to be allowed to do things.
It helps, in that you do not need to spread one single password around
to a lot of people, which is a problem in itself. Instead people can use
their own password, which they hopefully are more careful with, and
should never share with anyone.
But once a user have root privileges, everything is open. And without,
most everything is closed. It's still pretty binary.
Using sudo to allow users to only run specific commands is pretty hard
to make safe, since there are so many ways to circumvent that... I've
not seen anyone try to use that to enhance security anywhere.
Didn't Linux implement rights, or something like that, as a new way of
actually being able to grant users(?) and processes(?) specific rights
without having to give them everything? Or is my memory failing me again?
Johnny Billquist
offhand, in NetBSD, you have:
services_mkdb
netgroup_mkdb
dev_mkdb
pwd_mkdb
And of course, newaliases...
Are you sure these don't exist in FreeBSD too...? :-)
Johnny Billquist
Almost forgot... Another binary file is /etc/localtime...
Bob Eager
>> Ah well. I just use FreeBSD. As I said, it all seems to just happen
>> usually, since one would use (e.g.) 'pw' to create or update a user,
>> and that edits the text files and updates the binary.
>
> offhand, in NetBSD, you have:
> services_mkdb
> netgroup_mkdb
> dev_mkdb
> pwd_mkdb
>
> And of course, newaliases...
services_mkdb is there, but optional. To be honest, in most systems it
isn't used (or necessary). If it isn't used, the text file is used. It's
only just appeared in recent versions. I don't use it.
No netgroup_mkdb or dev_mkdb.
As I said, pwd_mkdb exists, but no-one edits the passwd or groups files
any more; they use 'pw' which takes care of it all. The passwd and groups
files are generated too, so that programs can easily read them if they
wish.
Bob Eager
Agreed. But it's not a file one ever has to edit. One just runs tzsetup
to create it, and there it stays.
Rob Brown
On Tue, 1 Feb 2011 at 15:25 -0800, John Wallace wrote:
> Are the two of you deliberately ignoring RSX11D and IAS just to
> upset me?
I never worked on (or even saw) either, having only started working
with any version of RSX (RSX-11B!) in 1977. For a very long time,
many of the RSX-11M manuals mentioned both RSX-11M and IAS. I always
wondered about IAS.
So when did -11D and IAS disappear? What were the differences between
the two, and between them and -11M?
> (if you call bit inversion, or something along those lines,
> encryption).
Must be better than ROT13!
van...@vsta.org
> As I said, pwd_mkdb exists, but no-one edits the passwd or groups files
> any more; they use 'pw' which takes care of it all.
Speak for yourself. :->
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Bill Gunshannon
Well, in a way that's correct as it is just a link to a specific timezone
file. Which does have to be edited and then recompiled with zic whenever
the government decides to play with the DST rules.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
Bob Eager <rd...@spamcop.net> writes:
> On Wed, 02 Feb 2011 11:45:16 +0100, Johnny Billquist wrote:
>
>>> Ah well. I just use FreeBSD. As I said, it all seems to just happen
>>> usually, since one would use (e.g.) 'pw' to create or update a user,
>>> and that edits the text files and updates the binary.
>>
>> offhand, in NetBSD, you have:
>> services_mkdb
>> netgroup_mkdb
>> dev_mkdb
>> pwd_mkdb
>>
>> And of course, newaliases...
>
> services_mkdb is there, but optional. To be honest, in most systems it
> isn't used (or necessary). If it isn't used, the text file is used. It's
> only just appeared in recent versions. I don't use it.
>
> No netgroup_mkdb or dev_mkdb.
>
> As I said, pwd_mkdb exists, but no-one edits the passwd or groups files
> any more; they use 'pw' which takes care of it all. The passwd and groups
> files are generated too, so that programs can easily read them if they
> wish.
Monday and I certainly didn't use "pw". Never have to the best of
my knowledge. Of course, I didn't add them with an editor either,
but I do frequently use "vipw" to make changes to the pasword file(s).
Considering the functions of the password file on Unix, I really don't
see any advantage in making it binary. I have had password files with
over 5000 users over 20 years ago (when systems as well as disks were
not as fast or efficient as they are today) and never had a problem
with delay accessing the file.
Bob Eager
Depends whether you were using a BSD system that has pwd_mkdb, I guess.
'pw' is a one stop way of doing it. It has the advantage of being easily
scripted, too; I have scripts that make password and group file changes,
all using 'pw'.
> Considering the functions of the password file on Unix, I really don't
> see any advantage in making it binary. I have had password files with
> over 5000 users over 20 years ago (when systems as well as disks were
> not as fast or efficient as they are today) and never had a problem with
> delay accessing the file.
I agree. Not quite sure why it's there.
On the other hand, pw_mkdb is necessary in order to construct the shadow
password file -m the public one without even encrypted passwords in it.
Bob Eager
> Bob Eager <rd...@spamcop.net> wrote:
>> As I said, pwd_mkdb exists, but no-one edits the passwd or groups files
>> any more; they use 'pw' which takes care of it all.
>
> Speak for yourself. :->
If you're using FreeBSD, that makes it one step, not two (the second
being pwd_mkdb, which does rather more than simply construct a binary
password file).
John Wallace
It's been a *long* time (IAS V3.1 on an 11/70 in 1985 or so, as an
upgrade from RSX11D on a tired old 11/40).
For a bit of background, you could try http://www.john-a-harper.com/ias.html
who describes it far better than I could (though I do remember that
PLAS is something like Program Logical Address Space).
There are some highlights that I specifically remember.
John Harper's page specifically mentions the scheduler, and it did
seem to work remarkably well in the circumstances. Twenty five years
or more later, every Tuesday morning I ask myself why a Window box
can't distinguish between an interactive application and a background
anti-virus scan and prioritise/schedule accordingly, but when you
combine a Window box and corporate Symantec AV, what else should be
expected except trouble. Sometimes throwing more resources at a
problem isn't the answer.
SYSGEN (or not). DECUS and the like were forever going on about the
wonders (?) of RSX SYSGEN, which was something completely foreign to
the 11D/IAS world; a more constrained set of hardware and software
meant that pre-GENed systems were entirely practical. I guess the
modern equivalent of SYSGEN is rebuilding a Linux kernel; again
something that isn't really widely needed but does provide handy
customisation at times (my other machine at work is a Suse rebuilt
with the RT kernel stuff to support a high speed datalogging app).
Shareable readonly code. This was a big thing on a multiuser system
with not much memory, meaning you only needed one copy of the
program's pure area (or whatever term may have applied), regardless of
however many people were using it. Made it into 11M+ in due course.
DCL, obviously, not that many of us used it after an initial dabble.
Doubtless loads of other stuff that I've forgotten. Enough commonality
with RSX11M to make lots of hand software available, enough
differences to make the move worthwhile.
hth
John
Lawrence D'Oliveiro
> Almost forgot... Another binary file is /etc/localtime...
That’s just a straight copy of a file from /usr/share/zoneinfo. All those
files are compiled from documented source. If you find errors or omissions
in them, submit patches upstream.
I would prefer /etc/localtime was a symlink, which also makes it clearer
what your system timezone is (just follow the link). For some reason, there
are those who object to that...
Lawrence D'Oliveiro
fbed15...@u14g2000vbg.googlegroups.com>, John Wallace wrote:
> For a bit of background, you could try
> http://www.john-a-harper.com/ias.html ...
Hey, neat stuff—thanks for that.
“Read-with-prompt”—now there’s a function I fondly remember from the VMS
terminal driver, which I still consider the best I’ve ever come across. As I
recall, you could implement every terminal I/O function with that one call.
Add the timeout and line-termination mask options, and it made use of all of
the P1-P6 parameters available in $QIO.
> SYSGEN (or not). DECUS and the like were forever going on about the
> wonders (?) of RSX SYSGEN, which was something completely foreign to
> the 11D/IAS world; a more constrained set of hardware and software
> meant that pre-GENed systems were entirely practical. I guess the
> modern equivalent of SYSGEN is rebuilding a Linux kernel; again
> something that isn't really widely needed but does provide handy
> customisation at times (my other machine at work is a Suse rebuilt
> with the RT kernel stuff to support a high speed datalogging app).
Bear in mind with Linux, you can build most optional features as modules.
And you can build and load additional modules at any time without rebuilding
your whole kernel. And start using them without even rebooting...
John Wallace
central.gen.new_zealand> wrote:
> In message <3142125b-012e-44b6-b6b0-
Indeed. Drivers and all kinds of stuff can be done on the fly, unlike
lesser operating systems.
But there are exceptions. OpenSuse's RT options, at least when I was
setting them up, still required a rebuild, and it took me back to the
early days of Digital UNIX, which initially seemed to require a
rebuild every time there was a 'y' in the day (it got a lot better
later).
Johnny Billquist
localtime can be a symlink, or not. That is irrelevant. The contents of
the file, wether you copy it into /etc/localtime, or you make
/etc/localtime a symlink to the actual file, is binary.
Lawrence D'Oliveiro
> sudo does not really solve the Unix problem of everything needs to be
> root to be allowed to do things.
Still does a better job than anything RSX was able to come up with.
Lawrence D'Oliveiro
<11ccb0af-48b2-4edd...@y31g2000prd.googlegroups.com>, John
Wallace wrote:
> OpenSuse's RT options, at least when I was setting them up, still required
> a rebuild ...
Yeah, those real-time patches were floating around outside the official
source tree for a while. Since they impacted a lot of places, you couldn’t
just load them in as a module.
> , and it took me back to the early days of Digital UNIX, which initially
> seemed to require a rebuild every time there was a 'y' in the day (it got
> a lot better later).
I looked after some Alphas around the time of DEC UNIX 4.0d. Don’t recall
ever having to do a rebuild. As a novice admin, my one party trick was
figuring out how to get around the installer’s insistence that /usr shall be
a separate partition from /.
That client set up their first Linux system not long afterwards. The
difference in flexibility was like night and day...
Lawrence D'Oliveiro
> On 2011-02-03 04:13, Lawrence D'Oliveiro wrote:
>
>> In message<iibj1v$36o$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> Almost forgot... Another binary file is /etc/localtime...
>>
>> That’s just a straight copy of a file from /usr/share/zoneinfo. All those
>> files are compiled from documented source. If you find errors or
>> omissions in them, submit patches upstream.
>>
>> I would prefer /etc/localtime was a symlink, which also makes it clearer
>> what your system timezone is (just follow the link). For some reason,
>> there are those who object to that...
>
> localtime can be a symlink, or not. That is irrelevant. The contents of
> the file, wether you copy it into /etc/localtime, or you make
> /etc/localtime a symlink to the actual file, is binary.
But there is never any need to edit it.
Compared to DEC, where most of the config seemed to be 1) in binary files,
and 2) scattered over a bunch of system directories, interspersed with
executables and other stuff.
Filesystem Hierarchy Standard, did they ever hear of it?
Johnny Billquist
> In message<iidr5a$70a$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>> On 2011-02-03 04:13, Lawrence D'Oliveiro wrote:
>>
>>> In message<iibj1v$36o$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>
>>>> Almost forgot... Another binary file is /etc/localtime...
>>>
>>> That’s just a straight copy of a file from /usr/share/zoneinfo. All those
>>> files are compiled from documented source. If you find errors or
>>> omissions in them, submit patches upstream.
>>>
>>> I would prefer /etc/localtime was a symlink, which also makes it clearer
>>> what your system timezone is (just follow the link). For some reason,
>>> there are those who object to that...
>>
>> localtime can be a symlink, or not. That is irrelevant. The contents of
>> the file, wether you copy it into /etc/localtime, or you make
>> /etc/localtime a symlink to the actual file, is binary.
>
> But there is never any need to edit it.
Well, there is, but not that often. But it's just one more binary file.
I've counted to atleast 6 by now. Some of them edited more often than
others. But the fact is that more and more files are not actually text
files anymore. It was more true in the past, but Unix/Linux seems to be
drifting away from that idea.
> Compared to DEC, where most of the config seemed to be 1) in binary files,
> and 2) scattered over a bunch of system directories, interspersed with
> executables and other stuff.
Well, there were/are also much fewer config files than under Unix.
And the scattered thing is less of a problem since you use tools to edit
them anyway. So you don't need to keep track of where they are.
> Filesystem Hierarchy Standard, did they ever hear of it?
I doubt it.
Did it even exist when they designed OSes?
Besides, what relevance do a Unix "standard" have for a non-Unix system?
Johnny Billquist
Really? How do you figure that?
Lawrence D'Oliveiro
> On 2011-02-01 04:13, Lawrence D'Oliveiro wrote:
>> In message<ii7m4s$pa4$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> On 2011-01-31 00:53, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<ii0m4o$gdv$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>>
>>>>> Look at the mess in the Unix world because of the one privilege
>>>>> "root", which also means you get all the right if you need any. And
>>>>> the fact that it is tied to a user ...
>>>>
>>>> No it isn’t. It is tied to a process. Some Linux installs don’t even
>>>> give the root user a password by default, so you can’t log into it.
>>>
>>> It is not tied to a process. It is a user - root. The fact that you
>>> might not log in as that user don't change this. It is the *uid* of 0.
>>> Not any *pid*.
>>
>> No, it is the effective uid, not necessarily the login uid. So you don’t
>> have to login as uid 0.
>
> Effective uid and login uid are both a uid.
But only one actually has anything to do with user logins. Remember you were
trying to claim it was “tied to a user” above? Well, it’s not.
> The basic fact is still that
> only uid 0 can do anything in Unix. And that is a problem that is as old
> as Unix itself. And no argumentation is going to change that fact.
>
>>> And any program that needs to do anything more interested needs to run
>>> with an effective uid of 0, which means that this program can do just
>>> about anything.
>>
>> Not really. Lots of interesting things happen on my system under other
>> user IDs:
>>
>> ldo@theon:~> ps -ef | grep -vE 'root|ldo'
>> UID PID PPID C STIME TTY TIME CMD
>> nobody 912 1 0 Jan29 ? 00:26:56 /usr/sbin/g15daemon
>> timidity 1285 1 0 Jan29 ? 00:00:00 /usr/bin/timidity -Os -iAD
>> 103 1291 1 0 Jan29 ? 00:00:01 /usr/bin/dbus-daemon --system
>> 106 1318 1 0 Jan29 ? 00:00:02 /usr/sbin/hald
>> 106 1366 1319 0 Jan29 ? 00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
>> daemon 1402 1 0 Jan29 ? 00:00:00 /usr/sbin/atd
>> avahi 1430 1 0 Jan29 ? 00:00:07 avahi-daemon: running [theon.local]
>> mysql 1898 1786 0 Jan29 ? 00:02:45 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid- file=/var/run/mysqld/mysqld.pid --
socket=/var/run/mysqld/mysqld.sock --port=3306
>> ntp 2007 1 0 Jan29 ? 00:00:10 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 113:122
>> postgres 2104 1 0 Jan29 ? 00:00:03 /usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c config_file=/etc/postgresql/9.0/main/postgresql.conf
>> postgres 2157 2104 0 Jan29 ? 00:00:33 postgres: writer process
>> postgres 2158 2104 0 Jan29 ? 00:00:20 postgres: wal writer process
>> postgres 2159 2104 0 Jan29 ? 00:00:06 postgres: autovacuum launcher process
>> postgres 2160 2104 0 Jan29 ? 00:00:04 postgres: stats collector process
>> postfix 2264 2255 0 Jan29 ? 00:00:00 qmgr -l -t fifo -u
>> www-data 5097 1659 0 Jan30 ? 00:00:00 /usr/sbin/apache2 -k start
>> www-data 5098 1659 0 Jan30 ? 00:00:00 /usr/sbin/apache2 -k start
>> www-data 5099 1659 0 Jan30 ? 00:00:00 /usr/sbin/apache2 -k start
>> postfix 7979 2255 0 15:32 ? 00:00:00 pickup -l -t fifo -u -c
>
> Note that almost all, if not actually all of the interesting ones in
> this list starts by running as root ...
You’re clearly getting out of your depth here. Instead of randomly firing in
the dark, perhaps you need to go spend some time learning how some of the
above software actually works. It seems your *nix knowledge ends around the
time of Sendmail and the 1988 Morris worm.
A good place to start is by learning about Postfix. You can discover how it
is split into separate pieces that never run as root, and don’t even
entirely trust each other.
Apache is probably also a good one to look at. These are both apps that have
been heavily hammered on by malicious Internet users trying to break them
over many years.
>> The setuid(2) system call takes a uid, not a username. The kernel knows
>> nothing about the passwd file, and will happily let you set any value for
>> this field, depending on your privileges.
>
> Yes. But the login program will not let you log in to an account with
> that uid, since no account with that uid exist.
What has the login program got to do with it? You still seem fixated on this
idea that privilege is associated with a “user”. It’s not. It’s associated
with a process, and can be controlled in much finer-grained ways than via
login.
Lawrence D'Oliveiro
> However, this is rather far beyond the original claim that DEC
> didn't provide a way for output from CMP to be used to patch files.
But as they say, a journey of a thousand miles begins with the first step.
Being able to apply patches in the ways I described was that first step.
I think Larry Wall created patch before he did Perl. The latter may have had
more publicity over the years, and was certainly a far bigger project, but
while that looks to be eclipsed somewhat by later languages, patch is, if
anything, even more heavily used than ever.
Which turned out to be the more pivotal innovation? It might be patch.
> On 2011-01-30 02:34, Lawrence D'Oliveiro wrote:
>>
>> In message<ii2d7o$1mf$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>>> Applying a patch, or reverse it... Maybe it could be useful. I've
>>> seldom, if ever, actually used that ...
>>
>> Important for testing the effect of a patch: build with it, build without
>> it, go quickly back and forth as you please.
>
> I've done a lot of development over a long time, and used a number of
> different version control systems, and whatnot, and I have not used it
> this way at all. So maybe that is more a result of how you as an
> individual work?
Well, I don’t just write software, I also test and debug it. When someone
sends me a patch, I like to be sure it does what they say it does. I also
like to perform QA on my own patches before sending them out.
>>> Dry-run a patch? What for?
>>
>> To make sure it applies cleanly. After all, it could conflict with
>> another patch.
>
> Um... That is already detected and marked by diff3...
That’s assuming my third source file is the same as their third source file.
With distributed, collaborative development, you can’t guarantee that.
>>> If the patch is not creating a useful thing, then just delete the
>>> resulting file. This is RSX. You have versioned files.
>>
>> Assuming you can keep track of which ones to delete. Too easy to make
>> mistakes with a multi-file patch.
>
> Keeping track of versions. Well, yes, some brainwork is required.
Not brainwork, but repetitive tedium. Repetitive edium is what the computer
is best at—let it deal with that, and leave me, the human, free to
concentrate on the important brainwork.
> However, more brainwork is required if you actually are doing
> development. You might as well argue about the problem of keeping track
> of which patches you have applied, which you have applied in reverse,
> not at all, or had conflicts with, and so on. It's all brain work, and
> not entirely trivial.
Any good version-control system will keep track of all that for me.
Lawrence D'Oliveiro
> On 2011-02-03 10:22, Lawrence D'Oliveiro wrote:
>
>> In message<iibceg$13i$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> sudo does not really solve the Unix problem of everything needs to be
>>> root to be allowed to do things.
>>
>> Still does a better job than anything RSX was able to come up with.
>
> Really? How do you figure that?
Based on the more fine-grained control it offers: not only can you specify
which users have privileged access, you can even control the commands
they’re allowed to execute.
Lawrence D'Oliveiro
> On 2011-02-03 10:32, Lawrence D'Oliveiro wrote:
>
>> In message<iidr5a$70a$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>
>>> localtime can be a symlink, or not. That is irrelevant. The contents of
>>> the file, wether you copy it into /etc/localtime, or you make
>>> /etc/localtime a symlink to the actual file, is binary.
>>
>> But there is never any need to edit it.
>
> Well, there is, but not that often.
Never. I have never had to edit a binary timezone file in my life.
> But the fact is that more and more files are not actually text files
> anymore.
Like I said, I simply have not seen that on Linux systems.
>> Compared to DEC, where most of the config seemed to be 1) in binary
>> files, and 2) scattered over a bunch of system directories, interspersed
>> with executables and other stuff.
>
> Well, there were/are also much fewer config files than under Unix.
That seemed to go with less software running under the DEC systems. After
all, where would you keep your DNS resolver config? Your NTP config? Your
MTA config? Your system log config? Your SAMBA config? Your LDAP config?
Your SSL CA certs? Your system printer config? Your X11 config? Your hosts
file? System defaults for user programs like your shell and Emacs? (The
preceding all extracted from a quick scan of my /etc directory.) Your DEC
system would need equivalents to all of those, if it’s going to offer
equivalent functionality.
> And the scattered thing is less of a problem since you use tools to edit
> them anyway. So you don't need to keep track of where they are.
But then you have to remember what tools to use. For instance, how would you
transfer all your custom config settings to a new system?
>> Filesystem Hierarchy Standard, did they ever hear of it?
>
> I doubt it.
> Did it even exist when they designed OSes?
Unix early on seemed to cotton on to some basic conventions. Like putting
all system configs in /etc seemed to happen very early—I think this was
already standard in the mid-1980s, when I had my first exposures to Unix
(which I admit I didn’t think much of at the time).
> Besides, what relevance do a Unix "standard" have for a non-Unix system?
That’s the thing, isn’t it? The designers of the *nix system showed more
foresight, by worrying about details (like an FHS and keeping the system
time in UTC) that others thought unimportant at the time. Look which one has
survived and thrived over the decades, and which ones have not...
John Wallace
central.gen.new_zealand> wrote:
> In message <iidt6h$7m...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
> > On 2011-02-03 10:32, Lawrence D'Oliveiro wrote:
>
With the benefit of hindsight, I hope even the VMS folks would agree
that system time in UTC would have been a better idea than the mess it
ended up as. VMS quadword time, on the other hand, is absolutely
brilliant, simply because it is **one single standard encoding** for
an absolute time, a delta time, any other possible kind of time, and
it comes out of the box with practically every conceivable conversion
or arithmetic routine. Whereas the world of UNIX and Window boxes has
to jump through hoops to do time and date conversions and arithmetic.
I'm not as convinced as Lawrence is that Linux now has a "standard"
filesystem layout either. I'm currently developing an app on SuSe
(32bit) for eventual deployment on (OS tbd, but today's test
environment is fedora 64bit). Things are in different places, things
like libdwarf build differently. Not major differences, but enough to
mean that One Makefile Does Not Fit All.
My favourite Linux portability standard is LSB, but "the nice thing
about standards is that there are so many to choose from".
UNIX is the OS whose authors in the early days couldn't even agree on
how many parameters open() took (BSD open() vs System V open()).
Horses for courses.
Lee K. Gleason
"John Wallace" <johnwa...@yahoo.co.uk> wrote in message
news:4cadc750-d307-4ea5...@k4g2000pre.googlegroups.com...
On Feb 2, 3:51 am, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message
> <261c477c-3bdf-4eed-ae11-47d6fed6c...@f21g2000vbg.googlegroups.com>, John
>
> Wallace wrote:
> > Are the two of you deliberately ignoring RSX11D and IAS just to upset
> > me?
>
>Passwords not in cleartext, passwords stored slightly obfuscated in
>one of the standard system files (not the same way as on 11M/11M+). I
>do know which file but can't remember the exact details; there aren't
>many places so it's left as an exercise to the student...
[377,77]PDSUPF.DAT is the location. I'm curious about the encryption details
if you can recall them...
--
L:ee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net
Lee K. Gleason
an initial dabble.
IAS had more than just DCL - it included a timesharing subsystem (if you
chose to start it) that created an entire timesharing user environment, with
its own CLI (PDS, the early ancestor otf DCL). It also include the fine
grained privilege architecture people are familiar with from VMS (there were
assorted privivleges for different activities, instead of just priv'ed or
non-priv'ed that RSX had). PDS and timesharing allowed you to offer
services to folks who weren't ready for the excitement of dealing with MCR
and CSI style commands, and strict RSX style priority scheduling.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net
Bill Gunshannon
Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> writes:
> In message <iidt6h$7m3$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>> On 2011-02-03 10:32, Lawrence D'Oliveiro wrote:
>>
>>> In message<iidr5a$70a$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>>>
>>>> localtime can be a symlink, or not. That is irrelevant. The contents of
>>>> the file, wether you copy it into /etc/localtime, or you make
>>>> /etc/localtime a symlink to the actual file, is binary.
>>>
>>> But there is never any need to edit it.
>>
>> Well, there is, but not that often.
>
> Never. I have never had to edit a binary timezone file in my life.
Well, I have never edited the binary ones either, but I have had to
edit the text and recompile using zic in the past. And, knowing the
US government inabilty to keep their hands off things like DST, I
expect I will have to do it again int he future. I pointed at it
subtly (maybe too subtly) in a past post, but let me ask this right
out in the open. Just what is the advantage of making these configs
binary instead of plain ASCII files? Considering the extremely small
size of the majority of them, I really see absolutely no advantage
and a whole bunch of disadvantages.
>
>> But the fact is that more and more files are not actually text files
>> anymore.
>
> Like I said, I simply have not seen that on Linux systems.
>
>>> Compared to DEC, where most of the config seemed to be 1) in binary
>>> files, and 2) scattered over a bunch of system directories, interspersed
>>> with executables and other stuff.
>>
>> Well, there were/are also much fewer config files than under Unix.
>
> That seemed to go with less software running under the DEC systems. After
> all, where would you keep your DNS resolver config? Your NTP config? Your
> MTA config? Your system log config? Your SAMBA config? Your LDAP config?
> Your SSL CA certs? Your system printer config? Your X11 config? Your hosts
> file? System defaults for user programs like your shell and Emacs? (The
> preceding all extracted from a quick scan of my /etc directory.) Your DEC
> system would need equivalents to all of those, if it’s going to offer
> equivalent functionality.
The networking stuff could actually be done with one file kept in the
"Networking" directory. Well, except maybe for the SSL CA certs, but
then, their not config files and so not germane to the discussion.
And, of course, one could easily create a directory called [CONFIG] and
put them all there. Unix used to have that, but alas, no more.
>
>> And the scattered thing is less of a problem since you use tools to edit
>> them anyway. So you don't need to keep track of where they are.
>
> But then you have to remember what tools to use. For instance, how would you
> transfer all your custom config settings to a new system?
If that was practical, I would expect the tool to have an Export command.
How do you move all the configs from one Unix machine to the next when
you may not even know where all of them are. Or, what they are called!
>
>>> Filesystem Hierarchy Standard, did they ever hear of it?
>>
>> I doubt it.
>> Did it even exist when they designed OSes?
>
> Unix early on seemed to cotton on to some basic conventions. Like putting
> all system configs in /etc seemed to happen very early—I think this was
> already standard in the mid-1980s, when I had my first exposures to Unix
> (which I admit I didn’t think much of at the time).
>
And yet today.......
>> Besides, what relevance do a Unix "standard" have for a non-Unix system?
>
> That’s the thing, isn’t it? The designers of the *nix system showed more
> foresight, by worrying about details (like an FHS and keeping the system
> time in UTC) that others thought unimportant at the time. Look which one has
> survived and thrived over the decades, and which ones have not...
Let's be realistic here. Unix, per se, has not survived. AT&T is dead.
the CSRG is dead. The only reason Unix has thrived in the manner we see
is that it has no owner. You know, so has CP/M for pretty much the same
reasons. I can assure you if RSX, RSTS and RT-11 were released in source
under a BSD style license they would continue to thrive and even advance.
I know that if I had it witht hat license I would be working very hard
on making RSTS a portable OS with support for a greater selection of
hardware, starting with more memory and porting worthwhile aps and
functions (like TCP/IP and X11) to it. Don't get me wrong, I love Unix.
I have been working with for 30 years. But there are things where it
might not really be the best choice and I would love to see other options
avaiable. And, yes, I love RSTS, too.
John Wallace
> "John Wallace" <johnwalla...@yahoo.co.uk> wrote in message
Ah well, PDS never really caught on where I was, though we did have a
bit of a look. A 785 with VMS arrived there shortly after I left; when
I left, I moved to the big wide world of VMS on VAX (together with
BSD4.1 via Eunice), and Venix (PC/XT), and System V on 68K, hence the
earlier comment about the incompatible different varieties of open().
I'm beginning to wonder if my recollection relates specifically to
RSX11D, rather than IAS. Or maybe PDS user passwords were stored
differently than MCR user passwords?
Anyway, you've got an ODS-1 system disk. You've got the MFD, you've
got 000000.DIR, and you've got INDEXF.SYS (and a few other bits not
relevant to this picture). Afaik there was no MCR-related equivalent
of PDSUPF.DAT. However, each (MCR?) user has a UIC. The associated UIC
has its directory block in INDEXF.SYS. The associated UIC has a
password that's stored somewhere. That's about as far as I'm willing
to go in public (and my recollection may be wrong anyway) but anyone
with an 11D (or IAS?) machine and some appropriate inspiration should
be able to work it out.
Check your inbox in a while.
"strict RSX style priority scheduling."
Is that 11M-style strict priority scheduling?
My recollection is that IAS (and 11D) even without PDS had the handy
scheduler behaviour where terminal IO completion got an application a
brief priority boost in the scheduler, ie interactive apps like
editors got decent service and non-interactive base priority stuff
like compilers lost out slightly (but who cared, compile+link time was
time for tea and/or listings anyway). Maybe PDS took the scheduler
further? I was led to believe 11M didn't do the priority boost
although had very limited experience of 11M to confirm this or
otherwise.
Hth
John
Lawrence D'Oliveiro
<2765b3c1-3aac-4e3d...@a8g2000pri.googlegroups.com>, John
Wallace wrote:
> ... BSD4.1 via Eunice ...
I remember doing some builds from source on DEC Alphas from around 1998—Perl
I think it was—and seeing the message: “Congratulations! You’re not running
EUNICE!”.
Bill Gunshannon
Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> writes:
Actually, I think that used to be in autoconf. but I don't think it is
anymore.
You know, there really was nothing wrong with EUNICE. Conceptually, it
was just like The UCSD P-System and The Software Tools Virtual Operating
System. Way ahead of its time. It needed hardware capabilities to catch
up with it. After all, like the other two mentioned it was just a very
early example of what we, today, call "VM".
And if you think it was just too slow, you should have tried using it
on a VAX-11/780 when someone else was using the ADA Compiler. :-)
van...@vsta.org
> I remember doing some builds from source on DEC Alphas from around 1998?Perl
> I think it was?and seeing the message: ?Congratulations! You?re not running
> EUNICE!?.
That was the grandfather of "configure"--it was shell script. I first ran
into it with Larry's (still excellent) "warp" game.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
John Wallace
> In article <iif5b6$b9...@lust.ihug.co.nz>,
> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> writes:
>
> > In message
> > Wallace wrote:
>
> >> ... BSD4.1 via Eunice ...
>
> > I remember doing some builds from source on DEC Alphas from around 1998—Perl
> > I think it was—and seeing the message: “Congratulations! You’re not running
> > EUNICE!”.
>
> Actually, I think that used to be in autoconf. but I don't think it is
> anymore.
>
> You know, there really was nothing wrong with EUNICE. Conceptually, it
> was just like The UCSD P-System and The Software Tools Virtual Operating
> System. Way ahead of its time. It needed hardware capabilities to catch
> up with it. After all, like the other two mentioned it was just a very
> early example of what we, today, call "VM".
>
> And if you think it was just too slow, you should have tried using it
> on a VAX-11/780 when someone else was using the ADA Compiler. :-)
>
> bill
>
> --
> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
> University of Scranton |
> Scranton, Pennsylvania | #include <std.disclaimer.h>
"there really was nothing wrong with EUNICE."
Spoken like someone who's never had to seriously use it? It did its
best to fit foreign concepts (fork, filesystem, etc) on top of an OS
never intended to support them (and without using the kernel hackery
that VMS POSIX brought). Back then I was doing multiplatform software
development and developing documentation to match. We had an on-paper
quite nice 68K/System V box which was unstable, Eunice (BSD) which was
slow, and VMS (in the days of the V3.7 to V4.x transition) which just
quietly got on with it. Regardless of the paper performance of the
68K, VMS was the most productive environment. For programming, VMS V4
brought a screen oriented debugger. For documentation, HQ had dictated
UNIX nroff etc, but we found it was more productive to write a simple
nroff to runoff translator for drafts, and use the UNIX side only for
fine-tuning the final version. Performance is not the same as
productivity, but it's hard to benchmark productivity.
"when someone else was using the ADA Compiler."
Anybody's Ada (not ADA) compilation system is a relatively complex
beast. Unlike many languages, it's much more than just a compiler and
a linker; there are libraries to process, and in a non-trivial
application there's a lot of inter-module checking to be done, for
example. Processor intensive, memory intensive, and IO intensive.
DEC Ada was widely regarded as the industry best, while it was around,
and when DEC decided not to do Ada 95 there was much wailing and
gnashing of teeth amongst the customers I knew, and others elsewhere.
There were plenty of civil and military customers happily using DEC
Ada on VMS (targetted on VMS and on VAXELN and on M68K), and on
Digital UNIX (for Digital UNIX). Some of them were just using DEC Ada
as a reference to check their other compilers and get decent error
messages out when their other compilers were unhelpful in obscure
circumstances.
Lawrence D'Oliveiro
> You know, there really was nothing wrong with EUNICE.
OK, trivia question. In the days before version 4 which brought in 39.39
names, VMS was restricted to 9-character filenames and 3-character
extensions. So EUNICE used a hashing system to map *nix-style filenames onto
VMS filenames of the form HSHxxxxxx.HSH, with a corresponding HSHxxxxxx.HSN
that contained the real filename.
I noticed a lot of colleagues using EUNICE seemed to end up with this one
particular pair of filenames, HSH0NAEDA.HS[HN], in their login directories.
The question is: what *nix filename did that represent?
Lawrence D'Oliveiro
<940831e9-88b0-4e9c...@v16g2000vbq.googlegroups.com>, John
Wallace wrote:
> "there really was nothing wrong with EUNICE."
>
> Spoken like someone who's never had to seriously use it? It did its
> best to fit foreign concepts (fork, filesystem, etc) on top of an OS
> never intended to support them (and without using the kernel hackery
> that VMS POSIX brought).
By the way, I can’t find anything on Wikipedia about EUNICE or the
Wollongong Group. Anybody want to step up to fill the void? :)
> Anybody's Ada (not ADA) compilation system is a relatively complex
> beast. Unlike many languages, it's much more than just a compiler and
> a linker; there are libraries to process, and in a non-trivial
> application there's a lot of inter-module checking to be done, for
> example. Processor intensive, memory intensive, and IO intensive.
I wonder how it would compare nowadays, though. I think even GCC would be
considered a “complex beast” these days—dealing with Ada would be pretty
much a walk in the park on modern systems.
> DEC Ada was widely regarded as the industry best, while it was around,
> and when DEC decided not to do Ada 95 there was much wailing and
> gnashing of teeth amongst the customers I knew, and others elsewhere.
Fate of proprietary software everywhere, as I have said elsewhere.
How does GNAT compare? They seem to have taken on the role of adopting much
of the code from orphaned compilers of times past.
Johnny Billquist
> In message<ii3prk$gmi$1...@Iltempo.Update.UU.SE>, Johnny Billquist wrote:
>
>> However, this is rather far beyond the original claim that DEC
>> didn't provide a way for output from CMP to be used to patch files.
>
> But as they say, a journey of a thousand miles begins with the first step.
> Being able to apply patches in the ways I described was that first step.
Yes. And DEC did provide CMP and SLP. I don't get it. Why do you have
such a hard time accepting that these do the same thing Unix did with
diff and ed for the first 15 years?
> I think Larry Wall created patch before he did Perl. The latter may have had
> more publicity over the years, and was certainly a far bigger project, but
> while that looks to be eclipsed somewhat by later languages, patch is, if
> anything, even more heavily used than ever.
Yes. He wrote patch before perl.
> Which turned out to be the more pivotal innovation? It might be patch.
Comparing perl with patch? That's like comparing apples and oranges...
>>>> Dry-run a patch? What for?
>>>
>>> To make sure it applies cleanly. After all, it could conflict with
>>> another patch.
>>
>> Um... That is already detected and marked by diff3...
>
> That’s assuming my third source file is the same as their third source file.
> With distributed, collaborative development, you can’t guarantee that.
Without diff3, you cannot have your revision control system. diff and
patch alone will not cut it. That is why diff3 exist.
>>>> If the patch is not creating a useful thing, then just delete the
>>>> resulting file. This is RSX. You have versioned files.
>>>
>>> Assuming you can keep track of which ones to delete. Too easy to make
>>> mistakes with a multi-file patch.
>>
>> Keeping track of versions. Well, yes, some brainwork is required.
>
> Not brainwork, but repetitive tedium. Repetitive edium is what the computer
> is best at—let it deal with that, and leave me, the human, free to
> concentrate on the important brainwork.
Sure. Software can always be improved. Noone have denied that.
>> However, more brainwork is required if you actually are doing
>> development. You might as well argue about the problem of keeping track
>> of which patches you have applied, which you have applied in reverse,
>> not at all, or had conflicts with, and so on. It's all brain work, and
>> not entirely trivial.
>
> Any good version-control system will keep track of all that for me.
Indeed. And any version-control system requires more than diff and
patch. Or else it requires you to check out files and lock them from any
other modifications.