TUHS September 2017

tuhs@tuhs.org

97 participants
84 discussions

by Norman Wilson

Larry McVoy: > +1 on what Ron said. I don't get the rationale for going back to ptrace. > Anyone know what it is? Is there a perf issue? Kurt H Maier: The usual rationale presented is that someone can exhaust the fd table and then you can't get anything done. Instead of fixing that problem, the popular approach is to add more syscalls, like with getrandom(2). ==== Funny that that rationale isn't extended to its logical conclusion: get rid of open and creat. Then nobody needs to worry about running out of file descriptors ever! I too am saddened to see such a retrograde step, but perhaps I'm biased. When I arrived in 1127, the kernel had /proc but still had ptrace as well. Why? Because no one was brave enough to wade into sdb and adb. After a couple of years, I felt brave enough, so I did it. Once the revised sdb and adb had propagated to all our systems, I removed the syscall. I celebrated by physically removing ptrace(2) from the Eighth Edition manual in the UNIX room: the manual entry comprised two facing pages, which I glued together. I can sympathize with FreeBSD excuse someone cited elsewhere, that nobody used the code so it should go--I'm always in favour of improving programs by chopping sutff out--but I think the decision here was backwards. The proper answer would have been to teach ps et al to use /proc, not to invent a new complex of system calls. I dislike how Linux has tossed information about processes and other system-related data into the same namespace (and now that there is /sys as well as /proc, I wonder whether it's time to divorce them, or even to move /proc into /sys/proc), but the general direction of moving things into the file system makes sense. I have some qualms about adding more and more code to the kernel that just does string processing (making the kernel bigger and more complicated, and widening the attack surface for bad guys), though; maybe most of that stuff belongs not in the OS proper but in a user-mode program that reads /dev/mem and presents as a file system. Norman Wilson Toronto ON

7 years, 2 months

Re: [TUHS] APPLIX-L On this day... (Rosetta Stone, Einstein's equation, first Model T, first passenger train)

by Dave Horsfall

On Wed, 27 Sep 2017, Roland Turner wrote: > * Simply attaching the entire message as a message/rfc822 part is an > appealing approach, but very few mail clients would do anything > intelligent with it. My MUA of choice, Alpine, certainly does, and it's hardly uncommon. I tried Elm once, and immediately went straight back to Pine (as it was known then); never bothered with Mutt. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 2 months

TUHS: munged From header for DKIM

by Warren Toomey

All, I've set up a mirror TUHS list which munges the From: line to keep mail systems like Gmail happy. I've migrated some of you over to this new list: those whose subscriptions were disabled due to excessive bounces. I'm hoping that this will a) fix most of the bounce problems and b) keep those who don't want address munging happy. If I've moved you and you want to be put back on the non-munged list, let me know. Fingers crossed that this is a good solution, Warren

7 years, 2 months

Excessive bouncing ... argh!

by Warren Toomey

All, overnight the mail list blocked about 60 people because of excessive bouncing. It was probably because the list has been busy, and the bounce threshold for the (mostly gmail) addresses was exceeded. I've manually re-enabled them all. I have installed the script that strips DKIM and ARC header lines before the list software processes the inbound e-mails. We will see if that helps. Apologies, Warren

7 years, 2 months

Another mail list idea

by Warren Toomey

All, I just had a whole bumch of gmail addresses disabled on the TUHS list because of DKIM. I had an idea. I'll create a second list which munges the From: line. E-mail to tuhs(a)tuhs.org will go to both lists. I'll move the gmail people over to the munging list. This is just a test e-mail to see if the munging list works. I'm the only one on it. If it seems to work, I'll move the gmail folk over. Cheers, Warren

7 years, 2 months

Re: [TUHS] Sockets and the true UNIX

by Norman Wilson

Clem Cole: It was never designed for it. dmr designed Streams to replace the tty handler. I never understood why the Summit guys insisted on forcing networking into it. ====== You've mistaken. The point of the stream I/O setup with stackable line disciplines, rather than the old single line-discipline switch, was specifically to support networking as well as tty processing. Serial-device drivers in V7 used a single line-discipline driver, used variously for canonical-tty handling and for network protocols. The standard system as used outside the labs had only one line discipline configured, with standard tty handling (see usr/sys/conf/c.c). There were driver source files for what I think were internal-use-only networks (dev/pk[12].c, perhaps), but I don't think they were used outside AT&T. The problem Dennis wanted to solve was that tty handling and network protocol handling interfered with one another; you couldn't ask the kernel to do both, because there was only one line discipline at a time. Hence the stackable modules. It was possible to duplicate tty handling (probably by placing calls to the regular tty line discipline's innards) within the network-protocol code, but that was messy. It also ran into trouble when people wanted to use the C shell, which expected its own special `new tty' line discipline, so the network code would have to know which tty driver to call. It made more sense to stack the modules instead, so the tty code was there only if it was needed, and different tty drivers could exist without the network code knowing or caring. When I arrived at the Labs in 1984, the streams code was in use daily by most of us in 1127. The terminals on our desks were plugged into serial ports on Datakit (like what we call a terminal server now). I would turn on my terminal in the morning, tell the prompt which system I wanted to connect to, and so far as I could tell I had a direct serial connection. But in the remote host, my shell talked to an instance of the tty line module, which exchanged data with a Datakit protocol module, which exchanged data with the low-level Datakit driver. If I switched to the C shell (I didn't but some did), csh would pop off the tty module and push on the newtty module, and the network code was none the wiser. Later there was a TCP/IP that used the stream mechanism. The first version was shoehorned in by Robert T Morris, who worked as a summer intern for us; it was later cleaned up considerably by Paul Glick. It's more complicated because of all the multiplexers involved (Ethernet packets split up by protocol number; IP packets divided by their own protocol number; TCP packets into sessions), but it worked. I still use it at home. Its major flaw is that details of the original stream implementation make it messy to handle windows of more than 4096 bytes; there are also some quirks involving data left in the pipe when a connection closes, something Dennis's code doesn't handle well. The much-messier STREAMS that came out of the official System V people had fixes for some of that, but at the cost of quite a bit more complexity; it could probably be done rather better. At one point I wanted to have a go at it, but I've never had the time, and now I doubt I ever will. One demonstration of virtue, though: although Datakit was the workhorse network in Research when I was there (and despite the common bias against virtual circuits it worked pretty well; the major drawback was that although the underlying Datakit fabric could run at multiple megabits per second, we never had a host interface that could reliably run at even a single megabit), we did once arrange to run TCP/IP over a Datakit connection. It was very simple in concept: make a Datakit connection (so the Datakit protocol module is present); push an IP instance onto that stream; and off you go. I did something similar in my home V10 world when quickly writing my own implementation of PPP from the specs many years ago. The core of that code is still in use in my home-written PPPoE code. PPP and PPPoE are all outside the kernel; the user-mode program reads and writes the serial device (PPP) or an Ethernet instance that returns just the desired protocol types (PPPoE), does the PPP processing, and reads and writes IP packets to a (full-duplex stream) pipe on the other end of which is pushed the IP module. All this is very different from the socket(2) way of thinking, and it has its vices, but it also has its virtues. Norman Wilson Toronto ON

7 years, 2 months

Re: [TUHS] Unix of choice these days?

by Doug McIlroy

>> "Bah. That's just some goof-ball research toy." > I feel like the same thing was said about Unix at some point very early in it's history. Amusingly the IT department of AT&T felt that way and commissioned a Harvard prof, no less, to write a report about why VMS was the way to go on Vaxen. The hired gun (so much for academic integrity) addressed the subject almost entirely with meta arguments: (1) VMS was written by OS professionals; Unix was a lab experiment. (2) One could count on support from DEC, not from Research. (So much for USG; as far as i know the author never asked anyone in] Bell Labs about anything.) (3) And the real killer: VMS was clearly far advanced, witness its shelf of manuals vs the thin Unix volumes that fit in one's briefcase. Lee McMahon had particular fun with this one in a rebuttal that unleashed the full power of his Jesuit training in analytic debate. Doug

7 years, 2 months

Another "craft" discussion topic - mindless tool proliferation

by Jon Steinhart

OK, here's another one that's good for chest thumping... I am not a fan of texinfo. It doesn't provide any benefits (to me) over man. I suppose that it was trailblazing in that it broke manual pages up into sections that couldn't easily be viewed concurrently long before the www and web pages that broke things up into multiple pages to make room for more ads. Any benefits that texinfo might have are completely lost by the introduction of multiple non-intersecting ways to find documentation. This is a systemic problem. I have a section in my book-in-progress where I talk about being a "good programming citizen". One of the things that I say is: Often there is a tool that does most of what you need but is lacking some feature or other. Add that feature to the existing tool; don't just write a new one. The problem with writing a new one is that, as a tool user, you end up having to learn a lot of tools that perform essentially the same function. It's a waste of time an energy. A good example is the make utility (invented by Stuart Feldman at Bell Labs in 1976) that is used to build large software packages. As time went on, new features were needed. Some were added to make, but many other incompatible utilities were created that performed similar functions. Don't create burdens for others. Improve existing tools if possible. A funny example of this is when I was consulting for Xilinx in the late 80s on a project that had to run on both Suns and PCs. Naturally, I did the development on a Sun and ported to the PC later. When it came time to do the port, a couple of the employees proudly came to me and told me about this wonderful program that they wrote that was absolutely necessary for doing the PC build. I was completely puzzled and told them that I already had the PC build complete. They told me that that couldn't be possible since I didn't use their wonderful utility. Turns out that their utility wrote out all of the make dependencies for the PC. I, of course, wrote a .c.obj rule which was all that it took. They were excessively angry at me for inadvertently making them look like fools that they were. Another example is a more recent web-based project on which I was advising. I'm a big fan of jQuery; it gets the job done. Someone said "Why are you using that instead of angular?" I did a bit of research before answering. Turns out that one of the main reasons given for angular over jQuery was that "it's fresh". That was a new one for me. Still unclear why freshness is an attribute that would trump stability. So, I'm sure that many of you have stories about unnecessary tools and packages that were created by people unable to RTFM. Would be amused to hear 'em. Jon

7 years, 2 months

An Early Unix Group Meeting (funny story)

by Jon Forrest

I started using Unix in ~1977 at UC Santa Barbara. At some point around then we decided to host a Unix users meeting in the U-Cen student union building. We asked the facilities people to prepare a sign pointing to the meeting room. Imagine my reaction when I walked into the building and saw the following sign: "Eunuchs Group Meeting - Room 125" I don't know if any eunuchs actually showed up. Jon Forrest

7 years, 2 months

Re: [TUHS] PDP-10 UNIX?

by Nelson H. F. Beebe

Warner Losh <imp(a)bsdimp.com> kindly corrected my statement that kcc compiler on the PDP-10 was done by Ken Harrenstien, pointing out that it was actually begun by Kok Chen (whence, the name kcc). I've just dug into the source tree for the compiler, and found this leading paragraph in kcc5.vmshelp (filesystem date of 3-Sep-1988) that provides proper credits: >> ... >> KCC is a compiler for the C language on the PDP-10. It was >> originally begun by Kok Chen of Stanford University around 1981 (hence >> the name "KCC"), improved by a number of people at Stanford and Columbia >> (primarily David Eppstein, KRONJ), and then adopted by Ken Harrenstien >> and Ian Macky of SRI International as the starting point for what is now >> a complete and supported implementation of C. KCC implements C as >> described by the following references: >> >> H&S: Harbison and Steele, "C: A Reference Manual", >> HS1: (1st edition) Prentice-Hall, 1984, ISBN 0-13-110008-4 >> HS2: (2nd edition) Prentice-Hall, 1987, ISBN 0-13-109802-0 >> K&R: Kernighan and Ritchie, "The C Programming Language", >> Prentice-Hall, 1978, ISBN 0-13-110163-3 >> >> Currently KCC is only supported for TOPS-20, although there is >> no reason it cannot be used for other PDP-10 systems or processors. >> The remaining discussion assumes you are on a TOPS-20 system. >> ... I met Ken only once, in his office at SRI, but back in our TOPS-20 days, we had several e-mail contacts. ---------------------------------------- P.S. In these days of multi-million line compilers, it is interesting to inspect the kcc source code line count: % find . -name '*.[ch]' | xargs cat | wc -l 80298 A similar check on a 10-Oct-2016 snapshot of the actively-maintained pcc compiler for Unix systems found 155896 lines. ------------------------------------------------------------------------------- - 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, 2 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 September 2017