VSCodium – das Open-Source-Binärpaket von VSCode

 (vscodium.com)
2 Punkte von GN⁺ 2023-09-05 | 1 Kommentare | Auf WhatsApp teilen
  • Da der VS Code-Quellcode und die offizielle Distribution unterschiedlichen Bedingungen unterliegen, ist VSCodium eine Alternative für Nutzer, die direkt ein MIT-lizenziertes Binärpaket erhalten möchten
  • Der vscode-Quellcode von Microsoft steht unter der MIT-Lizenz, aber das herunterladbare Produkt Visual Studio Code enthält eine separate Lizenz sowie Telemetrie/Tracking
  • VSCodium übernimmt den Distributionsprozess mit automatisierten Skripten, die das vscode-Repository von Microsoft bauen und die resultierenden Binärdateien in GitHub Releases veröffentlichen
  • Die bereitgestellten Binärdateien haben deaktivierte Telemetrie, und aktuelle Releases sind für Windows, Mac OS und Linux verfügbar
  • Die Installation ist über verschiedene Paketmanager möglich, darunter Homebrew, WinGet, Chocolatey, Scoop, Snap, Nixpkgs, AUR, deb/rpm-Repositories und Flatpak

Unterschiede zwischen dem VS Code-Quellcode und der Microsoft-Distribution

  • VSCodium ist eine freie/Open-Source-Binärdistribution auf Basis von Microsofts VS Code
  • Der vscode-Quellcode von Microsoft steht unter der MIT-Lizenz, aber das von Microsoft vertriebene Produkt Visual Studio Code verwendet eine nicht-FLOSS-Lizenz und enthält Telemetrie/Tracking
  • Der von Microsoft verteilte Build entsteht, indem das vscode-Repository geklont und anschließend product.json mit Microsoft-spezifischen Funktionen angewendet wird
    • Zu diesen Microsoft-spezifischen Funktionen gehören Telemetrie, Gallery, Logo usw.
    • Wenn man direkt mit dem Standard-product.json baut, entsteht ein „cleaner“ Build ohne Microsoft-Anpassungen, auf den standardmäßig die MIT-Lizenz angewendet wird

Build- und Distributionsweise von VSCodium

  • VSCodium ermöglicht es, einen MIT-lizenzierten Build zu beziehen, ohne dass Nutzer den Quellcode selbst herunterladen und bauen müssen
  • Die Build-Skripte klonen das vscode-Repository von Microsoft, führen die Build-Befehle aus und laden die resultierenden Binärdateien in GitHub Releases hoch
  • Die VSCodium-Binärdateien stehen unter der MIT-Lizenz und haben deaktivierte Telemetrie
  • Wer selbst bauen möchte, kann das vscode-Repository und die Build-Anleitungen von Microsoft verwenden
  • Aktuelle Releases werden für Windows, Mac OS und Linux bereitgestellt

Installation nach Paketmanager

  • Bei Verwendung von Homebrew auf dem Mac: 
    brew install --cask vscodium
  • Unter Windows können mehrere Paketmanager verwendet werden
    • WinGet 
      winget install vscodium
    • Chocolatey 
      choco install vscodium
    • Scoop 
      scoop bucket add extras
scoop install vscodium
  • Unter Linux ist die Installation über Snap, Nixpkgs, AUR, Flatpak usw. möglich
    • Im Snap Store wird es unter dem Namen Codium angeboten 
      snap install codium --classic
    • Unter Nix(OS) kann vscodium zu environment.systemPackages hinzugefügt oder lokal installiert werden 
      nix-env -iA nixpkgs.vscodium
    • Unter Arch Linux kann das AUR-Paket vscodium-bin mit einem AUR-Helper installiert werden 
      yay -S vscodium-bin

Installation über Distributionen und Repositories

  • Auf Parrot OS ist VSCodium standardmäßig vorinstalliert
    • Falls es nicht standardmäßig sichtbar ist, kann es aus dem offiziellen Parrot-Repository installiert werden 
      sudo apt update && sudo apt install codium
  • deb-Pakete für Debian/Ubuntu werden über VSCodium-bezogene Repositories und CDN-Mirrors installiert
    • Nach dem Hinzufügen des GPG-Schlüssels für das Repository wird die passende Repository-Konfiguration für die jeweilige Debian-/Ubuntu-Version ergänzt
    • Der Installationsbefehl lautet wie folgt 
      sudo apt update && sudo apt install codium
    • Wenn vscodium-insiders gewünscht ist, wird codium durch codium-insiders ersetzt
  • rpm-Pakete für Fedora/RHEL/CentOS/Rocky Linux/OpenSUSE werden ebenfalls durch Hinzufügen separater Repositories installiert
    • Fedora/RHEL/CentOS/Rocky Linux: 
      sudo dnf install codium
    • OpenSUSE/SUSE: 
      sudo zypper in codium
  • Unter Gentoo/Funtoo erfolgt die Installation per ebuild
    • Funtoo: 
      sudo emerge -av vscodium-bin
    • Gentoo: 
      sudo emerge -av vscodium

Flatpak und Migrationsdokumentation

  • VSCodium ist auch als Flatpak-App verfügbar; das Build-Repository ist flathub/com.vscodium.codium
  • In Umgebungen mit aktiviertem Flathub-Repository kann die Installation mit folgendem Befehl erfolgen 
    flatpak install flathub com.vscodium.codium
  • Wenn gnome-software-plugin-flatpak installiert ist, lässt sich VSCodium auch in GNOME Software finden
  • Besonderheiten, die bei der Migration von Visual Studio Code zu VSCodium oder bei der Nutzung auftreten können, sind in der Dokumentation zusammengefasst

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-05
Meinungen auf Hacker News

  • Binaries, die von solchen Projekten erstellt werden, wirken für mich schwerer vertrauenswürdig als die von Big Tech bereitgestellten Binaries. Big Tech gehört zwar zu den größten Trackern, aber Projekte mit deutlich weniger Personal und Interessenbindungen scheinen anfälliger für Supply-Chain-Angriffe oder feindliche Übernahmen zu sein, falls Entwickler das Projekt verkaufen
    Ich kenne mich in diesem Bereich nicht besonders gut aus, daher wären Referenzen hilfreich, wie solche Projekte diese Risiken vermeiden; vielleicht ist diese Sorge ja berechtigt

    • Diese Sorge ist völlig berechtigt. Das soll keine Bewertung dieses konkreten Projekts sein, aber es ist schwierig, den Prozess vertrauenswürdig zu machen, bei dem man das Original nimmt, verändert und neu verteilt
      Große Unternehmen betreiben extremen Aufwand, um die Vertrauenskette der von ihnen gebauten Software sicherzustellen, und auch App-Distributionsplattformen investieren viel, um eine Ende-zu-Ende-Vertrauenskette vom Entwickler bis zur App zu gewährleisten, die auf dem Gerät des Nutzers läuft
      Ohne sowohl dem ursprünglichen Autor als auch dem Weiterverteiler zu vertrauen, ist das grundsätzlich kaum möglich; überprüfbare Build-Verfahren, die Prüfung von Signaturschlüsseln und Hashes sowie erneutes Signieren verringern jedoch das erforderliche Maß an Vertrauen. Wenn Nutzer theoretisch denselben Build selbst reproduzieren können, wird er leichter vertrauenswürdig
      Die beste Option wäre, dass das ursprüngliche Projekt selbst Builds ohne Branding bereitstellt und Projekte wie VSCodium nur noch reine Konfiguration sind, etwa zum Deaktivieren von Telemetrie, sodass kein erneutes Signieren nötig ist. Das Chromium-Projekt zum Beispiel verteilt selbst Chromium-Binaries ohne Google-spezifische Elemente
      Ich hatte dabei vor allem App Stores im Kopf, aber auf Orte wie Debian-Paket-Repositories trifft fast dieselbe Logik zu. App Stores signieren in der Regel in der Mitte neu, weshalb man dem Store vertrauen muss; solche Unternehmen investieren aber viel Aufwand, um die Vertrauenswürdigkeit an dieser Stelle sicherzustellen
    • Theoretisch gilt: Wenn ein solches Projekt mit GitHub Actions baut und man Microsofts Sicherheit vertraut, kann man den Commit-Hash aus der Action prüfen und die Unterschiede zum Upstream vergleichen
      Wenn diese Unterschiede sicher wirken, heißt das ungefähr, dass man auch dem Binary vertrauen kann. Natürlich muss man auch prüfen, dass keine Internet-Ressourcen eingebunden werden, deren Integrität nicht auf dieselbe Weise gewährleistet werden kann
    • Ich habe gerade vscodium auf einer Manjaro-Maschine installiert, und es wurde aus den AUR-Quellen gebaut
      Man sollte den vom Paket verwendeten Quellcode mit dem Upstream-Microsoft-Git-SHA vergleichen können, auf dem es angeblich basiert: https://aur.archlinux.org/packages/vscodium
      Passenderweise gibt es jetzt auch eine Open-Source-Remote-Mode-Erweiterung, sodass es keinen Grund mehr gibt, die proprietäre Version zu verwenden. Bei mir gibt es keine Telemetrie mehr
    • Wenn ich mir ansehe, wie die Tech-Branche heute aussieht, und nachdem ich darin gearbeitet habe, sehe ich es eher umgekehrt
      Ich habe keinerlei Vertrauen, dass große Unternehmen etwas ordentlich machen und ihre Anwendungen nicht unter dem Namen Telemetrie mit Spyware vollstopfen. Dann vertraue ich lieber Menschen, die hartnäckig daran arbeiten, freie und Open-Source-Software zu schaffen
    • Ich vertraue derzeit ebenfalls eher dem ursprünglichen Entwicklungsunternehmen. Es wäre gut, mehr Optionen zu haben
      Reproduzierbare Builds könnten hier helfen, wie Go es im aktuellen SDK gemacht hat: https://go.dev/blog/rebuild
      Bei einem Fork mit wenigen Quelländerungen ist das besonders wirksam, weil man nur die Patches prüfen muss
      Linux-Distributionen sind ziemlich ähnlich. Debian-Paketen vertraue ich im Großen und Ganzen, weil es eine Dachorganisation und Prozesse gibt. Bei unabhängigen Organisationen ist das weniger der Fall
      Vielleicht gibt es irgendwann eine Dachorganisation, die nur für reproduzierbare Builds zuständig ist, und Menschen könnten darüber Binaries verteilen. Wie bei Domain-Registraren könnte unabhängige Prüfung diese Organisation ehrlich halten

  • Microsoft hat wichtige Erweiterungen darauf beschränkt, dass sie nur in den offiziellen Releases verwendet werden können, und damit Konkurrenz in diese Richtung beseitigt. Ich persönlich nutze Remote-Erweiterungen ziemlich häufig, und es wäre schön, wenn jemand eine Alternative anbieten würde.

    • Heute habe ich Glück.
      „Open Remote - SSH“ von „jeanp413“, also @ext:jeanp413.open-remote-ssh, funktioniert zumindest bei mir genauso wie die Closed-Source-Erweiterung.
      Ich nutze das vscodium-AUR-Paket unter Manjaro und habe die Erweiterung aus dem Standard-Store von vscodium bezogen. Ob sie im Microsoft Store verfügbar ist, weiß ich nicht.
      Unter Code - OSS hat diese Erweiterung bei mir nicht funktioniert; es sah nach einem Konfigurationsfehler aus, aber ich habe es nicht weiter verfolgt.
    • In der Dokumentation steht, wie man wieder auf den offiziellen Extension Marketplace umstellt: https://github.com/VSCodium/vscodium/blob/master/DOCS.md#how...
      Wenn es also eine unverzichtbare Erweiterung gibt, die nicht im Codium-Marketplace ist, kann man sie weiterhin über den Microsoft Marketplace nutzen.
    • Ich habe angefangen, Remote OSS zu verwenden, zusammen mit einem Custom Script, das den Remote-Code-Host installiert und startet. Es funktioniert auch auf Remote-Servern gut und passt gut zu devcontainers auf dem Remote-Host.
      Um Installation und Konfiguration des Tunnels automatisch zu erledigen, kann man so etwas wie dieses Script verwenden: https://github.com/CGamesPlay/dotfiles/blob/master/files/.lo...
      Ich arbeite außerdem an einem PR, der eine Möglichkeit hinzufügt, automatisch ein Custom Script auszuführen, um den Tunnel einzurichten: https://github.com/xaberus/vscode-remote-oss/pull/9
      Remote OSS: https://open-vsx.org/extension/xaberus/remote-oss
    • Die Alternative ist meiner Ansicht nach schlicht, VS Code nicht zu benutzen. Auf der Arbeit nutze ich es, weil die IT-Abteilung es offiziell unterstützt und mir das Tracking dort egal ist, aber für private Projekte verwende ich weiterhin Sublime.
    • Es gibt https://open-vsx.org/extension/jeanp413/open-remote-ssh und https://open-vsx.org/extension/jeanp413/open-remote-wsl.

  • Das ist im Grunde dasselbe, was man erhält, wenn man den Quellcode von Visual Studio Code herunterlädt und baut.
    Auch der Name wirkt wie ein Wortspiel à la Chrome → Chromium.
    Die Praxis von Microsoft und Google, ihre Produkte angeblich zu „Open Source“ zu machen, während sie in Wirklichkeit Produkte mit zusätzlichen Closed-Source-Funktionen veröffentlichen, ist im besten Fall unehrlich und im schlimmsten Fall Stoff für eine riesige Klage.

    • 100 % richtig. Google und Apple haben diesen Trend begonnen, MS hat ihn perfektioniert. Sie sagen, sie würden ein „Open-Source“-Produkt schaffen, bringen tatsächlich aber eine Closed-Source-Version heraus.
      Diese Großkonzerne profitieren von der Arbeit naiver Software Engineers, die ihre Zeit Open-Source-Produkten spenden, liefern den Endnutzern aber eine Closed-Source-Version aus.
    • Ich verstehe nicht, was daran unehrlich sein soll oder wofür man klagen würde. „Sie haben das Produkt als Open Source veröffentlicht und kostenlos verteilt, aber es ist nicht so, wie ich es gern hätte“ scheint als Klagegrund schwierig zu sein.
    • „Stoff für eine riesige Klage“ ist eine ziemlich gewagte Behauptung. Solange vscode oder andere Produkte keinen GPL-lizenzierten Code unzulässig verwenden oder Lizenzbedingungen verletzen, macht Microsoft zumindest meines Wissens nichts falsch.
      Das ist derselbe Fall wie bei unzähligen kommerziellen Firmen, die proprietäre Software auf Basis von Open-Source-Projekten veröffentlichen.
    • Das ist ein Modell der offenen Enshittification.
    • Ich finde, der Begriff „Open Source“ wird hier ziemlich fair verwendet. Andere können den Quellcode nehmen und, abgesehen vielleicht von der Telemetrie, legal nahezu identische Builds verteilen.
      Was es braucht, ist eher eine Kennzeichnung von Anti-Features wie im F-Droid-Store. Zum Beispiel Hinweise wie „Diese App hängt von anderen unfreien Apps ab“ oder „Sie hängt von unfreien Netzwerkdiensten ab oder fördert diese“.

  • Vscode wurde so entworfen, dass es Fragmentierung herbeiführt: https://ghuntley.com/fracture/

    • Das wurde bereits 2022 diskutiert: https://news.ycombinator.com/item?id=32657709
      Kurz gesagt: Microsoft hat Visual Studio Code mit eingebauter Telemetrie veröffentlicht, weshalb Projekte wie VSCodium begannen, eigene Builds ohne Telemetrie bereitzustellen. Da diese Projekte jedoch nicht unter Microsofts Lizenz stehen, können sie nicht denselben Marketplace verwenden, und genau das ist die Fragmentierung aus dem Titel.
      Danach heißt es, andere proprietäre IDEs hätten ebenfalls Probleme, und GitHub sei eine Falle, die Entwickler einfängt und fragmentiert.
      Dieses Drama rund um Microsoft und Open Source erinnert an die Halloween-Dokumente: http://www.catb.org/~esr/halloween/
    • Der Kern, zu dem der Artikel letztlich gelangt, ist, dass Microsoft die beste IDE und die besten Erweiterungen gebaut hat und es deshalb schwer geworden ist, Microsoft nicht zu nutzen. Das hat mehrere unschöne Implikationen.
      Ähm … ja? Dann nutzt man es eben oder nicht. Ich bin mir nicht sicher, ob „es ist so gut, dass man es kaum nicht nutzen kann“ eine berechtigte Beschwerde ist.
    • Nach dieser Definition fällt es wirklich schwer, ein erweiterbares Produkt oder eines, das Erweiterungen zulässt, zu nennen, das nicht so entworfen wurde, dass es Fragmentierung herbeiführt.

  • Gestern musste ich vom Open-Source-Build wechseln. Nach dem Update sah es so aus, als hätte Pylance wegen DRM aufgehört zu funktionieren
    Bei jedem Start zeigte es eine große Warnung an, dass die Nutzung in einem nicht von MS genehmigten Build einen Lizenzverstoß darstellt, und stoppte dann sofort

    • Stattdessen kann man pyright verwenden: https://github.com/microsoft/pyright
      Es ist die freie Open-Source-Version von pyright, allerdings fehlen einige Funktionen
    • Das klingt nach einem Grund, Pylance nicht zu verwenden

  • Verwandte Beiträge
    VSCodium – Free/Libre Open Source Software Binaries of VS Code - https://news.ycombinator.com/item?id=31604932 - Juni 2022, 430 Kommentare
    VS Code without Microsoft branding/telemetry/licensing - https://news.ycombinator.com/item?id=23447413 - Juni 2020, 200 Kommentare
    VSCodium – An Open Source Visual Studio Code Without Trackers - https://news.ycombinator.com/item?id=19650109 - April 2019, 253 Kommentare
    VSCodium: 100% Open Source Version of vs. Code - https://news.ycombinator.com/item?id=19619956 - April 2019, 8 Kommentare
    VSCodium: Binary releases of VSCode without MS branding, telemetry and licensing - https://news.ycombinator.com/item?id=17850960 - August 2018, 113 Kommentare

  • Ich habe es lange genutzt und auch meinem Team empfohlen, bin am Ende aber davon abgekommen. Ohne Remote SSH und devcontainers hält Microsoft einen stark fest, wenn man VSCode möglichst umfassend nutzen will
    Außerdem scheint Microsoft bei der Telemetrie zurückgerudert zu sein, und angeblich kann man sie jetzt vollständig deaktivieren. Allerdings habe ich nicht selbst getestet, ob „aus“ wirklich aus ist

    • Die offizielle devcontainer-Erweiterung erledigt den Großteil der Kernarbeit über die Open-Source-devcontainer CLI, sodass sie auch außerhalb einer IDE genutzt werden kann
      Außerdem kann man mit Remote OSS einen vscodium-Remote-Host in einem dev container verwenden. Mehr dazu habe ich in diesem Kommentar geschrieben: https://news.ycombinator.com/item?id=37386025

  • Ich nutze sowohl VSCode als auch VSCodium. Der Grund ist einfach und praktisch: Konfigurationsverwaltung und unterscheidbare mehrere Fenster
    Mein VSCode ist vollständig von der enormen Menge an Erweiterungen vereinnahmt, die für Microchip/Atmel/zephyr-Arbeiten nötig zu sein scheinen
    Für ansible/elixir-Arbeiten nutze ich VSCodium

    • Das klingt nach ziemlich viel Aufwand, um zwei verschiedene Umgebungen zu pflegen
      Hat VSCodium keine Funktion wie Browser-Profile, bei der man innerhalb dieses Profils alle möglichen Einstellungen ändern kann? In Firefox nutze ich das häufig so und lasse die Fenster auch unterschiedlich aussehen

  • Ich hoffe, es wird weiter gepflegt. Die Erweiterung unseres Startups liegt im Open VSX Registry, und wir sind sehr zufrieden damit, es so zu betreiben

  • Unter Arch gibt es ein anscheinend gleichwertiges Paket einfach unter dem Namen code

    • code ist der Name des Binaries, und das „Projekt“ selbst heißt, wie unter https://wiki.archlinux.org/title/Visual_Studio_Code beschrieben, Code - OSS
      Das ist das Paket aus dem Haupt-Repository; wenn man VSCodium oder Visual Studio Code verwenden möchte, muss man AUR nutzen