1,552 karma · joined November 23, 2016
Like think about a software org with good CI/CD versus one without. The mature org can do consistent incremental releases because each one is safe and low overhead, the messier org will do fewer big releases because each release requires a big effort on its own.
As model developers mature we might expect to see more frequent point releases rather than the big bang evolutions.
Like seriously, what do you want here? Or are you just mad at everyone and lashing out?
Every tool is a trade off between effort to create vs power of the solution.
Effort is generally expensive so most things settle on some general purpose local maximum. If you had infinite effort available, you could build bespoke hardware and software from the ground up to solve every problem. It would be faster and more power efficient than any solution available today.
CPUs win out over integrated circuits because the same CPU can be used for ~every software problem, so by using a CPU you benefit from everyone pooling their efforts to improve the general purpose CPU rather than their own specific niche. But when you reach a certain scale/requirements it makes sense to do something more specific. This is one reason why we have standardized GPUs. Still general purpose but more specialized than a CPU. Or think about how Bitcoin mining moved to ASICs, because they need to do one specific thing as fast and as power efficiently as possible.
So for databases, when you get to specific scale and requirements the same kind of specialization starts to make sense. DuckDB or Clickhouse for analytical loads, TigerBeetle for high scale transactional stuff, etc. And that scale is aggregated across ~all software users, i.e. scale of analytical workloads being big enough to support analytical DBs.
Also as time goes on and industries develop the cost to develop specific solutions can go down.
I see this repeated a lot and IMO it's simply not true.
The main decentralized advantage of Git is that you can continue to do VCS operations without network access or access to the remote host.
Most of what Github does is managing collaboration. The only thing we've "thrown away" by using Github is the email based workflows or directly pushing git branches to various hosts. But unless you're gonna have team members SSH into each other's machines you'd still need a central repo somewhere.
Generally isn't a good bot one that respects robots.txt and is respectful of the site's resources by not being spammy?
The two critical questions IMO are:
1. At what scale do these issues arise? 2. Does Postgres make it harder to solve them when you reach that scale than another solution would have?
Some of that probably depends on the libraries or tools you use on top of Postgres but being able to easily swap to Redis or a proper queue at scale should mitigate the risk of starting with Postgres if you don't already have the scale.
The person you're replying to said they know someone who closed a few deals as a result of their OpenClaw. How is that not interesting?
It doesn't prove that it's globally useful, well implemented, or even worth the cost/effort. But it is something interesting.
It sounds like you're saying "Actually you, as a human, are simply not smart enough to evaluate Opus 4.8"
One provider who was undercutting the market with non-standard billing model moving to a more standard billing and prices doesn't seem like that strong of a signal, other than that Copilot was underpriced.
I don't disagree with your other points though.
I get there's been plenty of vaporware cars in the past but by all signs Slate is making real progress towards delivering actual vehicles.
I've been seeing more things like this lately. It's doing the weird kind of passive deflection that's very funny when in the abstract and very frustrating when it happens to you.
Remember in JJ you're always "in a commit", so the equivalent of the git working tree (i.e. unstaged changes in git) is just a new commit, often with no description set yet. (Because in JJ a commit also doesn't need a description/commit message immediately).
So in a mega-merge you can have a working tree that pulls from local-dev-tuneup, bugfix-a, and feature-b, and you can then squash or split changes out of it onto any of those source branches. Like you can avoid serializing those branches before you're ready to.
I've definitely faced the scenario in Git where I have a unmerged changes that I want to use while continuing work on a feature branch. I end up creating a PR for the branch of the first smaller features (e.g. local-dev-tuneup->master), then a second PR pointing at the first (feature-a -> local-dev-tuneup). It works but it's all a bit cumbersome, even more so if feature-a ends up needing to land before local-dev-tuneup. JJ has better tools for handling this.
Or potentially a team member has critical changes with a PR open and you want to start building on top of their changes now. Manageable in Git but you're locked in on a branch of their branch. Now add a second set of critical changes. Can be done in git but you'll be jumping through hoops to make it happen.
Of course you might say that all indicates a workflow/process problem, but my experience is this situations are common enough but not frequent.
(I haven't actually used megamerges myself yet but the article has me ready to try them out!)
Proceeds to write the hypiest comment possible. No substantial claims of why the model is not hype, just how dangerous it would be if the weights leaked and how cheap it would be for anyone to just start using it for EVIL if it ever did.
Go into Claude right now. What does it have? Internet access after you prompt it.
Ok now pull out your phone, a credit card, a security camera. You can say "Claude these are yours, run a business", but nothing's going to happen until you build an actual harness.
Like the idea presented by the article is interesting, but it's basically just a fluff piece. The actual interesting article would have way more detail.
If you start a new job and on your first day they go "Yeah the last guy said we don't need a database, so he rolled his own." are you gonna be excited, or sweating?
Exception being perhaps "The last team chose to build their own data layer, and here's the decision log and architecture docs proving why it was needed."
That alone is a terrible thing. Open formats are so much more user friendly
What's special about SQLite is that it already solves most of the things you need for data persistence without adding the same kind of overhead or trade offs as Postgres or other persistence layers, and that it saves you from solving those problems yourself in your json text files...
Like by all means don't use SQLite in every project. I have projects where I just use files on the disk too. But it's kinda inane to pretend it's some kind of burdensome tool that adds so much overhead it's not worth it.
- Lets me deploy stateless containers easily
- Let’s me leverage the NAS for local redundancy and a more centralized place to do backups
- When a project grows it’s easy to promote it to use a hosted S3
- Local S3 becomes a target for Litestream and Restic
- Developing against the local fs and then handling file storage is a huge friction, unless I’m using something like Rails that already has a good abstraction
Like `jj commit -m 'Feature A' file1 file2` then `jj commit -m 'Feature B' file3 file 4`