It’s very interesting. I’ve tried to observe myself. It seems that if I can see a breakpoint somewhere and then examine state and then see what the problem is, a debugger is great.
If, however, it’s something where I need to examine state at multiple times in the execution, I lose track in my mind of the state I’ve seen before. This is where print debugging shines: I can see how state evolved over time and spot trends.
You’re misunderstanding. In those other apps the behavior is this: you open a document. You put the cursor on line 3 column 3. You use the mouse wheel or trackpad to scroll down to line 600. You hit cursor right. The cursor is now on line 3 column 4.
In emacs the cursor would be somewhere around line 600 instead.
It should be possible to save the cursor position, hide it if it moves away from view during scrolling, and restore it back on any command but scrolling, or at least at the firs cursor-movement command.
It’s autocomplete being based on words. It knows computer and it knows keyboard and so in English it is trivial to type computer keyboard.
In German it also knows Computer and Tastatur, but I can’t use autocomplete to type Computertastatur.
Actually I just learned I can. Apparently this word is in the dictionary. But there are just so many compound nouns, it’s impossible for them all to be in the dictionary.
To make it work in such a language it has to understand about constructing compound nouns.
I recall that inetd started a new instance of the demon for every incoming connection, and this caused lots of processes when lots of connections happened.
I don’t recall whether you could tell inetd not to do that.
inetd could pass the listening socket to the process. That was the `wait|nowait` field in /etc/inetd.conf. The typical config for TCP used with services like finger was `nowait`, which meant inetd would listen on a socket and spawn a new process for every incoming connection, without waiting for a previously spawned process to exit. But in `wait` mode it would spawn the process when it detected a connection, pass the listening socket (not connected socket) as fd 0, then wait for the server to exit before polling the listening socket again.
inetd was (remains?) a perfectly useful solution in this space. It just maybe needs some love to add some convenience features. Off the top of my head: 1) ability to split /etc/inetd.conf into, e.g., /etc/inetd.conf.d; 2) ability to trigger a restart of a specific service, rather than restarting the entirety of inetd.
Docker desktop for Mac: dockerd runs in the VM and the client from the host system wants to connect. But of course we all hope that the network it is exposed to is still only on the Mac.
mit-ai was running its, not unix, and there wasn't even a port of unix to the pdp-10 at the time. moreover uucp addresses are of the form host!user rather than user@host
To clarify on account of kragen's idiosyncratic avoidance of uppercase, "its" is "ITS", the Incompatible Timesharing System, developed by MIT's AI Lab:
yeah, eventually, but in 01976 uucp was just getting started. even in 01978 i don't think they had a well-defined network map, though they said uucp already connected over 100 unix machines in the 7th edition manual. that post is from 01981
unfortunately 'show original message' is grayed out, so i can't actually see the map
>The "ML Device" protocol is a remote file system invented for the PDP-10 MIT Incompatible Timesharing System. It may have been the very first transparent networking filesystem.
>Build:
Install libfuse-dev, then type make.
>Usage:
Create a mount point directory, and then mount an ITS file system like this:
>I know it's always hard to define an exact first, so I'll just ask about early network file systems. To be more specific, I'm wondering about file systems that transparently present directories and files as if they were local. I don't consider FTP or similar mechanisms to be candidates.
>For some time it has been my suspicion that the ITS "MLDEV" facility was very early ("the first"), but I never had any facts to back it up. I do have a file timestamped November 1972 that gives us an upper bound for the introduction of the facility. On the MIT-AI PDP-10, it provided an ML device (hence the name) which worked much like the local DSK device except the data was accessed through MIT's ARPANET IMP. MIT-ML of course had an AI device.
>Present evidence is that ITS had a very early networked file system no later than 1972.
>ITS has had a facility called the "ML Device", or MLDEV, for a long time. The name probably comes from a time when the users of the older more established computer called AI wanted access to files on the computer called ML. The "device" part is because ITS files are named by four parts: device, directory, and two file names. To access ML files from AI, the device name is ML. Conversely, from ML the AI device is used.
>To date this facility, we can check timestamps from backup tapes. The earliest file called MLDEV is from July 1975. However, if we examine the source code for an earlier ITS version we see that it has built in ML and AI devices that when accessed starts a program called SYS; ATSIGN OTHER. Disassembling this file we can see that it indeed is accepting file operations and sends information across ARPANET. The earliest file with that name has a timestamp from November 1972.
>We know from RFC documents 342, 344, and 366 that AI and ML were first put on the ARPANET in May-June 1972. So MLDEV could not have been in use before 1972.
The MLDEV was quite convenient for talking to the other ITS machines, as they just lived in the filesystem no differently from local files.
Among the many hackerish features of ITS was allowing a user space process to act like a device, not just for a filesystem but as a TTY, which allowed a lot more kinds of terminals to be supported than would fit in the monitor (kernel in today’s parlance).
> Among the many hackerish features of ITS was allowing a user space process to act like a device, not just for a filesystem but as a TTY, which allowed a lot more kinds of terminals to be supported than would fit in the monitor (kernel in today’s parlance).
I begin to understand where Plan 9 got that "other" kind of inspiration.
CRTSTY was kind of like "screen", in that it ran a virtual terminal through something like a pseudo TTY. The terminal interpreted SUPDUP protocol into any terminal type that CRTSTY supported. And you could disconnect and reattach to it later to restore your processes, to change terminals or survive a flakey modem or ARPA connection dropping out.
But even without CRTSTY, ITS gave everyone the ability to reattach to their processes after they got disconnected, and even pass processes like Lisp interpreters and Zork games around from user to user to share like a joint, by detatching and reattaching them to different TTYs!
>For display terminals which are not handled directly by the
system there exists a program called CRTSTY. This provides the software
support to permit these terminals to take advantage of their display
characteristics. Among the terminals supported by CRTSTY are: ADM3's,
Concept 100's, Hazeltine 1500's, Perkins Elmer FOX's, Datamedias,
Control Data Corporation 713's, and a host of others. You should try
:INFO CRTSTY and :INFO TERMS to see if your terminal is included. If it
isn't, the maintainers of CRTSTY are usually willing to help you add it.
In the CRTSTY section of INFO the information you must provide to have a
new terminal supported is listed. You can communicate with the
maintainers of CRTSTY by sending mail to BUG-CRTSTY.
>SUPDUP v. To communicate with another ARPAnet host using the SUPDUP
program, which is a SUPer-DUPer TELNET talking a special display
protocol used mostly in talking to ITS sites. Sometimes
abbreviated to SD.
>NWG/RFC# 734 MRC 07-OCT-77 08:46 41953 SUPDUP Display Protocol Page 1 Network Working Group Mark Crispin Request for Comments 734 SU-AI NIC 41953 7 October 1977
>SUPDUP Protocol
>This document describes the SUPDUP protocol, a highly efficient display telnet protocol. It originally started as a private protocol between the ITS systems at MIT to allow a user at any one of these systems to use one of the others as a display. At the current writing, SUPDUP user programs also exist for Data Disc and Datamedia displays at SU-AI and for Datamedias at SRI-KL. The author is not aware of any SUPDUP servers other than at the four MIT ITS sites.
>The advantage of the SUPDUP protocol over an individual terminal's protocol is that SUPDUP defines a "virtual" or "software" display terminal that implements relevant cursor motion operations. The protocol is not built on any particular display terminal but rather on the set of functions common to all display terminals; hence it is completely device- independent. In addition, the protocol also provides for terminals which cannot handle certain operations, such as line or character insert/delete. In fact, it is more than this. It provides for terminals which are missing any set of features, all the way down to model 33 Teletypes.
>The advantage over the TELNET protocol is that SUPDUP takes advantage of the full capabilities of display terminals, although it also has the ability to run printing terminals.
>The SUPDUP protocol [Crispin 77] is a highly efficient display telnet protocol. The advantage over the TELNET protocol is that SUPDUP takes advantage of the full capabilities of display terminals, although it also has the ability to run printing terminals. When you use the SUPDUP protocol, you do not need to tell the remote host which you are connecting to what type of terminal you have or what the terminal's capabilities are. The host you are SUPDUPing from handles the actual display support for your terminal.
>Additionally, SUPDUP defines a network graphics protpcol [Stallman 78] which makes it easy for network hosts to draw pictures along in addition to text.
You didn't need CRTSTY to implement the SUPDUP protocol, but CRTSTY translated SUPDUP to standard terminal escape sequences, and provided buffering and optimization. Lisp machines and Knight TVs had their own SUPDUP terminal programs, and I made one for my Apple ][ in Forth.
SUPDUP had a line saving extension that RMS hacked into ITS Emacs, so it can stash lines on the screen in local memory before overpainting them, then almost instantly pop them back on the screen later, so you can scroll back and forth through text really fast at 300 baud (plus Devon McCullough made ZipMod with Huffman encoding to make it even faster on top of that):
I wrote a terminal emulator for the Apple ][ + Videx 80 column card in FORTH and reverse polish notation 6502 code, that supported SUPDUP including the line saving protocol that RMS hacked into ITS and EMACS (%TDSAV %TDRES), so Emacs could stash lines on the screen in a memory buffer (on the Apple's bank switched RAM card) and restore them later to paint the screen quickly when scrolling back and forth. (That was great at 300 baud!)
This is just the part of it that interprets SUPDUP codes -- layered on top of the rest of the terminal emulator that emulated H19 (VT52 + character/line insert/delete):
At 300 baud over a congested ARPA connection, we had a lot of time to think about how to optimize terminal emulation while waiting for the screen to repaint...
When James Gosling later implemented his Unix version of Emacs, he created a super-hot screen update algorithm that automatically took into account the capabilities of terminals and the length of their escape codes and padding required (some slow terminals needed padding when performing line/character insert/delete operations, otherwise they would miss characters. It used dynamic programming to figure out the optimal way of updating the screen, which was really great at low baud rates like 300 or 1200 baud.
Read the paper and display.c code I linked to in the above linked comment, and see the wikipedia page on dynamic programming:
>James Gosling's Emacs screen redisplay algorithm also used similar "dynamic programming techniques" to compute the minimal cost path through a cost matrix of string edit operations (the costs depended i.e. on the number of characters to draw, length of the escape codes to insert/delete lines/characters, padding for slow terminals, etc).
The comments in this old PDP-10 SUPDUP code [5] are hilarious!
SUPDUP on ITS was so smart and opinionated, it had its own ideas about who was a loser and who was a winner, how to figure it out by checking INQUIR entries and relationships, and who it should never or always hassle about net-hopping (hopping through a PDP-10 over the net just to use it as a glorified terminal emulator).
It never hassled gumby or cstacy (because they were free to do whatever they wanted to, like flushing whiny annoying over-entitled alcoholic science fiction writers [1] [2] [3] [4]), but always hassled rms (because it was usually an imposter logging in as rms with password rms just to net hop through the system.)
[...]
;;; these people aren't hassled
wintab: irp x,,[gumby,alan,cstacy,cent,devon,dph,oaf,mly,jtw,jnc,klotz,cbf,sra,ed,swa,map,jbvb]
sixbit/x/
termin
winlen==.-wintab
;;; These people are always hassled
lostab: irp x,,[tk,hewitt,rms]
sixbit/x/
termin
loslen==.-lostab
Being able to attach and reattach consoles is cool. While I worked at Broadcom, I developed a kernel patch (whatever happened to it) which allowed you to have a stable serial console via a USB dongle.
I was able to unplug the USB-serial adapter from the embedded device's USB port. Then plug in a different USB-serial adapter (different chip requiring a different driver). It would obtain the same /dev/ttyUSB<n> device, and you would be back in your session intact. If you were in the middle of a vi edit, you could just Ctrl-L to refresh the screen and keep going.
SMTP evolved as replacement for older approaches which, at one point, involved using FTP to mangle mailboxes remotely. Not so much a special mode for FTP as essentially an "use of" FTP. Similar to how non-trivial amounts of Electronic Data Interchange in business happens over FTP(S) to this day.
UUCP was definitely not "Unix only", several operating systems supported it back in the day, Lisp Machines and ITS could access UUCP over Chaosnet. Mark Plotnick wrote the service (aka deamon) for Chaosnet for Unix in 1984.
For anyone who might not know, UUCP literally stands for "UNIX-to-UNIX copy".
Of course, especially given its relative simplicity, at some point non-UNIX systems started to implement it (I think I maybe used some DOS package at some point).
You may not be aware that it's a false friend. The German word Billion exists, and it means trillion.
So the German reader will read the English article (in English, not auto-translated), see the word billion, think “oh that looks familiar” and might assume it means the same as the German word Billion.
Machine translation makes quite a few mistakes, so I think if you have some decent knowledge of a language, you might be better off reading the original rather than a machine translation. At least my point of view from a couple of years ago. But it's also possible that machine translation has gotten WAY better in the last couple of years, I'm not sure.
If, however, it’s something where I need to examine state at multiple times in the execution, I lose track in my mind of the state I’ve seen before. This is where print debugging shines: I can see how state evolved over time and spot trends.