TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by jnc＠mercury.lcs.mit.edu

> From: Grant Taylor > I'm not quite sure what you mean by naming a node vs network interface. Does one name (in the generic high-level sense of the term 'name'; e.g. an 'address' is a name for a unit of main memory) apply to the node (host) no matter how many interfaces it has, or where it is/moves in the network? If so, that name names the node. If not... > But I do know for a fact that in IPv4, IP addresses belonged to the > system. No. Multi-homed hosts in IPv4 had multiple addresses. (There are all sorts of kludges out there now, e.g. a single IP address shared by a pool of servers, precisely because the set of entity classes in IPvN - hosts, interfaces, etc - and namespaces for them were not rich enough for the things that people actually wanted to do - e.g. have a pool of servers.) Ignore what term(s) anyone uses, and apply the 'quack/walk' test - how is it used, and what can it do? > I don't understand what you mean by using "names" for "path selection". Names (in the generic sense above) used by the path selection mechanism (routing protocols do path selection). > That's probably why I don't understand how routes are allocated by a > naming authority. They aren't. But the path selection system can't aggregate information (e.g. routes) about multiple connected entities into a single item (to make the path selection scale, in a large network like the Internet) if the names the path selection system uses for them (i.e. addresses, NSAP's, whatever) are allocated by several different naming authorities, and thus bear no relationship to one another. E.g. if my house's street address is 123 North Street, and the house next door's address is 456 South Street, and 124 North Street is on the other side of town, maps (i.e. the data used by a path selection algorithm to decide how to get from A to B in the road network) aren't going to be very compact. Noel

6 years, 6 months

Re: [TUHS] Happy birthday, Ken Thompson!

by Doug McIlroy

> Ken wrote ... ed(before regexp ed) Actually Ken wrote a regexp qed (for Multics) before he wrote ed. He wrote about it here, before the birth of Unix: Programming Techniques: Regular expression search algorithm Ken Thompson June 1968 Communications of the ACM: Volume 11 Issue 6, June 1968 This is the nondetermistic regexp recognizer that's been used ever since. Amusingly a reviewer for Computing Reviews panned the article on the grounds that everybody already knew how to write a deterministic recognizer that runs in linear time. There's no use for this slower program. What the reviewer failed to observe is that it may take time exponential in the size of the regexp (and ditto for space) to make such a recognizer. In real life for a one-shot recognizer that can easily be the dominant cost. The problem of exponential construction time arose in Al Aho's egrep. I was an early adopter--for the calendar(1) daemon. The daemon generated a date recognizer that accepted most any (American style) date. The regular expresssions were a couple of hundred bytes long, full of alternations. Aho was chagrinned to learn that it took about 30 seconds to make a recognizer that would be used for less than a second. That led Al to the wonderful invention of a lazily-constructed recognizer that would only construct the states that were actually visited during recognition. At last a really linear-time algorithm! This is one of my favorite examples of the synergy of having sytems builders and theoreticians together in one small department. Doug

6 years, 6 months

Software Archeology: QED

by Christopher Browne

Sorry to drop in on the thread a bit late, and, strictly speaking, not (according to headers) connected to the thread; I am well acquainted with David Tilbrook, who is sadly not doing too well; it is not surprising that Leah Neukirchen was unable to get a hold of him as he hasn't been using email for some number of years > 1, and is definitely not programming. Hugh Redelmeier and I are looking into trying to do some preservation of his QEF toolset that included the QED port. Neither Hugh nor I are ourselves QED users; I'm about 30 years into my Emacs learning curve, albeit using Remacs (the Rust implementation) lately, while Hugh maintains JOVE to the extent to which it remains maintained. http://www.cs.toronto.edu/pub/hugh/jove-dev/ -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

6 years, 6 months

Happy birthday, Ken Thompson!

by Dave Horsfall

Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful (I know, it's an exaggeration, but think about it). -- Dave

6 years, 6 months

Re: [TUHS] Commercial UNIX was other stuff before

by Clem Cole

On Sun, Feb 3, 2019 at 2:59 PM Cág <ca6c(a)bitmessage.ch> wrote: > [Hockey Pucks and AIX are alive, Wikipedia says. > The problem could be that neither support amd64 and/or Be careful. The history of proprietary commercial UNIX implementations is that they were developed by HW manufacturers that had proprietary ISAs. So that fact that UX was Itanium and AIX was Power (or Tru64 in its day was Alpha) should not be surprising. It was the way the market developed. Each vendor sold a unique ecosystem and tried very hard to keep you in it. Portability was designed as an >>import<< idea, and they tried to keep you from exporting by getting you to use 'value add.' I remember during the reign of terror that Solaris created. Take as an example, the standard portable threading library was pThreads. But Solaris threads were faster and Sun did everything it could get the ISV's write using Solaris Threads. Guess what -- they did. So at DEC we found ourselves implementing a Solaris Threads package for Tru64, so the ISVs could run their code (I don't know if IBM or HP did it too, because at the time, our competition was Sun). BTW: this attitude was nothing new. I've said it before, the greatest piece of marketing DEC ever did was convince the world that VMS Fortran was Fortran-77. It was not close. And when you walked into most people writing real production code (in Fortran of course), you discovered they had used all of the VMS Fortran extensions. When the UNIX folks arrived on the scene the f77 in Seventh Edition was not good enough. You saw first Masscomp in '85, then a year later Apollo and 2 years after that, Sun develop really, really good Fortran's -- all that were VMS Fortran compatible. nobody cares about commercial Unix systems anymore. > This is a bit of blind and sweeping statement which again, I would take some care. There are very large commercial sites that continue to run proprietary UNIX on those same proprietary ISAs, often with ISV and in-home developed applications that are quite valuable. For instance, a lot of the financial and insurance industries live here. The question comes to how to value and count it. Just because the hackers don't work there, does not mean there are not a lots firms doing it. Those sites are extremely large and represent a lot of money. The number of them is unlikely to be growing last time I looked at the numbers. In fact, in some cases, they >>are<< being displaced by Intel*64 systems running a flavor of Linux. The key driver for this was the moving the commercial applications such as Oracle and SAP to Linux and in particular, Linux running on VMs. But a huge issue was code reuse. To reuse, Henry's great line about BSD, Linux is just like Unix; only different. Simply has the cost of maintaining your own ISA and complete SW ecosystem for it continues to rise and in fact is getting more and more expensive as the market shrinks. At this point, the only ones left are HP, IBM and the shadow of Sunoracle. They are servicing a market that is fixed. > > As far as commercial systems go, even CentOS has a far larger market > share on the supercomputer territory than RHEL does, according to > TOP500. > Again be careful. In fact this my world that I have lived for about 40+ years. The Top100 system folks really do not want any stinking OS between their application and the hardware. They never have. Don't kid yourself. This is why systems like mOS (Rolf Riesen's MultiOS slides <https://wrome.github.io/slides/rome16_riesen.pdf> and github sources <https://github.com/intel/mOS/wiki>) are being developed. Simply put, the HPC folks have always wanted the OS out the way. Unix was a convenience for them and Linux just replaced UNIX. The RHEL licensing scheme is per CPU and on a Beowulf style cluster, it does not make a lot of sense. I know a lot of the Linux community likes to crow about the supers using Linux. They really don't Its what runs on the login node and the job scheduler. It could be anything as long as its cheap, fast and the physicists can hack on it. This is a behavior that goes back the Manhatten Project and its unchanged. The 'capability' systems are a high-end world that is tuned for a very specific job. You can learn a lot in that area, but because about making generalizations. As I like to say -- Fortran still pays my salary. These folks codes are unchanged since my father's time as a 'computer' at Rocket Dyne in the 1950s. What has changed is the size of the datasets. But open up those codes and you'll discover the same math. They tend to be equation solvers. We just have a lot more variables. Clem

6 years, 6 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > a bunch of OSI/ISO network stack posters (thank goodness that didn't > become standard, woof!) Why? The details have faded from my memory, but the lower 2 layers of the stack (CLNP and TP4) I don't recall as being too bad. (The real block to adoption was that people didn't want to get snarled up in the ISO standards process.) It at least managed (IIRC) to separate the concepts of, and naming for, 'node' and 'network interface' (which is more than IPv6 managed, apparently on the grounds that 'IPv4 did it that way', despite lengthy pleading that in light of increased understanding since IPv4 was done, they were separate concepts and deserved separate namespaces). Yes, the allocation of the names used by the path selection (I use that term because to too many people, 'routing' means 'packet forwarding') was a total dog's breakast (allocation by naming authority - the very definition of 'brain-damaged') but TCP/IP's was not any better, really. Yes, the whole session/presentation/application thing was ponderous and probably over-complicated, but that could have been ditched and simpler things run directly on TP4. {And apologies for the non-Unix content, but at least it's about computers, unlike all the postings about Jimmy Page's guitar; typical of the really poor S/N on this list.) Noel

6 years, 6 months

Re: [TUHS] Happy Birthday Ken Thompson!

by Doug McIlroy

> without those two we'd all be running M$ Windoze Apropos of which, I complained to Walter Isaacson about his writing them out of "The Innovators"--Turing Award, National Medal of Technology, Japan Prize and all. I suppose I should not be surprised that he didn't deign to answer. Doug

6 years, 6 months

Wanted: AT&T System V Release 3.2.{1,2,3} Source Code

by Seth J. Morabito

[Cross-posted from the 3B2 mailing list] Hi folks, I'm in search of source code for AT&T's System V Release 3.2.1, 3.2.2, and/or 3.2.3 for the 3B2. Does this exist? Has anyone ever seen it? Note that I'm not looking for the System V Release 3.2 Source Code Provision for the 3B2 /310 and /400 -- I already have that. It was absolutely invaluable when I was writing my 3B2/400 emulator. The reason I'm so keen on getting access is that I have ROM images from a 3B2/1000, and I'd like to add support for it to my 3B2 emulator. The system board memory map seems a bit different than the /300, /310, and /400. These max out at SVR 3.2. I can't imagine trying to add 3B2/1000 support without the 3.2.x source code. I imagine there's some tape image somewhere that's a delta of files that take you from 3.2 to 3.2.1, 3.2.2 or 3.2.3? -Seth -- Seth Morabito Poulsbo, WA, USA web(a)loomcom.com

6 years, 6 months

DEC and Dave Cutler (was Re: The John Snow's of the UNIX family)

by Paul Winalski

On 1/16/19, Kevin Bowling <kevin.bowling(a)kev009.com> wrote: > I’ve heard and personally seen a lot of technical arrogance and > incompetence out of the Masshole area. Was DEC inflicted? In > “Showstopper” Cutler fled to the west coast to get away from this kind of > thing. > Having worked at DEC from February 1980 until after the Compaq takeover, I would say that DEC may have exhibited technical arrogance from time to time, but certainly never technical incompetence. DEC's downfall was a total lack of skill at marketing. Ken Olsen believed firmly in a "build it and they will come" philosophy. Contrast this with AT&T's brilliant "Unix - consider it a standard" ad campaign. DEC also suffered from organizational paralysis. KO believed in decisions by consensus. This is fine if you can reach a consensus, but if you can't it leads to perpetually revisiting decisions and to obstructionist behavior. There was a saying in DEC engineering that any decision worth making was worth making 10 times. As opposed to the "lead, follow, or get out of the way" philosophy at Sun. Or Intel's concept of disagree and commit. DEC did move towards a "designated responsible individual" approach where a single person got to make the ultimate decision, but the old consensus approach never really died. Dave Cutler was the epitome of arrogance. On the technical side, he got away with it because his way (which he considered to be the only way) was usually at least good enough for Version 1, if not the best design. Cutler excelled in getting V1 of something out the door. He never stayed around for V2 of anything. He had a tendency to leave messes behind him. A Cutler product reminded me of the intro to "The Peabodys" segment of Rocky & Bullwinkle. A big elaborate procession, followed by someone cleaning up the mess with a broom. Cutler believed in a "my way or the highway" approach to software design. His move to the west coast was to place himself far enough away that those who wanted to revisit all his decisions would have a tough time doing so. On the personal side, he went out of his way to be nasty to people, as pointed out elsewhere in this thread. Although he was admired technically, nobody liked him. -Paul W.

6 years, 6 months

Fwd: Posters

by Warner Losh

Meant to reply all on this.... Warner ---------- Forwarded message --------- From: Warner Losh <imp(a)bsdimp.com> Date: Sat, Feb 2, 2019, 11:37 PM Subject: Re: [TUHS] Posters To: Grant Taylor <gtaylor(a)tnetconsulting.net> I'll take pictures tomorrow. No zeppelin though... I had hoped that I still had my ultrix version of Phil Figlio's original usenix artwork. I can find the Usenix one and the Unix one, but not that one online. Anybody have one they can share? Warner On Sat, Feb 2, 2019, 7:32 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org wrote: > On 2/2/19 6:35 PM, Warner Losh wrote: > > Is there any interest from this group in photos of any of these? > > I would be interested in pictures of the computer related pictures to > see if I'd be interested enough to pay for and / or for shipping on any > of them. > > > > -- > Grant. . . . > unix || die > >

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