VSCodium - el binario de código abierto de VSCode

 (vscodium.com)
2 puntos por GN⁺ 2023-09-05 | 1 comentarios | Compartir por WhatsApp
  • Como VS Code tiene condiciones distintas entre el código fuente y la distribución oficial, VSCodium se vuelve una alternativa para quienes quieren obtener directamente un binario con licencia MIT
  • El código fuente vscode de Microsoft está bajo licencia MIT, pero el producto descargable Visual Studio Code incluye una licencia distinta y telemetría/seguimiento
  • VSCodium distribuye scripts automatizados que compilan el repositorio vscode de Microsoft y suben los binarios resultantes a GitHub releases, reemplazando así el proceso de distribución
  • Los binarios ofrecidos tienen la telemetría desactivada y se pueden descargar las versiones más recientes para Windows, Mac OS y Linux
  • Se puede instalar mediante varios gestores de paquetes como Homebrew, WinGet, Chocolatey, Scoop, Snap, Nixpkgs, AUR, repositorios deb/rpm y Flatpak

Diferencia entre el código fuente de VS Code y la distribución de Microsoft

  • VSCodium es una distribución binaria libre/de código abierto basada en VS Code de Microsoft
  • El código fuente vscode de Microsoft tiene licencia MIT, pero el producto Visual Studio Code distribuido por Microsoft usa una licencia que no es FLOSS e incluye telemetría/seguimiento
  • La compilación distribuida por Microsoft se crea clonando el repositorio vscode y aplicando un product.json con funciones exclusivas de Microsoft
    • Esas funciones exclusivas de Microsoft incluyen telemetry, gallery, logo, etc.
    • Si se compila directamente con el product.json predeterminado, se genera una compilación “clean” sin personalizaciones de Microsoft, y por defecto se aplica la licencia MIT

Cómo compila y distribuye VSCodium

  • VSCodium permite obtener una compilación con licencia MIT sin que el usuario tenga que descargar el código fuente y compilarlo manualmente
  • Los scripts de compilación clonan el repositorio vscode de Microsoft, ejecutan los comandos de compilación y luego suben los binarios resultantes a GitHub releases
  • Los binarios de VSCodium tienen licencia MIT y la telemetría está desactivada
  • Quienes quieran compilar por su cuenta pueden usar el repositorio vscode de Microsoft y sus instrucciones de compilación
  • La versión más reciente está disponible para Windows, Mac OS y Linux

Instalación según el gestor de paquetes

  • En Mac, si usas Homebrew: 
    brew install --cask vscodium
  • En Windows se pueden usar varios gestores de paquetes
    • WinGet 
      winget install vscodium
    • Chocolatey 
      choco install vscodium
    • Scoop 
      scoop bucket add extras
scoop install vscodium
  • En Linux se puede instalar con Snap, Nixpkgs, AUR, Flatpak, etc.
    • En Snap Store se ofrece con el nombre Codium 
      snap install codium --classic
    • En Nix(OS), vscodium se puede agregar a environment.systemPackages o instalar localmente 
      nix-env -iA nixpkgs.vscodium
    • En Arch Linux, el paquete vscodium-bin de AUR se puede instalar con un AUR Helper 
      yay -S vscodium-bin

Instalación mediante distribuciones y repositorios

  • VSCodium viene preinstalado en Parrot OS
    • Si no aparece por defecto, se puede instalar desde el repositorio oficial de Parrot 
      sudo apt update && sudo apt install codium
  • El paquete deb para Debian/Ubuntu se instala mediante repositorios relacionados con VSCodium y mirrors CDN
    • Después de agregar la clave GPG del repositorio, se añade la configuración correspondiente a la versión de Debian/Ubuntu
    • El comando de instalación es el siguiente 
      sudo apt update && sudo apt install codium
    • Si quieres vscodium-insiders, cambia codium por codium-insiders
  • El paquete rpm para Fedora/RHEL/CentOS/Rocky Linux/OpenSUSE también se instala agregando un repositorio aparte
    • Fedora/RHEL/CentOS/Rocky Linux: 
      sudo dnf install codium
    • OpenSUSE/SUSE: 
      sudo zypper in codium
  • En Gentoo/Funtoo se instala mediante ebuild
    • Funtoo: 
      sudo emerge -av vscodium-bin
    • Gentoo: 
      sudo emerge -av vscodium

Flatpak y documentación de migración

  • VSCodium también está disponible como app de Flatpak, y el repositorio de compilación es flathub/com.vscodium.codium
  • En entornos con el repositorio Flathub habilitado, se puede instalar con el siguiente comando 
    flatpak install flathub com.vscodium.codium
  • Si gnome-software-plugin-flatpak está instalado, también se puede encontrar VSCodium en GNOME Software
  • La documentación resume los puntos particulares que puedes encontrar al migrar de Visual Studio Code a VSCodium o durante su uso

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-05
Opiniones de Hacker News

  • Los binarios creados por proyectos como este se sienten más difíciles de confiar que los binarios ofrecidos por Big Tech. Aunque Big Tech está entre los mayores rastreadores, un proyecto con mucha menos gente e intereses parece más vulnerable a ataques a la cadena de suministro o a una adquisición hostil si un desarrollador vende el proyecto.
    No conozco tan bien este tema, así que me gustaría tener materiales de referencia sobre cómo proyectos como este evitan esos riesgos; quizá esta preocupación sí sea válida.

    • Esa preocupación es totalmente válida. No intento evaluar este proyecto en particular, pero hacer confiable el proceso de tomar el original, modificarlo y redistribuirlo es difícil.
      Las grandes empresas hacen esfuerzos extremos para garantizar la cadena de confianza del software que compilan, y las plataformas de distribución de apps también hacen mucho por asegurar una cadena de confianza de extremo a extremo, desde el desarrollador hasta la app que se ejecuta en el dispositivo del usuario.
      Básicamente es imposible sin confiar no solo en el autor original, sino también en el redistribuidor, pero mecanismos como procedimientos de compilación verificables, verificación de claves de firma y hashes, y refirma reducen la cantidad de confianza necesaria. Si el usuario, en teoría, puede reproducir la misma compilación por su cuenta, se vuelve más fácil confiar.
      La mejor opción sería que el proyecto original ofreciera directamente builds sin marca, y que proyectos como VSCodium quedaran solo para configuración, como desactivar la telemetría, sin necesidad de volver a firmar. Por ejemplo, el proyecto Chromium distribuye directamente binarios de Chromium sin los elementos exclusivos de Google.
      Estaba pensando sobre todo en las app stores, pero casi la misma lógica aplica a lugares como los repositorios de paquetes de Debian. Las app stores normalmente vuelven a firmar en el medio, así que hay que confiar en la tienda, pero estas empresas hacen muchos esfuerzos para asegurar la confiabilidad de ese punto.
    • En teoría, si un proyecto así compila con GitHub Actions y confía en la seguridad de Microsoft, bastaría con revisar el hash del commit obtenido por la acción y comparar las diferencias con el upstream.
      Si esas diferencias parecen seguras, eso se acerca a poder confiar también en el binario. Por supuesto, también habría que comprobar que no esté descargando recursos de internet cuya integridad no pueda garantizarse de la misma forma.
    • Acabo de instalar vscodium en una máquina con Manjaro, y se compiló desde el código fuente de AUR.
      Debería ser posible comparar el código fuente que usó el paquete con el SHA de git upstream de Microsoft en el que afirma basarse: https://aur.archlinux.org/packages/vscodium
      Justo ahora también existe una extensión de modo remoto open source, así que ya no hay razón para usar la versión propietaria. De mi lado, ya no hay telemetría.
    • Después de ver cómo luce la industria tecnológica actual y de haber trabajado dentro de ella, pienso más bien lo contrario.
      No tengo ninguna confianza en que una gran empresa haga algo bien y no llene la aplicación de spyware bajo el nombre de telemetría. Prefiero confiar en la gente que insiste obstinadamente en crear software libre y de código abierto.
    • Yo, por ahora, confío más en la empresa desarrolladora original. Ojalá hubiera más opciones.
      Las compilaciones reproducibles pueden ayudar aquí, como hizo Go con el SDK más reciente: https://go.dev/blog/rebuild
      Es especialmente útil si el fork tiene pocos cambios de código fuente, porque entonces solo hace falta verificar los parches.
      Las distribuciones de Linux son bastante similares. La razón por la que en general confío en los paquetes de Debian es que existe una organización paraguas y procedimientos. Las organizaciones independientes tienen menos de eso.
      Algún día podría existir una organización paraguas dedicada solo a compilaciones reproducibles, y la gente podría distribuir binarios a través de ella. Como con los registradores de dominios, una verificación independiente podría mantener honesta a esa organización.

  • Microsoft restringió las extensiones principales para que solo se usen en los lanzamientos oficiales, eliminando así la competencia en esa dirección. Personalmente uso bastante las extensiones remotas, así que ojalá alguien ofrezca una alternativa.

    • Hoy tuve suerte.
      “Open Remote - SSH” de “jeanp413”, es decir @ext:jeanp413.open-remote-ssh, al menos para mí funciona igual que la extensión de código cerrado.
      Uso el paquete AUR de vscodium en Manjaro, y obtuve la extensión desde la tienda predeterminada de vscodium. No sé si está en la tienda de Microsoft.
      En Code - OSS esa extensión no me funcionó, pero parecía un error de configuración y no investigué más.
    • En la documentación hay una forma de volver a cambiar al marketplace oficial de extensiones: https://github.com/VSCodium/vscodium/blob/master/DOCS.md#how...
      Así que, si hay una extensión imprescindible que no está en el marketplace de codium, todavía se puede usar a través del marketplace de Microsoft.
    • Empecé a usar Remote OSS y lo uso junto con un script personalizado que instala y ejecuta el host de código remoto. Funciona bien también en servidores remotos, y se integra bien con devcontainers en el host remoto.
      Para automatizar la instalación y configuración del túnel, se puede usar algo como el script que está aquí: https://github.com/CGamesPlay/dotfiles/blob/master/files/.lo...
      También estoy trabajando en un PR para agregar una forma de ejecutar automáticamente un script personalizado que configure el túnel: https://github.com/xaberus/vscode-remote-oss/pull/9
      Remote OSS: https://open-vsx.org/extension/xaberus/remote-oss
    • Creo que la alternativa es simplemente no usar VS Code. En el trabajo lo uso porque el área de IT le da soporte oficial y no me importa el rastreo, pero para trabajo personal sigo usando Sublime.
    • Están https://open-vsx.org/extension/jeanp413/open-remote-ssh y https://open-vsx.org/extension/jeanp413/open-remote-wsl.

  • Esto es básicamente lo mismo que se obtiene al descargar el código fuente de Visual Studio Code y compilarlo.
    Incluso el nombre parece casi un juego de palabras del estilo Chrome → Chromium.
    La práctica de Microsoft y Google de decir que “abren el código” de sus productos, cuando en realidad lanzan productos con funciones adicionales de código cerrado, es deshonesta en el mejor de los casos y, en el peor, material para una demanda enorme.

    • 100% de acuerdo. Google y Apple iniciaron esta tendencia, y MS la perfeccionó. Dicen que crean productos “open source”, pero en realidad publican una versión de código cerrado.
      Estas grandes empresas se benefician del trabajo de ingenieros de software ingenuos que donan su tiempo a productos open source, pero lo que entregan a los usuarios finales es una versión de código cerrado.
    • No entiendo qué tiene de deshonesto ni cuál sería la base para demandar. Con “publicaron el producto como open source y lo distribuyeron gratis, pero no es como yo quería” parece difícil demandar.
    • Lo de “material para una demanda enorme” es una afirmación bastante audaz. A menos que vscode u otros productos estén usando código con licencia GPL de forma indebida o no cumplan con los requisitos de la licencia, al menos que yo sepa Microsoft no está haciendo nada malo.
      Es el mismo caso que el de muchísimas empresas comerciales que lanzan software propietario basado en proyectos open source.
    • Esto es un modelo de enshittification abierta.
    • Creo que aquí el término “open source” se está usando de forma bastante justa. Otras personas pueden tomar el código fuente y distribuir legalmente una compilación casi idéntica, salvo por cosas como la telemetría.
      Lo que hace falta es algo más parecido a la clasificación de antifunciones de la tienda F-Droid. Por ejemplo, marcas como “esta app depende de otras apps no libres” o “depende de servicios de red no libres o los promueve”.

  • Vscode fue diseñado para inducir fragmentación: https://ghuntley.com/fracture/

    • Ya se discutió en 2022: https://news.ycombinator.com/item?id=32657709
      En resumen, Microsoft lanzó Visual Studio Code con telemetría incorporada, por lo que proyectos como VSCodium empezaron a publicar compilaciones personalizadas sin telemetría. Pero como estos proyectos no tienen licencia de Microsoft, no pueden usar el mismo marketplace, y esa es la fragmentación del título del artículo.
      Luego dice que otros IDE propietarios también tienen problemas, y que GitHub es una trampa para capturar y fragmentar a los desarrolladores.
      Este drama alrededor de Microsoft y el open source me recuerda a los documentos de Halloween: http://www.catb.org/~esr/halloween/
    • El punto central al que llega ese artículo, al final, es que Microsoft creó el mejor IDE y las mejores extensiones, y por eso se volvió difícil no usar Microsoft. Eso tiene varias implicaciones malas.
      Mmm… ¿y? Úsalo o no lo uses. No estoy seguro de que “es tan bueno que no puedo dejar de usarlo” sea una queja válida.
    • Con esa definición, de verdad cuesta pensar en algún producto con extensibilidad o que permita extensiones que no esté diseñado para inducir fragmentación.

  • Ayer tuve que cambiarme desde la build de código abierto. Después de actualizar, Pylance pareció dejar de funcionar por DRM
    Cada vez que iniciaba, mostraba una gran advertencia de que usarlo en una build no aprobada por MS era una violación de la licencia, y se detenía de inmediato

    • En su lugar se puede usar pyright: https://github.com/microsoft/pyright
      Es la versión libre y de código abierto de pyright, pero le faltan algunas funciones
    • Eso suena como una razón para no usar Pylance

  • Artículos relacionados
    VSCodium – Free/Libre Open Source Software Binaries of VS Code - https://news.ycombinator.com/item?id=31604932 - junio de 2022, 430 comentarios
    VS Code without Microsoft branding/telemetry/licensing - https://news.ycombinator.com/item?id=23447413 - junio de 2020, 200 comentarios
    VSCodium – An Open Source Visual Studio Code Without Trackers - https://news.ycombinator.com/item?id=19650109 - abril de 2019, 253 comentarios
    VSCodium: 100% Open Source Version of vs. Code - https://news.ycombinator.com/item?id=19619956 - abril de 2019, 8 comentarios
    VSCodium: Binary releases of VSCode without MS branding, telemetry and licensing - https://news.ycombinator.com/item?id=17850960 - agosto de 2018, 113 comentarios

  • Lo usé durante mucho tiempo y le dije al equipo que también lo usara, pero al final me rendí. Sin las funciones de Remote SSH y devcontainers, Microsoft tiene un fuerte control sobre quienes quieren sacarle el máximo provecho a VSCode
    Además, parece que Microsoft dio marcha atrás con la telemetría, y ahora dicen que se puede desactivar por completo. Aunque no probé personalmente si “desactivado” realmente significa eso

    • La extensión oficial de devcontainer delega la mayor parte del trabajo clave en la devcontainer CLI de código abierto, así que se puede usar fuera de cualquier IDE
      Además, si usas Remote OSS puedes usar un host remoto de vscodium dentro de un dev container. Escribí más detalles en este comentario: https://news.ycombinator.com/item?id=37386025

  • Uso tanto VSCode como VSCodium. La razón es simple y práctica: gestión de configuración y varias ventanas distinguibles
    Mi VSCode está completamente invadido por una cantidad enorme de extensiones que parecen necesarias para trabajo con Microchip/Atmel/zephyr
    Para trabajos con ansible/elixir uso VSCodium

    • Parece una forma bastante complicada de mantener dos entornos distintos
      ¿VSCodium no tiene una función como los perfiles de navegador, donde se puedan cambiar todo tipo de configuraciones solo dentro de ese perfil? En Firefox lo uso seguido de esa forma, y también dejo las ventanas con apariencias distintas

  • Espero que lo sigan manteniendo. La extensión de nuestra startup está en Open VSX Registry, y estamos muy satisfechos operando así

  • En Arch hay algo que parece ser un paquete equivalente, simplemente con el nombre code

    • code es el nombre del binario, y el “proyecto” en sí es Code - OSS, como se indica en https://wiki.archlinux.org/title/Visual_Studio_Code
      Ese es el paquete que ofrece el repositorio principal, y si quieres usar VSCodium o Visual Studio Code tienes que usar AUR