singron

If your working set is 20 TB, then it's pretty big. Each database has its own mix of hot/cold data, so it's impossible to compare without more information. A better measure might be IOPS. RDS has fairly low maximum IOPS unless you spend a lot more for provisioned IOPS or use Aurora.

I have mysteriously lost comments/descriptions I wrote on issues. I figured it was related to a failed and lost opportunistic update like this, although I suppose it could have been caused by a fixable bug.

I'm not sure this is true for Google. Ignoring their equity in Anthropic, AI is generally a threat to Google, since it's the closest thing to upsetting their search monopoly. The best case for Google is if OpenAI and Anthropic are way out over their skis, and Google is the only major player left with their sturdier financial position. The worst case is if ChatGPT/Claude completely displace search and nobody wants to pay for gemini. I find it unlikely that all three go down for the same reason.

It's circular since Google owns part of SpaceX. According to [1] they own 7% of SpaceX, so a $1.75T IPO would value their stake at $120B. The target IPO price is >90x revenue, so if Google increases SpaceX's revenue by $11B, SpaceX's valuation could increase by $990B to maintain the same multiple, which would increase the value of Google's stake by $69B.

1: https://finance.yahoo.com/markets/stocks/articles/alphabet-s...

I haven't worked there in several years, but assuming memegen hasn't wildly changed: Management likes having a pulse on employees, and they tolerate memegen since it's mostly fun, it builds shared culture in a massive company, lets workers (mostly) harmlessly blow off steam, and it would be massively unpopular to shut it down. Management does not like that memegen is often a nexus of cynicism and employee activism. Also in my experience, most employees were nearly completely agnostic or ignorant about whatever trend was on memegen, so it wasn't necessarily representative.

After 5 years, you'll have an extra $1M in savings, and you can safely pay yourself 4% or $40k each year in perpetuity without doing any work.

This is also a really extreme version of the prisoners dilemma. In the standard formula, there are 2 prisoners, so it's somewhat practical to not defect, but there are hundreds of thousands of qualified candidates for working at Meta in these roles, so your personal decision to defect or not has likely no effect on the ultimate outcome. I.e. for the second option to work, you actually need to organize a unified labor movement with no defectors, which is probably impossible.

These guard types are great and I've heavily used them in the past. But why codegen them?

E.g. the jwt auth example has some major problems since the verification rules aren't fully specified in the spec. The jwt-token verified rule only checks that the string isn't empty, but it doesn't actually verify that it is correctly parsed, non-expired, and signed by a trusted key. The authenticated-user rule doesn't check that the user-id actually came from the jwt. If you hand-wrote your constructor, you would ensure these things. Similarly, all the other constructors allow passing in whatever values you like instead of checking the connections of the real objects.

By calling the constructor for these types, you are making an assertion about the relationship of the parameter values. If AI is calling the constructor, then it's able to make it's own assertions and derive whatever result it wants. That seems backwards. AI should use the result of tenant-access to deduce that a user is a member of tenant, but if they can directly call `(tenant-access user-id tenant-id true)`, then they can "prove" tenant-access for anything. In the past, we have named the constructors for these types `TenantAccess.newUnverified`, and then heavily scrutinized all callers (typically just jwt-parsers and specific database lookups). You can then use `TenantAccess.{userId,tenantId}` without scrutiny elsewhere.

Specifically it decrements the TTL of routed packets, so hotspot traffic will tend to have a TTL of 63 instead of 64. You could theoretically disable this at the risk of creating infinite routing loops, although android probably makes it inaccessible if the kernel has a setting for it at all, so you might have to rewrite packets in user space.

Yes. The original Dapper used 64 bit trace ids and collisions were rarely a problem.

If you don't drop any spans from a trace, you can completely disambiguate a collision since the trace will have two distinct root spans. If you are missing spans, you might have a break in the parent-child links.

Even with infinite retention, your analysis will bucket by time somehow, so a collision might have no effect if the collision doesn't happen at a proximate time. If you are manually looking at traces, it will be very obvious there is a collision unless they happen at the same time.

Also, birthday paradox only expresses probability that there is a collision somewhere, but if you are filtering or looking at single spans, then the probabiliy that you actually see a collision is greatly reduced.

I think for basically all systems, an additional 64-bits has insignificant additional cost, so you may as well prevent collisions, but I think it could be a reasonable tradeoff if it mattered.

I thought it was clear and am also surprised by the reaction (en-US speaker). "Is/are expected" is generally used as a passive-voiced form of "we/they predict" (obviously without having to specify a specific pronoun). E.g. "It's expected to rain tomorrow" means a weather forecast says it will rain tomorrow and usually not that people want it to rain tomorrow.

I wonder if this phrase has different connotations among other English readers? A lot of these comments are fairly early for US timezones.

A specific process can use mlockall to keep all its mapped memory resident and prevent swapping or page cache eviction. That's what earlyoom does so that it can stay responsive when memory gets low. It's unfortunately underutilized in other infrastructure. It's also all-or-nothing: everything stays resident until it's munlocked regardless of how frequently it's used.

I had hoped that something like Linux Pressure Stall Information (PSI) would become more useful for low-memory scenarios. E.g. you could put critical processes in a cgroup that could rate-limit swap-outs/evictions so that it was always responsive. There are some cgroup knobs that affect reclamation, but you need a really good guess about how much memory something needs, which makes it hard to use.

https://docs.kernel.org/accounting/psi.html

This has the wrong explanation of the proposed rseq (Restartable Sequences) solution.

> a Linux kernel facility that lets userspace code detect whether it was preempted or migrated during a critical section and restart it if so. PostgreSQL's spinlock paths would use rseq to detect preemption and retry, avoiding the scenario where a preempted lock holder stalls all waiting backends.

The real proposal is about time-slice extension, which is a feature that uses the abi for rseq but otherwise has nothing to do with retrying critical sections. While a process holds a s_lock, it would set a request bit. If the kernel tries to preempt that thread while the request bit is set, it instead extends the time slice once and returns control back to the thread. It's further explained here: https://docs.kernel.org/userspace-api/rseq.html

If a waymo costs $200k (car+sensors+install labor) and drives 200k miles, then amortizing up-front costs alone are about $1/mile. We don't really know what the TCO of a waymo is, and it's possible it could go down with economies of scale. Rideshare drivers can get paid $1-2/mile although it varies a lot.

I'm a big believer in this workflow and generally agree with all the guidelines about when to do and not do this.

Code review has value, but I don't think we are always honest about the costs. At most places I've worked, there has been an informal understanding that code should be reviewed within 24 hours or so, but there is a world of difference between getting a review within 2 hours and 23 hours.

If you have to go back and forth a second time, it's so much more likely that the approval comes much later due to straddling end-of-day in someone's timezone.

Tangentially, if you are designing policies for code review at your org, try to think both about minimum requirements (e.g. PRs should get a first look within 24 hours) and typical requirements (e.g. most PRs should get reviewed within 2-3 hours). What typically happens is what determines overall velocity for your org, so it's much more important than whatever strict SLA policy you have. These are also fixable problems if you have targeted conversations with people. E.g. "I noticed X, Y, Z times, you had unreviewed PRs at the end of the day. Can you set aside some time to review code before EOD? Or try installing PR reminder?"

For Americans, 120 kph is ~75mph and 140kph is ~85mph. I think there is a single road in the US with an 85 speed limit, and only some states use 75-80.

I have noticed LLMs have a propensity to create full single page web applications instead of simpler programs that just print results to the terminal.

I've also struggled with getting LLMs to keep spec.md files succinct. They seem incapable of simplifing documents while doing another task (e.g. "update this doc with xyz and simply the surrounding content") and really need to be specifically tasked at simplifying/summarizing. If you want something human readable, you probably just need to write it yourself. Editing LLM output is so painful, and it also helps to keep yourself in the loop if you actually write and understand something.

If you need to type in a password to unlock your keychain (e.g. default behavior for gpg-agent), then signing commits one at a time constantly is annoying.

Does "own" try to sign working copy snapshot commits too? That would greatly increase the number and frequency of signatures.

ZFS has similar configurations possible (e.g. copies).

You can end up in this state with btrfs if you start with a single device (defaults to data=single,metadata=dup), and then add additional devices without changing the data/metadata profiles. Or you can choose this config explicitly.

I really wish the btrfs-progs had a --this-config-is-bad-but-continue-anyway flag since there are so many bad configurations possible (raid5/raid6, raid0/single/dup). The rescue tools are also bad and are about as likely to make the problem worse as fix it.

Yes it's not UB, but the consequences are not limited to a EINVAL/EBADF/EBADFD. Calling close twice is essentially the same problem as calling free twice, so you get all the use-after-free problems on your file descriptors.

Epic's 2019 P&L was published as part of Epic v. Apple. According to that:

* Fortnight revenue was $5.5B in 2018 and $3.8B in 2019

* Employee counts in those years: 1063 and 1932

* Average "People" cost per employee: $141K, $142K (CPI adjusted is $182K in 2026).

* Average "Production & Hosting" cost per employee: $189K, $150K (CPI $248K, $194K)

* Platform royalty expenses were 25% of total game revenue

* Slightly under half their Operating Expenses were people

* Fortnight was >90% of revenue

I have a strong guess that "People" costs doesn't include all salaries, and that many employees are categorized under "Production & Hosting", although I expect that also includes other costs. I'll guess 75% is people, which makes total CPI adjusted average cost per employee somewhere around $320K-$370K, but I'll say $320K.

This means 5000 employees cost around $1.6B and cutting 1000 saved around $320M/year in addition to $500M of other costs.

Most estimates of Fortnight revenue claim it's roughly flat or falling between 2020 and 2025 fluctuating between $3B and $6B.

Unless Unreal Engine or EGS revenue took off, it's kind of weird to quadruple headcount while keeping revenue basically flat or falling. If fortnight only makes $2B next year, then they would be underwater on just royalties and salaries.

https://s3.documentcloud.org/documents/20696836/epic-apple-t...

FYI 11M IOPS in terms of AWS EBS is 138 gp3 volumes (80K IOPS each), which costs about $56K/month or about $1.3M over 2 years. If anyone was considering using EBS for high-IOPS workloads, don't.

I think your test had 10 980 Pros, which were probably around $120 each at the time (~$1200 total). SSDs are wildly more expensive now, but even if you spend $500 each, it's nowhere close to EBS.

It's apples vs oranges, but sometimes you just want fruit.

The default config file explains some common things you might want to do. E.g. left or right side and scaling factor.

I used to work at Clockwise and am (was?) a common shareholder. I'm happy that many employees got to get a job at Salesforce. I'm sure it was tough to swallow some pride and recommend Reclaim, who was our strongest competitor in the space (or at least the one we talked about the most). Reclaim was acquired by Dropbox a while ago, although Dropbox wanted them to continue to run and develop the product there.

I also applaud them for not selling the data (as promised in the ToS). There was always a strong commitment to that from day 1, but I'm glad to see that wasn't an option when times got harder. Calendar data sometimes has really sensitive stuff in it, and it would have been a massive betrayal to do anything but delete it after a shutdown.

If you are interested in a more detailed piece about a company struggling in this space, I recommend Rise's shutdown announcement last year. We read this at Clockwise and unfortunately felt it in our bones. There is an ironic Clockwise callout in the piece if you can spot it.

https://www.risecalendar.com/blog/sunsetting-rise

I'm obviously not part of the decision, but I'm sorry the shutoff for users is so soon. Also, please don't revoke your Clockwise app authorization before the shutoff, since that will prevent Clockwise from cleaning up your calendar. If you want to cleanly turn off Clockwise before the shutoff, you can go through the normal deactivation process at https://www.getclockwise.com/uninstall.

It's a huge bummer for me too to have worked on something for years and then to have it suddenly vanish one day.

If you are looking to start a new company in this space, I'll gladly offer my services to talk you out of it. If any die-hard users want to make a self-hosted tool, I'm happy to give some tips from my experience. I know at least one large company has an internal tool like Clockwise's autopilot/flexible meetings.

You only pay cap gains if you realize gains, so you would only face a huge tax bill if you had a pile of cash dumped on you. E.g if you inherit a $1M house and sell it, and the IRS thinks you own 20% taxes on $900,000 of gains, then you have $1M of cash on hand to pay $180K in taxes.

(Also, if you live in the house for 2 years and then sell it, you can exclude $250K-$500K in gains, but that has nothing to do with inheritance).

Deferring taxes is essentially an interest-free loan from the government to you. You can take that money, invest it, and then keep most of the earnings when you eventually pay the taxes.

There are also some loopholes where capital gains taxes deferred until after death just don't get paid at all. This is the "step-up basis" where your inheritors get to reset the basis of capital assets and neither you nor they has to pay taxes on the capital gain.

If you like OpenTTD, you may want to try OpenTTD-JGRPP (JGRennison's Patch Pack). It has a bunch of additional QoL improvements and additional features. It was never distributed on Steam, so nothing has changed there.

https://github.com/JGRennison/OpenTTD-patches

In the CA bill, "User" means child. It's pretty clear that non-human users aren't covered and don't have to participate. E.g. the API can return N/A or any other value for non-humans. If there is a way to make the API applicable only to human children users, then it doesn't even need to be callable for other entities. E.g. on android, each app gets its own uid, so the unix user doesn't correspond to a child, so the API will instead (probably) be associated with another entity (e.g. their Google account, an android profile, or an android (non-unix) user)

This is very funny. I can see how this isn't in the training set though.

1. If you wanted it to do something different, you would say "no, do XYZ instead".

2. If you really wanted it to do nothing, you would just not reply at all.

It reminds me of the Shell Game podcast when the agents don't know how to end a conversation and just keep talking to each other.

There is a section comparing flight emissions to US citizen average total emissions. This might make him feel good, but only 30% of an average American's emissions come from transportation and just a sliver from flying, so it's very likely his total emissions are much higher.

It's sort of like the opposite of this idea:

https://en.wikipedia.org/wiki/Roger_Fisher_(academic)#Preven...

> Fisher [...] suggested implanting the nuclear launch codes in a volunteer. If the President of the United States wanted to activate nuclear weapons, he would be required to kill the volunteer to retrieve the codes.

>> [...] The volunteer would carry with him a big, heavy butcher knife as he accompanied the President. If ever the President wanted to fire nuclear weapons, the only way he could do so would be for him first, with his own hands, to kill one human being. [...]

>> When I suggested this to friends in the Pentagon they said, "My God, that's terrible. Having to kill someone would distort the President's judgment. He might never push the button."

> — Roger Fisher, Bulletin of the Atomic Scientists, March 1981[10]