FLOSS Weekly Episode 770: 10% More Internet

This week, Jonathan Bennett and Doc Searls talk with David Taht about the state of the Internet and, specifically, IPv4 exhaustion. We’re running out of IPv4 addresses! But we’ve been running out for something like ten years now. What gives? And why are nearly 20% of the world’s IPv4 addresses sitting unused? David has a hack that would give the world 10% more Internet, but Amazon might have something to say about it.

There’s even more, like Kessler Syndrome, some musing on what the Interplanetary Internet will look like, the worth of real paper books, and a long-term bet for some IPv4 addresses to come to fruition in 2038.

Continue reading “FLOSS Weekly Episode 770: 10% More Internet”

The First Search Engines, Built By Librarians

Before the Internet became the advertisement generator we know and love today, interspersed with interesting information here and there, it was originally a network of computers largely among various universities. This was even before the world-wide web and HTML which means that the people using these proto-networks, mostly researchers and other academics, had to build things we might take for granted from the ground up. One of those was one of the first search engines, built by the librarians who were cataloging all of the research in their universities, and using their relatively primitive computer networks to store and retrieve all of this information.

This search engine was called SUPARS, the Syracuse University Psychological Abstracts Retrieval Service. It was originally built for psychology research papers, and perhaps unsurprisingly the psychologists at the university also used this new system as the basis for understanding how humans would interact with computers. This was the 1970s after all, and most people had never used a computer, so documenting how they used search engine led to some important breakthroughs in the way we think about the best ways of designing systems like these.

The search engine was technically revolutionary for the time as well. It was among the first to allow text to be searched within documents and saved previous searches for users and researchers to access and learn from. The experiment was driven by the need to support researchers in a future where reference librarians would need assistance dealing with more and more information in their libraries, and it highlighted the challenges of vocabulary control in free-text searching.

The visionaries behind SUPARS recognized the changing landscape of research and designed for the future that would rely on networked computer systems. Their contributions expanded the understanding of how technology could shape human communication and effectiveness, and while they might not have imagined the world we are currently in, they certainly paved the way for the advances that led to its widespread adoption even outside a university setting. There were some false starts along that path, though.

A Handy Guide To The Humble BBS

Some of us who’ve been online since the early days fondly remember the web of yore — with its flashing banners, wildly distracting backgrounds, and automatic side-scrolling text. But there was a time before the worldwide web and the Internet as we recognize it today, and the way of communicating in this before-time was through Bulletin Board Systems, or BBS. There are still some who can cite this deep magic today, and this page is perhaps the definitive guide to this style of retrocomputing.

This how-to is managed by [Blake.Patterson] who is using a wide variety of antique machines and some modern hardware in order to access the BBSes still in service. He notes in this guide that it’s possible to use telnet and a modern computer to access them, but using something like an Amiga or Atari will give you the full experience. There are some tools that convert the telephone modem signals from that original hardware to something that modern networking equipment can understand, and while the experience might be slightly faster as a result, it does seem to preserve the nostalgia factor quite well.

For those looking for more specific guides, we’ve featured [Blake]’s work a few times in the past, once with an antique Epson PX-8 laptop and again with a modern ESP8266. It doesn’t take much computing power to get connected to these old services, so grab whatever you can and start BBSing!

A Collection Of Websites That Look Like Desktops

Web design has come a long way since those halcyon days of Web 1.0. There are plenty of rules about how to make a clean and efficient website, but sometimes it’s more fun to throw them out and just be creative instead. In that vein, [Simone] has curated a wonderful collection of websites that emulate the computer desktop experience online.

The collection’s website very much fits this theme. Upon visiting, an Award BIOS screen flashes up. From there, we get a Windows 95-like interface full of links to other sites that emulate a computer desktop layout. There’s even a 3D screensaver that pops up if you mouse away for too long.

There’s Browso.app, which semi-accurately tells you information about your computer in a theme reminiscent of MacOS 9. Meanwhile, clicking on “It Is As if You Were Doing Work” will take you to a weird game that’s compelling in its replication of office banality. Nightwave Plaza offers exquisite vaporwave vibes, while others simply intend to faithfully recreate various OSes in a browser window.

It’s a fun collection of websites that go from the weirdly afamiliar to downright impressive recreations of former realities. It’s certainly fun to click around for a while and see what’s out there. We do love some good web ephemera around these parts!

Bufferbloat, The Internet, And How To Fix It

There’s a dreaded disease that’s plagued Internet Service Providers for years. OK, there’s probably several diseases, but today we’re talking about bufferbloat. What it is, how to test for it, and finally what you can do about it. Oh, and a huge shout-out to all the folks working on this problem. Many programmers and engineers, like Vint Cerf, Dave Taht, Jim Gettys, and many more have cracked this nut for our collective benefit.

When your computer sends a TCP/IP packet to another host on the Internet, that packet routes through your computer, through the network card, through a switch, through your router, through an ISP modem, through a couple ISP routers, and then finally through some very large routers on its way to the datacenter. Or maybe through that convoluted chain of devices in reverse, to arrive at another desktop. It’s amazing that the whole thing works at all, really. Each of those hops represents another place for things to go wrong. And if something really goes wrong, you know it right away. Pages suddenly won’t load. Your VoIP calls get cut off, or have drop-outs. It’s pretty easy to spot a broken connection, even if finding and fixing it isn’t so trivial.

That’s an obvious problem. What if you have a non-obvious problem? Sites load, but just a little slower than it seems like they used to. You know how to use a command line, so you try a ping test. Huh, 15.0 ms off to Google.com. Let it run for a hundred packets, and essentially no packet loss. But something’s just not right. When someone else is streaming a movie, or a machine is pushing a backup up to a remote server, it all falls apart. That’s bufferbloat, and it’s actually really easy to do a simple test to detect it. Run a speed test, and run a ping test while your connection is being saturated. If your latency under load goes through the roof, you likely have bufferbloat. There are even a few of the big speed test sites that now offer bufferbloat tests. But first, some history. Continue reading “Bufferbloat, The Internet, And How To Fix It”

Not On The Internet

Whenever you need to know something, you just look it up on the Internet, right? Using the search engine of your choice, you type in a couple keywords, hit enter, and you’re set. Any datasheet, any protocol specification, any obscure runtime error, any time. Heck, you can most often find some sample code implementing whatever it is you’re looking for. In a minute or so.

It is so truly easy to find everything technical that I take it entirely for granted. In fact, I had entirely forgotten that we live in a hacker’s utopia until a couple nights ago, when it happened again: I wanted to find something that isn’t on the Internet. Now, to be fair, it’s probably out there and I just need to dig a little deeper, but the shock of not instantly finding the answer to a random esoteric question reminded me how lucky we actually are 99.99% of the time when we do find the answer straight away.

So great job, global hive-mind of über-nerds! This was one of the founding dreams of the Internet, that all information would be available to everyone anywhere, and it’s essentially working. Never mind that we can stream movies or have telcos with people on the other side of the globe – when I want a Python library for decoding Kansas City Standard audio data, it’s at my fingertips. Detailed SCSI specifications? Check.

But what was my search, you ask? Kristina and I were talking about Teddy Ruxpin, and I thought that the specification for the servo track on the tape would certainly have been reverse engineered and well documented. And I’m still sure it is – I was just shocked that I couldn’t instantly find it. The last time this happened to me, it was the datasheet for the chips that make up a Speak & Spell, and it turned out that I just needed to dig a lot harder. So I haven’t given up hope yet.

And deep down, I’m a little bit happy that I found a hole in the Internet. It gives Kristina and me an excuse to reverse engineer the format ourselves. Sometimes ignorance is bliss. But for the rest of those times, when I really want the answer to a niche tech question, thanks everyone!

Building Faster Rsync From Scratch In Go

For a quick file transfer between two computers, SCP is a fine program to use. For more complex, large, or regular backups, however, the go-to tool is rsync. It’s faster, more efficient, and usable in a wider range of circumstances. For all its perks, [Michael Stapelberg] felt that it had one major weakness: it is a tool written in C. [Michael] is philosophically opposed to programs written in C, so he set out to implement rsync from scratch in Go instead.

[Michael]’s path to deciding to tackle this project is a complicated one. His ISP upgraded his internet connection to 25 Gbit/s recently, which means that his custom router was the bottleneck in his network. To solve that problem he migrated his router to a PC with several 25 Gbit/s network cards. To take full advantage of the speed now theoretically available, he began using a tool called gokrazy, which turns applications written in Go into their own appliance. That means that instead of installing a full Linux distribution to handle specific tasks (like a router, for example), the only thing loaded on the computer is essentially the Linux kernel, the Go compiler and libraries, and then the Go application itself.

With a new router with hardware capable of supporting these fast speeds and only running software written in Go, the last step was finally to build rsync to support his tasks on his network. This meant that rsync itself needed to be built from scratch in Go. Once [Michael] completed this final task, he found that his implementation of rsync is actually much faster than the version built in C, thanks to the modernization found in the Go language and the fact that his router isn’t running all of the cruft associated with a standard Linux distribution.

For a software project of this scope, we find [Michael]’s step-by-step process worth taking note of for any problem any of us attempt to tackle. Not only that, refactoring a foundational tool like rsync is an involved task on its own, let alone its creation simply to increase network speeds beyond what most of us would already consider blazingly fast. We’re leaving out a ton of details on this build so we definitely recommend checking out his talk in the video below.

Thanks to [sarinkhan] for the tip!

Continue reading “Building Faster Rsync From Scratch In Go”