<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>History of Technology on Kevin R. Kuhl</title>
    <link>https://www.kevinrkuhl.com/tags/history-of-technology/</link>
    <description>Recent content in History of Technology on Kevin R. Kuhl</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 05 May 2026 19:00:00 -0400</lastBuildDate><atom:link href="https://www.kevinrkuhl.com/tags/history-of-technology/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Terry Godier: &#34;The Boring Internet&#34;</title>
      <link>https://www.kevinrkuhl.com/blog/2026/05/godier-the-boring-internet/</link>
      <pubDate>Tue, 05 May 2026 19:00:00 -0400</pubDate>
      
      <guid>https://www.kevinrkuhl.com/blog/2026/05/godier-the-boring-internet/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://www.terrygodier.com/the-boring-internet&#34;&gt;&lt;em&gt;The Boring Internet&lt;/em&gt;&lt;/a&gt; is a wonderful post by &lt;a href=&#34;https://www.terrygodier.com/&#34;&gt;Terry Godier&lt;/a&gt; about what’s dying and what remains as the internet changes. It echoes my own sentiments about &lt;a href=&#34;https://www.kevinrkuhl.com/blog/2026/02/rss-syndication-and-the-future-of-the-web/&#34;&gt;RSS surviving its own death&lt;/a&gt;. The core idea is that we shouldn’t care about the platforms, even if they once offered us convenience; we should care about the standards and ways of communicating.&lt;/p&gt;
&lt;p&gt;Anyways, the core idea of what we should care about aren&amp;rsquo;t the platforms, even though they offered us things. We should care about standards and ways of communicating:&lt;/p&gt;
&lt;blockquote class=&#34;my-6 p-4 border-l-4 border-gray-300 bg-gray-50 italic&#34;&gt;
    
    &lt;p class=&#34;mb-0&#34;&gt;&lt;p&gt;The layer where every human activity became a venture-backed destination, every destination became a feed, every feed became ad inventory, and every ad market became a machine for producing more things to interrupt you with.&lt;/p&gt;
&lt;p&gt;Underneath that layer is another internet: older, slower, less polished, harder to monetize, and much harder to kill.&lt;/p&gt;
&lt;p&gt;It is not utopia. It is full of spam, abandoned servers, broken clients, hostile nodes, strange old commands, half-maintained software, and people arguing in plain text about things no normal person should care about.&lt;/p&gt;
&lt;p&gt;But it has one enormous advantage over the platforms that replaced it in your imagination.&lt;/p&gt;
&lt;p&gt;No one owns it.&lt;/p&gt;
&lt;/p&gt;

    
    
&lt;/blockquote&gt;
&lt;p&gt;ATProto and ActivityPub are the latest incarnations of this philosophy. As the major platforms begin to sunset or pivot, &lt;em&gt;protocols&lt;/em&gt; are where I’m looking to build new ways of publishing and connecting.&lt;/p&gt;
&lt;p&gt;Also, &lt;a href=&#34;https://www.terrygodier.com/phantom-obligation&#34;&gt;&lt;em&gt;Phantom Obligation&lt;/em&gt;&lt;/a&gt; on the UX of RSS readers is also excellent.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Paul Osmon: &#34;Building the Web&#34;</title>
      <link>https://www.kevinrkuhl.com/blog/2026/03/building-the-web/</link>
      <pubDate>Mon, 09 Mar 2026 13:31:00 -0400</pubDate>
      
      <guid>https://www.kevinrkuhl.com/blog/2026/03/building-the-web/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://paulosman.me/&#34;&gt;Paul Olson&lt;/a&gt; is a software engineer with a background in platform engineering and observability, and is working on an engineer&amp;rsquo;s &lt;a href=&#34;https://paulosman.me/2026/03/05/building-the-web-a-history-of-web-architecture/&#34;&gt;history of web architecture&lt;/a&gt;. Here&amp;rsquo;s how he describes the project:&lt;/p&gt;
&lt;blockquote class=&#34;my-6 p-4 border-l-4 border-gray-300 bg-gray-50 italic&#34;&gt;
    
    &lt;p class=&#34;mb-0&#34;&gt;&lt;p&gt;The years spanning from 1993 to 2015 were extraordinary. Linux and FreeBSD became mainstream server operating systems, the NCSA httpd project was released, it begat the Apache HTTP server, which in turn inspired projects like nginx. The world saw the birth of a global network for information exchange and its evolution into the substrate of our everyday lives. We went from editing files and placing them in directories on a server to shipping fully containerized applications through complex pipelines. Client-server architecture became three-tiered architecture, eventually morphing into the microservice death star diagrams shared in conference talks as humble brags about the amount of infrastructure required to run large sites. Most of this innovation was done in the open, often by people collaborating across organizational and geographic boundaries. I owe my career to this time period and to the people who shaped it. The amount of knowledge sharing and learning, between practitioners figuring things out the hard way, that has happened during this time period is staggering.&lt;/p&gt;
&lt;p&gt;I’m writing a book detailing the major shifts in web architecture that happened during this time period. Things continued to happen, of course, and 2015 is admittedly a bit arbitrary &amp;mdash; but I chose this timeline because we had containerization and orchestration cemented. Much work that has happened since has been focused on ML / AI, which is out of scope for this project. I’m writing the book because it’s important to illustrate the connective tissue between these developments. It’s also important to appreciate how these contributions were made by practitioners working in specific contexts under specific constraints, and how their innovations compounded &amp;mdash; sometimes unexpectedly. I want to dive into how the industry evolved from stateless web servers serving static documents through the C10K problem, through developments in caching reverse proxies, improvements to OS kernels, experiments with new programming models, infrastructure like CDNs, and beyond. I’ll treat security as a common thread that runs through each chapter, with each innovation addressing some challenges and introducing new attack surface area for others.&lt;/p&gt;
&lt;/p&gt;

    
    
&lt;/blockquote&gt;
&lt;p&gt;I think these kinds of projects are immensely valuable. Building an account of why things are the way they are, from the perspectives of people working in the trenches can leverage insights that are valuable for future projects. For those of us working in software engineering today, understanding this perspective is a form of architectural forensics. You can&amp;rsquo;t truly understand why a system is complex until you understand the problem it was originally designed to solve.&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s also valuable for people outside of the world of software &amp;mdash; while Osman&amp;rsquo;s intended audience is engineers, academics really benefit from this sort of undertaking, we can better understand the shape the web is taking when we understand that technologies aren&amp;rsquo;t inevitable, but responses to specific problems.&lt;/p&gt;
&lt;p&gt;The book will be released progressively at &lt;a href=&#34;https://buildingtheweb.dev&#34;&gt;buildingtheweb.dev&lt;/a&gt;, and you can following along by signing up at the site, or using your RSS reader of choice.&lt;/p&gt;
&lt;p&gt;Quick aside &amp;mdash; I’m planning to ramp up the frequency of these posts. There are some big (and very positive) changes in the works professionally. Expect a bit of an adjustment period, followed by a lot more technical deep-dives and interesting links!&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>