> From: Dave Horsfall
> We lost Jon Postel, regarded as the Father of the Internet
Vint and Bob Kahn might disagree with that that... :-)
> (due to his many RFCs)
You need to distinguish between the many for which he was an editor (e.g. IP,
TCP, etc), and the (relatively few, compared to the others) which he actually
wrote himself, e.g. RFC-925, "Multi-LAN address resolution".
Not that he didn't make absolutely huge contributions, but we should be
> Now it could be that v7 troff is perfectly capable of generating the
> manual just like older troff would have.
On taking over editorship for v7, I added some macros to the -man
package. I don't specifically recall making any incompatible
changes. If there were any, they'd most likely show up in
the title and synopsis and should be fixable by a minor tweak
to -man. I'm quite confident that there would be no problems
with troff proper.
Angelo Papenhoff <aap(a)papnet.eu> writes about the conversion of
printer points to other units:
>> >From my experience in the world of prepress 723pts == 10in.
>> Then Adobe unleashed PostScript on us and redefined the point
>> so that 72pt == 1in.
>> Ibunaware of any other definitions of a point.
The most important other one is that used by the TeX typesetting
system: 72.27pt is one inch. TeX calls the Adobe PostScript one a big
point: 72bp == 1in. Here is what Don Knuth, TeX's author, wrote on
page 58 of The TeXbook (Addison-Wesley, 1986, ISBN 0-201-13447-0):
>> The units have been defined here so that precise conversion to sp
>> is efficient on a wide variety of machines. In order to achieve
>> this, TeX's ``pt'' has been made slightly larger than the official
>> printer's point, which was defined to equal exactly .013837in by
>> the American Typefounders Association in 1886 [cf. National Bureau
>> of Standards Circular 570 (1956)]. In fact, one classical point is
>> exactly .99999999pt, so the ``error'' is essentially one part in
>> 10^8. This is more than two orders of magnitude less than the
>> amount by which the inch itself changed during 1959, when it
>> shrank to 2.54cm from its former value of (1/0.3937)cm; so there
>> is no point in worrying about the difference. The new definition
>> 72.27pt=1in is not only better for calculation, it is also easier
>> to remember.
Here sp is a scaled point: 65536sp = 1pt. The distance 1sp is smaller
than the wavelength of visible light, and is thus not visible to
TeX represents physical dimensions as integer numbers of scaled
points, or equivalently, fixed-point numbers in points, with a 16-bit
fraction. With a 32-bit word size, that leaves 16 bits for the
integer part, of which the high-order bit is a sign, and the adjacent
bit is an overflow indicator. That makes TeX's maximum dimension on
such machines 1sp below 2^14 (= 16,384) points, or about 5.75 meters
or 18.89 feet.
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
> From: Jacob Ritorto
> If this is true, I wonder why the install only offers rl01?
Where does it say this? (I didn't search for that.)
> I'm totally in the market for an Able Enable board too! Out of
> zcuriosity, is it totally out of the question to just find the prints
> and do a production run?
Rotsa ruck! They're down the same mine as Jimmy Hoffa!! :-)
But seriously, if you could find them, that would be fantastic. I've managed
to collect (thanks Clem!) a tiny bit of info about them:
and I _think_ I've worked out how they worked, but more is better. We had a
set of the prints at MIT BITD, but we didn't have the PROM/PLA/PAL/etc
programming info, and one would need that too to reproduce them.
> I sure hope there's a pdp11 sdcard / usb disk solution someday like they
> did for the Commodore 64
So Dave Bridgham and I have been working on a QBUS card with an FPGA that uses
an SD card to hold the bits, and emulates an RK11/RP11/etc controller. We have
a wire-wrap prototype working (the RK11's done, the RP11 should be a short
edit of that), and UNIX boots and runs. Now to turn it into PCB's...
We've planned that the next step will be to do a UNIBUS version, which will
also include ENABLE functionality (although it won't be plug compatible with
an ENABLE, the memory will be on-board).
Now to find the time/energy to make it happen... :-(
> From: Noel Hunt
> In addition to SINE, does anyone know what happened to EINE?
Was replaced by ZWEI fairly early on.
Dunno if it still exists on an MIT dump-tape somewhere.
I am starting to collect, if possible, different versions of the QED
editor; with a hope to put up a git repo.
If you have a tarball of code, please send it to me with as much info
about it as you have. I would like to track down the qedbuf(1) man page
I have contacted Rob Pike and got one tarball from him. I have another
tarball that I got sometime in 1987 and have a promise of code coming
Was wanting to put together a fully functional (meaning able to load the
whole distro and recompile itself) and "reliable" System III machine made
of real, albeit not terribly sexy parts. I have (4) working rl02 drives
and an 11/34, so I feel like there's a chance it could work. I'll have to
build it on the emulator, of course, then vtserver it over to the real hw
But the blocker is that System III only supports rl01, not rl02, which
kills the 'full distro' prospect.
Would anyone know if it's trivial to modify the source for the rl01 driver
to just add double the blocks, thereby supporting rl02? Or am I wildly
underestimating the task at hand? Has this been done before? Tips?
Does anyone know any history about X11's secondary selection?
What did / still does use it?
I'm fairly familiar with the primary selection and clipboard. But I'm
not aware of anything that uses the secondary selection.
Grant. . . .
unix || die