201–210 of 331 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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”
If only Anthropic had some kind of automated testing, support, planning machine.
AI doesn't solve this. You need humans who can understand and verify what is being made.
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
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?
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
> 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…
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.
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.
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…
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
Earlier quoted context omitted.
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…
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…
We give Claude full visibility into your Linux machine, with a JS runtime over the top for building tools.
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…