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.

[flagged]

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

Sounds like a skill issue

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

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

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