> $200/month is already out of reach of the majority of the population.
1. You can build small applications with the $20/month sub, much more with the $100/month. Competition and technology improvements will inevitably improve the price to value ratio.
2. Cable sports subscriptions are in a similar price range. Expensive, but not exclusive to “the elites”.
The median per capita income in the United States is $37,683/year.[0] Depending on your state, after taxes, that's something like ~$2,600/month. You're asking almost 10% of their post-tax income to this just for the opportunity to create software. With rent, food, and other living expenses many households at that income level simply cannot afford this.
This is the median income. If it's a struggle for someone on this income then it's worse for half of all Americans, and American incomes are higher than most of the rest of the world.
Very much on the same page as the author, I think AI is a phenomenal accelerant.
If you're going in the right direction, acceleration is very useful. It rewards those who know what they're doing, certainly. What's maybe being left out is that, over a large enough distribution, it's going to accelerate people who are accidentally going in the right direction, too.
Maybe to the people writing the invoices for the infra you're renting, sure. Or to the people who get paid to dig you out of the consequences you inevitably bring about. Remember, the faster the timescale, the worse we are wired to effectively handle it as human beings. We're playing with a fire that catches and spreads so fast, by the time anyone realizes the forest is catching and starting to react, the entire forest is already well on the way to joining in the blaze.
> We're playing with a fire that catches and spreads so fast, by the time anyone realizes the forest is catching and starting to react, the entire forest is already well on the way to joining in the blaze.
I suspect this has been said in one form or another since the discovery of fire itself.
Even if it is as perennial as contempt for descendents, when the fact is that signals are getting so fast they trigger downstream responses faster than a neuron can finish it's refractory period renders it not exactly a trivially dismissable observation.
Liz is one of the most genuine and thoughtful people I ever worked with. The software world would be a better place if more people like her were running the show. Best of luck to her.
A directory over SSH can be your git server. If your CI isn't too complex, a post-receive hook looping into Docker can be enough. I wrote up about self hosting git and builds a few weeks ago[1].
There are heavier solutions, but even setting something like this up as a backstop might be useful. If your blog is being hammered by ChatGPT traffic, spare a thought for Github. I can only imagine their traffic has ballooned phenomenally.
> The origin of a git repo is more or less just the contents of the .git directory in a remote location. That's it. You don't even need to run a git server if you're happy enough using ssh for transport.
Yeah. You probably do want to make sure you turn your .git/ into a "bare" git repository but that's basically it.
And it's what I do too: an OCI container that gives me access to all my private Git repos (it sets up SSH with U2F so I get to use my Yubikey to push/pull from various machines to those Git repos).
I use https://pipe.pico.sh for this use case. It’s a pubsub over ssh. It’s multicast so you can have multiple listeners on the same topic, and you can have it block or not block the event.
Most builds take a long time, at least in C++ and Rust (the two languages I work in). And from what I have seen of people working in Python, the builds aren't fast there either (far faster of course, but still easily a minute or two).
Also, how would PRs and code review be handled?
Your suggestion really only makes sense for a small single developer hobby project in an interpreted language. Which, if that is what you intended, fair enough. But there really wasn't enough context to ascertain that.
I did give additional context in the blog post I linked, but yes, to be clear, this is something that will really work best for small projects with reasonably fast build cycles.
If you're already at the point where you're fielding pull requests, lots of long running tests, etc., you'll probably already know you need more than git over ssh.
I've heard it described as the first time many non-programmers have been able to make computers "do things" without it being defined by someone else (app interface, developer, etc). It's a hugely empowering development from that perspective.
The stuff you've listed are the kinds of things smart home enthusiasts do with whatever tools are available to them, and are just a sign of people exploring the possibility space.
are non programmers actually using openclaw successfully? because even "step 1 install your API keys" requires navigating concepts that are foreign to most "civilians"
Journalists, anyway. I think I originally heard it from Casey Newton on Hard Fork, but it was a month back so not 100% sure.
But there's loads of people who would be stumped by a for loop, yet can easily work their way through a setup guide, particularly with the hype/promise and an active community.
I've been tinkering away on one of these myself, https://rockstar.ninja. I expect there are a hundred others out there, going to be interesting to see what the end shape of these tools is.
1. You can build small applications with the $20/month sub, much more with the $100/month. Competition and technology improvements will inevitably improve the price to value ratio.
2. Cable sports subscriptions are in a similar price range. Expensive, but not exclusive to “the elites”.
reply