TUHS

tuhs@tuhs.org

5 participants
6532 discussions

Re: UNIX System V Release 2.2 gdts Vax-780

by jnc＠mercury.lcs.mit.edu

> From: Ken Unix > I have mknod but need the (c,b) major/minor numbers for /dev/lp It looks like SysV still has conf.c; you're looking for 'cdevsw'. Noel

2 years, 3 months

Re: [TUHS]: C dialects

by Douglas McIlroy

> In hindsight Algol68 may have been the last committee designed > language that was good. The committee itself fractured over the design. Dissenters who thought it was far too complex upped stakes and formed WG2.3, which pointedly concentrated on program design, not language. Doug

2 years, 3 months

UNIX System V Release 2.2 gdts Vax-780

by KenUnix

Hi. I am trying to figure out how to create a device /dev for lp. I have mknod but need the (c,b) major/minor numbers for /dev/lp /etc/mknod name c | b major minor I do have the required software to run lp. I have read through the docs I have but no luck. Thanks Ken -- WWL 📚

2 years, 3 months

Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > In C I use it all the time to do goto err for common error recovery > because C doesn't have anything better. That's because C doesn't have 'conditions'. (Apparently, from the following posts, most people here are unfamiliar with them. Too bad, they are a great idea. OK summary here: http://gunkies.org/wiki/Condition_handler for those who are unfamiliar with the idea.) I was at one point writing a compiler using a recursive descent parser, and decided the code would be a lot simpler/cleaner if I had them. (If, for example, one discovers discovers an un-expected 'end of file', there can be an extremely large number of procedure invocations in between where that is discovered, and where it is desirable to handle it. So every possible intervening procedure would have to have an 'unexpected EOF' return value, one would have to write code in every possible intervening procedure to _handle_ an 'unexpected EOF' return value, etc.)' (Yes, I could have used setjmp/longjmp; those are effectively a limited version of condition handlers.) Since C has a stack, it was relatively easy to implement, without any compiler support: on() became a macro for 'if _on("condition_name")'; _on() was a partially-assembler procedure which i) stacked the handler (I forget where I put it; I may have created a special 'condition stack', to avoid too many changes to the main C stack), and ii) patched the calling procedure's return point to jump to some code that unstacked the handler, and iii) returned 'false'. If the condition occurred, a return from _on() was simulated, returning 'true', etc. So the code had things like: on ("unexpected EOF") { code to deal with it } With no compiler support, it added a tiny bit of overhead (stacking/unstacking conditions), but not too bad. John Wroclawski and someone implemented a very similar thing entirely in C; IIRC it was built on top of setjmp/longjmp. I don't recall how it dealt with un-stacking handlers on exit (which mine did silently). Noel

2 years, 3 months

I can't drive 55: "GOTO considered harmful" 55th anniversary

by Steffen Nurpmeso

I wonder if Pink Floyd's Summer68 maybe refers to this. Other than that i am addicted and could not live without it. The other (terrible) song is from 1984 (east southern US). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

2 years, 3 months

5ESS Operating Systems Today?

by segaloco

Starting this in TUHS due to UNIX relevance, but with the heavy disclaimer this should quickly diverge to COFF if it drifts into foreign waters. I've gotten to reading about 5ESS lately, and it seems there are many in use still today. I found myself wondering what the evolution has looked like as far as computing hardware and operating systems involved. DMERT ran on the 3B-20D supporting the 5ESS systems in the early 80s, at the same time that UNIX 4.x was making rounds on the 3B-20S. A 5ESS manual from 2001[1] mentions UNIX RTR (Real-Time Reliable) of the DMERT lineage. Wikipedia[2] suggests 5ESS is still very much in use and mentions more modern systems like VCDX; its "Sun Microsystems SPARC workstation runs the UNIX-based Solaris (operating system) that executes a 3B20/21D processor MERT OS emulation system." This sounds like the Lucent 3B20 emulator. Is there still a line of UNIX RTR/DMERT being maintained to this day? Or are users left with other avenues to keep their hardware updated if necessary? [1] - https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/235600510_V1_5… [2] - https://en.wikipedia.org/wiki/5ESS_Switching_System - Matt G.

2 years, 3 months

Re: virtual consoles / Alt-Fx

by Rudi Blom

On SCO UNIX 3.2V4 you indeed have local virtual consoles moving from one to another using the function keys. Worked from F1 to F12, but how often you could login would depend on your license. Of course all still character based, and depending on your TERM setting. -- The more I learn the better I understand I know nothing.

2 years, 3 months

Unix 2.0v2 Vax-780 IP address access

by KenUnix

Hi! I have an updated Unix 2.0v2 package running under the current Vax-780 sim. It has been tuned up with missing packages and some new ones. Like automatic startup with date/time setting, running fsck at boot and properly shutting down ALL processes at shutdown allowing for a "clean" shutdown thereby avoiding fsck issues at the next boot. Also there is a virtual tape so you can do backups.. My question is can THIS version access an IP address? And if so, how. If there is any interest I could package it up into a tar file for others. Thanks, Ken -- WWL 📚

2 years, 3 months

PWB 1.0 Distro and Licensing Timeframe

by segaloco

Hello folks, posing a question here that will help with some timelining. So System III, according to everything I've read, was commercially issued in 1982. However, PWB 3.0 was issued internally in 1980, two years prior. This isn't that surprising, give USL some time to work it up for commercial-readiness. Where I'm curious is if there was a similar gap for the public release of PWB, given that was earlier on and pre-support and such. Was there a particular "public release" date for PWB 1.0 or would it have just been whenever folks started getting tapes out of Bell? I know it shows up in a price sheet floating around from say 1983 or 1984 among the likes of V7, 32V, System III, and System V also for sale, but would anything that early have had a formal "ship date" indicating a day they cut the master to copy tapes from or was it more of a contact Bell, someone will cut you a tape of whatever we've got right now? Also, was PWB held as something that would be "marketable" from the get-go, or was it more of a happy accident that it wound up in the right place in the right time to become the commercial line? One would think USG Generic would be the one they'd shoot for being the "base" to build on, but everything I'm finding in my study of System III lately is pointing to a much more PWB-ish lineage with random borrowings from CB, PY, HO, IH, among others. - Matt G.

2 years, 3 months

converting C/A/T to postscript

by arnold＠skeeve.com

There was such a tool, psroff (same name as, but no shared code with the Adobe version) that read either C/A/T or ditroff output and produced postcript. It was in volume 24 of comp.sources.unix. There were also multiple patches to it. It dates from 1991. segaloco, you were looking for this? Contact me privately if you can't find it. Arnold

2 years, 3 months

Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

by jnc＠mercury.lcs.mit.edu

> From: "Ronald Natalie" > Multilevel breaks are as bad as goto with regard to structure violation. In a way, you are right. There isn't really much difference between: for (mumble) { for (foobar) { do some stuff break-2; } } and: for (mumble) { for (foobar) { do some stuff goto all_loops_done; } } all_loops_done: The former is basically just 'syntactic sugar' for the latter. I think the point is that goto's aren't necessarily _always_ bad, in and of themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's in a _structured_ way (oxymoronic as that sounds), to get around things that are lacking in the language's flow-control, they're probably fine. Then, of course, one gets into the usual shrubbery of 'but suppose someone uses them in a way that's _not_ structured?' There's no fixing stupid, is my response. Nested 'if/then/else' can be used to write comletely incomprehensible code (I have an amusing story about that) - but that's not an argument against nested 'if/then/else'. As I've said before, the best sculpting tools in the world won't make a great sculptor out of a ham-handed bozo. Noel

2 years, 3 months

Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > for breaking out of multiple levels of while/for loops. Yeah, multi-level 'breaks' were one of the things I really missed in C. The other was BCPL's 'VALOF/RESULTIS'. Back before C compilers got good enough to do inline substitutions of small procedures (making macros with arguments less useful), it would have been nice to have, for macros that wanted to return something. Instead, one had to stand on one's head and use a '(cond ? ret1 : ret2 )' of some form. Noel

2 years, 3 months

Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

by jnc＠mercury.lcs.mit.edu

> From: Ralph Corderoy > if you say above that most people are unfamiliar with them due to their > use of goto then that's probably wrong I didn't say that. I was just astonished that in a long thread about handling exceptional conditions, nobody had mentioned . . . exceptions. Clearly, either unfamiliarity (perhaps because not many laguages provide them - as you point out, Go does not), or not top of mind. Noel

2 years, 3 months

simh running System V add serial (telnet) lines

by KenUnix

I have successfully got System V running on a PDP11 sim. I have been trying to add serial lines like on Version 7 but have had no success. What would be necessary under System V on a sim to do so. I have already tried the SIMH group but no working answers. If direct telnet is a better way please let me know. Thanks Ken -- WWL 📚

2 years, 3 months

scaling on TCP socket connections

by ron minnich

Ca. 1981, if memory serves, having even small numbers of TCP connections was not common. I was told at some point that Sun used UDP for NFS for that reason. It was a reasonably big deal when we started to move to TCP for NFS ca 1990 (my memory of the date -- I know I did it on my own for SunOS as an experiment when I worked at the SRC -- it seemed to come into general use about that time). What kind of numbers for TCP connections would be reasonable in 1980, 90, 2000, 2010? I sort of think I know, but I sort of think I'm probably wrong.

2 years, 3 months

Fifth Edition Manual Restoration

by segaloco

So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: https://gitlab.com/segaloco/v5man There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. - Matt G.

2 years, 3 months

Re: scaling on TCP socket connections

by Paul Ruizendaal

From reading a lot of papers on the origins of TCP I can confirm that people appear to have been thinking in terms of a dozen connections per machine, maybe half that on 16-bit hardware, around 1980. Maybe their expectations for PDP-10’s were higher, I have not looked into that much. > From: Tom Lyon <pugs78(a)gmail.com> > Sun chose UDP for NFS at a point when few if any people believed TCP could > go fast. > I remember (early 80s) being told that one couldn't use TCP/IP in LANs > because they were WAN protocols. In the late 80s, WAN people were saying > you couldn't use TCP/IP because they were LAN protocols. I’m not disputing the above, but there was a lot of focus on making TCP go fast enough for LAN usage in 1981-1984. For example see this 1981 post by Fabry/Joy in the TCP-IP mailing list: https://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6… There are a few other similar messages to the list from around that time. An early issue was check-summing, with that initially taking 25% of CPU on a VAX750 when TCP was heavily used. Also ideas like having "trailing headers" (so that the data was block aligned) were driven by a search for LAN performance. Timeouts were reduced from 5s and 2s to 0.5s and 0.2s. Using a software interrupt instead of a kernel thread was another thing that made the stack more performant. It always seemed to me that the BBN-CSRG controversy over TCP code spurred both teams ahead with BBN more focussed on WAN use cases and CSRG more on LAN use cases. I would argue that no other contemporary network stack had this dual optimisation, with the possible exception of Datakit.

2 years, 3 months

Unix System V date command update

by KenUnix

Guys, Find attached an updated date.c for Y2K for System V IE: date 0309182123 Also works: # date +%D 03/09/23 # date +%y%m%d%H%M 2303091823 Interesting Version 7 wants: date 2303091821 Ken -- WWL 📚

2 years, 3 months

Re: Origins of the frame buffer device

by jnc＠mercury.lcs.mit.edu

> From: Kenneth Goodwin > The first frame buffers from Evans and Sutherland were at University of > Utah, DOD SITES and NYIT CGL as I recall. > Circa 1974 to 1978. Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to PDP-10's; '74-'78 sounds like an interim period.) Noel

2 years, 3 months

'Huge' file support removed from PWB1

by jnc＠mercury.lcs.mit.edu

In PWB1, support for 'huge' files appears to have been removed. If one compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double indirect block" code is gone. I guess PWB didn't need very large (> 8*256*512 = 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it were, though - unless PWB was generating lots of files of between 7*256*512 and 8*256*512 bytes in length, and they wanted to avoid the overhead of the double-indirect block? (The savings in code space are derisory - unlike in LSX/MINI-UNIX.) Anyone know? Noel

2 years, 3 months

Origins of the frame buffer device

by Paul Ruizendaal

I am confused on the history of the frame buffer device. On Linux, it seems that /dev/fbdev originated in 1999 from work done by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bellard?). However, it would seem at first glance that early SunOS also had a frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature (a character device that could be mmap’ed to give access to the hardware frame buffer, and ioctl’s to probe and configure the hardware). Is that correct, or were these entirely different in nature? Paul

2 years, 3 months

the wheel of reincarnation goes sideways

by ron minnich

The wheel of reincarnation discussion got me to thinking: What I'm seeing is reversing the rotation of the wheel of reincarnation. Instead of pulling the task (e.g. graphics) from a special purpose device back into the general purpose domain, the general purpose computing domain is pushed into the special purpose device. I first saw this almost 10 years ago with a WLAN modem chip that ran linux on its 4 core cpu, all of it in a tiny package. It was faster, better, and cheaper than its traditional embedded predecessor -- because the software stack was less dedicated and single-company-created. Take Linux, add some stuff, voila! WLAN modem. Now I'm seeing it in peripheral devices that have, not one, but several independent SoCs, all running Linux, on one card. There's even been a recent remote code exploit on, ... an LCD panel. Any of these little devices, with the better part of a 1G flash and a large part of 1G DRAM, dwarfs anything Unix ever ran on. And there are more and more of them, all over the little PCB in a laptop. The evolution of platforms like laptops to becoming full distributed systems continues. The wheel of reincarnation spins counter clockwise -- or sideways? I'm no longer sure the whole idea of the wheel or reincarnation is even applicable.

2 years, 3 months

Re: Origins of the frame buffer device

by norman＠oclsc.org

Rob Pike: As observed by many others, there is far more grunt today in the graphics card than the CPU, which in Sutherland's timeline would mean it was time to push that power back to the CPU. But no. ==== Indeed. Instead we are evolving ways to use graphics cards to do general-purpose computation, and assembling systems that have many graphics cards not to do graphics but to crunch numbers. My current responsibilities include running a small stable of those, because certain computer-science courses consider it important that students learn to use them. I sometimes wonder when someone will think of adding secondary storage and memory management and network interfaces to GPUs, and push to run Windows on them. Norman Wilson Toronto ON

2 years, 3 months

An odd disclaimer on the Lions Commentary

by Warner Losh

Recently, I stumbled upon a photo of the Lions Commentary that didn't have a bell disclaimer, but a Wollongong Group disclaimer on it. Not Wollongong University, but The Wollongong Group (a company I coincidentally used to work for). I wish I'd saved the images, because now I can't find it. Has anybody else seen this? Warner

2 years, 3 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

> I'll turn this into a 'Fixing damaged V5/V6 file systems' article on > the CHWiki. Here'a a first crack at it: https://gunkies.org/wiki/Repairing_early_UNIX_file_systems Any suggestions for improvements/additions will be gratefully received! I've also been amusing myself trying to figure out who wrote: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c and how it got to MIT - which might give us a clue as to who wrote it. (It's clearly a distant ancestor to 'fsck'.) The fact that we've lost Ted Kowalski is really hindering, alas. Interestingly, Dale DeJager, head of the CB-UNIX group, earlier remembered Hal Pierson working on a file system checker early on: "Hal also implemented the first file system check routine that was written in C. It replaced an .. assembler version from research" but it's not clear if the thing Hal wrote, mentioned there, has any relationship with the 'check' of V5: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/check.c Maybe one of the Labs old-timers here remembers where the V5 thing came from? (I.e. did Ken or Dennis write it, or did it come from Columbus?) If you do, it would be a big help! Noel

2 years, 3 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