I do agree with you put I would push a little further - is it that complexity itself is the enemy? Or is it that the secondary outcomes of complexity (bugs, more effort to make changes, confusing code) are the enemy? If it is the secondary outcomes that are the enemy, and AI actually effectively allows you to mitigate those outcomes (debatable! I debate this with myself all the time!), then maybe we should embrace the complexity (or the agent should on our behalf)
> I do agree with you put I would push a little further - is it that complexity itself is the enemy? Or is it that the secondary outcomes of complexity (bugs, more effort to make changes, confusing code) are the enemy?
I agree, but I think we're still a long way away from being able to trust AI to manage all software complexity for us. For one, LLMs frequently get tripped up by their own complexity. But even if the complexity didn't make LLMs more error prone or expensive to run, you still often need a human in the loop to understand what the system does.
I think of it kind of like compilers. Compilers do a good enough job that 99% of developers don't understand code at the bytecode or machine instruction level, but if we lost that last 1% of programmers who understand CPU instructions, we'd be in serious trouble.
Prefilling any model with the first 1% of reasoning tokens from another model should always move the output towards the output of the other model directionally - that's just next token prediction doing its thing.
But of course your brain can process each ear separately. You have a holistic conscious experience, but that is like a hallucination constructed by your brain for your own benefit.
The raw signals are indeed "in stereo"
Even if you could do attribution correctly (I think you can do this partially if you are really diligent about A/B testing), that is still only one input to the equation. The other fact worth considering is the scale factor - if a team develops a widget which has some ARR value today, that same widget has a future ARR value that scales with more product adoption - no additional capital required to capture more marginal value. How do you quantify this? Because it is hard and recursive (knowing how valuable a feature will be in the future means knowing how many users you have in the future which depends on how valuable your features are as well as 100 other factors), we just factor this out and don't attempt to quantify things in dollars and euros.
> Also, if you don't like the NASDAQ 100 rules, then you don't have to invest in securities that track it.
Isn't the idea with the indexes that they allow you to intentionally not take an activist position in the market? The exposure is not tied to any underlying market hypothesis. In other words, if we make people form a market hypothesis in order to decide whether or not to hold this index, it has failed in its purpose.
This is not true. The IETF draft is explicit that E2EE means that the message cannot be read by any party other than the sender and the intended receiver. When companies like Meta claim they support E2EE, this is what they claim. There are no tricky semantics or legalese at play here.
Speaking of Zoom and encryption, its crazy that they bought Keybase (I think they basically said it was largely an acquihire) years ago, and have neither shut it down as everyone thought, nor materially changed it in any way. Unless they changed something it even gives 200GB cloud storage (KBFS) iirc.
It's not entirely accurate to say "any party other than the sender and the intended receiver," since the messaging app running on the user's device can read the messages. Something like "any third party (other than the app vendor)" would be more accurate. Without actually analyze app behavior, it comes down to trusting that the vendor doesn't do anything nefarious.
One could imagine a design where even the app vendor is untrusted... You would send an encrypted chunk direct to the GPU, which would then decrypt and render the message text in some secure environment onto the screen.
Neither the OS nor the application would know the contents of your message beyond "it's 500x700 pixels".
Similar things are done for DRM video, and widevine level 1 or 2 haven't seen many breaches despite running on a wide array of hardware open to physical attack.
In the messaging game, there is every incentive to be seen as the secure-est one.
If you can have an e2e chat between two iphones locked in a big glass box with a sign that says "Anyone who can hack into this conversation gets $100M", that's a really good marketing campaign.
If you can make the app use secure enclaves or whatever to take the ~100k people who write the source code of the libraries, app and OS out of the attack surface, that $100M becomes much safer.
As far as I remember, Google does the final signing of the APK, which is eventually the signature verified by the OS to verify if an update is valid or not.
So Google can, if ordered or willing to help, create a new release track (e.g. experimental-do-not-deleted) and add specific e-mails to that track with the "improved" version.
Nobody would be able to see that in real world, and you know what, if WhatsApp themselves are ordered, they can also create their own "test" track, it's just less covert but it would technically be working.
In all cases, Google and Apple have to respect US laws, and the laws of earning money too.
If you do not cooperative with intelligence / police services of your country, only bad things can happen.
Yes, the app could be compromised, or the OS, or the compiler of the app, or of the OS, or the OS of the compiler, or the CPU any of these things run on, etc. etc. None of that is relevant to the definition of E2EE.
It's relevant to how E2EE is described to users. Representing that it's not possible for anyone other than the sender or recipient to read messages is misleading and just incorrect in general.
A particularly relevant point is when it comes to government interception. E.g. it would be perfectly possible for an messaging app to have a "wiretap mode" that the vendor enables for users that are the subject of a relevant warrant.
> When companies like Meta claim they support E2EE, this is what they claim.
Well, that statement can only resolve to true.
These requests of data collection are perfectly legal.
FBI DITU gives an order: give me all chats from *@banana.com and they receive banana.com.
From there, two choices from the perspective of a tech provider:
a) You accept. You get paid.
You can always claim you had been coerced / are a victim, and that everything has been done by the law.
b) You refuse. It's a crime.
You take the risk to lose over 250K per day (!) in fines, some other court scandals that will come to you, some shady private stuff (what if we learn about your secret jacuzzi ?), harassement of the team, be publicly shamed that you supported terrorists who caused actual death of Americans, etc.
In addition, nobody will know that you are the privacy hero and you are not even sure that the data is not exfiltrated another way.
To this day, Apple, Facebook, Google still deny participating in illegal requests. They claim these were lawful requests, that have been carefully looked one-by-one.
Yes, we looked carefully and decided we won't enjoy losing 100M USD and go to jail.
The trick is that the identifier / wildcard can be very vague and wide. Or there can be multiple of them, each of them are narrow, but put one of top of the other they are super wide.
Hiring is still a pretty non-uniform thing despite attempts to make it less so - I'm sure there are some teams and orgs at all these large companies that do it well, and some that do it les well. I think it is pretty well accepted that university brand is not a good signal, but it is an easy signal and if the folks in the hiring process are a bit lazy and pressed for time, a bit overwhelmed by the number of inbound candidates, or don't really know how to evaluate for the role competencies, I think it's a tool that is still reached for today.
In a way, I think the hiring process at second-tier (not FAANG) companies is actually better because you have to "moneyball" a little bit - you know that you're going to lose the most-credentialed people to other companies that can beat you dollar for dollar, so you actually have to think a little more deeply about what a role really needs to find the right person.
> This is partly a tooling problem. Many of the tools we use do not do a good job of capturing and representing this data. For example, the majority of latency graphs produced by Grafana, such as the one below, are basically worthless. We like to look at pretty charts, and by plotting what’s convenient we get a nice colorful graph which is quite readable. Only looking at the 95th percentile is what you do when you want to hide all the bad stuff. As Gil describes, it’s a “marketing system.” Whether it’s the CTO, potential customers, or engineers—someone’s getting duped. Furthermore, averaging percentiles is mathematically absurd. To conserve space, we often keep the summaries and throw away the data, but the “average of the 95th percentile” is a meaningless statement. You cannot average percentiles, yet note the labels in most of your Grafana charts. Unfortunately, it only gets worse from here.
I think this is getting a bit carried away. I don't have any argument against the observation that that average of a p95 is not something that mathematically makes sense, but if you actually understand what it is, it is absolutely still meaningful. With time series data, there is always some time denominator, so it really means (say) "the p95 per minute averaged over the last hour", which is or can be meaningful (and useful at a glance).
Also, the claim that "[o]nly looking at the 95th percentile is what you do when you want to hide all the bad stuff" is very context dependent. As long as you understand what it actually means, I don't see the harm in it. The author makes this point that, because a load of a single webpage will result in 40 requests or so, you are much more likely to hit a p99 and so you should really care about p99 and up - more power to you, if that's the contextually appropriate, then that is absolutely right, but that really only applies to a webserver serving webpage assets which is only one kind of software that you might be writing. I think it is definitely important to know, for one given "eyeball" waiting on your service to respond, what the actual flow is - whether it's just one request, or multiple concurrent requests, or some kind of dependency graph of calls to your service all needed in sequence - but I don't really think that challenges the commonsense notion of latency, does it?
Nearly all time series databases store single value aggregations (think p95) over a time period. A select few store actual serialized distributions (Atlas from Netflix, Apica IronDB, some bespoke implementations).
Latency tooling is sorely overlooked mostly because the good tooling is complex, and requires corresponding visualization tooling. Most of the vendors have some implementation of heat map or histogram visualization but either the math is wrong or the UI can’t handle a non trivial volume of samples. Unfortunately it’s been a race to the bottom for latency measurement tooling, with the users losing.
I take it as a given that what is stored and graphed is an information-destroying aggregate, but I think that aggregate is actually still useful + meaningful
They care very deeply about this and devoted a lot of resources to (re)grading the digital versions that you see today on Disney+. The versions you see are intentional and not the result of cost cutting. (I was not directly privy to this work but I worked on Disney+ before its launch and I sat in on some tech talks and other internal information about the digital workflows that led to the final result on the small screen and there was a lot of attention on this at the time)
I think there's a discussion to be had about art, perception and devotion to the "original" or "authentic" version of something that can't be resolved completely but what I don't think is correct is the perception that this was overlooked or a mistake.
reply