Anthropic, please ship an official Claude Desktop for 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.

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.

Honestly, it sounds like you guys need to learn to say no. Worked at an OEM and we had device divers for RHEL. If you got it working on something else, good for you. But if you wanted to open a support case, you better be able to reproduce the bug on a supported version of RHEL.

I would occasionally humor people running CentOS if I had some spare cycles, but if you were on Debian the answer was: sorry, would love to help but I can’t.

The people who can’t understand why you have a tight support matrix are the people you don’t want to get sucked into the rabbit hole with anyway.

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.

Much easier to create a vm testing swarm of 100 disitributions with llms

I dunno why this is always so difficult.

Maybe those same people can just prefer using OpenCode. It's at least free software, particularly if that old computer is running only free software with free firmware, and OpenCode can run free models.

Obviously this will probably fail on other distros, but I've found in the past similar groupings. Backwards compatibility is different: I expect a package a compile on Ubuntu 24 not to work on Ubuntu 22.

This is anecdotal, and in the context of rust + EGUI, so I'm not sure how applicable it is to Electron.

I recently hit a Wayland snag: It doesn't support Device Events other than mouse movement. I worked around it by changing to Window events. I could see that being annoying if this substitution weren't acceptable, but it was in this case.

"Tony Stark can do it in a cave! With rocks!"

Flatpak can be set up on many/most distros.

So get to grips with "upstream"! Managing upset "opinionated" and "entitled" users is par for the course anywhere. Have a look at how Veeam do it, for example.

Obviously that sort of compatibility nonsense never happens in say Windows (fairly popular OS).

Let's take a quick look at say web proxies. Proxies are quite popular in corporate environments but blow me if Windows and vendors who use it make it as hard as possible to deal with:

You might think group policy would sort it all out - lol! You have loads of elderly policies relating to IE (several versions) hanging around smelling rather fishy and mildly useful if you have older Windows hanging around. You can use GPOs to fix the following but it will be Preferences and involve a bit of ingenuity.

You have .Net Framework apps - eg AD Sync (Entra, Smentra whatever its called today). That will need you to fiddle with a specific XML file.

winhttp api? Powershell. OK you have two sets of settings here: proxy and advproxy. proxy has string properties that you set and is a bit crap and advproxy has a JSON flavour and is a bit shit. advproxy seems to ignore anything in the ignore list apart from or exclusively <local>. At least advproxy allows you to fall back on a proxy.pac file (which IE decided to call wpad.dat and who can forget an IE5 version that called it WPAD.DA?)

Picking on Linux users is disingenuous - all OSs can be customized to the point of tricky to support and besides who on earth is Twitter?

It’s not a great experience if only some apps on supported on your favourite Linux distro while others aren’t.

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.

DaVinci resolve is QT. But making a video editor performant in Electron is even harder than writing it in C++..

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

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)

I’m pretty sure that excludes Claude Desktop.

https://www.techtimes.com/articles/317463/20260531/flathub-a...

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."

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'll be happy the day there's an official distribution and I can put the repo to rest

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.

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).

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?

They all have pros and cons. Pick the one that suits you best. Then you're also agent harness flexible (I use opencode).

Sandboxing a GUI is typically more operational overhead than sandboxing a cli (mounting compositor sockets, GPU access, etc).

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

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.

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.

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.

It’s really not that hard.

https://www.xrdp.org/

(Or x forwarding over ssh, or waypipie if you only need to access a gui application, not a desktop).

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.)

However, I do think an app image or I guess a flatpak would be nice.