So what is the etymology of "shell", then? I see that Multics has a shell. Was the CTSS user interface also called a shell?
Cheers, Warren
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
John Cowan:
Wikipedia is by nature a *summary of the published literature*. If you
want to get some folklore, like what "cron" stands for, into Wikipedia,
then publish a folklore article in a journal, book, or similar reputable
publication. Random uncontrolled mailing lists simply do not count.
======
That sounds fair enough on the surface.
But if you follow the references cited to support the cron
acronyms, you find that random unsupported assertions in
conference papers do count. That's not a lot better.
I'd like to see a published, citable reference for the
true origin of `cron'. Even better, better published
material for a lot of the charming minutiae of the early
days of UNIX. (Anyone feel up to interviewing Doug and
Ken and Brian and whoever else is left, and writing it up
for publication in ;login:?)
But I'd be satisfied if we could somehow stamp out the
use of spurious references to support spurious claims.
If I had the time and energy I'd look into how to challenge
the cron acronyms on those grounds. Any volunteers?
Norman Wilson
Toronto ON
> From: Will Senn
> 000777 HALT
That's actually "BR ."; the difference is important, since the CPU (IIRC)
doesn't honour DMA requests when it is halted, and DMA needs to be working for
the controller to read that first block (a secondary tape bootstrap) into
memory.
> This seems like gobbledegook to me.
:-)
> It moves the MTCMA (Magtape Current Memory Address) into R0, then it
> moves the MTCMA into the MTBRC (Magtape Byte Record Count)
"The address of the MTCMA into", etc. Looking quickly at the programming spec
for the TM11 controllers, it wants a negative of the byte count to transfer in
this register; the address of the MTCMA just happens to also be a large enough
negative number to be usable as the (negative) size of the transfer request.
(The first record is probably shorter than that, but that doesn't matter.)
Note that this code could probably also have been written:
MOV #172524, R0
MOV R0,@R0
and been equally functional.
> then it moves 60003 into the MTC (Magtape control register), which
> causes a read operation with 800BPI 9 Channel density.
I'm too lazy to look at the programming spec for the details, but that sounds
right.
> Am I misinterpreting the byte codes or is this some idiosyncratic way to
> get the Magnetic tape to rewind or something (the TM11 has a control
> function to rewind, so it seems unlikely that this is the case
No, it's just the shortest possible program to read the first block off the
tape.
It depends on i) the operator having manually set the tape to the right point
(the start of the tape), so that it's the first block that gets read, and ii)
the fact that the reset performed by hitting the 'Start' key on the CPU clears
the TM11 registers, including the Current Memory Address register, so the
block that's read is read into memory location zero.
Hence the direction to 'once the tape has stopped moving, re-start the CPU at
0'.
Noel
> Thank you for responding so carefully.
The devil is in the details...
> I have been reading the PDP-11/40 handbook, much too much :)
I'm not sure that's possible! :-)
Yes, yes, I know, the architecture is deader than a doornail for serious use,
but I liken it to sailing vessels: nobody uses them for serious cargo haul any
more, but they are still much beloved (and for good reasons, IMO).
The PDP-11 is an incredibly elegant architecture, perhaps the best ever (IMO),
which remains one of the very best examples ever of how to get 30 pounds into
the proverbial ten-pount sack - like early UNIX (more below).
> this is really elegant code. The guys who thought this up were amazing.
Nah, it's just a clever hack (small-scale). What is really, almost
un-approachably, brilliant about early UNIX is the amount of functionality
they got into such a small machine.
It's hard to really appreciate, now, the impact UNIX had when it first
appeared on the scene: just as it's impossible for people who didn't
themselves actually experience the pre-Internet world to _really_ appreciate
what it was like (even turning off all one's computers for a day only
approximates it). I think only people who lived with prior 'small computer
OS's' could really grasp what a giant leap it was, compared to what came
before.
I remember first being shown it in circa 1975 or so, and just being utterly
blown away: the ability to trivially add arbitrary commands, I/O redirection,
invisibly mountable sections of the directory tree - the list just goes on and
on. Heck, it was better than all but a few 'big machine' OS's!
> Thanks again for your help.
Eh, de nada.
Noel
John Cowan:
Well, of course there are conferences and there are conferences. The
only conference I've ever had a paper published at, Balisage, is as
peer-reviewed as any journal. (And it is gold open access and doesn't
charge for pages -- the storage costs are absorbed as conference overhead.)
====
Have you actually looked up the cited reference?
The trouble is not that it's a conference paper. The trouble is
that that the `authority' being cited is just a random assertion,
not backed up.
It's as if I mentioned your name in a paper about something else,
remarked in passing and without any citation of my own that you have
a wooden leg, and Wikipedia accepted that as proof of your prosthesis.
Norman Wilson
Toronto ON
(Four limbs and eight eyes, thank you very much)
On Dec 22, 2015, at 5:44 PM, Norman Wilson <norman(a)oclsc.org> wrote:
> If that's the quality of reference they accept, there is simply no
> reason to take anything they publish as gospel.
You're mistaking Wikipedia for an information source you can rely on. It's
not. It's more akin to an attempt to prove that an infinite number of
monkeys, with an infinite number of typewriters, and an infinite amount of
time, can produce a reliable encyclopaedia.
(Yes, yes, spare me the surveys that show that Wikipedia's error rates aren't
that bad, when compared with other encyclopaedias, etc.)
Don't get me wrong, Wikipedia is quite useful as a place for an
_introduction_ to any topic, but anyone who really wants to _reliably_ know
anything about a topic needs to look at the references, not the articles.
There was an attempt to do a Wikipedia-like online encyclopaedia that one
could rely on - Citizendium - but alas it doesn't seem to have taken off (or
hadn't when I got distracted from working on it).
And I know whereof I speak; those who wish to be amused may want to read:
http://en.wikipedia.org/wiki/User:Jnc/Astronomer_vs_Amateur
And apologies for continuing the off-topic (this group certainly can't fix
Wikipedia, people have been complaining about this problem for many years
now), but some buttons, you just have to respond when they are pushed...
Noel
On 2015-12-23 17:04, norman(a)oclsc.org (Norman Wilson) wrote:
> John Cowan:
>
> Wikipedia is by nature a*summary of the published literature*. If you
> want to get some folklore, like what "cron" stands for, into Wikipedia,
> then publish a folklore article in a journal, book, or similar reputable
> publication. Random uncontrolled mailing lists simply do not count.
>
> ======
>
> That sounds fair enough on the surface.
>
> But if you follow the references cited to support the cron
> acronyms, you find that random unsupported assertions in
> conference papers do count. That's not a lot better.
I've had similar experiences with Wikipedia in the past. At one point I
was trying to get the PDP-11 article corrected, as it said that the
PDP-11 was an architecture that disappeared in the 80s (paraphrasing). I
pointed out that the last *new* PDP-11 model from DEC itself was
released in 1990, and that others are still making new PDP-11 CPUs.
My corrections were reverted, and I was asked for citations. I went
through a silly loop of requests for sources for my claims, while there
seems to have been no demand for citation for the original claims, more
than the "knowledge" of someone. It wasn't until I dug up the system
manuals and documentation from DEC about the PDP-11/93 and PDP-11/94
(which have actual time of original publishing date printed) that my
claims were (somewhat) accepted.
I've also had numerous fights about the Wikipedia articles about virtual
memory, where the original authors on the article clearly had not
understood the difference between virtual memory and demand paged
memory. The articles are better today, but when I last looked, they
still had some details wrong in there. And getting anything corrected is
hell, as any silly statement that is already in is almost regarded as
gospel, and anything you try to correct is questioned to hell and back
before anyone will accept it. (Hey, according to Wikipedia, a PDP-11 do
not have virtual memory... I wonder what it has then. Fake memory?
Although, the article might now actually accept that a PDP-11 do have
virtual memory, although no OS I know of implements demand paging, but
that could be done as well, if anyone wanted to.)
Nowadays, I use Wikipedia to find information, but just take everything
in there with a large grain of salt when it comes to details. There are
just too many ignorant people who are writing stuff, and who seem to get
anything accepted, and too much hassle to get anything corrected when
you actually knows the subject.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Perhaps Wikipedia would be satisfied if we could get
Ken to write a letter to some current published journal,
saying that he's the one who named cron, he's heard
people are interested in how it got that name, here's
how. We could then cite that as a reference.
On the other hand, this may be an example of the
degree to which one should trust Wikipedia. The
`command run on notice' acronym claim is backed up
by an article from the AUUG (Hi Warren!) Proceedings,
1994, in which the first reference to cron gives
that explanation with no further reference.
If that's the quality of reference they accept, there
is simply no reason to take anything they publish
as gospel. Sorry.
Norman Wilson
Toronto ON
Proud that no one has yet made a spurious Wikipedia
page asserting the etymology of my personal domain
name.
Larry McVoy:
As a guy who has donated money to Wikipedia this whole thread makes
me not want to donate again. Just me being grumpy.
====
Me too.
Perhaps we should start our own online encyclopedia.
In the Ken tradition we could call it pedi.
(pdia sounds better, but pdia.org is already taken.)
Norman Wilson
Toronto ON
I had never doubted that "cron" was a contraction of "chrono-".
Wikipedia, however, offered several folk acronyms on a par
with it. Brian asked Ken, who confirmed,
"cron comes from the prefix (greek?) for time.
it should have been chron, but i never could spell."
I edited Wikipedia to expunge the nonsense. Amusingly that
makes the article less "verifiable" because there had been
literature citations for the nonsense, but there is none
for the fact.
Doug
All,
I am in the process of gaining a deeper understanding of PDP-11 machine
instructions and how the bootstrap loader and its cousins function. As
part of that process, I am analyzing the code. I am concurrently working
through the DEC bootstrap loader and the bootstrap loader that is
described in the v6 documentation. The DEC bootstrap loader, while
fascinating and elegant, is relatively straightforward, given its
enormous range and the fact that it is self-modifying. I wrote up my
preliminary notes here:
http://decuser.blogspot.com/2015/12/analysis-of-pdp-11-bootloader-code.html
The code that is in the v6 documentation on the other hand is not
yielding easily to reasonable interpretation and I was hoping y'all
might be able to shed some light on how it works.
The following is the TU10 (TM11) bootstrap code from "Setting Up Unix -
Sixth Edition":
TU10
012700
172526
010040
012740
060003
000777
The author's notes around the code are:
The tape should move and the CPU loop. (The TU10 code is not the DEC
bulk ROM for tape; it reads block 0, not block 1.)
Halt and restart the CPU at 0. The tape should rewind. The console
should type ‘=’.
Of course, following the instructions results in a successful outcome,
but understanding what is happening is difficult given that this is a
virtual environment and no discernible tape movement can be detected.
My attempt at interpretation is along the following lines, I
manufactured the dissasembly based on my reading of the PDP-11/40
handbook and the machine codes:
012700 MOV #172526, R0 ; moves the TM11 Current Memory Address Register
(MTCMA) address into R0
172526 ; the immediate operand
010040 MOV R0,-(R0) ; moves the contents of R0, 172526, into
memory location 172524, the TM11 Byte Record Counter (MTBRC)
012740 MOV #60003,-(R0); moves 60003 into memory location 172522, the
TM11 Command Register (MTC)
060003 ; immediate data
000777 HALT
This seems like gobbledegook to me. It moves the MTCMA (Magtape Current
Memory Address) into R0, then it moves the MTCMA into the MTBRC (Magtape
Byte Record Count), then it moves 60003 into the MTC (Magtape control
register), which causes a read operation with 800BPI 9 Channel density.
172526 is -5252 in 2's complement.
Am I misinterpreting the byte codes or is this some idiosyncratic way to
get the Magnetic tape to rewind or something (the TM11 has a control
function to rewind, so it seems unlikely that this is the case, but I'm
mystified)?
I single stepped through the code in the simulator, and the TM11
registers appear to be pretty unobservable (examining these three
registers always displays 0's, but if I change from referencing the TM11
registers to another area of memory, say 100500 I see the values I would
expect to see as they are being moved from the registers into memory).
Thanks,
Will
Hi all, I've been in contact with Steven Schultz and I've set up a
mirror of his 2.11BSD patches at:
http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches/
I have no "git fu", but it would be nice to have a Git repository
with all the sources fully patched. Oh, and new boot tapes :-)
I should ask Santa for it.
Cheers, Warren
Ok, not sure if anyone will want to do this but I've just compiled
ed.c from Unix v6 on Unix v5.
It's not much bigger than the assembled ed, with 1314 lines of C code
the compiled executable is only 6518 bytes vs 4292 for the original. I
was looking at the source code and didn't see anything that the v5 cc
couldn't handle. I trimmed the source a bit, there's a function at the
end called getpid() which is commented out.
The comment says:
/* Get process ID routine if system call is unavailable. */
but my version of v5 does have that system call so it's all good.
It's been run a few times and it seems to work just fine. It may even
have a few more features than the v5 ed, I'm not sure yet :)
Mark
> From: Random832
> Not quite. On a stock V6 kernel, system call 30 (smdate/utime) maps to
> nullsys rather than nosys.
Oh, right. (Hadn't checked the number, assumed they used a new one for utime.)
Noel
> From: Random832
> Non-existent syscalls map to nosys, which sets u_error to 100 ... which
> causes the process to be sent a signal SIGSYS.
Oh, right, I'd forgotten that.
So, getting back to v6tar, I'll bet that if you try and use it to _read_ a TAR
file file under V6 (i.e. write files into the V6 filesystem), it will bomb out
(because of the call to utime).
Noel
> From: Mark Longridge
> Not too sure about reversing getpid.o, but maybe possible with db?
Well, me, I'd just use 'od' - but then again, I have ucode for disassembling
PDP-11 octal! :-) (OK, OK, so a lot of the less common instructions I have
to look up! :-)
But, seriously, yeah, 'db' is probably the way to go.
FWIW, it's possible to get 'adb' running under V6 without much (any?) work,
too. Although maybe it needs the 'phototypesetter' C compiler? I'd have to
check...
There's also a 'cdb' running around (I found a copy on the 'Shoppa disks'),
which is basically 'db' but augmented with a few useful commands - maybe stack
backtrace, I don't recall the details, the documentation in on my V6, and I
don't feel like spinning it up just to look for that.
Noel
So, speaking of system calls that are missing in earlier versions of Unix,
that tickled a memory:
> From: Will Senn
> ... a special version of tar must be prepared to run on V6.
> The document goes on to describe a reasonable method to make v6tar on
> v7 and copy the binary over to the v6 system.
When I got tar running on my V6, I didn't know about this, and I took
a V7 tar and got it running myself, see here:
http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html#tar
One thing I found out while doing that is that tar uses the 'utime' system
call on V7 to set the file date, but i) V6 doesn't have utime() (although it
has smdate(), albeit commented out in the standard distro), and ii) on now
looking in src/cmd/tar and src/libc/v6 in the V7 distro, I don't see a
replacement version of utime().
As near as I can make out, 'v6tar' must be using the standard V7 version of
utime(), which I assume turns into a call to nosys() on V6 (returns an error);
tar doesn't check the return value, so the call fails (silently). So v6tar
won't correctly set the file date when moving a file _to_ V6.
Noel
> From: Mark Longridge <cubexyz(a)gmail.com>
> if one looks at /lib/libc.a via 'ar t getpid.o' you can see the object
> file getpid.o
Library, schlibrary! The important question is 'is it in the kernel source'?
(Although now that I think about it, if the library routine tries to use a
non-existent system call, it should return an error. It would be interested
to disassemble the library routine, and see what it thinks it is doing.)
Noel
On 2015-12-12 06:31, Peter Jeremy<peter(a)rulingia.com> wrote:
> Also, I've seen suggestions that there's a 2.11BSD patch later than
> 447 but I can't find anything "official" andwww.2bsd.com is either
> down or inaccessible from all the systems I have access to. Does
> anyone know if 448 or later were released? And given the issues with
> www.2bsd.com would someone be willing to mirror it (assuming we can
> got a copy of it)?
Yes, I did 448. Various bits and pieces that were fixed there, but
unfortunately I haven't managed to reach Steve to get it officially
sanctioned.
I've passed it out a few times, but there is no canonical place for it.
You can find it at ftp://ftp.update.uu.se/pub/pdp11/2.11bsd/
Feel free to pass that information around.
Things fixed in there:
. Added a timeout to boot prompt for automatic boot
. Made console 8-bit clean
. Changed gethnamadr to fall back to /etc/hosts if dns fails.
. Fixed kernel build process to get version and date properly into kernel.
. Fixed raboot to work on non-DEC mscp controllers
. Fixed tmac macro to work correctly after 2009.
. Fixed a couple of documentation errors.
Essentially small issues that bothered me as I was running on an 11/84
with a CMD controller a few years ago. A system on which I also booted
other OSes, which is why the 8-bit clean issue also bothered me.
(Also was really surprised at the ugly Y2K fix someone had done with
tmac, which failed again in 2010).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Ken Iverson was born in 1920; he is (in)famous for inventing APL. And if
you haven't used APL\360 on a dumb Kleinschmidt[*] terminal, you didn't
miss anything.
[*]
And that's the first time I've seen a spell-checker suggest that it be
replaced with "Consummated".
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Some time ago, someone posted an early Unix image that I recall
running. I know it was pre-groups but don't recall anything else and
I can't find either the images or mailing list references either
locally or on tuhs.org. Does anyone recall the details.
Also, I've seen suggestions that there's a 2.11BSD patch later than
447 but I can't find anything "official" and www.2bsd.com is either
down or inaccessible from all the systems I have access to. Does
anyone know if 448 or later were released? And given the issues with
www.2bsd.com would someone be willing to mirror it (assuming we can
got a copy of it)?
--
Peter Jeremy