Our bodies are designed such that we need to lose consciousness, entirely, for a full third of every day. This is evidently necessary for some kind of regular brain maintenance, maybe forming long term memories, who knows what else. If we don’t sleep, we quickly become groggy and non-functional.
Really? Continue reading
The scope of the fediverse has been hotly debated recently. Are we a big fedi? Or a small fedi? Are instances just nodes? Or networked communities? Which Camp of Mastodon are we in? How far should our replies travel? How about our blog posts and Bluesky skeets? Should we welcome Threads? Or block them?
Should we open the fediverse to everyone, let them exercise freedom of association, embrace the inevitable Eternal September, and get good at managing the problems? Or should we learn from Twitter that a “global town square” has big downsides, try to prevent those harms from the beginning, and only expand online communities once we have their consent?
Should there be one internet? Or multiple, sometimes separate internets? Continue reading
I’m a big believer in the demarcation problem: in the general case, there’s no shortcut to determining objective truth. It’s similar to the halting problem in computer science: if we want to know whether a claim is true, we have to go through the scientific method. It’s the only process we know that works.
It’s far from ideal, though. Sometimes the claim is fiendishly complex, sprawling, or only loosely defined. The scientific method can’t always come up with a simple, easy answer, especially not on the first try. Instead, it approaches the right answer, narrowing in over years or decades, with missteps and false starts along the way.
This means that policing misinformation is fraught, at best. Forget policing, we can’t even reliably identify misinformation, at least not always, or in any reasonable time frame. Continue reading
…or if you prefer, eating my own cooking, or scratching my own itch, or drinking my own champagne. Sure. These are all metaphors for the idea that if you build something, it turns out better if you use it yourself, especially if you want it yourself. However, when I think about my projects for bridging social networks, I wonder if I don’t use them myself deeply enough. If I’m not the target audience. Is that a problem?
It’s not entirely true. Strictly speaking, I do use them. After this post gets published, you’ll see a trickle of likes, reposts, and replies from social networks start to show up down in the comments, thanks to Bridgy and Bridgy Fed. The part I worry about isn’t the tools part, it’s the social part. How online social tools should work, how communities should use them, how they affect the ways people interact online. These have all been hot topics for a while now, with social networks pushing “healthy conversations” and Congress haranguing tech execs on Capitol Hill, and even more acutely recently now that Twitter is burning and a new crop of social networks has sprouted. Continue reading
Well, it’s come to this. Twitter is burning, a billionaire owes money, an API will soon get lobotomized, so Bridgy‘s Twitter support will die within the month is dead. Granary‘s and twitter-atom too. The Twitter API may now be effectively unmaintained, but they still managed to find an engineer somewhere to change a few numbers in the billing code and update some text on a web page.
What a waste. Plenty of ink has been spilled on all this already, I won’t belabor the point, but what an utter waste. Continue reading
Matilda, 1996
Content negotiation is a feature of HTTP that lets clients ask for, and servers return, different content types based on the request’s Accept header.
Sounds great, right? Well, no. Content negotiation is the classic example of an idea that sounds good in theory, but for the vast majority of web developers, turns out to be net harmful in practice. A few reasons: Continue reading
A long time ago, I decided to show Bridgy‘s end users its raw logs. Like, raw logs. HTTP requests, database reads and writes, JSON objects, stack traces, etc. It’s an unusual UI feature, but it’s been an unqualified success, enough that when I built Bridgy Fed, I immediately included it and never looked back.
Whenever Bridgy does something nontrivial – poll a social network account, send a webmention, publish a post – I generally include a link to the server logs for that operation. Here’s an example, a series of timestamped plain text log messages from a poll of my Twitter account. They include initial config and parameters, account status, each individual Twitter API request, the results of those requests, how Bridgy interpreted them, HTTP requests to my web site, the subsequent actions Bridgy took and why, how the account’s status changed, and when the next poll is scheduled for. Continue reading
A while back, early in the blockchain hype cycle, a startup called Verisart popped up and promised to “fix” fine art. Not sure if that painting is real? Can’t find out who owns it, or where they got it? Worried that the gallery you’re emailing is a scammer? Worry no more! Verisart puts it all on a magically secure blockchain, and poof! No more problems.
It wasn’t long before “digital troublemaker” Terence Eden created a Verisart account, told them he owned the Mona Lisa, and they dutifully accepted it and published it permanently on their “secure servers” and “most trusted” blockchain.
Long story short, I convinced them that I painted the Mona Lisa. An excellent situationalist prank. Much avant-garde, so postmodernism.
Funny joke, right? Blockchain fans cried foul, everyone else had a good laugh, we all moved on. The blockchain didn’t go away, though. More and more people are connecting it to the real world now, in more and more ways, and it’s not up to the challenge. Its strengths do not apply to the offline, off-chain world. The blockchain has a real world problem, and we’re not talking about it enough. Continue reading
We live in a golden age of software reuse. We’ve never before had such a wealth of freely available code, in so many languages, so easy to find and install.
And yet, we’re drowning. We slap together rickety rowboats and toss them out on PyPI Ocean and npm Sea, then act surprised when the changes flood in. We ignore the flood as long as we can, then patch the holes with duct tape and bilge pumps as if they can hold back the tide. They cannot.
It’s a wonderful, horrible problem, and I don’t know what to do about it. Continue reading
I’ve spent some time over the last few weeks reading about the various *nix init systems: venerable SysV, interim replacement Upstart, controversial monolith systemd, Apple’s proprietary launchd, and niche variants like runit and Epoch. Lots of history, lots of flame wars.
One key takeaway: socket activation is a breathtakingly elegant way to parallelize system startup. In every modern operating system, boot consists of starting hundreds of processes and waiting for them to initialize. Most depend on each other, and many init systems encode these dependencies by hand, waiting for each process to initialize completely before starting the next. Not surprisingly, this is heavyweight, slow, and a maintenance burden.
The key insight was that processes generally interact with each other over sockets, usually AF_UNIX (ie files), occasionally AF_INET and others. If a process isn’t yet listening on a socket, connecting to it will fail, so a given process can’t start until the processes it depends on are ready and listening. Continue reading
Matthew Childs / Reuters
