VSCodium - Le binaire open source de VSCode

 (vscodium.com)
2 points par GN⁺ 2023-09-05 | 1 commentaires | Partager sur WhatsApp
  • VS Code ayant des conditions différentes entre son code source et sa distribution officielle, VSCodium constitue une alternative pour les utilisateurs qui veulent directement obtenir un binaire sous licence MIT
  • Le code source vscode de Microsoft est sous licence MIT, mais le produit Visual Studio Code téléchargeable utilise une licence distincte et inclut de la télémétrie/du suivi
  • VSCodium remplace le processus de distribution par des scripts automatisés qui compilent le dépôt vscode de Microsoft et publient les binaires résultants sur les GitHub releases
  • Les binaires fournis ont la télémétrie désactivée et les dernières releases sont disponibles pour Windows, Mac OS et Linux
  • L’installation est possible via de nombreux gestionnaires de paquets comme Homebrew, WinGet, Chocolatey, Scoop, Snap, Nixpkgs, AUR, des dépôts deb/rpm ou Flatpak

Différence entre le code source de VS Code et la distribution Microsoft

  • VSCodium est une distribution binaire libre/open source basée sur VS Code de Microsoft
  • Le code source vscode de Microsoft est sous licence MIT, mais le produit Visual Studio Code distribué par Microsoft utilise une licence non FLOSS et inclut de la télémétrie/du suivi
  • Le build distribué par Microsoft est produit en clonant le dépôt vscode, puis en appliquant un product.json intégrant des fonctionnalités propres à Microsoft
    • Ces fonctionnalités spécifiques à Microsoft incluent la telemetry, la gallery, le logo, etc.
    • Si l’on compile directement avec le product.json par défaut, on obtient un build « clean » sans personnalisation Microsoft, auquel s’applique par défaut la licence MIT

Méthode de build et de distribution de VSCodium

  • VSCodium permet aux utilisateurs d’obtenir un build sous licence MIT sans avoir à télécharger le code source ni à le compiler eux-mêmes
  • Les scripts de build clonant le dépôt vscode de Microsoft, exécutent les commandes de compilation, puis téléversent les binaires résultants sur les GitHub releases
  • Les binaires de VSCodium sont sous licence MIT et la télémétrie y est désactivée
  • Les utilisateurs souhaitant compiler eux-mêmes peuvent utiliser le dépôt vscode de Microsoft ainsi que ses instructions de build
  • Les dernières releases sont proposées pour Windows, Mac OS et Linux

Installation selon le gestionnaire de paquets

  • Sur Mac avec Homebrew : 
    brew install --cask vscodium
  • Sous Windows, plusieurs gestionnaires de paquets sont disponibles
    • WinGet 
      winget install vscodium
    • Chocolatey 
      choco install vscodium
    • Scoop 
      scoop bucket add extras
scoop install vscodium
  • Sous Linux, l’installation est possible via Snap, Nixpkgs, AUR, Flatpak, etc.
    • Dans le Snap Store, l’application est proposée sous le nom Codium 
      snap install codium --classic
    • Sur Nix(OS), on peut ajouter vscodium à environment.systemPackages ou l’installer localement 
      nix-env -iA nixpkgs.vscodium
    • Sur Arch Linux, le paquet AUR vscodium-bin peut être installé avec un AUR Helper 
      yay -S vscodium-bin

Installation via distributions et dépôts

  • Sur Parrot OS, VSCodium est installé par défaut
    • S’il n’apparaît pas, il peut être installé depuis le dépôt officiel Parrot 
      sudo apt update && sudo apt install codium
  • Les paquets deb pour Debian/Ubuntu s’installent via les dépôts liés à VSCodium et des miroirs CDN
    • Il faut ajouter la clé GPG du dépôt, puis la configuration du dépôt correspondant à la version Debian/Ubuntu utilisée
    • La commande d’installation est la suivante 
      sudo apt update && sudo apt install codium
    • Pour vscodium-insiders, remplacez codium par codium-insiders
  • Les paquets rpm pour Fedora/RHEL/CentOS/Rocky Linux/OpenSUSE s’installent eux aussi via l’ajout d’un dépôt dédié
    • Fedora/RHEL/CentOS/Rocky Linux : 
      sudo dnf install codium
    • OpenSUSE/SUSE : 
      sudo zypper in codium
  • Sur Gentoo/Funtoo, l’installation se fait via ebuild
    • Funtoo : 
      sudo emerge -av vscodium-bin
    • Gentoo : 
      sudo emerge -av vscodium

Flatpak et documentation de migration

  • VSCodium est également disponible comme application Flatpak, et son dépôt de build est flathub/com.vscodium.codium
  • Si le dépôt Flathub est activé, l’installation peut se faire avec la commande suivante 
    flatpak install flathub com.vscodium.codium
  • Si gnome-software-plugin-flatpak est installé, VSCodium peut aussi être trouvé dans GNOME Software
  • Les particularités à connaître lors d’une migration de Visual Studio Code vers VSCodium, ou à l’usage, sont regroupées dans la documentation

À lire aussi

1 commentaires

 
GN⁺ 2023-09-05
Avis de Hacker News

  • Les binaires produits par ce genre de projet me semblent plus difficiles à faire confiance que ceux fournis par les Big Tech. Les Big Tech sont certes les plus gros traqueurs, mais un projet avec beaucoup moins de personnel et d’intérêts en jeu paraît plus vulnérable aux attaques de la chaîne d’approvisionnement ou à une prise de contrôle hostile si un développeur vend le projet.
    Je ne suis pas vraiment spécialiste du sujet, donc j’aimerais avoir des ressources de référence sur la manière dont ces projets évitent ces risques ; et peut-être que cette inquiétude est effectivement fondée.

    • Cette inquiétude est tout à fait légitime. Sans vouloir évaluer ce projet en particulier, rendre fiable le processus consistant à récupérer l’original, le modifier puis le redistribuer est difficile.
      Les grandes entreprises déploient des efforts extrêmes pour garantir la chaîne de confiance des logiciels qu’elles compilent, et les plateformes de distribution d’apps font elles aussi beaucoup d’efforts pour assurer une chaîne de confiance de bout en bout, depuis le développeur jusqu’à l’app exécutée sur l’appareil de l’utilisateur.
      C’est fondamentalement impossible sans faire confiance non seulement à l’auteur original, mais aussi au redistributeur ; toutefois, des procédures de build vérifiables, la vérification des clés de signature et des empreintes, ou encore la resignature permettent de réduire la quantité de confiance nécessaire. Si l’utilisateur peut, en théorie, reproduire lui-même le même build, il devient plus facile d’y croire.
      La meilleure option serait que le projet d’origine fournisse lui-même des builds sans marque, et que des projets comme VSCodium se limitent à de la configuration uniquement, par exemple la désactivation de la télémétrie, afin qu’aucune resignature ne soit nécessaire. Par exemple, le projet Chromium distribue directement des binaires Chromium dépourvus des éléments propres à Google.
      Je pensais surtout aux app stores, mais presque la même logique s’applique à des endroits comme les dépôts de paquets Debian. Les app stores resignent généralement au milieu de la chaîne, il faut donc faire confiance au store, mais ces entreprises font beaucoup d’efforts pour garantir la fiabilité de ce point.
    • En théorie, si ce projet compile via GitHub Actions et que l’on fait confiance à la sécurité de Microsoft, il suffit de vérifier le hash du commit récupéré par l’action et de comparer les différences avec l’upstream.
      Si ces différences semblent sûres, cela revient presque à dire que l’on peut aussi faire confiance au binaire. Bien sûr, il faut aussi vérifier qu’il ne récupère pas de ressources Internet dont l’intégrité ne peut pas être garantie de la même manière.
    • Je viens d’installer vscodium sur une machine Manjaro, et il a été compilé depuis les sources AUR.
      On devrait pouvoir comparer le code source utilisé par le paquet avec le SHA git upstream de Microsoft sur lequel il prétend se baser : https://aur.archlinux.org/packages/vscodium
      En plus, il existe maintenant aussi une extension de mode distant open source, donc je n’ai plus de raison d’utiliser la version propriétaire. De mon côté, plus de télémétrie.
    • Après avoir vu à quoi ressemble aujourd’hui l’industrie tech, et y avoir travaillé, je pense plutôt l’inverse.
      Je n’ai aucune confiance dans le fait qu’une grande entreprise fasse les choses correctement et ne remplisse pas son application de spyware sous le nom de télémétrie. Je préfère faire confiance à des gens qui s’acharnent à produire du logiciel libre et open source.
    • Moi aussi, pour l’instant, je fais davantage confiance à l’entreprise qui développe le projet d’origine. Ce serait bien d’avoir plus de choix.
      Les builds reproductibles pourraient aider ici, comme Go l’a fait avec son SDK récent : https://go.dev/blog/rebuild
      C’est particulièrement pertinent pour un fork avec peu de changements dans le code source, puisqu’il suffit alors de vérifier les patches.
      Les distributions Linux sont assez similaires. Si l’on fait globalement confiance aux paquets Debian, c’est parce qu’il existe une organisation faîtière et des procédures. Les organisations indépendantes en ont moins.
      Peut-être qu’un jour, il existera une organisation faîtière dédiée uniquement aux builds reproductibles, et que les gens pourront distribuer des binaires par son intermédiaire. Comme pour les bureaux d’enregistrement de domaines, une vérification indépendante pourrait inciter cette organisation à rester honnête.

  • Microsoft a limité l’usage de certaines extensions clés aux seules versions officielles, éliminant ainsi la concurrence dans cette direction. Personnellement, j’utilise pas mal les extensions distantes, et j’aimerais que quelqu’un propose une alternative.

    • Aujourd’hui, j’ai de la chance
      “Open Remote - SSH” de « jeanp413 », c’est-à-dire @ext:jeanp413.open-remote-ssh, fonctionne au moins chez moi exactement comme l’extension à source fermé
      J’utilise le paquet vscodium AUR sur Manjaro, et j’ai récupéré l’extension depuis le store par défaut de vscodium. Je ne sais pas si elle est disponible dans le store de Microsoft
      Dans Code - OSS, cette extension ne fonctionnait pas chez moi ; ça ressemblait à une erreur de configuration et je n’ai pas creusé davantage
    • La documentation explique comment revenir au marketplace officiel des extensions : https://github.com/VSCodium/vscodium/blob/master/DOCS.md#how...
      Donc si vous avez des extensions indispensables qui ne sont pas sur le marketplace de Codium, vous pouvez toujours les utiliser via le marketplace de Microsoft
    • J’ai commencé à utiliser Remote OSS, avec un script personnalisé qui installe et lance l’hôte de code distant. Ça marche bien aussi sur les serveurs distants, et ça s’intègre correctement avec les devcontainers sur l’hôte distant
      Pour automatiser l’installation et la configuration du tunnel, vous pouvez utiliser un script comme celui-ci : https://github.com/CGamesPlay/dotfiles/blob/master/files/.lo...
      Je travaille aussi sur une PR qui ajoute un mécanisme lançant automatiquement un script personnalisé pour configurer le tunnel : https://github.com/xaberus/vscode-remote-oss/pull/9
      Remote OSS : https://open-vsx.org/extension/xaberus/remote-oss
    • L’alternative, à mon avis, c’est tout simplement de ne pas utiliser VS Code. Au travail, je l’utilise parce que le service IT le prend officiellement en charge et que le suivi ne les préoccupe pas, mais pour mes projets personnels j’utilise toujours Sublime
    • Il y a https://open-vsx.org/extension/jeanp413/open-remote-ssh et https://open-vsx.org/extension/jeanp413/open-remote-wsl

  • C’est fondamentalement ce que l’on obtient en téléchargeant le code source de Visual Studio Code et en le compilant
    Le nom ressemble aussi à un jeu de mots du même genre que Chrome → Chromium
    La pratique de Microsoft et Google consistant à dire qu’ils « rendent open source » leurs produits, tout en publiant en réalité des produits avec des fonctionnalités supplémentaires à source fermé, est au mieux malhonnête, et au pire matière à un énorme procès

    • 100 % d’accord. Google et Apple ont lancé cette tendance, et MS l’a parachevée. Ils disent créer des produits « open source », alors qu’en réalité ils publient une version à source fermé
      Ces grandes entreprises profitent du travail d’ingénieurs logiciels naïfs qui donnent de leur temps à des produits open source, mais ce qu’elles livrent aux utilisateurs finaux, c’est une version à source fermé
    • Je ne vois pas ce qui est malhonnête, ni sur quoi on pourrait intenter un procès. « Ils ont publié le produit en open source et l’ont distribué gratuitement, mais ce n’est pas comme je le voudrais » me paraît difficile à attaquer en justice
    • « Matière à un énorme procès » est une affirmation assez audacieuse. À moins que vscode ou un autre produit n’utilise de façon inappropriée du code sous licence GPL ou ne respecte pas les exigences de licence, à ma connaissance Microsoft ne fait rien de répréhensible
      C’est le même cas que de nombreuses entreprises commerciales qui publient des logiciels propriétaires basés sur des projets open source
    • C’est un modèle de gentrification ouverte
    • Ici, l’usage du terme « open source » me semble assez honnête. D’autres peuvent récupérer le code source et distribuer légalement des builds presque identiques, à la télémétrie près
      Ce qu’il faudrait, c’est plutôt une distinction de type anti-fonctionnalités, comme dans le store F-Droid. Par exemple, des mentions comme « cette application dépend d’autres applications non libres » ou « dépend de services réseau non libres, ou en encourage l’usage »

  • Vscode a été conçu pour provoquer la fragmentation : https://ghuntley.com/fracture/

    • Cela avait déjà été discuté en 2022 : https://news.ycombinator.com/item?id=32657709
      En résumé, Microsoft a publié Visual Studio Code avec de la télémétrie intégrée, ce qui a conduit des projets comme VSCodium à proposer des builds personnalisés sans télémétrie. Mais comme ces projets ne disposent pas de la licence Microsoft, ils ne peuvent pas utiliser le même marketplace, et c’est cela la fragmentation dont parle le titre de l’article
      L’auteur poursuit en disant que d’autres IDE propriétaires posent aussi problème, et que GitHub est un piège qui capture les développeurs et les fragmente
      Ce drame autour de Microsoft et de l’open source rappelle les documents Halloween : http://www.catb.org/~esr/halloween/
    • Le point central auquel cet article finit par arriver, c’est que Microsoft a créé le meilleur IDE et les meilleures extensions, ce qui rend difficile de ne pas utiliser Microsoft. Et cela a plusieurs implications négatives
      Euh… certes ? On l’utilise ou on ne l’utilise pas. Je ne suis pas sûr que « c’est tellement bon qu’on ne peut pas s’en passer » soit une plainte vraiment légitime
    • Avec cette définition, j’ai vraiment du mal à penser à un produit extensible, ou permettant des extensions, qui n’ait pas été conçu pour provoquer la fragmentation

  • Hier, j’ai dû abandonner le build open source. Après la mise à jour, Pylance semblait avoir cessé de fonctionner à cause du DRM
    À chaque démarrage, il affichait un gros avertissement indiquant que l’utiliser dans un build non approuvé par MS constituait une violation de licence, puis s’arrêtait aussitôt

    • On peut utiliser pyright à la place : https://github.com/microsoft/pyright
      C’est la version libre et open source de pyright, mais il manque certaines fonctionnalités
    • Ça ressemble à une bonne raison de ne pas utiliser Pylance

  • Articles liés
    VSCodium – Free/Libre Open Source Software Binaries of VS Code - https://news.ycombinator.com/item?id=31604932 - juin 2022, 430 commentaires
    VS Code without Microsoft branding/telemetry/licensing - https://news.ycombinator.com/item?id=23447413 - juin 2020, 200 commentaires
    VSCodium – An Open Source Visual Studio Code Without Trackers - https://news.ycombinator.com/item?id=19650109 - avril 2019, 253 commentaires
    VSCodium: 100% Open Source Version of vs. Code - https://news.ycombinator.com/item?id=19619956 - avril 2019, 8 commentaires
    VSCodium: Binary releases of VSCode without MS branding, telemetry and licensing - https://news.ycombinator.com/item?id=17850960 - août 2018, 113 commentaires

  • Je l’ai utilisé longtemps et je l’ai recommandé à mon équipe, mais j’ai fini par abandonner. Sans les fonctionnalités Remote SSH et devcontainers, Microsoft tient fortement ceux qui veulent tirer le maximum de VSCode
    En plus, Microsoft semble avoir reculé sur la télémétrie, et on dit qu’il est désormais possible de la désactiver complètement. Je n’ai toutefois pas testé moi-même si « désactivé » l’est vraiment

    • L’extension devcontainer officielle délègue l’essentiel du travail au devcontainer CLI open source, donc il peut être utilisé en dehors de n’importe quel IDE
      De plus, avec Remote OSS, on peut utiliser un hôte distant vscodium dans un dev container. J’ai donné plus de détails dans ce commentaire : https://news.ycombinator.com/item?id=37386025

  • J’utilise à la fois VSCode et VSCodium. La raison est simple et pratique : la gestion des paramètres et plusieurs fenêtres faciles à distinguer
    Mon VSCode est complètement envahi par une quantité énorme d’extensions qui semblent nécessaires pour le travail Microchip/Atmel/zephyr
    Pour le travail ansible/elixir, j’utilise VSCodium

    • Ça me paraît assez compliqué juste pour maintenir deux environnements différents
      VSCodium n’a-t-il pas une fonction de profils, comme dans un navigateur, permettant de modifier toutes sortes de paramètres uniquement dans ce profil ? Je fais souvent ça avec Firefox, et je donne aussi aux fenêtres une apparence différente

  • J’espère que ça continuera à être maintenu. L’extension de notre startup est publiée sur Open VSX Registry, et nous sommes très satisfaits de fonctionner ainsi

  • Sur Arch, il existe un paquet qui semble équivalent et qui s’appelle simplement code

    • code est le nom du binaire, et le « projet » lui-même est Code - OSS, comme indiqué sur https://wiki.archlinux.org/title/Visual_Studio_Code
      C’est le paquet fourni par le dépôt principal ; pour utiliser VSCodium ou Visual Studio Code, il faut passer par l’AUR