mattzito

No, if you are going to change the structure of a structured document that has been saved to disk, your options are:

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.

I think you have to go market by market to make that statement. In NYC, for example, it was explicitly illegal for yellow cabs to accept radio/pickup calls, which was the domain of the livery cabs (black cars). The tradeoff was that only yellow cabs could do street hails. That worked for everybody for years - yellow cabs did a volume business, livery cabs were for outer boros or luxury/business travel and would sneakily try to pick up street hails.

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.

It was a proper Gmail account? Or was it an email@domain account that maybe was using her work email address?

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.

I am very much not a lawyer, and while I work for Google, I do not work on this, and this is just my plain language reading of the docs.

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.

That's because it's a bit of a nesting doll situation. As you can see here:

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)

It's a lot more nuanced than that. If you use the free edition of Code Assist, your data can be used UNLESS you opt out, which is at the bottom of the support article you link to:

"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.

Because as people start bidding they become invested in the outcome, and can often be convinced to go higher than they otherwise would. The trick is to set it under the minimum price the right amount that you can get multiple people bidding on the same item, each topping the other by smallish amounts. That way it doesn’t “feel” like you’re crossing the right price - “I’m already in for $60m, 1 more million is like 2% more, and then I beat this other person for something valuable”

Are we talking about the same Airbnb? When I think of resorts, I think of staff, bars, restaurants, activities, often all inclusive, and often catered to my desired demographic (adults only, family friendly, etc.)

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.

FWIW, as far as I'm aware, it wasn't gmail scraping that was the cause of Amazon pulling that information. It was third-party plugins that read people's inboxes to provide them with coupons, discounts, etc., and those companies would sometimes sell the pricing data. I assume Amazon wasn't thrilled about that, but there wasn't anything they (or gmail) could do about it as long as the user was granting them access to their inbox.

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).

I didn’t move the goal posts, I was referring to your married couple example. If you are married and you jointly agree to change the standard of living because of your shared goals/values, that’s your business.

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.

It doesn't make sense that married people can willfully lower standard of living but non custodial parents cannot.

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.

Neither of those are enterprise products, though. Looker, as a better comparison, is still available on AWS and Azure.

If you have a few minutes, reading the full complaint is worth it - the blog posts and the articles don't really do the whole story justice.

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.

Well, for options it's more complicated than that - you can have ISOs that convert to NSOs to allow people to defer having to exercise illiquid options when they leave the company. So that's where my options question was coming from - the scenario you describe is VERY common in a scenario where ISOs have converted to NSOs upon leaving the company.

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.

Wait - there’s a lot of assumptions being made in this thread. Is everyone you’re referring to a former employee? Are you sure you had RSUs, proper, as opposed to options?

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?

I think now we're just arguing semantics. The only billing metrics for cell phones that are visible to the user are usage in minutes and data. This is the easiest type of metric to understand and meter - because it's pure aggregation, and you have a fixed window over which you count the number of bytes or minutes consumed. Compare that to technology metrics like storage consumed, query executions, etc. where the variability in units and behaviors can be massive.

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.

Sure, it’s also very easy to understand paying for deli cold cuts by the pound, but it doesn’t make it a good comparison.

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's funny, this was actually one scenario that I thought about mentioning but I had to get on a plane and was running out of time.

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.

I spend a lot of time on pricing and packaging of SaaS software and the challenge is real. Everybody says they want simple pricing, which often aligns to seats or MAU - but then they want usage-based pricing, but then they're concerned about unpredictable costs and spiky usage.

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)

But by their own admission, other than for two states they don’t uniquely count people, it’s counting admissions. That could skew the numbers meaningfully.

As someone who rented for 20 years in NYC, this is a bizarre scenario you describe. You deal with a broker during the leasing process, and then after you lease it, you pay the landlord, they have to sign the lease and approve repairs, and are the person with whom you review lease increases. The most arms length relationship I have ever heard or seen is having an admin assistant for the landlord handle all the operational things.

I have never seen a situation where the broker is responsible for the lease terms, because in the end the landlord has to sign their end.

In NYC, rents went way down, to the point where there was a sticker shock from people who moved to NY during Covid and were shocked when prices went back up a year or two later.

Right, you CAN set that up, but in the US, not accepting visa and Mastercard is essentially untenable if you are a retailer or restaurant. You might be able to avoid accepting AmEx, but from talking with restaurant owners, the biggest spenders are often AmEx holders and are annoyed at having to use a backup card.

It’s not justice towards the employer, but justice towards your peers, both those who you work with directly, as well as those who are negatively impacted because you took a job that could have been someone else’s.

If you want to have multiple jobs at the same time, there is a vehicle available for that, it’s called “consulting”.

I don’t think anyone should have loyalty towards their employer - you should be free to jump ship to a better gig whenever you want, in the same way they are free (in the US) to let you go at their convenience. But taking multiple full time jobs is wrong, imo.

That is inaccurate. You only see individuals with whom you have directly shared the document with and/or people in your domain (if a business/enterprise customer). For anything link shared, you see the anonymous animal names.

How would they be able to link that? Document owners can't see non-domain users who viewed a particular document (and even for domain users, that can be disabled).

There are lots of family owned businesses in the US that look after their employees. I think it’s more that there are significantly fewer tech companies in general that are family owned businesses.

This is inaccurate-

- charcoal - no roofs or balconies, but terraces and backyards are okay. You do need 10 feet of clearance from walls and fences, but this is less rare than you might think. I’ve lived in two places that met this criteria and have a few friends that did as well

- propane - illegal in most circumstances except with a very small propane tank

- natural gas - legal in all circumstances as long as installed by a city licensed installer.

It’s true that it’s not as common as it is in the suburbs, but essentially every building built in the last 20 years or major renovations ends up including one or more grills.

As a college non-graduate, I think that is leveraging the strong data that for most people a college degree is a huge net benefit is reasonable.

As someone who was once <25, I think that version of me is stupid in a wide variety of ways. I hear you that it can be negative to divide things that way, but it seems reasonable to say “after you are either a non college graduate with a number of years of experience or a college graduate with ~2 years of post-college experience.

I hear you, though, it’s hard to sort people into buckets.

I was just pointing out that the idea that one could go for “hours” without seeing a car is essentially impossible in Manhattan, even during Covid.