Hi all,
Would anyone here be able to help me troubleshoot my qd32 controller? I
have a pdp11/73 that's mostly working, boots 2.11 from rl02 okay, but I
need my big disk to work so I can load the rest of the distro.
I've been following the manual for the qd32 to enter the geometry of my
real working m2333 (jumpered correctly according to the manuals), but when
I load the special command into the qd32's SP register that's supposed to
load the geometry table from the pdp11 memory to the novram, I get a bad
status value from the qd32's SP register and it remains unresponsive when I
try to store the geometry. If I go ahead and try the built-in qd32 format
command, it responds similarly. When I pull in mkfs from tape (vtserver)
and try anyway, despite the failures, to run mkfs on the m2333, I get an
!online error from the standalone unix mkfs. The disk does respond (the
select light flashes and I can hear heads actuating), but without geometry
and format, I'm obviously dead in the water.
Any suggestions on how to proceed?
thx
jake
> Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway?
Symmetry. You unmount what you mount.
A competing model is that of links. Link makes an old file available
under a new name. But you unlink by the new name. Necessarily so,
because there may be many new names for one old file.
This is reminiscent of Don Norman's screed about the unnaturalness
of Unix. He didn't like strcpy because the arguments come in the
opposite order to those of cp. But stcpy is part of C, and in
C the destination of assignment comes before the source. But Norman
didn't rail at C. You pays your money and takes your choice.
Doug
these were in by the time I can along but I was wondering when they got it.
They've also always felt a bit like a thing that did not fit to me. I'm
pretty sure I was not alone, given that the Unix authors worked out a way
to get rid of them in later efforts. I know what came after, in Plan 9;
what came before, in Unix, that led to special files?
We lost computer pioneer John von Neumann on this day in 1957; the "von
Neumann" architecture (stored program etc) is the basis of all modern
computers, and he almost certainly borrowed it from Charles Babbage.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Greg Lehey
>> V3 and earlier still *called* them special files, but it seems they
>> were essentially just magic inode numbers (there was no physical file
>> on disk, just any directory entry with the given inode would be the
>> special file).
> Isn't that still the case?
>From reading the manual page (URL sent earlier), in V3 and before it really
was just an inode _number_ (less than 50, IIRC). The first inode, in the
first disk block after the super-block, was inode #51. This is of course
different from later Versions, where there is an _inode_ for devices, but
still no actual _file_.
Noel
Co-inventor of Unix, he was born on this day in 1943. Just think: without
those two, we'd all be running M$ Windoze and thinking that it's
wonderful (I know, it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> My experience is that the problems involved in making a program faster are
> often quite interesting and fun to work on. But the problems making things
> fit in a small space are, IMHO, really deadly.
First make things "as simple as possible, but no simpler" (Einstein). Ken and
Dennis not only cut out fat, they also found generalizations that combined
traditionally disparate features, so the new whole was smaller (and more
comprehensible) than the sum of the old parts. The going gets tough in the
presence of constraints on space or time. Steve's perception, I think, is
colored by the experience of facing hard limits on space, but not on time.
Describing one complication of hard time constraints, John Kelly used to
say that the Packard Bell 250 was "the only machine I ever used where
you transfer to a time of day rather than a memory location". (The delay-
line memory had two instruction formats: one was operation + address-of-
next-instruction, the other was just the operation--the next instruction
being whatever came out of the delay line when the operation ended. The
latter mode minimized both execution time and code space, but the attention
one had to pay to time was, to borrow Steve's phrase, "really deadly".)
Design tradeoffs for efficiency pose an almost moral conundrum:
whether to make things fast or make them easy. For example, the
classic Unix kernel typically did table lookup by linear search,
whereas Linux (when I last looked) typically used binary search.
The price of Linux's choice is that one must take care to keep
the tables sorted. Heavy discipline has to be imposed on making
entries and deletions.
Doug
What do you mean plan9 is dead? It's even possible make a facebook post
from inside plan9 nowadays!
https://twitter.com/bigatojj/status/949838932841201664
See vmx(1)
Em 3 de fev de 2018 23:25, "Steve Simon" <steve(a)quintile.net> escreveu:
Hi,
I have to take issue with the “plan9 is dead” statement,
I agree it seems on a downward spiral, but are a few who fight on.
[sent from my plan9]
-Steve
