TUHS

tuhs@tuhs.org

40 participants
6499 discussions

Re: [TUHS] Depraz/Logitech Digimouse manual

by John Floren

I uploaded the high-resolution one to https://jfloren.net/content/unix_skeleton.jpg if anyone wants to check it out in all its glory. Thanks, Rob, this is a great picture. I don't think things were *too* different by the time I visited for IWP9 in 2007, but it's been a long time and I guess I didn't take any pictures then. john ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, August 6th, 2021 at 2:44 PM, Rob Pike <robpike(a)gmail.com> wrote: > I sent a higher-res version in which you can read all the text but it was "moderated". > > This is the Unix room as of the year 2000 or so. > > -rob > > On Sat, Aug 7, 2021 at 4:34 AM ron minnich <rminnich(a)gmail.com> wrote: > >> The story of the mice, one of which I gave to John: >> >> I ran a program called FAST-OS for LANL/Sandia for 6 years starting >> 2005. Think of it as "Plan 9 on petaflop supercomputers" -- it may >> seem strange now, but in that era when some top end systems ran custom >> kernels, there was a strong case to be made that plan 9 was a good >> choice. By 2011, of course, the Linux tsunami had swept all before it, >> which is why you no longer hear about custom HPC kernels so much -- >> though in some places they still reign. In any event, this program >> gave me 6 years to work with "the Unix room", or what was left of it. >> I had been in the Unix Room in 1978, and even met Dennis, so this >> prospect was quite a treat. >> >> We funded Charles Forsyth to write the amd64 compilers for Plan 9, >> which if you used early Go you ran into (6c 6a 6l); we also funded the >> amd64 port of Plan 9 (a.k.a. k10) as well as the port to Blue Gene. >> That amd64 port is still out and about. You can find the Blue Gene >> kernel on github. >> >> I had lots of fun spending time in the Unix room while working with >> the late Jim McKie, and others. I saw the tail end of the traditions. >> They had cookie day once a week, if memory serves, on Thursday at 3. I >> got to see the backwards-running clock, Ken's chess trophies, his >> pilot's license, pictures of Peter everywhere, a "Reagan's view of the >> world" map, the American Legion award for Telstar (which was rescued >> from a dumpster!), and so on. The "Unix room" was more than one room, >> all built on a raised floor, as I assume it was former old school >> machine room space. If memory serves, it filled the entire width of >> the end of the top floor of the building it was in (4th floor?) -- >> maybe 50 ft x 50 ft -- maybe a bit more. There was a room with desks, >> and a similar-sized room with servers, and a smaller room containing a >> lab-style sink, a very professional cappucinno machine, decades of old >> proceedings, and a sofa. I fixed the heavy-duty coffee grinder one >> year; for some reason the Italian company that produced it had seen >> fit to switch BOTH hot and neutral, and the fix was to only switch >> hot, as the neutral switch had failed; I guess in the EU, with 220v, >> things are done differently. >> >> It was fun being there. A few years later the whole room, and all its >> history, was trashed, and replaced with what Jim called a "middle >> management wxx dream" (Jim was never at a loss for words); Jim found >> some yellow Police crime scene tape and placed it in front of the >> doors to the new space. It was redubbed "the innovation space" or some >> such, and looked kind of like an ikea showroom. Much was lost. I tried >> to find a way to save the contents of the room; I had this dream of >> recreating it at Google, much as John Wanamaker's office was preserved >> in Philadelphia for so many decades, but I was too late. I have no >> idea where the contents are now. Maybe next to the Ark. >> >> One day in 2008 or so jmk took me for a tour of the buildings, and we >> at one point ended up high in the top floor of what I think was >> Building One (since torn down?), in what used to be Lab Supply. Nobody >> was there, and not much supply was there either. Finally somebody >> wandered in, and Jim asked where everyone was. "Oh, they closed lab >> supply, maybe 4 years ago?" >> >> Bell Labs had seen hard times since the Lucent split, and it was clear >> it had not quite recovered, and Lab Supply was just one sign of it. I >> think the saddest thing was seeing the visitor center, which I first >> saw in 1976. In 1976, it was the seat of the Bell System Empire, and >> it was huge. There was a map of the US with a light lit for every >> switching office in the Bell Labs system. There was all kinds of Bell >> Labs history in the visitor center museum. >> >> The museum had shrunk to a much smaller area, and felt like a closet. >> The original transistor was still there in 2010, but little else.The >> library was, similarly, changed: it was dark and empty, I was told. >> Money was saved. At that time, Bell Labs felt large, strangely quiet, >> and emptied of people. It made me think of post-sack Rome, ca. 600, >> when its population was estimated to be 500. I have not been back >> since 2011 so maybe things are very different. It would be nice if so. >> >> As part of this tour, Jim gave me 3 depraz mice. I took one, gutted >> it, (sorry!), and filled its guts with a USB mouse innards, and gave >> it back to Jim. He then had a Depraz USB mouse. jmk's mouse did not >> have any lead in it, as John's did, however. The second I gave to >> someone at Google who had worked at the labs back in the day. The >> third mouse I gave to John, and he made it live again, which is cool. >> >> In spite of their reputation, I found Depraz mice hard to use. I have >> gone through all kinds of mice, and am on an evoluent, and as far as >> Depraz go, I guess "you had to be there". I don't recall if jmk used >> his "usb depraz" or it ended up on a shelf. Sadly, I can no longer ask >> him. >> >> I'll be interested to see what John thinks of the Depraz. >> >> ron >> >> On Fri, Aug 6, 2021 at 9:52 AM John Floren <john(a)jfloren.net> wrote: >>> >>> Ah, right. I opened the mouse because one of the encoders didn't seem to be working (it worked fine again this morning, who knows...) and discovered that there was something duct taped inside the plastic shell: >>> >>> http://jfloren.net/content/depraz/inside.jpg >>> >>> Peeling back the tape, I saw what I first took to be chunks of flattened beer cans: >>> >>> http://jfloren.net/content/depraz/reveal.jpg >>> >>> A closer look showed that they were the wrappers which cover the corks of wine bottles. Up into the 1980s, these were made out of lead, and by flattening five of them, a previous owner of the mouse was able to add quite a bit of extra weight to it: >>> >>> http://jfloren.net/content/depraz/wrapper.jpg >>> >>> >>> john >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> >>> On Friday, August 6th, 2021 at 9:34 AM, ron minnich <rminnich(a)gmail.com> wrote: >>> >>> > john, don't forget to mention the beer can >>> > >>> > On Fri, Aug 6, 2021 at 9:29 AM John Floren john(a)jfloren.net wrote: >>> > >>> > > I stuck an Arduino on it and with surprisingly little code I have it acting like a 3-button USB mouse. >>> > > >>> > > The only problem is that the pointer doesn't move smoothly. It does OK left-to-right, and can move down pretty well, but going up is a problem. I think pushing the mouse forward tends to move the ball away from the Y-axis wheel, and the old spring on the tensioner just doesn't have the gumption to hold that heavy ball bearing in any more. >>> > > >>> > > john >>> > > >>> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> > > >>> > > On Wednesday, August 4th, 2021 at 9:12 PM, ron minnich rminnich(a)gmail.com wrote: >>> > > >>> > > > John, you can see that "stick a bird on it" -> "stick an arduino on >>> > > > >>> > > > it" -> "stick a pi on it" has gone as you once predicted :-) >>> > > > >>> > > > On Wed, Aug 4, 2021 at 8:59 PM John Floren john(a)jfloren.net wrote: >>> > > > >>> > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> > > > > >>> > > > > On Wednesday, August 4th, 2021 at 6:12 PM, Henry Bent henry.r.bent(a)gmail.com wrote: >>> > > > > >>> > > > > > On Wed, 4 Aug 2021 at 20:52, John Floren john(a)jfloren.net wrote: >>> > > > > > >>> > > > > > > Having just been given a Depraz mouse, I thought it would be fun to get it working on my modern computer. Since the DE9 connector is male rather than female as you usually see with serial mice, and given its age, I speculate that it might have a custom protocol; in any rate, plugging it into a USB-serial converter and and firing up picocom has given me nothing. >>> > > > > > > >>> > > > > > > Does anyone have a copy of a manual for it, or more information on how to interface with it? If I knew how it was wired and what the protocol looked like, I expect I could make an adapter pretty trivially using a microcontroller. >>> > > > > > >>> > > > > > This might be of some help? >>> > > > > > >>> > > > > > https://www.vcfed.org/forum/forum/technical-support/vintage-computer-hardwa… >>> > > > > > >>> > > > > > -Henry >>> > > > > >>> > > > > This looks great, thank you! >>> > > > > >>> > > > > john

3 years, 9 months

Depraz/Logitech Digimouse manual

by John Floren

Having just been given a Depraz mouse, I thought it would be fun to get it working on my modern computer. Since the DE9 connector is male rather than female as you usually see with serial mice, and given its age, I speculate that it might have a custom protocol; in any rate, plugging it into a USB-serial converter and and firing up picocom has given me nothing. Does anyone have a copy of a manual for it, or more information on how to interface with it? If I knew how it was wired and what the protocol looked like, I expect I could make an adapter pretty trivially using a microcontroller. Thanks, john

3 years, 9 months

Threads vs... not

by Lawrence Stewart

What do folks think about event-driven programming as a substitute for threads in UI and process control settings? I wrote the service processor code for the Sicortex Machines using libevent.a and I thought it was very lightweight and fairly easy to think about. (This was a thing running on ucLinux on a tiny 16 MB coldfire that managed the consoles and power supplies and temp sensors and JTAG access and booting and so forth.) Tk (IIRC) has a straightforward event driven model for UI interactions. Meanwhile, the dropbox plugin for my Mac has 120 threads running. WTF? This was triggered by the fork/spawn discussion. -Larry (started with Unix at V6 on an 11/34)

3 years, 9 months

Systematic approach to command-line interfaces

by Douglas McIlroy

> spawn() beats fork()[;] fork() should be deprecated Spawn is a further complication of exec, which tells what signals and file descriptors to inherit in addition to what arguments and environment variables to pass. Fork has a place. For example, Program 1 in www.cs.dartmouth.edu/~doug/sieve/sieve.pdf forks like crazy and never execs. To use spawn, the program would have to be split in three (or be passed a switch setting). While you may dismiss Program 1 as merely a neat demo, the same idea applies in parallelizing code for use in a multiprocessor world. Doug

3 years, 9 months

Re: [TUHS] Why does refer(1) have no database field for "edition"?.

by Douglas McIlroy

Another issue I have run into is recursion, when a reference includes another reference. This comes up in various forms: Also published as ... Errata available at ... Summarized [or reviewed] in ... Preprint available at ... Often such a reference takes the form of a URL or a page in a journal or in a proceedings. This can be most succinctly placed in situ -- formatted consistently with other references. If the reference identifies an alternate mode of publication, it may lack %A or %T fields. Partial proposal. a %O field may contain a reference, with no further recursion, The contained reference will be formatted in line in the %O text unless references are accumulated and the contained reference is not unique. Doug

3 years, 9 months

Systematic approach to command-line interfaces

by Douglas McIlroy

> Go gets us part of the way there, but cross-machine messaging is still a mess. Shed a tear for Plan 9 (Pike yet again). While many of its secondary innovations have been stuffed into Linux; its animating principle--transparently distributable computing--could not overcome the enormous inertia of installed BSD-model systems. Doug

3 years, 9 months

Re: [TUHS] Systematic approach to command-line interfaces [ meta issues ]

by Douglas McIlroy

I have considerable sympathy with the general idea of formally specifying and parsing inputs. Langsec people make a strong case for doing so. The white paper,"A systematic approach to modern Unix-like command interfaces", proposes to "simplify parsing by facilitating the creation of easy-to-use 'grammar-based' parsers". I'm not clear on what is meant by "parser". A plain parser is a beast that builds a parse tree according to a grammar. For most standard Unix programs, the parse tree has two kinds of leaves: non-options and options with k parameters. Getopt restricts k to {0,1}. Aside from fiddling with argc and argv, I see little difference in working with a parse tree for arguments that could be handled by getopt and working with using getopt directly. A more general parser could handle more elaborate grammatic constraints on options, for example, field specs in sort(1), requirements on presence of options in tar(1), or representation of multiple parameters in cut(1). In realizing the white paper's desire to "have the parser provide the results to the program", it's likely that the mechanism will, like Yacc, go beyond parsing and invoke semantic actions as it identifies tree nodes. Pioneer Yaccification of some commands might be a worthy demo. Doug

3 years, 9 months

Re: [TUHS] Systematic approach to command-line interfaces

by Ron Young

> On 7/31/21, Michael Siegel <msi(a)malbolge.net> wrote: > The TOPS-20 COMND JSYS implemented both of these features, and I think that command > completion was eventually added to the VMS command interpreter, too. FYI, There is also a unix version of the COMND JSYS capability. It was developed at Columbia University as part of their "mm" mail manager. It is located in to the ccmd subdirectory in the mm.tar.gz file. url: https://www.kermitproject.org/mm/ ftp://ftp.kermitproject.org/kermit/mm/mm.tar.gz -ron

3 years, 9 months

Re: [TUHS] Systematic approach to command-line interfaces

by Nelson H. F. Beebe

Besides C-Kermit on Unix systems, the TOPS-20 command interface is used inside the mm mail client, which I've been using for decades on TOPS-20, VMS, and several flavors of Unix: http://www.math.utah.edu/pub/mm mm doesn't handle attachments, or do fancy display of HTML, and thus, cannot do anything nasty in response to incoming mail messages. I rarely need to extract an attachment, and I then save the message in a temporary file and run munpack on it. Here are some small snippets of its inline help: MM] read (messages) ? message number or range of message numbers, n:m or range of message numbers, n-m or range of message numbers, n+m (m messages beginning with n) or "." to specify the current message or "*" to specify the last message or message sequence, one of the following: after all answered before current deleted flagged from inverse keyword last longer new on previous-sequence recent seen shorter since subject text to unanswered undeleted unflagged unkeyword unseen or "," and another message sequence R] read (messages) flagged since yesterday [message(s) appear here] MM] headers (messages) since monday longer (than) 100000 [list of long messages here] ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

3 years, 9 months

Re: [TUHS] Latex-Style Equations in Troff

by Douglas McIlroy

That's a neat tool. It would be nice to have the inverse tool, too; it's painful to do by hand. Doug

3 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