Live data from Hacker News

Anthropic, please ship an official Claude Desktop for Linux

github.com

161–170 of 331 posts

Re: Anthropic, please ship an official Claude Desktop for Linux

#161
post #159
post #108

Earlier quoted context omitted.

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.

> 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 e…

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.

Re: Anthropic, please ship an official Claude Desktop for Linux

#162

Earlier quoted context omitted.

> 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 sor…

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?

Re: Anthropic, please ship an official Claude Desktop for Linux

#163
post #84

Earlier quoted context omitted.

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 w…

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?

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.

Re: Anthropic, please ship an official Claude Desktop for Linux

#164

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

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.

Re: Anthropic, please ship an official Claude Desktop for Linux

#166

Earlier quoted context omitted.

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 tal…

I do other things on my computer apart from bash.

Re: Anthropic, please ship an official Claude Desktop for Linux

#167

Earlier quoted context omitted.

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 stil…

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

Re: Anthropic, please ship an official Claude Desktop for Linux

#168

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.

I know they don't do it due to fragmentation, but things like appimage do exist.

Re: Anthropic, please ship an official Claude Desktop for Linux

#169
post #162

Earlier quoted context omitted.

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 sor…

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.

Re: Anthropic, please ship an official Claude Desktop for Linux

#170

Earlier quoted context omitted.

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 stil…

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

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

Post reply on HN