spectraldrift
Joined 1 year ago
Karma
546
Submissions
61
Member since
Feb 5
Recent submissions
Comment · 13 days ago
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.
Comment · 21 days ago
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.
Comment · 1 month ago
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.
Comment · 1 month ago
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.
Comment · 2 months ago
Good reminder! I use the non-poisonous kind, phenol-free.
Comment · 3 months ago
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.
Comment · 4 months ago
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!)