Comment by aaddrick
4 hours ago
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.
> 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.
Yeah. I just dropped another repackaging repo for Wispr Flow. https://github.com/wispr-flow-linux/wispr-flow-linux
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.
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.
11 replies →
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.
On systemd, you can use ~/.config/environment.d to set it. Don't rely on your shell.
> they’re running an unknown distribution on a 13 year old ThinkPad.
"Tony Stark can do it in a cave! With rocks!"
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.
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.
2 replies →
> Did you hire a Linux release engineer
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.)
This does feel like the perfect setup for Claude though.
Much easier to create a vm testing swarm of 100 disitributions with llms
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.
It's mostly dealing with different backends\compositors\etc.
My reply to the comment below outlines the shape of the problem.
https://news.ycombinator.com/item?id=48434436#48435801
Just ship a flatpak?
[flagged]
Flatpak mostly solves this for GUI apps.
It does not. You just get more vocal angry customers who hate Flatpak and hate you for using it.
7 replies →
https://news.ycombinator.com/item?id=48434436#48435801
Made comment about flatpack below the comment above.
> The main reason must companies don't publish Linux electron apps
But 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.
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.
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?
5 replies →
[dead]
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.
Still mess it up*
Swipe keyboards on mobile are awful, but I can't break that habit.
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...
> We have basically achieved AGI
We haven’t.
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.
For future reference: you can edit posts for up to 2 hours.
Is that not karma gated?
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)
You're welcome!
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.
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
> The main reason must companies don't publish Linux electron apps is fragmentation.
flatpak!
If OpenCode can do it, then Anthropic can do it.
Sounds like a job for a more capable LLM than Opus.
[flagged]
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.
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."
My reply to the comment below outlines the shape of the problem.
https://news.ycombinator.com/item?id=48434436#48435801
1 reply →
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.
There's plenty of software running on Linux that is not open source, though.
1 reply →
The stable Linux ABI is Win32 provided by Wine.