IMMSMC the early Linux had problems with some old-good programs i.e. Sendmail.
New-born Linux hesitated between POSIX-BSD-Solaris semantic
i.e. in file-locking, pty, network interface binding e.t.c.
>From the early Sendmail README:
===
Linux
Something broke between versions 0.99.13 and 0.99.14 of Linux:
the flock() system call gives errors. If you are running .14,
you must not use flock. You can do this with -DHASFLOCK=0.
Around the inclusion of bind-4.9.3 & linux libc-4.6.20, the
…
[View More]initialization of the _res structure changed. If /etc/hosts.conf
was configured as "hosts, bind" the resolver code could return
"Name server failure" errors. This is supposedly fixed in
later versions of libc (>= 4.6.29?), and later versions of
sendmail (> 8.6.10) try to work around the problem.
Some older versions (< 4.6.20?) of the libc/include files conflict
with sendmail's version of cdefs.h. Deleting sendmail's version
on those systems should be non-harmful, and new versions don't care.
Sendmail assumes that libc has snprintf, which has been true since
libc 4.7.0. If you are running an older version, you will need to
use -DHASSNPRINTF=0 in the Makefile. If may be able to use -lbsd
(which includes snprintf) instead of turning this off on versions
of libc between 4.4.4 and 4.7.0 (snprintf improves security, so
you want to use this if at all possible).
NOTE ON LINUX & BIND: By default, the Makefiles for linux include
header files in /usr/local/include and libraries in /usr/local/lib.
If you've installed BIND on your system, the header files typically
end up in the search path and you need to add "-lresolv" to the
LIBS line in your Makefile. Really old versions may need to include
"-l44bsd" as well (particularly if the link phase complains about
missing strcasecmp, strncasecmp or strpbrk). Complaints about an
undefined reference to `__dn_skipname' in domain.o are a sure sign
that you need to add -lresolv to LIBS. Newer versions of linux
are basically threaded BIND, so you may or may not see complaints
if you accidentally mix BIND headers/libraries with virginal libc.
If you have BIND headers in /usr/local/include (resolv.h, etc)
you *should* be adding -lresolv to LIBS. Data structures may change
and you'd be asking for a core dump.
[View Less]
I've managed to reach an important milestone in my efforts to recreate
2.11BSD pl 0 from sources. I've managed to unwind the patches, recreated
some programs that were lost (the patches destroyed data and weren't modern
context diffs).
So I've managed to unwind back to pl 0, I've managed to bootstrap the
assembler (it wouldn't build on pl 195), recreate ld, ranlib and ar. I've
rebuilt the libraries and many binaries.
https://bsdimp.blogspot.com/2020/07/211bsd-original-tapes-recreation.html…
[View More]No tapes yet, but I thought people here would like to know.
Warner
[View Less]
(if this is better suited for COFF, that'd be fine too)
I've been trying to set up UUCP on my V7 system and its raspberry Pi host.
This plus the "s" editor (already working) are really all that's needed to
make this something pretty close to a daily driver, if all I wanted to do
was write text files (which in some sense is all my job _is_, but to be
fair I get a much more immediate feedback loop in my current environment).
I was following
https://github.com/jwbrase/pdp11-tools/blob/master/…
[View More]howtos/V7%20UUCP%20Insta…
more or less--I had already rebuilt v7 with the DZ terminal driver and was
using it for interactive sessions (albeit, before I started trying to get
UUCP running, with 7-bit line discipline--but I've since changed that).
I have 16 DZ lines, I've set them to 8-bit mode. They're working fine,
because I can use them for terminal sessions.
I've built UUCP, set a node name, and set it up on the pi.
I can execute uucico to send files, and it, frustratingly, almost works.
>From the Pi side, I see (with uulog):
uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol
'g' sending packet/window 64/3 receiving 64/7)
uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
/home/adam/git/simh/sim_scsi.h (6780 bytes)
uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for
packet
uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86,
resent 6, received 1
uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
order 0, remote rejects 0
uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440
bytes 19 bps)
So it's clearly logging in, and if I telnet in directly, the v7 end is
starting uucico as expected:
login: pi-uucp
Password:
Shere
uulog -x on the v7 side has no output, and nothing ever appears in the
spool directory, which I suspect is a direct result of the timeout waiting
for packet.
So my question is, what else do I do to debug this? Clearly the pi (Taylor
UUCP) side is expecting something else--maybe an acknowledgement?--from the
v7 side to let it know the transmission was successful.
Any help would be appreciated.
Adam
[View Less]
John Linderman:
Every "divestiture" had an adverse effect on critical mass. The split
between AT&T and Bellcore was a big hurt.
The split between AT&T and Lucent was another. When I joined the Labs in
1973, it was an honor to work there.
====
Maybe I'm blinded because I wasn't there earlier, but
to me, joining Bell Labs in 1984, just after the original
divestiture that split off Bellcore, was still an honour.
There were certainly good people I never had a chance to
work with …
[View More]because they went to Bellcore, but in 1127 at
least, morale was good, management stayed out of our way
and encouraged researchers to work on whatever interested
them, and a lot of good work was done even if that group
was no longer the source of All UNIX Truth. (In fact I
think we missed the boat on some things by being too
inwardly-focussed, TCP/IP in particular, but divestiture
didn't cause that.)
It seemed to me that the rot didn't really begin to show
until around 1990, the time I left (though not for that
reason; this is hindsight). Upper management were
visibly shifting focus from encouraging researchers to
do what they did best to treating researchers as a source
of new products to be marketed. The urge to break the
company up further seems to me to have been a symptom,
not a cause; the cause was a general corporate shift
toward short-term profits rather than AT&T's traditional
long-term view. AT&T was far from alone in making this
mistake, and research in the US has suffered greatly all
over as a result.
I remember visiting a couple of years after I left, and
chatting with my former department head. He said 1127
was having trouble convincing new researchers to join up
because they'd heard (correctly) that the physics and
chemistry research groups were being cut back, and feared
computing science would have its own reckoning soon enough.
In fact the corporate direction of the time was to cut
back on the physical sciences and push to expand software
research and development, but I don't blame the new
researchers for being concerned (nor did my ex-DH), and
in the long term they turned out to be more right than
wrong.
Nothing lasts forever, but the classic Bell Labs lasted
a long time. We have nothing like it now. I don't think
we'll have anything like it any time soon. That's sad.
Norman Wilson
Toronto ON
[View Less]
Preferring fewer emails, but not wanting to miss out on topics
that had not occurred to me, I would continue to subscribe
to the digest and not switch to a topic-filtering option.
Doug
On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote:
> People (not just Clem), when you change the topic, can you please
> modify the Subject: to match? I'm not overly interested in uucp,
> but editors are a completely different matter. I'm sure I'm not the
> only one, so many interested parties will miss these replies.
I see this type of change happen — in my not so humble opinion — /way/
/too/ /often/.
So, I'm wondering if people are interested in configuring TUHS and / or
COFF …
[View More]mailing list (Mailman) with topics. That way people could
subscribe to the topics that they are interested in and not receive
copies of topics they aren't interested in.
I'm assuming that TUHS and COFF are still on Mailman mailing lists and
that Warren would be amicable to such.
To clarify, it would still be the same mailing list(s) as they exist
today. They would just have the to be utilized option of picking
interesting topics. Where topics would be based on keywords in the
message body.
I'm just trying to gauge people's interest in this idea.
--
Grant. . . .
unix || die
[View Less]
Dave Horsfall:
A boss of mine insisted that we all learned "ed", because one day it might
be the only editor available to you after a crash; he was right...
====
Besides which, as The Blessed Manual said in every
Research edition:
ed is the standard text editor.
Norman Wilson
Toronto ON
(typing this in Toronto qed)
John Cowan:
Very much +1. Part of the trouble is that Gmail and similar clients don't
routinely show you the Subject: line to make it easy to edit it; you have
to take affirmative action when you want to change the subject matter.
====
Perhaps we should take a leaf from 1980s Rob Pike, and
just automatically change every message to be
Subject: The content of this message
(There is an actual story behind that, but I'll leave it
to Rob to tell.)
Norman Wilson
Toronto ON
