HN user

zerotolerance

461 karma

Just a dude

Posts43
Comments156
View on HN
medium.com 6y ago

Write about work, not for work

zerotolerance
1pts0
long-form.com 6y ago

A Long-Form Manifesto

zerotolerance
3pts0
github.com 7y ago

Go Fmt vs. Os in Hello, World

zerotolerance
1pts0
medium.com 7y ago

Dynamic Certificate Management for Cloudflare Origins in Go

zerotolerance
1pts0
medium.com 7y ago

I wrote about “Coffee Shop Life” and what I look for in a place to work

zerotolerance
2pts0
medium.com 7y ago

Guided Narrative: The Secret to Working Toward Consensus

zerotolerance
2pts0
medium.com 7y ago

Where is this “Orchestration” thing going?

zerotolerance
1pts0
medium.com 7y ago

Kubernetes as a Common Ops Data Plane

zerotolerance
2pts0
medium.com 8y ago

Immutable Infrastructure it is Not

zerotolerance
2pts0
medium.com 8y ago

Use Multi-Stage Docker Builds to Inject CA Certs for Scratch Images

zerotolerance
1pts0
github.com 9y ago

Show HN: Local DynamoDB Snapshots as Containers

zerotolerance
2pts0
medium.com 9y ago

Functional Testing DynamoDB Services with a CI/CD Pipeline and Containers

zerotolerance
1pts0
medium.com 9y ago

Poisonous Interface Type Domains (Service APIs)

zerotolerance
1pts0
medium.com 9y ago

Secrets and LIE-Abilities: The State of Modern Secret Management (2017)

zerotolerance
58pts3
medium.com 9y ago

A Few Little Tar Stream Utilities

zerotolerance
1pts0
medium.com 9y ago

“We do REST” is not Enough

zerotolerance
1pts0
medium.com 10y ago

Federated Clusters with Docker Swarm

zerotolerance
4pts0
medium.com 10y ago

Docker Swarm: Flat File Engine Discovery

zerotolerance
1pts0
medium.com 10y ago

Evaluating Container Platforms at Scale

zerotolerance
7pts0
medium.com 10y ago

Toward a Production-Ready Docker Swarm Cluster with Consul

zerotolerance
2pts0
medium.com 10y ago

Real Development Environments with Docker

zerotolerance
4pts0
medium.com 10y ago

RE: Engineering Culture

zerotolerance
7pts3
github.com 10y ago

Show HN: Old School Service Discovery with NMAP for Small Networks

zerotolerance
1pts0
medium.com 10y ago

Docker Networks: Discovering Services on an Overlay

zerotolerance
4pts0
medium.com 10y ago

Docker Overlay Networks: That Was Easy

zerotolerance
4pts0
blog.codeship.com 10y ago

Run a Docker Registry with ECS and S3

zerotolerance
14pts0
medium.com 10y ago

What’s Montague: Docker User Problems and Patterns

zerotolerance
2pts0
medium.com 11y ago

How Not to Fuck Up a Perfectly Good Chance to Hire Someone

zerotolerance
3pts6
medium.com 11y ago

Publishing Docker Images with Automated Builds

zerotolerance
1pts0
medium.com 11y ago

Criteria for Selecting a Docker Image Distribution Method

zerotolerance
1pts0

This is an excellent question and the answer is maybe not too surprising. Where mechanics buy their own tools and nurses have little tool purchasing power, developers produce machinery that is costly to change and if they struggle to use something (activation risk) then we can't get that lock-in to stick. DevRel isn't for the individuals, it is for influencing the aggregate so they get their companies stuck with the solution.

Your comment could have been, "I've never agreed with the design philosophy behind Go." I've always appreciated the apparent Go design philosophy and feel like it most matches my lessons learned from 20 years in software. Feature minimalism is a feature for languages targeting organizations with thousands of programmers. If by 21st century language, you mean one that has become unrecognizable through multiple generations of fashionable feature and ecosystem thrash then I'm all for Go not becoming a 21st century language. Language should be boring if the target environment is large teams with varied skill sets. Plain speak. Low jumpy behavior. No cream, no syntactic sugar. Get the job done.

"will" being the operative word here. High school level Econ makes no promises about WHEN prices adjust. Price setting is a whole science highly susceptible to collusion pressure. Prices generally drop only when the main competition point is price (commodities). In this case the main issue is that AI is commoditizing many if not all types of labor AND product. In a world where nothing has value how does anything get done?

The children are a distraction. They're a secondary justification. Don't lose the plot. This law serves only one outcome: enablement of further authoritarianism.

A simple web we own 5 months ago

We do not have a supply side issue. We have a worsening discovery and discoverability issue. People publish on platforms because that is where they might be FOUND / or pushed by the algorithm into the feeds of others. RSS is subscription, not discovery. Search / suggest / IR requires scaled centralization. Then there are the network effects and activation cost to moving.

Yeah, sure we need this. The time for it was back in like 2005 at the latest.

The real issue is more existential. Right now we're about to lose the war that requires digital connectivity to live and use modern services. We're going to lose cash payments. If you're going to fight a fight, that is where the effort matters in 2026.

"Community" might be the hook, not the content itself. That's the way it works right now even in the pure editorial garbage piles. They might not always pay for the content directly, but they get revenue through high-margin merchandise, advertising, and scams. But you might imagine positioning as "I'm a XYZ reader." Still feels weak, but that's all we've got. The internet killed content scarcity. The product is not the content. The product is the way reading / watching / paying for it makes you feel. It is church. It is a tithing. A community subscription service.

There is a lot of "my" floating around in this article. I always love getting peeks into experiences with this sort of thing, but I think the "mys" highlight something I've seen every day. These agents are really great at bespoke personal flows that build up a TON of almost personal tribal knowledge about how things get done if there is any consistency to those flows at all. Doing this in larger theaters is much more difficult because tribal knowledge is death for larger teams. It drives up the cost of everything which is why individuals or extremely new small teams feel so much more productive. Everything is new here and consistency doesn't matter yet.

But today people can just vibe code their own sudo "with blackjack and hookers!"

/s

Really though, it is remarkable just how high we've built this towering house of cards on the selfless works of individuals. The geek in me immediately begins meditating on OSS funding mechanisms I've seen in the past, and what might work today. Then I remember that I don't believe it can work, but hope desperately that people like Todd can keep paying rent and continue getting some satisfaction from the efforts.

Pure anecdote. Over the last year I've taken the opportunity to compare app development in Swift (+ SwiftUI and SwiftData) for iOS with React Native via Expo. I used Cursor with both OpenAI and Anthropic models. The difference was stark. With Swift the pace of development was painfully slow with confused outputs and frequent hallucinations. With React and Expo the AI was able to generate from the first few short prompts what it took me a month to produce with Swift. AI in development is all about force multipliers, speed of delivery, and driving down cost per product iteration. IMO There is absolutely no reason to choose languages, frameworks, or ecosystems with weaker open corpuses.

I always like finding people advocating for older sage knowledge and bringing it forward for new audiences. That said, as someone who wrote a book about Docker and has lived the full container journey I tend to skip the containerized build all together. Docker makes for great packaging. But containerizing ever step of the build process or even just doing it in one big container is a bit extra. Positioning it as a build scripting solution was silly.

Google created two kinds of value: content discovery via connection (value to the consumer), and market reachability for advertisers. Oh, and also the world's most inconvenient spell check.

AI proposes to solve: a content supply side problem which does not exist, and an analysis problem which also only maybe exists. Really what it does in the best of cases (assuming everything actually works) is drive the cost to produce content to zero, make discovery less trustworthy, make the discovery problem worse, and launder IP. In the best case it is a net negative economic force.

All that said, I believe the original comment is about the fact that the economy exists to serve market participants and AI is not a market participant. It can act as a proxy, but it doesn't buy or sell things in the economic sense. Through that lens, also in the best case the technology erodes demand by reducing economic power of the consumer.

That said, I'm stoked to hear about the next AI web site generator or spam email campaign manager. Lets setup an SPV to get it backed off-balance sheet.

It is such a pure thing when an engineer looks at the world and is surprised, frustrated, or disappointed at behavior at scale. This is a finance game which in itself is a storytelling / belief based system. It might seem like math, but when you're playing on the growth edges valuation is really is about the story you tell and the character of the players. Thats only worse when people stop caring about cashflows or only expect them to happen "in the future" because that makes it someone else's problem.

Nobody is buying them today. But these shaky clumsy versions didn't exist even a few years ago. The hype promises these things tomorrow, which is obvious BS. But the better they look today the more investment will be poured into their R&D which accelerates real improvement, which accelerates investment, etc.

Generalist robotics are all about minimizing or at least front loading some portion of retooling cost, minimizing overhead associated with safety and compliance, and being able to capitalize what would have otherwise been human opex. Those pressures aren't going anywhere.

The most difficult part is managing the delivered / processed state and ordered delivery. Consistent ordering of receipt into a distributed buffer is a great challenge. Most stacks do that pretty well. But deciding when a message has been processed and when you can safely decide not to deliver it again it is especially challenging in a distributed environment.

That is sort of danced around a bit in this article where the author is talking about dropped messages, etc. It is tempting to say "use a stream server" but ultimately stream servers make head-of-line accounting the consumer's responsibility. That's usually solved with some kind of (not distributed) lock.

There are good things about this article. It seems like a nice intro for people who have never worked on this type of system. And I'm always happy to celebrate someone's win. But I feel like it was missing an overview of what actually makes distributed queues difficult (the distributed part) and why you probably don't need them if you can survive without them.

Did he need it to prove a business viable if there were already players in the market? No. Do you ever need to validate that people would switch providers of a commodity product or service if presented with a cheaper option? Also no. What did he learn then, that he can create a partial solution that people might pay for initially (no data on renewals) but will ultimately have to actually hire people to build a real product which will eat at his differentiator (price). Wait until he decides he actually has to spend money on marketing.

The good news is that with each of these we get to "validate" that having an idea still isn't worth much without the ability to actually execute.