TUHS

tuhs@tuhs.org

21 participants
6516 discussions

by Richard Tobin

> The rest of your story is great, just one small correction. SunView started > as something Sun specific but it pretty quickly became a library on top of > X11. I'm not sure if it ever worked on X10, I think it did but I'm not sure. As I recall it, SunTools (the original Sun window system) was renamed SunView, and the API was ported to X11 under the name XView. > Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview. > This would have been around 1990, is that still X10 or X11? X11 came out in 1987. I The first version I remember using is X11R3, which came out in 1988. See https://www.x.org/wiki/X11R1 (and .../X11R2 etc) -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 8 months

Re: [TUHS] X and NeWS history (long)

by Nelson H. F. Beebe

Here is a BibTeX entry for a book on the NeWS system: @String{pub-SV = "Spring{\-}er-Ver{\-}lag"} @String{pub-SV:adr = "Berlin, Germany~/ Heidelberg, Germany~/ London, UK~/ etc."} @Book{Gosling:1989:NBI, author = "James Gosling and David S. H. Rosenthal and Michelle Arden", title = "The {NeWS} Book: an introduction to the {Network\slash extensible Window System}", publisher = pub-SV, address = pub-SV:adr, pages = "vi + 235", year = "1989", ISBN = "0-387-96915-2", ISBN-13 = "978-0-387-96915-2", LCCN = "QA76.76.W56 A731 1989", bibdate = "Tue May 25 07:20:00 1999", bibsource = "http://www.math.utah.edu/pub/tex/bib/unix.bib", keywords = "NeWS (computer file); Windows (computer programs)", } It is the only book that I have recorded on NeWS (I have it on my office bookshelf). If there is interest, I can post links to 10 or so journal articles and conference proceedings about NeWS from 1986 to 1990. ------------------------------------------------------------------------------- - 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

Mobile Strategies

by Ron Natalie

Trying a one solution fits all approach was always Microsoft's approach. Back over a decade ago when I was big into MFC development, it was amazing how much of the Windows bloat was present in WINCE (or Windows Moble as they later styled it). It's almost impossible to differentiate a desktop and mobile on the Windows side. They tout it as an advantage. Oddly, Android gives an indication of how to do it right. Sure, you can take the essentials out of the common system, but you don't have to move inappropriate bloat over.

7 years, 8 months

Re: [TUHS] File-as-record

by Doug McIlroy

> On the programming side, there wasn't either the memory capacity or > processing power to implement a modern disk file system. One of the > first computers I worked with was a System/360 model 25 running > DOS/360. The machine had 48K of core memory, 12K of which was for the > OS, leaving 36K for programs. No virtual memory. Unix was a counterexample. Recall that v1 worked on a 24K machine, 16K of which was OS and 8K user. And it had a modern file system. Programming was so much easier that it lured people (e.g. me) away from big mainframe computers. Doug

7 years, 8 months

Re: [TUHS] Happy birthday, Dennis Ritchie!

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > Just think, if it wasn't for him and Ken, we'd all be running Windoze, > and thinking it's wonderful. It's actually worse than that. We'd be running a Windows even worse than current Windows (which has managed to pick up a few decent ideas from places like Unix). Noel

7 years, 8 months

Move completed: slowly bringing stuff back up

by Cory Smelosky

Evening, Okay - now that I've completed moving and settling in, I am slowly bringing some stuff back up. UCBVAX should come back in the next few weeks (now much closer to Berkeley...). One advantage of the new location: cheaper power so my PBX runs all the time now. ;) Once I acquire a second modem I will accept UUCP at 115200 and 2400 baud via telephone :) -- Cory Smelosky b4(a)gewt.net

7 years, 9 months

Re: [TUHS] Line Terminators in Text Files

by Doug McIlroy

> does anyone know anything about the 1961 DoD 8-bit > character set standard it refers to? > > This does not appear to say anything about LF vs "Newline" (as either a > name or a function), though the 1986 version of ASCII deprecates it, so > was most likely acknowledged in versions between these in response to > practices on OSes such as Multics. ECMA-6:1973 acknowledges it I wouldn't say the "practices" of Multics influenced the recognition of NL in the ASCII standard, for Multics didn't go into use until 1970, while NL was specified by 1965 (see below) with direct reference to the properties of equipment, not operating systems. Just what equipment, I don't know. IBM Selectric perhaps? I recall Multics discussions that specifically cited the standard, in particular Joe Ossanna's liaison between Multics and the TTY 37 design team at Western Electric, circa 1967. Thus it is my understanding that Multics was an early adopter of ASCII's NL convention, not an influencer of it. Quotation from "Proposed revised American standard for information interchange", CACM 8 (April 1965) 207-214: The controls CR and LF are intended for printer equipment which requires separate combinations to return the carriage and feed a line. As an alternative, for equipment which uses a single combination for a combined carriage-return and line-feed operation (called New-Line), NL will be coded at FE 2 [LF]. Then FE 5 [CR] will be regarded as Backspace BS. If the latter type of equipment has to interwork with the former, it may be necessary to take steps to introduce the CR character. One might read the preceding paragraph as advice not only to writers of driver software but also to a future standards committee to undo the curious notion of regarding CR as BS. Unix effectively took it both ways, and kept the original meaning of CR. doug

7 years, 9 months

Re: [TUHS] [Groff] It is time to modernise "groff"

by Doug McIlroy

> troff has a substantial history. Significant changes in troff could invalidate most of the old documents leaving troff with no usage base, and a poor tool at rendering all of the troff documents out there. As a living example, I have troff files from as far back as 1975 that still work, and perhaps some even older that have lost their dates due to careless copying. The only incompatibility with groff is easy to fix: inserting a space before the arguments of a troff request. The few other incompatibilities I've encouuntered have been graciously corrected by groff maintainers. You get no such help for old Word files. doug

7 years, 9 months

looking for UNIX News (July 1975 through 1977)

by Jeremy C. Reed

Anyone have UNIX News newsletters from 1975/1976 and ;login: from 1977? For details see https://www.usenix.org/system/files/login/articles/login_apr15_16_unix_news… I don't know if is a complete transcription of the July 20, 1975 issue. That article suggests others will be reprinted, but I only found: Number 4, March 19, 1976 https://www.usenix.org/system/files/login/articles/login_june_11_unix_news.… Number 10, October 1976 https://www.usenix.org/system/files/login/articles/login_aug15_10_unix_news… Volume 2, Number 5, May--June 1977 https://www.usenix.org/system/files/login/articles/login_oct15_12_unix_news… (webpage wrongly says Number 10) Volume 2, Number 7, August 1977 https://www.usenix.org/sites/default/files/login_aug77.pdf excerpts: https://www.usenix.org/system/files/login/articles/login_dec15_11_history_l… Do you know of others? In an article, Salus wrote Number 2 is October 8, 1975 and Number 3 is February 10, 1976. Thanks Jeremy C. Reed p.s. I have read many AUUGN issues over the past few years. Thanks for hosting those.

7 years, 9 months

Line Terminators in Text Files [Was: Re: Why Pascal is Not My Favorite Programming Language - Unearthed!]

by Nemo

On 02/09/2017, Dave Horsfall <dave(a)horsfall.org> wrote: > On Thu, 31 Aug 2017, Nemo wrote: > >> (By the way, why all the ^M is the files?) > > Err, because CR/LF was the line terminator? Hhhmmm... This begs the historical question: When did LF replace CR/LF in UNIX? N. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." >

7 years, 9 months

RIP Solaris

by Diomidis Spinellis

In case you missed the news, it seems that Oracle is effectively shutting down the development of Solaris. You can read an eloquent obituary written by Bryan Cantrill at http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of…. Diomidis

7 years, 9 months

Re: [TUHS] Line Terminators in Text Files

by Doug McIlroy

> When did LF replace CR/LF in UNIX? Never. Unix always took LF as newline--an interpretation blessed by the ASCII standard. The convention was inherited from Multics. Interpolation of CRs was the business of drivers, not file formats. As far as I know, the only CR/LF terminal that original Unix dealt with was the model 33 console. That was identified by the fact that the login name was received in all caps. IIRC the TTY 37 conformed to Multics practice on the advice of Joe Ossanna. Because of the model 33, login names were case-insesitive. Come to think of it, I don't know whether they still are in general, though they must be for email to be delivered by login name. Doug

7 years, 9 months

Re: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal isNot My Favorite Programming Language - Unearthed!]

by Richard Tobin

> As I recall, the original definition of ASCII suggested that the > LF character was either "line feed" or "new line", and that if it > *was* new-line, it would be stand-alone. I have put a copy of the original ASCII standard (scanned images) at http://www.cogsci.ed.ac.uk/~richard/ascii.tar I don't remember where I got it from. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 9 months

Re: [TUHS] Future Languages

by Richard Tobin

> So we have some source (that you can have as well, Apache license) > that handles not strings but vectors of strings (or structs or whatever). > > I need to write up how it works, it's sort of clever. It stores both > the size of the vector (always a power of 2) in part of the bits of the > first entry and the actual length in the other part. Because we can > express powers of two in very little space we can support both values > in a 32 bit unsigned with a max length of used space of around 134M. I have something similar. It allocates space for two ints (number allocated and used) at ((int *)array)[-1] and [-2]. Typical use is LTVectorAndInit(char *, names); while(...) LTVectorPush(names, s); for(i=0; i<LTVectorCount(names); i++) ... names[i] ...; LTVectorFree(names); -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 9 months

Re: [TUHS] It is time to modernise "groff"

by Doug McIlroy

> > p) Remove the '-a' option (the ASCII approximation output). > > I didn't even know this existed. Looking at what it spits out, I find > myself wondering what good it is. Is this for Unix troff compatibility? > For people who didn't even have glass TTYs and needed to imagine what > the typeset output would look like? Here's a classic use: Since groff is not WYSIWYG, the experimental cycle is long: edit - save - groff - view. In many cases that cycle can be short-circuited by typing straight into groff -a. doug

7 years, 9 months

Re: [TUHS] Introduction to {t,r,g}roff & co...

by Norman Wilson

Call me old-fashioned, but I still think the papers in Volume 2 of the Seventh Edition manual are a good straightforward start. There's a tutorial on troff, and papers introducing eqn, tbl, and refer. Norman Wilson Toronto ON

7 years, 9 months

Introduction to {t,r,g}roff & co...

by Grant Taylor

Hi, Can anyone point to an introduction to {t,r,g}roff / pic / tbl / etcetera? I've respected them for years and with all the latest discussions about them I'd like to try and learn something. Any pointers would be appreciated. -- Grant. . . . unix || die

7 years, 9 months

Re: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

by Norman Wilson

Steve Johnson: I think of Alan Demer's comment: "There are two kinds of programming languages, those that make it easy to write good programs, and those that make it hard to write bad ones." ==== I'm (still) with Larry Flon on this one: There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs. -- SIGPLAN Notices, October 1975, p. 16. There are certainly language that make it easier to avoid trivial mistakes, like buffer overruns and pointer botches, but the sort of nonsense Kernigan and Plaugher demonstrated and discussed about the same time in The Elements of Programming Style shows up in any language. I'm afraid I see that nearly any time I look in source code. To be fair, these days I rarely have the time to look at someone else's source code unless it's buggy, but it is nevertheless appalling what one finds in critical system software like boot environments and authentication code. There is no royal language to good programs. Programming well takes discipline and skill and experience. Languages like Pascal that prevent certain classes of sloppiness like overrunning arrays and string buffers may be better for teaching beginners, but only because that makes it easier to focus on the real issues, such as how to structure a program well and how to write clearly. I have yet to see evidence that that actually happens. Norman Wilson Toronto ON

7 years, 9 months

Re: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is Not My Favorite Programming Language - Unearthed!]

by jnc＠mercury.lcs.mit.edu

> From: Chris Torek > termcap has entries for the number of NUL characters to insert after > carriage return. Actually, the stock terminal driver in V6 Unix (here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/dmr/tty.c if anyone wants to see the actual code; it's in ttyoutput()) had some pretty complex code to do just the right amount of delay (in clock ticks) for a large number of different motion contral characters (TAB, etc, in addition to LF and CR), and then uses the system timer to delay that amount of real time after sending such a character (see the very bottom of ttstart()). E.g. for a NL, it used the fact that it 'knew' which column the print head was in to calculate the exact return time. Clever, but alas, it did this by sticking 'characters' in the buffered output stream with the high bit set, and the delay required in the low 0177 bits, which the output start routine interpreted; as the code drolly notes, "thus (unfortunately) restricting the transmission path to 7 bits". Which was a real PITA recently when I tried to download a binary file to an LSI-11 from a V6 running in Ersatz-11! I had to tweak the TTY driver to allow 8-bit output... Noel

7 years, 9 months

Why Pascal is Not My Favorite Programming Language - Unearthed!

by arnold＠skeeve.com

Seek and ye shall find. Ask and ye shall receive. Brian Kernighan was kind enough to find for me everyone's favorite Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not My Favorite Programming Language". Attached is the file and his macros. This will not immediately format using groff etc.; I hope to create a version that will, sometime in the next few weeks. In the meantime, Warren, please add to the archives when you are able. Enjoy! Arnold

7 years, 9 months

Follow-on to the Pascal/C/etc. discussion

by Jon Steinhart

Hi everybody. I'm new to this list as a side-effect of my question about the provenance of strcmp and the convention of returning <0, 0, >0. I had to learn Pascal as a freshman in college which was challenging coming from BTL knowing C. Kept wondering how Pascal could be used for anything useful. The answer that I later saw in industry was "by adding non-standard extensions". Language discussions often turn to the issue of whether programming languages should prevent programmers from making mistakes or whether that's the job of the programmer. This is, of course, independent of discussing the expressiveness of languages. I agree that a lot of "programming" today consists of trusting and bolting together random library functions. That's not me; I often work on safety critical devices and I'm not going to rely on libraries of unknown provenance when building a medical device that I make be hooked up to it someday. Years ago I inherited a project written in hodgepodge of programming languages including ruby. My first reaction to ruby was "Wow, how do I get some of what they're smoking because it's better than anything I have?" I eventually asked Ward Cunningham about it because he was working for ruby house AboutUs at the time. His answer went something like this: Jon, you're an engineer and you understand engineering. You know programming and programmers and understand programming. Then, there are the people with whom we entrust our confidential credit card data. That's what ruby is for. This nicely summarized the current state of affairs in which the most critical tasks are assigned to the least competent people. I see this as a management, business, and political problem which can't be solved by different languages. I have often made the statement that "I would never hire someone who had to use glibc in order to implement a singly-linked list." I get push-back such as "Oh, and people can create bugs rather than using the debugged library?" to which I glibly respond "debugged library like OpenSSL?" I am more than a little terrified by the "everybody must learn to code in high school movement". What they're learning is something at a level akin to the ruby example above. The goal is clearly to make "coding" a minimum wage job and to many the distinction between "coding" and engineering is lost. I've spoken with many kids in the "future engineer" category who are frustrated at the lack of depth in the curriculum. I'd summarize it as teaching people to program without teaching them anything about computers. Anyway, I have been volunteering to teach technology to kids for years as karmic payback to my BTL explorer scout advisors Carl Christensen, Heinz Lycklama, and Hans Lie. Not to mention all of the amazing people that I met there when my dedication to hitchhiking up the the Labs after school and talking people into signing me in turned into a series of summer jobs. I'm in the process of turning my class notes into a book. The goal of the book is to teach kids enough about computers that they can understand what their code is actually doing and why one can write better code with an understanding of the hardware and environment. The book is in the editing phase so it's beyond wholesale changes. But I'm curious as to what you all think should be in such a book as I'll find a way to wedge in anything important that I missed. Thanks, Jon

7 years, 9 months

Re: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

by Diomidis Spinellis

And let's not forget Alan Perlis's: "A language that doesn't affect the way you think about programming, is not worth knowing." https://en.m.wikiquote.org/wiki/Alan_Perlis -------- Original message -------- From: Toby Thain Date:02/09/2017 18:00 (GMT+02:00) To: Dan Cross Cc: The Eunuchs Hysterical Society , quad Subject: Re: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed! ... Finally, a favourite quote: "Programs must be written for people to read, and only incidentally for machines to execute" -- Hal Abelson https://twitter.com/old_sound/status/903919515884544000 --Toby > > - Dan C. >

7 years, 9 months

Re: [TUHS] What was the first edition of UNIX that left AT&T

by jnc＠mercury.lcs.mit.edu

> From: "Jeremy C. Reed" > I don't know the key for "v" but maybe means "very distant host" Yes. See: http://mercury.lcs.mit.edu/~jnc/tech/jpg/ARPANet/L77Dec.jpg and look at the MIT-44 IMP (upper right center). It's listed as having a PDP-11, with the /v, and that machine (LL-ASG, 1/44) was definitely on a VDH (it was not in Tech Sq). (A VDH was basically an IMP modem interface hardware-wise, but made to look like a host at a high level within the IMP software.) > He also told me the Unix v6 Arpanet code was from San Diego. Err, he may have gotten it from San Diego, but they didn't write the code, it was written at UIll. See: http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC which contains a copy of the code, which came to me via NOSC in SD. Noel

7 years, 9 months

Re: [TUHS] What was the first edition of UNIX that left AT&T

by Clem cole

I did hear back from Lou Katz - user #1. Indeed the first version that escaped the labs was the 4th edition. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 1, 2017, at 7:16 PM, Clem cole <clemc(a)ccc.com> wrote: > > Interesting. If O'Malley had a connection wonder what it was connected too on both sides. It had to be to lbl but the Vdh was a piece of shit even in the ingvax days. The first version was even worse. On the ucb side I wonder. It would not have been Unix because UofI did the original arpanet code and that was for v6. There was never a pdp10 at ucb so I wonder if it was one of the CDC machines which were the primary systems until Unix came to be. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >>> On Sep 1, 2017, at 5:59 PM, Jeremy C. Reed <reed(a)reedmedia.net> wrote: >>> >>> On Fri, 1 Sep 2017, Clem Cole wrote: >>> >>> So it means that UCB was hacking privately without taking to Katz@ NYU, or >>> the Columbia and Harvard folks for a while. I need to ask Lou what he >>> remembers. UCB was not connected to the Arpanet at this point (Stanford >>> was), so it's possible Ken's sabbatical openned up some channels that had >>> not existed. [UCB does not get connected until ing70 gets the >>> vdh-interface up the hill to LBL's IMP as part of the Ingress project and >>> that was very late in the 70s - not long before I arrived]. >> >> Allman told me that Mike O'Malley had an ARPA connection at UCB that was >> axed a few years before the INGRES link. So yes, I think no Arpanet >> connection during the early BSD development work. (Losing this >> connection may have had some controversy, but I don't know the details.) >> >> Fabry told me that O'Malley used Unix for his (EECS) Artificial >> Intelligence research projects before he discovered it (so before the >> October 1973 Symposium). >> >> RFC 402 of Oct 1972 has a ARPA network participant Michael O'Malley of >> University of Michigan Phonetics Laboratory. Also this draft report at >> http://digitalcollections.library.cmu.edu/awweb/awarchive?type=file&item=35… >> about the ARPA speech recognition project lists M. H. O'Malley at UCB >> and says the principle investigator from Univ. of Michigan moved to UCB. >> (I never go ahold of him to see if had any other relevance to my BSD >> story.) >> >>

7 years, 9 months

What was the first edition of UNIX that left AT&T

by Clem Cole

I was recently asked a question that I was not sure the answer, so I thought I would pass it to this group of folks. What was the first edition that actually left Murray Hill and where did it go? My own first encounter was the Fifth edition but I know that was later. I'm pretty sure both Harvard and MIT had it before CMU. I'm thinking Fourth edition went to Harvard and some other places ??NYU?? ??MIT?? Did anything earlier than Fifth ever leave Murray Hill? I don't think UCB or UofI got it until the Sixth edition. I believe there was some earlier commercial site ??CU in NYC maybe?? may have been in there also but I have no idea what version that was. Doug do you know? Warren any ideas? Tx Clem

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