TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by Warren Toomey

All, it's time to nudge the conversation away from debugging 2017 OOM issues and the pre-UNIX history of the Arpanet. We've been able to recover quite a deal of UNIX artifacts in the past two decades, but what artifacts (in your opinion) are still out there that we should try and unearth? Remember that the 50th anniversary is coming up in 2019. Here's my list: - more PDP-7 source code: the shell, the rest of the utilities - more 1st Edition source code: the rest of the utilities - ditto the missing bits of 3rd, 4th and 5th Editions - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?) - more details on who was Ted Bashkow, and the story behind his (+ others?) analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUni… - a firm date on the day that Ken added pipes to the kernel :) What else should be we looking for? What physical artifacts (drawings, artwork etc.) have we missed that should be sought after? Cheers, Warren

7 years, 8 months

Re: [TUHS] V7 Addendem

by Doug McIlroy

> Was this [v7 addenda] put out by the Labs? It is definitely Research code from the Labs. How it

7 years, 8 months

V10 spell vs. spell.old?

by Aharon Robbins

Hi. What's the difference between spell.old and spell in the V10 sources? I'm guessing spell.old is the original version for the small-address-space PDP-11 and that plain spell takes better advantage of the roomier vax... Thanks, Arnold

7 years, 8 months

Re: [TUHS] shell PS1/PS2 which survive cut-paste

by Paul Ruizendaal

>> 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. > > "#" as the root prompt predates # as the comment in the Bourne shell, > not to mention predating copy/paste entirely. (My understanding is that > the do-nothing command, ":" was used for comments. Talk about minimalist!) > > Same point for ">", since copy/paste didn't exist in the late 70s when > Bourne was doing the shell, it wasn't an issue. As early as V5 the (thompson) shell prompts were “#” and “%”, and “:” for a label. As the goto command exists in V4 (there is a man page for it), I would assume that those characters were used in V4 as well. So it would seem to go back to 1974. In the V7 (bourne) shell the default non-root prompt is “$”. Goto is dropped at this point. Don’t know when or where “>” was first used on Unix as a prompt character (on my boxes it still is “$”). Paul

7 years, 8 months

What UNIX Artifacts Are Still Missing?

by Paul Ruizendaal

> We've been able to recover quite a deal of UNIX artifacts in the past two > decades, but what artifacts (in your opinion) are still out there that > we should try and unearth? Remember that the 50th anniversary is coming up > in 2019. I’d be interested in anything on Spider/Datakit networking in V4-V7. (at them moment the trail starts at V8, with just a few hints in earlier source materials, and the bits that Noel found). My thinking is that there were two main lines of early networking development on Unix (and I realise that this gross simplification excludes many other worthy projects): 1. The “sockets” lineage from UoI NCP Unix -> BBN NCP Unix -> BBN TCP Unix -> 4.1a BSD -> 4.2 BSD 2. The “device” lineage from Spider -> Datakit -> UUCP -> streams -> STREAMS In the first lineage there is much material available, in the second very little. This is probably because Datakit was AT&T confidential at the time.

7 years, 8 months

Re: [TUHS] What UNIX Artifacts Are Still Missing?

by Nelson H. F. Beebe

Warren Toomey <wkt(a)tuhs.org> asks on Wed, 6 Dec 2017 08:21:13 +1000: >> - more details on who was Ted Bashkow, and the story behind his (+ others?) I found a short obituary at http://engineering.columbia.edu/web/newsletter/spring_2010/memoriam which is, in full: >> ... >> Theodore R. Bashkow Dr. Theodore R. Bashkow, professor emeritus of >> electricial engineering and computer science, died Dec. 23, 2009, at >> his home in Katonah, N.Y. See PDF version >> >> He was born in St. Louis, Mo., and attended Washington University, >> where he received his BS degree in mechanical engineering. He went on >> to receive his master’s and doctorate degrees at Stanford >> University. He served in the U.S. Air Force as a first lieutenant >> during World War II from 1943 to 1945. >> >> While in the Air Force, he served as maintenance officer and helped to >> stage the Enola Gay. In the 1950s, while at Bell Labs, Professor >> Bashkow became well known for his development of a new method for >> analyzing linear electrical networks, Professor Bashkow’s A matrix. He >> also became involved with digital computers. He joined the faculty of >> the Columbia Electrical Engineering Department in 1958 and helped >> transform the Electrical Engineering Department into the Department of >> Electrical Engineering and Computer Science. >> >> When, in 1979, this department was divided into the Electrical >> Engineering and Computer Science departments, Bashkow became one of >> the founding faculty members of Computer Science. He taught courses in >> digital logic, computer organization, and computer programming. He did >> research on parallel processing. In collaboration with Herbert >> Sullivan, he pioneered a new approach to that subject through the >> development of CHoPP, Columbia Homogeneous Parallel Processor, a >> large-scale, homogeneous, fully distributed parallel machine. A number >> of Columbia graduate students and a junior faculty member, David >> Klappholz, were also involved at various stages. >> >> In 1980, the Computer Science Department instituted an annual award in >> his honor, the Theodore R. Bashkow Award. Among his many affiliations, >> Professor Bashkow was an active member of IEEE, ACM, and Sigma Xi >> organizations. >> ... He is apparently not in Wikipedia. I then searched our local bibliography archives and found this publication-title summary (Bashkow is an uncommon name, so I didn't attempt to disambiguate the reported articles): MariaDB [bibtex]> select filename, label, substr(title,1,80) from bibtab where (author like '%Bashkow%') order by year, filename; +-------------------------+--------------------+----------------------------------------------------------------------------------+ | filename | label | substr(title,1,80) | +-------------------------+--------------------+----------------------------------------------------------------------------------+ | jacm.bib | Bashkow:1958:CPR | A ``Curve Plotting'' Routine for the Inverse Laplace Transform of Rational Funct | | ieeetranscomput.bib | Bashkow:1963:RDA | R63-106 The D 825 Automatic Operating and Scheduling Program | | ieeetranscomput.bib | Bashkow:1963:C | Contributors | | ieeetranscomput.bib | Bashkow:1963:PSD | A Programming System for Detection and Diagnosis of Machine Malfunctions | | ieeetranscomput.bib | Bashkow:1964:SCA | A Sequential Circuit for Algebraic Statement Translation | | fortran1.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput1970.bib | Bashkow:1971:BSS | B71-6 System Structure in Data, Programs, and Computers | | ieeetranscomput1970.bib | Bashkow:1971:BIC | B71-2 Introduction to Computer Organization | | ieeetranscomput1970.bib | Bashkow:1973:CRO | Comment on Review of Operating Systems Survey | | ovr.bib | Sullivan77b | A Large Scale, Homogeneous, Fully Distributed Parallel Machine | | ovr.bib | Sullivan77a | A Large Scale Homogeneous Fully Distributed Parallel Machine | | sigarch.bib | Sullivan:1977:LSHb | A Large Scale, Homogenous, Fully Distributed Parallel Machine, II | | sigarch.bib | Sullivan:1977:LSHa | A large scale, homogeneous, fully distributed parallel machine, I | | ieeetranscomput1980.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | super.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | ieeetranscomput1990.bib | Ghafoor:1991:SOG | A study of odd graphs as fault-tolerant interconnection networks | +-------------------------+--------------------+----------------------------------------------------------------------------------+ 17 rows in set (2.67 sec) ------------------------------------------------------------------------------- - 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, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Jon Forrest > LBL has never been part of UC Berkeley. It's (always?) been a > Department of Energy laboratory managed by the Univ. Actually, I think if you go back far enough (1930's), it was part of UCB, back when Lawrence first started it. And of course the DoE didn't exist until 1977, so during the early ARPANET era if would have been under the AEC, and then I assume the Energy Research and Development Administration after 1974 (I assume it didn't go with the NRC when the AEC was split up). Noel

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by Paul Ruizendaal

This page: http://www2.lbl.gov/Publications/75th/files/exhibit.html mentions 3 links between LBL and Arpanet: - In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor. - In 1986, when the Internet was on the verge of collapse from congestion, a Berkeley Lab researcher, Van Jacobson, co-developed the congestion control algorithms that allowed the Internet to keep growing. - In 1995, Jacobson and Steven McCanne developed MBone, the first successful software for multiparty audio and video conferencing over the Internet.

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by Paul Ruizendaal

I don’t think anybody was thinking you wilfully misrepresented things, it is always interesting to hear about strands of history that might have been missed earlier. It would be helpful to better understand the time period, people involved and the scope of work. I’m a bit confused as to what time period you are referring to: I think you are referring to the initial development of Arpanet, i.e. the second half of the sixties. Is that correct? There is a page here with some info on events in that period and it may have missed some interesting development work done at LBL: https://www.livinginternet.com/i/ii_roberts.htm Paul > > Message: 7 > Date: Mon, 4 Dec 2017 19:46:21 -0800 > From: Deborah Scherrer <dscherrer(a)solar.stanford.edu> > To: tuhs(a)minnie.tuhs.org > Subject: Re: [TUHS] ARPAnet now 4 nodes > Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70(a)solar.stanford.edu> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Yes, Van Jacobson was involved. Great guy. So sorry you feel the need > to think I am lying. Why would I make up this stuff? I was a > teeny tiny piece of it. Doesn't affect my career one way or other. I > don't care what you believe, but this really did happen. > > D

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > I don't know about the historical record. But everything I said is true, > based on my own personal experience. ... I was there, this happened. If > people didn't write it down, I don't know why. FWIW, I was actually at many of those meetings. (You can find my name in a lot of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved - and the Meeting Notes (which, you will note, are quite detailed) indicate the same thing. (Later on, of course, Van Jacobson of LBL did some imporant work on TCP congestion control, but that was in '87 or so - I can't instantly lay my hands on my copy of Van's famous e-mail, to get a more exact date - some years after the full-scale deployment of TCP/IP in January, 1983.) > Why would I misrepresent? Perhaps you are conflating several different things in your memory? Human memory is very fallible, which is why historians prefer contemporary documents (and even those sometimes have errors). Here: http://www.chiappa.net/~jnc/nontech/tmlotus.html is a mildly amusing example (from a completely different arena) of all that. Noel

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer <dscherrer(a)solar.stanford.edu> > A lot of the TCP/IP development was done at the Lab. I think this is incorrect. The "Birth of the Internet" plaque: http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg mentions a number of organizations, but not UCB. Also, if you look at early TCP/IP Meeting Notes, which list all the meeting attendees, e.g.: http://www.postel.org/ien/txt/ien3.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien134.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien160.txt http://www.postel.org/ien/txt/ien175.txt (plus a bunch more only available in PDF form here: http://www.postel.org/ien/pdf which I couldn't be bothered to look at, since they are huge scans which take a while to download - see the IEN Index for the numbers) you won't find anyone from UCB listed in any of them. Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but it had nothing to do with the "development" of TCP/IP. Noel

7 years, 8 months

signals and blocked in I/O

by Larry McVoy

Does anyone remember the reason that processes blocked in I/O don't catch signals? When did that become a thing, was that part of the original design or did that happen in BSD? I'm asking because I'm banging on FreeBSD and I can wedge it hard, to the point that it won't recover, by just beating on tons of memory. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > the initial research on the arpanet was done at Lawrence Berkeley Lab I was interested to find out more about this: I looked in Hafner, "Where Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET) but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did have Lawrence Livermore); there were a couple of 'Californa, University of (at Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet" (the first half of which covers the ARPANET), nothing under any of 'Lawrence Berkeley', 'LBL', 'Berkeley' or 'California'. In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA history, which has extensive coverage of the ARPANET project), there was one entry for 'Californa, University (Berkeley)', which might be about the work you refer to: "IPTO issued a contract for a 'network' project at the Berkeley campus of the University of California ... because of the presence at Berkeley of specialists in programming languages and heuristic programming". But there's nothing about what was produced. Is there anything you can point me at that provides more detail? Thanks! Noel

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> SRI, UCSD, UCLA, Utah: Ooops, typo: UCS_B_. Noel

7 years, 8 months

Re: [TUHS] ARPAnet now 4 nodes

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > The ARPAnet reached four nodes on this day in 1969 (anyone know which?) SRI, UCSD, UCLA, Utah: http://www.chiappa.net/~jnc/tech/arpageo.html All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in HOSTS.TXT, they were assigned in order of installation. > at least one "history" site reckoned the third node was connected in > 1977 ... Well, I can believe that perhaps there were only three left by > then... No: http://www.chiappa.net/~jnc/tech/arpalog.html 1977 was not too many years before the peak in size (with the MILNET split coming in October, 1983). Per: http://www.chiappa.net/~jnc/tech/arpanet.html "Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET with 68 nodes." Noel

7 years, 8 months

Re: [TUHS] RIP J.F.Ossanna

by Larry McVoy

On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote: > Larry McVoy <lm(a)mcvoy.com> wrote: > |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote: > |> 1977 marks my entry into the world of UNIX. I've always stated there was > |> only one person who truly understood nroff and he was dead. > |> I mourn the fact that of all the UNIX greats I've met, I missed out on > |> Ossanna. > > |I think one could argue that James Clark has a pretty good handle on > |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc). > > And Werner Lemberg, who carried the torch for the last almost two > decades. He brought in some really great improvements, like > arguments for strings, which allows to write pretty much TeX like > a.k.a. inline if you want to (as in "this is \*[I talic] text"). Yep. James exited stage left and Werner stepped in. I mean no disrespect to anyone, I was just saying that James has a really good handle on roff, he redid it all. I admire him for doing so (even though I curse the fact that he did it in C++).

7 years, 8 months

Unix on PDP8?

by Will Senn

All, Was Unix ever ported to a PDP8, or any other 12 bit environment, for that matter? If not, why not? My understanding, such as it is, is that Unix was created on the PDP7 - btw, thank you very much, Ken Thompson, you definitely changed my world :), which is an 18bit machine, and that it soon found its first real home on the 16 bit PDP11 series of machines (an 11/20), and from there, ever upward or at least ever onward. I'm curious about it for historical reasons, of course, but also because I've been messing around in the PDP8 emulation world and enjoying the excursion into simplified ISA and memory architectures. -will

7 years, 8 months

Re: [TUHS] UNIX on S/370

by Larry McVoy

So tape I can see being more weird, but isn't raw disk just "don't put it in buffer cache"? >From what I've been able to gather early tape in Unix was dicey, something about the driver doing seek. Was there more to it than that? On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote: > It???s not so much that they don???t mix, it???s not quite the same. Some > coprocessor ideas work really well into the Unix I/O model, others don't. > Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an > IBM channel controller or a CDC PPU. > > > > > > > > > On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm(a)mcvoy.com> wrote: > > > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote: > > > > > > > > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow > > > exposed above the device driver layer? If so, I missed that, because I > > had > > > no conceptual or technical problem with talking to an I/O > > > > > > > channel, it was pretty easy. And I suck at writing drivers. > > > > > > There's nothing that restricts a device driver to memory mapped I/O. > > You > > > do what ever you have to do to initiate the I/O. Even the x86's > > originally > > > used special instructions to start the I/O (in/out). The DENELCOR HEP > > > supercomputer (we did this port around 1983) we had to bounce I/O > > requests > > > off a separate I/O processor different from where the kernel was running. > > > Similar constucts were used on other machines. > > > > Yeah, that's what I thought. But other people were saying that I/O > > processors and Unix didn't mix. I don't get that, seems like whatever > > the model is is hidden under the driver, that's the whole point of the > > driver design is it not? > > > -- > Sent from a handheld expect more typos than usual -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 8 months

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > Entry points are usually defined as "foo$bar", where "foo" is the > segment name, and "bar" an entry point in the segment symbol table. I > believe that the degerate case of "foo$" is treated as "foo$foo" by the > shell. So I'm curious about how this, and additional names, interact. (For those who aren't familiar with Multics, a segment [file, sort of] can have multiple names. This is sort of like 'hard links' in Unix, except that in Multics one name, the "primary name" is very slightly preeminent. See here: http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout page 2-5, for more, if you're interested.) So if I have a segment with primary name 'foo', and additional names 'bar' and 'zap', and I say 'zap' to the Multics shell, I assume it does a call to zap$zap, which finds the segment with the primary name 'foo', and calls the 'zap' entry therein? > Multics rulez; UNIX droolz Dude, you clearly have Very Large brass ones to send that to this list! :-) Noel

7 years, 8 months

Dash options

by Jon Steinhart

Does anybody know the history of dash options? Were they a UNIX thing or did UNIX borrow them from something earlier? Jon

7 years, 8 months

Re: [TUHS] Dash options

by Doug McIlroy

Early on, when multics was understood to have one big, segemented address space, it was expected that PL/I name qualification ($) would serve to address segments. I do not know whether that idea was actually implemented. Doug

7 years, 8 months

/bin/true (was [TUHS] basic tools / Universal Unix)

by Ron Natalie

My favorite reduction to absurdity was /bin/true. Someone decided we needed shell commands for true and false. Easy enough to add a script that said "exit 0" or exit 1" as its only line. Then someone realized that the "exit 0" in /bin true was superfluous, the default return was 0. /bin/true turned into an empty, yet executable, file. Then the lawyers got involved. We got a version of a packaged UNIX (I think it was Interactive Systems). Every shell script got twelve lines of copyright/license boilerplate. Including /bin true. The file had nothing but useless comment in it.

7 years, 8 months

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> Multics had some kind of `attach' and `detach' of I/O streams, well > known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go > with it meant `>' was earmarked early on. According to "The Evolution of the Unix Timesharing System", full path names arrived later than I/O redirection, so by they time they needed a separator, '>' and '<' were gone. '/' also has the advantage of being a non-shift character! Noel PS: Re-reading that, I see that early Unix did not have an exec() call (as I was just discussing); it was done in user mode, with normal read and write calls.

7 years, 8 months

Re: [TUHS] Dash options

by Paul Ruizendaal

> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com> > wrote: > >> MS/DOS patterned its command line >> >> syntax after RT-11 and inherited the slash as a command option >> introduction from there. > > Minor correction... To do a CDC style patient zero history ;-) RT11 took > it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became > PC-DOS ney MS/DOS took it from CP/M. I think Gary Kildall was very much into the PDP-8 when teaching at the Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler for instance). Can't find the link now, but I read somewhere that his work with the 8008 and 8080 was guided by the idea of having a PDP-8 like machine in his home office. For CP/M's command syntax RT11 probably did not come into it. I just had a quick glance through the CP/M 1.4 - 2.2 manuals, and I did not see slash options (or any other option character). Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls were done such that converting existing 8080 CP/M code with Intel's source level 8080-to-8086 asm converter would generate the correct code. The FAT file system was modeled after the one used by MS Disk BASIC for the 8086. Not sure where the QDOS command line came from, other than CP/M. MS did a lot of its early development on a PDP-10: perhaps that was an inspiration too. Sorry for getting off-Unix-topic...

7 years, 8 months

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > But if that had been in D space, it couldn't have been executed. Along those lines, I was wondering about modern OS's, which I gather for security reasons prevent execution of data, and prevent writing to code. Programs which emit these little 'custom code fragments' (I prefer that term, since they aren't really 'self-modifying code' - which I define as 'a program which _changes_ _existing_ instructions) must have some way of having a chunk of memory into which they can write, but which can also be executed. > Where is the boundary between changing one instruction and changing them > all? Or is this boundary a figment of imagination? Well, the exec() call only overwrites existing instruction memory because of the semantics of process address space in Unix - there's only one, so it has to be over-written. An OS operating in a large segmented single-level memory could implement an exec() as a jump.... BTW, note that although exec() in a single address-space OS is conventionally something the OS does, this functionality _could_ be moved into the user space, provided the right address space primitives were provided by the OS, e.g. 'expand instruction space'. So the exec() code in user space would i) find the executable, ii) see how much of each kind of memory it needs, iii) get the OS to give it a block of memory/address space where the exec() code can live while it's reading in the new code, iv) move itself there, v) use standard read() calls to read the new image in, and then vi) jump to it. Yes, it's probably simpler to implement it in the OS, but if one's goal is to minimize the functionality in the kernel... Noel

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