Aside: I'm sending this reply to TUHS where the message that I'm
replying to came from. But i suspect that it should migrate to COFF,
which I'm CCing.
On 3/20/20 5:48 AM, paul(a)guertin.net wrote:
> I teach math in college, and I use an RPN calculator as well (it's
> just easier).
Would you please elaborate on "it's just easier"?
I'm asking from a point of genuine curiosity. I've heard many say that
RPN is easier, or that it takes fewer keys, or otherwise superior to
infix notation. But many of the conversations end up somewhat devolving
into religious like comments about preferences, despite starting with
honest open-minded intentions. (I hope this one doesn't similarly devolve.)
I've heard that there are fewer keys to press for RPN, but the example
equations presented have been effectively he same.
I've heard that RPN is mentally easier. But I apparently don't know
enough RPN to be able to think in RPN natively to evaluate myself.
I dabble with RPN, including keeping my main calculator app on my smart
phone in RPN mode.
So I am genuinely interested in understanding why you say that RPN is
just easier.
> Sometimes, during an exam, a student who forgot to bring their
> calculator will ask if they can borrow mine. I always say "sure, but
> you'll regret it" and hand them the calculator. After wasting one or
> two minutes, they give it back.
~chuckle~
> (Note that I always make sure no calculator is needed for my exams,
> but it's department policy to authorise non programmable calculators,
> and it seems to reassure students to have the calculator on the desk,
> so I don't mind.) >
ACK
--
Grant. . . .
unix || die
As many of you may be aware, Bruce D. Evans <bde(a)freebsd.org> died in
mid-December. I am currently looking through his digital estate on
behalf of his family and the FreeBSD Project.
I have discovered that he kept an extensive collection of 5¼" floppy
disks. I haven't looked through them but they appear to include
things like OS-9 and Hitachi Peach files (and presumably Minix stuff,
though I haven't found any of his Minix work). He also has a
selection of newletters from an Australian Peach users group. Is
there any interest in this material from a historicial perspective?
--
Peter Jeremy
On 3/8/20 9:39 PM, Warner Losh wrote:
> floppy controller supports the full range of crazy that once roamed
> the earth
Does anyone have any knee jerk reaction to the idea of putting a 5¼"
floppy drive on a USB-to-Floppy (nominally 3½") adapter?
Do I want to avoid tilting at this windmill?
Am I better off installing the 5¼" floppy inside the computer and
connecting directly to the motherboard?
I'm only wanting to pull files off of 5¼" disks. At most I'll want to
dd the disks to an image.
That being said, I wonder if I should also be collecting any different
types of images. (This may mean mobo instead of USB.)
Thank you for any pro-tips that you can provide.
--
Grant. . . .
unix || die
Moving to COFF ....
On Tue, Mar 17, 2020 at 10:58 AM Larry McVoy <lm(a)mcvoy.com> wrote:
> As much as I don't care for Forth, man do I wish it had become the standard
> for boot proms, it might not be my cup of tea but I could make it do what
> I needed it to do.
Amen bro... Sun did a nice job on that. Although the Alpha Boot ROMs
were pretty good too. At least they were UNIX like and were extensible like
the Sun boot ROMs. HP's were better than a PC BIOS, but they were pretty
awful.
> Can't say the same for UEFI, I disable that crap.
>
Well, it beats the crap out of IBM's BIOS, but that bar is very low. UEFI
was sort of a 'camel' (a horse designed by committee) and too many people
peed on it. Intel created EFI to try to fix BIOS and then people went
nuts. Apple's version is the best of them, but as you say, they all suck
if you have seen anything better. A big problem IMO is that EFI tried to
be somewhat compatible. In the end, they were not, so you got the worst of
both (new interfaces and legacy functionality).
Server systems that support IPMT have Minux under the covers in
coprocessor, which using a coprocessor is also how Apple runs UEFI. With
IMPT, it is sort of sad more of it is not really exposed, but you need the
added cost of the coprocessor. Plus it adds a new security domain, which
many people complain about. I try to know as little about it as possible
to get my work done, but exposing more of that interface might help.
Hi all, I'm looking for an interactive tool to help students learn the
Unix/Linux command line. I still remember the "learn" tool. Is there an
equivalent for current systems?
I have tried to forward-port the old learn sources to current Linux but
my patience ran out :-)
Thanks in advance for any tips/pointers.
Cheers, Warren
Given the recent discussion of pipes and networking ... I'm passing this
along for those that might not have seen it.
---------- Forwarded message ---------
From: Jack Haverty via Internet-history
Date: Tue, Mar 10, 2020 at 1:30 PM
Subject: Re: [ih] NCP and TCP implementations
To: *Internet-History*
The first TCP implementation for Unix was done in PDP-11 assembly
language, running on a PDP-11/40 (with way too little memory or address
space). It was built using code fragments excerpted from the LSI-11
TCP implementation provided by Jim Mathis, which ran under SRI's
home-built OS. Jim's TCP was all written in PDP-11 assembler. The code
was cross-compiled (assembled) on a PDP-10 Tenex system, and downloaded
over a TTY line to the PDP-11/40. That was much easier and faster than
doing all the implementation work on the PDP-11.
The code architecture involved putting TCP itself at the user level,
communicating with its "customers" using Unix InterProcess
Communications facilities (Rand "Ports"). It would have been
preferable to implement TCP within the Unix kernel, but there was simply
not enough room due to the limited address space available on the 11/40
model. Later implementations of TCP, on larger machines with twice the
address space, were done in the kernel. In addition to the Berkeley BSD
work, I remember Gurwitz, Wingfield, Nemeth, and others working on TCP
implementation for the PDP-11/70 and Vax.
The initial Unix TCP implementation was for TCP version 2 (2.5 IIRC), as
was Jim's LSI-11 code. This 2.5 implementation was one of the players
in the first "TCP Bakeoff" organized by Jon Postel and carried out on a
weekend at ISI before the quarterly Internet meeting. The PDP-11/40 TCP
was modified extensively over the next year or so as TCP advanced
through 2.5, 2.5+, 3, and eventually stabilized at TCP4 (which it seems
we still have today, 40+ years later!)
The Unix TCP implementation required a small addition to the Unix kernel
code, to add the "await" and "capac" system calls. Those calls were
necessary to enable the implementation of user-level code where the
traditional Unix "pipeline" model of programming
(input->process->process...->output) was inadequate for use in
multi-computer programming (such as FTP, Telnet, etc., - anywhere where
more than one computer was involved).
The code to add those new system calls was written in C, as was almost
all of the Unix OS itself. The new system calls added the functionality
of "non-blocking I/O" which did not previously exist. It involved very
few lines of code, since there wasn't room for very many more
instructions, and even so it required finding more space by shortening
many of the kernel error messages to save a few bytes here and there.
Randy Rettberg and I did that work, struggling to understand how Unix
kernel internals worked, since neither of us had ever worked with Unix
before even as a user. We did not try to "get it right" by making
significant changes to the basic Unix architecture. That came later
with the Berkeley and Gurwitz efforts. The PDP-11/40 was simply too
constrained to support such changes, and our mission was to get TCP
support on the machine, rather than develop the OS.
I think I speak authoritatively here, since I wrote and debugged that
first Unix TCP code. I still have an old, yellowing listing of that
first Unix TCP.
FWIW, if there's interest in why certain languages were chosen, there's
a very simple explanation of why the Unix implementation was done in
assembler rather than C, the native language of Unix. First, Jim
Mathis' code was in assembler, so it was easy to extract large chunks
and paste them into the Unix assembler implementation. Second, and
probably most important, was that I was very accustomed to writing
assembler code and working at the processor instruction level. But I
barely knew C existed, and was certainly not proficient in it, and we
needed the TCP working fast for use in other projects. The choice was
very pragmatic, not based at all on technical issues of languages or
superiority of any architecture.
/Jack Haverty
On 3/9/20 11:14 PM, vinton cerf via Internet-history wrote:
> Steve Kirsch asks in what languages NCP and TCP were written.
>
> The Stanford first TCP implementation was done in BCPL by Richard Karp.
> Another version was written for PDP-11/23 by Jim Mathis but not clear in
> what language. Tenex was probably done in C at BBN. Was 360 done in PL/1??
> Dave Clark did one for IBM PC (assembly language/??)
>
> Other recollections much appreciated.
>
> vint
--
Internet-history mailing list
Internet-history(a)elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
I started using 'cpio' in the 80tish and still use it, especially
transferring files and complete directories between various UNIX
versions like SCOUNIX 3.2V4.2, Tru64, HP-UX 11i..
The main option I use with cpio is (of course) "-c" and only occasionally "-u"
Hi,
while exploring the gopherspace (YES! Still existing,
growing community) I found this gopher page:
gopher://pdp11.tk/1
which can be reached with Lynx for example.
Unfortunately I cannot evaluate the items there, but
may be it is worth a look by someone knowledgeable.
Cheers!
mcc
I work at an astronomy facility. I get to do some fun dumpster diving.
I recently have pulled out of the trash a plugboard with a male and a
female D-Sub 52 connector. 3 rows of pins, 17-18-17. I took the
connectors off the board: there's nothing back there, so this thing only
ever existed so you could plug the random cable you found into it and its
friends to see what the cable fit.
I can't find much evidence that a 52-pin D-Sub ever existed.
Is this just Yet Another Physics Experiment thing where, hey, if your
instrument already costs three million dollars, what's a couple of grand
for machining custom connectors? Or was it once a thing?
(also posting to cc-talk)
Adam
