TUHS

tuhs@tuhs.org

34 participants
6419 discussions

Re: [TUHS] Happy birthday, Dennis Ritchie!

by Doug McIlroy

> When you say MIT you think about ITS and Lisp. That is why emacs IMHO > was against UNIX ideals. RMS was thinking in different terms than Bell > Labs hackers. Very different. Once, when visiting the Lisp machine, I saw astonishingly irrelevant things being done as first class emacs commands, and asked how many commands there were. The instant answer was to have emacs print the list. Nice, but it scrolled way beyond one screenful. I persisted: could the machine count them? It took several minutes of head-scratching and false starts to do a task that was second nature to Unix hands. With hindsight, I realize that the thousand emacs commands were but a foretaste of open-source exuberance--witness this snippet from Linux: !ls /usr/share/man/man2|wc 468 468 6766 Even a "kernel" is as efflorescent as a tropical rainforest.

7 years, 4 months

Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

by Norman Wilson

On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote: > slib.c:1653 (bk-7.3): open failed: permission denied > > which is way way way more useful than just permission denied. Random832 replied: Well. It's less useful in one way - it doesn't say what file it was trying to open. You could pass the filename *instead* of "open failed", but that still omits the issue I had pointed out: what were you trying to open the file for (at the very least, were you trying to read, write, or exec it). Ideally the function would have a format and arguments. ==== Exactly. The string interpretation of errno is just another item of data that goes in an error message. There is no fixed place it belongs, and it doesn't always belong there, because all that is error does not fail from a syscall (or library routine). I do often insert a function of the form void errmsg(char *, ...) in my C programs. It takes printf-like arguments. Normally they just get passed to vfprintf(stderr, ...), though sometimes there is something more esoteric, and often fprintf(stderr, "%s: ", progname) ends up in front. But errmsg never knows anything about errno. Why should it? It's supposed to send complaints to a standard place; it's not supposed to invent the complaints for itself! If an errno is involved, I write something like errmsg("%s: cannot open: %s", filename, strerror(errno)); (Oh, yes, errmsg appends a newline too. The idea is to avoid cluttering code with minutiae of how errors are reported.) I don't print the source code filename or line number except for `this shouldn't have happened' errors. For routine events like the user gave the wrong filename or it had the wrong permissions or his data are malformed, pointers to the source code are just unhelpful clutter, like the complicated %JARGON-OBSCURE-ABBREVIATION prefixes that accompanied every official error message in VMS. Of course, if the user's data are malformed, he should be told which file has the problem and where in the file. But that's different from telling him that line 193 of some file he doesn't have and will probably never see contains the system call that reported that he typed the wrong filename. Norman Wilson Toronto ON

7 years, 4 months

Re: [TUHS] Who is running their own mail server and what do you run?

by Robert Brockway

I received a private request for info on my Postfix config. I'm happy to post to list. This is the interesting bit: https://pastebin.com/tNceD6zM Running under Debian 8, soon to be upgraded to Debian 9. Postgrey is listening on TCP/10023. As an aside I just saw this in my mail queue: # mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 2182087EA 1618 Thu Sep 21 10:41:07 robert(a)timetraveller.org (host aneurin.horsfall.org[110.141.193.233] said: 550 5.7.1 <dave(a)horsfall.org>... No reporting address for linode.com; see RFC 2142 (in reply to RCPT TO command)) dave(a)horsfall.org That is aggressive standards compliance ;) Rob

7 years, 4 months

Trying some new TUHS mail configs

by Warren Toomey

All, sorry for the test post. Grant Taylor has been helping me resolve the mail bounces, which we think are due to the mailing list preserving the existing DKIM information when forwarding to e-mail. This e-mail is going to a test address which should strip the inbound DKIM stuff before passing to the TUHS list. Hopefully we can observe the result and check the logs. Warren

7 years, 4 months

Steering it back again ....

by Warren Toomey

And ... we now bring the threads on current Unix-like systems and current mail configuration to a close, and remind the group that the mailing list is about _old_ things :-) Mind you, if the list lasts another 25 years, these two threads will meet that criterion. Thanks, Warren

7 years, 4 months

Re: [TUHS] Who is running their own mail server and what do you r un?

by Jason Stevens

I use Exchange 5.5 & MacOS + Outlook... I know very un-unixy but it's more so a test bed for a highly modified version of Basilisk II (more so to test appletalk of all things) I route it through Office 365, since I use that for my company, and they have a 'connector' to route a domain through their spam filters and then drop it to my legacy Exchange server. I gave up on the SPAM fight, it really was far too much of a waste of my time. That and this email address is in far far too many databases... :| I'm on the fence if it's really worth the effort though. I wanted to setup some kind of UUCP / Exchange relay, and maybe go full crazy with X.25 but at some point I need to maybe let some of this old stuff just die... It's the same reason I don't run ATM at home. > ---------- > From: Larry McVoy > Sent: Thursday, September 21, 2017 12:25 AM > To: TUHS main list > Subject: [TUHS] Who is running their own mail server and what do you > run? > > I tried running my own server on mcvoy.com but eventually gave up, the > spam filtering was a non-ending task. > > If someone has a plug and chug setup for MX I'd love to try it. > > Thanks, > > --lm >

7 years, 4 months

Test on TUHS mail config

by Warren Toomey

Sorry all, just trying a change on the TUHS mail list config. I'll set it back once I see what this message does. Warren

7 years, 4 months

UNIX of choice these days?

by Rudi Blom

Maybe I'm the odd one out here, but at home I've only got a Windows/10 notebook :-) Mind you, at work I play with . aDEC 400xP, DECpc MTE, Prioris XL server running SCO UNIX 3.2V4.2 . AlphaServer DS10 running Digital Unix 4.0g . AlphaServer DS15 running Tru64 Unix 5.1B . HP(E) rx-servers rx1620, rx2620, rx2660 running HP-UX 11.23 . HP(E) rx-servers rx2800 i2/i4 running HP-UX 11.31 . DOS 6.22, Windows/Xp, Windows/7 clients Maintaining applications which were conceived late 80s is fun :-)

7 years, 4 months

ping

by ron minnich

I got a note about excessive bounces. Can you give me more info? I think somebody is up to something but can't be sure what.

7 years, 4 months

Re: [TUHS] PDP-10 UNIX?

by Nelson H. F. Beebe

I worked on, and co-managed, TOPS-20 on DECsystem 20/40 and 20/60 systems with the PDP-10 KL-10 CPU from September 1978 to 31 October 1990, when our 20/60 was retired. (A second 20/60 on our campus in the Department of Computer Science had been retired a year or two earlier). There were two C compilers on the system, Ken Harrenstien's kcc, and Steve Johnson's pcc, the latter ported to TOPS-20 by my late friend Jay Lepreau (1952--2008). pcc was a straightforward port intended to make C programming, and porting of C software, fairly easy on the PDP-10, but without addressing many of the architectural features of that CPU. kcc was written by Ken Harrenstien from scratch, and designed explicitly for support of the PDP-10 architecture. In particular, it included an O/S system call interface (the JSYS instruction), and support for pointers to all byte sizes from 1 to 36. Normal addressing on the PDP-10 is by word, with an 18-bit address space. Thus, two 18-bit fields fit in a 36-bit word, ideally suited for Lisp's CAR and CDR (contents of address/decrement register, used for first and rest addressing of lists). However, PDP-10 byte pointers encode the byte size and offset in the second half of a word. Pointer words could contain an indirect bit, which caused the CPU to automatically load a memory word at that address, and repeat if that word was found to be an indirect pointer. That processing was handled by the LOAD instructions, so it worked for all programming languages. Characters on the ten-or-so different PDP-10 operating systems were normally 7-bit ASCII, stored left to right in a word, with the right-most low-order bit set to 0, UNLESS the word was intended to be a 5-decimal-digit line number, in which case, that bit was set to 1. Compilers and some other tools ignored line-number words. As the need to communicate with other systems with 8-, 16-, and 32-bit words grew, we had to accommodate files with 8-bit characters, which could be stored as four left-adjusted characters with 4 rightmost zero bits, or handled as 9 consecutive 8-bit characters in two adjacent 36-bit words. That was convenient for binary file transfer, but I don't recall ever seeing 9-bit characters used for text files. By contrast, on the contemporary 36-bit Univac 11xx systems running EXEC-8, the O/S was extended from 6 six-bit Fieldata chararacters per word to 9-bit extended ASCII (and ISO 8859-n Latin-n) characters: the reason was that the Univac CPU had quarterword access instructions, but not arbitrary byte-size instructions like the PDP-10. I don't think that there ever was a C compiler on those Univac systems. On the PDP-10, memory locations 0--15 are mapped to machine registers of those numbers: short loops could be copied into those locations and would then run about 3x faster, if there weren't too many memory references. Register 0 was not hardwired to a zero value, so dereferencing a NULL pointer could return any address, and could even be legitimate in some code. The kcc documentation reports: >> ... >> The "NULL" pointer is represented internally as a zero word, >> i.e. the same representation as the integer value 0, regardless of >> the type of the pointer. The PDP-10 address 0 (AC 0) is zeroed and >> never used by KCC, in order to help catch any use of NULL pointers. >> ... In kcc, the C fopen() call second argument was extended with extra flag letters: >> ... >> The user can override either the bytesize or the conversion >> by adding explicit specification characters, which should come after >> any regular specification characters: >> "C" Force LF-conversion. >> "C-" Force NO LF-conversion. >> "7" Force 7-bit bytesize. >> "8" Force 8-bit bytesize. >> "9" Force 9-bit bytesize. >> "T" Open for thawed access (TOPS-10/TENEX only) >> >> These are KCC-specific however, and are not portable to other >> systems. Note that the actual LF conversion is done by the USYS (Unix >> simulation) level calls (read() and write()) rather than STDIO. >> ... As the PDP-10 evolved, addressing was extended from 18 bits to 22 bits, and kcc had support for such extended addresses. Inside the kcc compiler, >> ... >> Chars are aligned on 9-bit byte boundaries, shorts on halfword >> boundaries, and all other data types on word boundaries (with the >> exception of bitfields and the _KCCtype_charN types). Converting any >> pointer to a (char *) and back is always possible, as a char is the >> smallest possible object. If the original object was larger than a >> char, the char pointer will point to the first byte of the object; this >> is the leftmost 9-bit byte in a word (if word-aligned) or in the halfword >> (if a short). >> ... That design choice meant that the common assumption that a 32-bit word holds 4 characters remained true on the PDP-10. The _KCCtype_charN types could have N from 1 to 36. The case N = 6 was special: it handled the SIXBIT character representation used by compilers, linkers, and the O/S to encode external function names mapped to a 6-bit character set unique to the PDP-10, allowing 6-character unique names for symbols. I didn't readily find documentation of kcc features on the Web, so for those who would like to learn more about support of C and Unix code on the PDP-10, I created this FTP/Web site today: http://www.math.utah.edu/pub/kcc ftp://ftp.math.utah.edu/pub/kcc It supplies several *.doc files; the user.doc file is likely the one of most interest for this discussion. Getting C onto TOP-20 was hugely important for us, because it gave us access to many Unix tools (I was the first to port Brian Kernighan's awk language to the PDP-10, and also to the VAX VMS native C compiler), and eased the transition from TOPS-20 to Unix that began for our users about 1984, and continued until our complete move in summer 1991, when we retired our last VAX VMS systems. Finally, here is a pointer to a document that I wrote about that transition: http://www.math.utah.edu/~beebe/reports/1987/t20unix.pdf P.S. I'll be happy to entertain further questions about these two C compilers on the PDP-10, offline if you prefer, or on this list. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

7 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS