A lot of that is keyboard shortcuts for push-to-talk. Easy right?
X11 is mostly fine, but the world is moving into Wayland. Wayland doesn't have shortcuts native and relies on xdg-desktop-portal, which in turn relies on each backend to implement it's own version.
COSMIC from the Pop!OS team's xdg-desktop-cosmic doesn't support GlobalShortcuts yet (might now, haven't checked in a bit). So XWayland for them.
Tray icons? GNOME doesn't have a tray out of the box, but there's an extension. There's no standard for whether it's light mode or dark mode across distros and when you map out the options, no api's indicate whether the tray is light or dark while in light/dark mode. At some point you have to just accept it's not always perfect or patch in an override.
Global shortcuts definitely a pain point with Wayland but the portals are making progress.
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 = 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)
Back when I still had a need for it it was solely because some apps do not have proper support for missing tray icons (you can only fully close them via the tray icon), not because I actually like the feature.
I appreciate that GNOME tries to move on from this. Unfortunately it doesn't have the market control that Windows has, so not all app developers follow suit.
All these issues can happen in any platform, Linux is just the more annoying/unpredictable one, with GNOME taking the cake for being so obtuse. There is either a carelessness from the developer or the ad-hoc nature of those "tray icon" systems is to blame.
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.
On GNOME? Alt-tab, super overview, or click the dock icon. It's literally not any more complex than multitasking on an iPad.
That point would hold some water if the iPad were intended as a first-class multitasking platform, like a desktop OS. I don't know what the 'super' key in GNOME is, and don't much care, because if that kind of thing isn't obvious it might as well not exist. Having never used *nix on a graphical desktop before, I'm just blown away by how primitive the experience is.
Fortunately Claude Code was happy to install dash-to-panel for me when I asked it what the deal was with this particular flavor of airline food.
This is like having someone tell you that they refuse to use an iPad because the home button confuses them. That's your choice.
I've used GNOME professionally for 7 years now, and I've taught kids to use it at robotics workshops. If you can believe it, many of them are unable to use macOS and Windows at all, because their school districts don't buy them laptops anymore. I'm sorry that GNOME isn't a carbon copy of your favorite OS, but it's not hard to use whatsoever.
Obviously this will probably fail on other distros, but I've found in the past similar groupings. Backwards compatibility is different: I expect a package a compile on Ubuntu 24 not to work on Ubuntu 22.
This is anecdotal, and in the context of rust + EGUI, so I'm not sure how applicable it is to Electron.
I recently hit a Wayland snag: It doesn't support Device Events other than mouse movement. I worked around it by changing to Window events. I could see that being annoying if this substitution weren't acceptable, but it was in this case.
"Tony Stark can do it in a cave! With rocks!"
Much easier to create a vm testing swarm of 100 disitributions with llms
There are companies that do this right. But it often requires a hire. Too many companies think they can just yolo it because Linux isn’t a serious OS or whatever and then are surprised when it doesn’t work out well.
That's often a great idea!
But a full time hire? The GP's post implies that wouldn't make business sense for them, as even half a day occasionally on it is too much...
>> So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere. The number of tickets with Linux issues keeps growing and each one is taking more time to debug, all for a number of customers that is so small you can’t justify doing it.
Of course an experienced Linux release engineer can do it faster and more reliably. That's probably the cheaper option. But the business still has to decide their Linux customer or user base is large enough, or strategically worth supporting, to justify the cost however they do it.
For many businesses even fractional Linux support is not justifiable for the small number of Linux users and support requests they're unable to handle. Though I can't imagine that being the case for Anthropic!
(Hint: This is one of the things I consult on, if anyone is looking to pay for quality Linux release engineering and platform testing. I have hundreds of historical and current Linux VMs, multiple architectures old and new (esp. x86, ARM and RISC-V), some of them embedded, fairly deep knowledge of how the kernel and libraries work together, and test harnesses. Also I test some compiled applications for portability across other OSes and architectures, including Windows, MS-DOS, MacOS, BSDs, SunOS, HP-UX, etc. going all the way back to the early Unix lineage.)
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.
Not if they're GPL licensed you can't. And that's a headache most commercial people do not want at all when trying to write software that's often for a marginal part of their audience anyway.
Wrong, misleading and possibly FUD. Yes you can ship GPL licensed software with your application, even a proprietary, closed source application.
You have to comply with the GPL terms, but that's easy to do for every library or auxiliary program that you'd link to or call in a Linux distro.
The GPL is designed to support this use case, with it's "mere aggregation" clause making it clear that it's allowed.
The one thing you can't do if you're shipping a closed source application is link to GPL-licensed code (unless there's an special exception clause, or it's LGPL, or it's dual-licensed to allow this). But for this type of GPL library, you can't use the Linux distro's shipped version either. So the GPL constraint makes no difference to the question of whether you can ship a frozen or fallback version with your application in lieu of the distro version.
If there's a corner case the above doesn't cover, I'm not aware of it and I've studied GPL compliance more thoroughly than most people. So I'd like to know about it :-)
I dunno why this is always so difficult.
My reply to the comment below outlines the shape of the problem.
Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.
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.
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.
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.
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.
I wasn't looking to anger you, just to provide a different lens in which to view the situation.
Made comment about flatpack below the comment above.