• The Internet Is a Disjointed Memex

    The memex device imagined a lattice of information that grows and can be built on top of incrementally. The internet and hypertext are that—nearly all the world’s information is now captured in the format of the web. However, it’s disjointed which makes it largely inaccessible.

    We’re not so much “surfing the web” as we are “rock climbing the web”.

    A web browser is how we view the internet, but we can only access certain parts. Some information is behind logins, paywalls, or even firewalls.

    The only way to query the vast internet is by a service that can ingest it in it’s entirety and index it as a service—Google. Because this is the primary way people access information, content gets created for (and subsequently mediated by) Google.

    See also:


    Published

  • Protecting the North China Plain Explains Policies in China

    Protecting the North China Plain is the highest priority in China’s policies both domestic and foreign. The North China Plain is where most of the population lives (the Hu Line) and is the ancestral home for the Han ethnic group. There is also a thousand years of history that includes failing to protect the heartland (e.g. Mongol invasion).

    One can explain many seemingly disparate decisions by China when looking at it through this lens. Adding borders and buffers to prevent land invasions—building the Great Wall, invading Vietnam, and occupying Tibet. Preventing invasions from the sea and protecting supply lines—cracking down on Taiwan (and likely annexing it entirely) and the Belt and Road initiative (which leads to persecution of Uighurs).

    Read What China Wants.

    See also:

    • Recent aggression towards Hong Kong and Taiwan China officials called the Sword of Damocles is explained by this protectionist framework.

    Published

  • GitHub Codespaces Is Too Cumbersome and Expensive to Replace Local Development

    After trying out GitHub Codespaces for work, it’s clear that—while impressive—it is not a suitable replacement to developing locally. It’s slow to set up. It’s also very expensive.

    When using Codespaces with a monorepo that uses docker-compose to run services (e.g. a database, frontend app, and API server) you want to have everything running so you can develop as soon as it boots. However, every Codespaces container builds the entire docker-compose each time which takes time for any non-trivial setup.

    If you try to set your .devcontainer to your project’s docker-compose.yml, Codespaces doesn’t expose the running docker services in an accessible way and you are attached to a single container with no way to switch. You can’t see logs (e.g. docker compose logs {service}) or execute code in another container (e.g. docker compose exec {service} {command}). You can’t change which container the Codespace is attached to so running setup or maintenance scripts is difficult.

    You could use the default .devcontainer and call docker from within the Codespace terminal, but then you push the build latency to after the Codespace boots and the user has to remember to call it for the set of services they need.

    GitHub is also working on a feature to pre-build devcontainer images, but who knows how much that will cost in storage.

    Adding up the costs of using Codespaces full time shows that it’s more expensive than buying MacBook Air M1s. At the default 4 core VM at $0.36 you’re looking at roughly $1,000 per engineer per year. Not to mention and you still need to buy and maintain a work laptop.

    There is an argument to be made that you save money on time spent dealing with local configuration issues. This makes sense at larger organizations, but for a small startup, probably not.

    See also:


    Published