VSCode unter Linux (openSUSE Tumbleweed)

[Markus W. (dl8mby)]

Hallo Forum,

wollte etwas mit dem LILYGO T-Display-S3 CAP. (ESP-32-S3) spielen.
Auf der LILYGO Seite wird dafür VSCode von Microsoft empfohlen.

Dafür gibt es sogar ein Repo direkt mit rpm Paketen.

Nun meine Frage, würdet Ihr das Paket auf Eurem Linux installieren
oder eher ein anderes Tool verwenden, z.B. die Arduino GUI.

Im Forum konnte ich Beiträge finden, von Leuten, die VSCode unter
Linux verwenden, mit mehr oder weniger Problemen. Beiträge waren
zum Teil von 2019 und 2022.

Ist das MS Paket für Linux mittlerweile verlässlicher und seriös?

Traut Ihr dem Paket und kann man damit bedenkenlos arbeiten?

Danke für Eure Einschätzung - und bitte nicht gleich steinigen -
gilt für die MS Fraktion hier im Forum.

Gruß
Markus

[Monk (roehrmond)]

Markus W. schrieb:
> Ist das MS Paket für Linux mittlerweile verlässlicher und seriös?

Ist sie. Wir nutzen die IDE auf der Arbeit mit der Programmiersprache Go 
unter Linux.  Die Plugins ThunderClient und der Swagger Editor 
überzeugen für REST Schnittstellen.

Eine Zeitlang haben wir sie auch erfolgreich für Java verwendet, aber 
IntelliJ IDEA ist besser.

Zu Hause nutze ich vscode mit dem Arduino Plugin von Microsoft, um 
ESP8266 Module zu programmieren. Bei C++ bevorzuge ich sonst die Qt 
Creator IDE, aber Microsofts Arduino Integration ist echt gut.

[Markus W. (dl8mby)]

@Monk,

danke für Deinen schnellen Feedback.

Den QT-Creator habe ich auch auf dem System für diverse
C und C++ Projekte im Einsatz.

Bei der ESP32 (sicherlich auch bei ESP8266) brauchst man ja
eine komplette Toolchain um nicht nur zu editieren und compilieren
und linken sondern auch zu debuggen und zu flashen.

Kann das alles in die VSCode GUI einfach integriert werden?
(Wahrscheinlich über Plugins?)

Markus

[Markus W. (dl8mby)]

Habe jetzt das VSCode Paket installiert.

>zypper info code
Loading repository data...
Reading installed packages...


Information for package code:
-----------------------------
Repository     : Visual Studio Code
Name           : code
Version        : 1.93.1-1726079369.el8
Arch           : x86_64
Vendor         : Microsoft Corporation
Installed Size : 384.8 MiB
Installed      : No
Status         : not installed
Source package : code-1.93.1-1726079369.el8.src
Upstream URL   : https://code.visualstudio.com/
Summary        : Code editing. Redefined.
Description    : 
    Visual Studio Code is a new choice of tool that combines the simplicity of a code editor with what developers
    need for the core edit-build-debug cycle. See https://code.visualstudio.com/docs/setup/linux for installation

...

>zypper install code
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  code

1 new package to install.

Package download size:   137.2 MiB

Package install size change:
              |     384.8 MiB  required by to be installed packages
   384.8 MiB  |  -      0 B    released by to be removed packages

Backend:  classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): y
Retrieving: code-1.93.1-1726079369.el8.x86_64 (Visual Studio Code)                              (1/1), 137.2 MiB    
Retrieving: code-1.93.1-1726079369.el8.x86_64.rpm ................................................[done (5.7 MiB/s)]

Scheint nicht so groß zu sein.

Welch Plugins sind neben dem MS Arduino sinvoll, wenn man z.B.
auch Python Code für die kleinen ESP-X Module schreiben will?

Markus

[Monk (roehrmond)]

Markus W. schrieb:
> Bei der ESP32 (sicherlich auch bei ESP8266) brauchst man ja
> eine komplette Toolchain um nicht nur zu editieren und compilieren
> und linken sondern auch zu debuggen und zu flashen.

Ja. Allerdings kannst du Qt Creator als "besseren" Editor neben der 
Arduino IDE benutzen. Compilieren tut dann die Arduino IDE.

Bei vscode ist Arduino hingegen sauber integriert. Das Plugin lädt bei 
Bedarf die Arduino cli herunter und benutzt sie unter der Haube. Der 
Board-Manager wurde nachgebaut, auch die Examples sind direkt in vscode 
verfügbar (wenn auch erwas versteckt).

Für Python gibt es ein gutes Plugin direkt von Microsoft: 
https://code.visualstudio.com/docs/languages/python

Generell würde ich immer zuerst die Plugins von Microsoft versuchen, 
falls es mehrere Alternativen gibt. Weil ich bisher von allen positiv 
beeindruckt war.

[Markus W. (dl8mby)]

@Monk,

danke für die Hinweise/Links, werde ich mir ansehen.

Im Augenblick bin ich an so trivialen Dingen dran, wie
man die GUI an einen UHD Output anpasst, so dass die
Elemente gut sichtbar sind.

Die Textgröße im Editor ist ja noch trivial, aber wie vergrößere
ich die GUI Elemente, dass sie auf dem UHD Display besser
zu lesen sind?

Wühle in den Settings rum, habe aber noch nichts gefunden.
Gibt es einen Skalierungsfaktor, den man setzen kann?

Markus

[Harald K. (kirnbichler)]

Markus W. schrieb:
> Ist das MS Paket für Linux mittlerweile verlässlicher und seriös?
>
> Traut Ihr dem Paket und kann man damit bedenkenlos arbeiten?

Du kannst das Ding auch aus den Sourcen übersetzen. Möchte man es z.B. 
unter einem echten Unix wie FreeBSD verwenden, ist das auch der einzige 
Weg, da 'ranzukommen, weil es davon kein fertiges Paket gibt. Mit der 
"Ports"-Umgebung ist das aber kein Problem.

Da gibts die Sourcen:
https://github.com/microsoft/vscode

Eine Einstellung würde ich in der Konfigurationsdatei settings.json auf 
jeden Fall vornehmen:

  "telemetry.telemetryLevel": "off"

Denn "telemetry" braucht niemand.

Hilfreich ist die vscode-Extension "C/C++ Intellisense", die bietet 
einem Syntaxhighlighting, Codevervollständigung und mehr.

Der muss man in der Datei c_cpp_properties.json die Pfade auf die 
verwendeeten Sourcen, Compilerincludes etc. beibiegen, dann funktioniert 
das wunderbar.
Das geschieht dort unter "includePath", da kann in Json-Manier eine 
Liste von Verzeichnissen eingetragen werden:

{
  "configurations":
  [
    {
    "name": "meinkram",
    "includePath":
    [
      "/usr/include",
      "/usr/lib"
    ],
    "defines":
    [
      "DEBUG",
      "SONSTWAS"
    ]
    }
  ],
  "version": 4
}

So sieht das beispielsweise aus; wenn man Dinge mit bedingter 
Compilation macht, kann man die Symbole auch hier eintragen, dann kommt 
der Intellisense-Mechanismus bestens damit zurecht.

Auch wenn man #include-Dateien verwendet, die via Compilerparameter 
angegeben werden (und nicht im Sourcecode eingebunden werden), kann man 
sie hier mit "forcedInclude" angeben.

Markus W. schrieb:
> oder eher ein anderes Tool verwenden, z.B. die Arduino GUI.

Diese "GUI" ist auch in der 2.x-Version so derb rudimentär, daß der 
Vergleich zu vscode praktisch immer zugunsten von vscode ausfällt.

Was VsCode zur Perfektion fehlt, ist virtual whitespace.

[Markus W. (dl8mby)]

@Harald K.

Genau so was habe ich gemeint, bei meiner Frage,

danke für den Hinweis.

>"telemetry.telemetryLevel": "off"

Hast Du was zu meinem UHD Darstellungs-Problem einen Rat?

Markus

[Florian S. (sevenacids)]

Also wenn schon Visual Studio Code unter Linux, dann bitte in Form von 
VSCodium. Das sind freie Visual Studio Code-Binärdateien basierend auf 
den unter MIT stehenden Quellen ohne proprietäre 
Microsoft-Modifizierungen, wie Telemetrie und Tracking. Die verfügbaren 
Plug-Ins funktionieren auch damit. Gibt dazu ein Repo über GitLab, auch 
für OpenSUSE.

[Markus W. (dl8mby)]

Bei mir steht die json config unter

>find . -name \*settings.json\* | grep vscode
/usr/share/texmf/context/data/vscode/settings.json

Falls es jemanden auch interessieren sollte.

Danke für den Hinweis auf VSCodium von Florian S.

Werde ich mir auch ansehen. War bis dato nicht bekannt.

LG
Markus


Das o.g. setting zur telemetry stand bei mir garnicht drin.

   "telemetry.enableCrashReporter": false,
   "telemetry.enableTelemetry": false,
   "telemetry.telemetryLevel": "off",

hebe ich jetzt eingefügt.

[Monk (roehrmond)]

Markus W. schrieb:
> Die Textgröße im Editor ist ja noch trivial, aber wie vergrößere
> ich die GUI Elemente, dass sie auf dem UHD Display besser
> zu lesen sind?

Ich würde die Einstellung im Linux Desktop suchen, nicht in einzelnen 
Anwendungsprogrammen.

Diesbezüglich hat Gnome 47 gerade die Unterstützung für "Krumme" 
Vergrößerungsfaktoren erhalten.

[Markus W. (dl8mby)]

@Monk,

bei mir passen die anderen Programme bei der Darstellung auf dem UHD
Display, deshalb habe ich im Anhang das darunterliegende Fenster mit
abgebildet.
Diese Einstellung habe ich in der Window-Manager Config vorgenommen.
Offensichtlich verwendet VSCode diesen Wert nicht.

Während ich das schreibe, habe ich mir QT-Creator aufgerufen und
sehe, dass die Darstellung dort auch vergleichbar klein ist,
siehe Anhang, allerdings nicht bei den Windows-Menus, sondern bei
den QTC GUI-Elementen. War aber vor einigen Wochen noch nicht so.

Eventuell hat da ein Update des OS wieder was verändert.
Muss ich weiter suchen.

LG
Markus

[Markus W. (dl8mby)]

@Harald K

Bei meiner VSCode Installation gibt es keine

c_cpp_properties.json

Datei

sondern nur eine

~/.vscode/extensions/ms-vscode.cpptools-1.21.6-linux-x64/c_cpp_propertie 
s.schema.json,

nach der Installation des Plugins "C/C++ Intellisense".


Darin findet sich der json Block

>cat c_cpp_properties.schema.json
{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "definitions": {
        "configurations": {
            "type": "array",
            "items": {
                "type": "object",
                "required": [
                    "name"
                ],
                "properties": {
                    "name": {
                        "markdownDescription": "Configuration identifier. `Mac`, `Linux`, and `Win32` are special identifiers for configurations that will be auto-selected on those platforms, but the identifier can be anything.",
                        "descriptionHint": "Markdown text between `` should not be translated or localized (they represent literal text) and the capitalization, spacing, and punctuation (including the ``) should not be altered.",
                        "type": "string"
                    },
                    "compilerPath": {
                        "markdownDescription": "Full path of the compiler being used, e.g. `/usr/bin/gcc`, to enable more accurate IntelliSense.",
                        "descriptionHint": "Markdown text between `` should not be translated or localized (they represent literal text) and the capitalization, spacing, and punctuation (including the ``) should not be altered.",
                        "type": "string"
                    },
                    "compilerArgs": {
                        "markdownDescription": "Compiler arguments to modify the includes or defines used, e.g. `-nostdinc++`, `-m32`, etc. Arguments that take additional space-delimited arguments should be entered as separate arguments in the array, e.g. for `--sysroot <arg>` use `\"--sysroot\", \"<arg>\"`.",
                        "descriptionHint": "Markdown text between `` should not be translated or localized (they represent literal text) and the capitalization, spacing, and punctuation (including the ``) should not be altered, except potentially the `arg` text which is a placeholder and not literal text, i.e. an abbreviation for `argument`.",
                        "type": "array",
                        "items": {
                            "type": "string"
                        }
                    },


...

                    "includePath": {
                        "markdownDescription": "A list of paths for the IntelliSense engine to use while searching for included headers. Searching on these paths is not recursive. Specify `**` to indicate recursive search. For example, `${workspaceFolder}/**` will search through all subdirectories while `${workspaceFolder}` will not. Usually, this should not include system includes; instead, set `C_Cpp.default.compilerPath`.",
                        "descriptionHint": "Markdown text between `` should not be translated or localized (they represent literal text) and the capitalization, spacing, and punctuation (including the ``) should not be altered.",
                        "type": "array",
                        "items": {
                            "type": "string"
                        }
                    },
...

Dieser Bereich - letzter Block - muss wohl angepasst werden.


Markus

[Harald K. (kirnbichler)]

Markus W. schrieb:
> Bei meiner VSCode Installation gibt es keine
>
> c_cpp_properties.json

Die gehört in das Verzeichnis .vscode innerhalb Deines Projektes.

Hier gibts Dokumentation dazu:
https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference

Die von Dir gefundene Datei solltest Du hingegen nicht anfassen. Die 
steuert das UI für die Bearbeitung von c_cpp_properties.json, wie hier 
beschrieben:

https://code.visualstudio.com/docs/cpp/configure-intellisense

Bei Deinem Monitorproblem kann ich Dir nicht helfen, ich steuere meine 
Monitore mit ihrer nativen Auflösung und 100%-Skalierung an.

[Markus W. (dl8mby)]

Danke Harald K.

Habe mir gerade die ESP IDF Umgebung installiert und das
ESP-IDF Plugin im VSCodium (VSCode habe ich entfernt!)

Was mich etwas irritiert, das man kein Projekt anlegt, oder ist
Workspace ein Synonym für ein Projekt?

Man legt ja erst ein Projekt an, definiert den Type (C, C++, Python,
etc) und fügt anschließend bestehende oder erzeugt neue Files zum
Projekt hinzu.

Hast Du eine Brauchbare Beschreibung, wie man ein ESP Projekt
in VSCode anlegt um dann die "idf.py build" und "idf.py flash"
Kommandos durchlaufen lassen zu können.

Danke im Voraus für Deine Mühe.

Markus

Ok, da gibt es einiges zum Lesen

z.B.

https://code.visualstudio.com/docs/cpp/configure-intellisense#_option-1-select-a-configuration-option-through-the-configuration-quick-pick

oder auch:

https://randomnerdtutorials.com/vs-code-platformio-ide-esp32-esp8266-arduino/

[Monk (roehrmond)]

Markus W. schrieb:
> Was mich etwas irritiert, das man kein Projekt anlegt

In vscode öffnet man einfach entweder einzelne Dateien oder 
Projektverzeichnisse. Ein Verzeichnis mit einer *.ino Datei wird z.B 
automagisch als Arduino Projekt erkannt.

Sobald du Projekt-spezifische Settings änderst, legt die IDE das 
Unterverzeichnis .vscode an und speichert es dort im JSON Format. Man 
kann dort auch ruhig manuell Dateien anlegen und ändern. Das bietet sich 
an, wenn man Settings von einem bestehenden Projekt oder dem Internet 
kopieren will.

Wenn du irgendwelche Funktionen im Menü vermisst, drücke strg+shift+P 
und tippe ein, wonach du suchst. Dort gibt es zahlreiche weitere 
Funktionen mit Suche. Das ist in der IDE die einzige ungewöhnliche 
Tastenkombibation, die ich jeden Tag benutze.

[Markus W. (dl8mby)]

Nun habe ich das Problem, dass offensichtlich die
platformio Extension nicht fuer VSCodeium sondern
nur für VSCode existiert.
Oder hat jemand eine Möglichkeit gefunden, platformio
in VSCodium zu laden.

War wohl voreilig mit dem Löschen des VSCode Paketes.

Falls es in VSCodium nicht ladbar ist muss ich wohl wieder
zu dem MS Paket zurueck :-(

Markus

[Monk (roehrmond)]

Brauchst du denn Platformio? Reicht dir nicht das Arduino Plugin?

Ich frage, weil Platformio an der Komplexität der vielen Dependencies zu 
ersticken droht. Von Eierlegenden Wollmilchsäuen halte ich wenig. 
Arduino als Über-Framework über dem IDF (bzw. HAL bri ST) ist mur schon 
fast zu viel. Platformio setzt ja noch einen Layer drauf.

[Harald K. (kirnbichler)]

Markus W. schrieb:
> Was mich etwas irritiert, das man kein Projekt anlegt, oder ist
> Workspace ein Synonym für ein Projekt?

Ich mache mit vscode andere Dinge als Du, daher ist meine Vorgehensweise 
vielleicht nicht die richtige für Dich.


Ein neues Projekt lege ich an, indem ich ein Verzeichnis anlege, und in 
das eine Art "Schablone" für Projekte reinkopiere.

Die besteht bei mir aus einem simplen helloworld.c, einer Schablone für 
CMakeFiles.txt, und einem Unterverzeichnis namens .vscode, in das ich 
meine c_cpp_properties.json reinkopiere.

Dann rufe ich aus dem Projektverzeichnis heraus vscode mit

      vscode .

auf.

Aber, wie gesagt, ich benutze komplett andere Werkzeuge als Du für meine 
Arbeit, die ich mit vscode mache (wie Du schon erkannt hast, CMake als 
Makefilegenerator für ein make, llvm als C-Compiler und ein lldb-Plugin 
fürs Remote-Debuggen).

Wenn Du mit einem Deiner Werkzeuge ein funktionierendes Projekt hast, 
dann erfolgt die Integration in vscode unter anderem durch die Datei

     .vscode/tasks.json

In der steht drin, wie der Compiler aufgerufen wird, in der steht drin, 
wie der Debugger verwendet wird etc.
Die solltest Du Dir also genauer ansehen.

Und wenn im Verzeichnis .vscode noch irgendwas anderes liegt, solltest 
Du auch da mal hineinsehen, das ist potentiell interessant.


Viel Erfolg!

[Monk (roehrmond)]

Markus W. schrieb:
> Diese Einstellung habe ich in der Window-Manager Config vorgenommen.
> Offensichtlich verwendet VSCode diesen Wert nicht.

Probiere mal die Zoom Funktion
https://code.visualstudio.com/docs/editor/accessibility

Bei mir macht ctrl + nicht nur die Schrift, sondern auch die Symbole 
größer.

[Markus W. (dl8mby)]

Hallo Harald K,
hallo Monk,

danke für den Input zum Projek-Anlegen @Harald,
und danke für den Hinweis zum Zoom-Faktor @Monk,
hat geklappt und die Symbole werden ebenfalls größer.

War jetzt kurz weg und nun kann ich wieder rumspielen.

Euch einen schönen Samstag Abend.

LG
Markus

[Harald K. (kirnbichler)]

Markus W. schrieb:
> und danke für den Hinweis zum Zoom-Faktor @Monk,
> hat geklappt und die Symbole werden ebenfalls größer.

Diese Einstellung müsstest Du übrigens in settings.json finden - 
entweder in der projektspezifischen, oder in der, die irgendwo in Deinem 
~ liegt.

[Andreas M. (amesser)]

Ich verwende schon lange VSCode und habe damit keine Probleme unter 
Linux. Auch die Darstellung auf meinem 4k Monitor passt. Hast Du schon 
mal die DPI vom XServer geprüft? ( xdpyinfo in einem terminal eingeben) 
Die Automatische Erkennung hat bei mir selten richtig funktioniert.

Ein Kritikpunkt an VSCode bei mir war, dass das .DEB Paket eine der 
ausführbaren Dateien als setuid installiert hat. Das geht meiner Meinung 
nach gar nicht, wer weis was da alles unter der Haube passiert. 
Glücklicherweise kann man unter Debian dem dpgk per Config sagen, diese 
Rechte automatisiert wieder zu entziehen.

Bei VSCode sollte man auch immer die Cacheverzeichnisse im Blick 
behalten, die C Extension legt Standardmäßig je Projekt bis zu 5GB 
Intellisense Cache an.

[Monk (roehrmond)]

Andreas M. schrieb:
> Ein Kritikpunkt an VSCode bei mir war, dass das .DEB Paket eine der
> ausführbaren Dateien als setuid installiert hat. Das geht meiner Meinung
> nach gar nicht, wer weis was da alles unter der Haube passiert.
> Glücklicherweise kann man unter Debian dem dpgk per Config sagen, diese
> Rechte automatisiert wieder zu entziehen.

Ich halte Microsoft allerdings schon für vetrauenswürdig. Die werden das 
nicht missbrauchen, um dir böses anzutun.

[Andreas M. (amesser)]

Monk schrieb:
> Ich halte Microsoft allerdings schon für vetrauenswürdig. Die werden das
> nicht missbrauchen, um dir böses anzutun.

Wie du meinst. Der Punkt ist aber, das du nicht weist was dieses setuid 
Binary wirklich tut. Es könnte z.B. auch während des Update-Prozesses 
Code der Extensions ausführen. Vertrausts auch allen Extensions?

Letzlich ist es so, das ein User-Prozess nicht ohne Grund ein 
User-Prozess bleiben sollte. Als System-Administrator will ich nicht, 
das ein Benutzer mit root Rechten auf dem System rummacht, vor allem 
nicht ohne das ich vorher gefragt wurde und/oder der Benutzer das 
möglicherweise gar nicht weis. Der Benutzer kann ja alle möglichen 
Extensions installieren, daran kann ich Ihn als Admin gar nicht hindern. 
Ich will auch nicht das ein Benutzer des Systems einfach so eine 
Software aktualisieren kann, die dann auch alle anderen betrifft.

[Harald K. (kirnbichler)]

Andreas M. schrieb:
> Der Punkt ist aber, das du nicht weist was dieses setuid
> Binary wirklich tut.

Wie heißt es denn?

[Oliver S. (oliverso)]

Markus W. schrieb:
> Auf der LILYGO Seite wird dafür VSCode von Microsoft empfohlen.

Ein echter Linuxer nimmt vi oder emacs, für alles.

Oliver

[Andreas M. (amesser)]

Harald K. schrieb:
> Andreas M. schrieb:
>> Der Punkt ist aber, das du nicht weist was dieses setuid
>> Binary wirklich tut.
>
> Wie heißt es denn?

Habs gerade nochmal geprüft, ist auch im aktuellen Paket noch so:

$ dpkg-deb -c code_1.93.1-1726079302_amd64.deb  | grep sandbox
-rwsr-xr-x root/root     54248 2024-08-20 03:38 ./usr/share/code/chrome-sandbox

Unter Debian basierten Distributionen kann man mittels folgendem Befehl 
dpkg sagen, die Berechtigungen für diese Datei grundsätzlich zu 
überschreiben:

$ dpkg-statoverride --update --add root root 755 /usr/share/code/chrome-sandbox

[Harald K. (kirnbichler)]

Hmm.
https://github.com/flathub/com.visualstudio.code/issues/223

Unter "Progress for electron sandbox support" in 
https://code.visualstudio.com/updates/v1_59

findet man auch Hinweise.

Warum für sandbox so ein setuid-Zeug nötig ist? Keine Ahnung, dazu 
verstehe ich davon nicht genug.

Sicher dürfte aber sein, daß das tatsächlich absichtlich ist und keine 
irgendwie hintenrum reingedrückte Schadfunktion.

[Εrnst B. (ernst)]

Harald K. schrieb:
> Warum für sandbox so ein setuid-Zeug nötig ist?

War es früher, ist es (mit halbwegs aktuellen Kerneln, so ab 
5.10irgendwas) nicht mehr.

Hintergrund: Die gesamte Oberfläche von VSCode ist HTML+Javascript, und 
wird von einem mit dem Paket gebündelten Chrome-Webbrowser dargestellt.

Chrome möchte seine Render-Prozesse gerne in einer Sandbox ohne 
Dateisystemzugriff laufen lassen, aus Sicherheitsgründen.

Um diese Sandbox zu erstellen, waren früher Root-Rechte nötig, deshalb 
das kleine suid-helper-programm.

Bei aktuellen Kerneln (Wenn mit CONFIG_USER_NS=y erstellt) lässt sich 
die Sandbox ohne Root-Rechte erstellen, und chrome (bzw chromium, bzw 
electron, bzw vscode) machen das auch.

Aber: chrome und vscode sollen auf möglichst vielen verschiedenen und 
auch alten Linux-Distributionen funktionieren, deshalb wird das 
suid-binary mitgeliefert, auch wenn es in 99% der Fälle nicht verwendet 
werden muss...

Schöner wäre natürlich, wenn die post-install-scripte im dpkg das 
suid-bit nur setzen, wenn der laufende Kernel das auch erfordert.

[Harald K. (kirnbichler)]

Εrnst B. schrieb:
> Um diese Sandbox zu erstellen, waren früher Root-Rechte nötig, deshalb
> das kleine suid-helper-programm.

Danke für die Erklärung. Dann sollten damit "amesser"s Bedenken 
ausgeräumt sein.

[Markus W. (dl8mby)]

Ich bedanke mich auch für die rege Diskussion zu VSCode.
Habe jetzt gerade erst wieder durch Zufall reingeschaut und
gesehen, dass noch diverse Postings eingestellt wurden.

Werde erst am WE wieder mit dem VSCode weiter machen können.
Unter der Woche stehen andere Dinge an.

LG
Markus

[Andreas M. (amesser)]

Harald K. schrieb:
> Danke für die Erklärung. Dann sollten damit "amesser"s Bedenken
> ausgeräumt sein.

Nö sind sie nicht. Erstens ist es unnötig, der Kernel unterstützt die 
entsprechenden Features bereits seit 2013, zweitens habe ich inzwischen 
ausreichend Erfahrung mit der "Vertrauenswürdigkeit" von Microsoft und 
drittens müsste der chrome (bzw in diesem Fall chromium) gar nicht im 
"code" Paket enthalten sein, da dieser für so ziemlich jedes Linux über 
die normalen Paketquellen bezogen werden kann.

[Εrnst B. (ernst)]

Andreas M. schrieb:
> müsste der chrome (bzw in diesem Fall chromium) gar nicht im
> "code" Paket enthalten sein

Gibt diverse Optionen, wie du VSCode ohne den mitgelieferten Browser 
installieren kannst, und dann per Webbrowser benutzen kannst.

z.B.
https://coder.com/docs/code-server
https://hub.docker.com/r/linuxserver/code-server
usw.

Ist halt für die meisten User eher unpraktisch so.

[Harald K. (kirnbichler)]

Andreas M. schrieb:
> und
> drittens müsste der chrome (bzw in diesem Fall chromium) gar nicht im
> "code" Paket enthalten sein, da dieser für so ziemlich jedes Linux über
> die normalen Paketquellen bezogen werden kann.

Vscode ist eine "Electron"-Anwendung, da läuft afaik kein normaler 
Webbrowser.

[Εrnst B. (ernst)]

Harald K. schrieb:
> Vscode ist eine "Electron"-Anwendung, da läuft afaik kein normaler
> Webbrowser.

da läuft halt mehr oder weniger ein Chrome/Chromium, dem die URL-Zeile 
wegkonfiguriert wurde, und der ein paar zusätzliche CSPs hat.
Und sein HTML&co direkt über seinen Server-Teil bekommt, um das http 
dazwischen zu sparen.
Aber soviel Unterschied zu einem normalen, "nicht-electron" Webbrowser 
ist da nicht.

Startseite wäre z.B. (Standardinstallation)
/usr/share/code/resources/app/out/vs/code/electron-sandbox/workbench/wor 
kbench.html

[Harald K. (kirnbichler)]

Εrnst B. schrieb:
> Aber soviel Unterschied zu einem normalen, "nicht-electron" Webbrowser
> ist da nicht.

Der ganz entscheidende Unterschied ist, daß das im Electron-Browser 
laufende Javascript Zugriff auf das Dateisystem des Wirts erhält, etwas, 
was im herkömmlichen Browser aus einer Vielzahl von Gründen ganz und gar 
nicht gewünscht wird.