Part 2: Building Infrastructure (1990-2005)

IRC Bots, Beowulf Clusters, and Distributed Computing on Commodity Hardware

Author: William Hawkes-Robinson Series: The Path to DGPUNET and SIIMPAF Published: October 2025 Reading Time: ~15 minutes

Series Overview

This is Part 2 of a 5-part series documenting the technical evolution from early introduction to role-playing gaming in 1977 and hobby programming in 1979 to modern distributed GPU computing and self-hosted Artificial Intelligence (AI) infrastructure. The series traces patterns that emerged over four decades and shows how they apply to current challenges in AI development and computational independence. This part focuses on scaling patterns from single systems to networks and building production infrastructure on commodity hardware.

The Series:

• Part 1: Early Foundations (1977-1990) - RPGs, first programs, pattern matching, and establishing core principles
• Part 2 (this article): Building Infrastructure (1990-2005) - IRC bots, NLP, Beowulf clusters, distributed computing, and production systems
• Part 3: Professional Applications (2005-2020) - Therapeutic gaming, educational technology, and real-time AI that outperformed commercial solutions
• Part 4: The GPU Challenge and DGPUNET (2020-2025) - GPU scarcity, centralization concerns, and building distributed GPU infrastructure
• Part 5: SIIMPAF Architecture and Philosophy - Bringing four decades of lessons together in a comprehensive self-hosted AI system

From Single Systems to Networks

While mainframes, UNIX systems, Sun Microsystems (The network is the computer), and others with very extensive resources had been networked since the 1970s, in the latter 1980s and 1990s an increasing momentum grew for individuals and small companies to be able to access resources enabling them to shift increasingly from working on individual computers to thinking about systems that spanned networks. The Internet was no longer just academic - it was becoming a platform for communication, commerce, and increasingly complex applications.

My work during this period increasingly moved from hobby projects to professional systems, from simple automation to distributed infrastructure. The patterns I'd learned on single computers in the 1970s & early 1980s turned out to apply to networks, but with new challenges around coordination, reliability, and scale.

IRC: A Laboratory for Natural Language Processing

Internet Relay Chat (IRC) became a major focus starting in the mid-1990s. I joined various IRC servers and eventually hosted a number of my own. IRC presented interesting technical challenges that connected directly to my earlier work on making computer interactions feel more natural and human-like, while also addressing automation and scaling issues.

Early IRC Bots

My first IRC bots were standard utility tools:

• Welcoming users when they joined a channel
• Providing information on request
• Logging conversations
• Managing basic channel operations
• File management
• User behavior management
• Polls and basic games
• Schedule tasks
• Listener and bridge bots across networks

But I was more interested in bots that could participate in conversations in ways that felt natural. This connected to the NPC work from the 1980s, but with a new constraint: real humans would immediately notice if responses were mechanical or inappropriate.

Making Bots More Human

The challenge wasn't just responding to keywords - it was understanding context, maintaining conversation state, and adapting responses to feel appropriate for the situation.

I experimented with:

• Context tracking: What was discussed recently in the channel?
• User history: Had this person talked to the bot before?
• Conversation flow: Was this a question, statement, or continuation of a previous topic?
• Appropriate timing: When should the bot respond versus staying silent?

The goal usually wasn't to fool anyone into thinking the bot was human, but to make interactions useful and not disruptive. A bot that responded to every mention of a keyword became annoying quickly. A bot that understood when to participate and when to watch was more useful.

Bot Detection Evasion

Some IRC channels automatically banned bots. This created an interesting challenge: could I make bot behavior indistinguishable from human behavior, at least for automated detection systems?

Techniques that helped:

• Variable response times (humans don't respond instantly)
• Occasional "typos" that get corrected
• Natural pause patterns in longer messages
• Context-appropriate silence (not responding to everything)
• Varied phrasing for similar responses

This wasn't about deception - many channels disclosed the bot's nature. It was about exploring what makes interaction feel human versus mechanical. These experiments informed thinking about natural language processing that I'd build upon over the decades.

RPG-Related Bots and MUD-Like Channels

Some of my more complex IRC work involved creating MUD-like (Multi-User Dungeon) game experiences in IRC channels. This combined the RPG work from the 1970s and 1980s with network programming and bot development.

The bot acted as NPCs, and in some cases even as a game master (GM), tracking:

• Character stats and inventories for multiple players
• Room descriptions and connections
• NPCs with behaviors and dialogue
• Combat and skill systems
• Persistence between sessions

Technical challenges included:

• Maintaining game state in memory with proper backup
• Handling concurrent player actions
• Providing individual information privately while managing public channel state
• Recovery from bot crashes without losing game progress
• Managing multiple simultaneous games in different channels

Security Bots

I also developed IRC bots focused on channel security - preventing spam, blocking problematic users, and managing access control. These bots needed to:

• Detect and respond to malicious behavior quickly, and not have to wait for ops/admin intervention
• Minimize false positives (blocking legitimate users)
• Provide clear feedback about why actions were taken
• Allow authorized users to override decisions
• Learn from administrator feedback and growing their core ruleset to be more "adaptive" to different communities/networks

This work led to thinking about intrusion detection and prevention systems more broadly, which became relevant in professional contexts.

Professional Development: SoftDocs and Compspect

My professional work in the 1990s involved systems that needed to be reliable, fast, and maintainable at a level beyond hobby projects.

High-Speed OCR Systems

At SoftDocs and Comspec in Utah, I worked on high-speed, high-capacity Optical Character Recognition (OCR) systems for industrial scanners. These systems served clients including:

• EG&G Chemical Weapons facilities in Tooele, UT
• Various government agencies
• The LDS Church's massive Genealogy department
• Swire International Coca Cola
• and 100+ other clients

The hardware was impressive - industrial scanners and "juke box" robots slotting optical media in and out, with overal systems that could process documents at high speed with excellent image quality. I had to program and maintain the hardware, software, and the full systems making it all work. The software challenge was converting those images to text accurately and taking appropriate actions based on the content.

Key requirements:

• Accuracy: Errors in government documents or genealogy records had real consequences, including complex full-text search across massive (and often fractured) databases
• Speed: Systems needed to keep up with the scanner hardware
• Reliability: Equipment ran for extended periods without manual intervention
• Error handling: Problems needed to be logged and handled gracefully, not crash the system

This work taught me about production systems at a scale beyond anything I'd worked on before. When a system processes thousands of documents daily, even small error rates or efficiency problems compound quickly.

The pattern matching and text processing skills from IRC bot development applied here, but with much stricter accuracy requirements. "Good enough" for a chatbot wasn't good enough for legal or historical documents.

Beowulf Clusters at ITI

As Network & Systems Manager at Information Technology International (ITI) in the late 1990s, I researched and setup in production Beowulf clusters - multiple commodity-grade Linux PCs networked together to act as a single, more powerful system.

The Economic Argument

The appeal of Beowulf clusters was economic. Instead of buying expensive enterprise servers, we could:

• Purchase multiple lower-cost PC systems
• Run Linux (free, reliable, customizable)
• Achieve performance and redundancy comparable to much more expensive solutions
• Scale by adding more (inexpensive) nodes, like RAID or NAS is to drive storage, these clusters were to computing

The trade-off was complexity. A single enterprise server can be simpler to manage than multiple networked systems. But for certain workloads, the economics made sense.

Technical Lessons

Working with Beowulf clusters taught me:

1. Network is often the bottleneck: Fast nodes don't help if they're waiting on network or other nodes communication.

2. Not all workloads benefit from distribution: Some tasks parallelize well, others don't.

3. Debugging distributed systems is harder: Problems that would be obvious on a single system become complex when spread across multiple machines.

4. Redundancy requires planning: Just having multiple machines doesn't automatically provide fault tolerance.

5. Monitoring is essential: You need to know what each node is doing and quickly identify problems.

These lessons would prove directly applicable decades later when building DGPUNET, but I didn't know that at the time. I was solving the immediate problem of providing reliable, performant services within budget constraints.

MaladNet: Rural Wireless ISP

In the late 1990s and early 2000s, I operated MaladNet, a Wireless ISP (WISP) providing broadband Internet to very rural locations in conditions that ranged from -20°F (and colder) in winter with 3+ feet of snow to 112°F+ in the summer.

Technical Challenges

Power: These were completely standalone towers in isolated remote environments on hilltops with no roads (off-road, snowmobile, or hike/horse access only). None of the tower locations had access to any grid power. Solutions included:

• Solar panels
• Wind turbines
• Battery banks for overnight and cloudy periods
• Monitoring systems to alert when power was low, antennas drifting off target, interference, solar storms, or other issues impacting functionality

Weather: The equipment had to function reliably in extreme conditions:

• Heat management in summer (most equipment will literally fry or melt if not kept cool enough)
• Cold management in winter (some electronics stop working below certain temperatures)
• Wind resistance
• Snow and ice accumulation
• Lightning protection
• Coronal Mass Ejections and Solar Storams causing RF and electromagnetic induction messing with signal to noise ratios (SNRs)
• Animals, vandals, and thieves

Maintenance: Remote tower locations meant that every service call was expensive in time and travel. Systems needed to:

• Self-recover from most problems
• Provide detailed remote diagnostics
• Alert before minor issues became major failures
• Support remote configuration changes

Connectivity: The towers connected via wireless yagis in point-to-point focused "hops" to my HQ buildings using very high-quality UUNET backbones, but local connections to customer sites needed careful planning for line-of-sight, interference, and bandwidth management.

Intrusion Detection and Prevention

Running an ISP meant dealing with security issues constantly. This led to developing increasingly sophisticated intrusion detection systems (IDS) and intrusion prevention systems (IPS). I had been developing some of these back in the 80s and 90s for the companies and clients I worked for, but running an ISP took it to a whole other level.

Early attempts used simple pattern matching - looking for known attack signatures in network traffic. But attacks evolve, and pattern matching only catches known problems, but overtime I was developing increasingly complex heuristic algorithms.

More effective approaches included:

• Baseline behavior: Learn what normal traffic looks like for each customer
• Anomaly detection: Flag significant deviations from normal patterns
• Automated responses: Block traffic that matches attack patterns without waiting for manual intervention
• Learning from mistakes: Allow overriding false positives and incorporate feedback

The IDS/IPS work combined many previous lessons:

• Pattern matching from IRC bots
• Automation from BBS systems
• Reliability requirements from production OCR systems
• Real-time processing needs from network infrastructure

2600 IRC Node Rebuild (2003)

In 2003, I helped rebuild the entire 2600 "Hacker Quarterly" Magazine IRC network from scratch after it had been down for over a year from a massive global DDoS. Getting this up and running (quietly in stealth mode for a few months to avoid being attacked before ready) involved:

• Setting up reliable IRC server infrastructure
• Establishing security policies and technical controls
• Connecting multiple servers into a coherent network all over the world
• Managing services and channel operations
• Documentation and training for other administrators

The rebuilt network has operated continuously since 2003. This work contributed to [providing a whole other scale of ]experience with building infrastructure designed for long-term operation against massive hostile attackers, not just initial deployment. I of course didn't do this alone, but I was the catalyst and core infrastructure to get it started and rebuilt, because no one else would touch them with a 10' pole.

Key focus areas:

• Redundancy: Multiple servers in different locations
• Security: Protecting against attacks while allowing legitimate use
• Monitoring: Knowing when problems occur quickly
• Documentation: Allowing others to maintain and improve the system
• Scalability: Handling growth in users and channels

Trigeo and Further IDS/IPS Development

A brief period working at Trigeo (later acquired by Solar Windows) in Post Falls, Idaho involved a Linux + Java shop where I continued refining intrusion detection and prevention systems.

This work benefited from all the previous experience - IRC security bots, MaladNet IPS, and production systems management. The patterns were becoming clearer:

1. Know normal before you can identify abnormal 2. Respond automatically to clear threats 3. Provide detailed logging for ambiguous situations 4. Learn from administrator decisions 5. Performance matters - security that slows everything down won't be used

Patterns That Emerged

Looking back at 1990-2005, several themes stand out:

Commodity Over Enterprise

From Beowulf clusters to MaladNet's solar-powered towers, the pattern was using less expensive, more available components to achieve results comparable to more expensive single solutions.

This wasn't about being cheap - it was about what was sustainable and maintainable. This approach of using open source to facilitate implementation of 80-90% existing off-the-shelf solutions combined with 10-20% custom development (Some of Hawke Robinson's Key CITO Methodologies) would become a core principle across all later work. Multiple commodity systems provided:

• Better economics for the capabilities needed
• Easier replacement (components were more readily available)
• Opportunities to learn by building and maintaining infrastructure
• Flexibility to adapt to changing needs

Distributed Over Centralized

Whether splitting workload across Beowulf nodes or managing multiple MaladNet towers, distributed architectures provided redundancy and scaling that single systems couldn't match economically.

The trade-off was complexity, but that complexity was manageable with proper planning, monitoring, experience, wisdom, and especially important is quality technical documentation.

Make Things More Human

From IRC bots to NPC behaviors to security systems that learned from feedback, the thread of making computer interactions feel more natural continued through all of this work.

It wasn't about fooling anyone - it was about making systems that were easier to work with, more intuitive, and better at understanding context and intent.

Automation and Reliability

Production systems from OCR scanning to ISP management to IRC networks taught that reliable operations require:

• Extensive automation of routine tasks
• Clear error handling and logging
• Self-recovery where possible
• Alerting before small problems become large ones
• Documentation for when manual intervention is needed

Looking Forward

By 2005, I had extensive experience with:

• Distributed computing on commodity hardware
• Natural language processing and bot development
• Production systems requiring high reliability
• Network infrastructure and security
• Remote systems management in challenging conditions

The next phase would apply these skills to educational and therapeutic contexts, leading to systems that integrated voice, real-time processing, and multi-modal interactions at scales that served thousands of users.

That's where Part 3 picks up - moving from infrastructure building to applications that directly served users in educational and therapeutic contexts, eventually leading to breakthroughs that outperformed commercial solutions.

Next in Series: Part 3: Professional Applications and Breakthroughs (2005-2020) - Therapeutic gaming, educational technology, and the LearningMate breakthrough

Previous in Series: Part 1: Early Foundations (1977-1990) - How role-playing games and early computing shaped four decades of development

About This Series: This is Part 2 of a 5-part series documenting the technical evolution from early hobby programming to DGPUNET (Distributed GPU Network) and SIIMPAF (Synthetic Intelligence Interactive Matrix Personal Adaptive Familiar). The series focuses on practical problems and solutions, avoiding marketing language in favor of technical accuracy and honest assessment.

About the Author: William Hawkes-Robinson has been developing software since 1979, with focus areas including distributed computing, natural language processing, educational technology, and therapeutic applications of gaming. He is the founder of RPG Research and Dev2Dev Portal LLC, and is known internationally as "The Grandfather of Therapeutic Gaming" for his long-running work applying role-playing games to therapeutic and educational contexts.

Contact: hawkenterprising@gmail.com Website: https://www.hawkerobinson.com Tech Blog: https://techtalkhawke.com

Version: 2025.10.17-1230 Status: Draft for Review Word Count: ~2,100 words