Use REAL UUIDs in Test2

Changes for 0.002002 - 2024-04-25T12:16:42+01:00

• Fix a debian issue (#2)

Parse plain English date/time range strings

Changes for v1.0.1 - 2024-04-19T16:50:33Z

• Update README (Andrew Hewus Fresh)
• Pull request #2: SM-4807 (James Hammer)
• SM-4807 Add POD for new features (James Hammer)
• SM-4807 Correct thirteenths to thirteenth typo (James Hammer)

Okay I thought I'd share this recent post here on the #Fediverse. To give it some context, it's an answer to a common question, often a misunderstanding (even by many knowledgeable folks) as to just how we got here.

So first, the question, posed HERE.

And my answer follows below:

There's a lot of apples and oranges here. And everyone had a lot of good points made, but your question is simple, and has a very simple answer. I'll endeavor to address that directly, but do need to tend to some of what has already been said.

## Scroll down to the tl;dr for the succinct answer of your question

Ethernet, ARCNET, Token Ring, Thick net (RG-59), Thin net (RG-58 A/U), and UTP (Cat 3, Cat 5, and Cat 6 unshielded twisted pair, Etc.) really have zero bearing on your question insofar as IP is concerned. All of these specifications relate to the definition of technologies that, although are indeed addressed in the OSI model which is indeed very much in use to this day,but are outside the scope of Internet Protocol. I'll come back to this in a minute.

It's quite common to say TCP/IP, but really, it's just IP. For example, we have TCP ports and we have UDP ports in firewalling. i.e., TCP is Transmission Control Protocol and handles the delivery of data in the form of packets. IP handles the routing itself so those messages can arrive to and from the end points. Uniform Data Protocol is another delivery system that does not guarantee arrival but operates on a best effort basis, while TCP is much chattier as it guarantees delivery and retransmission of missed packets - UDP is pretty efficient but in the case of say, a phone call, a packet here and there won't be missed by the human ear.

That's a very simplistic high level-view that will only stand up to the most basic of scrutiny, but this isn't a class on internetworking ;) If you just want to be able to understand conceptually, my definition will suffice.

Networking (LAN) topologies like Token Ring, ARCNET, and Ethernet aren't anywhere in the IP stack, but figure prominently in the OSI stack. I'm not going to go into the details of how these work, or the physical connection methods used like Vampire Taps, Thin net, or twisted pair with RJ-45 terminators, but their relationship will become obvious in a moment.

The OSI model unfolds like so, remember this little mnemonic to keep it straight so you always know:

> People Don't Need To See Paula Abdul

Okay, touched on already, but not really treated, is the description of that little memory aid.

> Physical, Data Link, Network, Transport, Session, Presentation, and Application layers (From bottom to top).

The physical and Data Link layers cover things like the cabling methods described above,and you're probably familiar with MAC Addresses (medium access control) on NICs (network interface controller). These correlate to the first two layers of the OSI stack, namely, the Physical (obvious - you can touch it), and the Data Link layer - how each host's NIC and switches on each LAN segment talk to each other and decide which packets are designated for whom (People Don't).

In software engineering, we're concerned mostly with the Session, Presentation, and Application layers (See Paula Abdul). Detailed explanation of these top three layers is outside the scope of this discussion.

The Beauty of the OSI model is that each layer on one host (or program) talks to exclusively with the same layer of the program or hardware on the other host it is communicating with - or so it believes it is, because, as should be obvious, is has to pass its information down the stack to the next layer below itself, and then when it arrives at the other host, it passes that information back up the stack until it reaches the very top (Abdul) of the stack - the application.

Not all communication involves all of the stacks. At the LAN (Local Area Network) level, we're mostly concerned with the Physical and Data Link layers - we're just trying to get some packet that we aren't concerned about the contents of from one box to another. But that packet probably includes information that goes all the way up the stack.

For instance, NIC #1 has the MAC: 00:b0:d0:63:c2:26 and NIC #2 has a MAC of 00:00:5e:c0:53:af. There's communication between these two NICs over the Ethernet on this LAN segment. One says I have a packet for 00:00:5e:c0:53:af and then two answers and says, "Hey that's me!" Nobody else has that address on the LAN, so they don't answer and stop listening for the payload.

Now for Internet Protocol (IP) and TCP/UDP (Transmission Control Protocol and User Datagram Protocol):

IP corresponds to Layer 3 (Need) - the Network Layer of the **OSI Model.

TCP and UDP correspond to Layer 4 (To) - the Transport Layer of the OSI model.

That covers the entire OSI model and how TCP/IP correspond to it - almost. You're not getting off that easy today.

There's actually a bit of conflation and overlapping there. Just like in real life, it's never that cut and dried. For that, we have the following excellent explanation and drill down thanks to Julia Evans:

- Layer 2 (Don't) corresponds to Ethernet.
- Layer 3 (Need) corresponds to IP.
- Layer 4 (To) corresponds to TCP or UDP (or ICMP etc)
- Layer 7 (Abdul) corresponds to whatever is inside the TCP or UDP packet (for example a DNS query)

You may wish to give her page a gander for just a bit more of a deeper dive.

Now let's talk about what might be a bit of a misconception on the part of some, or at least, a bit of a foggy conflation between that of the specification of the OSI model and a Company called Bolt Beranek & Newman (BBN) a government contractor tasked with developing the IP stack networking code.

The TCP/IP you know and depend upon today wasn't written by them, and to suggest that it was the OSI model that was scrapped instead of BBN's product is a bit of a misunderstanding. As you can see from above, the OSI model is very much alive and well, and factors into your everyday life, encompasses software development and communications, device manufacturing and engineering, as well as routing and delivery of information.

This next part is rather opinionated, and the way that many of us choose to remember our history of UNIX, the ARPANET, the NSFnet, and the Internet:

The IP stack you know and use everyday was fathered by Bill Joy, who arrived at UC Berkeley in (IIRC) 1974), created vi because ed just wasn't cutting it when he wanted a full screen editor to write Berkeley UNIX (BSD), including TCP/IP, and co-founded Sun Microsystems (SunOS / Solaris):

> Bill Joy just didn’t feel like this (the BBN code) was as efficient as he could do if he did it himself. And so Joy just rewrote it. Here the stuff was delivered to him, he said, “That’s a bunch of junk,” and he redid it. There was no debate at all. He just unilaterally redid it.

Because UNIX was hitherto an AT&T product, and because government contracting has always been rife with interminable vacillating and pontificating, BBN never actually managed to produce code for the the IP stack that could really be relied upon. In short, it kinda sucked. Bad.

I highly recommend that you take a look at this excellent resource explaining the OSI model.

# tl;dr:

So! You've decided to scroll down and skip all of the other stuff to get the straight dope on the answer to your question. Here it is:

> What were the major things that caused TCP/IP to become the internet standard protocol?

The ARPANET (and where I worked, what was to become specifically the MILNET portion of that) had a mandate to replace NCP (Network Control Protocol) with IP (Internet Protocol). We did a dry run and literally over two thirds of the Internet (ARPANET) at that time disappeared, because people are lazy, software has bugs, you name it. There were lots of reasons. But that only lasted the better part of a day for the most part.

At that time the ARPANET really only consisted of Universities, big Defense contractors and U.S. Military facilities. Now, if you'll do a bit of digging around, you'll discover that there was really no such thing as NCP - that is, for the most part, what the film industry refers to as a retcon, meaning that we, as an industry, retroactively went back and came up with a way to explain away replacing a protocol that didn't really exist - a backstory, if you will. Sure, there was NCP, it was mostly a kludge of heterogeneous management and communications programs that varied from system to system, site to site, with several commonalities and inconsistencies that were hobbled together with bailing twine, coat hangers, and duct tape (for lack of a better metaphor).

So we really, really, needed something as uniform and ubiquitous as the promise that Internet Protocol would deliver. Because Bill Joy and others had done so much work at UC Berkeley, we actually had 4.1BSD (4.1a) to work with on our DEC machinery. As a junior member of my division, in both age and experience, I was given the task of, let's say throwing the switch on some of our machines, so to speak, when we cut over from the NCP spaghetti and henceforth embraced TCP/IP no matter what, on Flag Day - 01 January 1983.

So you see,the adoption of Internet Protocol was not a de facto occurrence - it was de jure, a government mandate to occur at a specific time on a specific day.

It literally had nothing to do with popularity or some kind of organic adoption, the erroneously described, so-called demise of the OSI model, or any physical network topology.

### DARPA said 01 January 1983 and that's it, and that was it - Flag Day.

Sure, it took a few days for several facilities to come up (anyone not running IP was summarily and unceremoniously cut off from the ARPANET).

And one also needs to consider that it wasn't every machine - we only had some machines that were Internet hosts. We still had a lot of mainframes and mini computers, etc., that were interconnected within our facilities in a hodgepodge or some other fashion. Nowadays we have a tendency to be somewhat incredulous if every device doesn't directly connect over IP to the Internet in some way. That wasn't the case back then - you passed traffic internally, sometimes by unmounting tapes from one machine and mounting them on another.

There was a lot of hand wringing, stress, boatloads of frustration, and concern by people over keeping their jobs all over the world. But that's why and when it happened. Six months later in the UNIX portions of networks we had much greater stability with the release of 4.2BSD, but it wouldn't really be until a few years later Net2 was released that things settled down with the virtually flawless networking stability that we enjoy today.

Enjoy!

#tallship #DARPA #IP #Internet_Protocol #Computer_History #internetworking #Internet #ARPANET #MILNET #NSFnet #Bill_Joy #BBN #UNIX #BSD

⛵

.

Make new tickets from correspondence

Changes for 0.04

• Installation instructions correction (Codeberg issue #1 / RT #151741)
• Action path correction from Andreas Wandel (Codeberg issue #2 / RT #151742)
• Perldoc updated to match README

Make new tickets from correspondence

Changes for 0.03

• Installation instructions correction (Codeberg issue #1 / RT #151741)
• Action path correction from Andreas Wandel (Codeberg issue #2 / RT #151742)

Maintain and serve a REST API to search PGXN mirrors

Changes for 0.20.0

• Removed the `Capfile` and `eg` directory. Examples for managing PGXN can now be found in the pgxn/pgxn-ops GitHub repository.
• Switched from Text::Markdown to CommonMark for parsing and formatting Markdown files (but not MultiMarkdown files). This allows code fences to work and generates nicer HTML in general, but is stricter about certain things.
• The docs indexer now indexes a distribution's README if it is the only documentation it finds in the distribution (#12).
• The docs indexer now strictly links an extension to the doc file specified via the `docfile` key in its `provides` object, even if it's a README (#10).
• The indexer will now index a testing release if there are no stable releases, and will index an unstable release if there are neither stable nor testing releases (#2).
• Updated the SemVer regex when parsing rsync output to the official version published in https://regex101.com/r/vkijKf/ (#16).
• Fix unzipping of distributions to ensure that all directories are readable and executable but not writeable by all, and that files are only readable by all (#15).
• Dropped support for Perl 5.10 and 5.12.

A SQL Database object abstraction class

Changes for v1.1.1 - 2024-01-05T10:36:08Z

• Correcting minor issue with the use of constants in unit tests (Gitlab #2)
• Correcting an oversight (bug) in DB:😮bject:😛ostgres::Query in method on_conflict()
• Correcting number formatting (Gitlab #1)

parse XLSX files

Changes for 0.29 - 2024-01-02

• Merge pull request #1 from theevilapplepie/master: Fix for 'Argument "" isn't numeric in addition (+) at /usr/local/shar…
• Merge pull request #2 from oharakouhei/master Incorrect cell values due to phonetic data doy#72
• Merge pull request #3 from nickzoic/master: Fix die message in parse()
• Merge pull request #4 from mazurin/master: Cannot open password protected SHA1 encrypted files. doy#68
• Merge pull request #5 from danderman/master: use date format detection based on Spreadsheet:🤐LSX
• Merge pull request #6 from gquipster/master: Add rudimentary support for hyperlinks in cells

Mapping Perl releases on CPAN to the location of the tarballs via MetaCPAN API

Changes for 0.008 - 2024-01-01T00:52:55Z

• Add checksum_sha256 (#2)

6. Creative and Artistic Gatekeeping
Fuck Big Media, Big Publishing, Academia Inc., Hollywood, and any other industry (and their annoyingly self-congratulatory tastemakers) that exist to dictate which narratives are worth listening to. I can make those decisions myself. And so can you.

It's not like there's a guarantee of better quality coming from The Creative Establishment. The criteria that matters to these people is that it makes money and doesn't upset the wrong people (from point #2).

Convert MultiMarkdown syntax to (X)HTML

Changes for 1.002 - 2023-10-31T19:46:11Z

• new heading_ids_spaces_to_dash feature from Doug Hoyte (#2)

Concise, expressive creation of Class::Meta classes

Changes for 0.14 - 2023-08-02T01:28:30Z

• Better fix for failing tests on Windows, suggested by Eric Brine.
• Fixed broken rt.cpan.org email address.
• Fixed a couple of typos in the Pod. Thanks to Grzegorz Rożniecki for the pull request (#1).
• Fixed no-op version requirement for Class::Meta thanks to Graham Knop (#2).
• Removed the pod tests from the distribution.

A PSGI framework for building REST api's in Perl.

Changes for 0.002 - 2023-07-31

• Alpha release #2
• Includes fixes to documentation

Monitor a directory structure for changes

Changes for 0.21 - 2023-07-13T19:28:40Z

• Cosmetic changes (#2)

a Z80 assembler

Changes for 2.22 - 2023-05-24

• Bug Fixes
• Configure git workflows to test on Ubuntu, MaxOS and Windows
• #2 fails on Perl v10
• Fix failure on Windows machines

Create extensible modules which export things

Changes for 0.11 - 2023-05-21

• Fix bug using method attribute for option with parameter - #2
• More thorough unit tests for method attributes

• to_json and from_json are now documented (Dan Book, PR #2)

• Improved error diagnostics on failed system command
• Set daemon process name to 'yabsmd'
• Moved example init scripts into examples/
• Minor change to example sysvinit script
• Fixed bug rejecting immediate times at hour 20 (#2)
• Switched repo from Dist::Zilla to ExtUtils::MakeMaker
• Ship as a zero-dependency App::FatPacker packed script
• Upgraded minimum Perl version from v5.16.3 to v5.34.0
• Switched to semantic versioning scheme
• Changed license from MIT to GPL3
• Various documentation updates
• Added Changes file (this file)

• Add File::ShareDir::Install to CONFIGURE_REQUIRES #1
• Fix github repo URL #2