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.
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.
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?)
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).
Generell würde ich immer zuerst die Plugins von Microsoft versuchen, falls es mehrere Alternativen gibt. Weil ich bisher von allen positiv beeindruckt war.
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.
Eine Einstellung würde ich in der Konfigurationsdatei settings.json auf jeden Fall vornehmen:
1
"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:
1
{
2
"configurations":
3
[
4
{
5
"name": "meinkram",
6
"includePath":
7
[
8
"/usr/include",
9
"/usr/lib"
10
],
11
"defines":
12
[
13
"DEBUG",
14
"SONSTWAS"
15
]
16
}
17
],
18
"version": 4
19
}
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.
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.
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.
"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.",
16
"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.",
17
"type":"string"
18
},
19
"compilerPath":{
20
"markdownDescription":"Full path of the compiler being used, e.g. `/usr/bin/gcc`, to enable more accurate IntelliSense.",
21
"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.",
22
"type":"string"
23
},
24
"compilerArgs":{
25
"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>\"`.",
26
"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`.",
27
"type":"array",
28
"items":{
29
"type":"string"
30
}
31
},
32
33
34
...
35
36
"includePath":{
37
"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`.",
38
"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.",
39
"type":"array",
40
"items":{
41
"type":"string"
42
}
43
},
44
...
Dieser Bereich - letzter Block - muss wohl angepasst werden.
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:
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.
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.
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 :-(
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.
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
1
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
1
.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.
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.
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.
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.
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.
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.
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.
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.
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/workbench.html
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.
Noch weiß man nicht, was da genau das Problem ist. Liegt es in der von MS vertriebenen Version, oder liegt es auch in Code-OSS (das ist die Opensource-Variante, die man sich auch selbst aus Quelltext übersetzen kann)?
Oder liegt sie in irgendwas, was den Unterbau bildet (Electron oder weiß der Gott was)?
