Mine was more a generic argument against the "ban all AI" stance that I've recently seen pop up more often.
At the moment, there isn't another project (that I know of) like PostmarketOS filling the same niche. If a new project were to appear, and were using LLMs, it'd likely progress faster.
Regardless, I've had success with LLMs and while I understand the maintainers' concern, if used properly they're a powerful tool to quickly iterate on huge amounts of information. They could be used to automate reviews of the spam of low-quality PRs, for instance (if they were to materialize).
But having read their policy page, their stance is more on ethical grounds, not moral: https://docs.postmarketos.org/policies-and-processes/develop... . So while I still stand by my argument in the general case, here it's not applicable, and while I see their ethical concerns, one project boycotting a tool doesn't really fix the systemic issues they mention.
if you think of it like a bond it’s pretty fantastic. coupon rate 3.5% and you got it at a giant discount to par even though it’s actually (according to this guy’s beliefs which proved correct) nearly certain to be repaid.
You can run an entire apartment block off of a single sim card/phone line. The (technical) problem is that you are purchasing an insufficient amount of bandwidth. It goes without saying that a limited bandwidth integrated over a finite service period comes out to a limited amount of data, so the term is misleading.
If google has no obligation to provide the service tier, then they should stop providing it instead of providing it under false terms.
This is like if everyone in a city decided to take baths instead of showers, so the municpal water supply decided to ban baths instead of properly segmenting their service based on usage.
Service providers don't have the right to discriminate what their service is used for.
I don't think that's an apt metaphor. You bought one general water supply, like an API user. If they sold a "no baths" cheaper option I'd be fine with them banning baths to those customers.
Google's API does let you use any client.
The gemini/antigravity clients are a different (subscription) service. When you reverse engineer the clients and use their internal auth/apis you will typically have very different access patterns to other clients (eg: not using prompt caching), and this is likely showing up in their metrics.
This isn't unusual. A bottomless drink at a restaurant has restrictions: it's for you to drink, not to pass around to others at the table (unless they buy one too). You can't pour it into bottles to take large quantities home, etc. And it's priced accordingly: if sharing/bottling was allowed the price would have to increase.
> Service providers don't have the right to discriminate what their service is used for.
They frequently do have those rights, though. It's up to the paying customer to either pay for a different tier or move to a competitor who offers the tier they need.
You are never going to get a court to agree that service providers cannot offer different tiers, or segment their offerings.
Lmao no. You cannot use your common sim card for that. It's for an individual and they will cut your service and justifiably so, if they figure out that's what you're using it for.
If you buy a sim card built for that purpose sure, but then you'll be paying...biz prices!
This isn't really that hard to figure out people. So much outrage in comments on this. Self entitlement to the max from people who really haven't lifted a finger to stop the corporate overlords anyway.
So, if I use my SIM card 16 hours a day, 7 days a week, Ill get banned? Doesn’t that seem absurd? The SIM card is enforcing one voice call at a time. If the apartment building has to wait in line to use it, what’s the difference?
If you deployed it in a way that did multiplexing such that multiple users could use it at once, then sure—-Business time. But otherwise…
> So, if I use my SIM card 16 hours a day, 7 days a week, Ill get banned?
Probably not - you'll get billed or hit a FUP
> Doesn’t that seem absurd? The SIM card is enforcing one voice call at a time. If the apartment building has to wait in line to use it, what’s the difference?
The difference is that it is perfectly acceptable to enforce a "no-reselling" or a "no-3rd-party" for services.
I can't think of a single service provider that provides a consumer tier permitting reselling or 3rd-party use.
I can do it pretty easily. The restriction in both cases is so easily overcome it is ridiculous to build your buisness model around it and disrespectful to the customer's intellect.
> it is ridiculous to build your buisness model around it and disrespectful to the customer's intellect
Many things in business are easy to defeat if you’re willing to break the rules. Enforcement is handled through audits, flagging suspicious activity, and investigations.
It’s ridiculous to think that because you can temporarily circumvent a restriction that the rules don’t apply.
I don’t agree with the excessive enforcement used, but there is a lot of tortured logic in this thread trying to argue that the contract terms shouldn’t apply to service usage because the customer doesn’t like the terms.
The difference is that in micropayments the debt is practicially nothing, a fraction of a cent. So there's basicially no risk. Pre-pay, post-pay, doesn't really matter.
With minipayments, you could still lose a dollar or something. It's like a vending machine. If I put in a dollar and don't get a cookie, I will be pissed. You can run a buisness of setting up fraudulent vending machines that scam customers on the first purchase and dont put out cookies.
I don't really care if I put a tenth of a cent in and don't get my crumb out. I just won't buy the rest of the cookie. The margin on selling me the whole cookie is greater than scamming me out of a fraction of a cent. So it's not feasible to scam.
So the distinction matters. It's a difference in kind because in one model there is enough risk to sustain a buisness model off of scamming, which requires all this extra infrastructure for fraud prevention.
The benefit of micropayments is you don't need all this overhead for for fraud. Anyone can set up a vending machine pretty much anywhere and sell to anyone else.
The throughput is arbitrarialy limited by bitcoin's current block size, which hasn't been increased since satoshi's era.
Most cryptocurrencies have an adaptive block-size mechanism which allows the blocks to grow to a reasonable size which could facilitate such an onboarding of users. So it isn't a technical problem, it is just a question of bitcoin's current leadership, which is controlled by companies like blockstream.
People have been debating the blocksize for a very long time now and there doesn't seem to be any large desire to change it so while the ability to increase it exists changing anything that fundamental about bitcoin seems to be a non-starter and while that is true lightning is pointless as a solution for the masses.
Even if you increase the block size 100x though you're still not improving the numbers much since my very generous numbers ignore activity outside of lightning and assume a single on chain transaction for every user and a perfect network.
Maybe your understanding of lightning is wrong here. Yes you open channels, and transactions in lightning need open channels, but you do NOT NEED to open channels for specific transactions. You open channels once, and transact over them for years. I run a lightning node with more than 15 channels (each to different lightning nodes) that are all older than 1 year (I route payments, so I have way more channels than needed). You can batch-open channels, i.e. I could have opened all my 15 channels with a single on-chain transaction. Taproot update would make those "commitment transactions" onchain way smaller (in byte) than needed to in the past.
Once channels are open, the users on the lightning network can transact back and forth without any new channel opens/closure and thus no on-chain settlement. Hence: Throughput in lightning is not at all limited on the bitcoin transaction throughput.
reply