miguno

You didn’t use ZFS with FreeBSD?

Thank you!

With this argument you could also justify: "That's not a remote access trojan (RAT), that's just how client-server communication is designed to work."

You have to put a manifest there if you want the native messaging to work later.

The point is that Claude Desktop didn't ask the user whether they want native messaging in the first place. Which is strange, given that users experience many "Do you grant permission to do XYZ" prompts when working with Anthropic products in other situations.

Exactly, what the hell. Apart from Google Chrome (and Firefox, which isn't in the list below) I don't even have any of these other browsers installed!

  $ fd claude_browser_extension.json ~/Library
  /Users/miguno/Library/Application Support/BraveSoftware/Brave-Browser/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  /Users/miguno/Library/Application Support/Vivaldi/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  /Users/miguno/Library/Application Support/Arc/User Data/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  /Users/miguno/Library/Application Support/Microsoft Edge/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  /Users/miguno/Library/Application Support/com.operasoftware.Opera/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  /Users/miguno/Library/Application Support/Chromium/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
  /Users/miguno/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json

Claude Desktop repeatedly installed/updated these 7 extensions since the beginning of February on my Apple machine. Every entry in the filtered log below is for all 7 extensions:

    $ grep "Installed native host manifest" ~/Library/Logs/Claude/main.log | sed -e 's/ at \/Users\/.*//' | awk '{ print $1" "$2 }' | sort -n | uniq
    2026-02-04 18:53:21
    2026-02-04 23:33:26
    2026-02-04 23:34:20
    2026-02-04 23:34:27
    2026-03-16 09:29:18
    2026-03-17 11:52:22
    2026-03-18 22:22:22
    2026-03-19 14:49:34
    2026-03-20 09:42:03
    2026-03-20 10:10:39
    2026-04-02 22:50:26
    2026-04-02 22:57:56
    2026-04-10 19:38:38
    2026-04-10 19:40:51
    2026-04-12 18:52:36
    2026-04-12 19:10:04
    2026-04-12 20:07:21
    2026-04-15 12:19:46
    2026-04-15 12:20:16
    2026-04-15 12:29:45
    2026-04-16 22:15:47
    2026-04-16 22:24:19
    2026-04-18 10:58:13
    2026-04-18 15:06:54

As per https://code.claude.com/docs/en/model-config#adaptive-reason...:

Opus 4.7 always uses adaptive reasoning. The fixed thinking budget mode and CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING do not apply to it.

Steam is a wonderful boot loader.

So that's why Counter-Strike pros are nose-to-the-monitor close to their screens.

Example of player Yekindar: https://preview.redd.it/yekindar-xd-v0-zsm7fzd5jd5e1.jpeg?wi...

"I need you to be focused!"

Really sad. I have been a happy nvim-treesitter user for years.

But the maintainer's reaction is understandable. If you happen to read this: thanks so much for the time and work you have put into the project! There are people who really appreciate it.

Thanks for your contributions!

In the latest Stackoverflow survey, it's back at the "top 5 of desired stacks to use for next project" over a decade after its inception !

Oh, where did you find that?

Only info I could find was that Rails is at rank 10 in the Web Frameworks category for Admired vs. Desired in the 2025 survey: https://survey.stackoverflow.co/2025/technology/#2-web-frame....

Yes, been there, forgot that. I have since created a shell helper function that prints a list of "new and cool" CLI tools that I recently added to my dotfiles setup, which helps me committing them to long-term memory.

+1 to XLD. I have been using it for years, it's a wonderful piece of software.

Wonderful and charming. Thanks for sharing the game and the link to the engine!

I have been noticing this trend increasingly myself. It's getting more and more difficult to use tools like Google search to find relevant content.

Many of my searches nowadays include suffixes like "site:reddit.com" (or similar havens of, hopefully, still mostly human-generated content) to produce reasonably useful results. There's so much spam pollution by sites like Medium.com that it's disheartening. It feels as if the Internet humanity is already on the retreat into their last comely homes, which are more closed than open to the outside.

On the positive side:

1. Self-managed blogs (like: not on Substack or Medium) by individuals have become a strong indicator for interesting content. If the blog runs on Hugo, Zola, Astro, you-name-it, there's hope.

2. As a result of (1), I have started to use an RSS reader again. Who would have thought!

I am still torn about what to make of Discord. On the one hand, the closed-by-design nature of the thousands of Discord servers, where content is locked in forever without a chance of being indexed by a search engine, has many downsides in my opinion. On the other hand, the servers I do frequent are populated by humans, not content-generating bots camouflaged as users.

That is sad to hear. Spending even just thirty minutes on the website to better communicate what one can/cannot do would go a long way.

In any case, thank you for your work.

That's what the AI robots will use as an explanation when they have f*cked us up. :-)

This looks cool, can't wait to try it!

At first, people might think "$10,000 demo problem? What a high number!" Realistically, in corp environments, that number is an understatement. Plus the long time (and pain) it takes to get every team's buy-in to help with capturing/generating that data.

Thanks for putting things in perspective, EdwardDiego.

The fact that MM2 happened, and Confluent didn't try to stop it, despite it being awfully similar to Replicator, makes me think that Confluent are acting in good faith.

Let me share an anecdote related to this example. We (Confluent) were actually the ones who contributed the documentation for MirrorMaker v2 to the Apache Kafka docs (https://kafka.apache.org/documentation/#georeplication). The development lead on MM2 was (an engineer at) Cloudera, yet they never spent the time to provide user-facing documentation to the Kafka project. I don't want to speculate about reasons, yet I noticed that MM2 was documented in the Cloudera docs.

If we didn't care for the Kafka community at Confluent, we would not have spent our own resources and time to fill that gap, given that we have a proprietary product similar to MM2 (i.e., Confluent Replicator).

https://github.com/apache/kafka/pull/9983

Confluent Cloud is a truly 'fully managed' service, with a serverless-like experience for Kafka. For example, you have zero infra to deploy, upgrade, or manage. The Kafka service scales in and out automatically during live operations, you have infinite storage if you want to (via transparent tiered storage), etc. As the user, you just create topics and then read/write your data. Similar to a service like AWS S3, pricing is pay-as-you-go, including the ability to scale to zero.

Kafka cloud offerings like AWS MSK are quite different, as you still have to do much of the Kafka management yourself. It's not a fully managed service. This is also reflected in the pricing model, as you pay per instance-hours (= infra), not by usage (= data). Compare to AWS S3—you don't pay for instance-hours of S3 storage servers here, nor do you have to upgrade or scale in/out your S3 servers (you don't even see 'servers' as an S3 user, just like you don't see Kafka brokers as a Confluent Cloud user).

Secondly, Confluent is available on all three major clouds: AWS, GCP, and Azure. And we also support streaming data across clouds with 'cluster linking'. The other Kafka offerings are "their cloud only".

Thirdly, Confluent includes many additional components of the Kafka ecosystem as (again) fully managed services. This includes e.g. managed connectors, managed schema registry, and managed ksqlDB.

There's a more detailed list at https://www.confluent.io/confluent-cloud/ if you are interested. I am somewhat afraid this comment is coming across as too much marketing already. ;-)

Disclaimer: I work at Confluent.

PS: Not fully sure what could have caused your Kafka woes. Certainly all what you described is supported, and it also 'should' normally be easy to use as a user/developer.

For example, with Kafka Streams, any app you build with it just needs to set “processing.guarantee” to “exactly_once” in its configuration, and regardless of what happens to the app or its environment it will not lose messages (on write) or miss messages (on read) from Kafka.

Consider asking your question with a few more details in the Kafka user mailing list [1], or in the Confluent Community Slack [2] if you prefer chatting.

[1] https://kafka.apache.org/contact [2] https://launchpass.com/confluentcommunity

Both Kafka and Pulsar have this kind of bottleneck in your scenario -- say, one "hot" write partition.

If one Kafka broker or BookKeeper bookie node cannot keep up with the write load (e.g. network or disk too slow, CPU util too high), you must add more partitions. For Kafka, for the reasons you already mentioned. For BookKeeper (and Pulsar), because only a single ledger of a topic-partition is open for writes at any given time.

See my previous answer further up in this sub-thread. Neither Kafka nor BookKeeper require data repartitioning when adding new nodes. Instead, both require data rebalancing, which moves some data from existing nodes to the newly added nodes.

Think: repartitioning changes the logical layout of the data, which can impact app semantics depending on your application; whereas data (re)balancing just shuffles around stored bytes "as is" behind the scenes, without changing the data itself. The confusion stems probably from the two words sounding very similar.

For Kafka, you use tools like Confluent's Auto Data Balancer (https://docs.confluent.io/current/kafka/rebalancer/index.htm...) or LinkedIn's Cruise Control (https://github.com/linkedin/cruise-control) that automatically rebalance the data in your Kafka cluster in the background. Pulsar has its own toolset to achieve the same.

Bookies can seamlessly be added.

Kafka brokers can seamlessly be added, too.

I remember adding brokers to Kafka and taking advantage of them on existing topics meant repartitioning which if I recall correctly breaks the golden ordering contract that most devs bank on.

Adding brokers to Kafka does not require repartitioning. It requires data rebalancing ('migrate' some data to the new brokers), which does not break any ordering contract. I suppose the words sound sufficiently similar that they are easy to be mixed up. :)

(For what it's worth, BookKeeper requires the same data rebalancing process.)

The data written to the partition will always be in the order for that partition itself.

Yes, for Kafka, all log segments that make up a topic-partition are always stored -- or, when rebalancing, moved -- in unison on the same broker. Or, brokers (plural) when we factor in replication. Kafka's approach has downsides but also upsides: data is always stored in a contiguous manner, and can thus also be read by consumers in a contiguous manner, which is very fast.

In comparison, BookKeeper has segmented storage, too. But here the segments -- called ledgers -- of the same topic-partition are spread across different BK bookies. Also, because of how BookKeeper's protocol works (https://bookkeeper.apache.org/docs/4.10.0/development/protoc...), what bookies store are actually not contiguous 'ledgers', but in fact 'fragments of ledgers' (see link). As mentioned elsewhere in this discussion, one downside of this approach is that BK suffers proverbially from data fragmentation. (Remember Windows 95 disk fragmentation? Quite similar.)

No approach is universally better than the other one. As often, design decisions were made to achieve different trade-offs.

Yes, you remember correctly. The Kafka community has already started the work on getting rid of ZooKeeper. See https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A... for details.

(copying this text from another comment of mine elsewhere)

Well, the Pulsar broker is (kinda) stateless, because they are essentially a caching layer in front of BookKeeper. But where's your data actually stored then? In BookKeeper bookies, which are stateful. Killing and replacing/restarting a Bookkeeper node requires the same redistribution of data as required in Kafka’s case. (Additionally, BookKeeper needs a separate data recovery daemon to be run and operated, https://bookkeeper.apache.org/archives/docs/r4.4.0/bookieRec...)

So the comparison of 'Pulsar broker' vs. 'Kafka broker' is very misleading because, despite identical names, the respective brokers provide very different functionality. It's an apples-to-oranges comparison, like if you'd compare memcached (Pulsar broker) vs. Postgres (Kafka broker).

The broker being stateless is great. I've had issues with moving partitions around in Kafka.

Well, the Pulsar broker is (kinda) stateless, because they are essentially a caching layer in front of BookKeeper. But where's your data actually stored then? In BookKeeper bookies, which are stateful. Killing and replacing/restarting a Bookkeeper node requires the same redistribution of data as required in Kafka’s case. (Additionally, BookKeeper needs a separate data recovery daemon to be run and operated, https://bookkeeper.apache.org/archives/docs/r4.4.0/bookieRec...)

So the comparison of 'Pulsar broker' vs. 'Kafka broker' is very misleading because, despite identical names, the respective brokers provide very different functionality. It's an apples-to-oranges comparison, like if you'd compare memcached (Pulsar broker) vs. Postgres (Kafka broker).

Unlike Kafka, and despite some unfortunately misleading wordings in articles and documentation pages, Pulsar doesn't actually support exactly-once aka 'effectively-once' semantics because it lacks support for transactions. It only supports an idempotent producer combined with message deduplication. The current functionality only works when producing one message and to only one partition. For example, you cannot atomically produce multiple messages to one partition with Pulsar today, let alone multiple partitions.

See this Dec 2019 presentation by Pulsar committers, where they explain all this in more detail, i.e., the lack of transactions and the resulting limitations, and the motivation for adding such transactions to Pulsar. The approach looks very similar to Kafka's. https://www.slideshare.net/streamnative/transaction-preview-... The original ETA for transactions was Pulsar v2.6 (June 2020), but as of today there's still quite some work to be done (https://github.com/apache/pulsar/issues/2664). The latest ETA seems to be around the end of the year.

The key difference for an end user is that Kafka released all the functionality in one go back in 2017 (idempotent producer, transactions; which fwiw also explains why designing+building+testing took the Kafka community that long) so it has been much easier to understand what is actually supported vs. what is not.

Also, since you talked above about the "lack of documentation" to get up and running with a small Kafka deployment of only 1 broker and 1 ZK instance: this is covered in the Kafka quickstart, which is probably what most people will read when starting out with Kafka. See https://kafka.apache.org/documentation/#quickstart.

Perhaps you had a different issue though?

Kafka requires only a single ZooKeeper instance to get started. Kafka's official quickstart actually walks you through running a local deployment of Kafka that has 1x Kafka broker and 1x ZK instance: https://kafka.apache.org/documentation/#quickstart

Why don't you run Kafka from a Docker image, like the Docker images provided by Confluent?https://docs.confluent.io/current/installation/docker/docs/