Yeah, I don't want want to take away from anyone. The COSMIC team is doing amazing and hard work. I started dev on claude-desktop-debian with Pop!OS COSMIC as my daily. We're just in a weird spot for that particular issue right now. In 3 years, it'll be something else. That's the nature of fragmentation.

While GNOME tray lovers and haters both exist, only one of those two groups is liable to submit an issue against my repo looking for help getting icons working correctly.

> A lot of us are happy gnome doesn’t support tray icons.

A lot of us = very few people in total, apparently.

There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distros and overwhelmingly installed on those that don't have it. Even Gnome itself has started development on a native systray, although in classic Gnome NIH fashion they either want to implement a new standard or are were even considering using the deprecated snixembed standard instead of using what 99% of Linux does :+)

(Technically they want it for pretty good reasons, but good luck forcing all Linux applications to implement yet another standard, especially the commercial applications)

How do I bring your app to the foreground if I can't see an icon anywhere? I just installed Ubuntu for the first time a few weeks ago and genuinely don't see how people are supposed to use it, coming from a Windows/Mac background. How does a Linux user know what's running, without going to a terminal and running top?

The lack of desktop UI affordances in the leading "user-friendly" Linux distribution should be seen as a five-alarm fire by anyone interested in promoting wider Linux acceptance on the desktop. There are reasons why Linux can't get past low single-digit adoption no matter how badly Apple and Microsoft screw their users, and I'm sure the half-assed desktop UI is one of them.

I don't like tray icons. What I like less is an app that runs in the background anyway when I didn't ask it to and that behavior is hidden. It's infuriating to "quit" an app and it's still there. At least gnome finally addressed that with the little background apps widget.

Thanks to the Linux kernel's extremely high backward compatibility, and virtually all the libraries being open source, you can ship old or frozen versions of libraries with your application if you have to. You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality, while using the distro version if that's more up to date and still has the functionality. You can do the same for auxiliary programs your application uses.

I agree that sticking to libc is most reliable, if you can. But the experience is poor if you do that for desktop applications.

There's no singular source of truth, but there's a de facto frontier of only a few mainstream distros, as well as upstream heads for your dependencies.

It's extra work, but there are systematic workarounds to the feature drift over time and the tendancy of some open source projects to aggressively deprecate older functionality and older system compatilbilty.

You can, to an extent, automate testing on newer versions of distros to be alerted when something no longer works, and often you can do this before the official distro release date.

Unfortunately even libc is not reliable. Unless it's a static build, Glibc is often broken (with symbol version errors) when trying to run a binary compiled on one distro on another distro, or an older version of the same distro. Static binaries have other problems, though work very well if the application is self contained and isn't a GUI.

One thing that I find works very compatibly, though, is OpenGL / Vulkan binary-compatibility across distros and versions. There was a lot of work done on making libGL something you can link to or dynamically load reliably and take it from there. The OpenGL extension spaghetti is an interesting problem from then on, but that's more to do with the individual user's GPU and GPU drivers, independent of the Linux distro or even which OS it's running on.

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.

Can confirm, I hate flatpak

If all you want is a chat interface you can install Claude.ai as a PWA. The value proposition of the Claude desktop app includes being able to screenshot and interact with desktop app windows, the file system, etc. That drags you into desktop environment and compositor API hell.

Microsoft gave up on teams for linux, the app that's available now is a community electron webapp wrapper, and Zoom isn't electron at all, its QT but they chose the path of only supporting a few distros (Ubuntu, Debian, Mint, RedHat) and they also don't rely on system QT versions, they vendor it.

If your app is open source, I say just build & test on one of the major distros and let the community port it to others. If its closed source, well, good luck. But if what the parent said is true, that you now collect a bunch of very vocal pissed off customers because you didn't support their favorite distro, then its just not worth it at the current marketshare that desktop Linux has.

There's also the challenge of you just can't make any assumptions about what may be present or not on someone's Linux machine, even with the major distros.

Agreed - it's not the flatpak itself, it's that whole fragmented ecosystem. And unstable ABI doesn't help.

Such as?

The only proprietary software I have running on my machine is electron apps, which are essentially bloated VMs. As we’ve seen from this thread, this is still apparently too great of an engineering feat for anthropic to tackle. I don’t think I’m unique in this regard.