spectraldrift

Apologies! I'll add more words next time. I was actually just getting out of the movie when I saw this and should have taken more time to write a proper comment. Thanks for the reminder.

This is great! I recently started working on a privacy-first MCP server for proton mail, calendar and drive, written in rust that supports optional pseudonomization of identifiers in the data: https://github.com/matt-w-horn/protonctl

Supports mac and linux, but the linux part could use a bit more work.

I don't think it's a fallacy to say "you're criticizing A, but 100 years ago someone criticized B, and they were wrong", assuming A and B have some related property that we're criticizing, like "A outsources skill X". The real fallacy would be to say "A is fine because B turned out fine."

With every emerging technology or change, let's assume any particular concern about the technology will likely live somewhere on the spectrum from real to unsubstantiated. It seems important to tell the difference, because how will we know where to spend our time, money and effort if we waste it equally on all apparent problems, real or not? So: how do we tell the difference? One way is to look at history, and learn from our mistakes when engaging with new technology. In many cases, real problems emerge which at first might look like tail risks. "Illusory" problems might look real early on, but often have to do with matters of tradition, appearances or status-quo bias.

Let's take an example: the steam engine. How much of the earliest criticism was about the greenhouse gas emissions? Nobody conceived it. And how much of it was about morals, religion, junk science, or protecting incumbents? If we can identify patterns across these, it might make us better at identifying problems in the future, too.

This might just be me, but I find metaphors like ''Fingerprints' inside the Sun' harder to read than the title of the original paper, which is probably what should be linked here per HN submission guidelines:

> Planetary engulfment as a solution to solar-model discrepancies and its implications for planetary systems https://doi.org/10.1093/mnras/stag1527

For the press release, something like The Real Sun and Its Simulations Disagree. A Planet That Fell In Early Might Explain It. might be easier to follow.

Good reminder! I use the non-poisonous kind, phenol-free.

Here's my skill for long-term financial planning (tested only with fable): https://github.com/matt-w-horn/skills/tree/main/skills/finan...

I found it helpful. If anyone wants to fold in the advice from this article, feel free.

Linear seems like the kind of app that typically wouldn't need this sort of optimization. I could understand local copy of the DB for indexing, perhaps, but not for normal transactions. This app seems like an example of an app that would typically scale well on the backend - concurrent writes for a single issue would typically be rare, and if sharding is necessary for large customers it should shard quite well.

What about this requires more than a few ms (at most) on the backend, and how does a local copy make that better? It seems like a local copy would create even more inconsistency (and if it doesn't, the backend should be fast too!)

Why wouldn't this be priced in already? I am often skeptical when people claim to predict the market, given how much can be made by quietly predicting correctly.

Yes a broken clock might be right twice a day, but I also have limited time in my day. I've read enough of his opinions already and would like to make time for some others!

The author lost me when they quoted Thiel.

There's a great documentary from a German public broadcast channel on this topic, including interviews with the scientists and doctors researching the problem, as well as patients affected by these diseases. It seems like a big deal. https://youtu.be/G4d4DuAqXlI (2025, 43 minutes long)

I generally think this is a good article and I agree that measured confidence is important when working on any engineering project. However, I've often seen engineers who are a little too confident and can't admit when they're wrong. I worry articles like this could be misread by those folks and used to justify that behavior.

I've also noticed a pattern in Sean's writing where he redefines common English words to mean something different than the usual definition, potentially for a punchy title (I've seen "taste" and now "ego"). As engineers we often have to find analogous words for ideas that don't have them yet, but in this instance I think the article would be a lot less muddy if he just used "confidence." I appreciate he acknowledges this discrepancy in the comments, but maybe too much ego gets in the way to fix it during editing :)

This is a misleading article including some quotes that wildly mischaracterize the original sources, while also including many lines of unrelated speculation that could be easily researched.

From the article:

> However, Google's privacy policy — a document that users often blindly agree to after purchasing a device — makes it clear that videos can be captured when a device is offline. “That means you may not see a visual indicator when your camera is sending the video footage to our servers," the policy states.

I looked this up because no link was provided [1]. The full quote is "Some models of our cameras support recording of video footage while offline. For these cameras, video footage will be uploaded when the camera goes back online after the video footage has been recorded. That means you may not see a visual indicator when your camera is sending the video footage to our servers. However, in those instances, a visual indicator would have been visible when the camera was actually recording the video footage."

So in this case, the author mangles "offline" (no Internet) with "recording".

Another quote:

> Google didn’t immediately respond to questions from The Associated Press about how the footage of the masked person was captured while the camera was apparently disconnected

The cameras was very clearly disconnected after the footage was recorded, because you can see the suspect begin to disconnect the camera.

There are many other examples of poor reporting in this article but I will leave it to the reader to find them.

[1] https://safety.google/intl/en_ca/products/nest/

Weird how they only share three hand-picked evals, ignoring the evals where they were left in the dust like ARC-AGI2. This post is so misleading, I don't even know whether to trust the numbers they did share. One is just fraction of a percentage point away from Gemini 3 pro, which is awfully convenient for marketing and easy to hide. Very open, OpenAI.

So I'm only 40 years behind! It's amazing how early innovations like this seamlessly fade into the background and can be taken for granted by folks like myself.

Having never heard of mojo before, I found this article fascinating. It provides a great example of how a toy regex parser works and an excellent explanation of why vanilla regex tends to be slow. It also presents a novel solution: compiling the regex into regular code, which can then be optimized by the compiler.

> Should You Use Postgres? Most of the time - yes

This made me wonder about a tangential statistic that would, in all likelihood, be impossible to derive:

If we looked at all database systems running at any given time, what proportion does each technology represent (e.g., Postgres vs. MySQL vs. [your favorite DB])? You could try to measure this in a few ways: bytes written/read, total rows, dollars of revenue served, etc.

It would be very challenging to land on a widely agreeable definition. We'd quickly get into the territory of what counts as a "database" and whether to include file systems, blockchains, or even paper. Still, it makes me wonder. I feel like such a question would be immensely interesting to answer.

Because then we might have a better definition of "most of the time."

This is the second article I've seen on taste here. It seems to me the author's definition of "tinkering" is primarily describing hyperfocused, repetitive behaviors found in neurodivergent individuals, potentially even a complex form of stimming. I think this is unrelated to taste.

I think good taste in engineering comes down to a mix of skill and knowledge. It isn't just about how you can reach a goal, but rather about having a solid internal map of the world and an understanding of which parts of the map you are unfamiliar with. To those lacking knowledge, the map can deceptively appear much smaller. Skill allows you to effectively find your way to the places you know you can go. With knowledge and skill, taste comes naturally. Those with bad taste, I've found, are those with limited knowledge of the vast universe of tools available and/or the lack of skill needed to utilize those tools effectively.

This sounds incredibly frustrating. But given you're in the leadership seat, it's worth taking a hard look at yourself asking how you're playing a role in this, especially since it's unlikely people are this difficult for no reason. I am rather a bit skeptical of this account as written.

One hint: he was told he was meant to be the lead. That's a bit of a shitty promise to be given and taken away.

This guy is almost certainly operating from a place of "status injury." He sees you as the person who took his job.

So, some hard questions for self-reflection:

Knowing he felt slighted, did you ever try to build an alliance with him and acknowledge his expertise? Or did you just expect him to fall in line?

Are you showing him respect, or just demanding it because of your title?

Are his arguments over "trivial things" really trivial? Or is it his (unproductive) way of trying to assert the technical authority he feels you're ignoring?

Right now, your manager hears a personal problem ("This guy is a jerk to me"). That's why he's giving you the weak "don't let it bother you" response.

Stop making it personal. Use your leadership skills to actually lead this person. Try to fix the relationship. Give him ownership.

If that fails, you can go to your manager with a leadership problem ("I've tried A, B, and C to leverage his skills, but his behavior is still causing X business risk"). That is a problem a manager has to solve.

They already did it with Google's transformer architecture- why not Google's open-source browser framework too? They're pretty much a fork of Google's good-faith open-source efforts at this point.

It seems odd to me that someone would write such a polished and comprehensive article and yet completely misunderstand the definition of the central topic.

It fully depends on whether those rules or laws actually mean anything.

I'm not sure why this post gets boosted every few years- and unfortunately (as many have pointed out) the author demonstrates here that they do not understand distributed system design, nor how to use protocol buffers. I have found them to be one of the most useful tools in modern software development when used correctly. Not only are they much faster than JSON, they prevent the inevitable redefinition of nearly identical code across a large number of repos (which is what i've seen in 95% of corporate codebases that eschew tooling such as this). Sure, there are alternatives to protocol buffers, but I have not seen them gain widespread adoption yet.

You're confusing surface area with surface area to volume ratio.

Furthermore the fact that dams increase evaporation though this mechanism is an easily verifiable scientific fact. https://riverresourcehub.org/resources/how-dams-affect-water...

I had the same initial thought as well, but I realized this caveat would only be true if dams just made rivers deeper. But dams flood valleys and they make the water body much wider, not just deeper. A river that was 300 feet wide becomes a lake that’s miles wide. The width increase (10-100x) completely overwhelms the depth increase (maybe 3-10x), so surface area increases substantially.

Given that Earth averages towards smooth, the rate of width increase overwhelms the rate of depth increase when dams fill.

The only exceptions might be narrow canyon dams with nowhere to spread laterally, or dams on already-wide rivers. But those are rare.

It's wild how quickly this rumor spread across major news sources, and yet I was unable to find a primary source at all. I wonder how this started.

I assumed they were already doing this domestically.

You make a good point about experience. I've noticed an interesting paradox there.

The engineers who most aggressively advocate for bespoke solutions in the name of "simplicity" often have the least experience with their managed equivalents, which can lead to the regrets you mentioned. Conversely, many engineers who only know how to use managed services would struggle to build the simple, self-contained solution the author describes. True judgment requires experience with both worlds.

This is also why I think asking "do we actually need this scale?" is often the wrong question; it requires predicting the future. Since most solutions work at a small scale, a better framework for making a trade-off is:

* Scalability: Will this work at a higher scale if we need it to?

* Operations: What is the on-call and maintenance load?

* Implementation: How much new code and configuration is needed?

For these questions, managed services frequently have a clear advantage. The main caveat is cost-at-scale, but that’s a moot point in the context of the article's argument.

I agree with your sentiment, but what you're referring to is "I'm not good at this task yet" which is different from "I am inherently incapable/inferior". The first can motivate, the second does not- this is supported by a large body of pedagogical research.

https://opentext.wsu.edu/theoreticalmodelsforteachingandrese...

I agree with the spirit of the article, but I think the definition of "simple" has been inverted by modern cloud infrastructure. The examples create a false choice between a "simple but unscalable" system and a "complex but scalable" one. That is rarely the trade-off today.

The in-memory rate-limiting example is a perfect case study. An in-memory solution is only simple for a single server. The moment you scale to two, the logic breaks and your effective rate limit becomes N × limit. You've accidentally created a distributed state problem, which is a much harder issue to solve. That isn't simple.

Compare that to using a managed service like DynamoDB or ElastiCache. It provides a single source of truth that works correctly for one node or a thousand. By the author's own definition that "simple systems are stable" and require less ongoing work, the managed service is the fundamentally simpler choice. It eliminates problems like data loss on restart and the need to reason about distributed state.

Perhaps the definition of "the simplest thing" has just evolved. In 2025, it's often not about avoiding external dependencies. You will often save time by leveraging battle-tested managed services that handle complexity and scale on your behalf.