Choosing to do an app is quite often less about the capabilities (of an app on the phone, versus a website in a mobile browser) and more about discoverability and market reach. App Stores serve a "store window" purpose, where it is easy to search, easy to discover, easy to access new tools/solutions.
What annoys me is not that "this app could've been a webpage". It is that "this app should also have a web version".
TripIt comes to mind as the opposite way: they started as a website only, and quickly the need to have an app was obvious: GPS integration, offline access, contact list for sharing, and more.
This is how tickets for sports and concerts should always be sold.
Entertainment tends to compare with airline tickets, except that with air travel, there are regular flights and competition. There is no such thing as a single flight from Paris to New York on one Saturday at 9pm on a window of a few years.
> Founding cannot be a commodity. If it is, you have no moat or point, meaning you instantly collapse again, because you are an interchangeable commodity.
With the recent AMD announcement [1], local models are likely the future indeed. Cloud will be the place for remote sessions, remote agents, continuous agents. But I foresee a place where phones, laptops, PCs, and even perhaps dedicated hardware just for AI, will be the place for most AI-related workloads.
If you get caught with illegal guns and illegal chemicals, well... there are consequences. Bad actors will always find a way, at the risk of getting caught.
However, the vast majority of people will rely on commercial AI models.
> But I think mostly it will be used to serve ads.
If only...
I do believe that access to commercial AI should be regulated, heavily taxed, and controlled just as much as access to dangerous chemicals and weapons. Only this way the best AI models are more likely to indeed be used for frugal purposes (sadly, however, including ads).
Sonatype allows "io.github.<username>" as a valid groupId and has a process to verify ownership. I am sure other providers like GitLab can work on this.
That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype.
But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they are generally avoided because they hurt reproducible builds. That means a malicious new release does not automatically flow into most consumers’ builds just because it was published.
I'd go as far to say that NPM should:
1. Enforce scope (namespace) requirement, and require external verification (reverse DNS for example).
2. Disable version range support out of the box. User must --enable this setting from the command line at all times.
3. Remove support for install scripts completely. If someone wants to publish a ready-to-run software, there are plenty of other mechanisms.
It is 100% up to the package manager's steward to control how ownership of packages and namespaces are granted.
Maven Central exists for decades the amount of incidents of people stealing namespaces is minimal.
One can't simply publish a package under the groupId "com.ycombinator" without having some way to verify that they own the domain ycombinator.com. Then, once a package is published, it is 100% immutable, even if it has malicious code in it. Certainly, that library is flagged everywhere as vulnerable.
It baffles me that NPM for so long couldn't replicate the same guardrails as Maven Central.
A lot of "Claude Code is best at X" claims are probably user-selection bias.
The people saying it are often exclusively Claude Code users, not people who are actively benchmarking Claude Code against Gemini CLI, OpenAI Codex, GitHub Copilot, and other agent harnesses on the same tasks.
The claim may still be true for certain scenarios, but the evidence is usually anecdotal, not comparative.
Indeed, the fact that maintainers didn't have until only recently the control for disabling Pull Requests tab in a GitHub repo, is what drove a lot of issues in FOSS collaboration over the past decade.
FOSS and open source licenses never ever granted entitlement for contributors to have their proposals reviewed/merged by maintainers. Neither it ever offered entitlement for users to ask for free support.
FOSS is about giving people access to source code so they can do with it whatever they want, and maintainers/authors should have always had the ability to "publish and forget" the source code, without having to deal with those "entitlements".
I wonder if a model that does not know anything about a hypothetical programming language X, could write code once given said language X specification, APIs, and SDK tools and their documentation.
Meaning: the model has no idea, no access to examples, no previous codebase trained on, nothing, for language X. But it knows English, it knows how to program in general (training data does contain other programming languages), and everything we expect from LLMs today. It just doesn't know jack about language X.