TUHS

tuhs@tuhs.org

12 participants
6534 discussions

Fwd: Message from the family of Bram Moolenaar

by Steffen Nurpmeso

I do not know whether it is right, and i am surely not the right person to mourn in public, but i wanted to forward this. I only spoke to him once, he mailed me in private, but i could not help him supporting Uganda, even though i admired what he was doing, and often looked. Local capacity building, and (mutual) respect for local culture and practice, despite all sharp spikes and edges the storm causes over time, that is surely the way to do it right. --- Forwarded from Bram Moolenaar <Bram(a)Moolenaar.net> --- Sender: vim_announce(a)googlegroups.com To: vim_announce(a)googlegroups.com Subject: Message from the family of Bram Moolenaar Message-Id: <20230805121930.4AA8F1C0A68(a)moolenaar.net> Date: Sat, 5 Aug 2023 13:19:30 +0100 (WEST) From: Bram Moolenaar <Bram(a)Moolenaar.net> Reply-To: vim_announce(a)googlegroups.com List-ID: <vim_announce.googlegroups.com> Dear all, It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023. Bram was suffering from a medical condition that progressed quickly over the last few weeks. Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of. We as family are now arranging the funeral service of Bram which will take place in The Netherlands and will be held in the Dutch lanuage. The extact date, time and place are still to be determined. Should you wish to attend his funeral then please send a message to funeralbram(a)gmail.com. This email address can also be used to get in contact with the family regarding other matters, bearing in the mind the situation we are in right now as family. With kind regards, The family of Bram Moolenaar -- -- You received this message from the "vim_announce" maillist. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_announce+unsubscribe(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_announce/20230805121930.4AA8F1C0A68%4…. -- End forward <20230805121930.4AA8F1C0A68(a)moolenaar.net> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 year, 11 months

Re: Cool talk on Unix and Sendmail history, by Eric Allman

by norman＠oclsc.org

Doug McIlroy: This reminds me of how I agonized over Mike Lesk's refusal to remove remote execution from uucp. ==== Uux, the remote-execution mechanism I remember from uucp, had rather better utility than the famous Sendmail back-door: it was how uucp carried mail, by sending a file to be handed to mailer on the remote system. It was clearly dangerous if the remote site accepted any command, but as shipped in V7 only a short list of remote commands was allowed: mail rmail lpr opr fsend fget. (As uucp was used to carry other things like netnews, the list was later extended by individual sites, and eventually moved to a file so reconfiguration needn't recapitulate compilation). Not the safest of mechanisms, but at least in V7 it had a use other than Mike fixing your system for you. Is there some additional history here? e.g. was the list of permitted commands added after arguments about safety, or some magic command that let Mike in removed? Or was there a different remote-execution back door I don't remember and don't see in a quick look at uuxqt.c? Norman Wilson Toronto ON

1 year, 11 months

Re: emacs

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > when did emacs arrive in unix and was it a full fledged text editor > when it came or was it sitting on top of some other subssystem Montgomery Emacs was the first I knew of; it started on PDP-11 UNIX. According to: https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Montgomery… Montgomery Emacs started in 1980 or so; here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/emacs/emacs.doc is a manual from May, 1981. It had pretty full EMACS functionality, but the editor was not written in an implementation language of any kind (like the original, and like much later GNU Emacs); it was written in C. It did have macros for extensions, but they were written in Emacs commands, so, like the TECO that the original was written in, their source looks kind of like line noise. (Does anyone young even know what line noise looks like any more? I feel so old - and I'm a youngster compared to McIlroy!) > Was TECO ever on unix? I don't think it was widespread, but there was a TECO on the PDP-11 UNIXes at MIT; until Montgomery Emacs arrived, it was the primary editor used on those machines. Not that most people used TECO commands for editing; early on, they added '^R mode' to the UNIX TECO, similar to the one on ITS TECO, and a macro package was written for it (in TECO - so again, the source looks like line noise); the command set was like a stripped down EMACS - about a dozen command characters total; see the table about a page down here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/help All the source, and documentation, such as it is, it available, here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/ but don't even think about running it. It's written in MACRO-11, and it used a version of that hacked at MIT to run on UNIX. To build new versions of that, you need a special linker - written in BCPL. So you also need the UNIX BCPL compiler. Noel

1 year, 11 months

Re: emacs

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > There was a guy in production at Google using Unix TECO as his main > editor when I joined in 2002. Do you happen to know which version it was, or what it was written in? It must have been _somebody_'s re-implementation, but I wonder who or where (or why :-). Noel

1 year, 11 months

Re: [COFF] Re: What Happened to Interdata?

by segaloco

Steve thank you for the recollections, that is precisely the sort of story I was hoping to hear regarding your Interdata work. I had found myself quite curious why it would have wound up on a shelf after the work involved, and that makes total sense. That's a shame too, it sounds like the 8/32 could've picked up quite some steam, especially beating the VAX to the punch as a UNIX platform. But hey, it's a good thing so much else precipitated from your work! Also, those sorts of microarchitectural bugs keep me up at night. For all the good in RISC-V there are also now maaaaany fabs with more license than ever to pump out questionable ICs. Combine that with questionable boards with strange bus architectures, and gee our present time sure does present ripe opportunities to experiment with tackling those sorts of problems in software. Can't say I've had the pleasure but it would be nice to still be able to fix stuff with a wire wrap in the field... - Matt G. P.S. TUHS cc as promised, certainly relevant information re: Interdata 8/32 UNIX. ------- Original Message ------- On Friday, August 4th, 2023 at 6:17 PM, scj(a)yaccman.com <scj(a)yaccman.com> wrote: > Sorry for the year's delay in responding... I wrote the compiler for the Interdata, and Dennis and I did much of the debugging. The Interdata had much easier addressing for storage: the IBM machine made you load a register, and then you had a limited offset from that register that you could use. I think IBM was 10 bits, maybe 12. But all of it way too small to run megabyte-sized programs. The Interdata allowed a larger memory offset and pretty well eliminated the offsets as a problem. I seem to recall some muttering from Dennis and Ken about the I/O structure, which was apparently somewhat strange but much less weird than the IBM. > > Also, IBM and Interdata were big-endian, and the PDP was little-endian. This gave Dennis and Ken some problems since it was easy to get the wrong endian, which blew gaskets when executed or copied into the file system. Eventually, we got the machine running, and it was quite nice: true 32-bit computing, it was reasonably fast, and once we got the low-level quirks out (including a famous run-in with the "you are not expected to understand this" code in the kernel, which, it turned out, was a prophecy that came true. On the whole, the project was so successful that we set up a high-level meeting with Interdata to demo and discuss cooperation. And then "the bug" hit. The machine would be running fine, and then Blam! it has lept into low memory and aborted with no hint as to what or where the fault was. > > We finally tracked down the problem. The Interdata was a microcode machine. And older Unix system calls would return -1 if they failed. In V7, we fixed this to return 0, but there was still a lot of user code that used the old convention. When the Interdata saw a request to load -1 it first noticed that the integer load was not on an address divisible by 4, and jumped to a location in the microcode and executed a couple of microinstructions. But then it also noticed that the address was out of range and entered the microcode again, overwriting the original address that caused the problem and freezing the machine with no indication of where the problem was. It took us only a day or two to see what the problem was, and it was hardware, and they would need to fix it. We had our meeting with Interdata, gave a pretty good sales pitch on Unix, and then said that the bug we had found was fatal and needed to be fixed or the deal was off. The bottom line, they didn't want to fix the bug in the hardware. They did come out with a Unix port several years later, but I was out of the loop for that one, and the Vax (with the UCB paging code) had become the machine of choice... > > --- > > On 2023-07-25 16:23, segaloco via COFF wrote: > >> So I've been studying the Interdata 32-bit machines a bit more closely lately and I'm wondering if someone who was there at the time has the scoop on what happened to them. The Wikipedia article gives some good info on their history but not really anything about, say, failed follow-ons that tanked their market, significant reasons for avoidance, or anything like that. I also find myself wondering why Bell didn't do anything with the Interdata work after springboarding further portability efforts while several other little streams, even those unreleased like the S/370 and 8086 ports seemed to stick around internally for longer. Were Interdata machines problematic in some sort of way, or was it merely fate, with more popular minis from DEC simply spacing them out of the market? Part of my interest too comes from what influence the legacy of Interdata may have had on Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several times in the chemistry-side of my career and am curious if I was ever operating some vague descendent of Interdata designs in the embedded controllers in say one of my mass specs back when. >> >> - Matt G. >> >> P.S. Looking for more general history hence COFF, but towards a more UNIXy end, if there's any sort of missing scoop on the life and times of the Bell Interdata 8/32 port, for instance, whether it ever saw literally any production use in the System or was only ever on the machines being used for the portability work, I'm sure that could benefit from a CC to TUHS if that history winds up in this thread.

1 year, 11 months

Re: python

by Douglas McIlroy

> Most of the time I'd rather not have to care whether the thing > I'm printing is a string, or a pointer, or an integer, or whatever: > I just want to see its value. > Go has %v for exactly this. It's very nice for debugging. Why so verbose? In Basic, PRINT required no formatting directives at all. Doug

1 year, 11 months

Re: Split addressing (I/D) space (inspired by the death of the python... thread)

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > first two subsystems for the 11 that ran out of text space were indeed > vi and Pascal subsystems Those were at Berkeley. We've established that S-I&D were in V6 when it was released in May, 1975 - so my question is 'what was Bell doing in 1975 that needed more than 64KB?' The kernel, yeah, it could definitely use S-I&D on a larger system (especially when you remember that stock V6 didn't play any tricks with overlays, and also dedicated one segment - the correct term, used in the 1972 -11/45 processor manual - to the user structure, and one to the I/O page, limiting the non-S-I&D kernel to 48KB). But what user commands? It happens that I have a complete dump of one of the MIT systems, so I had a look to see what _we_ were running S-I&D on. Here's the list from /bin (for some reason that machine doesn't have a /usr/bin): a68 a86 c86 emacs lisp ndd send teco The lisp wasn't a serious use; I think the only thing we ever used it for was 'doctor'. So, two editors, a couple of language tools, an email tool (not sure why that one got it - maybe for creating large outgoing messages). (The ndd is probably to allow the biggest possible buffers.) Nothing in /etc, and in /lib, just lint1 and lint2 (lint, AFAICT, post-dates V6). Not a lot. So now I'm really curious what Bell was using S-I&D for. (If I weren't lazy, I'd pull the V6 distro - which is only available as RK images, and individual files, alas - and look in /bin and everywhere and see if I can find anything. I suspect not, though.) Anyone have any guesses/suggestions? Maybe some custom applications? Noel

1 year, 11 months

Re: python

by jnc＠mercury.lcs.mit.edu

How is discussing Python's output options related to the history of Unix? Noel

1 year, 11 months

SVR2 on the PDP-11? SVR3?

by segaloco

Does anyone know if there are any surviving examples of SVR2 for the PDP-11? Various SVR2 manuals still make mention of the assembler, linker, etc. and the pdp11 variable is present in machid(1)*. And on the note of the later years of the PDP-11, was there any hope for SVR3 on the PDP? I presume the introduction of demand paging was the end of things but I would be curious for anyone's recollections on the final years of System V on the PDP-11. - Matt G. P.S. *interesting little 3B5 side note, found as I was checking references that machid(1) in the "System V" branded manual from the initial System V commercial release mentions the pdp11, vax, and u3b machines, the latter being the 3B20S. However, the "Release 5.0" branded manuals also make mention of the u3b5 machine, the 3B5. The System V manuals are from January 1983 and the Release 5.0 manuals are June 1982. There isn't an earlier reference to cite as machid(1) was introduced in Release 5.0, at least from the literature I have available. The 4.x series ran on at least the PDP-11, VAX, and 3B20S computers at least, matching those listed in the System V manual. From what I have available initial 3B5 literature was distributed in the form of small binders a little different from the grey-on-black 1984 DEC Processor SVR2 binders, possibly right on the cusp of the split of p_man from u_man as this 3B5 User's Manual that I have contains sections 1-6 rather than just 1 and 6. They're dark grey with a large orange square in the middle (I believe I've sent a photograph of the manual before).

1 year, 11 months

emacs

by Will Senn

As a longtime user and lover of ed/ex/vi, I don't know much about emacs, but lately I've been using it more (as it seems like any self-respecting lisper, has to at least have a passing acquaintance with it). I recently went off and got MACLISP running in ITS. As part of that exploration, I used EMACS, but not just any old emacs, emacs in it's first incarnation as a set of TECO macros. To me, it just seemed like EMACS. I won't bore you with the details - imagine lots of control and escape sequences, many of which are the same today as then. This was late 70's stuff. My question for the group is - when did emacs arrive in unix and was it a full fledged text editor when it came or was it sitting on top of some other subssystem in unix? Was TECO ever on unix? Will

1 year, 11 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