So despite its importance much of it is actually pretty in-distribution.
31,384 karma · joined September 24, 2008
So despite its importance much of it is actually pretty in-distribution.
If I can be a bit bold and observe that this tic is also a very old rhetorical trick you see in our industry. Call it Schrodinger's Modest Proposal if you will.
In it someone writes something provocative, but casts it as both a joke and deadly serious at various points. Depending on how the audience reacts they can then double down on it being all-in-good-jest or yes-absolutely-totally. People who enjoy the author will explain the nonsensical tension as "nuance".
You see it in rationalist writing all the time. It's a tiresome rhetorical "trick" that doesn't fool anyone any more.
First-gen product that seemed to not know where it's going? Check.
Continued quiet iteration behind closed doors despite first-gen being a flop? Check.
Sticking with the product line over many years, where most other companies would have written off and thrown in the towel? Check.
Multi-pronged GTM strategy where other products prove out key bits of next product? Check. (see: SteamOS and Proton setting the stage for Steam Deck, which in turn sets the stage for Steam Machine 2)
Deep software-hardware integration in ways that are highly salient to users? Check (see: foviated streaming for Steam Frame, Steam Deck "just works")
In a vacuum there are potentially some advantages to doing your own silicon, especially if your goal is to sell the platform to other automakers as an OEM.
But custom silicon is pricey as hell (if you're doing anything non-trivial, at least), and the payoffs have a long lead time. For a company that's bleeding cash aggressively, with a short runway, to engage in this seems iffy. This sort of move makes a lot more sense if Rivian was an established maker that's cash-flow positive and is looking to cement their long-term lead with free cash flow. Buuuuut they aren't that.
IMO the right way to do this is to feed the audio into a transcription model, specifically one that supports diarization (separation of multiple speakers). This will give you a high quality raw transcript that is pretty much exactly what was actually said.
It would be rough in places (i.e., Speaker 1, Speaker 2, etc. rather than actual speaker names)
Then you want to post-process with a LLM to re-annotate the transcript and clean it up (e.g., replace "Speaker 1" with "Mayor Bob"), and query against it.
I see another post here complaining that direct-to-LLM beats a transcription model like Whisper - I would challenge that. Any modern ASR model will do a very, very good job with 95%+ accuracy.
So effectively your 1080p monitor has ~6x the pixel density of the VR headset.
This is the main reason many VR games don't let you just walk around and opt for teleportation-based movement systems - your avatar moving while your body doesn't can be quite physically uncomfortable.
There are ways of minimizing this - for example some VR games give you "tunnel vision" by blacking out peripheral vision while the movement is happening. But overall there's a lot of ergo considerations here and no perfect solution. The equivalent for a virtual desktop might be to limit the size of the window while the user is zooming/panning.
I agree with you - I would personally consider 35ppd to be the floor for usability for this purpose. It's good in a pinch (need a nice workstation setup in a hotel room?) but I would not currently consider any extant hardware as full-time replacements for a good monitor.
> "Could you not just move your face closer to the virtual screen to see finer details?"
Sure, but then you have the problem of, say, using an IMAX screen as your computer monitor. The level of head motion required to consume screen content (i.e., a ton of large head movements) would make the device very uncomfortable quite quickly.
The Vision Pro has about ~35ppd and generally people seems to think it hits the bar for monitor replacement. Meta Quest 3 has ~25ppd and generally people seem to think it does not. The Steam Frame is specs-wise much closer to Quest 3 than Vision Pro.
There are some software things you can do to increase legibility of details like text, but ultimately you do need physical pixels.
The depreciation/utility curve has always been aggressive no matter what product you're buying. Is a 2 year-old ICE car twice as bad as a new one? Is a 2 year-old TV? Clearly not, yet they are all worth that in the open market.
For EVs the depreciation curve is especially aggressive because of perceived advancements. Are the advancements worth buying new? I dunno! You tell me - but this is clearly being reflected in the market.
From a strict utilitarian standpoint, optimizing your depreciation/utility function should mean you're buying almost every single thing used. But yet lots of people don't do that. Humans are empirically not very good utilitarians!
Battery capacity, motor efficiency (getting more range out of the same battery), charging rate (800V architectures for example that let you charge > 150kW), battery chemistry (wider operating temp envelope, affects charging and driving efficiency depending on environment)... the list goes on.
The batteries are also getting cheaper - which is to say for the same $ you're now (generally) getting a larger battery.
> "If so, why aren't used dealers just including a battery swap in the price?"
Because the batteries are in fact not swappable from one gen to the next, because the power electronics around them are different, peak current draw is different (and that depends on the motor it's mated with!).
Like I know it's tempting and attractive to imagine EVs like regular cars with some giant-ass AA batteries installed on them, but that's not how they work! The battery is specced as a unit with the entire electrical system and drive motor options!
The last part of OP's statement is the key. In a field that's rapidly advancing technologically, used prices are depressed because the new product is that much better than the used product.
Think back to the early smartphone days - every year phones multiplied in performance, in screen resolution, etc. In that environment a used item is less attractive because you feel like you're missing out on features/capability. This keeps used prices down. Nowadays used smartphones are more competitive because the rate of advancement (that buyers care about at least) has slowed.
For example there's another post later in this thread that points out that the Nissan Leaf has been the same price forever - except the current-gen Leaf has literally double the range of the last one. Effects like this depress used prices.
Firstly, the M5 isn't 4-6x more powerful than M4 - the claim is only for GPU, only for one narrow workload, not overall performance uplift. Overall performance uplift looks like ~20% over M4, and probably +100% over M1 or so.
But there is absolutely a massive sea change in the MacBook since Intel 5 years ago: your peak workloads haven't changed much, but the hardware improvements give you radically different UX.
For one thing, the Intel laptops absolutely burned through the battery. Five years ago the notion of the all-day laptop was a fantasy. Even relatively light users were tethered to chargers most of the day. This is now almost fully a thing of the past. Unless your workloads are very heavy, it is now safe to charge the laptop once a day. I can go many hours in my workday without charging. I can go through a long flight without any battery anxiety. This is a massive change in how people use laptops.
Secondly is heat and comfort. The Intel Macs spun their fans up at even mild workloads, creating noise and heat - they were often very uncomfortably warm. Similar workloads are now completely silent with the device barely getting warmer than ambient temp.
Thirdly is allowing more advanced uses on lower-spec and less expensive machines. For example, the notion of rendering and editing video on a Intel MacBook Air was a total pipe dream. Now a base spec MacBook Air can do... a lot that once forced you into a much higher price point/size/weight.
A lot of these HN conversations feel like sports car fans complaining: "all this R&D and why doesn't my car go 500mph yet?" - there are other dimensions being optimized for!
I feel like that's kind of the other arm of this whole argument: on the one hand, you ain't gonna need that "scalable" thing. On the other hand, the "unscalable" thing scales waaaaaay higher than you are led to believe.
A single primary instance with a few read-only mirrors gets you a reaaaaaaally long way before you have to seriously think about doing something else.
I was but a baby engineer then, and the leads would not countenance anything as pedestrian as MySQL/Postgres.
Anyway, fast forward a bit and we were tasked with building an in-house messaging service. And at that point Mongo's eventual consistency became a roaring problem. Users would get notifications that they had a new message, and then when they tried to read it it was... well... not yet consistent.
We ended up implementing all kinds of ugly UX hacks to work around this, but really we could've run the entire thing off of sqlite on a single box and users would've been able to read messages instantaneously, so...
It definitely reduces the risk of updates, but it absolutely doesn't eliminate it.
The A/B updater itself is a surface area - especially if the logic is complex and there are other child devices that are updated at the same time (likely for cars). In that case you're not just coordinating between two independent partitions, you're coordinating between 2 * N partitions, half of which have dependencies on each other.
Also, the key bit of the mechanism is that upon successful boot the new partition is flagged as "good", which causes flags to be set to assert that the update was successful and the backup partition is no longer needed. That logic can (and does) fail - if your failure point occurs after this checkpoint you're hosed still because you're past the point of no return.
Making that worse is that in most systems you want the "it's all good" checkpoint to occur early - you don't want to, for example, wait multiple minutes for all user services to come up. But that also means that if a critical failure happens in said services, you're past the checkpoint.
You absolutely can quantify the results of a chaotic black box, in the same way you can quantify the bias of a loaded die without examining its molecular structure.
"We should have rigorous evaluations of whether or not [thing] works." seems like an incredibly obvious thought.
But in the realm of LLM-enabled use cases they're also expensive. You'd need to recruit dozens, perhaps even hundreds of developers to do this, with extensive observation and rating of the results.
So rather than actually try to measure the efficacy, we just get blog posts with cherry-picked example of "LLM does something cool". Everything is just anecdata.
This is also the biggest barrier to actual LLM adoption for many, many applications. The gap between "it does something REALLY IMPRESSIVE 40% of the time and shits the bed otherwise" and "production system" is a yawning chasm.
We're adding transistors at ~18%/year. That's waaaaay below the ~41% needed to sustain Moore's law.
Even the "soft" version of Moore's law (a description of silicon performance vs. literally counting transistors) hasn't held up. We are absolutely not doubling performance every 24 months at this point.
So we're seeing this play out. There are two factors that exist in tension here:
- The valuation of many of these companies depend on the perception that they are The Future. Part of that is heavy R&D spending and the reputation that they hire The Best. Even if the company mostly just wants to sit and milk its market position, keeping the stock price afloat requires looking like they're also innovative and forging the future.
- Some companies are embracing the milk-it-for-all-its-worth life stage of their company. You see this in some of the Mag-7 where compensation targets are scaling down, explicit and implicit layoffs, etc. This gear-shifting takes time but IMO is in fact happening.
The tightrope they're all trying to walk is how to do the latter without risking their reputation as the former, because the mythos that they are the engines of future growth is what keeps the stock price ticking.
Arduino has so little presence in production devices and is largely an enthusiast and hobbyist product. To be clear, this is good! Having well-supported high-quality enthusiast products is awesome.
But it just doesn't... seem to overlap with the bulk of Qualcomm's business, which is large-scale silicon sales to consumer and industrial clients.
This general concept (embedding third parties as widgets in a larger product) has been tried many times before. Google themselves have done this - by my count - at least three separate times (Search, Maps, and Assistant).
None have been successful in large part because the third party being integrated benefits only marginally from such an integration. The amount of additional traffic these integrations drive generally isn't seen as being worth the loss of UX control and the intermediation in the customer relationship.
But IMO the industry dogma is to use it for everything, particularly around greenfield development and new product areas that are pre-PMF.
Importantly also is that in many organizations A/B testing has become a crutch to avoid understanding the underlying system being measured.
Conversion rate rises by 5% if the button is green. Why? But rather than using experimentation as a tool for structured understanding many organizations devolve to "just test every change".
The practical outcome is that product teams commit elementary errors because they fail to understand why their products are successful, and product velocity slows as teams prove unable/unwilling to make any decisions without pushing something to prod.
In practice that hasn't borne out. You can download and run open weight models now that are spitting distance to state-of-the-art, and open weight models are at best a few months behind the proprietary stuff.
And even within the realm of proprietary models no player can maintain a lead. Any advances are rapidly matched by the other players.
More likely at some point the AI becomes "good enough"... and every single player will also get a "good enough" AI shortly thereafter. There doesn't seem like there's a scenario where any player can afford to stop setting cash on fire and start making money.
Effectively every single H100 in existence now will be e-waste in 5 years or less. Not exactly railroad infrastructure here, or even dark fiber.
Heck the opposite is true - it's why high inflation is so despised, specifically because prices outrun income growth.
Nearly every single one has quietly crawled their way back into those respective cities. Agglomeration effects baby!
Listen, I am sure there is some level of taxation at which the rich will in fact decamp and go somewhere else, but empirically we are nowhere near it, nor does it appear that any of the mainstream proposals (either for increased high-bracket tax rates or wealth taxes) get anywhere near it.
For example, MA instituted a 4% surtax on all incomes over $1M and... and the population of payers actually increased 25% since instituting it[1].
[1] https://www.wbur.org/news/2025/04/28/massachusetts-millionai...
Workspace accounts come with their own compliance requirements and edge cases that products need to handle, but rather than do that and provide a consistent user experience most product teams don't answer to the relevant PAs and so don't care, and Workspace accounts are a small enough minority of users that nobody has to care.
I've often railed against a particular way of doing product that's really common in our industry, but I suppose it's been a while so I'll do it again:
We have a real problem with metrics-driven product development, where we exclusively care about the 95% use case and actively disdain the 5% use cases.
On paper it makes sense - you direct your energies towards the highest-payback activities. But the problem is that every user falls into some 5% use cases, so a product that is purely made up of 95% use cases ends up becoming a patchwork that is frustrating to every user, somehow.
Rather than "product works great for 95% of users" you get "100% of users cut themselves on some corner of the product".
So in reality the opportunities to really code against a specific piece of hardware are few and far between...
Heck, then you get into multiple operating modes of the same hardware - the Nintendo Switch has a different perf profile if it's docked vs. not.