Interesting anecdote on Plenty of Fish. It’s definitely interesting how people aren’t really good at telling you what they like; empirical evidence is far better. I believe Paul Graham has an essay on a similar topic where if you ask people if they like an idea you have for a product, they are likely to say yes even if they wouldn’t actually use it. But if you ask them how much they would pay for access, or if they’d pay a certain amount, you’d get a more accurate response.

FWIW, I wasn’t suggesting pure randomness though, it’s more like probabilistic randomness. Rather than a binary threshold a post must pass to make the homepage that divides the community into curators and consumers, this would show you posts with a degree of randomness with a probability proportional to the likes it’s garnered.

Btw, I’m not sure what you meant by randomness is an underdog? Are you implying it’s a nice goal but it rarely works out in practice, perhaps because people actually do fall into natural curator / consumer buckets?

Oof, this comes at a hard moment in my Claude Code usage. I'm trying to have it help me debug some Elastic issues on Security Onion but after a few minutes it spits out a zillion lines of obfuscated JS and says:

  Error: kill EPERM
      at process.kill (node:internal/process/per_thread:226:13)
      at Ba2 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19791)
      at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19664
      at Array.forEach (<anonymous>)
      at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19635
      at Array.forEach (<anonymous>)
      at Aa2 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19607)
      at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19538
      at ChildProcess.W (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:20023)
      at ChildProcess.emit (node:events:519:28) {
    errno: -1,
    code: 'EPERM',
    syscall: 'kill'
  }

I'm guessing one of the scripts it runs kills Node.js processes, and that inadvertantly kills Claude as well. Or maybe it feels bad that it can't solve my problem and commits suicide.

In any case, I wish it would stay alive and help me lol.

I've been very reluctant to enter any queries into any LLM that might let on more than I'm willing to make public. I think about the people who poured their romantic energy into LLMs - beyond how dystopian that is on its face, the LLM vendors now have the ability to ad-target that person to within an inch of their life, and every incentive to exploit this to the max they can.

I've always thought that a problem with sites like Reddit and Hacker News is that a very small percentage of users engage with "new"; most people only see the posts that have been curated by that small minority which creates _some_ sort of bias (arguably, a positive one).

I've wanted to try something like a Hacker News where your homepage shows a random smattering of posts where the probability you'll see any particular one depends on its number of likes.

In other words, rather than having a firehose of "new" posts from which a few are elevated to the home page (masses), give everyone a dynamic home page which is mostly items that have been liked by many, but includes a mix of some that haven't made that threshold yet. Maybe instead of pure likes it could be a ratio of likes to views.

But the point is some way to engage everyone in the selection of what makes the homepage. It could even be as simple as "keep HN as is, but include 5 posts randomly chosen from recent submissions and tag them as such."

Dang, has anything like this been considered?

I spent the past month "de-Googling" my life after I saw a notice in my Gmail inbox that it was 20 years old. I took a step back and realized just how invested into the Google ecosystem I was. Gmail, Calendar, Docs, Drive, Maps, Keep, Photos, YouTube, FitBit, Android. Basically my entire digital life. My goal was more diversifying than security/privacy, but security/privacy is a really nice bonus.

I ended up going with Proton because they had a good solution for mail, calendar, and drive which I was looking to replace. I set up my custom domain to point to it and have my Gmail forwarding to it - any time I get an email to the old Gmail address I go change it on the website or delete the account altogether.

For Google Docs / Keep, I switched over to Obsidian and pay for the sync there. It's a great replacement for my main use case of Docs / Keep which is just a dumping ground for ideas.

For Google Photos, I now self-host Immich in Hetzner on a VPS with a 1TB storage box mounted via SSHFS. I use Tailscale to connect to it. It took a few days to use Google Takeout + immich-go to upload all the photos (~300GB of data) but it's working really well now. Only costs $10/mo for the VPS and 1TB of storage.

Android I think I'll be stuck on - I have a Pixel 8 Pro that technically supports Graphene but there are too many trade-offs there. Next time I need a new phone I'll take a serious look at Fairphone but I think the Pixel 8 Pro should last a few more years.

My FitBit Versa is really old and starting to die - I ordered one of the new Pebble watches and am patiently waiting for it to ship!

YouTube I'm stuck on because that's where the content is. I have yet to find a suitable replacement for Google Maps - OpenStreetMap is still really hard to use and gives bad directions.

What makes you think ads and the equivalent to SEO aren't coming for the LLM products? These companies are going to have to turn a profit eventually...

Anyone who regularly uses LLMs to produce code knows that vibe coding anything larger than a to-do app is not currently realistic.

Once your codebase reaches the size needed to solve actual business problems, the quality of the output varies wildly, the complexity of the prompts required to produce useful code increases, and the output code requires significant editing to actually integrate without bugs or errors.

My personal opinion is that for vibe coding to be viable as the complexity of feature requirements or the size of the code base increase, the specificity and complexity of the input prompt will eventually demand more from the engineer than just writing the code, since code is more specific by definition than natural language.