TUHS

tuhs@tuhs.org

47 participants
6502 discussions

by arnold＠skeeve.com

This is FYI. No comment on whether it was a good idea or not. :-) Arnold > From: Niklas Rosencrantz <niklasro(a)gmail.com> > Date: Sun, 19 Sep 2021 17:10:24 +0200 > To: tinycc-devel(a)nongnu.org > Subject: Re: [Tinycc-devel] Can tcc compile itself with Apple M1? > > > Hello! > > For demonstration purpose I put my experiment with a compiler backdoor in a > public repository > https://github.com/montao/ddc-tinyc/blob/857d927363e9c9aaa713bb20adbe99ded7… > > It's part of my academic project to work on provable compiler security. > I tried to do it according to the "Reflections on Trusting Trust" by Ken > Thompson, not only to show a compiler Trojan horse but also to prove that > we can discover it. > What it does is inject arbitrary code to the next version of the compiler > and so on. > > Regards \n

3 years, 8 months

ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe)

by Dan Cross

One of the things I really appreciate about participating in this community and studying Unix history (and the history of other systems) is that it gives one firm intellectual ground from which to evaluate where one is going: without understanding where one is and where one has been, it's difficult to assert that one isn't going sideways or completely backwards. Maybe either of those outcomes is appropriate at times (paradigms shift; we make mistakes; etc) but generally we want to be moving mostly forward. The danger when immersing ourselves in history, where we must consider and appreciate the set of problems that created the evolutionary paths leading to the systems we are studying, is that our thinking can become calcified in assuming that those systems continue to meet the needs of the problems of today. It is therefore always important to reevaluate our base assumptions in light of either disconfirming evidence or (in our specific case) changing environments. To that end, I found Timothy Roscoe's (ETH) joint keynote address at ATC/OSDI'21 particularly compelling. He argues that what we consider the "operating system" is only controlling a fraction of a modern computer these days, and that in many ways our models for what we consider "the computer" are outdated and incomplete, resulting in systems that are artificially constrained, insecure, and with separate components that do not consider each other and therefore frequently conflict. Further, hardware is ossifying around the need to present a system interface that can be controlled by something like Linux (used as a proxy more generally for a Unix-like operating system), simultaneously broadening the divide and making it ever more entrenched. Another theme in the presentation is that, to the limited extent the broader systems research community is actually approaching OS topics at all, it is focusing almost exclusively on Linux in lieu of new, novel systems; where non-Linux systems are featured (something like 3 accepted papers between SOSP and OSDI in the last two years out of $n$), the described systems are largely Linux-like. Here the presentation reminded me of Rob Pike's "Systems Software Research is Irrelevant" talk (slides of which are available in various places, though I know of no recording of that talk). Roscoe's challenge is that all of this should be seen as both a challenge and an opportunity for new research into operating systems specifically: what would it look like to take a holistic approach towards the hardware when architecting a new system to drive all this hardware? We have new tools that can make this tractable, so why don't we do it? Part of it is bias, but part of it is that we've lost sight of the larger picture. My own question is, have we become entrenched in the world of systems that are "good enough"? Things he does NOT mention are system interfaces to userspace software; he doesn't seem to have any quibbles with, say, the Linux system call interface, the process model, etc. He's mostly talking about taking into account the hardware. Also, in fairness, his highlighting a "small" portion of the system and saying, "that's what the OS drives!" sort of reminds me of the US voter maps that show vast tracts of largely unpopulated land colored a certain shade as having voted for a particular candidate, without normalizing for population (land doesn't vote, people do, though in the US there is a relationship between how these things impact the overall election for, say, the presidency). I'm curious about other peoples' thoughts on the talk and the overall topic? https://www.youtube.com/watch?v=36myc8wQhLo - Dan C.

3 years, 8 months

RegExp decision for meta characters: Circumflex

by Douglas McIlroy

> Maybe there existed RE notations that were simply copied ... Ed was derived from Ken's earlier qed. Qed's descendant in Multics was described in a 1969 GE document: http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condens…. Unfortunately it describes regular expressions only sketchily by example. However, alternation, symbolized by | with grouping by parentheses, was supported in qed, whereas alternation was omitted from ed. The GE document does not mention character classes; an example shows how to use alternation for the same purpose. Beginning-of-line is specified by a logical-negation symbol. In apparent contradiction, the v1 manual says the meanings of [ and ^ are the same in ed and (an unspecified version of) qed. My guess about the discrepancies is no better than yours. (I am amused by the title "condensed guide" for a manual in which each qed request gets a full page of explanation. It exemplifies how Unix split from Multics in matters of taste.) Doug

3 years, 8 months

Re: [TUHS] Unix for PDP11/20 w/o mmu or paging option

by jnc＠mercury.lcs.mit.edu

> From: Roland Huisman > I have a PDP11/20 and I would love to run an early Unix version on > it. ... But it seems that the earliest versions of Unix do not need the > extra memory. Does anyone have RK05 disk images for these early Unix > versions? Although the _kernel_ source for V1 is available: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1 most of the rest is missing; only 'init' and 'sh' are available. So one would have to write almost _everything_ else. Some commands are available in PDP-11 assembler in later versions, and might be movable without _too_ much work - but one would have to start with the assembler itself, which is luckily in assembler. If I were trying to run 'UNIX' on an -11/20, I think the only reasonable choice would be MINI-UNIX: https://gunkies.org/wiki/MINI-UNIX It's basically V6 UNIX with all use of the PDP-11 memory management removed. The advantage of going MINI-UNIX is that almost all V6 source (applications, drivers, etc) will run on it 'as is'. It does need ~56KB of main memory. If you don't have that much on the -11/20, LSX (links in the above) would be an option; it's very similar to MINI-UNIX, but is trimmed down some, to allow its use on systems with less main memory. I'm not sure if MINI-UNIX has been run on the -11/20, but it _should_ run there; it runs on the -11/05, and the only differences between the /20 and the /05 are that the /20 does not have the RTT instruction (and I just checked, and MINI-UNIX doesn't use RTT), and SWAB doesn't clear the V condition code bit. (There are other minor differences, such as OP Rn, (Rn)+ are different on the -11/20, but that shouldn't be an issue.) Step 1 would be to get MINI-UNIX running on an -11/20 under a simulator; links in the above to get you there. Noel

3 years, 8 months

Re: [TUHS] Unix for PDP11/20 w/o mmu or paging option

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The KS11 MMU for the 11/20 was built by CSS ... I think Noel has done > more investigation than I have. I got a very rough description of how it worked, but that was about it. > I'm not sure if the KS11 code is still there. I did not think so. No, the KS11 was long gone by later Vn. Also,I think not all of the -11/20 UNIX machines had it, just some. > The V1 work was for a PDP-7 Actually, there is a PDP-11 version prior to V2, canonically called V1. The PDP-7 version seems to be called 'PDP-7 UNIX' or 'V0'. > I'm fairly sure that the RK05, used the RK11-D controller. Normally, yes. I have the impression that one could finagle RK03's to work on the RK11-D, and vice versa for RK05's on the RK11-C, but I don't recall the details. The main difference between the RK11-C and -D (other then the implementation) was that i) the RK11-C used one line per drive for drive selection (the -D used binary encoding on 3 lines), and ii) it had the 'maintenance' capability and register (al omitted from the -D). > The difference seems to have been in drive performance. Yes, but it wasn't major. They both did 1500RPM, so since they used the same pack format, the rotational delay, transfer rate, etc were identical. The one peformance difference was in seeks; the average on the RK01 was quoted as 70 msec, and 50 msec on the RK05. > Love to see the {KT11-B prints] and if you know where you found them. They were sold on eBait along with an -11/20 that allegedly had a KT11-B. (It didn't; it was an RK11-C.) I managed to get them scanned, and they and the minimal manual are now in Bitsavers. I started working on a Tech Manual for it, but gave up with it about half-way done. > I wonder if [our V1 source] had the KS-11 stuff in it. No; I had that idea a while back, looked carefully, our V1 listings pre-date the KS11. > From: Roland Huisman > There is a KT11B paging option that makes the PDP11/20 a 18 bit > machine. Well, it allows 2^18 bytes of main memory, but the address space of the CPU is still2^16 bytes. > It looks a bit like the TC11 DECtape controller. IITC, it's two backplanes high, the TC11 is one. So more like the RK11-C... :-) > I have no idea how it compares to the later MMU units from the > software perspective. Totally different; it's real paging (with page tables stored in masin memory). The KT11-B provides up to 128 pages of 512 bytes each, in both Exec and User mode. The KT11-C, -D etc are all segmentation, with all the info stored in registers in the unit. > I wonder is there is some compatibility with the KT11-B [from the KS11] I got the impression that the KS11 was more a 'base and bounds' kind of thing. Noel

3 years, 8 months

Unix for PDP11/20 w/o mmu or paging option

by Roland

Hello Unix fanatics, I have a PDP11/20 and I would love to run an early Unix version on it. I've been working on the hardware for a while and I'm getting more and more of the pieces back online again. The configuration will be two RK05 hard disks, TU56H tape, PC11 paper tape reader/puncher and a RX01 floppy drive. Unfortunately I don't have a MMU or paging option. But it seems that the earliest versions of Unix do not need the extra memory. Does anyone have RK05 disk images for these early Unix versions? That would be a great help. Otherwise it would be great to have some input about how to create a bootable Unix pack for this machine. A bit about the hardware restoring is on the vcfed forum:https://www.vcfed.org/forum/forum/genres/dec/78961-rk05-disk-drive-ve… Booting RT11 from RK05https://youtu.be/k0tiUcRBPQATU56H tape drive back onlinehttps://youtu.be/_ZJK3QP9gRA Thanks in advance!Roland Huisman

3 years, 8 months

RegExp decision for meta characters: Circumflex

by markus schnalke

Hoi, I'm interested in the early design decisions for meta characters in REs, mainly regarding Ken's RE implementation in ed. Two questions: 1) Circumflex As far as I see, the circumflex (^) is the only meta character that has two different special meanings in REs: First being the beginning of line anchor and second inverting a character class. Why was it chosen for the second one? Why not the exclamation mark in that case? (Sure, C didn't exist by then, but the bang probably was used to negate in other languages of the time, I think.) 2) Symbol for the end of line anchor What is the reason that the beginning of line and end of line anchors are different symbols? Is there a reason why not only one symbol, say the circumflex, was chosen to represent both? I currently see no disadvantages of such a design. (Circumflexes aren't likely to end lines of text, neither.) I would appreciate if you could help me understand these design decisions better. Maybe there existed RE notations that were simply copied ... meillo

3 years, 8 months

Re: [TUHS] desiderata

by Douglas McIlroy

You can check the Computer History Museum's holdings on line. If they don't have the documents already, they would probably like them. The Living Computer Museum in Seattle had a working blit on display. If they don't already have the manual, I'm sure they would love to have one. Alas, their website says they've "suspended all operations for now", a result of the double whammy of Covid and the death of their principal angel, Paul Allen.

3 years, 8 months

desiderata

by Andrew Hume

more garage cleaning this last weekend. i came across some memorabilia from my time at Bell Labs, including a lovely article titled The Electrical Properties of Infants Infants have long been known to grow into adults. Recent experiments show they are useful in applications such as high power circuit breakers. Not to mention a lovely article from the “Medical Aspects of Human Sexuality” (July 1991) titled “Scrotum Self-Repair”. the two items are 1) “Documents for UNIX Volume 1” by Dolotta, Olson and Petrucelli (jan 1981)” 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes the full manual (including man pages) and circuit diagrams. i’d prefer to have them go to some archival place, but send me a private email if you interested and we’ll see what we can do. andrew

3 years, 8 months

desiderata

by Paul Ruizendaal

I’d be interested in a scan of the Blit schematics, and it seems that a few others might be as well: https://minnie.tuhs.org/pipermail/tuhs/2019-December/thread.html#19652 https://github.com/aiju/fpga-blit (for clarity: I’m not ‘aiju') Paul > Message: 1 > Date: Wed, 8 Sep 2021 01:29:13 -0700 > From: Andrew Hume <andrew(a)humeweb.com> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] desiderata > Message-ID: <34E984D3-AD92-402D-9A9C-E84B6362DF77(a)humeweb.com> > Content-Type: text/plain; charset=utf-8 > > more garage cleaning this last weekend. [...] > 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes > the full manual (including man pages) and circuit diagrams. > > i’d prefer to have them go to some archival place, but send me a private email > if you interested and we’ll see what we can do. > > andrew

3 years, 8 months

Is it time to resurrect the original dsw (delete with switches)?

by Jon Steinhart

I recently upgraded my machines to fc34. I just did a stock uncomplicated installation using the defaults and it failed miserably. Fc34 uses btrfs as the default filesystem so I thought that I'd give it a try. I was especially interested in the automatic checksumming because the majority of my storage is large media files and I worry about bit rot in seldom used files. I have been keeping a separate database of file hashes and in theory btrfs would make that automatic and transparent. I have 32T of disk on my system, so it took a long time to convert everything over. A few weeks after I did this I went to unload my camera and couldn't because the filesystem that holds my photos was mounted read-only. WTF? I didn't do that. After a bit of poking around I discovered that btrfs SILENTLY remounted the filesystem because it had errors. Sure, it put something in a log file, but I don't spend all day surfing logs for things that shouldn't be going wrong. Maybe my expectation that filesystems just work is antiquated. This was on a brand new 16T drive, so I didn't think that it was worth the month that it would take to run the badblocks program which doesn't really scale to modern disk sizes. Besides, SMART said that it was fine. Although it's been discredited by some, I'm still a believer in "stop and fsck" policing of disk drives. Unmounted the filesystem and ran fsck to discover that btrfs had to do its own thing. No idea why; I guess some think that incompatibility is a good thing. Ran "btrfs check" which reported errors in the filesystem but was otherwise useless BECAUSE IT DIDN'T FIX ANYTHING. What good is knowing that the filesystem has errors if you can't fix them? Near the top of the manual page it says: Warning Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume. Whoa! I'm sure that operators are standing by, call 1-800-FIX-BTRFS. Really? Is a ploy by the developers to form a support business? Later on, the manual page says: DANGEROUS OPTIONS --repair enable the repair mode and attempt to fix problems where possible Note there’s a warning and 10 second delay when this option is run without --force to give users a chance to think twice before running repair, the warnings in documentation have shown to be insufficient Since when is it dangerous to repair a filesystem? That's a new one to me. Having no option other than not being able to use the disk, I ran btrfs check with the --repair option. It crashed. Lesson so far is that trusting my data to an unreliable unrepairable filesystem is not a good idea. Since this was one of my media disks I just rebuilt it using ext4. Last week I was working away and tried to write out a file to discover that /home and /root had become read-only. Charming. Tried rebooting, but couldn't since btrfs filesystems aren't checked and repaired. Plugged in a flash drive with a live version, managed to successfully run --repair, and rebooted. Lasted about 15 minutes before flipping back to read only with the same error. Time to suck it up and revert. Started a clean reinstall. Got stuck because it crashed during disk setup with anaconda giving me a completely useless big python stack trace. Eventually figured out that it was unable to delete the btrfs filesystem that had errors so it just crashed instead. Wiped it using dd; nice that some reliable tools still survive. Finished the installation and am back up and running. Any of the rest of you have any experiences with btrfs? I'm sure that it works fine at large companies that can afford a team of disk babysitters. What benefits does btrfs provide that other filesystem formats such as ext4 and ZFS don't? Is it just a continuation of the "we have to do everything ourselves and under no circumstances use anything that came from the BSD world" mentality? So what's the future for filesystem repair? Does it look like the past? Is Ken's original need for dsw going to rise from the dead? In my limited experience btrfs is a BiTteR FileSystem to swallow. Or, as Saturday Night Live might put it: And now, linux, starring the not ready for prime time filesystem. Seems like something that's been under development for around 15 years should be in better shape. Jon

3 years, 8 months

Who said ...

by arnold＠skeeve.com

... DEC Diagnositcs would run on a beached whale ? Anyone remember and/or know? (It seems to apply to other manufacturer's diagnostics as well, even today.) Thanks, Arnold

3 years, 8 months

A language question

by Richard Salz

I hope that this does not start any kind of language flaming and that if something starts the moderator will shut it down quickly. Where did the name for abort(3) and SIGABRT come from? I believe it was derived from the IBM term ABEND, but would like to know one way or the other.

3 years, 8 months

Re: [TUHS] Who said ...

by norman＠oclsc.org

Clem Cole: I believe the line was: *"running **DEC Diagnostics is like kicking a dead whale down the beach.*" As for who said it, I'm not sure, but I think it was someone like Rob Kolstad or Henry Spencer. ===== The nearest I can remember encountering before was a somewhat different quote, attributed to Steve Johnson: Running TSO is like kicking a dead whale down the beach. Since scj is on this list, maybe he can confirm that part. I don't remember hearing it applied to diagnostics. I can imagine someone saying it, because DEC's hardware diags were written by hardware people, not software people; they required a somewhat arcane configuration language, one that made more sense if you understood how the different pieces of hardware connected together. I learned to work with it and found it no less usable than, say, the clunky verbose command languages of DEC's operating systems; but I have always preferred to think in low levels. DEC's diags were far from perfect, but they were a hell of a lot better than the largely-nonexistent diags available for modern Intel-architecture systems. I am right now dealing with a system that has an intermittent fault, that causes the OS to crash in the middle of some device driver every so often. Other identical systems don't, so I don't think it's software. Were it a PDP-11 or a VAX I'd fire up the diagnostics for a while, and have at least a chance of spotting the problem; today, memtest is about the only such option, and a solid week of running memtest didn't shake out anything (reasonably enough, who says it's a memory problem?). Give me XXDP, not just the Blue Screen of Death. Norman Wilson Toronto ON

3 years, 8 months

Re: [TUHS] Is it time to resurrect the original dsw (delete with switches)?

by norman＠oclsc.org

Not to get into what is soemthing of a religious war, but this was the paper that convinced me that silent data corruption in storage is worth thinking about: http://www.cs.toronto.edu/~bianca/papers/fast08.pdf A key point is that the character of the errors they found suggests it's not just the disks one ought to worry about, but all the hardware and software (much of the latter inside disks and storage controllers and the like) in the storage stack. I had heard anecdotes long before (e.g. from Andrew Hume) suggesting silent data corruption had become prominent enough to matter, but this paper was the first real study I came across. I have used ZFS for my home file server for more than a decade; presently on an antique version of Solaris, but I hope to migrate to OpenZFS on a newer OS and hardware. So far as I can tell ZFS in old Solaris is quite stable and reliable. As Ted has said, there are philosophical reasons why some prefer to avoid it, but if you don't subscribe to those it's a fine answer. I've been hearing anecdotes since forever about sharp edges lurking here and there in BtrFS. It does seem to be eternally unready for production use if you really care about your data. It's all anecdotes so I don't know how seriously to take it, but since I'm comfortable with ZFS I don't worry about it. Norman Wilson Toronto ON PS: Disclosure: I work in the same (large) CS department as Bianca Schroeder, and admire her work in general, though the paper cited above was my first taste of it.

3 years, 8 months

Re: [TUHS] Can't break line warning

by Douglas McIlroy

This may be due to logic similar to that of a classic feature that I always deemed a bug: troff begins a new page when the current page is exactly filled, rather than waiting until forced by content that doesn't fit. If this condition happens at the end of a document, a spurious blank page results. Worse, if the page header happens to change just after the exactly filled page, the old heading will be produced before the new heading is read. Doug

3 years, 9 months

Systematic approach to command-line interfaces

by Douglas McIlroy

> fork() is a great model for a single-threaded text processing pipeline to do > automated typesetting. (More generally, anything that is a straightforward > composition of filter/transform stages.) Which is, y'know, what Unix is *for*. > It's not so great for a responsive GUI in front of a multi-function interactive program. "Single-threaded" is not a term I would apply to multiple processes in a pipeline. If you mean a single track of data flow, fine, but the fact that that's a prevalent configuration of cooperating processes in Unix is an artifact of shell syntax, not an inherent property of pipe-style IPC. The cooperating processes in Rob Pike's 20th century window systems and screen editors, for example, worked smoothly without interrupts or events - only stream connections. I see no abstract distinction between these programs and "stuff people play with on their phones." It bears repeating, too, that stream connections are much easier to reason about than asynchronous communication. Thus code built on streams is far less vulnerable to timing bugs. At last a prince has come to awaken the sleeping beauty of stream connections. In Go (Pike again) we have a widely accepted programming language that can fully exploit them, "[w]hich is, y'know, what Unix is 'for'." (If you wish, you may read "process" above to include threads, but I'll stay out of that.) Doug

3 years, 9 months

Who is that in the framed photograph near the ceiling?

by norman＠oclsc.org

Steve Simon: once again i am taken aback at the good taste of the residents of the unix room. As a whilom denizen of that esteemed playroom, I question both the accuracy and the relevance of that metric. Besides, what happened to the sheep shelf? Was it scrubbed away after I left? And, Ken, whatever happened to Dolly the Sheep (after she was hidden to avoid upsetting visitors)? Norman Wilson Toronto ON No longer a subscriber to sheep! magazine

3 years, 9 months

Who is that in the framed photograph near the ceiling?

by Steve Simon

great picture. once again i am taken aback at the good taste of the residents of the unix room. -Steve

3 years, 9 months

Who is that in the framed photograph near the ceiling?

by William Cheswick

> I don't think anyone knows. Nobody relevant, I believe. > > -rob I understand that Dave Presotto bought that photo at a garage sale for $1. The photo hung in the Unix Room for years, at one point labeled “Peter Weinberger.” One day I removed it from its careful mounting and scanned in the photo. It bore the label “what, no steak?” The photo was stolen from a wall sometime after I left. The scanned image is at https://cheswick.com/ches/tmp/whatnosteak.jpeg ches

3 years, 9 months

Re: [TUHS] Depraz/Logitech Digimouse manual

by John Foust

At 07:24 PM 8/6/2021, Rob Pike wrote: >I don't think anyone knows. Nobody relevant, I believe. Indeed, a clipped and cleaned version in reverse image search on Google, Bing, Tineye and Yandex found nothing. Feels like a head shot for a theater major. - John

3 years, 9 months

Re: [TUHS] Depraz/Logitech Digimouse manual

by Rob Pike

I sent a picture (actually two at different resolutions; keep reading) to the list, but being images they are larger than the address space of a PDP-11 so not allowed here. Is it really necessary to have such a low message size limit in an era when I can buy a terabyte of storage for less than a hundred bucks? Here is a Google Drive link, for the adventurous. 20180123-UnixSkeleton.jpg <https://drive.google.com/file/d/1aS8ZmzwPUawIa8WXGoXOK9jDiYtJETGG/view?usp=…> -rob On Sat, Aug 7, 2021 at 7:44 AM 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

Re: [TUHS] Depraz/Logitech Digimouse manual

by norman＠oclsc.org

The mouse with wine-bottle lead foil in the top may have been my fault. I did that to two of them--at home and in my office--because I found a little more pressure made the ball track better. I've never been an alcohol-consumer; the lead came from a friend, who used to save it (back in the 1980s) to mail to Republicans. Apparently he had, many years before, registered to vote in a Republican primary solely to oppose a particularly-poor candidate. That somehow got him on a GOP mailing list that sent him endless funding appeals with post-paid envelopes. He used to fill the envelopes with lead and drop them in the mail, in the hope that he would cost the party even more in excess postage than they were already spending to send the funding pitches. By the time I was at Bell Labs, he had moved to Canada, and was no longer receiving unwanted political funding pitches, but he was glad to save a few bits of lead for me when I thought of the trick and asked him. Only too glad, it turned out; he kept saving it and saving it and saving it even though I neither needed nor wanted any more. Eventually I managed to get the message through to him. He has since moved back to the US. He is still fond of wine. I don't know what he does with the cork wrappers. Norman Wilson Toronto ON

3 years, 9 months

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

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