6/7/2026 at 1:55:05 PM
Hey!I manage the unofficial build at https://github.com/aaddrick/claude-desktop-debian
Debian is in the name, but scope has grown to all backends, compositors, etc.
The main reason must companies don't publish Linux electron apps is fragmentation. If you're doing anything more than rendering a webpage as an app, it starts to get complicated. I've got a bank of VM's setup for testing, and I still need it up.
by aaddrick
6/7/2026 at 3:17:09 PM
> The main reason must companies don't publish Linux electron apps is fragmentation. If you're doing anything more than rendering a webpage as an app, it starts to get complicated.Can confirm. At a past company we worked hard to release a Linux desktop client for our customers who wanted it, even though the number was small.
It turns into compatibility hell very fast. You think you can target a couple recent Ubuntu releases and everything will be good, but then you’re getting peppered with complaints from people using distributions you’ve never heard of because some part of the app isn’t working right. 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.
But those customers are angry. And vocal. They’re posting all over Twitter, Hacker News, and Reddit about how your company’s software is garbage, without mentioning that they’re running an unknown distribution on a 13 year old ThinkPad.
This even impacts open source projects. Several popular OSS Electron apps don’t work on many popular distros unless you set some command line workarounds, and even then it’s flakey. The open source projects get a pass because it’s open source, but if your company releases something you might be picking up a lot of angry, vocal customers that you didn’t want.
by Aurornis
6/7/2026 at 4:07:14 PM
Yeah. I just dropped another repackaging repo for Wispr Flow. https://github.com/wispr-flow-linux/wispr-flow-linuxA 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.
by aaddrick
6/7/2026 at 4:35:35 PM
A lot of us are happy gnome doesn’t support tray icons. We are sick of devs thinking their app is so important it needs a visual presence at all times. If I need your app I’ll bring it to the foreground, we have the technology.Global shortcuts definitely a pain point with Wayland but the portals are making progress.
by WD-42
6/7/2026 at 4:49:13 PM
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.
by aaddrick
6/7/2026 at 6:15:33 PM
> 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)
by jorvi
6/7/2026 at 6:36:20 PM
> There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distrosBack 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.
by aniviacat
6/7/2026 at 6:17:48 PM
The tray icon dock/panel in KDE is fully removable. You can just delete it. So the opposite of that is also a thing. No one is forcing you to always have a visual presence of a program. Even Windows let's you hide tray icons forever if you want.by hparadiz
6/7/2026 at 6:40:40 PM
But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.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.
by amlib
6/9/2026 at 8:11:01 AM
> But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.Can you name some that act like this? In 30 years I don't think I've ever seen that behavior...
by JCattheATM
6/8/2026 at 1:22:53 PM
That's precisely what is wrong with the state of the UI for Linux. Instead of boring, long research into user habits, finger memory, and productivity, resulting in boring standards like IBM CUA or Apple HIG, we got a bunch of opinionated engineers who think that people using computers fall into two categories: wizards, who are happy to spend their life tinkering with config files and making various pieces work together - and a bunch of losers not worth developing software for...(Until Microsoft had actively started fracking it up, sometime around Windows Vista) just like a Roman citizen landing up in any town of the Empire, one would be able to effectively and consistently navigate around, using both keyboard and mouse across most Windows applications. Everything worked in a boring, predictable way. Everything used standard API that provided the whole spectrum of UI capabilities.
With Linux, unfortunately, this was never considered ideal and instead we have a zoo of different paradigms and technologies (plus intense politicking of UI development). Which means, when something happens to work as expected without excessive ServerFault/ChatGPT trawling and config/gconf/dbus wizardry, it feels like a sheer delight and an exception rather than a rule.
by Postosuchus
6/7/2026 at 5:04:01 PM
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.
by CamperBob2
6/7/2026 at 5:11:59 PM
Did you try pressing the super keyby WD-42
6/8/2026 at 4:41:32 PM
Most desktop users aren't keyboard wizards.by curt15
6/7/2026 at 5:19:39 PM
> How do I bring your app to the foreground if I can't see an icon anywhere?On GNOME? Alt-tab, super overview, or click the dock icon. It's literally not any more complex than multitasking on an iPad.
by bigyabai
6/7/2026 at 5:33:51 PM
[flagged]by CamperBob2
6/7/2026 at 5:41:05 PM
> I don't know what the 'super' key in GNOME is, and don't careThis 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.
by bigyabai
6/8/2026 at 2:56:04 AM
> I don't know what the 'super' key in GNOME isClearly you're not a golfer.
by helterskelter
6/7/2026 at 5:36:45 PM
Oh please. The super key is the windows key. You come across as someone who has never used a computer before.by WD-42
6/7/2026 at 6:07:54 PM
[flagged]by kskdkwjdkwkkds
6/7/2026 at 7:28:18 PM
You come across as someone who’s never talked to a normal human beingby rhrtjfjjghf
6/7/2026 at 8:05:00 PM
[flagged]by CamperBob2
6/7/2026 at 8:33:21 PM
So you really couldn't figure out what "Super key" meant, even with context? I feel like you are being hyperbolic. This isn't magical hidden Linux knowledge. Honestly, if not being able to find what applications you have running, and not even trying pressing the large button on your keyboard with the windows logo on it was so traumatizing, you might want to just avoid Linux entirely.by WD-42
6/7/2026 at 9:21:29 PM
No, I didn't realize that the "Super key" was the Windows key, and no, I didn't think to try it. I never use the Windows key myself, because it's never needed. I'm either in a DOS or PS box, or if I'm working at the desktop, the taskbar gives me all the affordances I need including a 'Type here to search' box.Key point is that I don't want to press any keys to maintain my awareness of what's running on the machine. Processes with windows associated with them should always be apparent in one way or another. Ubuntu got the less-useful part of the taskbar right -- the quick-launch icons on the column at left -- while failing to do the important thing, which is to show, well, tasks.
I remember when they first started putting Windows keys on keyboards. If you think AI pisses people off, LOL... you weren't reading Slashdot and other Linux-adjacent sites when those keys started showing up. It's amusing to see that they've been embraced (if not extended) by the haters.
by CamperBob2
6/8/2026 at 4:57:59 PM
> Processes with windows associated with them should always be apparentKDE and GNOME both solve this with a dock, the same way that Windows and macOS solve it.
> It's amusing to see that they've been embraced (if not extended) by the haters.
The haters by-and-large don't use it. Those haters use esoteric tiling WMs that don't bind anything to super by default.
The KDE and GNOME developers have a direct usability goal. With respect to Slashdot's opinions, the Linux desktop would still be stuck in the 90s if we listened to them. Your perspective as a DOS/PowerShell user is not any more valuable, considering you barely use Windows as-is.
by bigyabai
6/9/2026 at 2:13:45 AM
KDE and GNOME both solve this with a dock, the same way that Windows and macOS solve it.Not by default, GNOME doesn't. Try installing Ubuntu. You get nothing but a blank desktop by default. The bar at left only shows shortcuts for launching tasks, not running tasks themselves.
Your perspective as a DOS/PowerShell user is not any more valuable, considering you barely use Windows as-is.
Those advocating an OS with 5% market share might do well to listen to other perspectives once in a while.
by CamperBob2
6/8/2026 at 2:01:44 AM
Don’t feed the trolls.by irishcoffee
6/7/2026 at 8:09:40 PM
And that this key is called "superkey" is a widespread standard on computers?Or just linux?
I think the latter. And it might surprise you, but there are computers with no linux installed. I think the vast majority actually. So why the need for insults?
by lukan
6/7/2026 at 8:30:51 PM
Pretending like the person I'm responding to isn't being willfully ignorant isn't helping. It's pretty simple to guess what "super key" means just from context, if not, it's a very quick (in the op's case) llm query away. Let's be real here.by WD-42
6/8/2026 at 12:36:08 AM
As someone whose last interaction with Windows was 98 and have been on Mac ever since I also had no idea what a super key was. Also Googled “Windows key” and realized I had seen it before in pictures but never thought about it.I used some sort of *nix on a VAX terminal in college and ran SUSE on my machine once I realized I hated Windows 98 but all of that is ancient history at this point lol. All of that is to say that it is possible for someone to be peripherally interested in this topic and not be aware of what a super key would be even in context. Maybe someone that uses Windows could pick up on it earlier but I certainly didn’t:)
by musictubes
6/8/2026 at 5:11:05 PM
It helps that the Super key's glyph is identical to the greyscale four-pane window icon that Microsoft uses: https://www.gnome.org/Most people that look down at their keyboard will be able to visually identify that icon out of the bunch, methinks.
by bigyabai
6/7/2026 at 8:48:20 PM
I am real. I used computers for a long time. Also linux, but not exclusivly.Guess what, I also only learned recently (some years now I think) after making it mire default, that on linux the windows key is called super key. And the person you insulted clarified he did not use linux at all.
So, how should he have known, despite working with computer extensivly?
by lukan
6/7/2026 at 6:37:50 PM
[dead]by preg_match
6/7/2026 at 6:07:00 PM
You might be happier with a consumer OS.by antonvs
6/8/2026 at 7:28:00 AM
if you're running ubuntu, and the app uses a systray icon, you just click on the systray icon. ubuntu has appindicators out of the box.by rav3ndust
6/8/2026 at 12:25:17 AM
> We are sick of devs thinking their app is so important it needs a visual presence at all timesKDE Plasma allows hide selected applications from the tray and make those accessible in a popup window. The solution to this problem is not to remove the feature entirely, but actually implement it properly.
by kombine
6/8/2026 at 2:13:09 AM
Going a little further back to 2001 Windows XP let users do the same. They haven't been requiring visual presence for decades!by c-hendricks
6/7/2026 at 4:44:17 PM
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.by jm4
6/8/2026 at 9:33:31 AM
I still don't see what was so broken about X's security model that it warranted a whole new protocol (with its own problems that it's still solving 15 years later) instead of an extension to X11.by MarsIronPI
6/7/2026 at 9:10:26 PM
> Can confirm. At a past company we worked hard to release a Linux desktop client for our customers who wanted it ... you’re getting peppered with complaints from people using distributions you’ve never heard of ... but the problem is in upstream somewhereYou have taken on the work the distributions do in the open source world. No upstream open source developer takes that on. Instead of getting bug reports from users, upstream developers insist bug reports are filtered by the distro maintainer first. They fix problems on their side so you never see them, and the ones that do make it through have been triaged. It's a win for everyone.
So the solution is to handle it the way they do. Choose a couple of baselines: maybe Debian Stable and Fedora. Publish packages for them, and make it plain they are only certified for those platforms. Make the rest someone else's problem: if you want it working on distro X, you package it for distro X. You've done the bulk of the work for them anyway, as most of them are either Debian or RPM based.
by rstuart4133
6/8/2026 at 2:20:37 PM
> No upstream open source developer takes that onThe key words here are "open source", right? Some problems can't be solved without cooperation with the developer.
by NotPractical
6/9/2026 at 10:06:20 PM
> Some problems can't be solved without cooperation with the developer.Those problems are the ones package maintainer forwards upstream.
It's well understood common and common workflow because lots of closed source packages are distributed by distro's now. Debian distributes firmware; Ubuntu and RedHat distribute closed source drivers.
by rstuart4133
6/7/2026 at 9:03:25 PM
Sounds like a product management problem. If you declare that you support RHEL and Ubuntu LTS and LTS-1 yet still process bug reports from other installations, the product owner is not doing their job properly. Any bug reports from Nix or Fedora got to be closed due to a wrong operating environment. Even accepting bug reports from the latest non-LTS Ubuntu release should be avoided.by smarx007
6/7/2026 at 7:55:41 PM
Yep, I've seen the same issue in video games. A few passionate engineers convince PMs to make a Linux version of the game, they test on few popular distros, everything is great. Then the game launches , and a very very very small minority of Linux users can't run your game, but they file 75% of all your support tickets. If you don't respond to them in the manner they find acceptable, they are extremely vocal on social media about how you as the developer are lazy and incompetent. It's 10000% not worth it for that reason alone. Nowadays I'd personally advocate for making sure the game runs well under Proton and leaving it at that.by gambiting
6/7/2026 at 8:13:52 PM
The sad part is, that those people usually think, they help linux this way.by lukan
6/8/2026 at 3:39:07 AM
> but then you’re getting peppered with complaints from people using distributions you’ve never heard of because some part of the app isn’t working right.Honestly, it sounds like you guys need to learn to say no. Worked at an OEM and we had device divers for RHEL. If you got it working on something else, good for you. But if you wanted to open a support case, you better be able to reproduce the bug on a supported version of RHEL.
I would occasionally humor people running CentOS if I had some spare cycles, but if you were on Debian the answer was: sorry, would love to help but I can’t.
The people who can’t understand why you have a tight support matrix are the people you don’t want to get sucked into the rabbit hole with anyway.
by tw04
6/7/2026 at 4:30:24 PM
Did you hire a Linux release engineer? Or was the situation the typical team of devs maining macOS that have never heard the term “Wayland” before plus That One Guy who switched to Ubuntu last year and advocated for it?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.
by WD-42
6/7/2026 at 5:20:44 PM
> Did you hire a Linux release engineerThat'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.)
by jlokier
6/7/2026 at 4:52:42 PM
Even for those who do this right, some things change under your feet because OSS maintainers of kernel feature A want to stop supporting V1 of A when V2 has been out for a decade. But the features missing in V2 are supposed to be provided by userspace B - and they are yet to tackle the functionality altogether. So now your app will just have to regress in features. It is very easy to ship OSS code as a maintainer of a project, it is very difficult to keep up with Linux as a developer unless you stick to libc. There is no one source of truth with regards to how things should work, there is no one roadmap, and maintainers care a lot more about complexity than maintaining feature parity of backwards compatibility. I do not blame them, but then it is difficult to target linux. Much easier to support a platform with guarantees and a shared vision. Saying this as someone who has only used Linux at home for 20 years.by eptcyka
6/7/2026 at 5:47:49 PM
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.
by jlokier
6/7/2026 at 6:02:40 PM
> You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionalityNot 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.
by physicsguy
6/7/2026 at 6:26:29 PM
Show me the part of the GPL which forbids you from shipping compiled binaries.by tadfisher
6/7/2026 at 6:28:13 PM
> Not if they're GPL licensed you can't.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 :-)
by jlokier
6/7/2026 at 7:47:54 PM
You cannot ship features that depend on cgroups v1. You may not ship features that depend on netlink attributes that exist on some distros, not others.by eptcyka
6/8/2026 at 6:34:07 AM
Yes, there are a few exceptions to the Linux kernel's backward compatibility. I've encountered others, but I don't remember which any more. They are quite rare, though.cgroups v1 might be the most irritating, because it was useful and something a shipped application or service might realistically use.
by jlokier
6/7/2026 at 9:07:50 PM
I understand this story, and I have heard it many, many times - but I do not understand how something that is possible for thousands of hobbyists writing text editors on their weekends is not possible for professionals! "You can't buy Linux-compatible software because it is too difficult to write. Instead, get it for free."by whatshisface
6/7/2026 at 4:25:19 PM
Reminds me that I occasionally have to set _JAVA_AWT_WM_NONREPARENTING=1 because it's not always inherited from my login shell. Otherwise Java windows won't display anything because I suppose Java waits for them to be reparented.by trumpdong
6/7/2026 at 5:55:37 PM
On systemd, you can use ~/.config/environment.d to set it. Don't rely on your shell.by GrayShade
6/7/2026 at 10:47:48 PM
Screw systemdby trumpdong
6/7/2026 at 3:27:54 PM
This does feel like the perfect setup for Claude though.Much easier to create a vm testing swarm of 100 disitributions with llms
by nbardy
6/7/2026 at 3:37:09 PM
You compile for the lowest possible Linux kernel and bundle your libs. Don't use container formats for stuff like this. tar.gz with an installer script is king.I dunno why this is always so difficult.
by hparadiz
6/7/2026 at 4:55:58 PM
It's mostly dealing with different backends\compositors\etc.My reply to the comment below outlines the shape of the problem.
by aaddrick
6/7/2026 at 7:44:56 PM
From experience: I work on a small team maintaining build infrastructure for my entire company. My goal, as much as possible, is to maintain a single build environment that can serve all purposes.But it has proven quite the challenge to support old Linux distros. We have tried using nix to pin deps, but this easily leads to new issues: hardcoded RPATHs leaking into binaries, glibc compatibility issues, etc.
If we instead fork the build environment and use an old Ubuntu for building our Linux app, then my life gets harder, because now I have two targets for a whole lot of internal tooling that my team maintains, and that tooling needs to be deployed to both build environments. Again, its the same shit: glibc mismatches, missing/different shared libraries, etc. Just causing problems in a different place.
There is certainly some element of skill issue at play. But I wouldn't call it easy.
by hamandcheese
6/7/2026 at 8:31:53 PM
Me too but my job is easier since I can target a specific version of ubuntu so I'm making debs and I don't have that problem.I have recently been working on a C11 GTK+ based task manager where I run into this. https://github.com/hparadiz/evemon/tree/main/packaging
This is why I said bundle your libs. If you bundle ALL of your libs you can't possibly run into an issue if your install script is run as root. Unless it's an extremely eccentric non desktop oriented system at which point that's kind of on them.
If you wanna cover 99.9% of Linux you build fedora, ubuntu, debian, nixos, arch and have a tar.gz as your overflow. For each target the lowest available LTS and don't waste time on distros that aren't getting security updates. It's not reasonable to ask for binaries built against your specific 11 year old gcc.
edit wanted to add one more thing.
I'm a big believer in having your tar.gz and install script inform your deb, rpm, aur, etc. It should be basically the same exact thing as your tar.gz just done in the format those distros want.
by hparadiz
6/8/2026 at 1:31:15 AM
The problem is using the build system. Using Nix flakes could help alleviate a lot of concerns, I wrapped a target meant for debian. After wrapping it with a flake, it worked on NixOS. But since I'm building it declaratively and not imperatively, it could target any distribution, even mac. I've done this with Bitwig, https://github.com/ArikRahman/Nixwig and Jank lang (https://github.com/jank-lang/jank) in this PR: https://github.com/NixOS/nixpkgs/pull/523741by arikrahman
6/7/2026 at 3:33:52 PM
> they’re running an unknown distribution on a 13 year old ThinkPad."Tony Stark can do it in a cave! With rocks!"
by jareklupinski
6/7/2026 at 6:55:16 PM
I don't have experience with Electron, but... IMO if you compile on something like Ubuntu 20, many applications will work reliably on Ubuntu 20, 22, 24,+, and Debian 2020 editions +. (Assuming same CPU arch as the compiling computer).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.
by the__alchemist
6/8/2026 at 12:38:42 AM
Man, I remember 25 years ago writing commercial software that worked across a half a dozen Linux distributions, at least two BSDs, Solaris, AIX, HP-UX, and Irix, and close to half a dozen CPU architectures. Yet today, developers struggle getting a build for two different versions of the same Linux distribution. The industry has lost a critical skill.by ryandrake
6/8/2026 at 7:36:54 AM
I know you are being facetious that there are a few that are a little bit too persnickety with old ThinkPads, but if they used a known distribution on the said 13-year old ThinkPad (that would probably be in the T430 territory), would it be better? I have a T430s and that is still a fine computer, even if my primary one is an 8 year old ThinkPad.Maybe those same people can just prefer using OpenCode. It's at least free software, particularly if that old computer is running only free software with free firmware, and OpenCode can run free models.
by bigpeopleareold
6/7/2026 at 7:46:18 PM
Could you not be extremely clear and state which distros are supported and make it clear that it may work on others but that they are untestedby bazmattaz
6/7/2026 at 8:41:59 PM
Unity Game Engine does this, They support x distro only. So you mess around installing their chosen OS only to find stuff still doesn't work properly.:)
by jay_kyburz
6/7/2026 at 6:03:20 PM
Just ship a flatpak?by esseph
6/8/2026 at 12:56:59 AM
Couldn't just a single Flatpak release be sufficient?Flatpak can be set up on many/most distros.
by winter_blue
6/8/2026 at 1:27:17 AM
Flatpack packages everything under one distributable, but doesn't solve the quirkiness of all the different frontends, backend, compositors, etc.- titlebar
- tray icon w/light and dark mode support
- global keyboard shortcut
- redraw events after resizing
Those are a subset of the many items that don't play well between various distros.
Like Ubuntu Gnome w/X11 vs Pop!OS COSMIC w/Wayland or any of the tiling window managers like hyprland.
by aaddrick
6/8/2026 at 7:15:23 PM
> titlebarConsistency of titlebars has been dead in every OS for decades now. This is not even a flatpak problem anyway, but I do think wayland/gnome ought to have some kind of fallback decoration. This wouldn't even be meant to solve this problem, but would be a nice gesture for situations where a dev really don't care about how the decoration functions or looks, like when opening a game window or movie player like mpv or even just having a friction-less experience when creating your first window in a new app.
> tray icon w/light and dark mode support
Flatpak and specially gnome are championing the background app portals. I have reservations on how it's not a full replacement for tray icons, but Desktop Environments are free to implement it like a tray icon.
> global keyboard shortcut
AFAIK it's a solved problem, but there is an adoption lag for DE's and apps.
> redraw events after resizing
Not sure what you mean by that? Apps resize fine in flatpak
Every problem in flatpak can be addressed. It sucks they weren't addressed sooner but I suggest you look into the efforts being made for flatpak-next. Even right now it's the closest thing we got to a unified gui experience in linux.
by amlib
6/8/2026 at 12:39:43 AM
"So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere."So get to grips with "upstream"! Managing upset "opinionated" and "entitled" users is par for the course anywhere. Have a look at how Veeam do it, for example.
Obviously that sort of compatibility nonsense never happens in say Windows (fairly popular OS).
Let's take a quick look at say web proxies. Proxies are quite popular in corporate environments but blow me if Windows and vendors who use it make it as hard as possible to deal with:
You might think group policy would sort it all out - lol! You have loads of elderly policies relating to IE (several versions) hanging around smelling rather fishy and mildly useful if you have older Windows hanging around. You can use GPOs to fix the following but it will be Preferences and involve a bit of ingenuity.
You have .Net Framework apps - eg AD Sync (Entra, Smentra whatever its called today). That will need you to fiddle with a specific XML file.
winhttp api? Powershell. OK you have two sets of settings here: proxy and advproxy. proxy has string properties that you set and is a bit crap and advproxy has a JSON flavour and is a bit shit. advproxy seems to ignore anything in the ignore list apart from or exclusively <local>. At least advproxy allows you to fall back on a proxy.pac file (which IE decided to call wpad.dat and who can forget an IE5 version that called it WPAD.DA?)
Picking on Linux users is disingenuous - all OSs can be customized to the point of tricky to support and besides who on earth is Twitter?
by gerdesj
6/7/2026 at 7:57:36 PM
I guess compatibility hell is why Linux will never go mainstream. Users like their favourite apps just working on their favourite OS.It’s not a great experience if only some apps on supported on your favourite Linux distro while others aren’t.
by bazmattaz
6/7/2026 at 4:44:41 PM
[flagged]by ai_slop_hater
6/7/2026 at 3:26:40 PM
Flatpak mostly solves this for GUI apps.by seabrookmx
6/7/2026 at 3:31:41 PM
It does not. You just get more vocal angry customers who hate Flatpak and hate you for using it.by Aurornis
6/7/2026 at 3:50:07 PM
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.
by Normal_gaussian
6/7/2026 at 4:06:19 PM
> 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.
by Aurornis
6/7/2026 at 4:17:24 PM
This is when you say "We support Ubuntu", and honestly that's fine.by tormeh
6/7/2026 at 4:31:35 PM
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.by trumpdong
6/7/2026 at 7:11:30 PM
You start with 'no', but rather than disagree, you've effectively restated my comment.I wasn't looking to anger you, just to provide a different lens in which to view the situation.
by Normal_gaussian
6/7/2026 at 3:36:43 PM
Can confirm, I hate flatpakby asveikau
6/7/2026 at 4:31:31 PM
Why?by Loeffelmann
6/7/2026 at 4:52:48 PM
I'm not the one who hates flatpak, but I will point you to this comment a little further up: https://news.ycombinator.com/item?id=48435993Flatpak 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.
by jm4
6/7/2026 at 7:05:44 PM
> 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.
by DaSHacka
6/7/2026 at 10:28:18 PM
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.
by badsectoracula
6/8/2026 at 12:33:42 AM
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.by asveikau
6/7/2026 at 6:59:23 PM
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.
by NotPractical
6/7/2026 at 5:00:08 PM
https://news.ycombinator.com/item?id=48434436#48435801Made comment about flatpack below the comment above.
by aaddrick
6/7/2026 at 3:03:36 PM
> The main reason must companies don't publish Linux electron appsBut they do? Companies don’t publish anything BUT electron apps. If desktop Linux gets anything from outside of FOSS, it’s electron. See Spotify, discord, slack, vscode… list goes on. I don’t think a for profit company has provided a GTK or qt app for Linux in the last 20 years.
I applaud your efforts but this is a supposed trillion dollar company with a product that probably has thousands of electron apps in its training set. They should be paying you.
by WD-42
6/7/2026 at 3:19:43 PM
Electron apps don’t work well across all of the Linux distributions if you’re doing anything that isn’t very simple.The comment was that the Electron apps aren’t being released for Linux even when they exist because Linux is so much harder to support, even in Electron.
If they don’t have resources (or desire) to keep the Electron app working on all the Linux distros then they definitely won’t have the resources to write a completely separate GTK app for the few Linux users.
by Aurornis
6/7/2026 at 3:59:08 PM
Anything that isn’t very simple? Like a llm chat interface? If zoom and Microsoft Teams of all people can do it, anthropic should be able to.Have you considered that maybe their code is just bad?
by WD-42
6/7/2026 at 4:23:51 PM
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.
by thewebguyd
6/7/2026 at 5:32:36 PM
According to the latest SO dev survey Ubuntu has 28% market share among developers. Considering coding seems to be the one place LLMs have found product market fit, I’m not sure how you can make the argument that the market share is too small. For other companies, absolutely. For ones marketing towards developers, seems like a mistake.by WD-42
6/7/2026 at 5:46:52 PM
How many devs use or would use a GUI app vs. just claude code in the terminal? My guess is not too many.I personally think they should port it, but, the developer product does already run on Linux, in the terminal, as is the case with the majority of other dev tools.
by thewebguyd
6/7/2026 at 10:00:41 PM
Using a largely-stock Ubuntu desktop for work the past 6 years, Zoom has also been one of the most broken mainstream apps I've every used on any system ever. I appreciate they provide a native Linux option, but it has consistently been barely functional—often fully unusable to where I'd join important calls from the browser instead.by macNchz
6/7/2026 at 6:20:20 PM
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.by mastax
6/7/2026 at 6:29:28 PM
I assume it would be chrome debug, and their chrome plugin, like it is on macos and windows. They could punt arbitrary app control easily enough.by eggnet
6/7/2026 at 4:09:18 PM
[dead]by redsocksfan45
6/7/2026 at 9:58:03 PM
> I don’t think a for profit company has provided a GTK or qt app for Linux in the last 20 years.DaVinci resolve is QT. But making a video editor performant in Electron is even harder than writing it in C++..
by 05
6/7/2026 at 4:11:34 PM
There's a similar project for Codex Desktop: https://github.com/ilysenko/codex-desktop-linux.After going through this process to get codex installed on Linux I'm honestly baffled why OpenAI doesn't have an official port. Though I haven't tested every part of the app, everything works as intended, even got computer use working without any issues.
by _fat_santa
6/7/2026 at 3:30:29 PM
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.by seabrookmx
6/7/2026 at 4:16:04 PM
I've looked on the rare occasion, but no one is asking for it on the repo, so hadn't been a priority like other distribution channels.It's great that I can ship one item for all platforms, but Flatpack doesn't solve the compatibility discovery problem for me.
More context in my reply to the comment linked here :https://news.ycombinator.com/item?id=48434436#48435661
by aaddrick
6/7/2026 at 8:30:22 PM
Just put some instructions on your website telling the user what to type into their shell? If they can't handle that, I guess it's the browser client.by petre
6/7/2026 at 1:56:10 PM
Still mess it up*Swipe keyboards on mobile are awful, but I can't break that habit.
by aaddrick
6/7/2026 at 3:04:02 PM
We have basically achieved AGI, but typing on mobile is still an unsolved problem. GBoard's dictionaries for Czech and Polish are still missing many usual declensions...by tasuki
6/7/2026 at 6:12:43 PM
> We have basically achieved AGIWe haven’t.
by kskdkwjdkwkkds
6/8/2026 at 1:20:58 AM
You’re absolutely right!by notai
6/7/2026 at 3:54:54 PM
The old minuum keyboard was fantastic; now I'm forced to use a swipe keyboard I'm constantly making mistakes - but at least its faster than pecking.by Normal_gaussian
6/7/2026 at 2:09:10 PM
For future reference: you can edit posts for up to 2 hours.by Kye
6/7/2026 at 3:53:48 PM
Is that not karma gated?by Normal_gaussian
6/7/2026 at 11:32:54 PM
It's been so long I have no idea what the karma thresholds are so this is possible.by Kye
6/8/2026 at 9:22:48 AM
I had a little search this morning, and I think I was wrong and you're right. 2h edit/delete when you have no replies.by Normal_gaussian
6/7/2026 at 2:05:00 PM
Nice, you have RPMs and DEBs in a remote repo we can add! Thanks for making it so easy to use :-)Also, I can't break the swipe keyboard habit either. It's the worst, but still better than the alternatives. Someday I hope physical keyboard makes a return (but I"m not holding my breath)
by freedomben
6/7/2026 at 4:32:21 PM
You're welcome!by aaddrick
6/7/2026 at 1:59:40 PM
If OpenCode can do it, then Anthropic can do it.by roryrjb
6/7/2026 at 8:37:08 PM
Wouldn't Flatpak be a solution to many of those problems? Develop the app against one Window Manager / Desktop environment and have them as requirements of the Flatpak?by cl3misch
6/7/2026 at 9:07:48 PM
Flathub has banned any software developed using AI or which is «ethically questionable».I’m pretty sure that excludes Claude Desktop.
https://www.techtimes.com/articles/317463/20260531/flathub-a...
by josteink
6/7/2026 at 7:04:12 PM
> The main reason must companies don't publish Linux electron apps is fragmentation.Unfortunately they do, instead of implementing a proper native application (don't hire web developers to do native apps).
Look at e.g. Cisco Webex, or Telegram. You can make a proper native application that just works and is not electron. A lot of people don't like electron apps, and it is more important in current economy (memory prices are too high to invest in more RAM).
by krzyk
6/10/2026 at 9:18:10 PM
Thanks for this. What are the downsides of using your build vs a hypothetical one from Anthropic?by MaxHodler
6/7/2026 at 2:37:51 PM
Biggest problem with Linux apps - i.e. distributed with ease the way that Windows and macOS apps are distributed, is the lack of a stable ABI. If you asked me about this 20 years ago I'd say in 2026 there'd for sure be a stable ABI, but no.by sgt
6/7/2026 at 3:38:20 PM
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."
by seabrookmx
6/7/2026 at 4:20:36 PM
My reply to the comment below outlines the shape of the problem.by aaddrick
6/7/2026 at 5:10:36 PM
Agreed - it's not the flatpak itself, it's that whole fragmented ecosystem. And unstable ABI doesn't help.by sgt
6/7/2026 at 2:54:04 PM
The stable Linux ABI is Win32 provided by Wine.by est31
6/7/2026 at 6:47:19 PM
[dead]by preg_match
6/7/2026 at 3:31:47 PM
This isn’t an issue in practice because the software running on Linux is open source. Yes if you want to distribute proprietary binary blobs and have them work forever it’s going to be a challenge, but in that case better to stick with the binary blob operating system.by WD-42
6/7/2026 at 5:10:10 PM
There's plenty of software running on Linux that is not open source, though.by sgt
6/7/2026 at 5:34:39 PM
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.
by WD-42
6/7/2026 at 7:55:58 PM
Tons and yeah of course some are also Electron apps but not all... Proprietary apps I can think of include Chrome, Teams until a few years ago (I think they just gave up), Steam, the JetBrains IDE's, Cursor, Discord, Matlab, ...Of course a lot of Linux users these days just live their lives through browsers. That's pretty sad.
by sgt
6/7/2026 at 8:38:28 PM
Chrome: Is electron without electronTeams: Was electron
Steam: Valve is deeply invested in Linux, this isn't them just shipping an app. Different category.
Jetbrains: Java
Cursor: Electron
Discord: Electron
Matlab: Java
ABI compatibility doesn't matter for any of your examples.
by WD-42
6/8/2026 at 6:48:42 AM
> Different categoryIsn’t Steam mostly webviews though ?
> Java
Well.. It’s not that massively different from running Qt apps in Gnome, though?
> ABI compatibility
I’m sure it matters for Swing to an large extent. Of course it the problem of the people developing the UI framework rather than the end app
by wqaatwt
6/7/2026 at 6:27:56 PM
I know they don't do it due to fragmentation, but things like appimage do exist.by giancarlostoro
6/7/2026 at 6:48:12 PM
Genuine question: how does that help?by lowbloodsugar
6/7/2026 at 9:33:36 PM
I've used various Linux distros, and if I see an appimage, I usually download those, and they usually just work.Apparently Linus Torvalds liked AppImage too.
by giancarlostoro
6/7/2026 at 5:47:16 PM
> The main reason must companies don't publish Linux electron apps is fragmentation.flatpak!
by Levitating
6/8/2026 at 1:04:59 AM
I have used it from the beginning. It's 100% functional.by DrFritz2
6/7/2026 at 4:37:33 PM
Sounds like a job for a more capable LLM than Opus.by orhmeh09
6/7/2026 at 2:48:13 PM
I have been running Claude Desktop on Linux via the unofficial Debian build for months and it is solid. The unofficial repo at github.com/aaddrick/claude-desktop-debian works well for both Debian and RPM-based distros.That said, an official build would make a huge difference for enterprise adoption. Many companies have policies against unofficial packages, and the signing + update mechanism is always going to be more trustworthy when it comes from Anthropic directly.
For anyone waiting: the unofficial build is perfectly usable for personal projects. But I would love to see Anthropic prioritize this -- the Linux developer community is exactly the audience that pushes Claude the hardest.
by jkwang
6/7/2026 at 9:58:56 PM
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.Of course, it's impossible to know for sure what was LLM processed or not, but most of your posts are getting classified that way.
You obviously have good points to make and are welcome here! but if you'd please write text by hand which you plan to post to HN itself, we'd appreciate it. The community feels strongly about this right now.
by dang
6/7/2026 at 11:34:31 PM
I do not know what fraction of LLM-processed messages are due to posters not being confident in their written English. To the extent that it is meaningful, we cana) be welcoming and indicate that we're OK with broken English (content and intent typically do get through), and/or
b) allow posting in languages other than English (does this even work right now?).
Above probably ahead of its time, but thought I'd just make the suggestion.
by dsubburam
6/8/2026 at 3:34:51 AM
I doubt that we'd do (b) (though maybe? who knows) - but I agree completely with (a)!by dang
6/8/2026 at 1:37:11 AM
I appreciate it! Glad it's working for you.I'll be happy the day there's an official distribution and I can put the repo to rest
by aaddrick