I'm with you. I have the Claude web app pinned as a PWA for quick queries, and then use the CLI for everything project-based.
I did consider experimenting with the Routines feature on the desktop app, but I'm leaning towards whipping together something with cron. I saw another poster here who has a daily PR summary routine that I think would be handy, as I have quite a few repos where I'm a sporadic contributor but would like to keep tabs.
Everyone parrots this but I don't think it's true. The Linux kernel does famously have a stable ABI (we "don't break user space" after all).
The issue is folks expect this to be at a higher level, so when libc or GTK or Qt etc. have breaking changes, all your apps using the old versions fail. This is a legitimate pain point with traditional distros.. I don't want to sound like I'm downplaying it.
However, this is basically solved by flatpak (and others like it, eg snap) which contain _all_ these dependencies in the package. Layering (ala containers) is used for deduplication so you don't have 20 copies of a given GTK version.
While MacOS provides the windowing toolkit etc. at the OS level, it's otherwise similar to how a .app file works. Installers aren't dropping dynamic libraries and resource files all over your disk, the app is "self-contained."
Have you considered flatpak support? I know it's has its rough edges, but I use many apps across arch/Fedora/Ubuntu that are delivered as a single flatpak.
This feels analogous to the old Google latency improvement story - improve performance and p99 goes up, not down, because more people are now able to use your product.
These angry customers are a symptom of having more customers; in this direction (compatibility) companies shouldn't be KPI'ing on angry customers.
It is very legitimate that high compatibility means more very obscure, low value, high cost, bug reports that are hard to classify as such. And my gosh, I hate working with rude ticket writers.
> These angry customers are a symptom of having more customers;
No, it's a symptom of having more of a very specific type of customer who is more demanding and difficult to please than your other customers.
When you don't officially support Linux, the Linux users are not surprised. It's normal for them. They find other ways to use the product.
When you do announce Linux support, you open Pandora's box of complaints. They're extra angry that you claim Linux support but it doesn't work perfectly on their unique combination of laptop, distro, display protocol, and window manager.
You gained a small number of happy customers, but picked up a disproportionately large number of angry, vocal customers in the process.
Indeed. You make anything past that the customer's problem. I have a few Ubuntu apps that needed a bit of jiggery-pokery to make them run on not-Ubuntu.
Flatpak serves a need, there are plenty of users who like it and there are probably even more who just use it without thinking much about it. Personally, I like it for a few reasons:
- Being able to install something dependency-heavy with just one package
- Sandboxing
- Getting a newer package than what my distro provides
- Being able to update apps independently of the rest of the OS
- Being able to easily install apps that my distro doesn't provide
The people who hate it, especially without giving a reason, are largely irrelevant when flatpak is filling a need for so many other people. Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.
> Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.
And how do you know the userbase for GP's specific product is all Flatpak users? In fact, based on their comment, it appears as though they are explicitly not, hence their vocal frustration.
Not the person who wrote that but i also avoid anything related to Flatpak. The reason is that it adds a lot of extra friction to anything it touches (despite what its proponents may claim), apps ignore various settings, it wastes disk space with pointless duplication and a bunch of other issues i do not remember right now (it isn't like i write those down - i just sometimes decide to try it for something exactly because i forgot all the issues i faced and somehow someone convinced me things aren't as i remember, then recoil in horror afterwards as it turns out things are as i vaguely remember -- of course the main thing i always remember is the distaste i have for the thing, not the individual microdetails that led to the distaste).
Ultimately if something isn't in my distro's repository, i try to compile it from source and if that isn't available, i just use something else.
It's superfluous, goes against unix philosophy, solves problems that don't exist in the most obnoxious ways possible, and your distro packager is certainly better.
There is a difference between mandating that your customers use one specific Linux distro which is maintained by a controversial company, and supporting all Linux distros through an imperfect-but-fully-working method.
Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.
Yeah ChromeOS has the same problem. They have a Javascript-native terminal emulator, and a wasm (formerly PNaCL) implementation of open-ssh. But they have to use ChromeOS specific browser extensions in order to allow native TCP connections to port 22 from wasm, and Google only gives themselves this privilege, not any random dev like us.
I'm curious to see if this weird stack gets ported to the Googlebooks or if they just make a mouse-friendly Android app instead.
That's mostly because BEAM uses an actor-style approach while predating the concept of actors, isn't it? Interesting artefact of history if so
Edit: upon rechecking, apparently that's not exactly right, and Erlang designers learned of actors after designing the language, which makes it all the more interesting
I've spent the last decade in erlang / elixir / OTP. I think a lot of the naming comes from the early use of erlang as effectively an "OS" for telecom switches.
I always joke that BEAM wants to be the operating system.
You not only leave performance on the table (which depending on your use case/environment, may not matter if you can just throw more threads at it) but also some developer ergonomics.
asyncio.gather is a lot less code than having to manage a thread pool or something like Celery with all it's underlying infrastructure.
If you're in an ecosystem where a lot of the async boilerplate is free/cheap (ex: FastAPI) then the developer overhead of sprinkling awaits on your I/O bound calls is pretty low IMO.
Performance aside (which I would argue is premature optimization, as most programs will not feel the theoretical overhead of threads), async is a bad approach for developer ergonomics. Threads are so much easier to work with and reason about than async. There are reasons to use async (like if you're in the rare case when thread overhead is noticeable), but developer ergonomics are absolutely not a reason.
Say I need the results from two expensive REST API calls, so I want to run them concurrently. Managing a thread pool you find a _better_ experience than
one, two = await asyncio.gather(callOne(), callTwo())
Sure, in a web server context you'd probably want to instantiate that executor globally and re-use it, Then you could write helper functions around that. But it's still considerably more code and legwork than the async alternative, while also being slower and using more memory if you care about those things.
> something like Celery with all it's underlying infrastructure.
Unpopular opinion, but combining this with the other "no thanks" sentiments in this subthread is the right answer. Your app is so complicated you need async? Then it's complicated enough that you can benefit from infrastructure. I don't want to watch coworkers try to badly rebuild message queue or scheduling semantics in an application code base. Just use infrastructure that's made by people who know what they are doing. That was problematic in 2015, but in 2026 it's a bit of docker, and it's not just about web/microservices. Very easy for sufficiently complex apps to simply leverage a local sandbox of celery, redis, graphdb's and whatever. Stand-alone is overrated since we don't have to do it anymore.. app devs should get more comfortable working with ensembles like this so they have access to best-in-class solutions.
You don't like infrastructure AND have such a need for performance AND don't want threads or multiprocess? Consider using another language. Async is mostly a solution in search of a problem, and the enduring popularity of TFA goes to show this has been the right conclusion for ~10 years.
I said nothing about "stand-alone" services. I'm all about using the right solution to the problem. We run on Kubernetes and have access to message queues. But if all I want to do is make a couple of HTTP calls concurrently, I don't think I should have to manage a thread/process pool to do so, or lean on a message queue or redis based RPC mechanism. In an async context I can do this with a single line of code.
Every rich client-side experience in your browser is written using async code in Javascript or Typescript, as is every electron app. Every developer at my company is comfortable with this pattern, and frameworks like FastAPI make this a similarly smooth experience when using Python.
If async was a solution in search of a problem, it wouldn't have been stolen from C# and added to Rust, Python, Kotlin, etc. The engineering effort required to bring this solution to all these languages is immense, so I'm clearly not the only person seeing value in it.
As other commenters have pointed out, cooperative multitasking is actually a great fit for I/O bound code.
reply