Greetings,
What's the canonical source for patches to 2.9BSD and 2.11BSD?
I see we have 2.11BSD patch 469 dated last month in the archive. Where does
it come from? Has anybody climbed the hill to import all the patches into a
git repo? I've found some mirrors, but moe.2bsd.org has been down for me
for ages... How does Warren keep things up to date?
I also have a (maybe faulty) memory of a similar series of patches to
2.9BSD because it was the last BSD to support non-split I&D space machines.
yet a quick google search turns up nothing other than a set of patches
dated August 1985 (also in our archive) and some changes for variants of
hardware (pro, mscp). Is that it?
Warner
I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
Today I bit the bullet and dropped my many articles and electronic
documents related to my technical explorations into Zotero. I was tired
of constantly having to remember where the documents were located and I
wanted to be able to curate them better (I tried git for a while, back
when, but I'm not a fan of non-text data in my repos, and it wasn't
really much better than the base file system approach). I've been using
Zotero for years now, for academic works, but not for technical works
unrelated to my research. I realized the man-years of effort to clean up
the entries that I had created in about 30-40 seconds of exciting drag
and drop, just about the time I deleted them from their original
locations. I think the work will pay off in due time, but we'll see.
Then I thought, surely, I'm not the first person to have had this
problem... it occurred to me that y'all must have faced this very
problem, a few years in, back in the late 70's, early 80's. That is,
document management. What did you do, variously, considering both text
and non-text?
Will
I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt
calculator was an HP-45 (circa 1973) RPN felt right. However I think
dc pre-dates ALL HP calculators, since there was one in the 1st Edition
written in assembly.
I extened my version of dc (way before gnu existed)
based on common buttons I used from HP calculators:
CMD WHAT
# comment, to new line
~ change sign of top of stack (CHS key)
| 1/top of stack (1/x key)
e push 99 digits of e (2.718..) on the stack
@ push 99 digits of pi on the stack (looks like a circle)
r reverse top of stack (x<>y key)
I had been fascinated with pi stemimg from the Star Trek epsiode Wolf
in the Fold where Spock uses it to usa all computing power
"Computer, this is a Class A compulsory directive. Compute to
the last digit the value of pi."
"As we know, the value of pi is a transcendental figure without
resolution. The computer banks will work on this problem to the
exclusion of all else until we order it to stop."
As it was supposed to be "arbitrary precision" here was my tool.
So I wrote Machin formula in dc slowing increasing the scale and printing
the results. In the orginal dc, yes the whole part was arbitrary, but the
decimal part (scale) was limited to 99. Well that became a disappiontment.
(this program is lost to time)
So I decided to rewrite it but increasing pi as a whole numbers instead
of increasing scale (ex. 31415, 314159, 3141592, ... etc)
I still have that program which is simply this --
[sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ
1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx
if you run it you'll notice the last 1 to 2 digits are wrong due to precision.
The next problem became small memory. I still have thes saved output before
it crashed at 1024 digits. No idea what specs of the machine it was run
on anymore its really old --
3141592653589793238462643383279502884197169399375105820974944592307816\
4062862089986280348253421170679821480865132823066470938446095505822317\
2535940812848111745028410270193852110555964462294895493038196442881097\
5665933446128475648233786783165271201909145648566923460348610454326648\
2133936072602491412737245870066063155881748815209209628292540917153643\
6789259036001133053054882046652138414695194151160943305727036575959195\
3092186117381932611793105118548074462379962749567351885752724891227938\
1830119491298336733624406566430860213949463952247371907021798609437027\
7053921717629317675238467481846766940513200056812714526356082778577134\
2757789609173637178721468440901224953430146549585371050792279689258923\
5420199561121290219608640344181598136297747713099605187072113499999983\
7297804995105973173281609631859502445945534690830264252230825334468503\
5261931188171010003137838752886587533208381420617177669147303598253490\
4287554687311595628638823537875937519577818577805321712268066130019278\
76611195909216420198938095257201065485862972
out of space: salloc
all 8587356 rel 8587326 headmor 1
nbytes -28318
stk 71154 rd 125364 wt 125367 beg 125364 last 125367
83 11 0
30 IOT trap - core dumped
But I was much happier with that.
On a side note: programming dc is hard. There was no comment character.
And it's a pain to read, and it's a pain to debug.
When I discovered the Chudnovsky algorithm for pi, of course I implemented it
in dc --
[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP
7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx
At 99 digits of scale it ran out in 7 rounds, but now with that limitation
removed and large memeories it just goes on and on.....
-Brian
PS: Thanks for the fast OpenBSD version of dc, Otto.
Otto Moerbeek wrote:
> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
> > On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
> > >
> > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
> > >
> > >> Watching the prime number generator (from the Wikipedia page on dc)
> > >> running on the 11/23 is much more entertaining than doing it on the
> > >> modern workstation I'm typing this on:
> > >>
> > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
> > >
> > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient
> > > FreeBSD box.
> >
> > That may be because FreeBSD continues computing primes while the MacOS
> > dc gives up after a while!
> >
> > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
> > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > ^C 11.93 real 11.79 user 0.13 sys
> > $ wc xxx
> > 47161 47161 319109 xxx
> > $ size `which dc`
> > text data bss dec hex filename
> > 238159 2784 11072 252015 0x3d86f /usr/bin/dc
> >
> > MacOS (m1 pro, prob. 2Ghz)
> > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > time: command terminated abnormally
> > 1.00 real 0.98 user 0.01 sys
> > [2] 37135 segmentation fault command time dc <<< > xxx
> > $ wc xxx
> > 7342 7342 42626 xxx
> > $ size `which dc`
> > __TEXT __DATA __OBJC others dec hex
> > 32768 16384 0 4295016448 4295065600 100018000
> >
>
> MacOS uses the GNU implementation which has a long standing issue with
> deep recursion. It even cannot handle the tail recursive calls used
> here and will run out of its stack.
>
> -Otto
Does anybody know how much memory was configured on the PDP-11 that
Lion's used for the commentary system. Here's what the book says about
the system:
; from lions, page 1
; The code selection presumes a "model" system consisting of:
; PDP11/40 processor;
; RK05 disk drives;
; LP11 line printer;
; PC11 paper tape reader/punch;
; KL11 terminal interface.
I usually add the mag tape, too
; TM10 magnetic tape - not in lions, but super handy
It seems like he must have had an MMU and 128k memory, but I don't know.
I'm hoping y'all remember, know, or can otherwise divine the correct
value. I've run with no MMU - crash on boot. I've also run with less
memory, but then cc won't build mkconf, when I have the TM10 enabled
kernel loaded. As a reminder, his book was published in 1977.
Thanks,
Will
> The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have
> an answer as to how you would reuse all that code on different hardware
> in a better way.
Plan 9 did it with #include. The name of the included file was the same for
every architecture. Only the search path for include files changed. Done with
care, this eliminates the typical upfront #ifdefs.that define constants and set
flags.
Other preprocessor conditionals can usually be replaced by a regular if, letting
the compiler optimize away the unwanted alternative. This makes conditionals
obey the scope rules of C.
Doug
6th Edition used the Thompson shell as /bin/sh. I don't think it had
those capabilities. Sometimes you could find an early version of the
Bourne shell in /bin/nsh (new shell) in v6.
The 7th Edition made the Bourne shell /bin/sh. And there sometimes
you could find the Thompson shell in /bin/osh (old shell).
Will Senn wrote:
> Login commands question:
>
> I'm sure it's simple, but I can't figure it out. How do I get something
> to run at login in v6? Right now, I use ed to create a file 'setprof'
> that contains:
>
> stty erase[space][backspace][return]
> stty nl0 cr0
>
> Then after logging in:
>
> sh setprof
>
> It works, but, it is pretty clunky.
>
> stty question:
>
> So, I looked at stty.c and it looks like the following should work, if
> the terminal is sending ^H for backspace:
>
> #define BS0 0
> #define BS1 0100000
>
> modes[]
> ...
> "bs0",
> BS0, BS1,
>
> "bs1",
> BS1, BS1,
>
>
> but:
>
> stty bs0
> or
> stty bs1
>
> don't result in proper backspace handling..
>
> but:
>
> stty[space][^h][return]
>
>
> works...
>
> Thoughts?
Login commands question:
I'm sure it's simple, but I can't figure it out. How do I get something
to run at login in v6? Right now, I use ed to create a file 'setprof'
that contains:
stty erase[space][backspace][return]
stty nl0 cr0
Then after logging in:
sh setprof
It works, but, it is pretty clunky.
stty question:
So, I looked at stty.c and it looks like the following should work, if
the terminal is sending ^H for backspace:
#define BS0 0
#define BS1 0100000
modes[]
...
"bs0",
BS0, BS1,
"bs1",
BS1, BS1,
but:
stty bs0
or
stty bs1
don't result in proper backspace handling..
but:
stty[space][^h][return]
works...
Thoughts?
> From: Clem Cole
> what I don't remember was it in v5
Your memory is going! :-) We discussed this recently (well, recently in _our_
timescale :-); it's built into in 'cc' in V5:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c
see "expand(file)".
Noel
> From: Will Senn
> My question is - how did y'all run things - with CSR zero and no kernel
> messages ... or with CSR non-zero and kernel messages.
On the -11/45 V6+ at MIT, we didn't have a printing terminal on the console,
just a VT52. We had a tool at MIT called 'dmesg':
http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/dmesg.8
which made up for that a bit.
We normally ran with the CSR set to 173030 - the 'boot in single-user'
setting. That's because at one point the machine was in the 9th floor machine
room, but the console VT52 was on the 5th floor (where our offices were - the
famous print of the GE-645 Multics was on the hallway wall outside mine :-),
and I'd added a 'reboot()' system call (nothing fancy, it just jumped to the
bootstrap ROM), so we could reboot the machine without going up in the
elevator (not if it had crashed, of course). Later on, after we'd done with
kernel hacking (adding a network interface, and IP), and the machine stayed up
for long periods, we moved the console up next to the machine (since if it
crashed, you had to use the front panel to restart it, so you had to be up
there anyway); we stayed with the default CSR setting, though. (If it panic'd,
you could see the reason why when you went to reboot it.)
> Oh, BTW, I know I've seen this noted elsewhere, but I can't remember
> where.
Maybe at:
https://gunkies.org/wiki/UNIX_Sixth_Edition#Distros
which discusses it?
Noel
