This is far outside of my wheelhouse, but I have some serious questions about the methodology here.
I dug into what they call a "resiliency checklist", which is what looks to be a set of questions that have qualitative answers which are subjective at best. This information looks like it is fed into the CRRI, the data set that substantiates the city-wide scores used to power this report.
I am very skeptical that these 2 things happened:
- They captured a representative set of key assets that go into making a "city"
- The answers they received are calibrated or are meaningful enough to make these large conclusions
I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.
Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise.
Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
> RoR was so brittle and slow that they couldn’t hire enough to keep it going.
This is such a "poor carpenter blaming his tools" take.
RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time.
By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.
You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.
Is it though? It doesn't need to be perfect to last. Good engineering practices certainly embrace timeless concepts. I understand if you are working in a feature-factory, but creating inheritable code should be given more consideration however much programmers dislike thinking about things like ROI.
Docker is built for web. The mental model is that the internet speed is relatively fast, the image is relatively small, and the device you're pulling onto is starting with essentially no data. All three of these assumptions are wrong for robotics:
- I've had someone in the Docker discord tell me at length that my container shouldn't be bigger than 1GB, which is impossible the moment you pull in CUDA or any ML libraries.
- Robots pull over 3G/Starlink/slow customer WiFi
- Robots are edge devices! They have previous related images, they aren't pulling onto a fresh disk like on web.
It's super common to have a layer in your Dockerfile that has several GB worth of dependencies. If you touch one of the dependencies, it thrashes that layer and anything below it. To quote the CPO from a company I left "Anytime anyone looks at the container the wrong way its a 13g dl over a shit cell connection or starlink". It's extra shit because most of the data the robot is pulling, the robot already has in another layer!
Clipper solves this by breaking apart Docker layers and indexing the files within. When you pull an image it will reuse related files in images you already have on your device. This has other side benefits as well, like being able to mount layers as networked filesystems and much more easily being able to run P2P updates.
It's less that robotics needs a different container registry and more that robotics needs a better container transport, and I've built the infrastructure around it for my registry.
Very interesting. We’ve for sure felt the pain of large robotics images and slow deployments, especially when CUDA and ML dependencies are involved, or when adding a seemingly small ROS package pulls a long chain of transitive dependencies. The file-level deduplication approach is clever. Curious how transparent it is to existing Docker/OCI workflows. Does it require any changes to the client, or it mostly sits underneath the existing tooling?
It mostly sits underneath existing tooling. I replace the push/pull client (run `clipper pull` instead of `docker pull`, and optionally the BuildKit driver (to get build outputs natively in my format). That pull command ingests the image into your chosen runtime, meaning your docker/podman/k8s run commands remain the same. If you're interested I can set up a demo/call/coffee.
I like the idea behind the site, but I have some nits.
First, when you list something like a financial figure, you must also include the relevant time period. E.g. you say 16.0B in taxes collected by Canada from American exporters. But you don't list the time period.
Second, you say 313 are taxed today. What is this in reference to? Goods? People? Companies? Percentage?
I strongly disagree. GitHub, a year ago, acknowledged the fundamental problems and began work on them. We all agree with the diagnosis and strategy: stop building new things, bring stability. Why would whether the CTO codes have any bearing on the correctness of this strategy? GitHub’s problem isn’t that leadership don’t understand the product, or that they don’t know what they should be doing, it’s that they’re battling unprecedented demand. If it was a disconnect between users and leadership on what matters, sure, a CTO who doesn’t use the product would be notable, but that isn’t the problem. And that’s all assuming he doesn’t actually use the product, maybe his privacy settings hide private commits.
Interesting - There's a couple of things that I disagree with here, but I do think this resonates: "We all agree with the diagnosis and strategy: stop building new things, bring stability."
Where I have a problem with the positioning of their GitHub profile is, he's the CTO of GitHub, arguably the defacto standard for open-source version control systems. His GitHub profile is linked to as the author for the post, and his GitHub profile simply tells me: "this guy doesn't code."
I don't care if this guy doesn't work on GitHub itself, I hardly would expect that, but IMO, any CTO of a company like GitHub should eat, breathe, and sleep code. He might, but his profile, which is being published as if it means anything, tells me he doesn't.
In other words, I think his private contributions should still manifest on the contribution graph. And for being the CTO of an organization like GitHub, with no open-source contributions... Not a great look.
I like the direction of capturing the human intent as a durable artifact, but I dislike how you've gotten there.
Let's look at your fizzbuzz example. Unfortunately, if you wanted to have the agent implement fizzbuzz for you, it looks like, in your example, you would have to already know how to effectively write fizzbuzz. Specifically, you call out the use of the modulo.
In your prompt, for the traditional agentic development path, you already declared the intent. There is some imperative language in there, sure, "Create a function that ...", but also there is the declarative state, that doesn't require knowledge of specific programming syntax or semantics.
What I've relied on is a more formal location/syntax for acceptance criteria are in code. These are then used to generate tests, and implementations. It isn't perfect, and more investment is needed, but it starts getting at the root of the problem.
What a weird line to draw. Data centres do a lot more than what you report. E.g. they might host your electronic health records. They might host census data, or weather data, or your kid's school learning management system.
As the creator of mediaden.ca[1] I’ve thought about this. Client side scanning is maybe marginally better than server side scanning, but both paths lead to privacy rot.
Governments need to catch criminals, but they shouldn’t do it at everyone else’s expense.
I dug into what they call a "resiliency checklist", which is what looks to be a set of questions that have qualitative answers which are subjective at best. This information looks like it is fed into the CRRI, the data set that substantiates the city-wide scores used to power this report.
I am very skeptical that these 2 things happened:
reply