TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by Dave Horsfall

A nerdy group on an Aussie list are discussing old Unix cracks, and the infamous "SPL 0" brick-that-box came up. I first saw it in ";login:" (I think), and, err, tried it (as did others)... Can anyone reproduce the code? It went something like: > [ SPL 0 ] > > I only did that once (and you should've heard what he said to me)... > I'm still trying to find the source for it (it was published in a > ";login:" journal) to see if SIMH is vulnerable. The concept was simple enough - fill your entire memory space with an uninterruptible instruction. It would have gone something like: opc = 000230 ; 000230 is the opcode for SPL 0 sys brk, -1 ; or whatever value got you all 64k of address space mov #place, sp jmp place . = opc - 2 ; the -2 is to allow for the PC increment on an instruction fetch, which I believe happens before any execution place: jsr pc, -(pc) Ring any bells, anyone? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

Re: [TUHS] Happy birthday, Internet!

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > The Internet ... was born on this day in 1969, when RFC-1 got published I have this vague memory that the Internet-History list decided that the appropriate day was actually the day the format of the v4 headers was set, i.e. 16 June, 1978. (See IEN-68, pg. 12, top.) Picking the date of RFC-1 seems a little odd. Why not the day the first packet was send over a deployed IMP, or the day the RFP was sent out, or the contract let? And the ARPANet was just one predecessor; one might equally have picked a CYCLADES date... > (spelled with a capital "I", please, as it is a proper noun) ... As I > said at a club lecture once, there are many internets, but only one > Internet. I myself prefer the formulation 'there are many white houses, but only one White House'! :-) Noel

7 years, 4 months

Happy birthday, J. Presper Eckert!

by Dave Horsfall

J. Presper Eckert was born on this day in 1919; along with John Mauchly, he was a co-designer of ENIAC, one of the world's first programmable electronic computers. Yes, there is a long-running dispute over whether ENIAC or Colossus was first; being a Pommie, I'm siding with Colossus :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

Re: [TUHS] long lived programs

by Norman Wilson

Steve Johnson: But in this case, part of the requirement was to pass some standard simulation tests (in FORTRAN, of course). He was complaining that these programs had bugs and didn't give the right answer. ==== This reminds me of an episode during my time at Bell Labs. The System V folks wanted to make pipes that were streams; our experience in Research showed that that was useful. We'd done it just by making pipe(2) create a stream. This caused some subtle differences in semantics (pipes became full-duplex; writing to a pipe put a delimiter in the stream, so that a corresponding read on the other end would stop at the delimiter; write(pipefd, "", 0) therefore generated something that would make read(pipeotherfd, buf, len) return 0). We'd been running all our systems that way for a while, and had uncovered no serious problems. But the System V folks were very nervous about it anyway, and wrote a planning document in which they proposed to create a new, different system call to make stream pipes. pipe(2) would make an old-fashioned pipe; spipe(2) (or whatever it was called, I forget the name) had to be called to get a stream. The document didn't really explain the justification for this. To us in Research it just sounded crazy. Someone else was going to attend a meeting with the developers, but at the last minute he had a conflict, so he drafted me to go. Although I can be pretty blunt in writing, I try not to be so much so in person when dealing with people I don't know; so rather than asking how they could be so crazy as to add a new kind of pipe, I asked why they really thought it necessary. It took a little probing, but the answer turned out to be that their management insisted that everything pass an official verification suite to prove compliance with the System V, Consider It Standard; and said verification suite didn't just check that the first file descriptor returned by pipe(2) could be read and the second written, it insisted that the first could not be written and the second not read. Full-duplex pipes didn't meet the standard, it was claimed. I asked what exactly is the standard? The SVID, I was told. What does the SVID really say, I wondered? We got a copy and looked up pipe(2). According to the official standard, the first file descriptor must be readable and the second writeable, but there was no statement that it couldn't work the other way too. Full-duplex pipes did in fact meet the standard; it was the verification suite that, in an excess of zeal, didn't conform. The developers were absolutely delighted with this. They too thought it was stupid to have two different kinds of pipes, particularly given our experience that full-duplex delimited pipes didn't break anything. They were very happy to have Research not just yell at them for doing things differently from us, but help them figure out how to justify doing things right. I don't know just how they took this further with management, but as it came out in SVr4, pipe(2) returned a full-duplex stream. This is still true even unto Solaris 10, where I just tested it. I made friends that day. That developer group kept in touch with me as they did further work on pipes, the terminal driver, pseudo-ttys, and other things. I didn't agree with everything they did, but we were able to discuss it all cordially. Sometimes the verification program just needs to be fixed. And sometimes the developers that seem set on doing the wrong thing really want help in subverting whatever is forcing that on them, because they really do know what the right thing is. Norman Wilson Toronto ON

7 years, 4 months

Re: [TUHS] Happy birthday, Internet!

by Rudi Blom

Just had a look at RFC-1, my first look ever. First thing I noticed is the enormous amount of abbreviations one is assumed to be able to instantly place :-) So looking up IMP for instance the wiki page gives me this funny titbit "When Massachusetts Senator Edward Kennedy learned of BBN's accomplishment in signing this million-dollar agreement, he sent a telegram congratulating the company for being contracted to build the "Interfaith Message Processor"." https://en.wikipedia.org/wiki/Interface_Message_Processor

7 years, 4 months

Re: [TUHS] long lived programs

by Doug McIlroy

> Shortly after I arrived, the comp center announced a brand-new feature -- permanent disc storage! (actually, I think it was a drum...) Irrelevant to the story (or Unix), but it was indeed a disc drive--much more storage per unit volume than drums, which date to the 1940s, if not before. Exact opposite of current technology: super heavy and rigid combs banged in and out of the disk stack. The washing-machine sized machine could be driven to walk across the floor. It would not be nice to be caught in its path. (Fortunately ordinary work loads did not have such an effect.) Vic Vyssotsky calculated that with only 10 times its 10MB capacity, we could have kept the entire printed output since the advent of computers at the Labs on line. Doug

7 years, 4 months

Happy birthday, Internet!

by Dave Horsfall

The Internet (spelled with a capital "I", please, as it is a proper noun) was born on this day in 1969, when RFC-1 got published; it described the IMP and ARPAnet. As I said at a club lecture once, there are many internets, but only one Internet. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

Re: [TUHS] shared objects in Unix (Clem cole) / Accent influence

by Paul Ruizendaal

> Date: Fri, 30 Mar 2018 00:28:13 -0400 > From: Clem cole <clemc(a)ccc.com> > > Also, joy / BSD 4.2 was heavily influenced by Accent (and RIG )and the Mach memory system would eventually go back into BSD (4.3 IIRC) - which we have talked about before wrt to sockets and Accent/Mach’s port concept. From an "outsider looking in” perspective I’m not sure I recognise such heavy influence in the sockets code base. Of course, suitability for distributed systems was an important part of the 4.2BSD design brief and Rick Rashid was one of the steering committee members, that is all agreed. However in the code evolution for sockets I only see two influences that seem not direct continuations from earlier arpanet unices and have a possible Accent origins: - Addition of sendto()/recvfrom() to the API. Earlier code had poor support for UDP and was forced through the TCP focused API’s, with fixed endpoint addresses. It could be Accent inspired, it could also be a natural solution for sending datagrams. For example, Jack Haverty had hacked a “raw datagram” facility into UoI Arpanet Unix around ’79 (it’s in the Unix Tree). - Addition of a facility to pass file descriptors using sendmsg()/recvmsg() in the local domain. This facility was only added at the very last moment (it was not in 4.1c, only in 4.2). I’m being told that the CSRG team procrastinated on this because they did not see much use for it — and indeed it was mostly ignored in the field for the next two decades. Joy had left by that time, so perhaps the dynamics had changed. Earlier I though that the select() call may have come from Accent, but it was inspired by the Ada select statement. Conceptually, it was preceded on Unix by Haverty’s await() call (also ’79). For clarity: I wasn’t there, just commenting on what I see in the code. Paul

7 years, 4 months

dead bstj unix link on wikipedia

by ron minnich

anyone got a fix? https://en.wikipedia.org/wiki/Bell_System_Technical_Journal see this text 1. Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing System" <http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html>. *Bell System Technical Journal*. *57* (6). Retrieved 2010-10-22

7 years, 4 months

shared objects in Unix

by Paul Winalski

The recent discussion of long-lived applications, and backwards compatibility in Unix, got me thinking about the history of shared objects. My own experience with Linux and MacOS is that statically-linked applications tend to continue working from release to release, but shared objects provided by the OS tend not to be backwards compatible, and one often has to carry around with your application the exact C runtime and other shared objects your program was linked against. This is in big contrast to shared libraries on VMS, where great care is taken to maintain strict backward compatibility release to release. What is the history of shared objects on Unix? When did they first appear, and with what object/executable file format? The a.out ZMAGIC format doesn't seem to support them. I don't recall if COFF does. MACH-O, at least the MacOS dialect of it, supports dynamic libraries. ELF supports them. Also, when was symbol preemption invented? Traditional shared library designs such as in IBM System/370, VMS, and Windows NT doesn't have it. As one who worked on optimizations in compilers, I came to hate symbol preemption because it prohibits many useful optimizations. ELF does provide a way to turn it off, but it's on by default--you have to explicitly declare symbols as protected or hidden via source language pragmas to get rid of it. -Paul W.

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