TUHS

tuhs@tuhs.org

6515 discussions

by Dave Horsfall

Tommy Flowers MBE was born on this day in 1905; an electrical and mechanical engineer, he designed Colossus, arguably the world's first electronic computer, which was used to break the German "Lorenz" high-level cipher (not Enigma, as some think). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

Various Unix

by Jose R. Valverde

Before we had to phase out our FTP server, I kept on it several versions of UNIX clones and related OS that were mostly not on TUHS. This post is to remember some of these systems. Many of these were open sourced or widely available at some time and were related to UNIX one way or another. I may not have the latest versions or all the versions, but at least I do keep something. The following ones have been open sourced at some point in time (I believe): ChorusOS Coherent EXOS L4 Lunix MaRTE-OS Mach OpenBLT OpenSolaris Sprite (I also own the original distribution CD) Trix UniFlex agnix amoeba bkunix bsd386 hurd iunix jaluna-c5 lsx-unix mini-unix minix omu opensolaris starunix thix from tliquest.net/local/unix: uzi and various other bits tme tropix tunix unix-v8 unix-wega uzi xhomer xinu xv6 yoctix Plus several archaic CDs with early versions of Linux, Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs) and even the Beowulf/Extreme Linux CDs (plus I must keep around the mirror we hosted for a long time of the Beowulf site). The hobbyist CDs for OpenSolaris 8 (and I believe 9) with sources. Oh, and MOSIX/OPENMOSIX. In addition, I have many other sources whose Copyright status I'm not aware of, but which are interesting for archival purposes. Regarding QNX, yes, it was open sourced (at least for hobbyist use, I have to check the license) for several distributions. I ported some bioinformatics software and kept for some time a distribution repository, and I'm pretty certain I must have the sources as well as the virtual machines. I'll try to verify the licenses to see if it can be redistributed, although I doubt they can. Oh, and I also own the mentioned famous 3.5" diskette. I think I digitized it long ago. Would have to check. Off the Net, it has been possible, one time or another, to recover executables and, sometime, even sources, of many systems. Archive.org has -I believe- a copy of a once famous repo of abandonware with binaries of SCO, System V, AIX, etc... I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64, OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at some time or another in source code format, and binaries of IRIX, Lisa, QNX, A/UX, xenix... Some years ago, I had more free time and could test many systems on emulators, and built images and accompanying scripts ready ti run. I also made some tools to be able to transfer data in and out of old unix versions (so I could edit the software off the virtual machine while back-porting a screen editor to V6, v5, etc... with only vt100 support). Not UNIX-related, I also keep copies of many other ancient operating systems and software and hardware emulators. Well, as I said at the beginning, everything that I had, I should still keep while the hard disks continue spinning. If there is any interest in adding any of these to TUHS, I can try to find a way to send it all. If I find time to browse through everything, I would like to upload all the source code to GitHub (at least anything that's redistributable). If I find the time... But, Warren, if you are interested in anything, let me know and I'll find a way to give you access. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es

7 years, 5 months

pre-UNIX legacy in UNIX?

by Nigel Williams

I blundered today into the GECOS field in /etc/passwd: https://en.wikipedia.org/wiki/Gecos_field "Some early Unix systems at Bell Labs used GECOS machines for print spooling and various other services,[3] so this field was added to carry information on a user's GECOS identity." I had forgotten about this field and I don't recall it being previously described as related to GECOS (I likely didn't take note at the time I first encountered it). Aside from the influence of Multics and other things on UNIX design are there other tangible[1] manifestations of non-UNIX operating system things like the GECOS field that were carried forward intact in later UNIX implementations? [1] things can be pointed at, rather than design ideas

7 years, 5 months

Re: [TUHS] pre-UNIX legacy in UNIX?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > In fact, I don't recall being aware of the existence of the ITS > movement at the time Unix arose. For background, here are a few selected timeline items: ?/1967 ITS design starts 7/67 ITS first becomes operational 12/67 Multics single process boot on 645 10/68 Initial Multics milestone (8 users) 01/69 Limited Initial Multics milestone (12 users) 04/69 Bell Labs drops out of Multics (I included the latter since I'm assuming the "time Unix arose" is after the Bell Labs departure.) Note: I'm not saying or implying anything about the 3 systems with this; this is purely data. Noel

7 years, 5 months

Re: [TUHS] pre-UNIX legacy in UNIX?

by Doug McIlroy

> > are there other tangible[1] manifestations of non-UNIX operating > > system things like the GECOS field that were carried forward intact in > > later UNIX implementations? > > Job control was inspired by ITS job control capabilities. Control-Z > does pretty much the same thing in both operating systems. I don't think "carried forward" describes job control, which I believe was never in any Research system. "Borrowed" would be more accurate. In fact, I don't recall being aware of the existence of the ITS movement at the time Unix arose. Doug

7 years, 5 months

Re: [TUHS] pre-UNIX legacy in UNIX?

by Richard Tobin

> > In fact, I don't recall being aware of the existence of the ITS > > movement at the time Unix arose. > Was there ever a movement? It was just four machines at MIT. When AT&T sued BSD Inc over (among other things) the phone number 1-800-ITS-UNIX, the joke was that MIT should have sued them too. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 5 months

Re: [TUHS] OT: trains [Was: Date madness]

by Norman Wilson

Ian Zimmerman: > How do other train systems handle [DST], e.g. the European intercity > system? Dave Horsfall: UTC? It's not hard to get used to it. ===== You misunderstand the problem. Suppose I'm planning to board a train at 0300 on the morning Daylight Time ends. Now suppose the train actually departs an hour early, at 0200, because it originated before the time change and some nerd who never rides trains declared that it shall not wait the extra hour until scheduled departure time. Nerds may be happy, but the paying passengers won't be. Telling passengers to set their watches to UTC just won't happen. (Some of us nerds actually had our watches on GMT for a few months back in the years that gave the `Nixon table' in old ctime.c its (informal) name, but gave up because it was just too damn much work to stay in sync with the real world.) Once upon a time, before railways had radio communications and proper track-occupancy signalling, the consequences were more serious than that: if you run an hour ahead of schedule, you risk colliding with another train somewhere. That is why it was the railways that first accepted and promoted standard time zones. Nowadays it's not about scheduling and safety, just about having an acceptable user interface. In a similar vein, I know of at least one case in which Amtrak changed the official departure time of a train (that requires advance reservations and often runs full) from 0000 to 2359, because people would get confused about which day midnight falls on and show up a day late. (Actually the Amtrak timetable read 1200 midnight and 11:59 PM, but 24-hour time is one of the changes I agree people should just accept and use.) Norman Wilson Toronto ON

7 years, 5 months

Early Clones / Rewrites for TUHS archives

by Clem Cole

My question about SOL got me thinking a bit. It would be nice to have section in TUHS of any early clones that could be collected. The two that I can think of that probably should be there are (other feel free to point ones that we should try to find): 1.) Idris, which was fairly true to V6 (enough that the one time I test it, things from pretty much just worked). It was notable from being first. Although the C compiler and the 'anat' (the assembler) were a tad different. It the system that got Bill Plauger in trouble @ USENIX @ UDEL when he was booed for a 'marketing' talk. 2.) CRDS (pronounced Cruds by those of use that use it at the time) - Charles River Data Systems. It was a UNIX-like system, although I do not think really attempted to hold to a V7 API much more than intent. Although if my memory serves me, one of the unique features was the use of Reed & Kanodia synchronization in its kernel [REED79], which I was a always a fan. The system was slow as sin bit it ran on a 68000. [CRUDS system, a Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used to bootstrap]. Clem [REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and Sequencers"

7 years, 5 months

Re: [TUHS] Date madness

by Norman Wilson

Arnold: ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s for several years and I don't remember having to set the date / time every time I did a reboot. They sat in a data center, so I may have never done a cold boot from power on. It was a LONG time ago now, so there's undoubtedly lots that I just plain don't remember. ==== I believe all the VAXes had time-of-year clocks, though the implementation and the method of access varied from model to model. On `Big' VAXes, the clock was considered part of the console front-end, and accessed through the model-specific console scheme. MicroVAXes had no console front-end; I believe the clock was accessed through registers, but it was an off-the-shelf digital-watch chip with some funny format (separate registers for year, month, day, hour, minute, second). So they all had proper battery-backed-up clocks, but of many different types. It wasn't as simple as reading a single counter out of a register, sensible as that might seem. If anyone's really interested I can dig up details for the several models of Big and MicroVAX I dealt with; I still have all the code lying around. Norman Wilson Toronto ON

7 years, 5 months

OT: Konrad Zuse

by Dave Horsfall

We lost Konrad Zuse on this day in 1995; he invented the world's first programmable computer -- the Z3 -- which was unfortunately lost in the Berlin bombing during 1943. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 5 months

Date madness

by jnc＠mercury.lcs.mit.edu

Heh, my V6 machine thinks (via 'date') that today is _Monday_, December 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the date code is probably missing the '400 year' exception. Noel

7 years, 5 months

shell PS1/PS2 which survive cut-paste

by George Michaelson

I tried a long time ago to set PS1 and PS2 to character sequences which would permit cut-paste to work. I failed, but I didn't try very hard. The choice of "# " and "> " interests me. Because roots prompt of "hash" has a side effect of making a cut-paste over it a comment in most shells. But.. it predates being *able* to cut-paste so it has to be a side-effect, not a design choice. "> " is more dangerous in cut-paste. Which again feels like a side-effect both by anachronistic time effects, and intent: nobody would be that suicidally mad to make cut-paste invoke shell pre-forming the command sequence which neccessarily zeros out the > targets before executing the cmd... -G

7 years, 5 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > One would think that SIMH I'm using Ersatz-11... > into the simulated computer's time of day clock. What Time of Day clock? We're talking PDP-11's here! :-) The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure none of their others did. And of course V6 long pre-dated the /93-94. Noel

7 years, 5 months

Re: [TUHS] Date madness

by Doug McIlroy

>>> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. >> >> Easy, but perhaps unwise. The sign bit is a potential escape hatch for >> times, just as it is for characters in UTF-8. > > I'm not sure what you're suggesting - UTF-8 works because it's a variable length encoding - a variable length timestamp might be interesting as an academic exercise, but there's no way for time() to specify how much space is needed, or be informed of how much space is allocated Like UTF-8, a variable-length time would be something normal programs aren't supposed to see--it would be a format for external media (i.e. file systems). Times in inodes would be variable-length. Times returned by stat() and time() would be full length. Only the kernel needs to know the encoding. One may note that inodes already use a variable-length encoding for the list of physical block addresses, so there is nothing radical here. I admit, though, that if the kernel can tell "old" from "new" inodes, then they could have different time encodings rather than one variable-length encoding. Doug

7 years, 5 months

Re: [TUHS] Early Clones / Rewrites for TUHS archives

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > It would be nice to have section in TUHS of any early clones that could > be collected. The Unix Tree does have a section for "Unix Clones", and it has Coherent, Xinu, Minix and some early Linuxes. Another one that's missing (although in a different category) is Ultrix-32.> Noel

7 years, 5 months

Partition table rationales?

by Random832

Is there any information on the rationales behind the sizes and positions of the hardcoded partitions in the rp/hp drivers in V6? There are odd gaps of unused space between ones that appear to be intended to be used together (I think I have some pieces of the puzzle worked out below, but not all). For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are 9200 blocks. The hp partitions looked more complicated, but it looks like the manpage is wrong about where partition 2 starts - 84018 vs 48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567 start on 100-cylinder boundaries, but are only a bit over 97 cylinders long - in fact, they are the same length as rp[01]: 203 RP03 cylinders. rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks, making rp[65] and 47 reasonably non-wasteful configurations. Is there something special about 9200 blocks? rp2 and rp3 are that size, and hp1 is that size rounded to the next cylinder. V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set with no wasted space. hp[0145], 016, and 017 are non-overlapping sets.

7 years, 5 months

Re: [TUHS] Date madness

by Doug McIlroy

> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. Easy, but perhaps unwise. The sign bit is a potential escape hatch for times, just as it is for characters in UTF-8. Doug

7 years, 5 months

Difference in purpose of /var/spool vs /var/lib

by Grant Taylor

Can anyone enlighten me on the effective difference in the use of /var/spool vs /var/lib? It's my understanding that spools are for files that are in transit. Effectively like packages moving through a shipping depo or people waiting in line. I.e. they come in, they hang around for a while, and then they leave. I'm of the opinion that files in /var/lib should stick around longer and are not nearly as dynamic (if at all, save for code updates). As sure as I type this, I can't think of a reason library files would go under /var vs a different */lib directory. Does it make any difference if the files are actually executed and / or consumed on the system? I don't consider the POP3 / IMAP / NNTP server to be processing files when people access messages / articles (read: files) via the respective protocols. Back story: I'm considering writing something that will download a file every day and process the last day's / week's / month's file(s) to generate output which is itself stored elsewhere. - I feel like these files should live in the /var/spool/<bla> subdirectory. -- Grant. . . . unix || die

7 years, 5 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Tom Ivar Helbekkmo > My /83s have them, but I'm not so sure it's a feature of the CPU board: > there's this thought nagging in the back of my head that the ToY thing > actually sits in the front panel module with the various buttons on it. /83 documentation seems to be very thin on the ground, alas. It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual (EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84 Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a different backplane, with QBUS/UNIBUS converter, so this could equally well be titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock", indicating the 83/84 don't have one. Several companies made after-market ToD clocks to plug into the QBUS, e.g. here: https://www.ebay.com/itm/371284594072 Is something like that what your /83 has? Noel

7 years, 5 months

Other history lists...

by Grant Taylor

Does anyone know of any other similar history discussion mailing lists / newsgroups to discuss things like Mainframes or (Open)VMS? I have some questions as I try to broaden my horizons, but I don't think they fit in the TUHS context. -- Grant. . . . unix || die

7 years, 5 months

V7 Addendem

by Warner Losh

>From the tuhs web site: "This is a set of addenda to Seventh Edition Unix, possibly put out by the Labs." and "The identity of the person who donated them is unknown." Two questions: Was this put out by the Labs? Second: There was recently a discussion about a tape found at some public location during an early Unix user group meeting. Is this that tape? Warner

7 years, 5 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > So how did you manage to lose a whole year? Time travel? :-) No, I just haven't booted the V6 often in the last year, and when I did, I never bothered to reset the time; so it was still on Nov, 2016. Noel

7 years, 5 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> So, I looked at the code, and the bug is not obvious. Because there _was_ no bug!!! :-) It was saying December 12 was a Monday because the _year_ was still set to _2016_, and in 2016, December 12 _was_ a Monday! {Smacks forehead!} Noel

7 years, 5 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> Guess the date code is probably missing the '400 year' exception. So, I looked at the code, and the bug is not obvious. (The routine for detecting leap years in V6's ctime.c is so minimalistic it actually works for 2000!) The version I'm currently running had been worked on some, to have a hack fix for the overflow of the number of 8-hour periods since the epoch ("hack" since the 'fixed' version will break in 2029 or so), and I was worried that 'fix' was wrong and caused the week-day problem, but I don't think so. Noel

7 years, 5 months

The French SOL Project

by Clem Cole

In the early 1980s, a bunch of French researchers set out to build a clone of UNIX/V7 in Pascal (using a ukernel IIRC). The project was the SOL project [Gien, 1983]. I believe it eventually begat the Chorus system (which was C++); which UI was going to use for System V/R5 before it all blew up. 1) Does anyone know what happen to SOL? Was it finished, deployed, used for anything? 2.) Did the sources and doc survive (and who owns the IP)? I think those should be in the TUHS archives, as I think this was the first attempt at a rewrite of UNIX in something other than C (or assembler). 3.) On a similar thought, did the Chorus code survive and who owns the IP? Clem [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX Association, 1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada, July, 1983, Pages 75-78

7 years, 5 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