You’d think that by now, networks were well enough understood that people would stop making assumptions that we have known, almost since the dawn of networking, to be untrue. Yet as users, developers, and network administrators, we still seem curiously unable to let go of long-held beliefs. Perhaps the best-known collection of mistaken ideas about networks is the eight fallacies of distributed computing. The eight fallacies - The network is reliable - Latency is zero - Bandwidth is infinite - The network is secure - Topology doesn’t change - There is one administrator - Transport cost is zero - The network is homogeneous Where did this list come from? The list began with four original fallacies (the first four in the list), collected by Bill Joy and Tom Lyon, two of the original eight founders and employees of Sun Microsystems. Sun integrated high-speed graphics, the UNIX operating system, and a working Internet protocol stack, which led to the explosion in desktop computing, their meteoric rise, and ultimate acquisition by Oracle Computing. When you use a Berkeley Software Distribution (BSD) variant, a Linux distribution, or even Android, you’re using technology that has followed a lineage from Sun Microsystems. Think of the ZFS file system, the Network File System (NFS) protocol for network file storage, and Java, to name a few. The list was later expanded by L. Peter Deutsch, who added a further three fallacies while at Sun. The final fallacy was coined by James Gosling, who, fittingly, also worked at Sun, bringing us to the eight fallacies we now know and love. Over time, these ideas have settled and inspired other lists of fallacies — for example, the fallacies surrounding dates and times, or the falsehoods people believe about names. I would be surprised if there weren’t more. We encounter these date and name errors constantly, whether filling in forms or interacting with assets on the web or in apps. The underlying eight fallacies of distributed computing are buried ‘constants’ in our use of the network. They are worth thinking about as network operators, whether in protocol and software design, or how they impact users in daily life. By keeping them in mind, we can better address the behaviours that arise from these fallacies as we encounter them online. The list is aimed at people writing network software: Applications that call into the network, services that are called from the network, and network protocols. It provides practical guidance — even if presented abstractly — on how to think about sending data through a network, and the questions you should ask. Questions such as: - Was it actually sent? - Was it received? - How can you tell? - Can you send it again, or is the data gone? - Does it even need to be sent again? - Do you have time to handle this data? How will it affect the rest of your program? - Does the network behave in ways you really understand, despite its complexity?? Looking at the fallacies case by case What follows is my personal understanding of the meaning of each of the eight fallacies of distributed computing, as they relate to how the network behaves towards me and my services. Others have different views, and I may have gotten some things wrong. 1. The network is reliable Measured as a whole, the Internet is probably broken somewhere, for some users, at all times. That we individually experience it as reliably available is a triumph of hope over experience. Claims of ‘five nines’ reliability often lead us to act as if ‘it won’t happen to me’. More specifically, people tend to assume that once a packet is sent, it will be received. Most of the time, it is. But we still have to design protocols to handle the cases when it isn’t. Consider the first of the three classic measures of a network’s behaviour: loss, delay, and jitter. ‘Loss’ is simply another way of saying ‘unreliable’. If your protocol doesn’t account for the fact that data can be lost, it will run into problems. Much of the Transport Control Protocol (TCP) and QUIC layers are specifically designed to recognise packet loss and handle it. Internet Protocol (IP) — whether version four or six — does not guarantee delivery. That responsibility falls to higher layers if they are capable. 2. Latency is zero Latency encompasses the other two network issues mentioned above: Delay and jitter. Delay is sometimes simply a function of distance, given the speed of light — but even this can be misunderstood, since the speed of light in fibre is slower than in a vacuum. Additional delays occur when converting a signal from copper to fibre and sending it along a fibre optic link. Because of this, sending data via microwave, radio, or even laser between satellites can sometimes be faster than sending it through fibre. Jitter, the variability of delay, is a major challenge for gaming and streaming protocols. Latency and loss are the reasons why services like Netflix both buffer data and use error-correcting codes. These techniques compensate for fluctuations in delay, providing a smooth and reliable playback experience. 3. Bandwidth is infinite It’s tempting to think that in the modern Internet, we can sometimes treat bandwidth as effectively infinite for most practical purposes. The reality, however, is that many links in the system have more people sending packets than there are spaces available to carry them. Dealing with the consequences of ‘less-than-infinite’ bandwidth introduces queuing, which in turn creates delay. With delay comes jitter, and under extreme conditions, packet loss. The limitations of finite bandwidth directly affect every network flow subject to these constraints. In today’s network, where data is often ‘close by’ in a Content Delivery Network (CDN), we rarely notice this. In bandwidth terms, the limits of the network are often far removed from us — with one exception: our local home link. We may use gigabit-capable devices, but our local link speed is often only a few hundred megabits. Can we exceed our home router’s capacity? Almost trivially. Can we exceed our home Wi-Fi network? Certainly. A modern mobile phone can sustain 400 Mbit/sec or more, but a Wi-Fi network purchased five years ago might cap out at 100 Mbit/sec. Investing in network bandwidth to match expectations is like building roads to handle peak-hour traffic: you can make it appear that congestion doesn’t exist, but the cost may be higher than desired. When upgrading a home router to match the speed of new edge fibre delivery, we face the same question: how much bandwidth do we really need? 4. The network is secure In the days of monopoly telecommunications, when a single provider ran networks across an entire economy, there was one major risk: that the provider might fail to ensure the privacy of our data. Typically, they controlled all the infrastructure, and intrusions were rare, if not unheard of. Encoding overhead was minimal, and law enforcement could access data through a single channel. Today, networks run across multiple providers and through intermediaries with whom we have no relationship. Continuing to believe that nobody is ‘seeing’ our packets is naïve. What we can do is ensure the packets themselves contain only secret, protected data. Designing protocols to provide this protection — now and into the future — is both costly and time-consuming. With emerging quantum computing threats to public–private key cryptography, even this protection may not be as guaranteed as we would like. Even protected packets, however, reveal information. Traffic analysis can expose patterns, and advanced machine learning can distinguish streaming, file storage, and interactive traffic from packet timing and size alone. Never treat the network as inherently secure, and never rely on it below your HTTPS or Transport Layer Security (TLS) connections to hide you from others. 5. Topology doesn’t change Topology changes can come from many sources. They occur when your mobile phone connects to a different tower, or when the phone of the person you are communicating with does. They also occur when your provider optimises traffic for efficiency or profit by routing packets differently than you expect. We experience these topology changes as loss, delay, and jitter. Transport protocols like QUIC and TCP shield us from the effects of changes ‘in the middle’ of the network and the resulting impact on packet paths from source to destination. However, the processes that manage these changes — such as Virtual Router Redundancy Protocol (VRRP), Common Address Redundancy Protocol (CARP), Border Gateway Protocol (BGP), or Multipath TCP — are not free. These overheads mean that assumptions such as no loss, no delay, or no duplication of data cannot be relied upon. 6. There is one administrator Sometimes, it feels as if there isn’t even a single administrator. Other times, it seems like having just one would be better than the many we encounter. Even within a single Network Operations Centre (NOC), multiple hands, models, and processes can be at work. Modern networks are so complex that the administrator you speak to is very probably not the one actually making changes in the system. 7. Transport cost is zero Cost is multidimensional. Take the Short Message Service (SMS) protocol as an example. If you multiplied the cost of sending a few packets via SMS by the number of packets required to send a movie, the total would run into thousands of dollars. But does that reflect the actual cost? Where does cost come from in a network? Is it the electricity needed to transmit packets? The hardware? The support systems, business logic, accounting, and risk management? All of these contribute real-world costs to make data transport possible. Just because cost is not exposed directly in a protocol does not mean it doesn’t exist — it means that the cost is being absorbed elsewhere in society. Some costs are never recovered directly and simply become part of the aggregate ‘cost of doing business’. Others, such as the asymmetric charges for sending and retrieving data from Amazon S3 long-term storage, are deliberately structured to encourage fetching data only when necessary. 8. The network is homogeneous One of the great fallacies of BGP routing is the idea that ‘cost’ is the same as AS path length. If you ignore all other factors, you might prefer the route with the fewest AS hops. But is that really wise? Consider connecting European nodes to Asian nodes over a slow, expensive, low-capacity link, while exposing all your European peers to your Asian peers. That thin, costly link will quickly become congested. The inconsistencies in delay, bandwidth, and load capacity become apparent almost immediately. Even in simple home networks, differences between devices on Wi-Fi and devices on Ethernet can be stark. A TV streaming over Wi-Fi competes for airtime with other devices on the same channel, a problem that doesn’t exist when using an Ethernet switch. The costs of delay and retransmission are largely hidden by oversupply, buffering, and encoding. Yet, if you examine network behaviour closely, the differences are clear. IP) masks many of the nuances between local and remote, slow and fast, or reliable and unreliable connections. Higher-layer protocols, however, must handle these realities — balancing time, buffer usage, and computational costs — to deliver the best service possible under the circumstances. Fallacies we believe about fallacy lists The network wouldn’t be what we know and love if the list of network fallacies didn’t contain a fallacy itself. Several online discussions of these fallacies mistakenly refer to Tom Lyon as Dave Lyon. It seems that, over time, even facts can’t be counted on to remain fixed. Maybe one day this list of eight fallacies will grow to nine or ten. I think it’s unlikely to drop down to seven. The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

TLDR: I had 2,207 GoPro videos, and I need to rewatch them to find interesting moments from my cycling journey. I built a project to index them locally on my M1 Max using open-source ML models, search for those moments, and send the best clips straight to my DaVinci Resolve timeline. I indexed 628 videos (668.68 GB, 15h 13m 18s of footage duration), more details in the metrics table in the last section of this article. Full article: https://iliashaddad.com/blog/i-indexed-669-gb-of-my-gopro-videos-using-my-m1-max-computer https://news.ycombinator.com/item?id=48222733 https://blog.simbastack.com/indexed-a-year-of-video-locally/ I wasn't familiar with your project though, interesting stuff. I'm trying to add more photography related features to Framedex but yeah there's so much we can do locally, exciting times. reply

The Government is "angry and frustrated" at local councils for "badly failing" on dereliction, prompting a new tax to be introduced to tackle the scourge that will be administered instead by the Revenue Commissioners. Tánaiste and finance minister Simon Harris was scathing in his criticism of local authorities as he revealed the tax. He will brief Cabinet on Tuesday on plans to introduce the tax as part of the upcoming Finance Bill. Harris said on Sunday that the "novel approach" was being taken out of both frustration and anger at "the scourge of dereliction" in communities, which "local authorities have not done enough to rectify". He said that councils have had the power to collect a derelict sites levy, but that "if you were to look at the derelict sites register, you'd swear to God dereliction was only in a couple of counties". "We've given them extra staff, we've given them extra funding, and they haven't done enough on dereliction. "And how sickening is it if you're a young person trying to buy a home and you're living in a neighbourhood or a community or driving by boarded up buildings, some of which are public buildings. "We're going to have to take this over, because we can't leave it to the local authorities, because they failed in their job to administer the derelict sites. They've badly failed, with a few notable exceptions, by the way. "And so we're now going to legislate in this year's budget to bring in a derelict sites tax and to have Revenue collect it, and that will focus the minds around dereliction." Harris said that property owners would be faced with a "choice" on what to do with their holdings. Latest estimates indicate there were about 19,438 residential derelict properties across the State at the end of 2025. The Tánaiste said the primary objective of the measure was not to collect tax but to "encourage behavioural change and support the revitalisation of communities by bringing long-term derelict buildings back into productive use". The new tax will be administered by Revenue, while local authorities will maintain derelict property registers and identify properties that meet the relevant criteria. Officials are continuing to develop the detailed design of the scheme, including exemptions, appeals mechanisms and ownership verification arrangements, ahead of legislation later this year. Harris also aimed at councils over what he said was a failure to zone adequate land for building. "I've sat in front of far too many chief executives of far too many councils...and they eyeball us and say they've done enough, and they haven't. They're letting young people down," Harris said.

I’ve been telling people for the last 25 years that Jane Street as an organization was just not interested in formal methods. I’m not saying that anymore. It’s not exactly that I think we were wrong all those years. To be clear, we’re strong believers in the power of tools to help us write better and more reliable code. And type systems are a kind of lightweight formal method that we’ve gotten an enormous amount of benefit from. So you might expect us to have been big believers in more full-on formal methods. But outside of some special cases (notably, hardware synthesis), our sense has been that formal methods were just not worth the costs for us. And those costs are really high! seL4 is a great example of this. It’s a formally verified microkernel, and a profound achievement. But, boy was it expensive to do! It took 25 person-years of effort to verify 8,700 lines of C, and each line of code required something like 23 lines of proof and a half a person-day to verify. Our hope is to make formal methods as pervasively useful of a tool for building software as sophisticated type systems are for us today. That kind of approach could be worth it for a security-critical microkernel, where the stakes are high and the specifications are fairly clear. But it just doesn’t make sense for most software, and to us it didn’t feel like it made sense for even our most critical software. But the emergence of agentic coding has changed our perspective, and we’ve gone from being skeptical to being excited about the possibilities. And as a result, we’re now building a team to focus on formal methods. Our hope is to make formal methods as pervasively useful of a tool for building software as sophisticated type systems are for us today. Why the change of heart? Agentic coding upsets the formal-methods apple-cart in a few ways. For one thing, it dramatically changes the cost of using formal methods. It’s not that agents can on their own construct arbitrarily challenging proofs.1 But models are enormously helpful, and broaden the set of people who can use these tools productively. With formal methods being easier to use than ever, it’s worth reconsidering the old cost/benefit calculus. But things haven’t changed only on the cost side. The benefits seem bigger now too. There are really two reasons for this: The verification bottleneck is more important than ever. Models are increasingly good at writing useful code. But there’s a big gap between the code that models generate, and code that you’d want to actually release. To some degree, this is an artifact of how the models are trained. They’re surprisingly good at achieving the goal you set in front of them, but they don’t do a great job of maintaining and even improving the quality of the codebase as they do so. Agentic code is getting better, but is still tends towards slop: overly complicated, full of weird bugs and corner cases, often not following essential invariants of the codebase that it’s a part of. As a result, people need to spend a lot of time verifying that the code produced by agents is up to snuff. And formal methods could be a way of relieving some of that verification burden, and making the process of review a lot more efficient. Separately, agents thrive on feedback. This is true both when you’re training agents using RL, and when you’re using agents to code. And formal methods are another powerful form of feedback that can increase the agents’ ability to solve hard problems. A lot of why we're excited about full-on formal methods is that we see how valuable types are when programming with agents. Not that formal methods are the only way of getting feedback. Tests are incredibly valuable as well, and can be made even better by leaning into property-based tests and fuzzing. And lord knows we’ve spent a lot of time building out testing infrastructure. But tests aren’t enough! There are inherent limits in the power of tests to cover the state space that your program might explore. One of the things we’ve seen in our own programming in OxCaml is that agents benefit a ton from universal guarantees, the ∀ you get out of type systems. If your type system has a way of preventing data races, it lets you get rid of all2 data races. If you set up your types to make cross-site scripting vulnerabilities impossible, then you can really get rid of those entirely, in a way that mere testing has trouble doing. Indeed, a lot of why we’re excited about full-on formal methods is that we see how valuable types are when programming with agents, both for easing the verification bottleneck and providing agents with better feedback, and that makes us excited to see how much more uplift could be available by leveraging more powerful proof techniques. We have two things going for us: deep control of the language we're using, and a community of programmers who are ready for this. Why do it here? One question this raises is: why is Jane Street well positioned to work on this problem? The whole world is thinking about what agents mean for the future of programming, and there are endless startups looking for ways of mixing formal methods and agents. Why is this something we’d work on internally? And why should formal methods experts in the outside world be excited to join our efforts here? For one thing, we have deep control of the language we’re using, and that lets us adjust that language to make it a better home for proof-oriented techniques. There are lots of potential directions to go here: from integrating modular specifications of properties into the type system, to adding type-level constraints around things like ownership and mutability to make certain kinds of proofs easier, to building proof techniques directly into the language. We also have a community of programmers who are ready for this, or at least more ready than any serious programming community I’ve encountered. For most people who work on programming languages, the easy part is coming up with new and better ideas about how to make programming better. The hard part is convincing anyone to actually use those ideas for real work. At Jane Street, things are different! We routinely have users angry at us because the new, weird type-system features we promised them aren’t coming fast enough. We have a lot of people with the right background to leverage these techniques, and a lot of baked in interest in getting things right and building high-quality software. We think that user base will gives us the freedom to try a mixture of approaches; there are some near-term improvements we think we can make which will have pretty immediate impact, and some ambitious, longer-term visions for where we can get in a few years. Having an engaged and excited user base makes both of these approaches possible, and lets us learn from the first, while we build towards the second. None of this is to say that we’re going to ignore work in the outside world. We’re excited and inspired by the work in a variety of other PL communities, built around tools like Lean, Dafny, Rocq, Agda, Iris, and too many more to mention. And we’re excited to look for ways of integrating OxCaml with some of these tools, to take advantage of the great infrastructure that’s already out there. But we also think there are some unique advantages that can only be realized by engaging with the language and the proof techniques at the same time. Join us! If this sounds interesting to you, consider applying! We’re looking for people in both London and New York. We’re in the early stages of interviewing people for these spots and building a team, and there’s an enormous amount of work ahead of us, and we’d love you to be a part of it. Footnotes - Our experience is that models still need help and guidance from humans in order to navigate a complex proof. A human programmer may have ideas about why a system works and how, at a high level, to go about proving it. But most programmers don’t know how to encode these proof ideas in a way that will satisfy a given proof system. Models can automate much of the drudgery and provide a ready source of expertise on the technical details of writing out a proof. ↩ - OK, well, maybe not all. There are escape hatches, like Obj.magic , that let you work around type-level constraints. But you can track and ban exceptions like that for most of your code, at which point you do get something very close to universal guarantees. And, indeed, formal methods can allow you to make it explicit why your use of those escape hatches is actually safe. ↩

When Dragon’s Dogma 2 launched in early 2024, the game quickly captured the industry's attention as an ambitious sequel that retained all the unique quirks of the original – both the acclaimed and the highly divisive ones. Director Hideaki Itsuno delivered an uncompromising vision of high fantasy, featuring a curious world, an emergent physics engine, and a unique Pawn system. However, there was another prominent aspect of the game that sparked massive conversation immediately after release: the sudden presence of day-one microtransactions. Debates surrounding microtransactions are certainly nothing new in the gaming industry, making community backlash almost inevitable whenever they appear. After all, nobody likes the idea of their credit card feeling like an unimmersive gameplay mechanic. Yet, the situation with Dragon’s Dogma 2 quickly snowballed into a much larger controversy at its launch, going viral across social media platforms, triggering a wave of negative reviews on Steam, and leaving a portion of the fanbase deeply confused. Former Devil May Cry, Dragon's Dogma Director Working On New Project Hideaki Itsuno started working on his new project after spending over 30 years at Capcom. A Controversial History and a Sudden Reversal The confusion stemmed from the fact that while these paid items were available for real money, every single one of them could actually be acquired organically just by playing the game. So, its microtransactions functioned basically as optional shortcuts for impatient players. For instance, the purchasable Portcrystal serves as a customizable fast-travel destination, and only two can be found during a standard first playthrough. Therefore, having a few extras on hand simply sped up travel times without genuinely breaking or harming the core gameplay progression. Now, after more than two years of community debate, Capcom finally seems to be stepping back from this model. In an official social media post on X (formerly Twitter), the studio announced that the Deluxe Edition and a vast majority of the game's DLC items will be permanently discontinued on June 24 at 5 pm PT. “Thank you so much for supporting Dragon's Dogma 2 over the years,” the official statement reads. “Due to the development of additional content and various adjustments for the upcoming title update, the following products will no longer be available.” Most of the optional DLC items are being pulled from digital storefronts, with only two exceptions: the Explorer's Camping Kit (Camping Gear) and the Dragon's Dogma Music & Sound Collection (Custom Sounds). This means players will no longer be able to purchase Portcrystals, Rift Crystals, Art of Metamorphosis incenses, or Makeshift Gaol Keys with real-world currency. After more than two years of community debate, Capcom finally seems to be stepping back from this model. However, for those who have already purchased these items or plan to do so before the deadline, the developers clarified that they can still be used normally if previously obtained. So, if you were thinking of getting some of these, you'd better hurry! While an explicit reason for the removal was not detailed, Capcom nodded toward this being part of the ongoing preparations for the Dark Arisen expansion of Dragon’s Dogma 2, which aims to act as the definitive version of the game with fresh content and new character customization options, and it is going to be released on October 26, 2026. Last but not least, Capcom confirmed that the base Dragon's Dogma 2 game will receive a permanent price discount starting on that exact date, though the studio has yet to specify the exact percentage of the price cut. Either way, the action RPG’s days are officially numbered before it finally becomes a completely microtransaction-free game after all the controversy. Capcom Considers All Resident Evils Canon According To Leaker (Even When It Doesn't Make Sense) A notable Capcom leaker has confirmed that the company considers all of the Resident Evil games canon, even though it doesn't make sense.

AIs are already far more capable than most people realize. A large part of this so-called capability overhang comes not from the limits of AI (though, of course, they still have many limits), but from how people interact with it. The vast majority of people access AI through chatbots, and usually the free versions with less capable models. A chatbot is fine for a quick question, but it is a bad way to get real work done.

In fact, recent research suggests that we pay a mental tax when using chatbot interfaces for work. A new paper had a small group of financial professionals do a complex valuation task with GPT-4o1 and measured their cognitive load from the transcripts, turn by turn. People did see a productivity gain from using AI, but some of that seemed to be offset by the fact that the AI presented information in a way that completely overwhelmed people: giant walls of text, offers to pursue new topics, and sprawling discussions. The chatbot interface appeared to be the obstacle, not the work. And once a conversation got messy, it stayed messy. The AI, optimized to be helpful, just mirrored back whatever disorganized structure the user provided while the user, overwhelmed, didn’t reorganize. Both sides kept compounding the problem. The people hurt most were less experienced workers, exactly the people who could benefit the most from AI… if they could keep track of what they were doing with it

daily

Specialized interfaces

Using the interfaces you already have

Interfaces on Demand

Coding tools that aren’t just coding tools

PhD Level Intelligence?

Gemini 3

The Learning Brain

The Creative Brain

The Collective Brain

Against “Brain Damage”