1) Rewrite the file to disk 2) Append the new data/metadata to the end of the existing file

I suppose you could pre-pad documents with empty blocks and then go modify those in situ by binary editing the file, but that sounds like a nightmare.

In those days if you needed a car to take you someplace, aside from the outer boro examples, it was always faster to get a yellow cab. The car services could maybe get there in 45 minutes if you were lucky - big companies would often have deals with car service companies to have a few cars stationed at their buildings for peak times, so execs didn't have to wait for a car.

The yellow cab operators were essentially all independent - many rented their medallion/vehicle, either from a colleague or an agency, but they worked their own schedules and their own instincts on where to be picking up fares at given times.

No one expected something like uber - what is essentially a street hail masquerading as a livery cab. This basically destroyed yellow cabs and the traditional livery cab companies, but some of it is attributable to the VC spend, lowering prices (yellow cab fares are set by the city, livery cab fares are market-regulated) and incentivizing drivers. They made it so lucrative to drive an uber that you had thousands of new uber drivers on the road, or taxi drivers who stopped leasing their medallions and started driving uber.

At some point, though - the subsidies dried up, prices went up, and now its often faster to get a yellow cab than an uber/lyft. This is anecdata, but I take cabs a lot, and I've spoken with ~6 taxi drivers in the last year who either started with driving uber and shifted to driving a taxi, or went taxi-uber-taxi. Then I've had a lot more taxi drivers where they need passengers to put the destination into the driver's waze or google maps, even for simple things like intersections - I suspect they're uber drivers who became depedent on the in-app directions and native language interactions.

But the broader point I'm making is that in NYC, the drivers themselves were essentially unable to do anything about the changing market. The only power they had was to shift between the type of fares they were getting. And today when you order an uber, sometimes you get a yellow cab.

I’m asking because I used to work adjacent to this area, and I know of only a few scenarios where an account becomes a workspace account after being a consumer account.

When you look at the github repo for the gemini CLI:

https://github.com/google-gemini/gemini-cli/tree/main

At the bottom it specifies that the terms of service are dependent on the underlying mechanism that the user chooses to use to fulfill the requests. You can use code assist, gemini API, or Vertex AI. My layperson's perspective is that it's positioned as a wrapper around another service, whose terms you already have accepted/enabled. I would imagine that is separate from the Gemini app, the settings for which you linked to.

Looking at my own settings, my searches on the gemini app appear, but none of my gemini API queries appear.

https://github.com/google-gemini/gemini-cli/tree/main

If you scroll to the bottom, it says that the terms of service are governed based on the mechanism by which you access Gemini. If you access via code assist (which the OP posted), you abide by those privacy terms of code assist, one of the ways of which you access is VScode. If you access via the Gemini API, then those terms apply.

So the gemini CLI (as I understand it) doesn't have their own privacy terms, because it's an open source shell on top of another Gemini system, which could have one of a few different privacy policies based on how you choose to use it and your account settings.

(Note: I work for google, but not on this, this is just my plain reading of the documentation)

"If you don't want this data used to improve Google's machine learning models, you can opt out by following the steps in Set up Gemini Code Assist for individuals."

and then the link: https://developers.google.com/gemini-code-assist/docs/set-up...

If you pay for code assist, no data is used to improve. If you use a Gemini API key on a pay as you go account instead, it doesn't get used to improve. It's just if you're using a non-paid, consumer account and you didn't opt out.

That seems different than what you described.

When I think of Airbnb, I think of an apartment with a pool in the Caribbean, where I have to hunt around to figure out the best places to eat, or cook myself.

But also - I just ordered something off of amazon and I noticed that the confirmation had the item that I ordered in it, albeit in a shortened/summarized way? So maybe they brought it back, figuring that with just part of the name, there's not much someone can do with the pricing information? Or maybe they just don't care anymore?

(disclosure: I work at google, but not on this, but worked adjacent to the gmail team for a few years and am going off of my memory. I'll also tap the sign that Google doesn't mine your gmail for ads, for both consumer AND paying customers).

When you’re not married anymore, I’m in favor of the idea of making it easier to change child support payments in situations where things are amicable and jointly agreed to. I am very much aware that is not the situation today.

My point about losing flexibility is that when you have kids, your choices are not your own anymore. You can say all you want that they need “necessities”, but I know from experience that the way people interpret that varies widely. I think the only fair way to do it is to keep QOL as the goal. If you want more accountability as to how the money is spent, sure, though I’m not sure how that would work in practice.

Of course it does - because both parents are responsible for the welfare of the children, and so if they both decide that they want to lower the standard of living that is a shared/joint agreement.

If the non-custodial parent decides they want to lower their child's standard of living, a) that is a unilateral decision, and b) they (the non-custodial parent) don't have to bear the implications of that lowered standard of living.

> your system would have me a criminal were it I didn't have custody.

Yes, sadly, having children means that sometimes you lack flexibility and can't make the decisions you would like to make.

There is extremely damning evidence that this unnamed individual ("D.S.") in Ireland was acting at the behest of Deel senior leadership, including:

- the COO of deel reached out to a rippling payroll manager on linkedin to recruit them. The rippling employee didn't respond. Shortly thereafter, D.S. pulled up that employees personnel record in the HR system that has their unlisted phone number. Shortly after THAT, the COO of deel reached back out to that employee via WhatsApp and that phone number.

- The information was about to publish a story about Deel potentially violating sanctions. New information in the article was that at least one of the customers involved was a company called "tinybird". No one at rippling was aware that this company even existed, but a week BEFORE the article came out, but after the reporter had been asking questions of Deel, D.S. started searching Slack for "tinybird" (and there were no other searches of "tinybird" across the whole company)

- Around the same time, the reporter for the information reached out to rippling and had internal Rippling slack messages about potential similar sanctions violations. A short time before that happened, D.S. was suddenly searching for "russia", "sanctions", "iran", etc.

- There was an email between D.S. and the ceo of Deel, along with an introduction to someone from the family VC fund.

- And then, of course, the honeypot - a fake channel, fake chats from the Rippling CRO, but the chats had real stories that former Deel employees had alleged. Email sent to only the CEO of Deel, his dad/chairman of the board, and their GC. Just a short time later, D.S. was searching for the fake channel, trying to find it, adn trying to find these chat messages.

I'm sure the CEO will try to have plausible deniability, that it was someone else in his org that he delegated investigating these things to, he had no idea, etc. But if they can get D.S. to crack and share the details of what happened, I think it will be tough to toe that line.

But okay, you have RSUs - how familiar are you with your agreement? It could have been a double trigger vesting arrangement, where the shares "semi-vest" over time, but then they don't fully vest until a liquidity event, at which point poof suddenly all of those ghost shares become REAL shares. If that's the case, they likely baked in a process for employees to have those shares withheld, or auto-sold during the lockup period. It's all tied in with their HR system and other payroll processes to make that easy.

Another scenario is that at some point since you left, or right before the IPO, they re-issued everyone's shares to be a different share class, because they wanted to clean up their cap table before going public. For employees they could just fix that for them, because again - all baked into the existing systems. For previous employees (and people who were gifted stock and former board members and advisors and angel investors and whoever else), they don't have an easy way to fix this. The old stock class technically doesn't exist because its been converted, so they can't sell to cover, and when they convert, they couldn't automate that because they don't have your withholding information and other payroll details for compliance purposes.

In either scenario, it's worth either reading your agreement carefully and/or talking to an attorney. Regardless, however, if this was related to an IPO, the legal and compliance stuff on this is going to be buttoned up and carefully done, so assume that (however unfair) they either have to do this in this fashion or it's much easier for them to do it this way (or some combination of both). It is possible to do very shady things during a private transaction, even a private transaction with a publicly traded company, but not for an IPO.

There are companies that will loan you money to cover vesting costs or these types of situations - they'll do it at shitty rates, but if the options are losing out on a windfall or losing an extra 10-20% on the windfall, it's worth considering.

If you have options, this is entirely because of the different treatment between ISOs and NSOs.

Is it possible you thought you had RSUs but instead had options?

What would be other metrics that you could bill consumers for that they could do anything about?

> You aren't required to have a complicated pricing structure even for incredibly complicated services. Doing so is a deliberate product choice with consequences.

You're making my point - the simpler you make it, and the more abstractions you put, the more decoupled each billed object is from the underlying costs. The implications of that are that you have to be careful about making sure that the economics work out, and that means either you have some customers subsidize others or you are very confident that customers can't use your product in such a way that it turns your numbers upside down. At the same time, that abstraction that you choose will not map to how every customer wants to buy.

To go back to several posts ago, "per user" pricing is a per-unit abstraction that lots of customers like and understand. Sure, customers recognize that some users will use more than others, but it's a deliberate product choice that you abstract the more complicated dimensions from the users.

It sounded like YOU, as a buyer, want a DIFFERENT abstraction, which is "usage" - and again, that's reasonable, but as a product team have to make exactly the same calculus, which is "what metric do we use instead as a proxy?", with the understanding that there are lots of SaaS products where usage patterns are highly variable and it is difficult to come up with single units that cover your bases without making the per-unit price higher than it might otherwise be.

It's not hard to imagine yet another buyer who says (assuming the product metric chosen was "storage consumed"), "wait, I like usage billing, but your per-GB cost is really high for us, because we store a lot of data, but we don't access most of it - why can't you just charge me for data accessed?". You either say no or add more billing dimensions.

> They're also not truly fungible, though that's mostly for the higher end of the consumer market. Think about TMobile's "uncarrier" marketing, or Verizon's network coverage marketing.

It's interesting, because that ALSO proves the point, because the only differentiation you are citing are things other than what customers are being metered for. There's availability differences, but that's orthogonal to the billing metric. If I have connectivity, my minute on tmobile is the same as my minute on verizon is the same as my minute on mint, and the differentiation is everything OTHER THAN the billed minute.

To wrap up - I don't disagree with you that there are benefits to usage-based billing. The point that I am making is that for essentially any SaaS product that has any depth, it can be difficult to pick a single metric at an attractive price point that a) covers your margins across the spectrum of usage behaviors, and b) maps to the metric that the vast majority of your users want. If you try to make everybody happy, you either lose the simplicity or you hurt your underlying margins while simultaneously making everybody's lives harder.

Consumer telecom is a great example of a very constrained problem space. There’s two levers, call time and data. And the population of people who are consuming that are limited to the size of the family.

By contrast, enterprise telecom is incredibly complicated, with variable pricing by region, by time, type of inbound number, and then the software that sits atop that telecom is an additional license.

Telecom is also largely a commodity - one provider is the same as the other. SaaS providers are fundamentally trying to not be commodities, and so the comparison is weak at best.

It is true you CAN do this, but very few do, for a few reasons:

One is, it's bad for margins - when you build a pricing model, you inevitably end up creating a system where some customers subsidize other customers. You assume each user or unit of usage is going to cost you X/unit and you charge X+Y. There is inevitably going to be a distribution of users and their usage patterns and costs, and the 90% percentile is probably going to be 5X, and the 10% is probably going to be .2X. There's not any malice there, it's just that different users have different usage scenarios and they use the product differently.

Another reason relates to the issues with usage-based billing. Even in that scenario, whatever usage dimension you measure on will have users that don't fit the profile and they still end up being subsidized (from a margins perspective) by customers that DO map to the profile. A really naive example - you're a database company, you want to be cheap for people to get started, you go with usage based billing and charge based on storage. For most customers, that works - assuming your product value is apparent and differentiated, I think most people would understand that "I have to pay more because I'm storing more data, and accessing that data can be more expensive, queries more complex, and the utiltiy that I get from the database scales as the quantity of storage increases". Great, usage based billing, let's do it.

But - then you have users who store very small amounts of data but with incredibly high query volumes. Your options are to either just eat the cost of those users (which might be fine for some amount of time) or now start to add additional dimensions on which you meter usage. So now you charge for storage AND cpu time AND maybe concurrent connections if that's a problem AND bandwidth. Congratulations, you have now created the perfect usage-based billing model, which perfectly assigns customer charges to handle the multitude of usage patterns that customers experience.

BUT, it's really complicated to explain to people, and it's really complex to predict costs. That has two implications, one of which is that your value proposition has to be increasingly compelling as complexity increases. To use the database example, at some point someone at a customer will say "honestly, wouldn't it be more predictable if we just spun up a couple of VMs and ran a database instance ourselves?". Complex usage-based pricing works if you've got incredible technology that would be difficult to impossible for a customer to deploy themselves, but if your value prop is convenience and/or abstraction, you're diminishing that value as you make the pricing model increasingly less convenient and less abstract.

The other factor is that someone has to build and manage the metering of all of these things. Even a single dimension like storage is complicated - how do I bill for additional storage? Do I look at the total storage at the end of the month and multiply by X? That hurts users who, say, run end of month batch jobs - but for you, users that use huge amounts of temporary space and then free them before the end of the month, that hits your bottom line (depending on your own architecture). So maybe you want to charge on a daily basis, but now every problem gets more complicated.

Then, if you extend that across multiple billing dimensions, it's just gotten harder and more complicated. Now it's rock and a hard place time - you can stick to one abstract usage measure that is easy to reason about, but you're inevitably going to have some users that underpay based on that usage measure and some that overpay. Or you can add more dimensions and make things more "fair", but everybody's lives are harder, both for the customer and for you and your team.

When you give customers automatic optimization, you get the worst of both worlds - you make less money on the bottom 10% (usage-wise) of users/customers because they end up falling into the usage based billing, and you make less money on the top 10% because there is capped upside for you as the provider. For customers, sure, it saves them money, but what you're really giving them is a price cap (not to exceed X).

I would say for the sales teams, it's also not great, because they have all of the challenges of explaining two different models. For enterprises, it's a mess because 1) they'll probably want to negotiate specific billing terms for their use cases (we don't want to pay X for bandwidth, we want to pay Y) and other structural terms, all of which your billing system needs to support.

At the end of the day, however you charge for anything is an abstraction layer on top of your costs. That's true if you charge per user, or per object, or per gig, or per connection, or whatever else. It's all unit-based pricing even if it's not usage-based procing. You have to decide how much work you want your engineers, customers, salespeople, etc. to do in order to build, explain, and understand how much someone will pay for software.

My general advice is to pick the simplest pricing model that protects your margins and prevents abuse. For infrastructure-y products, things like storage, compute, network, are all reasonable meters. For SaaS products for business users, per-user pricing is well-understood, and there are things you can do if you really want to apply a usage-based element there (bill based on MAU, or have a MAU component separate from seats purchased). But there's really only two scenarios - you pick a small number of meters and understand that some customers will subsidize other customers, or you meter across a bunch of dimensions that align to your costs and create a lot of complexity for your customers. Blending the two gives you worse margins and the complexity of both options combined.

Unfortunately, there's no such thing as a free lunch - you can have simple and predictable but you will have some users that you pay for that aren't getting value. You can have usage-based billing, but then you run the risk that anyone who uses an antipattern for the product will suddenly cost you a ton (or consume all of their allocated quota and be dead in the water, which is differently bad).

The more flexibility you offer, the more complexity you're putting onto customers and sales teams to understand what's the best way for them to consume the software.

There's also a lot of market pressure to "follow the crowd" - even if you have an option that is (in your mind) more customer friendly/favorable, if you are structuring your pricing differently than the competition, there will be customers who are concerned that they're not getting "a good deal" or concerned that the structure will end up being less favorable to them over time (after all, why does everybody ELSE do it this other way?). Sales reps also prefer pricing strategies that are at least structurally consistent with other products on the market, because it makes their lives easier.

Similarly, it's very difficult to change pricing nad packaging later on - changing price is relatively simple, but changing units of billing or retiring an old offering can be an extremely difficult task.

(disclaimer: these are just my own opinions, everything is hard)