Once upon a time when I was really really green we had this little lab datacenter, just a room full of machines, and the lab manager guy, crazy dude that I was a bit afraid of, handed me his pager for the weekend, I guess he had to be gone. I didn't really get this whole on-call thing back then, and so I shoved it into backpack and forgot about it. Well, there was a windstorm, so Sunday evening I check it, and there is a sequence of 24 messages from the UPS "power lost, shutting down server X#", with a gap of a few hours, then 23 messages from UPS "power reappeared, booting up server X#". As I said, I didn't really get this whole on-call thing so I ignored it until Monday when I manually booted server X24. Nobody noticed. Glad it wasn't that important...
Reminds me of one time I was working as a teen, for a workstation software development group, and my time was shared as an assistant to the site sysadmin.
The head sysadmin was gone and there was an incident that required rebooting or power-cycling the critical Sun 4/390 server that was in a locked machine room, so people were asking me what to do, but I hadn't yet been allowed to touch that server.
This machine handled email, special Internet gateway, Usenet, Sun YP maps, license servers, most of the critical NFS volumes (home directories, tools, SCM of our code), and maybe some weird thing for the non-engineering people who only had Windows boxes.
At the time, I thought of power-cycling as risky (for one thing, we had enough SPARCstations with Quantum 105 drives, that a rare power outage meant that we'd usually lose a workstation, though the 4/390 used huge IPI drives). And I think I didn't have that root password, and maybe not even the door keypad code that the console was behind.
So I mostly just speed-walked around the building, as if with purpose, while trying to figure out who I could contact, to get access and tell me what the safe procedure was to reboot/cycle the big loud machine that everything depended on.
On my very first admin job all the way back in high school the single server with all the schools data had hung. So I power-cycled it only for it to blow the UPS and the fuse. Probably too much dust had accumulated in the PSU and the current surge of booting shorted it out. The following conversation with the adult in charge was not pleasant. When you press the reset button and the lights above go out with a bang - a stressful day.
These days most anything that would serve a role as a core router at a mid to large sized ASN will be powered from a huge battery bank and -48VDC rectifier system. You can easily have 400-800Gbps of traffic going through one box.
And if you look at the photo of the front panel, you can see the "AUTO RSTRT" switch that's mentioned in the article - it's the third from the left on the top panel:
We had one of these refrigerator-sized boxes in our machine room in the early 80's to connect our DEC-20 to the Arpanet. A few years later, it was replaced by a Cisco router that was a fraction of its size.
> The IMP software and the ARPA network communications protocol running on the IMPs was discussed in RFC 1 (https://datatracker.ietf.org/doc/html/rfc1), the first of a series of standardization documents published by what later became the Internet Engineering Task Force.
It was also pretty clear that the IMP itself, and BBN as its vendor, was kind of at the center of this whole thing, where RFCs were always implicitly for internal discussion between these people who were also always in external discussion with BBN, recording what BBN said and what changes to the IMP were coming that would allow for/enable changes to planned protocols and software.
You might say that the IETF was really just a user group for "amateur" BBN IMP enthusiasts. :) I say "amateur", because BBN's real paying customers, as a DARPA contractor, would have been government, military, and telcos. Thus why none of those were participants in the "Network Working Group" — they were getting white-glove service directly from BBN!
If anyone knows exactly when DARPA itself (and US gov/mil installations as a consequence) began participating in the IETF / switched their own internal networks to using IETF-developed standards, that'd likely be a fascinating little point of history to learn about.
When I worked at BBN in the late 90s, around the time they were bought by GTE, they had a warehouse of old equipment, and I noticed they had a couple of IMPs. I really hope those ended up in a museum.
Looks like we may see more and more HN submissions that are URLs pointing to Mastodon "toots". Better than URLs pointing to Twitter pages, but still baffling given that the content is less than 500 characters, and even less in the case of Twitter.
The text of a toot is in the page. There is no Javascript-triggered HTTP request to retrieve it. One does not need to enable Javascript to fetch and read toots in a web browser. But, like Twitter, some web developer(s) thought it would be a good idea to try to prevent www browser users from seeing any content unless they enable Javascript.
One workaround is to simply add /embed to the URL.
Personally I have added a rule to the localhost-bound forward proxy that adds this automatically so Mastodon toots are readable in the text-only browser.
> Better than URLs pointing to Twitter pages, but still baffling given that the content is less than 500 characters, and even less in the case of Twitter.
The content here is almost 2,000 characters. Mastodon is just software you run yourself, even if it has a default character limit you can configure it to be whatever you want. Using Mastodon as a blog is actually kind of neat, although for my own use I'd want to customize it to have syntax highlighting for code.
I don’t understand this quote which I’ve heard 1Mx. I’m not aware of any layer or protocol in networks that have a concept of damage. There is such a thing as failover links but they’re very rare for most layers of the network and certainly not unique to the Internet, they definitely have nothing to do with censorship which is the version of the quote I see the most.
It's a misquote. The actual comment was made about USENET, not the Internet, in response to an incident at Stanford. This was the "rec.humor.funny" incident, in the late 1980s.[1] Someone at Stanford (Ralph Gorin, an IT manager?) had blocked some USENET groups from entering the campus USENET network. But there was a faculty member who had a low-bandwidth connection to the outside world, and ran a USENET node. USENET works by syncing; when two nodes talk, they exchange any missing messages in any groups they both support. USENET nodes often connected by dialing each other with dial-up modems every hour or so. Some low-bandwidth connection automatically copied across the missing censored messages. So, USENET really did treat censored messages as lost data to be transmitted over another path.
John Gilmore is generally credited with saying this about the Internet around 1993, but he acknowledges was originally made about USENET.[2]
If anyone can find Stanford SU-SCORE archives for the 1980s, the original source is probably in there.
I should've put an emoticon. It was a play on the old saying about trying to censor on the Internet. In this case, it was trying to "shut down the Internet", and "the Internet" popped right back on.
I just finished reading "Where Wizards Stay Up Late - The Origins of the Internet", and the story of the IMP features heavily in that book. And it describes some of the resiliency features too, including the auto restart, and even auto loading of it's software! Cool stuff. I highly recommend it to anyone who wants to hear more about this time period of the early "internet". Good stuff.
Back then, it was spelled "Internet". Frmr VP Al Gore described it as "the information superhighway" while the late Sen. Ted Stevens called it "a series of tubes."
The transition from BBSes (with UUCP and CompuServe) to dial-up ISPs was tedious. Newsgroups (NNTP), IRC chat, FTP servers, and Gopher search clients were as important as web pages.
And placeholder icons, red-on-yellow scrolling marquee Comic Sans, page visit counters, and blink tags abounded. (Oh, and page rings, broken deep links, and capture auto-redirect pages. That was before the era of pop-under popup pages, embedded plugins (SWF Flash, ActiveX, Java Applets (which could be cryptographically-signed) controls, and sensible browser security controls.)
Around 1996, I wrote a shiny-new HTTP/1.0 (!) CGI chat server in Perl with a HTML-JavaScript client using (inefficient) polling. The client exploited HTTP/1.0 to keep the server connection alive almost indefinitely with periodic no-op messages. The server could push new chat messages by writing them to all N clients.
Later on, on LANs, multicast UDP could sometimes deliver a message to multiple listeners.
Multicast, SCTP, UDP lite, and broadcast don't really scale across the series of tubes. UDP is "best effort" and not guaranteed. UDP's advantage is lower latency. IPv6 will take another 30 years to deploy unless a collective of telcos conspire to phase out IPv4.
Edit 3: I believe I worked with someone who worked with Lauren at UCLA.
Edit 4: The first Internet message from UCLA to SRI was "LO".
BBN, that is an acronym I haven't heard in years that brings back memories!
They've been around for a long time, but I didn't hear of them until the mid 1990's when I was running a system that ping'd all the major DNS servers (Internet Weather Report).
They wrote the first TCP/IP stack. Correctly. We got the Berkeley one instead with all its bugginess (which bugs we still work around) for dumb reasons.
I have not found out what the API would have been like, instead of socket() / connect() / listen() etc.
Lauren's outlook on social media is monochromatic, apocalyptic and incorrect in one respect.
When real names and pictures are required of everyone, cyberdisinhibitionism, the tendency for people to act horribly and without boundaries, is reduced and conversation becomes more civilized. Signalvnoise (Basecamp / DHH blog) points to this observation.
This toot reminds me of the plot of Infocom's classic text adventure "The Lurking Horror":
Despite a terrible snowstorm, a young G.U.E. Tech student travels to the school's computer lab to work on his grad paper. However, something strange has happened. The file containing the student's document has been partially overwritten by the Department of Alchemy's files. At first the student's only goal is to retrieve his lost document, but soon he realizes that something far more sinister is occurring in the depths of the school building.
I posted this thread of spooky NSA networking stories, supporting links, and old emails a few years ago to the "30 spies dead after Iran cracked CIA comms network" discussion:
At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins.
Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card.
On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field.
Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV:
I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip.
Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight.
Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones."
Date: Thu, 11 Sep 86 13:53:45 EDT
From: Steve D. Miller <steve@brillig.umd.edu>
To: staff@mimsy.umd.edu
Subject: Talking to the Milnet NOC
This message is intended to be a brief tutorial/compendium of
information you probably want to know if you need to see about
getting the LH/DH thingy (and us) talking to the world.
First, you need the following numbers:
(1) Our IMP number (57),
(2) Mimsy's milnet host address (26.2.0.57),
(3) The circuit number for our link to the NSA
(DSEP07500-057)
(4) The NOC number itself (692-5726).
Second, you need to know something about the hardware. There
are three pieces of hardware that make up our side of the link:
the LH/DH itself, the ECU, and the modem. The LH/DH and the
ECU are the things in the vax lab by brillig; the ECU is the
thing on top (with the switches), and the LH/DH is the thing
on the bottom. The normal state is to have the four red LEDs
on the ECU on and the Host Master Ready, HRY, Imp Master Ready,
and IRY lights on at the LH/DH. If these lights are not on,
something is wrong. If mimsy is down, then we'll only have some
of the lights on, but that should fix itself when mimsy comes up.
Some interesting buttons or switches on the ECU are:
reset - resets something or another
stop - stops something or another
start - restarts something or another
local loopback -- two switches and two leds; you may need
to throw one or the other of these if the NOC asks
you to. These loopback switches should be distinguished
from those on the modem itself.
remote loopback -- like local loopback, but does something else.
The modem is in the phone room beside the terminal room (rm.
4322, if memory serves). It can be opened with the chase key from
the key box...but if someone official and outside of staff asks
you that, you probably shouldn't admit to it. It has a switch on
it, too; it seems that switch normally rests in the middle, and
there's a "LL" setting to the left which I assume puts the modem in
local loopback mode.
Now that you have some idea of where things are, call the NOC.
Identify yourself as from the University of Maryland, and say that
we're not talking to the outside world. They will probably ask for
our Milnet address or the number of the IMP we're connected to,
and will then poke about and see what's happening. They will ask
you to do various things; ask if you're not sur...
To: fair@ucbarpa.berkeley.edu (Erik E. Fair)
Cc: ucdavis!ccohesh@ucbvax.berkeley.edu, Hackers_Guild@ucbvax.berkeley.edu
Subject: Re: a question of definition
Date: Thu, 29 Jan 87 12:29:36 PST
From: Milo S. Medin (NASA ARC Code ED) <medin@orion.arpa>
Actually its:
SCINET -- Secret Compartmented Information Net (if you don't know what
compartmented means, you don't need to ask)
DODIIS -- DoD Intelligence Information Net
The other stuff I think is right, at least without me looking things
up. I probably shouldn't have brought this subject of the secure part
of the DDN up. People like being low key about such things...
Erik, all the BBN gateways on MILNET and ARPANET currently comprise
the core, not just mailbridges. Some are used as site gateways, others
as EGP neighbors, etc... And just because you are dual homed doesn't mean
you get a mailbridge. And the IETF doesn't deal with low level stuff
like that; DCA does all that. In fact, the reason we are getting an
ARPANET PSN is because when DCA came out to do a site survey, they
liked our site so much they asked if they could put one here! It's
amazing how many sites have tried to get ARPANET PSN's the right
way and have had to wait much longer than us... BTW, since we are
dual homed (probably a gateway with 2 1822 interfaces in it), we
are taking steps to be sure that people on ARPANET or MILNET can't
use our gateway to bypass the mailbridges. The code will be hacked
to drop all packets that aren't going to a locally reachable network.
BARRNet, even though its locally reachable, will be excluded
from this however, since the current procedural limitations call for
not allowing any BARRNet traffic to flow out of BARRNet to MILNET
and the reverse. NASA traffic of course can traffic through BARRNet,
and even use ARPANET that way (though that's not a big deal when
we get our own ARPANET PSN). That's because only NASA is authorized
to directly connect to MILNET, not UCB or Stanford, etc...
DCA must have the ability to partition the ARPANET and MILNET in
case of an "emergency", and having non-DCA controlled paths between
the nets prevents that. There was talk some time ago about putting
explosive bolts in the mailbridges that would be triggered by
destruct packets... That idea didn't get far though...
The DDN only includes MILNET,ARPANET,SCINET,etc... Not the attached
networks. If it did, you'd need to file a TSR to add a PC to your
local cable. A TSR is a monstrous piece of paperwork that needs to
be done anytime anything is changed on the DDN... Rick knows all
about them don't you Rick?
The whole network game is filled with acronyms! I gave up trying
to write documents with full explainations in terms long ago...
I have yet to see a short and concise (and correct) way of describing
DDN X.25 Standard Service for example... That's probably one of the
harder things about getting into networking these days. We won't
even talk about Etherbunnies and Martians and other Millspeak...
Milo '1822' Medin
There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know).
Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET:
To: fair@ucbarpa.berkeley.edu (Erik E. Fair)
Cc: Hackers_Guild@ucbvax.berkeley.edu, ucdavis!ccohesh@ucbvax.berkeley.edu
Subject: Re: a question of definition
Date: Thu, 29 Jan 87 15:33:35 PST
From: Milo S. Medin (NASA ARC Code ED) <medin@orion.arpa>
Right, the core has many gateways on it now, maybe 20-30. All the LSI's will
be stubbed off the core however, and only buttergates will be left after
the mailbridges and EGP peers are all converted. Actually, I think DARPA is
paying for it all...
Ames is *not* getting a mailbridge. You are right of course, that we could
use 2 gateways, not just 1 (actually, there will be a prime and backup anyways),
and then push routing info appropriately. But that's anything but simple.
Firstly, the hosts have to know which gateway to send a packet to a given
network, and thus have to pick between the 2. That's a bad idea.
It also means that I have to pass all EGP learned info around on the
local cable, and if I do that, then I can't have routing info from
the local cable pass out via EGP. At least not without violating
the current EGP spec. Think about it. It'd be really simple to
create a loop that way. Thus, in order to maximize the use of both
PSN's, you really need one gateway wired to both PSN's, and just
have it advertise a default route inside. Or use a reasonble IGP,
of which RIP (aka /etc/routed stuff) is not. I'm hoping to get
an RFC out of BBN at this IETF meeting which may go a long way in
reducing the use of RIP as an IGP.
BTW, NSA is an example of a site on both MILNET and ARPANET but without
a mailbridge...
There is no restriction that a network can only be on ARPANET or MILNET.
That goes against the Internet model of doing things. Our local
NASA gatewayed nets will be advertised on both sides. The restriction
on BARRNet is that the constituent elements of BARRNet do not all
have access to MILNET. NSF has an understanding with DARPA and
DCA that NSFnet'd sites can use ARPANET. That does not extend to
the MILNET. Thus, Davis can use UCB's or Stanford's, our even NASA's
ARPANET gateways, with the approval of the site of course, but
not MILNET, even though NASA has MILNET coverage. Thus we are required
to restrict BARRNet routing through our MILNET PSN. If we were willing
to sponsor UCB's MILNET access, for some requirement which NASA
had to implement, then we would turn that on. But BARRNet itself will
but cutoff to MILNET (and probably ARPANET too) at Ames, but not
cut off to other NASA centers or sites that NASA connects. There is
no technical reason that prevents this, in fact, we have to take
special measures to prevent it. But those are the rules. Anyways,
mailbridge performance should improve after the conversion, so
UCB should be in better shape. And you'll certainly be able to
talk to us via BARRNnet... I have noticed recently that MILNET<->
ARPANET performance has been particularly poor... Sigh.
The DCA folks feel that in case of an emergency they may be
forced to use an unsecure network to pass certain info around. The
DDN brochure mentions SIOP related data for example. Who knows,
if the balloon goes up, the launch order might pass through Evans
Hall on its way out to SAC... :-)
Milo
Here's another funny story from my email archives of around the same time, about how Jordan Hubbard's infamous rwall almost got UC Berkeley cut off from the internet, with some more interesting details from other old net boys like Milo Medin, Marc Crispin, and Dennis G. Perry:
Speaking of YP (which I always thought sounded like a brand of moist baby poop towelettes), BSD, wildcard groups, SunRPC, and Sun's ingenuous networking and security and remote procedure call infrastructure, who remembers Jordan Hubbard's infamous rwall incident on March 31, 1987?
>On March 31, 1987 Hubbard executed an rwall command expecting it to send a message to every machine on the network at University of California, Berkeley, where he headed the Distributed Unix Group. The command instead began broadcasting Hubbard's message to every machine on the internet and was stopped after Hubbard realised the message was being broadcast remotely after he received complaints from people at Purdue University and University of Texas. Even though the command was terminated, it resulted in Hubbard receiving 743 messages and complaints, including one from the Inspector General of ARPAnet.
I was logged in on my Sun workstation "tumtum" when it happened, so I received his rwall too, and immediately sent him a humorous email with the subject of "flame flame flame" which I've lost in the intervening 35 years, but I still have a copy of his quick reply:
From: Jordan K. Hubbard <jkh%violet.Berkeley.EDU@berkeley.edu>
Date: Tue, Mar 31, 1987, 11:02 PM
To: Don Hopkins <don@tumtum.cs.umd.edu>
Subject: re: flame flame flame
Thanks, you were nicer than most.. Here's the stock letter I've been
sending back to people:
Thank you, thank you..
Now if I can only figure out why a lowly machine in a basement somewhere
can send broadcast messages to the entire world. Doesn't seem *right*
somehow.
Yours for an annoying network.
Jordan
P.S. I was actually experimenting to see exactly now bad a crock RPC was.
I'm beginning to get an idea. I look forward to your flame.
Jordan
Here's the explanation he sent to hackers_guild, and some replies from old net boys like Milo Medin (who said the program manager of the Arpanet in the Information Science and Technology Office of DARPA Dennis G. Perry said they would kick UCB off the Arpanet if it ever happened again), Mark Crispin (who presciently proposed cash rewards for discovering and disclosing security bugs), and Dennis G. Perry himself:
From: Jordan K. Hubbard <jkh%violet.Berkeley.EDU@berkeley.edu>
Date: April 2, 1987
Subject: My Broadcast
By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)
So now everyone is ...
38 comments
[ 3.1 ms ] story [ 95.7 ms ] threadThe head sysadmin was gone and there was an incident that required rebooting or power-cycling the critical Sun 4/390 server that was in a locked machine room, so people were asking me what to do, but I hadn't yet been allowed to touch that server.
This machine handled email, special Internet gateway, Usenet, Sun YP maps, license servers, most of the critical NFS volumes (home directories, tools, SCM of our code), and maybe some weird thing for the non-engineering people who only had Windows boxes.
At the time, I thought of power-cycling as risky (for one thing, we had enough SPARCstations with Quantum 105 drives, that a rare power outage meant that we'd usually lose a workstation, though the 4/390 used huge IPI drives). And I think I didn't have that root password, and maybe not even the door keypad code that the console was behind.
So I mostly just speed-walked around the building, as if with purpose, while trying to figure out who I could contact, to get access and tell me what the safe procedure was to reboot/cycle the big loud machine that everything depended on.
https://upload.wikimedia.org/wikipedia/commons/0/04/Interfac...
We had one of these refrigerator-sized boxes in our machine room in the early 80's to connect our DEC-20 to the Arpanet. A few years later, it was replaced by a Cisco router that was a fraction of its size.
> The IMP software and the ARPA network communications protocol running on the IMPs was discussed in RFC 1 (https://datatracker.ietf.org/doc/html/rfc1), the first of a series of standardization documents published by what later became the Internet Engineering Task Force.
On that note, it's actually quite interesting to peruse the first few RFCs (https://www.rfc-editor.org/rfc-index-100a.html). Internet RFCs pretty clearly started off as the "Network Working Group"'s internal mailing list, where they'd throw any old thing: plans (https://www.rfc-editor.org/rfc/rfc4.html), meeting notes (https://www.rfc-editor.org/rfc/rfc6.html), mirrors for internal use (https://www.rfc-editor.org/rfc/rfc12.html), storytelling (https://www.rfc-editor.org/rfc/rfc89.html), etc.
It was also pretty clear that the IMP itself, and BBN as its vendor, was kind of at the center of this whole thing, where RFCs were always implicitly for internal discussion between these people who were also always in external discussion with BBN, recording what BBN said and what changes to the IMP were coming that would allow for/enable changes to planned protocols and software.
You might say that the IETF was really just a user group for "amateur" BBN IMP enthusiasts. :) I say "amateur", because BBN's real paying customers, as a DARPA contractor, would have been government, military, and telcos. Thus why none of those were participants in the "Network Working Group" — they were getting white-glove service directly from BBN!
If anyone knows exactly when DARPA itself (and US gov/mil installations as a consequence) began participating in the IETF / switched their own internal networks to using IETF-developed standards, that'd likely be a fascinating little point of history to learn about.
The text of a toot is in the page. There is no Javascript-triggered HTTP request to retrieve it. One does not need to enable Javascript to fetch and read toots in a web browser. But, like Twitter, some web developer(s) thought it would be a good idea to try to prevent www browser users from seeing any content unless they enable Javascript.
One workaround is to simply add /embed to the URL.
https://mastodon.laurenweinstein.org/@lauren/109588605178700...
Personally I have added a rule to the localhost-bound forward proxy that adds this automatically so Mastodon toots are readable in the text-only browser.
The content here is almost 2,000 characters. Mastodon is just software you run yourself, even if it has a default character limit you can configure it to be whatever you want. Using Mastodon as a blog is actually kind of neat, although for my own use I'd want to customize it to have syntax highlighting for code.
Adding /embed to the Mastodon toot also improves the desktop reading experience by removing the left and right sidebars.
(It could be further improved if it had mobile-specific styling.)
John Gilmore is generally credited with saying this about the Internet around 1993, but he acknowledges was originally made about USENET.[2]
If anyone can find Stanford SU-SCORE archives for the 1980s, the original source is probably in there.
[1] http://jmc.stanford.edu/general/rhf.html
[2] https://quoteinvestigator.com/2021/07/12/censor/
I was pleasantly surprised to see them on the Fediverse, but I guess that shouldn't be a surprise.
Node 1: UCLA (30 August, hooked up 2 September, 1969) - SDS SIGMA 7, SEX
Node 2: Stanford Research Institute (SRI) (1 October) - SDS940/Genie
Node 3: University of California Santa Barbara (UCSB) (1 November) - IBM 360/75, OS/MVT
Node 4: University of Utah (December) - DEC PDP-10, Tenex
https://www.zakon.org/robert/internet/timeline/
And a network sketch:
https://www.scientificamerican.com/gallery/early-sketch-of-a...
The transition from BBSes (with UUCP and CompuServe) to dial-up ISPs was tedious. Newsgroups (NNTP), IRC chat, FTP servers, and Gopher search clients were as important as web pages.
And placeholder icons, red-on-yellow scrolling marquee Comic Sans, page visit counters, and blink tags abounded. (Oh, and page rings, broken deep links, and capture auto-redirect pages. That was before the era of pop-under popup pages, embedded plugins (SWF Flash, ActiveX, Java Applets (which could be cryptographically-signed) controls, and sensible browser security controls.)
Around 1996, I wrote a shiny-new HTTP/1.0 (!) CGI chat server in Perl with a HTML-JavaScript client using (inefficient) polling. The client exploited HTTP/1.0 to keep the server connection alive almost indefinitely with periodic no-op messages. The server could push new chat messages by writing them to all N clients.
Later on, on LANs, multicast UDP could sometimes deliver a message to multiple listeners.
Multicast, SCTP, UDP lite, and broadcast don't really scale across the series of tubes. UDP is "best effort" and not guaranteed. UDP's advantage is lower latency. IPv6 will take another 30 years to deploy unless a collective of telcos conspire to phase out IPv4.
Edit 3: I believe I worked with someone who worked with Lauren at UCLA.
Edit 4: The first Internet message from UCLA to SRI was "LO".
They've been around for a long time, but I didn't hear of them until the mid 1990's when I was running a system that ping'd all the major DNS servers (Internet Weather Report).
https://icannwiki.org/BBN
I have not found out what the API would have been like, instead of socket() / connect() / listen() etc.
When real names and pictures are required of everyone, cyberdisinhibitionism, the tendency for people to act horribly and without boundaries, is reduced and conversation becomes more civilized. Signalvnoise (Basecamp / DHH blog) points to this observation.
https://signalvnoise.com/posts/2205-there-is-an-inverse-rela...
Another thought piece:
https://ericsammons.com/internet-anonymity-the-good-the-bad-...
Interesting article about grandiose and vulnerable narcissism interacting with anonymity:
https://www.sciencedirect.com/science/article/abs/pii/S01918...
Anonymity is necessary for some discussions (like these), but it should not be pervasive or without boundaries.
https://lauren.vortex.com
Despite a terrible snowstorm, a young G.U.E. Tech student travels to the school's computer lab to work on his grad paper. However, something strange has happened. The file containing the student's document has been partially overwritten by the Department of Alchemy's files. At first the student's only goal is to retrieve his lost document, but soon he realizes that something far more sinister is occurring in the depths of the school building.
https://news.ycombinator.com/item?id=18376750
At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins.
https://emaillab.jp/dns/hosts/
https://multicians.org/site-dockmaster.htmlWhenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card.
On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field.
Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV:
https://www.youtube.com/watch?v=hVth6T3gMa0
I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip.
Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight.
Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones."
I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far.
Milo Medin knows this stuff first hand:
https://web.archive.org/web/20180505024303/https://innovatio...
There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know). Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET:
https://news.ycombinator.com/item?id=31822138
Speaking of YP (which I always thought sounded like a brand of moist baby poop towelettes), BSD, wildcard groups, SunRPC, and Sun's ingenuous networking and security and remote procedure call infrastructure, who remembers Jordan Hubbard's infamous rwall incident on March 31, 1987?
https://news.ycombinator.com/item?id=25156006
https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident
>rwall incident
>On March 31, 1987 Hubbard executed an rwall command expecting it to send a message to every machine on the network at University of California, Berkeley, where he headed the Distributed Unix Group. The command instead began broadcasting Hubbard's message to every machine on the internet and was stopped after Hubbard realised the message was being broadcast remotely after he received complaints from people at Purdue University and University of Texas. Even though the command was terminated, it resulted in Hubbard receiving 743 messages and complaints, including one from the Inspector General of ARPAnet.
I was logged in on my Sun workstation "tumtum" when it happened, so I received his rwall too, and immediately sent him a humorous email with the subject of "flame flame flame" which I've lost in the intervening 35 years, but I still have a copy of his quick reply:
Here's the explanation he sent to hackers_guild, and some replies from old net boys like Milo Medin (who said the program manager of the Arpanet in the Information Science and Technology Office of DARPA Dennis G. Perry said they would kick UCB off the Arpanet if it ever happened again), Mark Crispin (who presciently proposed cash rewards for discovering and disclosing security bugs), and Dennis G. Perry himself: