How 'Artificial Intelligence' Is Slowly Drowning In Its Own Droppings

© 2026 Peter N. M. Hansteen

A website designed to appeal to humans' vanity serves to reveal how the large language models degrade by ingesting each others' unverified output

In early July 2026, I was made aware of the website intheweights.com via a fediverse post. The idea is simple, and appeals to human vanity: You type in your name, and the site checks the various large language models for any data it can find on you in the models.

---

Note: This piece is also available without trackers but classic formatting only here.

---

The post I responded to appears to be no longer available, but I checked out my own results and posted the results with screenshots:

Post by @pitrh@mastodon.social

View on Mastodon

If for some reason the embedded post is not readable, I also saved screenshots of the site output.

First up, the main result, with what seems to be the highest confidence score:

Initial highest scored intheweights.com assessment based on my name July 2 2026:
PETER N. M. HANSTEEN
OPENBSD PF FIREWALL AUTHOR
> 608 STRENGTH • TOP 6%
GPT-5.5 SAYS
NORWEGIAN TECHNOLOGIST AND AUTHOR KNOWN FOR OPENBSD, PF FIREWALL ADVOCACY, AND THE BOOK THE BOOK OF PF•"

Fair enough, I advocate OpenBSD but did not write any part of the operating system, I wrote The Book of PF, and I work in the tech industry.

I addition, there were two entries that I was pleased to see the site labeled as likely hallucinations:

Initial intheweights.com assessment 1 of 2 of likely hallucinations based on my name July 2 2026:
PETER N. M. HANSTEEN
NORWEGIAN SOLAR PHYSICIST
52 STRENGTH•
GROK 4.20 SAYS
NORWEGIAN SOLAR PHYSICIST SPECIALIZING IN THE SUN'S CHROMOSPHERE, TRANSITION REGION, AND CORONAL HEATING. "

That is definitely not me. For context, according to the Name Search service on Statistics Norway's (Statistisk Sentralbyrå) website, we are only 140 persons who have Hansteen as their surname, and Fewer than four people or no one has the name Peter Nicolai Mathias Hansteen, and to my knowledge I do not share first names with any living relative.

I am no longer active on the site that used to be called Twitter, which is where I assume Grok finds a significant subset of the data it ingests. But while there, since the late noughties until shortly after the site was sold, I may very well have posted about global warming with links to actual studies that involve solar phenomena.

---

Update 2026-08-02: Prompted by something else entirely, I checked Google Scholar (I refuse to give a direct link), which seems to confuse me with one VH Hansteen, who does publish in that field, with several publications where one H Peter is a co-author.

I am sure somebody will come up with a snappy and snarky term for that phenomenon.

---

The next entry I found a bit more bizarre, to wit:

Initial intheweights.com assessment 2 of 2 of likely hallucinations based on my name July 2 2026:
PETER NM. HANSTEEN NORWEGIAN GEOPHYSICIST

46 STRENGTH <
QWEN3 SB SAYS
A NORWEGIAN GEOLOGIST AND ACADEMIC, KNOWN FOR CONTRIBUTIONS TO GEOPHYSICS AND EARTH SCIENCES.

That one is a bit strange. While I do have a living close relative who is a geologist with publications in academic journals, this entry seems to have taken most of its data from the biography of Christopher Hansteen. We are related, but as can seen from the Wikpedia article, separated by several generations.

But at least, the site considered both of those to be likely hallucinations.

But give it a couple of weeks

For whatever reason (er, actually my laziness), the intheweights.com tab stayed open in my browser, and I went back to check the results on July 21st.

The first entry was much the same,

Highest scored intheweights.com assessment based on my name July 21 2026:
PETER N. M. HANSTEEN
OPENBSD PF fIREWALL AUTHOR
731 STRENGTH • TOP 4%
€ GPT-5. 5 SAYS
NORWEGIAN TECHNOLOGIST AND AUTHOR KNOWN FOR OPENBSD, PF FIREWALL ADVOCACY, AND THE BOOK THE BOOK OF PF.

Oddly enough, the confidence had risen a bit, and I was now in the top four percent. I still did not write that operating system, I only use it and like it enough that I will likely talk about it to strangers.

The second had apparently been moved up the ranks and was no longer considered a likely hallucination:

Second highest intheweights.com assessment based on my name July 21 2026:
PETER N. M. HANSTEEN
NORWEGIAN SOLAR PHYSICIST
43 STRENGTH • TOP 95%
GROK 4.20 SAYS
NORWEGIAN SOLAR PHYSICIST SPECIALIZING IN THE SUN'S CHROMOSPHERE, TRANSITION REGION, AND CORONAL HEATING.

So what happened here is that Grok had grown more confident in its most likely imaginary physicist. Another close but no longer living relative was a physicist, but the description does not map well to their actual published work.

Then thankfully, the last item was still considered a likely hallucination:

Third ranked intheweights.com assessment based, rated likely hallucination, on my name July 21 2026:
PETER N. M. HANSTEEN
NORWEGIAN GEOPHYSICIST
38 STRENGTH <
QWEN3 SB SAYS
A NORWEGIAN GEOLOGIST AND ACADEMIC, KNOWN FOR CONTRIBUTIONS TO GEOPHYSICS AND EARTH SCIENCES.

So the conclusion here seems to be that while the confidence in the largely fact based first item had risen overall, so had the rating for one of the likely hallucinations.

The explanation here is likely that for my material, it is very much available online, some of it under copyright but free, some under copyright but without technologically enforced restrictions, and some is actually under a free license for anyone to use as they wish.

For my relatives who are actual academics, both the living and the deceased, more than likely they have published more material than I have in total, but a large part of that material either predates the Internet or is hidden behind paywalls. Then again my relative the geologist insists that the bulk of their material is indeed freely available online with sufficient information to separate their work from mine.

So there we have it: The large language models can only ingest what is placed within reach, and they work in parallel to generate material based on what their inner, opaque, and possibly quite tangled, logic considers probable. Then it seems that the output generated soon after is fed back to the large language models as training data for themselves.

This means that more likely than not, more material will be attributed to the more visible person in the training data, based on their version of probability, than is actually appropriate. We saw an early version of this in Those Titles the AI Bot Thought I Had Written (also here).

With the large language models seeming to grow more confident of the actual existence of their own fictional creations, how likely is it that they will soon sink out of sight, buried in layer upon layer of unverified output from themselves and their peers?

My best hope is that we will be able to clean the Internet of their nonsense before it is too late.

---

How 'Artificial Intelligence' Is Slowly Drowning In Its Own Droppings is © 2026 Peter N. M. Hansteen (published 2026-07-22)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

Those Titles the AI Bot Thought I Had Written

© 2024 Peter N. M. Hansteen (2024-12-06)

Beware of robots generating your references. They could very well take it upon themselves to lie on your behalf. Testing in 2023, I observed a whopping 25% truth in the result. What is the truth rating in 2024?

Note: This is a field note that was originally intended as a fediverse (mastodon) post, but the text would have overflowed into a thread and would then have become quite cumbersome.

Back in the early days of generative Artificial Intelligence revolution (read: late 2023) I had heard enough of the hype that I did a few minimal experiments (see my earilier notes ChatGPT opines on IPv6 procastination, waxes lyrical over OpenBSD (also prettified, tracked) and I asked ChatGPT to write a pf.conf to spec, 2023-06-07 version (also prettified, tracked)) that had me conclude that for my own purposes at least, the technology as it appeared at the time was unlikely to improve productivity for myself or any of my immediate colleagues.

The TL;DR would be that since the models will only become somewhat useful if they are trained on a sufficient volume of material within the topic of interest, clearly a lot of work needed to be done. Basically, the gaps in the training data seemed to fit essentially most of the field I deal with professionally, beyond of course a few trivial generalities. And those were cracks that could only be papered over at the cost of pulping several good-sized forests.

---

Note: This piece is also available without trackers but classic formatting only here.

---

Not easily discouraged, I thought maybe, it just might be, that the data the language model trainers had sucked in from public sources on the Internet would contain enough factual information that the system would be able to cough up a reasonable bibliography of what I had written.

So I opened another session with the same robot and typed

---

what are the most read articles by Peter N. M. Hansteen?

---

After a brief pause, the cursor started moving and presented its result:

---

As an AI language model, I don't have real-time access to up-to-date information or specific statistics on article readership. Additionally, my training only goes up until September 2021, so I may not be aware of the most recent articles published by Peter N. M. Hansteen. However, I can provide you with some notable articles that Peter N. M. Hansteen has written up until my knowledge cutoff date.

Peter N. M. Hansteen is a well-known author and has written extensively on the topic of networking and computer security, particularly focused on OpenBSD and firewalls. Some of his notable articles include:

"The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall" - This is a comprehensive guide that provides practical information on setting up and configuring firewalls using OpenBSD's PF (Packet Filter) system. It covers topics such as filtering network traffic, NAT (Network Address Translation), and quality of service (QoS).

"Building Firewalls with OpenBSD and PF" - This article discusses the concepts and techniques involved in building firewalls using OpenBSD and its PF system. It provides practical examples and guidance on firewall design and implementation.

"Securing the Edge: A Practical Introduction to OpenBSD Packet Filtering" - This article focuses on the fundamentals of packet filtering using OpenBSD's PF system. It covers topics such as rule syntax, filtering criteria, and advanced filtering techniques.

"So You Want to Be a Firewall Wizard? Part 1" and "Part 2" - These two-part articles provide an introduction to firewall concepts and techniques, with a focus on OpenBSD and PF. They cover topics such as rule sets, network address translation, and handling complex firewall configurations.

Please note that the popularity of articles can vary over time, and it's always best to refer to the author's official website, blog, or other reliable sources for the most up-to-date information on their publications and readership.

---

(Preserved as text, cut and pasted from the website, here)

My initial reaction when I saw the result was a sound you would associate with something quite unpleasant happening.

I'll take one paragraph at the time.

Though it was probably intended as a disclaimer, the claims in the first paragraph there are, as we shall see, only 25% true, if even that.

The second paragraph has a description of me that is on par for what would turn up in a not terribly specific search using your favorite Internet search engine.

Just how well known an author and what consitutes extensive writing is open for discussion, but at least the paragraph as a whole is not counter-factual.

I did write The Book of PF. The third edition of the book would have been available via that link and a few others at the September 2021 cutoff date, and the description is a valid, if somewhat short of exhaustive, description of the book when it comes to subjects covered.

However, the three titles that follow were not written by me.

I think I have read articles matching those titles at some point, but the actual authors of those pieces would not be terribly pleased to have them attributed to somebody else. I would assume their publishers would like a word there too.

I have mentioned this session a few times to colleagues and friends over refreshments, but I have not really give it much thought since.

But the chatter about how the AI bot herders are heroically fighting their charges' tendency to hallucinate seems to never come to an end.

So my question to you is: Has the situation actually improved since then?

If you have any useful experience to share or other input on the subject, please follow up with a comment in the thread where you found the reference to this note.

A reasonable followup question would be,

Are the efforts that go into (what is currently labeled as) Artificial Intelligence starting to pay off?

followed by

or are we for now better served by having the abbreviation "AI" (perhaps more reasonably) expand to "Artificial Inanity"?

Come to think of it, unless the various bots that scrape the net actually obey my robots.txt directives, publishing even this text here will lead to further confusion over who actually wrote those titles. This is bound to turn up in the AI slop presented to some poor soul looking for valid information.

Again, if you have any useful insigths or experiences you want to share on the subject, please follow up with a comment where you found the link to this piece, or post to this fediverse thread (raw link https://mastodon.social/@pitrh/113612679976829404).

I look forward to reading your comments.

---

Those Titles the AI Bot Thought I Had Written is © 2024 Peter N. M. Hansteen (published 2024-12-06)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

At EuroBSDcon 2025, there will be a Network Management with the OpenBSD Packet Filter Toolset session, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon. The latest information I have is that physical copies will be shipping by the end of January 2026

---

I asked ChatGPT to write a pf.conf to spec, 2023-06-07 version

© 2023 Peter Hansteen

ChatGPT prompt and answer

Prompted by this exchange

I just had to check what its capabilities were. Here is what happened:

Note: A version without trackers but “classical” formatting is available here.

---

PNMH::
write an OpenBSD pf.conf that blocks by default, allows traffic from the local host, allows name resolution, network time and ssh out from the DMZ, lets http and https through to the web server, and allows smtp that has been whitelisted by spamd to pass to the mail server.

To which ChatGPT answered:

Sure! Here's an example of an OpenBSD pf.conf configuration file that meets your requirements:

# Define network interfaces
ext_if = "em0"  # External interface (connected to the internet)
dmz_if = "em1"  # DMZ interface
lan_if = "em2"  # Local LAN interface

# Set default block policy
block all

# Allow traffic from the local host
pass quick on lo0 all

# Allow name resolution (DNS)
pass out on $ext_if inet proto udp to any port domain

# Allow network time (NTP)
pass out on $ext_if inet proto udp to any port ntp

# Allow SSH out from the DMZ
pass out on $dmz_if inet proto tcp to any port ssh

# Allow HTTP and HTTPS traffic to the web server
pass in on $ext_if inet proto tcp to $ext_if port { http, https }

# Allow SMTP traffic that has been whitelisted by spamd to the mail server
pass in on $ext_if inet proto tcp to $ext_if port smtp \
    rdr-to $lan_if port spamd

# Log and block any remaining traffic
block log all

    

Make sure to replace the interface names (em0, em1, em2) with the appropriate interface names on your OpenBSD system. Additionally, adjust the names of the web server and mail server as needed.

Remember to save the pf.conf file in the correct location (/etc/pf.conf by default on OpenBSD) and reload the firewall rules using the pfctl command for the changes to take effect.

Note: This configuration assumes you have already set up spamd and whitelisted the desired SMTP traffic.

---

I will leave it as an excercise to the reader to point out why this would earn an F.

Or you can take in things like our Network mananagement with the OpenBSD Packet Filter Toolset or just get yourself a copy of The Book of PF, as an option after after looking up the PF user guide.

Update: Point it at specific sources! After posting the original result I got a few responses, with lots of smileys and other emojis.

Then, a colleague advised that pointing the system at specific sources such as the man pages would likely produce better results.

So here is the second exchange:

PNMH:
based on the information in https://man.openbsd.org/pf.conf and https://man.openbsd.org/spamd write an OpenBSD pf.conf that blocks by default, allows traffic from the local host, allows name resolution, network time and ssh out from the DMZ, lets http and https through to the web server, and allows smtp that has been whitelisted by spamd to pass to the mail server.

The response was,

Certainly! Here's an updated version of the pf.conf configuration file based on the information from the OpenBSD man pages for pf.conf and spamd:

# Define macros for network interfaces and IP addresses
ext_if = "em0"  # External interface (connected to the internet)
dmz_if = "em1"  # DMZ interface
lan_if = "em2"  # Local LAN interface

# Set default block policy
block all

# Allow traffic from the local host
pass quick on lo0 all

# Allow name resolution (DNS)
pass out on $ext_if inet proto udp to any port domain

# Allow network time (NTP)
pass out on $ext_if inet proto udp to any port ntp

# Allow SSH out from the DMZ
pass out on $dmz_if inet proto tcp to any port ssh

# Allow HTTP and HTTPS traffic to the web server
pass in on $ext_if inet proto tcp to $ext_if port { http, https }

# Allow SMTP traffic that has been whitelisted by spamd to the mail server
table  persist file "/etc/spamd.whitelist"
pass in on $ext_if inet proto tcp to $ext_if port smtp \
    rdr-to $lan_if port spamd if-bound \
    spammed by 

# Log and block any remaining traffic
block log all

In this version, we have added the table, which is populated by the /etc/spamd.whitelist file. This file should contain the IP addresses or networks that have been whitelisted by spamd. Make sure to save the pf.conf file in the correct location (/etc/pf.conf by default on OpenBSD) and reload the firewall rules using the pfctl command for the changes to take effect. Please note that this configuration assumes you have correctly set up spamd and have populated the /etc/spamd.whitelist file with the desired IP addresses or networks.

---

It did pick up a few clues from the man pages I fed it, but it still has fairly obvious flaws that would stem from it not being able to take in the actual interdependencies of even a very clearly worded, if slightly complex document like man pf.conf.

But then what would happen if we in addition feed it the PF user guide?

Let's try:

PNMH:
based on the information in https://www.openbsd.org/faq/pf/index.html and links therein as well as https://man.openbsd.org/pf.conf and https://man.openbsd.org/spamd write an OpenBSD pf.conf that blocks by default, allows traffic from the local host, allows name resolution, network time and ssh out from the DMZ, lets http and https through to the web server, and allows smtp that has been whitelisted by spamd to pass to the mail server.

The third try response was,

Certainly! Here's an updated version of the pf.conf configuration file based on the OpenBSD FAQ for pf, as well as the pf.conf and spamd man pages:

# Define macros for network interfaces and IP addresses
ext_if = "em0"  # External interface (connected to the internet)
dmz_if = "em1"  # DMZ interface
lan_if = "em2"  # Local LAN interface

# Set default block policy
block all

# Allow traffic from the local host
pass quick on lo0 all

# Allow name resolution (DNS)
pass out on $ext_if inet proto { udp, tcp } to any port domain

# Allow network time (NTP)
pass out on $ext_if inet proto udp to any port ntp

# Allow SSH out from the DMZ
pass out on $dmz_if inet proto tcp to any port ssh

# Allow HTTP and HTTPS traffic to the web server
pass in on $ext_if inet proto { tcp, udp } to $ext_if port { http, https }

# Allow SMTP traffic that has been whitelisted by spamd to the mail server
table  persist file "/etc/spamd.whitelist"
pass in on $ext_if inet proto tcp to $ext_if port smtp \
    rdr-to $lan_if port spamd if-bound \
    spammed by 

# Log and block any remaining traffic
block log all
    

In this version, the rules have been updated to align with the OpenBSD pf FAQ and provide a more comprehensive configuration. Make sure to save the pf.conf file in the correct location (/etc/pf.conf by default on OpenBSD) and reload the firewall rules using the pfctl command for the changes to take effect. Please note that this configuration assumes you have correctly set up spamd and have populated the /etc/spamd.whitelist file with the desired IP addresses or networks.

---

It is fairly obvious that this would not have passed the pfctl parser, and that feeding it the relevant man pages as well as the PF user guide did not make the system more capable of understanding how rule evaluation actually works.

In fact, all three tries would be functionally equivalent to the rather terser

block

But arriving at that conclusion would require the reader to actually understand the content fed to it.

---

My favorite take on this so far came via Mastodon, from Mark Shane Hayden, in this toot, which reads in full:

@mwl @pitrh I suppose we can take solace in that if Skynet ever came into existence for real it would be unreachable

ChatGPT opines on IPv6 procastination, waxes lyrical over OpenBSD

© 2023 Peter Hansteen

Are the robots indeed capable of helping us in our tech writing, or even help our creativity? This writer tries on the robot that's been in the news for size. OpenBSD material to be had at the end.

For a number of years, those involved in networking things have all had one thing in common: A TODO item about either getting started implementing IPv6 in their networks, or at least getting started on planning to go dual-stack or even purely IPv6.

And as anybody who follows networking things is aware, IPv6 adoption in some parts of the world has been advancing hardly at all, even in jurisdictions where actual legislation is in place that mandates IPv6 use and leaves IPv4 support as an allowable option.

I have been involved in some capacity or other in enough of these efforts over the years that I have been pondering writing a piece about the slow rate of adoption, and of course I hoped to be able to write something witty or at least entertaining about something that is in fact, to some of us at least, a somewhat frustrating situation.

Then today I attended an internal presentation by a colleague that included some examples of ChatGPT use writing as well as programming.

The demonstration was enough fun that I thought I would see if the robot could offer some insights and perhaps get me started on writing the piece I had been pondering.

Signing up and getting access to a trial was painless and quick, so some things have improved since I first tried to access the service a few weeks ago when news about the service first hit.

First try: Please write me a story

The first chat went like this:

PNMH: managers and admins put off setting up IPv6 in their networks. write a short story on how and why they procrastinate and make excuses.

ChatGPT: Once upon a time, in a large corporation, there was a group of managers and administrators responsible for the network infrastructure. They had heard about IPv6, the new internet protocol, and knew that it was important to adopt it to future-proof the company's network. However, they kept putting off the task of implementing IPv6, and s why:

Firstly, they felt overwhelmed by the complexity of IPv6. They were used to IPv4, and the thought of transitioning to a new protocol seemed daunting. They convinced themselves that they needed more time to research and plan the transition thoroughly.

Secondly, they thought that their current IPv4 infrastructure was sufficient, and that there was no need to change anything. They believed that IPv6 adoption was only necessary for larger companies and service providers, not for their organization.

Thirdly, they were concerned about the cost of implementing IPv6. They felt that it would require a significant investment in new hardware, software, and training, and they were not sure if the benefits of IPv6 would justify the expense.

Finally, they were preoccupied with other pressing matters, such as meeting deadlines, managing budgets, and dealing with daily operational issues. IPv6 implementation was not a top priority for them, and they kept pushing it back on their to-do lists.

As time went by, the managers and administrators continued to procrastinate, making excuses and justifications for not implementing IPv6. They were oblivious to the fact that their competitors were already using IPv6 and gaining a competitive edge. They failed to realize that IPv6 adoption was not a choice but a necessity for staying relevant and competitive in the digital age.

In the end, the managers and administrators were forced to implement IPv6 when their IPv4 addresses ran out, causing network disruptions and downtime. They learned the hard way that procrastination and excuses only lead to costly delays and missed opportunities.

Also accesssible as pure text as chatgpt_on_ipv6_procrastination.txt

As one of my mastodon commenters said, it looks like this robot has peeked into too many IT Management meetings.

I would myself have been more worried about ensuring that services we run are accessible to IPv6-only networks, and for that matter that users in our own networks should be able to access services in IPv6-only parts of the Internet.

This shows that whatever they trained the system on seems to have included the most frequently cited reasons for not actually moving forward with IPv6 implemenation or other network modernization. But the thing had stylistic issues and I was looking for something fresher. So on to the next try.

Second try: Tease the legal requirements

Some stakeholders, such as Norwegian public sector entities, are under legal obligation to make their services available on IPv6 and to enable clients in their network to access IPv6 resources, the final deadline for that implementation in principle passed at the end of 2022.

So I tried stressing that point in my second try. Here is a record of hat session:

PNMH: why do network designers always postpone their IPv6 implementation even past legally required deadlines?

ChatGPT: There are a few reasons why network designers may postpone their IPv6 implementation, even past legally required deadlines:

Compatibility issues: IPv4 and IPv6 are not directly compatible with each other, which means that devices using IPv4 cannot communicate directly with devices using IPv6. This creates interoperability issues that can make it difficult for organizations to transition to IPv6 without causing disruptions to their existing networks.

Cost: Implementing IPv6 requires an investment in new hardware, software, and training. For some organizations, the cost of upgrading their infrastructure to support IPv6 may be prohibitive, especially if they have already invested heavily in their existing IPv4 infrastructure.

Lack of perceived need: Some organizations may not see the urgency in transitioning to IPv6, especially if they are not experiencing any immediate problems with their IPv4 networks. This can lead to a "wait and see" approach, where organizations postpone their IPv6 implementation until they are forced to do so by external factors.

Complexity: IPv6 is more complex than IPv4, which can make it more difficult for network designers to implement and manage. This complexity can also make it more challenging to troubleshoot network issues that may arise after the transition to IPv6.

Lack of IPv6 support from vendors: Some network hardware and software vendors may not yet fully support IPv6, which can make it difficult for organizations to transition to IPv6 without making significant changes to their existing infrastructure.

Overall, transitioning to IPv6 requires a significant investment of time and resources, and network designers may delay implementation for various reasons. However, as the pool of available IPv4 addresses continues to dwindle, and as more organizations begin to adopt IPv6, it is becoming increasingly important for organizations to make the transition to IPv6 in a timely manner.

Also accesssible as pure text as chatgpt_on_ipv6_procrastination_legal.txt

This was actually an improvement. The reachability point is made clearer here, and the system clearly picked up on the legal requirement part.

Whether IPv6 is in fact more complex than IPv4 is debatable, but the robot is right that this is at least a common perception, factual or otherwise.

A clear improvement, but when I publish something, I make an effort to make it witty or at least a bit snarky.

Time to tweak the query once again.

Third try: Once more, with wit and feeling

My third and final IPv6-themed query of the day ran like this:

PNMH: write a funny story about why IPv6 implementation is so hard and scary to plan for and actually do

ChatGPT: Once upon a time, there was a small company that had been using IPv4 for all their networking needs. One day, their IT manager decided that it was time to upgrade to IPv6.

Excited by the prospect of faster speeds and improved security, the IT manager decided to jump right in and start planning for the implementation of IPv6. However, as they began to research and plan, they soon discovered that implementing IPv6 was not as easy as they had thought.

First, they realized that they would need to upgrade all of their networking equipment to support IPv6. This was going to be expensive, but the IT manager was determined to make it happen. They went ahead and ordered all the necessary equipment and started scheduling the installation.

However, as the installation date approached, the IT manager began to feel a sense of dread. What if the new equipment didn't work with their existing systems? What if they couldn't get everything up and running in time?

Feeling overwhelmed, the IT manager decided to take a break and watch some TV. As luck would have it, they stumbled upon a horror movie about a group of people who get lost in a network of tunnels and are pursued by an army of rogue IPv6 addresses.

Suddenly, the IT manager's fear of implementing IPv6 reached new heights. They couldn't shake the feeling that something was going to go horribly wrong. They started imagining all sorts of terrifying scenarios: their network crashing, their data being compromised, even their computers coming to life and taking over the office!

In the end, the IT manager decided to put the IPv6 implementation on hold indefinitely. They just couldn't bring themselves to take the risk. And so, the small company continued to chug along on IPv4, while their competitors raced ahead with faster, more secure networks.

The moral of the story? Don't let fear hold you back from upgrading to IPv6. Sure, it can be scary and complicated, but with the right planning and support, you can make the transition smoothly and reap the benefits of a faster, more secure network. And who knows, maybe you'll even get a good horror story out of it!

Also accesssible as pure text as chatgpt_on_ipv6_procrastination_funny.txt

Ouch. The Once upon a time lead-in is back. But the rest is something that I might actually manage to editstomptwistcrunch into something presentable given enough coffee and time.

I have had worse material handed to me to edit by humans, and I may have done worse first drafts myself when writing when I should not have.

There are some logic issues in there, but nothing that could not be edited out or around.

By this time of the day, I had to go attend to a few things with deadlines, but I took the time to do a final query on a slightly different topic.

And now for something completely different: Write me OpenBSD poetry

So after looking into a slightly painful topic, what better than to see what our robot friend has learned about our favorite operating system and poetry:

PNMH: write a poem about OpenBSD

ChatGPT: In a world of code and bytes,
Where hackers lurk in endless nights,
There shines a system, strong and bright,
A fortress of security, with OpenBSD in sight.

Like a lighthouse on a stormy shore,
It guards the network from cyber war,
With firewalls, cryptography, and more,
It stands tall, unyielding, forevermore.

In its heart, a philosophy,
Of code that's clean and free,
No backdoors, no secret keys,
Just trust and transparency.

From humble beginnings, it arose,
A gift to the world, from the chosen few,
A beacon of hope, for those who oppose,
The tyranny of those who seek to control.

So let us raise a toast, to OpenBSD,
A shining example of what can be,
When we dare to dream, and we dare to be free,
For a better tomorrow, for you and for me.

Also accesssible as pure text as chatgpt_poem_about_openbsd.txt

I just had to post that to openbsd-misc, and it will be interesting to see how the thread develops. And is a fitting end to what is, I think, the piece I have posted under my own name that contains the least material written by myself.

Good night and good luck.

<