tomnipotent

None of your examples pass any of the checks for a monopoly unless you twist the definition of "market" to be the narrowest possible. Situational exclusivity is not the same as a monopoly, and these examples don't pass the hypothetical monopolist test or the cellophane fallacy.

There is no legal, economic, or dictionary definition of monopoly that supports your position. The closest example is "aftermarket" (what you call vertical) following the 90's Kodak SC case, which has long since fizzled out. Monopoly might as well not mean anything if you can define it however narrowly you want.

It's amazing how many people throw around the word monopoly without remotely understanding what it means.

Those prices don't need to bake in the training cost, since it was eaten by someone else (whomever trained the open source models). Anthropic et al. need to price in the whole lifecycle.

A web form assumes the input is or can be made structured, or that you have a user that is willing to fill in a form (vs. writing an email). An LLM is great at taking free-form/unstructured content and mapping it nicely to a structured surface area.

More than two decades, folks were grumbling about this in the SOA days.

Not to mention it can query across heterogeneous sources, so the same query can use a duckdb table, sqlite, csv, and parquet (including predicate pushdown).

It doesn't matter what Google makes money from, it matters what they pay Mozilla for. And they pay Mozilla exclusively rev share on ads, nothing else.

Without the ads, there would be no payments to Mozilla. It's absolutely 100% unequivocably ad money.

Apparently you don't understand what bankruptcy means. A company can run out of funds and not be able to meet payroll without declaring bankruptcy, they're different things. But by all means keep talking out of your ass.

MySQL has advocated for decades spinning up a replica with the upgraded version, waiting for it to catch up to master before promoting it to the new master. You can do the same thing with Postgres.

No one said anything about bankruptcy, you seem to have made that up for your "argument" or whatever this is. The company didn't have a viable business model and was running out of cash. MSFT right-sized the team for the project they wanted it to be, rather than the business model the prior company was trying to be.

The company raised $10M, did two rounds of layoffs totaling a quarter of the company, and was then acquired not long after. Early stage companies like that don't do layoffs unless it's to extend cash runway, but run wild with whatever unfounded fantasy you have about it all.

Right, the very public two rounds of layoffs the company did right before being "acquired" had nothing to do with them running out of money.

It's literally a Google search away. If you had the time to write this comment, you had more than enough time to do the search.

> they fired many staff engineers

Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.

> database engine sets up the join

Every major database uses nested loop, hash, or sort-merge joins. If the data is small enough to fetch in a second query, I don't see any scenario where it would make a query spill to disk when it otherwise wouldn't have (except those pesky OR's).

Most JOIN issues can be resolved by composing using sub-queries/CTE's to defer a join to a smaller intermediary result, and the only time this generally can't be done is if you need a predicate on the joined table.

> you've asked the database engine to sort things

I've only found this to be true when there's an OR condition where the single query ends up doing a bitmap against every row, in which case a UNION will be faster since it's just appending two already-index-ordered streams.

> Same with UNION vs IN

A union is almost always going to be worse - most query planners cannot optimize across queries in a UNION, so each query is going to have separate ops vs. a single op with the IN. The only case I've seen this be true is for multi-column predicates with an OR clause against a composite index. I just tested the former in both Postgres and MSSQL and the UNION query cost was 2x the IN clause.

> maybe it decides to do an index scan which takes longer

This has not been my experience unless the table statistics are bad.

I'm not sure I follow. Fetching the data in one query should almost always be faster and more efficient - the same work is being done regardless, except now you have the additional overhead involved with a second query (network and connection overhead, parsing etc.)

You're welcome to do the search yourself, but I'm guessing you won't because it too conveniently debunks your claim/marketing pitch.

I've sold close to $1B on Shopify in the last decade and have never had a problem with them.

Or were you doing something shady that was legitimate grounds for Shopify to remove those products? There's a big difference between what you personally think should be appropriate and what laws and compliance requirements consider. It's like the annual HN post about someone that claims Cloudflare shut down their account and eventually it turns out they were clearly doing something against the TOS.

The answer is most likely none.

It still exists now, but it's always been a incredibly small niche role.

> can actually be sustainably served at $20/mo

Excepts it comes with a terrible experience that's not sustainable for any serious day-to-day work that doesn't involve constant coffee breaks to wait for some tokens to get generated. No thanks. They don't have to live up to the hype to be useful tools, and for something that costs me annually what I make in a day I'm perfectly happy with the value I'm getting of out of it all (even if someone else is subsidizing it... for now).

> going hundreds of billions of dollars into debt

This forum exists exactly because of these companies.

Claude Code isn't OSS, so I fail to see the connection. You're paying for compute, not access to code. I'm personally more than happy to pay for access to that compute.

This is a nice fantasy, but that's all it is. Most of the code used by corporations is also mostly contributed to by other corporations. Contributions by volunteers is the exception for most of the projects in this context. I also don't think this is a bad thing.

> they are not governed by multibillion dollar companies

Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion dollar companies. Red Hat and IBM are responsible for 40-60% of contributions to Qemu.

My personal experience is that programmers confuse what they can do today with what they can learn to do tomorrow.

> you have to design to a lowest-common-denominator that balances

Something that's always stuck with me is a bit from the book "Don't Make Me Think" about cost vs. value in attention and complexity, that when you add a feature used by only a small percentage of users you're "taxing" 100% of users for the benefit of a few. That you should optimize for the common path and not edge cases. Over two decades later I still find this an exceedingly difficult challenge to juggle that doesn't just mean hiding advanced features behind extra menus.

You and others are confusing definition for meaning. An HN rule asks people to engage with the best interpretation of someones argument, in which case it's very clear what the OP was communicating by using "government" where you might use "state", and it's clear from responses that folks clearly know that but have decided to argue over pointless semantics that engage with the posters meaning. Not a single comment tried to engage with the comment with good intentions, so focused on "I gotcha!" vibes over unproductive pedantry. How pointless and petty.

What matters is what the OP was communicating with it, and in English it means all state bodies responsible for administration. No one would argue the US Supreme Court is not part of the government.