jonquark

Having recently tried Handy (on Wayland/Gnome) it seemed very slow. On first look this seems very slick and the default settings are responsive on my aging laptop.

I'm very impressed so far.

Isn't the metric that you've used "bugs per commit ~ per new line of code" going to miss the issue?

All code is technical debt.

If rsync releases used to have 500 lines changed and 5 bugs in and AI-powered rsync releases have 50000 lines and 500 bugs, it's the same bugs/line but much worse experience for the user?

I've not looked into the details of this case and I do use AI assistance coding at work but in my experience, the problem is that it's too easy to write lots of code and therefore hard to review the huge volumes of code and this analysis will ignore that?

edit: actually your table shows there weren't unusually large numbers of commits in this release, so perhaps my initial skepticism shows a bias I have?

The UK spends a lower fraction of its GDP on health than the US (the US is an outlier because of its system).

The UK's NHS is not why it's not taking part in this mess.

Yes maths is singular, just like physics. We would say in the UK "maths is hard, physics is also hard"

Only Hamas could do that but this article is pointing out that all of Gaza (not just Hamas members) are being starved.

It's the only social media I still use.

I don't notice "disjointed communities" I just look at the posts from people I follow without knowing which server they are on. I'm aware you can see a list of posts on your local server but I imagine people on most instances (unless the instance has a strong theme like for people from a particular location) never use it.

I'm not a hardware tinkerer - but if there was a production version of this, I would buy it. But I guess I'm a niche market.

The Wayland leg works fine for me on gnome+wayland.

I agree there are cases where Kafka and MQTT are often used together. If you have lots of MQTT clients producing messages fanned-in to a small number of backend apps (or consuming a small number of wide fan out messages) people often combine Kafka as a fat pipe behind MQTT brokers (though there are alternatives, consuming messages from the brokers using e.g. MQTTv5 shared subs)

In more complicated situations (e.g. "outgoing" persistent messages buffered for individual clients (i.e. each client has a "message inbox"), Kafka is less obviously useful (it's an anti-pattern to try and random-seek the messages from Kafka topics as clients connect). In this kind of pattern, the main architecture pattern I see are clients partitioned across (highly available) MQTT brokers. If the messages come from MQTT clients directly to other clients (e.g. instant messaging (Facebook Messenger uses MQTT), having these broker in a cluster sharing a topic tree is very useful.

If the outgoing messages don't get buffered whilst the clients are off-line (e.g. because these are responses to client requests) then you don't need each client to be routed to a "home" broker that buffers the messages - it can connect anywhere.

It all depends on the shape of the message flow you're designing the system to support (but to say MQTT is a toy for small numbers of topics as it seemed to me that you argued up-thread seems misguided).

MQTT.org can't answer that as it's a web page for for a protocol. I've worked on platforms that do have a historian feature but it will vary from broker to broker.

(disclosure, I work on Eclipse Amlen and it does not - but people often rig it up to a subscriber that funnels (some/all) messages into databases

This comment seems backwards to me. If you're funnelling incoming messages in to hundreds of topics (or less) Kafka is a great "fat pipe" if you need millions (or tens of millions) of topics for IoT devices, MQTT is much more designed for that usecase

Disclosure: I'm biased - I've worked on the MQTT spec and I'm the lead for Eclipse Amlen