TUHS

tuhs@tuhs.org

6532 discussions

by Dan Cross

[TUHS as Bcc] I just saw sad news from Bertrand Meyer. Apparently, Niklaus Wirth passed away on the 1st. :-( I think it's fair to say that it is nearly impossible to overstate his influence on modern programming. - Dan C.

1 year, 6 months

Re: Question about BSD disklabel history

by norman＠oclsc.org

Disk sections (I don't think anyone in Research called them partitions--certainly the Research manuals didn't) were originally defined in the device driver, not by data on the disk. In those days, system management included recompiling stuff, including the OS kernel, and it was not unusual for sites to edit hp.c or whatnot to adjust things to local preference. There was nothing magic about the mapping between device names and minor device numbers either; the system came with certain conventions on the original tape, but it was not at all uncommon to change them. By the time I arrived at the first Unix site I ever helped run, in a physics group at Caltech, we already used a different naming convention: a BSD-like ddNs, where dd was a driver name, N the physical drive unit number, s a section letter. I don't know whether that was borrowed from BSD (it must have started during the 3BSD era, since I started there in mid-1980 and 4BSD appears to have been released late in that year). Looking at my archival copy of that much-locally-hacked source tree, I see that we later moved the definitions of all the disk-section tables to a single file compiled at system-configuration time (we used a USG-like scheme that compiled most of the system into libraries, rather than compiling every file separately for each target system a la V7 and BSD). That simplified handling our somewhat- complicated disk topology: all but system disks were connected through System Industries 9400 disk controllers, which were a neat design (each controller could interface to as many as four hosts and four disks) but in practice were not always reliable. On one hand, we arranged for one disk to be used in parts by our main time-sharing VAX and a subsidiary PDP-11/45, making the 11/45 cheaper to keep around; on the other, the main VAX had two paths to each of its disks, through different SI controllers, so when an SI controller conked out we could run without it until the service guys fixed it. (Each disk was dual-ported, as was common in the SMD world, hence connected to two controllers.) Reliability took rather more work in those days. A different data point: by the time I moved from California to New Jersey and joined 1127, Research was also using a different naming scheme for disk sections. By then the internal naming convention was e.g. ra17 for physical unit 1, section 7; by further convention 7 (the highest-numbered section). At some point a little later we added an ioctl to set the starting block and size of a particular section on a particular drive, but we never went to having the OS itself try to find a label and trust its contents (something that still makes the 1980s part of me feel a little creepy, though 21st century me has come to terms with it). Norman Wilson Certified old fart Toronto ON

1 year, 6 months

Early 70's WECo "Turnkey Systems"? Re: S.S. Pirzada UNIX Paper

by segaloco

In S.S. Pirzada's 1988 paper[1], page 35, section 3.3.2, he writes: "Some operating telephone companies and the switching control center system (SCCS) group in Holmdel, NJ decided to use UNIX to collect maintenance data from their switches and for administration purposes. Other departments also started building applications on top of UNIX, some part of turnkey systems licensed by Western Electric (WECo)." This is describing the situation before the establishment of USG in September 1973. I'm curious, does anyone recall what some of these pre-USG WECo "turnkey systems" were? The things that come to mind when I think of that phrase don't come about for several years, such as the 5ESS and other work surrounding Bellmac stuff. The SCCS UNIX connection describes what becomes CB-UNIX if I understand the situation correctly, but that stays a bit afield from the more conventional pool that is dipped into for WECo needs. Switching and UNIX all kinda come back together with DMERT on 1A/3B-API and 5ESS, but again that's late 70s R&D, early 80s deployment, not this time period, leaving me terribly curious what WECo would've been bundling UNIX with and shipping out to telcos. The famous early use of UNIX in the Bell System is typography, and WECo did have involvement with Teletype equipment, so perhaps something along those lines? If it helps set the scene, a binder I recently picked up from ~1972 describing Western Electric test sets distributed to telcos describes the following additional classes of such documents: Shop Services - Special non-standard products Public Telephones - System standard public telephone equipment Data Communications - Teletypewriter and Data Sets Subscriber Products - System standard PBX's, station equipment and special services Non-Subscriber Products - Microwave, cable, power equipment, etc. Non-Bell Equipment Index - Non-Bell System manufactured communication equipment Unfortunately haven't seen any of the other binders yet but I've been keeping an eye out, one or another might describe something WECo was shipping around that had some UNIX up in it. Nothing in this binder seems computer-y enough to run an operating system, just lots of gauges, dials, and probes. Luckily it is quite clear what data test sets are designed for 103-data set maintenance so I have fodder for seeking Dataphone tools... Anywho, happy soon to be new year folks, I'm excited to see what turns up next year! - Matt G. [1] - https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pi…

1 year, 6 months

Trying to compile cron

by KenUnix

Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 and am apparently missing required libraries. The reason is on the 3b2-400 after boot up it complains there is corruption in the crontab for every user lp, sysadm, root and so on. # make cron cc -O cron.c -o cron undefined first referenced symbol in file el_add cron.o el_delete cron.o el_empty cron.o el_first cron.o el_init cron.o xmalloc cron.o el_remove cron.o num cron.o days_in_mon cron.o days_btwn cron.o ld fatal: Symbol referencing errors. No output written to cron *** Error code 13 Stop. Does anyone have these libraries? Thanks. -- WWL 📚

1 year, 6 months

Re: Trying to compile cron

by Brian Walden

As I messed with making a custom cron in the late 80s, remembered the the el_ functions are for event list processing. But you didn't specify the source of your source, by the hardware it needs to be of System V heritage. And a lot of that source is hard to offically come by due to licensing. Good way to view old SVR4 is to look at OpenIndiana, Illumos, or OpenSolaris code bases that you can find. You're in luck, as TUHS has a copy, see -- https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/cron/elm.c Look at the Makefile for the other files you need to compile into it too. -Brian KenUnix wrote: > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > and am apparently missing required libraries. The reason is > on the 3b2-400 after boot up it complains there is corruption > in the crontab for every user lp, sysadm, root and so on. > > # make cron > cc -O cron.c -o cron > undefined first referenced > symbol in file > el_add cron.o > el_delete cron.o > el_empty cron.o > el_first cron.o > el_init cron.o > xmalloc cron.o > el_remove cron.o > num cron.o > days_in_mon cron.o > days_btwn cron.o > ld fatal: Symbol referencing errors. No output written to cron > *** Error code 13 > > Stop.

1 year, 6 months

Historic "Communications Etiquette" Practices?

by segaloco

Good time of day folks, I often ponder on people's attachments to pixels on the screen that come about by clicking *this* icon and typing in a box surrounded by blue and with an icon in position <xyz> vs pixels on the screen that come about instead by opening that application that is a black border with a little paper airplane button in the bottom right vs....etc. To make it more clear, I find myself often confused at people treating email different from SMS different from social media DMs different from forum posts different from some other mechanism that like literally all the others is pixels arranged into glyphs on a screen conveying an approximation of human speech. This difference among these different ways to send said pixels to people has eluded me all my life despite working with technology since I was a tot. What this has me curious on is if in the early days of UNIX there were attempts at suggesting which provided communication mechanisms were appropriate for what. For instance something that smells of: It is appropriate to use mail(1) to send a review of a piece of work vs it is appropriate to use write(1) to ask Jim if he wants to take a lunch break before the big meeting. Did this matter to people back then like it seems to now? To me it's just pixels on a screen that are there when I look at them and aren't when I don't. Truth be told I am hoping to learn something from this because I only do a couple email lists and web forums, my social life generally does not involve SMS, phone calls, nor social media. Where it has become tedious is someone I meet who seems to want to communicate over pixels on screens is then put off when I provide them an email address, usually asking instead if I have a Facebook or whatever the kids are calling Twitters today. The few times I've tried to explain email will be me transmitting you communication as pixel glyphs on a screen just like anything else would be me transmitting you communication as pixel glyphs on the screen, this doesn't diffuse their concerns any, they then just think there is something wrong with me for comparing words as pixels on a screen to words as pixels on a screen. Granted, I've probably avoided plenty of vapid people this way, but it feels like it's becoming more and more expected that "these pixels on the screen in *this* program are only for this and those pixels on the screen in *that* program are only for that". Is this a recent phenomenon? Has communication over electronic means always had these arbitrary limitations hoisted on it by the humans that use it? Or did people not give a hoot what you sent over what program and actually cared more about the words you're saying than the word you typed at a terminal to then be able to transmit words? I doubt what I learn is going to royally change my approach to allowing technology in my irl social life, but it would be nice to at least have more mental ammo when someone asks to be friends online and then gives me mad sideeye when I go "sure here's my email address!" - Matt G.

1 year, 6 months

DMD 5620 mouse available

by arnold＠skeeve.com

... at a rather high price: https://www.ebay.com/itm/265518759380?hash=item3dd226bdd4:g:8gUAAOSwW21h8N7… :-) Arnold

1 year, 6 months

PDP-7 and Interdata 8/32 Bell System UNIX Installations?

by segaloco

Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point? My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX. Thanks for any info! - Matt G.

1 year, 6 months

Off topic: BSD timezone function vs. POSIX timezone variable

by Aharon Robbins

Hi All. This is a bit off-topic, but people here are likely to know the answer. V7 had a timzone function: char *timezone(int zone, int dst); that returned a timezone name. POSIX has a timezone variable which is the offset in seconds from UTC. The man pages for all of {Net,Free,Open}BSD seem to indicate that both are available on those systems. My question is, how? The declarations for both are given as being in <time.h>. But don't the symbols in libc.a conflict with each other? How does a programmer on *BSD choose which version of timezone they will get? Feel free to reply privately. Thanks, Arnold

1 year, 6 months

Loud machines (was Compatibility Question)

by Douglas McIlroy

> Paul -- you left out the other "feature" -- the noise, which was still deafening even with a model N1 and its cover. It was indeed loud, but GE out-roared them with a blindingly fast card reader. The machine had a supposedly gentle touch; it grabbed cards with vacuum rather than tongs. But the make-and-break pneumatic explosions sounded like a machine gun. A noise meter I borrowed from the Labs' tool crib read 90db 6 feet away. Doug

1 year, 6 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