TUHS September 2017

tuhs@tuhs.org

97 participants
84 discussions

by Warren Toomey

All, I just had this question popped into my inbox. Cheers, Warren ----- Forwarded message from Evan Koblentz <evan(a)snarc.net> ----- Hi Warren. Evan K. here from Vintage Computer Festival, etc. I'm trying to find out who invented the Chroot command in Version 7 Unix. Could you help, possibly including a post to TUHS email list on my behalf? I posted to our local (northeast US) list and also emailed Brian Kernighan and Bill Cheswick. Hoping this leads to an answer. I'm looking for a name, not just generalities. Thanks very much. ----- End forwarded message -----

7 years, 7 months

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

by norman＠oclsc.org

Random832: Just out of curiosity, where does perror(filename), quite possibly the *most* common error message on Unix as a whole, fall on your scale? It says which of the file location or permissions (or whatever else) it is, but not whether it was attempting to open it for reading or writing. ===== I never liked perror much. It's a little too primitive: you get exactly one non-formatted string; you get only stderr, so if you're sending messages separately to a log or writing them to a network connection or the like, you're out of luck. strerror(errno) hits the sweet spot for me. Until it appeared in the standard library (and until said standard spread enough that one could reasonably expect to find it anywhere) I kept writing more or less that function into program after program. I guess the problem with perror is that it isn't sufficiently UNIX-like: it bundles three jobs that are really separate (convert errno to string message, format an error message, output the message) into one function, inseparably and inflexibly. Norman Wilson Toronto ON

7 years, 7 months

B Source Code

by Robert Swierczek

Does anyone know of the existence of source code written in B (C's predecessor?) I have encountered a few snippets here and there, but nothing substantial. The only "real" program that I know of is AberMUD-1. It looks like there exists a physical print-out of it: https://dropsafe.crypticide.com/article/12714 Could it be that this is the only artifact left of this most important "missing link" of C and Unix History? How can this (and any other B source) be gathered and preserved?

7 years, 7 months

Re: [TUHS] Weird nix? Regulus

by Derek Fawcus

> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. Funny, I was just poking through some ccpm68k source/tools, which happened to contain the Alcyon C compiler source, and one of the files is: $ cat v103/doc/files/Sectioname .fo 'REGULUS Reference Manual'- % -'FILES' $ The same system? DF

7 years, 7 months

PDP-10 UNIX?

by Arthur Krewat

Was there ever a UNIX or even the thought of porting one to a PDP-10? 36-bit machine, 18-bit addresses (more on KL10 and KS10), and: *0 would return register 0 instead of a SIGSEGV ;) 8-bit bytes would have been a wasteful exercise, but you never know. (losing 4 bits of every 36-bit word) thanks! art k.

7 years, 7 months

Re: [TUHS] PDP-10 UNIX?

by jnc＠mercury.lcs.mit.edu

> That makes sense if it's '73. That would be the Ritchie front end and > v5/v6 syntax as I remember=20 Here: http://publications.csail.mit.edu/lcs/specpub.php?id=717 is the TR describing it (well, this report covers one by him for the Honeywell 6000 series, but IIRC it's the same compiler). I didn't read the whole thing slowly, but glancing quickly at it, it sounds like it's possible a 'from scratch' thing? Noel

7 years, 7 months

Re: [TUHS] B Source Code

by jnc＠mercury.lcs.mit.edu

> From: Alec Muffett > "threaded code" in the old sense could be smaller than the equivalent > CISC binary on the same machine One can think of 'threaded code' as code for a new virtual machine, one specialized to the task at hand. > https://en.m.wikipedia.org/wiki/Threaded_code For those who really want to delve in some depth, see the chapter "Turning Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC View of Hardware Systems Design", by Bell, Mudge and McNamara. Interesting factoid: The PDP-11 initially used a threaded FORTRAN implementation. In line with the observation above (about a new virtual machine), DEC actually looked into writing microcode for the -11/60 (which had a writeable control store) to implement the FORTRAN virtual machine. Noel

7 years, 7 months

Re: [TUHS] PDP-10 UNIX?

by Johnny Billquist

On 2017-09-17 18:33, Arthur Krewat <krewat(a)kilonet.net> wrote: > Was there ever a UNIX or even the thought of porting one to a PDP-10? Definitely a thought. An attempt was started on NetBSD for the PDP-10, and it sortof got halfway of getting into single-user, but I'm not sure if the person who worked on it just got distracted, or if he hit problems that were really hard to solve. I certainly know the person, and can find out more if people really are interested. > 36-bit machine, 18-bit addresses (more on KL10 and KS10), and: > > *0 would return register 0 instead of a SIGSEGV ;) Yes. Not the first machine that would be true for. You don't have address 0 unmapped on a PDP-11 either. > 8-bit bytes would have been a wasteful exercise, but you never know. > (losing 4 bits of every 36-bit word) Uh... Why 8 bit bytes? That way lies madness. There exists a really good C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like a charm, except when some people write portable code that is not so portable. ;-) KCC was written by KLH, unless I remember wrong. Same guy who also wrote the KLH-10 emulator. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 7 months

Weird nix? Regulus

by David

What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. The APIs were ever so slightly different because the authors were concerned about copyright infringement. libc calls had different argument orders or types and in general it was just off enough that you wanted to claw at the screen every time something went wrong. To top it off, the system we were hosting it on was so slow that a full rebuild of our meager (10k lines) software took overnight. I eventually ported all the software to a SparcStation-2 cross compiling to the 68k target we were embedded on. > To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could be the hardware e.g NULL was not zero, NUXI byte ordering etc. > > Cheers, Warren

7 years, 7 months

Re: [TUHS] really Pottering vs UNIX

by Clem Cole

On Thu, Sep 14, 2017 at 4:09 PM, Jon Steinhart <jon(a)fourwinds.com> wrote: > > Well, I'd suggest that a lot of this has to do with people who have vision > and people who don't. When you look at UNIX, you see something created by > a bunch of very talented people who had a reasonably shared vision of what > they were trying to achieve. > Jon - I mostly agree, but would twist it a little differently (hey, we've been arguing since the 1970s, so why stop now). I think you are actually touching on an idea that has been around humanity for a long time that is independent of the computer field. We call it "good taste." Part of acquiring good taste is learning what is in bad taste, a heavy dose of experience and frankly the ability to evaluate your own flaws. What I always love about Dennis, Ken, Doug, Steve and the rest if the team is their willingness to accept the shortcomings and compromises that were made as the developed UNIX as a system. I never saw them trying to claim perfection or completeness, much less and end state had been reached. Always looking for something better, more interesting. And always, standing on the shoulders of others... What I really dislike about much of the crowd that has been discussed is that they often seem more contented to kick people in the shins that standing on their shoulders. I used to say, when we were hiring people for some of my start-ups, what we wanted was experienced folks that had demonstrated good taste. Those are people you can trust; and will get you pretty close to where you want to be. In fact, to pick on one of my previous employers, I have always said, what DEC got wrong, was it was always striving to be perfect. And lots of things never shipped, or when they did (like Alpha) it was wonderful, but it did not matter. The opportunity window had passed. Part of "good taste" is getting the job done and on time. Being "good enough" and moving on to the next thing. Sun (certainly at the beginning) was pretty good at this idea. The UNIX team clearly got a lot of it right. It is easy to throw stones at others. It is hard to repeatedly get so much right for so long and UNIX has and did. Clem

7 years, 7 months

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

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