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.
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.
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)
> There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distros
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.
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.
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.
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.
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.
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.
> I don't know what the 'super' key in GNOME is, and don't care
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.
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?
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.
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?
<attenborough>
In this thread, we witness the irony of Linux advocates telling people to use the Windows key.
</attenborough>
I'm extremely experienced using and developing for Windows (and earlier) platforms, but it's true that I've never used a Linux machine before. I'm taking the opportunity to deliberately set one up and use it with Claude Code's help, in order to understand where the remaining sharp edges are, as well as the remaining dull ones. Desktop UX definitely qualifies as one of the latter.
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.
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.
> 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 somewhere
You 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.
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."
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.
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.
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.)
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.
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.
> You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality
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 :-)
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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...
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)
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.
> 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).
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."
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.
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.
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.
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.
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.
I didn't say that they _couldn't_, but it clearly isn't a priority for them. They still have the same opportunity cost any other engineering team faces.
They can work on feature X or feature Y -- which is the better choice?
Apparently they don't think Linux support is significant. I doubt the lack of support is due to technical constraints.
Use the existing Slop they have that needs 1GB of Ram for a simple Terminal app to create an even more slopped Linux app... If only they had any devs at their 500K and way up pay package that could actually write a simple app, that you know does not suck.
Torment doomers claim that the commodification of humanity’s suffering will usher in a dark age, but quarterly earnings have never been higher. I trust that Death Star Inc has humanity’s best interests at heart.
TBH I don't get the narrative there either. Earlier it was about how regular people can now build many types of software for themselves (and btw, I agree with this), but somehow the narrative has shifted to something like "regular software engineers would work with the customer to develop applications", which makes a lot less sense.
I don't think the CLI offers daily routines under the Anthropic subscription anymore?
There's also the cross conversation memory search, which uses a different conversation dataset (the Claude Web / Claude.AI conversations) than Claude Code does. I'm not even sure Claude Code does cross conversation search?
The Desktop interface also presents Markdown as formatted text and presents artifacts (especially interactive ones) better than the CLI can.
All that said - I actually use the CLI for nearly everything (even on Windows). Rather than use Claude Desktop for daily "routines" that are capped at 15 total cron-jobs and use extra usage credits, I think I'll continue building my own minimal harness and move my routines to models from other providers.
> I don't think the CLI offers daily routines under the Anthropic subscription anymore?
It (Claude Code) does, I discovered it by accident recently, having never used daily routines before. Haven't touched Claude Desktop at all, outside of playing with it for 30 mins or so months ago.
TLDR: I used Claude Code to build a command that scrapes job postings from a few employers I am interested in (it is a bit more complicated than that, but that's the gist). At the end CC asked me "do you want me to re-run it daily?" I said yes, and it generated a daily routine and gave me a URL to my anthropic account page where I can see all my daily routines.
There, it says that I am currently using up 1 out of 15 "free" daily routines that come with my personal subscription, and I would have to pay extra if I want to have more than 15 active at a time (I assume by switching to per-token pricing for anything beyond 15, but not sure).
> All that said - I actually use the CLI for nearly everything (even on Windows).
I also haven't touched routines, but I use cc to write automation tasks that will integrate a model when I need an inference layer. Which I also did before routines..
Have people actually been using routines effectively?
> There's also the cross conversation memory search, which uses a different conversation dataset (the Claude Web / Claude.AI conversations) than Claude Code does. I'm not even sure Claude Code does cross conversation search?
This is one of the first things I “fixed” with skills and hooks. I index every conversation in SQLite and have a skill which knows what to do when I ask it to search the index. I had to avoid the word memory because it’s too tied up in other parts of the context. It even indexes across my different machines. I set this up because I have terrible context discipline. I’ll go off on a tangent in one context and start planning and sometimes implementing something based on that thread which really deserves its own context. Afterward I can create the new context and move relevant bits to it, but I’d lose that initial starting conversation which inherently has more data than the summary in the new context.
I also use a few different related contexts. One where I’m building a game engine in zig and another talking about game ideas. There’s a lot of back and forth going on there which needs some shared context. I solve this with a combination of Claude.md references and that searchable session index.
Everything I do with scheduled tasks are just wired up with systemd and simple scripts. No LLM in the critical execution path. Again a skill tells CC how I manage those scheduled things so I just have to say something like “run this every day at midnight” and CC has reliably taken care of the rest.
What do people do with these? I don't use Claude but when I did I couldn't think of anything useful to do with the routines. I'm probably not being imaginative enough.
At work, I have my Claude set up to go through the issue tracker, source control, dashboards, team Slack channels, calendar appointments, and have it look for things like upcoming scheduling issues and deadlines that might get tough. A lot of those services need a corporate VPN or access to my local machine for the LLM to get the information right.
Nothing I can't do myself (and generally I do keep an eye on that sort of thing), but it did catch a holiday for my foreign team members that seemed to have gone unnoticed, and remarked about a status mismatch between Jira and source control that made the dashboard misrepresent progress. It's not much, but it's an extra little check that works quite well.
Another trick I'm experimenting with is having Claude rebase my open PRs waiting for review every day, and auto-solving conflicts when they arise. I don't trust it enough to let it push code to the repository, but I think I have the prompt set up in such a way that I might soon start using it.
While not trying to recreate the infamous dropbox comment - if you already have Claude code, are on Linux - can't Claude write a cronjob/systemd task that invokes itself for you?
I could write a program that does this of course, but interpreting the current state of Slack threads is not something a Python script will be able to do without involving another LLM. I automated and script what I need or want to automate and script already, but for things like this where understanding of language is useful, I leave it to the slop machine.
Things like "this is a holiday in country X but only for people living in province Y except for in town Z" are massive pain to script. Plus, if the issue tracker and source control automation were working correctly, I wouldn't need to read the status of both to get a good understanding of the situation. Any time scripting there should probably be spent (by someone else) on fixing the problem in the first place.
When Claude eventually doubles or triples the token cost to stop hemorrhaging money, I'm going to lose these scripts and I won't be upset about it in the least. But until then, my "somewhat understanding of context" script-but-not-really setup is proving quite useful.
0 8 * * 1-5 claude -p "Fetch my unread emails from the last 24 hours, identify urgent items, and provide a bulleted summary." >> ~/desktop/daily_email_summary.txt
(Courtesy of Gemini, not Claude code, as I'm on my phone).
Now, obviously - you might want something a little more elegant; but my point was that if you already grant Claude tool access to your email, slack etc - then it should be trivial to wrap it in a script, and run that from Cron.
I wouldn't do that; I don't trust Claude code with access to my mail (nor would I trust Claude desktop - but I don't use it anyway).
But, if you do trust Claude to read your slack and email, I don't see why Claude code couldn't do this for you almost out of the box?
Cowork is pretty useful for non-technical folk for things you'd traditionally just write a quick little bash or python script for (which really, is what Cowork is doing behind the scenes anyway).
I've gotten good results using it at work for keeping track of expense receipts. I dump them into an "Inbox" folder and Claude will OCR them, convert any images to PDF, rename, and move them into year/month/date folders and classify them (cost centers, based on a mapping and examples I gave it). This runs daily, checking the Inbox directory for new items.
My next step is getting it to pull them from my email automatically for me as well, or from a specific alias so when I take a pic of a receipt on the go I can just email it and have Claude rename and organize it for me, then it all gets sent off to AP at the end of the month.
Non technical knowledge workers have all kinds of little admin tasks like that which Cowork can do for them, where previously they lacked the skills or will to just learn some python and script it themselves.
I’d like the thing to read my mail twice a day and tell me if I missed something important.
Haven’t set it up because I’m horrified by the thought of it reading my mail. Doubly so if it decides to do anything other than telling me if I missed something important.
> Multiple projects/isolated memories in the same folder
I cannot stand this and do not know how to start a new project/session in a new folder. Even if I select a new folder in the UI when typing the first prompt of a new session, it keeps going back to the first folder I created. For this reason alone I am thinking of going to the CLI. But if anyone has any answers, I am all ears.
Mainly: true sandbox separation. I don't want the model having full access to my machine. With a dump format that Claude understands, I'm able to pass only the files I want Claude to see, and he can't break any of them. I don't care about setting up access lists and so on. I don't trust that the cli product will be properly sanboxed and it's quite clear their software offerings are largely aigen code, and I catch bugs from Claude every day. I also get useful stuff, so it's worth it, but definitely not worth it, imo, to grant it any access to my machine.
As a jai and linux user, myself, looking at nono's os-sandbox (from here [1]) it seems nice too. Thanks for the recommend I was looking for something that might be nice on Mac and nono seems good to recommend to coworkers and the like.
Jai is not written by ai, but only its website is. It's written by a Stanford Computer-Science professor with decades of C++ and Unix/linux experience.
> [1]: Was jai written by an AI coding agent?
No. While this web site was obviously made by an LLM (ChatGPT read the man page, asked some follow-up questions, and produced a prompt from which claude code built a vitepress site), jai itself was hand implemented by a Stanford computer science professor with decades of C++ and Unix/linux experience. As an experiment, the author did previously try vibe-coding a container, but the results were disastrous and repeatedly put his machine in a state that required a reboot (e.g., recursively changing the attributes of all mounts in the wrong mount namespace). The author does use coding agents to look for bugs, get feedback, and develop tests. However, rest assured that a single human understands every line of C++ in jai.
I've been using jai [1] for sandboxing on linux (although I use opencode and local models and not claude code) and I'm pretty satisfied with it. It comes in three different modes [2]: casual mode, strict mode, and bare mode. Here's some descriptions of each mode:
Casual mode [3]:
> Your home directory is mounted as a copy-on-write overlay. The jailed process sees your real files, but writes go to $HOME/.jai/default.changes instead of modifying originals, except in the directory where you ran jai.
Your current working directory grants full read/write access to code in the jail (unless suppressed with -D). So files deleted there are really gone.
/tmp and /var/tmp are private.
The rest of the filesystem is read-only.
Strict mode [4]:
> The process runs as the unprivileged jai system user, not as you.
Home directory is an empty private directory at $HOME/.jai/<name>.home.
Granted directories (via -d or cwd) are exposed with id-mapped mounts — files look like they are owned by jai inside the jail.
Because the process has a different UID, it cannot read files outside your home directory that are only accessible to your user — this is where confidentiality comes from.
Bare mode [5]:
> Home directory is an empty private directory, like strict mode.
But the process runs as your user, not as jai.
This means it cannot provide confidentiality — the process can still read any file accessible to your UID outside the home directory.
I've always ran my stuff in casual so far just so my whole computer doesn't get rimraffed :P. but I'm thinking of switching to just strict mode, but haven't really vibe coded in a while so I haven't tried it yet.
I made myself a very simple one from the start when I realized it can access everything on my computer https://git.jeena.net/jeena/agent-container my goal was that it would work transparently and the paths and user, etc. would be just the same as on the host but inside of a docker container.
What's the market for linux users who want an electron app so they can vibecode in a visual studio fork but wont just build it themselves nor do they want to clone and build someone else's repo
Not sure, but I would happily take half the pay of any developer at Anthropic to do that role for them if it gets me Claude Desktop on my Linux box, I do not like third party hacks of Windows Electron apps made to work on Linux, always makes me uncomfortable.
No horse in this race because I don’t want a Claude app, but the median Linux user is increasingly just a normal person who doesn’t want spying telemetry or ads or whatever
I avoided it after Anthropic's rampage against `claude -p` to stop Openclaw and didn't want to get hit in the crossfire. It was hard to follow their back and forth, but it seems that's done now?
I don’t really care about the OS. I want a beefy laptop with a good keyboard and trackpad, long battery life, and a crisp screen. Preferably very silent, bonus points for a clean design. That’s the value proposition of a MacBook.
Why would you not want your development environment to be as close to your deployment environment as possible? Even MacOS bash commands have hiccups every so often. In my experience working with Linux developers, they seem to know the internals of the servers much better and can optimize/debug prod fast - and this understanding is only compounded with LLMs.
I'm sure many developers would be equally talented at debugging such issues if we deployed on Windows or MacOS, but virtually no one does that.
Personally I don’t understand why Claude Code doesn’t have a mode to make text green and characters come down from the top of the screen individually, like in The Matrix.
OK, just please be careful how you frame what you're asking for.
For software development use of Claude, I'd be happy if the `claude` CLI executable does everything I need, within the Linux KVM VM sandboxes I create for the work, without a desktop client. The cleaner and more trustworthy, the better.
Also, for random interactive use of Claude for asking questions, I use it from my host desktop, sandboxed within the Web browser, and I want that to be well-supported. Someone marketing/product person at an AI company will naturally want to dark-pattern push people towards a proprietary desktop client, but that's one corner of abuse potential that we can still keep in check.
For agentic automation of my host desktop things and the things they have access to... no, thank you, the state of the art is not ready for that.
Lame, I know, but you have to entertain yourself sometimes when the only thing anybody talks about here is ruddy spicy autocorrect and self-inflicted job destruction.
This sounds like a really good test for agentic coding and something Anthropic should seriously consider doing as a proof of Claude Code quality. They could easily have agents built per Linux distribution that will run on every new release and do complete testing and publishing. IF they can successfully do that it would be a nice marketing as well. :)
YES! But also hmm, maybe not. I literally installed the unofficial build[0] a few hours ago, and when I started it and saw a bunch of Electron processes immediately trigger my spawn swarm detector, I just closed it. Don't think I'll ever touch it again.
That's me, and that sounds weird. Mind giving stone more details so I can help get to the source of it? Or just submit an issue on the repo. Should just be one main electron process.
I find Claude Desktop on macOS infinitely better at managing RAM when you have 10+ or more parallel sessions.
(Some for different aspects of full stack features, some for managing specific client situations advised by the codebase and its tools!)
The CLI is not designed to be lightweight, and it’s easy to get into situations where every CLI session consumes multiple GB of memory alone - stack them up and it’s a lot!
And not all terminal GUIs handle multiple tabs well enough to see all sessions at a glance.
So on top of the plugin features, desktop is a really useful thing to have!
So yes, it's a TUI... but it's a TUI rendered by Ink, a React library, with a full JS runtime in the background. The number of re-renders per unit time involved with rerendering a JS implementation of flexbox every new token comes in? That's not a walk in the park for a garbage collector, and a single memory/retention leak can cascade dramatically.
I imagine this is part of the impetus behind the Bun acquisition - they have a deep need to push optimization efforts towards the specific patterns that are most relevant to their use cases. (Which are probably good ones for the broader Bun userbase, to be sure, but relative prioritization is something they now have greater control over.)
This is like begging Microsoft to port SQL Server to Linux. Anthropic is a proprietary walled garden with poor service trading solely on dominance in a single product field, just like Microsoft with its business tools. Yet people are clamoring to become more dependent on them. Those same complaints you hear from Windows users today? Will be the complaints from Claude users in the future. No choice but to put up with it. What else are you gonna do, learn to use Codex? Your company won't pay for it because the users prefer the one tool they already know how to use. Funny how history repeats itself.
Not exactly Claude Desktop but we have something more "generic" that works across multiple OSes (written in Tauri) - Msty Claw [1]. It also comes with a companion E2E encrypted mobile app.
You build it for Ubuntu , people will demand fedora. Build fedora they’ll want Arch.
This is fine for FOSS projects where the community can fork and contribute, but as a company I can imagine tons of support tickets coming from Linux users who’s particularly DE/Distro permutation isn’t working right.
So your argument is "if you give a mouse a cookie"? There are plenty of companies and they just throw us a deb and we do the rest.
And even if it were a valid point, why would eye even waste a second of your life argumenting against Linux when it's being asked to a company with a projected 1 trillion dollars IPO.
Yeah that would be great. I seriously don't understand how a company with this much money doesn't have some of the more basic ux implemented to make it a really great app. Blows my mind.
Anthropic, if you're reading this: I'm a developer trying to figure out LLMs, I use them 8h per day to do my work. Claude Desktop is a missing piece I don't have access to because I'm only on Linux! I'm happy with a simple AppImage.
Yeah nah it's yet another security risk.
There was an article recently about Claude Code desktop installing some browser files, it wasn't a hole per-se but doesn't make the whole thing trustworthy.
I no longer know if this is a real person who is simping for Anthropic and will be ultimately enslaved by Anthropic or if this is an Anthropic ad to have "proof" for the high demand of their services.
Interesting take away, but one that I'd think is intrinsically wrong.
The Linux desktop is fragmented and gatekept in such a manner that most people of a reasonable mind aren't going to waste tokens on it, and damned sure not going to waste software/support engineer time on it.
Note that none of these complaints are about CLI or server software. "Linux" the kernel + GNU utils + shell handle all of this just fine. The year of the Linux desktop is just never going to happen unless one desktop standard takes over and 'wins' in the short to medium term.
Now, in the longer term when tokens run cheap maybe we'll successfully have 20 different competing, incompatible Linux deskstops, but it doesn't seem likely.
Inded. But... Let's say by compiling for Windows and MacOS you are making it work on 80% of users' computers. Then you compile on an older Ubuntu version which will work on any newer Ubuntu or Debian system, and you're at 90%. Worth doing. Then you do a Centos/RH build to get to 95%.
This won't work for all Linux users, but that doesn't have to be the bar. Making a few linux builds for the most popular distros is incrementally better than saying it's Windows/Mac only.
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.
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)
> There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distros
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.
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.
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.
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.
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.
Did you try pressing the super key
> 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.
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.
> I don't know what the 'super' key in GNOME is, and don't care
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.
You might be happier with a consumer OS.
Oh please. The super key is the windows key. You come across as someone who has never used a computer before.
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?
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.
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?
You come across as someone who’s never talked to a normal human being
<attenborough> In this thread, we witness the irony of Linux advocates telling people to use the Windows key. </attenborough>
I'm extremely experienced using and developing for Windows (and earlier) platforms, but it's true that I've never used a Linux machine before. I'm taking the opportunity to deliberately set one up and use it with Claude Code's help, in order to understand where the remaining sharp edges are, as well as the remaining dull ones. Desktop UX definitely qualifies as one of the latter.
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.
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.
> 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 somewhere
You 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.
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."
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.
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.
> 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.)
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.
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.
> You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality
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.
Show me the part of the GPL which forbids you from shipping compiled binaries.
> 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 :-)
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.
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.
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 untested
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.
:)
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
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.
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.
> they’re running an unknown distribution on a 13 year old ThinkPad.
"Tony Stark can do it in a cave! With rocks!"
This does feel like the perfect setup for Claude though.
Much easier to create a vm testing swarm of 100 disitributions with llms
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.
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.
Just ship a flatpak?
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.
The sad part is, that those people usually think, they help linux this way.
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.
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.
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.
This is when you say "We support Ubuntu", and honestly that's fine.
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.
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.
Can confirm, I hate flatpak
Why?
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=48435993
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.
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.
> 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++..
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?
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.
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.
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.
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.
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.
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.
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?
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...
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
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.
> 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).
If OpenCode can do it, then Anthropic can do it.
I know they don't do it due to fragmentation, but things like appimage do exist.
Genuine question: how does that help?
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.
https://archive.ph/PSqlB
> The main reason must companies don't publish Linux electron apps is fragmentation.
flatpak!
Sounds like a job for a more capable LLM than Opus.
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
Agreed - it's not the flatpak itself, it's that whole fragmented ecosystem. And unstable ABI doesn't help.
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.
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.
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.
Chrome: Is electron without electron
Teams: 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.
The stable Linux ABI is Win32 provided by Wine.
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.
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.
If only Anthropic had some kind of automated tool that was good at porting software
Even if you can create infinite software you still have to be very intentional about what you’re choosing to work on.
There’s still a cost to testing, support, planning, etc even if coding is now “free”
Anthropic claims 8-fold productivity increase since 2025. If even that isn't enough to enable support for Linux, I don't know what it is.
I didn't say that they _couldn't_, but it clearly isn't a priority for them. They still have the same opportunity cost any other engineering team faces.
They can work on feature X or feature Y -- which is the better choice?
Apparently they don't think Linux support is significant. I doubt the lack of support is due to technical constraints.
If only Anthropic had some kind of automated testing, support, planning machine.
You wouldn't run an engineering company with 500 engineers reporting directly to the CEO.
AI doesn't solve this. You need humans who can understand and verify what is being made.
Not, according to their AI influencers
It doesn't sound like that's the bottleneck.
You forgot the *allegedly in there.
Imagine if cutting edge AI companies could decide to using their world best AI to
1) Develop software for linux
2) Provide decent support
If there were any truth to the marketing stories that say they have such a thing, then they could indeed.
It’s almost as if this whole productivity increase promised by AI is just marketing spiel, huh? Crazy.
Use the existing Slop they have that needs 1GB of Ram for a simple Terminal app to create an even more slopped Linux app... If only they had any devs at their 500K and way up pay package that could actually write a simple app, that you know does not suck.
Those highly paid human devs are hard at work on the Torment Nexus, which is their priority of course, you don't want China to win do you?
Torment doomers claim that the commodification of humanity’s suffering will usher in a dark age, but quarterly earnings have never been higher. I trust that Death Star Inc has humanity’s best interests at heart.
You’re asking too much.
Sorry that's not the use case anymore its about (checks notes) "forward deployed engineers", yep that's it. Go build!
TBH I don't get the narrative there either. Earlier it was about how regular people can now build many types of software for themselves (and btw, I agree with this), but somehow the narrative has shifted to something like "regular software engineers would work with the customer to develop applications", which makes a lot less sense.
What do you miss from the Desktop app that the CLI doesn’t cover? I’m mostly on Linux too and have just been using the CLI, so I’m curious.
I don't think the CLI offers daily routines under the Anthropic subscription anymore?
There's also the cross conversation memory search, which uses a different conversation dataset (the Claude Web / Claude.AI conversations) than Claude Code does. I'm not even sure Claude Code does cross conversation search?
The Desktop interface also presents Markdown as formatted text and presents artifacts (especially interactive ones) better than the CLI can.
All that said - I actually use the CLI for nearly everything (even on Windows). Rather than use Claude Desktop for daily "routines" that are capped at 15 total cron-jobs and use extra usage credits, I think I'll continue building my own minimal harness and move my routines to models from other providers.
> I don't think the CLI offers daily routines under the Anthropic subscription anymore?
It (Claude Code) does, I discovered it by accident recently, having never used daily routines before. Haven't touched Claude Desktop at all, outside of playing with it for 30 mins or so months ago.
TLDR: I used Claude Code to build a command that scrapes job postings from a few employers I am interested in (it is a bit more complicated than that, but that's the gist). At the end CC asked me "do you want me to re-run it daily?" I said yes, and it generated a daily routine and gave me a URL to my anthropic account page where I can see all my daily routines.
There, it says that I am currently using up 1 out of 15 "free" daily routines that come with my personal subscription, and I would have to pay extra if I want to have more than 15 active at a time (I assume by switching to per-token pricing for anything beyond 15, but not sure).
> All that said - I actually use the CLI for nearly everything (even on Windows).
I also haven't touched routines, but I use cc to write automation tasks that will integrate a model when I need an inference layer. Which I also did before routines..
Have people actually been using routines effectively?
> There's also the cross conversation memory search, which uses a different conversation dataset (the Claude Web / Claude.AI conversations) than Claude Code does. I'm not even sure Claude Code does cross conversation search?
This is one of the first things I “fixed” with skills and hooks. I index every conversation in SQLite and have a skill which knows what to do when I ask it to search the index. I had to avoid the word memory because it’s too tied up in other parts of the context. It even indexes across my different machines. I set this up because I have terrible context discipline. I’ll go off on a tangent in one context and start planning and sometimes implementing something based on that thread which really deserves its own context. Afterward I can create the new context and move relevant bits to it, but I’d lose that initial starting conversation which inherently has more data than the summary in the new context.
I also use a few different related contexts. One where I’m building a game engine in zig and another talking about game ideas. There’s a lot of back and forth going on there which needs some shared context. I solve this with a combination of Claude.md references and that searchable session index.
Everything I do with scheduled tasks are just wired up with systemd and simple scripts. No LLM in the critical execution path. Again a skill tells CC how I manage those scheduled things so I just have to say something like “run this every day at midnight” and CC has reliably taken care of the rest.
Why not just allow it to grep ~/.claude
For one thing, the Desktop app lets me control any remote sessions I have open via the Code functionality.
1. Same experience as my non-Linux coworkers, so we can share learnings and processes
2. Scheduled tasks that run locally ( https://support.claude.com/en/articles/13854387-schedule-rec... ) importantly different from Claude Code routines
3. Multiple projects/isolated memories in the same folder
4. Better UI
> Scheduled tasks that run locally ( https://support.claude.com/en/articles/13854387-schedule-rec... ) importantly different from Claude Code routines
What do people do with these? I don't use Claude but when I did I couldn't think of anything useful to do with the routines. I'm probably not being imaginative enough.
At work, I have my Claude set up to go through the issue tracker, source control, dashboards, team Slack channels, calendar appointments, and have it look for things like upcoming scheduling issues and deadlines that might get tough. A lot of those services need a corporate VPN or access to my local machine for the LLM to get the information right.
Nothing I can't do myself (and generally I do keep an eye on that sort of thing), but it did catch a holiday for my foreign team members that seemed to have gone unnoticed, and remarked about a status mismatch between Jira and source control that made the dashboard misrepresent progress. It's not much, but it's an extra little check that works quite well.
Another trick I'm experimenting with is having Claude rebase my open PRs waiting for review every day, and auto-solving conflicts when they arise. I don't trust it enough to let it push code to the repository, but I think I have the prompt set up in such a way that I might soon start using it.
While not trying to recreate the infamous dropbox comment - if you already have Claude code, are on Linux - can't Claude write a cronjob/systemd task that invokes itself for you?
I could write a program that does this of course, but interpreting the current state of Slack threads is not something a Python script will be able to do without involving another LLM. I automated and script what I need or want to automate and script already, but for things like this where understanding of language is useful, I leave it to the slop machine.
Things like "this is a holiday in country X but only for people living in province Y except for in town Z" are massive pain to script. Plus, if the issue tracker and source control automation were working correctly, I wouldn't need to read the status of both to get a good understanding of the situation. Any time scripting there should probably be spent (by someone else) on fixing the problem in the first place.
When Claude eventually doubles or triples the token cost to stop hemorrhaging money, I'm going to lose these scripts and I won't be upset about it in the least. But until then, my "somewhat understanding of context" script-but-not-really setup is proving quite useful.
I meant more like:
(Courtesy of Gemini, not Claude code, as I'm on my phone).Now, obviously - you might want something a little more elegant; but my point was that if you already grant Claude tool access to your email, slack etc - then it should be trivial to wrap it in a script, and run that from Cron.
I wouldn't do that; I don't trust Claude code with access to my mail (nor would I trust Claude desktop - but I don't use it anyway).
But, if you do trust Claude to read your slack and email, I don't see why Claude code couldn't do this for you almost out of the box?
Cowork is pretty useful for non-technical folk for things you'd traditionally just write a quick little bash or python script for (which really, is what Cowork is doing behind the scenes anyway).
I've gotten good results using it at work for keeping track of expense receipts. I dump them into an "Inbox" folder and Claude will OCR them, convert any images to PDF, rename, and move them into year/month/date folders and classify them (cost centers, based on a mapping and examples I gave it). This runs daily, checking the Inbox directory for new items.
My next step is getting it to pull them from my email automatically for me as well, or from a specific alias so when I take a pic of a receipt on the go I can just email it and have Claude rename and organize it for me, then it all gets sent off to AP at the end of the month.
Non technical knowledge workers have all kinds of little admin tasks like that which Cowork can do for them, where previously they lacked the skills or will to just learn some python and script it themselves.
I’d like the thing to read my mail twice a day and tell me if I missed something important.
Haven’t set it up because I’m horrified by the thought of it reading my mail. Doubly so if it decides to do anything other than telling me if I missed something important.
Some good ideas here: https://posthog.com/blog/making-claude-cowork-actually-usefu...
> Multiple projects/isolated memories in the same folder
I cannot stand this and do not know how to start a new project/session in a new folder. Even if I select a new folder in the UI when typing the first prompt of a new session, it keeps going back to the first folder I created. For this reason alone I am thinking of going to the CLI. But if anyone has any answers, I am all ears.
I would like to see the inline images that Claude suddenly tries to show me, until I remind them that I can't see images in the CLI.
Other than that, I am happy with the CLI.
The CLI is good for coding tasks but for other things non coding related, having the desktop app can be very useful
Mainly: true sandbox separation. I don't want the model having full access to my machine. With a dump format that Claude understands, I'm able to pass only the files I want Claude to see, and he can't break any of them. I don't care about setting up access lists and so on. I don't trust that the cli product will be properly sanboxed and it's quite clear their software offerings are largely aigen code, and I catch bugs from Claude every day. I also get useful stuff, so it's worth it, but definitely not worth it, imo, to grant it any access to my machine.
There are a number of utilities for this. I use jai: https://jai.scs.stanford.edu/ but also have seen nono: https://github.com/always-further/nono smolvm: https://github.com/smol-machines/smolvm zerobox https://github.com/afshinm/zerobox and matchlock https://github.com/jingkaihe/matchlock
They all have pros and cons. Pick the one that suits you best. Then you're also agent harness flexible (I use opencode).
As a jai and linux user, myself, looking at nono's os-sandbox (from here [1]) it seems nice too. Thanks for the recommend I was looking for something that might be nice on Mac and nono seems good to recommend to coworkers and the like.
[1]: https://nono.sh/os-sandbox
I would like a solution that was itself not largely written by an AI
Jai is not written by ai, but only its website is. It's written by a Stanford Computer-Science professor with decades of C++ and Unix/linux experience.
> [1]: Was jai written by an AI coding agent? No. While this web site was obviously made by an LLM (ChatGPT read the man page, asked some follow-up questions, and produced a prompt from which claude code built a vitepress site), jai itself was hand implemented by a Stanford computer science professor with decades of C++ and Unix/linux experience. As an experiment, the author did previously try vibe-coding a container, but the results were disastrous and repeatedly put his machine in a state that required a reboot (e.g., recursively changing the attributes of all mounts in the wrong mount namespace). The author does use coding agents to look for bugs, get feedback, and develop tests. However, rest assured that a single human understands every line of C++ in jai.
[1] https://jai.scs.stanford.edu/faq.html
The cli works on regular sandboxes just fine (podman, docker, bwrap, etc).
Sandboxing a GUI is typically more operational overhead than sandboxing a cli (mounting compositor sockets, GPU access, etc).
I've been using jai [1] for sandboxing on linux (although I use opencode and local models and not claude code) and I'm pretty satisfied with it. It comes in three different modes [2]: casual mode, strict mode, and bare mode. Here's some descriptions of each mode:
Casual mode [3]: > Your home directory is mounted as a copy-on-write overlay. The jailed process sees your real files, but writes go to $HOME/.jai/default.changes instead of modifying originals, except in the directory where you ran jai. Your current working directory grants full read/write access to code in the jail (unless suppressed with -D). So files deleted there are really gone. /tmp and /var/tmp are private. The rest of the filesystem is read-only.
Strict mode [4]: > The process runs as the unprivileged jai system user, not as you. Home directory is an empty private directory at $HOME/.jai/<name>.home. Granted directories (via -d or cwd) are exposed with id-mapped mounts — files look like they are owned by jai inside the jail. Because the process has a different UID, it cannot read files outside your home directory that are only accessible to your user — this is where confidentiality comes from.
Bare mode [5]: > Home directory is an empty private directory, like strict mode. But the process runs as your user, not as jai. This means it cannot provide confidentiality — the process can still read any file accessible to your UID outside the home directory.
I've always ran my stuff in casual so far just so my whole computer doesn't get rimraffed :P. but I'm thinking of switching to just strict mode, but haven't really vibe coded in a while so I haven't tried it yet.
[1]: https://jai.scs.stanford.edu/
[2]: https://jai.scs.stanford.edu/modes.html
[3]: https://jai.scs.stanford.edu/modes.html#casual-mode
[4]: https://jai.scs.stanford.edu/modes.html#strict-mode
[5]: https://jai.scs.stanford.edu/modes.html#bare-mode
If you don’t trust the CLI version to be properly sandbox d, why would the desktop one be?
I made myself a very simple one from the start when I realized it can access everything on my computer https://git.jeena.net/jeena/agent-container my goal was that it would work transparently and the paths and user, etc. would be just the same as on the host but inside of a docker container.
does claude desktop actually solve this issue? I’m on mac and use docker sbx to solve this https://docs.docker.com/ai/sandboxes/get-started/
On Linux you have bubblewrap!
Or, what does the Desktop app does that the webpage doesn't do?
Pasting images
What's the market for linux users who want an electron app so they can vibecode in a visual studio fork but wont just build it themselves nor do they want to clone and build someone else's repo
Not sure, but I would happily take half the pay of any developer at Anthropic to do that role for them if it gets me Claude Desktop on my Linux box, I do not like third party hacks of Windows Electron apps made to work on Linux, always makes me uncomfortable.
No horse in this race because I don’t want a Claude app, but the median Linux user is increasingly just a normal person who doesn’t want spying telemetry or ads or whatever
The median linux pc user is on Chrome OS from their school :p
I presume they meant if you filter out for Chrome and Android ;)
You got to love the irony of seeing hundred of users not being able to actually build a desktop version themselves using the cli agent.
Are LLMs rendering people that useless?
I avoided it after Anthropic's rampage against `claude -p` to stop Openclaw and didn't want to get hit in the crossfire. It was hard to follow their back and forth, but it seems that's done now?
Hard for one person to keep up with a product that ships updates multiple times a day.
Note “official” in the request… there are unofficial ones.
I'm still surprised at how many developers still turn their noses up at using Linux.
Like... You already use Docker and deploy to K8S... On Linux...
Desktop and server are two wildly different support surfaces
I don’t really care about the OS. I want a beefy laptop with a good keyboard and trackpad, long battery life, and a crisp screen. Preferably very silent, bonus points for a clean design. That’s the value proposition of a MacBook.
That’s very much not the same thing though?
It kind of is?
Why would you not want your development environment to be as close to your deployment environment as possible? Even MacOS bash commands have hiccups every so often. In my experience working with Linux developers, they seem to know the internals of the servers much better and can optimize/debug prod fast - and this understanding is only compounded with LLMs.
I'm sure many developers would be equally talented at debugging such issues if we deployed on Windows or MacOS, but virtually no one does that.
I do other things on my computer apart from bash.
Docker was designed for Linux, and on Windows you have to run a VM just to let Docker function.
Personally I don’t understand why Claude Code doesn’t have a mode to make text green and characters come down from the top of the screen individually, like in The Matrix.
Massively bugs me. I have to wear green sunglasses, change the language to Japanese, and turn my monitor sideways to get any real work done nowadays.
OK, just please be careful how you frame what you're asking for.
For software development use of Claude, I'd be happy if the `claude` CLI executable does everything I need, within the Linux KVM VM sandboxes I create for the work, without a desktop client. The cleaner and more trustworthy, the better.
Also, for random interactive use of Claude for asking questions, I use it from my host desktop, sandboxed within the Web browser, and I want that to be well-supported. Someone marketing/product person at an AI company will naturally want to dark-pattern push people towards a proprietary desktop client, but that's one corner of abuse potential that we can still keep in check.
For agentic automation of my host desktop things and the things they have access to... no, thank you, the state of the art is not ready for that.
The terribleness of VNC (vs RDP) is what gets you. A GUI client in that VM sucks to access. If it didn't, a GUI client wouldn't be easily rejectable.
So use RDP?
https://www.xrdp.org/
(Or x forwarding over ssh, or waypipie if you only need to access a gui application, not a desktop).
Just one-shot vibe it for yourself.
Lame, I know, but you have to entertain yourself sometimes when the only thing anybody talks about here is ruddy spicy autocorrect and self-inflicted job destruction.
> self-inflicted job destruction
Glad someone else sees this as well in this crappy website
This sounds like a really good test for agentic coding and something Anthropic should seriously consider doing as a proof of Claude Code quality. They could easily have agents built per Linux distribution that will run on every new release and do complete testing and publishing. IF they can successfully do that it would be a nice marketing as well. :)
YES! But also hmm, maybe not. I literally installed the unofficial build[0] a few hours ago, and when I started it and saw a bunch of Electron processes immediately trigger my spawn swarm detector, I just closed it. Don't think I'll ever touch it again.
[0] https://github.com/aaddrick/claude-desktop-debian
Hey!
That's me, and that sounds weird. Mind giving stone more details so I can help get to the source of it? Or just submit an issue on the repo. Should just be one main electron process.
Some more details*
I find Claude Desktop on macOS infinitely better at managing RAM when you have 10+ or more parallel sessions.
(Some for different aspects of full stack features, some for managing specific client situations advised by the codebase and its tools!)
The CLI is not designed to be lightweight, and it’s easy to get into situations where every CLI session consumes multiple GB of memory alone - stack them up and it’s a lot!
And not all terminal GUIs handle multiple tabs well enough to see all sessions at a glance.
So on top of the plugin features, desktop is a really useful thing to have!
What exactly is taking up so much space? Why does it need anything more than whatever the context is? Isn't it just sending text over an API?
So yes, it's a TUI... but it's a TUI rendered by Ink, a React library, with a full JS runtime in the background. The number of re-renders per unit time involved with rerendering a JS implementation of flexbox every new token comes in? That's not a walk in the park for a garbage collector, and a single memory/retention leak can cascade dramatically.
I imagine this is part of the impetus behind the Bun acquisition - they have a deep need to push optimization efforts towards the specific patterns that are most relevant to their use cases. (Which are probably good ones for the broader Bun userbase, to be sure, but relative prioritization is something they now have greater control over.)
I'm building a platform that does just that: https://yeet.cx/docs/
We give Claude full visibility into your Linux machine, with a JS runtime over the top for building tools.
Boris from the team here — we’re looking into it.
Thanks for dropping by. What has been your favorite part of building this tool so far?
This is like begging Microsoft to port SQL Server to Linux. Anthropic is a proprietary walled garden with poor service trading solely on dominance in a single product field, just like Microsoft with its business tools. Yet people are clamoring to become more dependent on them. Those same complaints you hear from Windows users today? Will be the complaints from Claude users in the future. No choice but to put up with it. What else are you gonna do, learn to use Codex? Your company won't pay for it because the users prefer the one tool they already know how to use. Funny how history repeats itself.
SQL Server does have a Linux version though lol
The ARM64 Linux version (Azure version actually) is what I run on my MacBook through docker when I need it for testing.
Not exactly Claude Desktop but we have something more "generic" that works across multiple OSes (written in Tauri) - Msty Claw [1]. It also comes with a companion E2E encrypted mobile app.
[1]: https://msty.ai/claw/features
Which Linux.
You build it for Ubuntu , people will demand fedora. Build fedora they’ll want Arch.
This is fine for FOSS projects where the community can fork and contribute, but as a company I can imagine tons of support tickets coming from Linux users who’s particularly DE/Distro permutation isn’t working right.
Still. An App Image would be nice
So your argument is "if you give a mouse a cookie"? There are plenty of companies and they just throw us a deb and we do the rest.
And even if it were a valid point, why would eye even waste a second of your life argumenting against Linux when it's being asked to a company with a projected 1 trillion dollars IPO.
What's your stake here?
The top comment large agrees with me. Your support matrix becomes too vast.
However, I do think an app image or I guess a flatpak would be nice.
I made a way to build Swift apps that build on Linux and run and look the same on MacOS https://github.com/Lore-Hex/QuillUI
I know Claude is electron now but if they made it native swift on macos then they could use this
Also can you please make it easy to switch between my work and personal accounts on mobile!
Yeah that would be great. I seriously don't understand how a company with this much money doesn't have some of the more basic ux implemented to make it a really great app. Blows my mind.
Anthropic, if you're reading this: I'm a developer trying to figure out LLMs, I use them 8h per day to do my work. Claude Desktop is a missing piece I don't have access to because I'm only on Linux! I'm happy with a simple AppImage.
Might as well say "Adobe, please ship an official creative suite for Linux", and will probably fall on the same deaf ears.
So true
>> Anthropic, please ship an official malware for Linux
Here, fixed it for you.
Our app, Runner: Cowork++
Supports linux :)
https://runner.now/
Cowork already boots Ubuntu 22.04 internally on macOS. The Linux execution path exists inside the product. What's missing is a published build.
How can they? They are busy designing agentic loops. They ship 8x more lines of code!!!
I thought going into ipo they were selling the idea that claude is already build claude.
Yeah nah it's yet another security risk. There was an article recently about Claude Code desktop installing some browser files, it wasn't a hole per-se but doesn't make the whole thing trustworthy.
Yes please! I think it's just kinda weird that this hasn't been done yet.
If you feel that strongly about it, why not write the issue description yourself?
Really.. I was scrolling to find a comment complaining for this slop GH issue, which should be 10% of the size of what it is.
Surprised me it took so much scrolling to get to this.
Like, who reads all that crap?
and make it free so we're not paying to be beta testers ;-)
"Sources for the load-bearing claims"
I no longer know if this is a real person who is simping for Anthropic and will be ultimately enslaved by Anthropic or if this is an Anthropic ad to have "proof" for the high demand of their services.
Neither, it is just a random LLM-generated issue.
It it was an LLM, why didn't it just vibecode the desired software instead of generating ticket spam?
Because using cheap LLMs to spam GH is way less expensive than fixing software with SOTA models.
I love the dueling messages on AI
"It'll make software easy and replace all software jobs!"
"Sorry, a Linux client is too hard and too much work!"
Interesting take away, but one that I'd think is intrinsically wrong.
The Linux desktop is fragmented and gatekept in such a manner that most people of a reasonable mind aren't going to waste tokens on it, and damned sure not going to waste software/support engineer time on it.
Note that none of these complaints are about CLI or server software. "Linux" the kernel + GNU utils + shell handle all of this just fine. The year of the Linux desktop is just never going to happen unless one desktop standard takes over and 'wins' in the short to medium term.
Now, in the longer term when tokens run cheap maybe we'll successfully have 20 different competing, incompatible Linux deskstops, but it doesn't seem likely.
Come on Linux is the terminal dominion for excellence! Claude Code in terminal all the way!!
We are all waiting for it.
Doesn't Wayland make it impossible anyway?
In what way?
In the way of eschewing all the APIs that allow an X11 client to control your desktop.
You're better off just using code cli
Why dont you ask Claude to write you a TUI ?
Why would they do that with their...checks notes...software changing AI?
Anthropic one-shotting a Linux distro would be quite the ad...
Perplexity are devleoping Comet as an AI-powered browser. I wonder if anybody will take the OS leap.
just use WINE or docker
> Just use WINE
Did you just tell me to go fuck myself ?
pull requests are welcome
"Linux" is not an operating system. One does not "just" release something "for Linux"
Inded. But... Let's say by compiling for Windows and MacOS you are making it work on 80% of users' computers. Then you compile on an older Ubuntu version which will work on any newer Ubuntu or Debian system, and you're at 90%. Worth doing. Then you do a Centos/RH build to get to 95%.
This won't work for all Linux users, but that doesn't have to be the bar. Making a few linux builds for the most popular distros is incrementally better than saying it's Windows/Mac only.
Please don't.
There is already way too much slop.
That will come the year after the year of linux on. The desktop /s