Before PPP Took Over: The Stubborn Few Still Running SLIP Like It's 1989

Most people who were online in the early nineties remember the exact sound of getting connected — that shriek-and-handshake ritual that meant the world was about to open up. What fewer people remember is the protocol quietly doing the heavy lifting underneath. Before PPP became the default, before broadband made the whole question irrelevant, there was SLIP. Serial Line Internet Protocol. Unglamorous, unencrypted, and weirdly beloved by the people who actually understood what it was doing.

Today, if you go looking for a SLIP provider in the United States, you are going to do a lot of searching. But they exist. A handful of them. And the people running those connections — on both the provider and user ends — have a lot to say about why the protocol never fully deserved its reputation as a dead end.

What SLIP Actually Was (and Wasn't)

SLIP dates back to 1984, when Rick Adams at the Center for Seismic Studies put together a simple framing protocol for pushing IP packets over serial lines. It was never formally standardized through the IETF in the way PPP eventually was. There was no built-in error correction, no authentication handshake, no dynamic IP assignment. You configured your IP address manually on both ends, fired up the connection, and hoped the line was clean enough to keep things stable.

That simplicity was both the feature and the bug. Compared to PPP, SLIP was lean. There was almost no overhead. On a slow modem — and they were all slow by today's standards — that leanness actually translated to a measurable difference in throughput. Early adopters who were running 2400 or 9600 baud connections noticed. Some of them never forgot.

PPP won out for legitimate reasons. It negotiated parameters automatically, handled noisy lines better, and supported compression and authentication out of the box. By the mid-nineties, most ISPs had moved on. SLIP became a footnote, then a trivia question.

The Providers Who Didn't Move On

Ask around in the right corners of the retro computing world and you'll eventually find references to ISPs — most of them tiny, most of them operating out of someone's basement or a small co-lo rack — that still list SLIP as a supported connection type. They're not advertising it on billboards. The option tends to live in a dusty corner of a configuration page, or gets mentioned in a mailing list thread, or comes up when a new customer asks if there's any way to get a vintage machine genuinely online without emulating a modern stack on top of it.

The operators of these services share a common profile. They've been running their networks for a long time — in some cases since before the commercial internet was really a thing — and they have a philosophical commitment to keeping legacy options available. One sysop running a small regional provider in the Pacific Northwest described it this way: taking away SLIP support would mean telling a subset of his users that their hardware is no longer welcome. He's not interested in doing that.

The user base is small but consistent. We're talking about people running original Amiga systems, early Sun workstations, vintage DOS machines with original Trumpet Winsock installs, and in a few cases, actual terminals that were never designed to be anything other than serial devices. For these users, PPP support in the hardware either doesn't exist or requires workarounds that introduce more complexity than SLIP's quirks ever did.

The Hardware Side of the Equation

Getting a machine onto SLIP in 2024 is not dramatically harder than it was in 1992, which is either reassuring or unsettling depending on your perspective. You need a serial port, a modem, a phone line or a serial null-modem cable if you're doing it locally, and a provider willing to accept the connection. The software side has been documented extensively by the hobbyist community — configuration guides exist for everything from Commodore systems to early Macintosh hardware to DOS-era PCs running packet drivers.

What's changed is the phone line situation. Getting a stable analog line in most of the US is increasingly difficult as carriers phase out POTS infrastructure. Some SLIP enthusiasts have adapted by using VoIP lines with ATA adapters, though line quality varies enough to cause headaches. Others have moved toward direct serial connections, using a local SLIP server as a bridge to the broader internet — effectively recreating the ISP relationship on a home network.

The modem hardware itself has become a collector's market. Certain models — the USRobotics Courier series comes up constantly, as do specific Hayes-compatible modems known for clean SLIP performance — command real prices when they show up on eBay or at estate sales. The people buying them aren't just putting them on shelves.

Nostalgia Versus Infrastructure

Here's where it gets interesting, and where the SLIP community diverges from the broader retro computing scene. A lot of vintage tech enthusiasm is, at its core, about aesthetics. The warm glow of a CRT, the satisfying clunk of a mechanical keyboard, the smell of old electronics — these are sensory experiences tied to memory. There's nothing wrong with that. But it's fundamentally decorative.

The people running SLIP connections are doing something different. They're making an infrastructure choice. The vintage machine on the desk isn't a museum piece — it's a working node. It sends and receives actual packets. It connects to actual servers. The protocol isn't being preserved behind glass; it's being used.

That distinction matters because it changes what the hobby reveals about the technology itself. When you run SLIP on original hardware against a real provider, you find out what the protocol actually does and doesn't do, under real conditions, with real latency and real line noise. You learn things about TCP/IP fundamentals that modern networking abstracts away entirely. Several people in this community have described it as the closest thing to a hands-on networking education that still exists outside of a classroom.

What Keeping It Alive Actually Takes

The providers who maintain SLIP support aren't doing it because it's profitable. The user numbers are too small for that. They're doing it because they built their networks with a certain philosophy — that the internet is more interesting when it accommodates more kinds of devices and more kinds of connections — and they haven't abandoned that philosophy just because the mainstream moved on.

Maintaining SLIP support in a modern routing environment requires some deliberate configuration. Most current network operating systems still have the capability; it just needs to be enabled and managed. The bigger challenge is documentation and support. When something goes wrong with a SLIP connection in 2024, the pool of people who can diagnose it is genuinely small. Providers in this space tend to know each other, share notes, and occasionally collaborate on troubleshooting in ways that feel more like the early internet than anything happening on a modern platform.

SLIP was never the future. It was always a stepping stone, and the industry stepped off it a long time ago. But stepping stones don't disappear just because nobody's crossing that particular river anymore. Some of them are still sitting there, solid, doing exactly what they were built to do — waiting for whoever still needs to make the crossing.