Don't leave us hanging! What happened next!?

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.

Here's an archived copy for those who may be having difficulty accessing the site: https://archive.ph/Ou23w

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:

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.

Fun point from that page:

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.

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.

I think that's the point -- the link with the trailing embed loads much faster, nearly instantly.

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.

One workaround is to simply add /embed to the URL.

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.)

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.

[1] http://jmc.stanford.edu/general/rhf.html

[2] https://quoteinvestigator.com/2021/07/12/censor/

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 was pleasantly surprised to see a self-hosted instance of Mastodon, though perhaps less surprising given the background of the author.

In case you're wondering (as I was):

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...

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".

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.

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

Title should be "I turned off the internet".

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.

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:

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:

    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 asking: "Who is this Jordan Hubbard, and why is he on my
    screen??"

    I will attempt to explain.

    I head a small group here at Berkeley called the "Distributed Unix Group".
    What that essentially means is that I come up with Unix distribution software
    for workstations on campus. Part of this job entails seeing where some of
    the novice administrators we're creating will hang themselves, and hopefully
    prevent them from doing so. Yesterday, I finally got around to looking
    at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
    was obvious that this was set up for rwall to use, so I read the documentation
    on "netgroup" and "rwall". A section of the netgroup man page said:

      ...
         Any of three fields can be empty, in which case it signifies
         a wild card.  Thus
                    universal (,,)
         defines a group to which everyone belongs.  Field names that ...
      ...

    Now "everyone" here is pretty ambiguous. Reading a bit further down, one
    sees discussion on yellow-pages domains and might be led to believe that
    "everyone" was everyone in your domain. I know that rwall uses point-to-point
    RPC connections, so I didn't feel that this was what they meant, just that
    it seemed to be the implication.

    Reading the rwall man page turned up nothing about "broadcasts". It doesn't
    even specify the communications method used. One might infer that rwall
    did indeed use actual broadcast packets.

    Failing to find anything that might suggest that rwall would do anything
    nasty beyond the bounds of the current domain (or at least up to the IMP),
    I tried it. I knew that rwall takes awhile to do its stuff, so I left
    it running and went back to my office. I assumed that anyone who got my
    message would let me know.. Boy, was I right about that!

    After the first few mail messages arrived from Purdue and Utexas, I begin
    to understand what was really going on and killed the rwall. I mean, how
    often do you expect to run something on your machine and have people
    from Wisconsin start getting the results of it on their screens?

    All of this has raised some interesting points and problems.

    1. Rwall will walk through your entire hosts file and blare at anyone
       and everyone if you use the (,,) wildcard group. Whether this is a bug
       or a feature, I don't know.

    2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
       who you are as long as you're root (which is trivial to be, on a work-
       station), I have to wonder what other RPC services are open holes. We've
       managed to do some interesting, unauthorized, things with the YP service
       here at Berkeley, I wonder what the implications of this are.

    3. Having a group called "broadcast" in your netgroup file (which is how
       it comes from sun) is just begging for some novice admin (or operator
       with root) to use it in the mistaken belief that he/she is getting to
       all the users. I am really surprised (as are many others) that this has
       taken this long to happen.

    4. Killing rwall is not going to solve the problem. Any fool can write
       rwall, and just about any fool can get root priviledge on a Sun workstation.
       It seems that the place to fix the problem is on the receiving ends. The
       only other alternative would be to tighten up all the IMP gateways to
       forward packets only from "trusted" hosts. I don't like that at all,
       from a standpoint of reduced convenience and productivity. Also, since
       many places are adding hosts at a phenominal rate (ourselves especially),
       it would be hard to keep such a database up to date. Many perfectly well-
       behaved people would suffer for the potential sins of a few.

    I certainly don't intend to do this again, but I'm very curious as to
    what will happen as a result. A lot of people got wall'd, and I would think
    that they would be annoyed that their machine would let someone from the
    opposite side of the continent do such a thing!

                             Jordan Hubbard
                             jkh@violet.berkeley.edu (ucbvax!jkh)
                             Computer Facilities & Communications.
                             U.C. Berkeley

    From: Milo S. Medin <medin@orion.arpa>
    Date: Apr 6, 1987, 5:06 AM

    Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher
    in the IG's office.  IPTO is the part of DARPA that deals with all
    CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...).
    Calling him part of the IG's office on the TCP/IP list probably didn't
    win you any favors.  Coincidentally I was at a meeting at the Pentagon
    last Thursday that Dennis was at, along with Mike Corrigan (the man
    at DoD/OSD responsible for all of DDN), and a couple other such types
    discussing Internet management issues, when your little incident
    came up.  Dennis was absolutely livid, and I recall him saying something
    about shutting off UCB's PSN ports if this happened again.  There were
    also reports about the DCA management types really putting on the heat
    about turning on Mailbridge filtering now and not after the buttergates
    are deployed.  I don't know if Mike St. Johns and company can hold them
    off much longer.  Sigh...  Mike Corrigan mentioned that this was the sort
    of thing that gets networks shut off.  You really pissed off the wrong
    people with this move! 

    Dennis also called up some VP at SUN and demanded this hole
    be patched in the next release.  People generally pay attention
    to such people.

                                            Milo

    From: Mark Crispin <MRC%PANDA@sumex-aim.stanford.edu>
    Date: Mon, Apr 6, 1987, 10:15 AM

    Dan -

         I'm afraid you (and I, and any of the other old-timers who
    care about security) are banging your head against a brick wall.
    The philsophy behind Unix largely seems quite reminiscent of the
    old ITS philsophy of "security through obscurity;" we must
    entrust our systems and data to a open-ended set of youthful
    hackers (the current term is "gurus") who have mastered the
    arcane knowledge.

         The problem is further exacerbated by the multitude of slimy
    vendors who sell Unix boxes without sources and without an
    efficient means of dealing with security problems as they
    develop.

         I don't see any relief, however.  There are a lot of
    politics involved here.  Some individuals would rather muzzle
    knowledge of Unix security problems and their fixes than see them
    fixed.  I feel it is *criminal* to have this attitude on the DDN,
    since our national security in wartime might ultimately depend
    upon it.  If there is such a breach, those individuals will be
    better off if the Russians win the war, because if not there will
    be a Court of Inquiry to answer...

         It may be necessary to take matters into our own hands, as
    you did once before.  I am seriously considering offering a cash
    reward for the first discoverer of a Unix security bug, provided
    that the bug is thoroughly documented (with both cause and fix).
    There would be a sliding cash scale based on how devastating the
    bug is and how many vendors' systems it affects.  My intention
    would be to propagate the knowledge as widely as possible with
    the express intension of getting these bugs FIXED everywhere.

         Knowledge is power, and it properly belongs in the hands of
    system administrators and system programmers.  It should NOT be
    the exclusive province of "gurus" who have a vested interest in
    keeping such details secret.

    -- Mark --

    PS: Crispin's definition of a "somewhat secure operating system":
    A "somewhat secure operating system" is one that, given an
    intelligent system management that does not commit a blunder that
    compromises security, would withstand an attack by one of its
    architects for at least an hour.

    Crispin's definition of a "moderately secure operating system": a
    "moderately secure operating system" is one that would withstand
    an attack by one of its architects for at least an hour even if
    the management of the system are total idiots who make every
    mistake in the book.
    -------

    From: Dennis G. Perry <PERRY@vax.darpa.mil>
    Date: Apr 6, 1987, 3:19 PM

    Jordan, you are right in your assumptions that people will get annoyed
    that what happened was allowed to happen.

    By the way, I am the program manager of the Arpanet in the Information
    Science and Technology Office of DARPA, located in Roslin (Arlington), not
    the Pentagon.

    I would like suggestions as to what you, or anyone else, think should be
    done to prevent such occurances in the furture.  There are many drastic
    choices one could make.  Is there a reasonable one?  Perhaps some one
    from Sun could volunteer what there action will be in light of this
    revelation.  I certainly hope that the community can come up with a good
    solution, because I know that when the problem gets solved from the top
    the solutions will reflect their concerns.

    Think about this situation and I think you will all agree that this is
    a serious problem that could cripple the Arpanet and anyother net that
    lets things like this happen without control.

    dennis
    -------

Also:

http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1

https://everything2.com/title/Jordan+K.+Hubbard