[FEATURE] Demande d’un build Linux officiel (Ubuntu LTS/Debian) pour Claude Desktop

• Demande d’une position publique d’Anthropic sur la prise en charge du desktop Linux et, si possible, d’un premier build officiel de Claude Desktop ciblant Ubuntu LTS/Debian
• À l’heure actuelle, Claude Desktop n’est distribué que pour macOS et Windows, et la page de téléchargement officielle l’indique comme « Not available for Linux », ce qui empêche les utilisateurs Linux d’utiliser Desktop extensions, computer use, desktop dictation et Cowork via le parcours GUI officiel
• Claude Code CLI s’exécute nativement sur Linux, mais comme il s’agit d’un outil terminal, ce n’est pas un moyen de remplacement pour développer et tester le plug-in Claude Code comme Claude Desktop extensions ; aujourd’hui, les tests de plug-ins nécessitent de basculer sur macOS ou Windows
• Claude Code fournit déjà des dépôts signed apt, dnf et apk, ainsi que des binaires variantes linux-x64, linux-arm64 et musl ; la solution proposée consiste à fournir, via le même pipeline de distribution, un .deb signed dans un dépôt apt opéré par Anthropic
• Comme éléments liés à Cowork, les résultats de rétro-ingénierie de Simon Willison, Pluto Security et pvieito sont cités ; il est également indiqué que le binaire Claude Code fonctionne dans une VM Ubuntu 22.04 basée sur Apple Virtualization Framework sur macOS, et que la documentation d’Anthropic confirme la séparation des hyperviseurs macOS/Windows
• johnzfitch/claude-cowork-linux est présenté comme un portage communautaire qui stub les macOS native modules et exécute le mode Cowork sur Linux x86_64 sans VM
• Les utilisateurs Linux dépendent actuellement de reconditionnements tiers du build Windows Electron ; aaddrick/claude-desktop-debian fournit des dépôts signed apt/dnf, .deb, .rpm, AppImage, des builds AUR et Nix, --doctor, des tests CI et des releases de suivi de Claude Desktop 1.11187.1, mais il n’est ni vendor-signed ni audité par l’éditeur
• Comme Claude Desktop est une application de gestion d’identifiants sur un poste de travail développeur, qui manipule OAuth tokens, API keys et extension configurations, l’absence de build Linux officiel soulève des préoccupations de confiance et de sécurité
• Les alternatives actuelles — Claude Code CLI, le client web claude.ai, les reconditionnements communautaires, l’exécution via Wine ou le basculement vers macOS/Windows — sont récapitulées, mais chacune présente des limites en matière de desktop extensions, computer use, Cowork, stabilité d’intégration, mises à jour de sécurité de première main et friction de développement répétée
• Si un premier build n’est pas sur la feuille de route, une demande de repli propose de publier dans la documentation d’installation l’absence de plan Linux et un calendrier approximatif, de reconnaître les projets communautaires recommandés, de fournir un résumé d’un audit de sécurité ponctuel, ainsi que des consignes de sécurité pour la gestion des identifiants et la configuration de MCP server pour les utilisateurs Linux

[GN⁺]

Avis sur Hacker News

• Une build non officielle est maintenue sur https://github.com/aaddrick/claude-desktop-debian
  Le nom contient Debian, mais le périmètre s’est désormais élargi à tous les backends, compositeurs, etc., et la raison principale pour laquelle les entreprises publient rarement des apps Electron pour Linux serait selon lui la fragmentation des distributions
  Dès qu’on dépasse le simple rendu d’une page web sous forme d’app, cela devient vite complexe, et même avec tout un lot de VM de test, le besoin persiste

  • Dans une ancienne entreprise, ils avaient sérieusement essayé de sortir un client desktop Linux malgré un faible nombre de clients intéressés, et ils ont constaté que cela tournait très vite à l’enfer de la compatibilité
    On peut penser qu’en ne ciblant que quelques versions récentes d’Ubuntu, tout ira bien, mais les plaintes affluent depuis des distributions dont on n’a jamais entendu parler, où une partie de l’app ne fonctionne pas correctement
    Même si un ingénieur passe une demi-journée à installer l’app dans une VM et à la déboguer, la cause se trouve quelque part dans un projet amont, et les tickets Linux continuent de s’accumuler pour un nombre de clients trop faible pour le justifier
    Et pourtant, ces clients sont en colère et très bruyants. Sans mentionner qu’ils font tourner une distribution obscure sur un ThinkPad vieux de 13 ans, ils vont sur Twitter, Hacker News et Reddit pour dire que le logiciel de l’entreprise est nul
    Même des apps Electron open source ne tournent pas sur plusieurs distributions populaires sans contournements en ligne de commande, et même là elles sont souvent instables. On l’accepte pour l’open source, mais si une entreprise le distribue, elle peut se retrouver avec des clients mécontents qu’elle ne voulait pas gérer
  • Dire que les entreprises ne publient pas d’apps Electron pour Linux est un peu étrange. Au contraire, on dirait qu’elles ne publient quasiment que des apps Electron
    Quand le desktop Linux reçoit quelque chose hors du libre et de l’open source, c’est souvent de l’Electron, avec des exemples comme Spotify, Discord, Slack, VSCode
    Sur les 20 dernières années, il y a très peu d’exemples d’entreprises commerciales ayant vraiment fourni de bonnes apps GTK ou Qt pour Linux
    L’effort de build non officielle est admirable, mais pour un produit d’une entreprise valorisée, à vue de nez, à des centaines de milliards, et dont les données d’entraînement doivent contenir des milliers d’apps Electron, ils devraient en assumer eux-mêmes le coût
  • Flatpak ne pourrait-il pas résoudre une bonne partie de ces problèmes ? Il suffirait peut-être de développer l’app pour un seul gestionnaire de fenêtres / environnement de bureau, puis d’en faire une exigence Flatpak
  • Il existe un projet similaire pour Codex Desktop : https://github.com/ilysenko/codex-desktop-linux
    Après être passé par le processus d’installation de codex sur Linux, il ne comprend vraiment pas pourquoi OpenAI ne publie pas de port officiel
    Il n’a pas testé toutes les parties de l’app, mais ce qu’il a essayé a fonctionné comme prévu, et computer use a aussi marché sans problème

• On aurait aimé qu’Anthropic ait une sorte d’outil d’automatisation efficace pour le portage logiciel

  • Même si on peut produire du logiciel à l’infini, il faut toujours être très intentionnel sur ce qu’on choisit de faire
    Même si coder est désormais « gratuit », il reste des coûts comme les tests, le support et la planification
  • On dirait que le goulot d’étranglement n’est pas là
  • Il manque allegedly
  • Ce serait bien que les entreprises d’IA de pointe décident d’utiliser les meilleures IA du monde pour développer des logiciels Linux et fournir un support correct
  • On se demande s’il s’agit de produire une app Linux encore plus bancale avec l’existant déjà bancal qui demande 1 Go de RAM pour une simple app terminal
    Ce serait bien qu’au moins un développeur rémunéré avec un package supérieur à 500 000 dollars sache écrire une app simple qui ne soit pas nulle et qu’on puisse réellement utiliser

• Beaucoup disent que c’est un problème difficile, mais il est intéressant de voir que Discord a publié ceci
  « Marre de cette adorable modale qui vous dit, si vous êtes utilisateur Linux, d’installer vous-même la mise à jour ? Bonne nouvelle : nous avons porté notre updater basé sur Rust vers Linux, ce qui permet désormais l’auto-mise à jour sur Linux comme sur Windows. Nous prenons également en charge les formats de paquets d’installation .rpm et .pkg.tar.zst. »
  Discord est un client plus exigeant, car il doit gérer la capture d’écran, la capture audio, le routage audio, et prendre en charge trois dépôts de paquets
  Si les problèmes de base sont corrigés, il suffit d’accepter qu’il faudra mettre à jour les dépendances de build et d’exécution à chaque version
  Le fait qu’un binaire unique soit distribué et fonctionne signifie qu’il doit embarquer toutes les bibliothèques dont il dépend ; Windows gère cela avec winsxs, alors que Linux vous demande de vous en charger vous-même

• Il se demande ce qui manque vraiment dans une app desktop que la CLI ne peut pas offrir. Lui aussi utilise surtout Linux et s’est contenté de la CLI

  • Avec l’abonnement Anthropic, il semble que la CLI ne fournisse plus de routine quotidienne
    De plus, la recherche de mémoire entre conversations utilise un ensemble de données de conversations différent de Claude Code, à savoir les conversations Claude Web/Claude.AI, et il n’est même pas certain que Claude Code fasse de la recherche entre conversations
    L’interface desktop affiche le Markdown comme du texte enrichi et montre bien mieux les artefacts interactifs que la CLI
    Cela dit, dans les faits il utilise la CLI pour presque tout. Les routines quotidiennes de Claude Desktop sont limitées à 15 tâches cron au total et consomment des crédits d’usage supplémentaires ; il compte donc créer lui-même un harness minimal et déplacer ses routines vers les modèles d’un autre fournisseur
  • Utiliser la même expérience que les collègues non-Linux facilite le partage des apprentissages et des processus
    Il faut aussi des tâches planifiées exécutées localement, et la fonctionnalité décrite ici https://support.claude.com/en/articles/13854387-schedule-rec... est importante et différente des routines de Claude Code
    Il faut aussi la capacité de gérer plusieurs projets / mémoires isolées dans un même dossier, ainsi qu’une meilleure UI
  • L’app desktop permet de contrôler les sessions distantes laissées ouvertes via la fonctionnalité Code
  • Il veut pouvoir voir les images inline que Claude essaie soudainement de montrer. Dans la CLI, Claude continue jusqu’à rappeler qu’on ne peut pas y afficher d’images
    À part ça, la CLI lui convient
  • La CLI est bien pour les tâches de code, mais pour d’autres usages sans rapport avec le code, l’app desktop peut être assez utile

• Je ne sais pas quelle est la taille du marché des utilisateurs Linux qui veulent une app Electron pour faire du vibe coding dans des apps dérivées de Visual Studio, mais ne vont ni la créer eux-mêmes ni cloner le dépôt de quelqu’un d’autre pour la compiler

  • Je n’en sais rien, mais si je pouvais utiliser Claude Desktop sur une machine Linux, j’accepterais volontiers de m’en charger pour la moitié du salaire d’un développeur chez Anthropic
    Les bidouillages tiers qui font tourner l’app Electron Windows sur Linux m’ont toujours semblé pénibles, donc je n’aime pas ça
  • Je ne veux pas spécialement de l’app Claude donc je ne suis pas directement concerné, mais l’utilisateur Linux moyen d’aujourd’hui ressemble de plus en plus à une personne ordinaire qui ne veut pas de choses comme la télémétrie intrusive ou la pub

• C’est étonnant de voir que tant de développeurs prennent encore de haut l’usage de Linux
  Vous utilisez déjà Docker et vous déployez sur K8S. Et tout ça tourne sur Linux

  • Le système d’exploitation en lui-même m’importe peu. Je veux un portable puissant avec un bon clavier et un bon trackpad, une longue autonomie et un écran net
    Si possible très silencieux, et avec un design épuré tant qu’à faire. C’est la proposition de valeur du MacBook
  • Ce n’est pas du tout la même chose
  • Le périmètre de support d’un desktop et d’un serveur n’a absolument rien à voir

• Il suffit de le faire soi-même d’un seul coup, en mode vibe
  C’est un peu nul, mais quand tout le monde ici ne parle que d’autocomplétion épicée et de destruction d’emplois auto-infligée, il faut parfois bien s’amuser soi-même

  • Ravi de voir que je ne suis pas le seul sur ce site lamentable à y voir de la destruction d’emplois auto-infligée

• Personnellement, je ne comprends pas pourquoi Claude Code n’a toujours pas de mode qui met le texte en vert et fait tomber les caractères un par un à l’écran comme dans The Matrix

  • C’est extrêmement agaçant. De nos jours, pour travailler correctement, il faut mettre des lunettes de soleil vertes, passer la langue en japonais et tourner le moniteur sur le côté

• J’aimerais qu’on fasse attention à la manière de formuler la demande
  Si le but est d’utiliser Claude pour le développement logiciel, je me contenterais largement d’avoir tout ce qu’il faut pour exécuter le binaire CLI claude dans une sandbox VM Linux KVM prévue pour le travail, sans client desktop. Plus c’est propre et fiable, mieux c’est
  L’usage conversationnel classique, pour poser des questions, je le fais dans la sandbox du navigateur web du desktop hôte, et j’aimerais que cette façon de faire soit bien prise en charge
  Les gens du marketing/produit dans les entreprises d’IA voudront évidemment pousser tout le monde vers un client desktop propriétaire, mais c’est encore un angle possible d’abus qu’on peut contenir
  Je ne veux pas que le desktop hôte, ni ce à quoi il a accès, soient pris en charge via une automatisation de type agent. La technologie n’est pas encore prête à l’heure actuelle

  • Le problème, c’est que VNC est vraiment trop mauvais par rapport à RDP
    L’accès au client GUI dans cette VM est catastrophique, sinon je n’aurais pas écarté aussi facilement l’idée d’un client GUI

• L’ironie de voir des centaines d’utilisateurs avec des agents CLI incapables de réellement fabriquer eux-mêmes une version desktop est assez drôle
  Les LLM rendent-ils vraiment les gens aussi impuissants ?

  • Je m’en suis écarté parce qu’Anthropic faisait tout un scandale autour de claude -p pour bloquer Openclaw, et je ne voulais pas me retrouver pris dans les retombées
    Il était difficile de suivre les passes d’armes entre les deux camps, mais on dirait que c’est peut-être terminé maintenant
  • Il est difficile pour une seule personne de suivre durablement un produit qui publie des mises à jour plusieurs fois par jour
  • Il faut voir que la demande contient le mot officiel. Des versions non officielles existent déjà