Hallo, ich will ein bisschen mit C rumspielen und habe deshalb unter Linux als Editor das Visual Studio Code über das Anwendungszentrum installiert. Das hat auch prima funktioniert, aber nun kann ich kein neues Projekt öffnen. Bei älteren Versionen von VS Code musste man, glaube ich, dafür einfach einen neuen Ordner anlegen und konnte dann die gewünschte Programmiersprache wählen. Diese Option finde ich bei der aktuellen Version leider nicht mehr. Kann hier jemand weiterhelfen? Außerdem benötigt man ja noch einen C-Compiler, um das Geschriebene auszuführen. Kann man einen C-Compiler direkt als Extension in das VS Code einbinden und welcher ist empfehlenswert (gibt es dort GCC)?
Chat GPT schon gefragt? Bei mir hat cGPT ca 3 Seiten rausgespuckt. Habe nur dein Text copy pastet.
Wenn man nur zum "rumspielen" so eine fette IDE will, na gut. Ich persönlich würde ja den GCC Compiler, ggf. make und einen netten Editor nehmen. Wenn ich nur nach "VS Code" google kommen sofort YT videos mit "VS-Code for absolute beginners". Da schon mal reingeschaut?
Udo S. schrieb: > Ich persönlich würde ja den GCC Compiler, ggf. make und einen netten > Editor nehmen. VSCode ist nur ein Editor, sonst nichts. Ob nett, ist Ansichtssache. Und da unter Linux gcc und make dranzudengeln sollte man wohl hinbekommen. Dirk schrieb: > Bei älteren Versionen von VS Code musste man, glaube ich, dafür > einfach einen neuen Ordner anlegen und konnte dann die gewünschte > Programmiersprache wählen. Diese Option finde ich bei der aktuellen > Version leider nicht mehr. Keine Ahnung, ob das mal so war. Leg einen neuen Ordner an, mit einer Datei main.c drin, und öffne den Ordner dann in VSCode. Den Rest macht der dann schon selber. Oliver
:
Bearbeitet durch User
Udo S. schrieb: > Wenn man nur zum "rumspielen" so eine fette IDE will, na gut. Will bei der Gelegenheit auch mal VS Code ein bisschen kennenlernen. Udo S. schrieb: > Wenn ich nur nach "VS Code" google kommen sofort YT videos mit "VS-Code > for absolute beginners". > Da schon mal reingeschaut? Gute Idee! Hatte bisher nur VSC und C zusammen gesucht und nichts gefunden. Manchmal braucht man jemanden, der von außen auf die Sache schaut. Oliver S. schrieb: > Keine Ahnung, ob das mal so war. Leg einen neuen Ordner an, mit einer > Datei main.c drin, und öffne den Ordner dann in VSCode. Den Rest macht > der dann schon selber. Ebenfalls gute Idee! Vielen Dank!!!
Nemopuk schrieb: > Für AVR kann man es so nutzen: > http://stefanfrings.de/avr_ide/index.html#vscode Prima, Danke für den Link!
Sowas würde ich immer per CMake und CMakePresets.json machen, und Ninja Multi-Config als Build-Tool nutzen. Siehe dazu das angehängte Minimal-Demo-Projekt. Erst die nötigen Tools, insbesondere den Compiler, installieren:
1 | sudo apt-get install -y gcc g++ ninja-build cmake |
In VS Code die Extensions für CMake und C/C++ installieren: - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools Dann den Projekt-Ordner in VS Code öffnen. Es sollte dann automatisch nach einem Preset fragen, oder du kannst das Preset im CMake-Menü auswählen, unter "Configure". Unter Linux wähle dort "GCC_x64" aus. Genau so funktioniert es auch unter Windows. Installiere dazu den Microsoft-Compiler von hier (unter dem Punkt "Buildtools für Visual Studio 2026"): https://visualstudio.microsoft.com/de/downloads/#build-tools-for-visual-studio-2026 . Als Configure-Preset in VS-Code dann MSVC_x64 auswählen.
Niklas G. schrieb: > Installiere dazu den Microsoft-Compiler > MSVC_x64 Für welche Mikrocontroller ist der denn geeignet?
:
Bearbeitet durch User
Nemopuk schrieb: > Für welche Mikrocontroller ist der denn geeignet? Wer redet von Mikrocontrollern?
Um (wie der Threadstarter schreibt) unter Linux "ein bisschen mit C rumzuspielen" braucht man keinen Microcontroller. Allerdings muss man da i.d.R. auch keinen C-Compiler installieren, der sollte einfach schon da sein. Als Kommandozeilencompiler, versteht sich. Ist doch ein Linux-System. Auf CMake, Ninja und ähnliches kann man für den Anfang auch verzichten, selbst auf ein Makefile, wenn das Herumspielprogramm nur aus einem Sourcefile besteht. Das Makefile kann man sich selbst schreiben, wenns mehr Sourcefiles werden, damit kommt man auch schon recht weit.
Harald K. schrieb: > Auf CMake, Ninja und ähnliches kann man für den Anfang auch verzichten, > selbst auf ein Makefile, wenn das Herumspielprogramm nur aus einem > Sourcefile besteht. Kann man, macht's aber lästiger. Denn gerade VS Code hat eine enorm praktische CMake-Integration.
Niklas G. schrieb: > Denn gerade VS Code hat eine enorm > praktische CMake-Integration. Mag sein, aber das sind halt noch weitere Dinge, die es zunächst deutlich undurchschaubarer machen. CMake löst Probleme, die man in der Situation des Threadstarters nicht hat.
Harald K. schrieb: > CMake löst Probleme, die man in der Situation des Threadstarters nicht > hat. Kann man in VS Code überhaupt auf Knopfdruck ein Projekt ohne CMake kompilieren?
Oliver S. schrieb: > Mit einem makefile ganz bestimmt. > Oliver Dann kann man aber auch gleich eine CMakeLists.txt schreiben, die ist nämlich deutlich weniger kryptisch als ein Makefile und ganz zufällig auch automatisch portabel zu grundverschiedenen Compilern wie MSVC...
:
Bearbeitet durch User
Und ums noch abzurunden: zum „nur etwas rumspielen“ ohne Ambitionen, sich in die bekanntermaßen kryptischen Geheimnisse von make oder cmake einzuarbeiten, würde ich mir eine vollwertige IDE installieren, die das alles automatisch im Hintergrund abwickelt. Eclipse, QtCreator, Codeblocks, … C-Projekt anlegen, im automatisch angelegten main.c lostippen, build drücken, fertig. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > würde ich mir eine vollwertige IDE installieren, die das alles > automatisch im Hintergrund abwickelt. Eclipse, QtCreator, Codeblocks, Die haben aber auch alle so ihre Tücken. Der Vorteil von VS Code ist dass es sehr aktiv entwickelt wird. Es generiert zwar die Build-Dateien nicht automatisch, aber die kann man ja einfach aus meinem Demo-Projekt übernehmen, der Rest geht automatisch...
Oliver S. schrieb: > Und ums noch abzurunden: zum „nur etwas rumspielen“ ohne Ambitionen Dafür würde ich mir unter Linux einfach ein kleines Bash Script schreiben. Und auch keine IDE verwenden. Ist doch völlig egal wenn da 1-10 Sourcen immer wieder alle übersetzt werden. Nur falls der Rechner mind. 15 Jahre alt ist, dann merkt man das.
Etwas "rumspielen" kann man auch gut im Browser. Gibt einige GCC Compiler online. Dann braucht man garnichts installieren oder von make wissen. Beispiel: https://www.onlinegdb.com/online_c_compiler
:
Bearbeitet durch User
Niklas G. schrieb: > Kann man in VS Code überhaupt auf Knopfdruck ein Projekt ohne CMake > kompilieren? Natürlich. Du musst das, was passieren soll, als "task" in der Datei .vscode/tasks.json definieren. Da kannst Du auch von Hand den Compiler aufrufen (für 1-Source-Projekte), oder make, oder ein Batchfile/shellscript, oder was auch immer sonst Dir gefällt. Vscode ist da extrem flexibel.
Harald K. schrieb: > Natürlich. Du musst das, was passieren soll, als "task" in der Datei > .vscode/tasks.json definieren. Das ist nicht "auf Knopfdruck"... Und wenn man schon eine tasks.json anlegt kann man auch stattdessen eine CMakeLists.txt anlegen. 900ss schrieb: > Er möchte aber nur etwas mit C rumspielen. Aber in VS Code. Was auch sinnvoll ist, denn da geht es recht komfortabel.
Niklas G. schrieb: > Das ist nicht "auf Knopfdruck" Natürlich. Du kannst eine der Tasks mit einer Tastenkombination ausführen, es ist nicht nötig, sich da durch das Menü zu hangeln.
Harald K. schrieb: > Du kannst eine der Tasks mit einer Tastenkombination > ausführen, es ist nicht nötig, sich da durch das Menü zu hangeln. Kompilation per CMake ist sowieso per Default auf F7. Simpler geht's also nicht.
Niklas G. schrieb: > Kompilation per CMake Kommst Du in den CMake-Himmel, wenn Du genug missioniert hast? ;-)
Niklas G. schrieb: > Die haben aber auch alle so ihre Tücken. Der Vorteil von VS Code ist > dass es sehr aktiv entwickelt wird. Das ist ganz sicher kein Vorteil. Das merkt man, wenn man nach z.B. einem halben Jahr mal ein älteres Projekt erneut bauen will und erst mal nix funktioniert, weil zwischenzeitlich irgendwelche eigentlich völlig unwichtigen Kleinigkeiten geändert wurden, diese Änderungen aber ein erfolgreiches Build verhindern. Solche Bananen-Software nervt einfach mal nur unendlich. Entwicklungswerkzeuge müssen einfach langfristig stabil funktionieren, sonst ist es kein Werkzeug, sondern Spielzeug.
Ob S. schrieb: > Das merkt man, wenn man nach z.B. > einem halben Jahr mal ein älteres Projekt erneut bauen will und erst mal > nix funktioniert, VS Code ruft zum Bauen nur CMake auf, wenn das plötzlich nicht mehr gehen sollte kann man immer noch einfach CMake direkt aufrufen. Ob S. schrieb: > Entwicklungswerkzeuge müssen einfach langfristig stabil funktionieren Im Gegenteil müssen Entwicklungswerkzeuge regelmäßig aktualisiert werden, damit man damit auch neuere Technologien anwenden kann. Wie sollen sich sonst neue Technologien etablieren wenn die Entwicklungswerkzeuge die nicht einbinden können?
:
Bearbeitet durch User
Niklas G. schrieb: > Kompilation per CMake ist sowieso per Default auf F7. Nö, ist es nicht. Ist es nur, wenn man die CMake-Extension installiert hat.
Dirk schrieb: > (gibt es dort GCC)? Dort gibt es sogar GDB. Du könntest aber auch sowas hier nutzen: https://docs.redhat.com/de/documentation/red_hat_developer_tools/1/html-single/using_llvm_13.0.1_toolset/index Was hast du für ein Linux, denn die Entwicklungspakete sind nicht überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit an Board. P.S.: Als Editor könnte man auch noch CudaText ausprobieren, wenn man mit den Editoren in der Konsole nicht klarkommt.
:
Bearbeitet durch User
Danke noch für die vielen Antworten. Ich will es jetzt erst mal weiter mit JS-C versuchen. Niklas G. schrieb: > Erst die nötigen Tools, insbesondere den Compiler, installieren:sudo > apt-get install -y gcc g++ ninja-build cmake Hallo Niklas, ich gehe mal Schritt für Schritt vor, ninja-build cmake habe ich installiert. Dann wie hier angegeben https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools habe ich auch cMake installiert mit "ext install ms-vscode.cmake-tools". Aber jetzt soll noch das hier gemacht werden: Ensure that either you've added your CMake executable to your PATH, or you've adjusted the cmake.cmakePath setting to point to your CMake executable. Ich verstehe leider nicht, wo man das eintragen soll. Kannst du mir da weiterhelfen?
Dirk schrieb: > Ich verstehe leider nicht, wo man das eintragen soll. Unter Linux muss du da normalerweise nichts machen. Gib auf einem Terminal den "cmake" und den "ninja" Befehl ein; wenn beide gefunden werden, sollte es auch in VS Code funktionieren. Unter Windows mit den Visual Studio Build Tools muss es eigentlich auch sofort funktionieren, denn da ist ein CMake und ein Ninja mitgeliefert und VS Code bindet die automatisch ein.
:
Bearbeitet durch User
Ob S. schrieb: > Niklas G. schrieb: > >> Die haben aber auch alle so ihre Tücken. Der Vorteil von VS Code ist >> dass es sehr aktiv entwickelt wird. > > Das ist ganz sicher kein Vorteil. Das merkt man, wenn man nach z.B. > einem halben Jahr mal ein älteres Projekt erneut bauen will und erst mal > nix funktioniert, weil zwischenzeitlich irgendwelche eigentlich völlig > unwichtigen Kleinigkeiten geändert wurden, diese Änderungen aber ein > erfolgreiches Build verhindern. Aber ja doch, das ist unbedingt ein Vorteil. Ein aktives Projekt -- womöglich mit einer nicht minder aktiven Community -- hat eindeutige Vorzüge. Sonst ist es nämlich am Ende nur noch möglich, olles Gerümpel zu bauen, während moderne Technologien irgendwann nicht mehr genutzt werden können -- und auch für alte Sachen weder Bugfixes noch Optimierungen ankommen. > Solche Bananen-Software nervt einfach mal nur unendlich. > Entwicklungswerkzeuge müssen einfach langfristig stabil funktionieren, > sonst ist es kein Werkzeug, sondern Spielzeug. Was Du in Deiner grandiosen "Kompetenz" nicht verstehst, ist, daß es dabei nicht um Weiterentwicklung, sondern um Abwärtskompatibilität geht.
Rbx schrieb: > Was hast du für ein Linux, denn die Entwicklungspakete sind nicht > überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit > an Board. In modernen Linux-Distributionen wird das häufig nicht installiert. > P.S.: Als Editor könnte man auch noch CudaText ausprobieren, wenn man > mit den Editoren in der Konsole nicht klarkommt. Ja, oder UltraEdit, Programmer's Notepad, Kate, gedit, Emacs, vi(m), Atom... wobei Emacs und vi(m) wahlweise mit und ohne GUI benutzt werden können, aber gerade diese beiden sind vermutlich eher etwas für Enthusiasten. ;-)
Sheeva P. schrieb: > aber gerade diese beiden sind vermutlich eher etwas für > Enthusiasten. ;-) Zur Not ginge ja auch noch Nano. Finde ich witzig, dass du auch gedit aufführst. So gesehen könnte man auch Wine + Notepad++ anwerfen. Der Vorteil mit den Terminal-Editoren ist einfach, mehrere Terminals aufmachen, in dem einen editieren, in dem anderen übersetzen und linken. Ich hatte, als noch das XPS lief, Code::Blocks mit mingw auf Windows Vista installiert, aber die IDE wollte trotz eingetragener Pfade den mingw nicht finden oder nutzen. Da hatte ich dann lieber mit Eclipse geliebäugelt, Eclipse ist zwar etwas eigen, aber funktioniert wenigstes, wie man das erwartet, selbst wenn es unübersichtlich wird.. Aktuell mag das vielleicht ein wenig anders sein, aber ich bin tatsächlich in dem meisten Fällen auch mit gedit zufrieden. Meine ganzen Rust-Experimente schreibe ich bisher all da rein. Zumindest im Moment. Dieses ganze Absichern bei Rust und dann hinterher oder zwischendurch doch wieder untergraben (z.B. mit Address-Referenzen) usw. kann schon ganz schön anstrengend sein, da stören ablenkende IDEs oder ähnliches nur unnötig.
Niklas G. schrieb: > Dirk schrieb: >> Ich verstehe leider nicht, wo man das eintragen soll. > > Unter Linux muss du da normalerweise nichts machen. Gib auf einem > Terminal den "cmake" und den "ninja" Befehl ein; wenn beide gefunden > werden, sollte es auch in VS Code funktionieren. Unter Windows mit den > Visual Studio Build Tools muss es eigentlich auch sofort funktionieren, > denn da ist ein CMake und ein Ninja mitgeliefert und VS Code bindet die > automatisch ein. Vielen Dank für die schnelle Antwort und gute Idee mit dem Terminal! Wenn ich dort "cmake" eingebe, erscheint folgendes:
1 | Usage |
2 | |
3 | cmake [options] <path-to-source> |
4 | cmake [options] <path-to-existing-build> |
5 | cmake [options] -S <path-to-source> -B <path-to-build> |
6 | |
7 | Specify a source directory to (re-)generate a build system for it in the |
8 | current working directory. Specify an existing build directory to |
9 | re-generate its build system. |
10 | |
11 | Run 'cmake --help' for more information. |
Gebe ich "ninja" ein, erscheint:
1 | ninja: error: loading 'build.ninja': No such file or directory |
Irgendwas scheint mit der source directory noch nicht zu stimmen?!
Dirk schrieb: > Irgendwas scheint mit der source directory noch nicht zu stimmen?! Ne es ist alles richtig. Jetzt weißt du dass beide Programme korrekt installiert sind. Damit die beiden Tools etwas sinnvolles tun, muss man sie mit den entsprechend richtigen Parametern aufrufen. Das macht VS Code automatisch. Öffne mein Demo-Projekt in VS Code und du solltest es kompilieren können.
Sheeva P. schrieb: > Rbx schrieb: >> Was hast du für ein Linux, denn die Entwicklungspakete sind nicht >> überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit >> an Board. > > In modernen Linux-Distributionen wird das häufig nicht installiert. Ich nutze folgende Linux-Version: Ubuntu 25.10 Kernel: Linux 6.17.0-14-generic Architecture: x86-64
Dirk schrieb: > Sheeva P. schrieb: >> Rbx schrieb: >>> Was hast du für ein Linux, denn die Entwicklungspakete sind nicht >>> überall dabei? Ich habe Fedora Workstation, da ist das meiste schon mit >>> an Board. >> >> In modernen Linux-Distributionen wird das häufig nicht installiert. > > Ich nutze folgende Linux-Version: > > Ubuntu 25.10 > Kernel: Linux 6.17.0-14-generic > Architecture: x86-64 Dann Folgendes im Terminal ausführen:
1 | sudo apt-get update |
2 | sudo apt-get install build-essential |
Harry L. schrieb: > Dann Folgendes im Terminal ausführen: Unnötig. Wir haben bereits alles nötige installiert: Niklas G. schrieb: > sudo apt-get install -y gcc g++ ninja-build cmake Dirk muss einfach nur noch das Projekt öffnen.
Niklas G. schrieb: > Ne es ist alles richtig. Jetzt weißt du dass beide Programme korrekt > installiert sind. Vielen Dank, dann habe ich das falsch interpretiert, sorry. Also, habe deinen Ordner geöffnet, "GCC_x64" ausgewählt und das hat schon mal geklappt. Wenn ich dann auf main.c gehe (also dein "Hello, World"-Programm) und unter "Run" auf "Run without debuggin" klicke, kommt eine Fehlermeldung in einem weißen Fenster:
1 | (X) |
2 | Configured Debug Type 'cppvsdbg' is installed but not supported in this invironment. |
3 | <Abbrechen> <Open launch.json> |
Muss man das Programm anders compilieren/starten oder liegt der Fehler woanders?
Harald K. schrieb: > Allerdings muss man da i.d.R. auch keinen C-Compiler installieren, der > sollte einfach schon da sein. Als Kommandozeilencompiler, versteht sich. > Ist doch ein Linux-System. Das ist afair schon lange nicht mehr Standardmäßig mit dabei. Selbst wenn man nen Kernel selber bauen will, muss man alles nachinstallieren. GNU/Linux wird immer frickeliger.
Dirk schrieb: > Muss man das Programm anders compilieren/starten oder liegt der Fehler > woanders? Vielleicht ist manuelles compilieren für den Anfang doch besser. So musst Du noch die IDE mitlernen. "gcc main.c" ist da einfacher :P
Beitrag #8018555 wurde vom Autor gelöscht.
Dirk schrieb: > Configured Debug Type 'cppvsdbg' is installed but not supported in this > invironment. Ah, das geht so anscheinend nur unter Windows. Ersetze mal die .vscode/launch.json durch die hier angehängte. Kann es gerade nicht selbst unter Linux testen. Zuvor installiere noch den GDB: sudo apt-get install -y gdb Jens B. schrieb: > "gcc main.c" ist da einfacher :P Bringt hier nichts, da das Programm anscheinend bereits kompiliert wurde, nur die Launch Configuration in VS Code ist falsch.
Vielen Dank! Niklas G. schrieb: > Zuvor installiere noch den GDB:
1 | sudo apt-get install -y gdb |
Das gibt folgendes aus:
1 | Paketlisten werden gelesen… Fertig |
2 | Abhängigkeitsbaum wird aufgebaut… Fertig |
3 | Statusinformationen werden eingelesen… Fertig |
4 | gdb ist schon die neueste Version (16.3-1ubuntu2). |
5 | gdb wurde als manuell installiert festgelegt. |
6 | Auflösen von Abhängigkeiten… Fertig |
7 | 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert. |
> Ah, das geht so anscheinend nur unter Windows. Ersetze mal die > .vscode/launch.json durch die hier angehängte. Kann es gerade nicht > selbst unter Linux testen. Habe dann launch.json wie empfohlen ausgetauscht. Nun kommt folgende Fehlermeldung, wenn man auf "Run without debuggin" klickt:
1 | (X) |
2 | |
3 | launch: program 'null' does not exist |
4 | |
5 | <Abbrechen> <Open launch.json> |
Dirk schrieb: > Nun kommt folgende Fehlermeldung, wenn man auf "Run without debuggin" > klickt: Drück mal F7 zum Kompilieren und zeig die Ausgabe aus dem "Output" Fenster.
Niklas G. schrieb: > Drück mal F7 zum Kompilieren und zeig die Ausgabe aus dem "Output" > Fenster.
1 | [main] Building folder: /home/adxcf/C Programme meine/DemoProj1/build |
2 | [main] Configuring project: DemoProj1 |
3 | [proc] Executing command: /usr/bin/cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -S "/home/adxcf/C Programme meine/DemoProj1" -B "/home/adxcf/C Programme meine/DemoProj1/build" -G "Ninja Multi-Config" |
4 | [cmake] CMake Error: The current CMakeCache.txt directory /home/adxcf/C Programme meine/DemoProj1/build/CMakeCache.txt is different than the directory /home/adxcf/C Programme meine/DemoProj/build where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt |
5 | [cmake] CMake Error: The source "/home/adxcf/C Programme meine/DemoProj1/CMakeLists.txt" does not match the source "/home/adxcf/C Programme meine/DemoProj/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory. |
6 | [proc] The command: /usr/bin/cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -S "/home/adxcf/C Programme meine/DemoProj1" -B "/home/adxcf/C Programme meine/DemoProj1/build" -G "Ninja Multi-Config" exited with code: 1 |
Könnte es eventuell damit zu tun haben, dass ich einen identischen Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst wie "DemoProj")
Dirk schrieb: > Könnte es eventuell damit zu tun haben, dass ich einen identischen > Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst > wie "DemoProj") Das kannst ja leicht durch Umbennen testen. Vermutlich lautet die Antwort dann "nein".
Dirk schrieb: > Könnte es eventuell damit zu tun haben, dass ich einen identischen > Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst > wie "DemoProj") Äh, offenbar versucht es den Ordner "DemoProj1" zu kompilieren aber ist verwirrt weil das Projekt mal im Pfad "DemoProj" konfiguriert wurde. Vermutlich hast du den Ordner mal umbenannt?! Beende VS Code, lösche den "build" Ordner im Projekt, und öffne es neu in VS Code. PS: Hier nicht die Ursache, aber du solltest unbedingt Leerzeichen im Projektpfad vermeiden, also "C Programme meine" ist nicht gut.
Niklas G. schrieb: > Dirk schrieb: >> Könnte es eventuell damit zu tun haben, dass ich einen identischen >> Ordner benutze, der "DemoProj1" heißt? (also eine 1 angehangen, sonst >> wie "DemoProj") > > Äh, offenbar versucht es den Ordner "DemoProj1" zu kompilieren aber ist > verwirrt weil das Projekt mal im Pfad "DemoProj" konfiguriert wurde. > Vermutlich hast du den Ordner mal umbenannt?! > > Beende VS Code, lösche den "build" Ordner im Projekt, und öffne es neu > in VS Code. > > PS: Hier nicht die Ursache, aber du solltest unbedingt Leerzeichen im > Projektpfad vermeiden, also "C Programme meine" ist nicht gut. Ah, ok, sowas hatte ich fast schon gedacht. Habe jetzt den Überordner noch mal neu aufgesetzt, diesmal direkt ohne Leerzeichen und deinen Ordner neu reingepackt und das json-File darin ausgetauscht wie oben beschrieben. Und jetzt geht es :))) Super, vielen herzlichen Dank für Deine Mühe und Geduld!!!!!!!!!!!!!!!!!! Ich bin so froh, dass es jetzt geht.
Dirk schrieb: > Und jetzt geht es :))) Tada 😁 Dirk schrieb: > Super, vielen herzlichen Dank Gern, viel Spaß 😉
Rbx schrieb: > Zur Not ginge ja auch noch Nano. Oder einer der tausend anderen Editoren, die es für Linux gibt. Nur... > Finde ich witzig, dass du auch gedit > aufführst. So gesehen könnte man auch Wine + Notepad++ anwerfen. ... warum man ausgerechnet eine Windows-Software in einem Nicht-Emulator benutzen wollen würde, erschließt sich mir nicht. > Der Vorteil mit den Terminal-Editoren ist einfach, mehrere Terminals > aufmachen, in dem einen editieren, in dem anderen übersetzen und linken. Äh, nein.
Fedora hat wohl kein Notepadqq als Package im Repo, nur eine veraltete Snap Version.
Niklas G. schrieb: > Harald K. schrieb: >> CMake löst Probleme, die man in der Situation des Threadstarters nicht >> hat. > > Kann man in VS Code überhaupt auf Knopfdruck ein Projekt ohne CMake > kompilieren? Gerade spaßeshalber probiert (weil ich, als eingefleischter Emacs-Fan :-), VScode dienstlich eh gerade offen hatte): * new window * open folder -> einen neuen angelegt * new text file * ein "hello world" hineingetippt * save as main.c * go -> debug Hat mich nach dem zu verwendenden Compiler gefragt, mir das Teil compiliert (irgendwie :), den GDB angeworfen, und alles laufen lassen. Da ich keinen breakpoint hatte, natürlich einfach einmal komplett durch. Also ja, geht, ohne Makefile, ohne CMake, ohne sonstwas. Die C/C++ extension muss man natürlich sinnvollerweise haben dafür.
:
Bearbeitet durch Moderator
ps: Es wirft dafür ein .vscode/tasks.json ab, in dem die relevanten Schritte beschrieben sind.
Niklas G. schrieb: > PS: Hier nicht die Ursache, aber du solltest unbedingt Leerzeichen im > Projektpfad vermeiden, also "C Programme meine" ist nicht gut. Nachdem das inzwischen selbst Windows problemlos hinkriegt, sollte das unter Linux doch nun wirklich kein Thema mehr sein. Oliver
Linux ist nicht das Problem. Nur der unbedarfte Nutzer. Jeder der Skripte schreibt hat das gelesen: Filenames and Pathnames in Shell: 2. How to do it wrongly (David A. Wheeler) https://dwheeler.com/essays/filenames-in-shell.html#wrong
:
Bearbeitet durch User
Oliver S. schrieb: > Nachdem das inzwischen selbst Windows problemlos hinkriegt, sollte das > unter Linux doch nun wirklich kein Thema mehr sein. Linux an sich verkraftet sogar noch viel schlimmere Pfadnamen als Windows. Nur viele Skripte und auch Anwendungen eben nicht. Prinzipiell ist das lösbar, aber wer macht sich die Arbeit...
Niklas G. schrieb: > Oliver S. schrieb: >> Nachdem das inzwischen selbst Windows problemlos hinkriegt, sollte das >> unter Linux doch nun wirklich kein Thema mehr sein. > > Linux an sich verkraftet sogar noch viel schlimmere Pfadnamen als > Windows. Nur viele Skripte und auch Anwendungen eben nicht. Prinzipiell > ist das lösbar, aber wer macht sich die Arbeit... Dann schreib ich’s mal etwas deutlicher: wenn in dem Kontext Linux/C/cmake/make/VSCode bei einem einfachen Hello world irgend etwas im Jahre 2026 nicht mit Leerzeichen im Pfad klarkommt, gehört das ab in die Tonne. Da gibts nix schönzureden, das muß funktionieren. Oliver
Oliver S. schrieb: > gehört das ab in die Tonne. Da gibts nix schönzureden, das muß > funktionieren. Dem geschenkten Gaul schaut man nicht ins Maul. Statt "in die Tonne" werden, könntest du dich an der Entwicklung der Korrektur beteiligen. Sozusagen als Dankeschön für das Geschenk.
:
Bearbeitet durch User
Oliver S. schrieb: > wenn in dem Kontext > Linux/C/cmake/make/VSCode bei einem einfachen Hello world irgend etwas > im Jahre 2026 nicht mit Leerzeichen im Pfad klarkommt, Es ist ja damit klar gekommen. CMake funktioniert unter Linux auch etwas besser als Windows. Aber früher oder später stolpert man über ein System das nicht damit klarkommt. Ich meine z.B. irgendwelche STM32 Tools mögen das nicht. Bevor man sich damit rumärgert die Ursache herauszufinden kann man auch direkt einen Projekte-Ordner ohne Leerzeichen anlegen.
Rbx schrieb: > Könntest du das vielleicht mal genauer erklären? Natürlich gerne. Schau, wenn ich ein Terminal-Fenster öffnen kann, dann kann ich Emacs oder vi(m) ebenfalls in der GUI starten. Das ist komfortabler, vor allem für die Augen, schließlich sitzt man beim Entwickeln oder komplizierten Konfigurationen mitunter stundenlang vor dem Ding. Und herumscrollen oder den Cursor schnell versetzen geht mit der Maus natürlich auch schneller. Dennoch hat es einen großen Vorzug, daß Emacs und vi(m) einen Modus haben, in dem sie auf der CLI nutzbar sind -- nämlich immer, wenn ich keine passende GUI habe, also keinen X-Server oder keine ausreichende Netzwerkperformance für X-Forwarding habe. Das wäre mir, wenn ich irgendwo schnell eine kleine Änderung machen möchte, aber auf einem Boot mit schlechtem Netz unterwegs bin, oder im Bett liege und zu faul bin, zu einem Rechner zu laufen, oder wenn ich bei einem Kunden bin, der meinen Geräten zwar keinerlei Zugang zu seinem Netzwerk und zum Internet gewähren mag, mir aber einen Putty, MobaXTerm oder ssh(1) auf einem seiner eigenen Geräte zur Verfügung stellen kann. Und sicher auch noch in anderen Situationen, die ich schon wieder vergessen habe. In all diesen Fällen habe ich auch auf der Kommandozeile den Editor, den ich kenne, mit der Konfiguration, die ich seit Jahrzehnten pflege, inklusive all dem netten Zeug wie Syntax-Highlighting, Autocompletion, und so weiter. Yay! Trotzdem würde ich sowohl Emacs als auch vi(m) nur Enthusiasten empfehlen, die extrem leistungsfähige Allround-Werkzeuge haben wollen, und dazu bereit sind, sich einzuarbeiten. Emacs und vi(m) können tolle Sachen (einige davon habe ich sogar bei sehr leistungsfähigen IDEs wie Eclipse vermißt), aber die Lernkurve ist steil und die Unterschiede zu standardkonformen Programmen sind riesig. Ganz grundsätzlich glaube ich aber dennoch, daß Linux- oder UNIX-Interessierte zumindest die Basics des vi(m) lernen sollten. Der ist einfach immer vorhanden und hie und wieder auch mal der allerletzte Ausweg... :-)
Sheeva P. schrieb: > Der > ist einfach immer vorhanden und hie und wieder auch mal der allerletzte > Ausweg... :-) Na ja, einen Nano findet man eigentlich auch überall, und ctrl-s zum speichern und ctrl-x zum beenden kann man sich so gerade noch merken. Oliver
:
Bearbeitet durch User
Nemopuk schrieb: > Oliver S. schrieb: >> gehört das ab in die Tonne. Da gibts nix schönzureden, das muß >> funktionieren. > > Dem geschenkten Gaul schaut man nicht ins Maul. Ehrlich gesagt halte ich das für keine besonders kluge Argumentation. Auf der einen Seite provoziert sie den fehlerhaften Umkehrschluß, daß OpenSource-SW nicht leistungsfähig genug wäre und die Entwickler sich nicht darum kümmern, weil der Gaul ja geschenkt ist. Das ist natürlich Unsinn, denn wenn man das richtig macht, ist es überhaupt kein Problem. > Statt "in die Tonne" werden, könntest du dich an der Entwicklung der > Korrektur beteiligen. Sozusagen als Dankeschön für das Geschenk. Das wiederum provoziert womöglich den Fehlschluß, daß OpenSource-SW nur etwas für Leute sei, die daran mitwirken können. Das ist andererseits ebenso Unfug, denn viele Anwender von OpenSource-Software haben keine Ahnung, wie das geht, können ihre Aufgaben aber trotzdem mit ihrer Software erfüllen.
Oliver S. schrieb: > Na ja, einen Nano findet man eigentlich auch überall Auf einem Solaris, AIX, HP-UX, {Free,Net,Open,Dragonfly}-BSD?
Sheeva P. schrieb: > Auf einem Solaris, AIX, HP-UX, {Free,Net,Open,Dragonfly}-BSD? FreeBSD: pkg install nano Mache ich immer als ersten Schritt nach dem Installieren des Systems. Die Gehirnwindungsanpassungen, die man benötigt, um so etwas wie "vi" als Editor zu bezeichnen, habe ich nicht. Schon auf meinem ersten Computer vor 40 Jahren hatte ich einen Texteditor, der nicht wie edlin zwischen zwei Betriebsarten umgeschaltet werden musste. Damals, in der vorderen Altsteinzeit, als Tastaturen noch keine Cursortasten hatten, da mag so etwas nötig gewesen sein, aber schon der Apple II hatte Cursortasten. Und ein VT100 sowieso. Ich hab' ein bisschen das Gefühl, daß das ein Pseudo-Elitending ist, man findet sich cool und überlegen, weil man ein maximal unbedienbares Programm "gemeistert" hat. Meine Lebenszeit ist mir für derartiges zu schade. Und wer Wordstar gewohnt ist, kann sich nano auch anpassen; neuere Varianten unterstützen den Kommandozeilenparameter --modernbindings
Druck Dir doch ein cheat sheet aus dann gehörst Du wie ich mit zur Elite.
Alexander schrieb: > Druck Dir doch ein cheat sheet aus dann gehörst Du wie ich mit zur > Elite. Bwahahaha
Harald K. schrieb: > Die Gehirnwindungsanpassungen, die man benötigt, um so etwas wie "vi" > als Editor zu bezeichnen, habe ich nicht. Tja, und mich verwirren diese vorinstallierten und standardmäßig aktivierten Nanos, wenn ich einen vi erwarten würde. ;-) Ich habe den auch nie wirklich gemocht, aber das bissel, was man für grundlegendes Editieren damit braucht, hat man schnell drauf, und das sitzt auch nach vielen Jahren noch griffbereit.
Sheeva P. schrieb: > Nemopuk schrieb: >> Oliver S. schrieb: >>> gehört das ab in die Tonne. Da gibts nix schönzureden, das muß >>> funktionieren. >> >> Dem geschenkten Gaul schaut man nicht ins Maul. > > Ehrlich gesagt halte ich das für keine besonders kluge Argumentation. > Auf der einen Seite provoziert sie den fehlerhaften Umkehrschluß, daß > OpenSource-SW nicht leistungsfähig genug wäre und die Entwickler sich > nicht darum kümmern, weil der Gaul ja geschenkt ist. Das ist natürlich > Unsinn, denn wenn man das richtig macht, ist es überhaupt kein Problem. Eben. Zudem es da nicht um irgend eine BastelWastelBananensoftware geht, sondern um Linux. Das ist zwar Open Source, aber trotzdem eine hochprofesionelle Software, und vermutlich zudem Vorreiter von Leerzeichen in Pfaden und Dateinamen, seit Anbeginn der Zeitrechnung. Und für alles andere, was es darauf um Kompilieren von C-Programmen gibt, gilt das genauso. Oliver
Hallo, Jörg W. schrieb: > aber das bissel, was man für > grundlegendes Editieren damit braucht, hat man schnell drauf, und das > sitzt auch nach vielen Jahren noch griffbereit. Bezieht sich obiges auf nano oder vi? rhf
Sheeva P. schrieb: > Trotzdem würde ich sowohl Emacs als auch vi(m) nur Enthusiasten > empfehlen, die extrem leistungsfähige Allround-Werkzeuge haben wollen, > und dazu bereit sind, sich einzuarbeiten. Willst du damit sagen, dass man sich beispielsweise bei Eclipse oder VS Code oder bei den Unix/Linux Shells nicht einarbeiten muss? Letztlich sind Vim oder Emacs gerade für Poweruser sehr wertvolle Werkzeuge, die muss man jetzt nicht automagisch in die Richtung "Spinner" lokalisieren. (übriges gab es vor einiger Zeit auch einen netten Artikel über den Emacs auf der Fedora-Seite). Ganz abgesehen davon reichen für Dirk schrieb: > ich will ein bisschen mit C rumspielen sogar Notepad oder Notepad++. Letzteres hat auch den Vorteil, viele Tabs aufmachen zu können, und so, wenn man Modul-Programm-Technisch unterwegs ist, eine ganz gute Übersicht haben kann. Notepad++ ist wohl nicht so ganz Wine-freundlich - aber das normale Notepad auf jeden Fall ;) (die Alternative zu Notepad++ wäre auf Linux SciTE - funktioniert zwar etwas anders als Notepad++, ist aber auch nicht schlecht.) Harald K. schrieb: > Die Gehirnwindungsanpassungen, die man benötigt, um so etwas wie "vi" > als Editor zu bezeichnen, habe ich nicht. Der Watcom-VI ist nicht ganz so schlimm. Das Problem bei den alten Editoren ist halt, du brauchst ähnlich viel Übungsaufwand wie beim akustischen Morse-Code lernen, oder beim Gitarre-Spielen Einstieg - und das ist eine Einstiegshürde, die sich vor allem für Poweruser lohnt (weil man ja sonst auch einige der Möglichkeiten gleich wieder vergisst). Letztlich: Vielleicht hilft es auch beim VI, wenn man die ersten gescheiterten Versuche der Bedienung schon hinter sich hat ;)
Roland F. schrieb: > Hallo, > Jörg W. schrieb: >> aber das bissel, was man für >> grundlegendes Editieren damit braucht, hat man schnell drauf, und das >> sitzt auch nach vielen Jahren noch griffbereit. > > Bezieht sich obiges auf nano oder vi? Da ich davor schrieb, dass Nano mich immer wieder verwirrt, sollte die Antwort klar sein. ;-)
Hallo, Jörg W. schrieb: > ...dass Nano mich immer wieder verwirrt... Deshalb hatte ich gefragt, mich verwirrt das dich Nano verwirrt. :-) Nano ist, vorsichtig formuliert, in meinen Augen recht schlicht. Da bleibt für Verwirrung eigentlich wenig Raum. Bei vi dagegen ist es genau umgekehrt, die dahinter stehende Bedienphilosophie ist für mich völlig unzugänglich. rhf P.S. Bei Taschenrechnern benutze ich andererseits ausschließlich UPN als als Eingabemethode und das ist für viele Andere ebenfalls völlig unzugänglich.
Roland F. schrieb: > Nano ist, vorsichtig formuliert, in meinen Augen recht schlicht. Da > bleibt für Verwirrung eigentlich wenig Raum. Verwirrend ist für mich bereits, wenn der Editor aufklappt und gefühlt die halbe Bildschirmfläche mit seinem Online-Manual füllt :-), wobei die Kommandos ja nun abseits jeglicher Standards sind. > Bei Taschenrechnern benutze ich andererseits ausschließlich UPN als als > Eingabemethode und das ist für viele Andere ebenfalls völlig > unzugänglich. Bei mir werkelt auch sowohl auf dem Desktop als auch Handy ein X48. Der richtige HP48 ist mir doch etwas zu klobig heutzutage, um ihn noch groß herumzutragen.
Jörg W. schrieb: > wobei die Kommandos ja nun abseits jeglicher Standards sind. --modernbindings Wer halt abseits der "Ich bediene nur und ausschließlich Unixoide Systeme"-Blase unterwegs ist, der ist schon dem Bedienstandard "Cursortasten bewegen den Cursor, ohne daß man zwischen Betriebsarten umschalten muss" begegnet. Sowas brauchten eigentlich nur Zeilenditoren wie Edlin ... Und daß man an termcap-Files herumschnitzen muss, weil natürlich das verwendete Terminal sich anders verhielt als die, die in der Standardkonfiguration vorhanden waren, das dürfte auch schon ein paar Tage her sein. (Mein erster Computer nutzte eine Art TVI950, das war der Befehlssatz der Grip von Conitec ... In der Firma, in der ich wenig später anfing zu arbeiten, gab es irgendeinen völlig obskuren Hausstandard einer längst vergessenen Firma aus Kanada. Aber einen Editor, der wusste, was Cursortasten sind)
Hallo, Jörg W. schrieb: > wobei die > Kommandos ja nun abseits jeglicher Standards sind. Ja, stimmt. Man kann aber in der Konfigurationsdatei "/etc/nanorc" einige Standardkommandos "freischalten". rhf
Angehängte Dateien:
-
exiting-vim.jpg
170 KB -
nano-1.png
130 KB -
nano-2.png
130 KB
Roland F. schrieb: > Ja, stimmt. Immerhin: Sie werden angezeigt. Man muss also keine man-Page bemühen, sondern für die allerwichtigsten Basics einfach nur hinschauen. Allerdings: Wenn man mit einem alten Röhrenterminal mit 80x25-Auflösung arbeitet, dann nimmt das standardmäßig eingeblendete Menü schon arg viel Platz weg. Das sind immerhin vier Zeilen, eine am oberen Bildschirmrand und drei am unteren. Hier zwei Bilder, wie das bei 80x25 aussieht: nano-1 zeigt die typische Belegung, nano-2 zeigt, was passiert, wenn man --modernbindings verwendet. (Und das ist die nano-Version, die man mit pkg install nano auf einem aktuellen FreeBSD erhält)
:
Bearbeitet durch User
Harald K. schrieb: > Und das ist die nano-Version, die man mit pkg install nano auf einem > aktuellen FreeBSD erhält Habe noch nie Bedarf gehabt, das auf einem FreeBSD zu installieren. :-) Wenn, dann installier ich mir einen Emacs, und wenn nicht, dann tut's der vi … Mit vim bin ich nie warm geworden, wenngleich der für Softwareentwicklung genauso taugen dürfte wie Emacs (und man heutzutage beide üblicherweise im GUI-Modus benutzt). VScode benutze ich vor allem beruflich, weil es meinen Kollegen noch am ehesten vermittelbar ist – und um es vorsichtig zu formulieren: Microsoft hat schon sehr viel schrecklicheres Zeug produziert als VScode. Für mich ist das immer noch das Beste aus dem Hause Microsoft seit dem m80 (Macro-80)¹. :-) ¹ https://en.wikipedia.org/wiki/Microsoft_MACRO-80
Jörg W. schrieb: > Habe noch nie Bedarf gehabt, das auf einem FreeBSD zu installieren. Ich installier mir das immer als erstes, weil "vi" einfach ... Wenn man früh genug die Gehirnwindungen angepasst bekommt, dann kann man sich daran gewöhnen und sich damit wohlfühlen. Das ist wohl wie bei Taschenrechnern, UPN oder nicht UPN. Die einen können Forth und Postscript lesen, die anderen nicht. Oder wie beim Autofahren; ist man früh genug auch mal in Großbritannien mit einem Auto gefahren, fällt einem die Umstellung nicht ansatzweise so schwer, wie wenn man das mit 20+ Jahren Fahrpraxis zum ersten Mal versucht.
Harald K. schrieb: > Wenn man früh genug die Gehirnwindungen angepasst bekommt, dann kann man > sich daran gewöhnen und sich damit wohlfühlen. Von "wohlfühlen" kann bei mir da auch keine Rede sein. In meiner allerersten Firma war ich der, der den vi am meisten gehasst hat, trotzdem kannte ich am Ende mehr Kommandos als meine Kollegen, die ihn damals wirklich für Softwareentwicklung genutzt haben. ;-) > Oder wie beim Autofahren; ist man früh genug auch mal in Großbritannien > mit einem Auto gefahren, fällt einem die Umstellung nicht ansatzweise so > schwer, wie wenn man das mit 20+ Jahren Fahrpraxis zum ersten Mal > versucht. In GB war ich nie, aber in ZA und Namibia. Fand ich im Großen und Ganzen nicht schwierig, man sitzt ja auf der anderen Seite und die anderen fahren auch alle so. :-) Einzig irgendwo in einem Wohngebiet ohne Verkehr beim Linksabbiegen fand ich mich dann mal auf der falschen Straßenseite wieder. Schwieriger fand ich das, als Fußgänger über die Straße zu gehen: links gucken, frei, rechts guck… hui, da huscht einer vor der Nase vorbei. :-/
Jörg W. schrieb: > Fand ich im Großen und > Ganzen nicht schwierig, man sitzt ja auf der anderen Seite und die > anderen fahren auch alle so. Ah ... ich mach' das mit meinem eigenen Auto. Da sitze ich, wo ich sonst auch sitze. (ist verständlicherweise in Südafrika & Co. weniger üblich, die Anfahrt ist doch etwas länger als nur bis Ijmuiden und rauf auf die Fähre nach Newcastle) Das erste Mal hab' ichs mit einem Fahrrad gemacht, ca. 2000 km quer durch England, Wales und Irland. Und: Ich liebe es. Vor allem Kreisverkehre. Oh, und das mit dem Linksabbiegen hatte ich auch mal, allerdings in Deutschland, nach einem längeren Urlaub in England. Ugh. Der Autofahrer, der mir da entgegengekommen ist, war leicht irritiert, aber glücklicherweise war da eine Fußgängerinsel mit abgesenktem Bordstein ... Dürfte knapp filmreif gewesen sein, die Aktion.
Jörg W. schrieb: > wobei die Kommandos ja nun abseits jeglicher Standards sind. Das ist ja Gott so Dank bei bei Emacs nicht der Fall ;) SCNR :)
900ss schrieb: > Das ist ja Gott so Dank bei bei Emacs nicht der Fall ;) Nö, dort ist alles Emacs-Standard. ;-) Im Ernst: Emacs war und ist an vielen Stellen durchaus ein Standard. Da er natürlich lange schon vor dem existierte, was dann spätere GUIs so gemacht haben, sollte es jetzt nicht so verwundern, dass sich diese unterscheiden. Dinge wie ^P und ^N für previous-line und next-line kannst du auch heute noch in jeder Bash so benutzen. Früher konnte man ab Cursor bis zum Ende der Zeile noch mit ^K in der URL-Zeile des Firefox löschen, aber das geht leider schon lange nicht mehr. Eigentlich schade, jetzt muss man das umständlich mit der Maus machen. Nano wiederum macht aber nichts davon, weder Emacs noch aktuelle GUI-Standards (zumindest eben nicht von Haus aus – Optionen wurden oben ja genannt).
Jörg W. schrieb: > Eigentlich schade, jetzt muss man > das umständlich mit der Maus machen. Links ist gar nicht so schlecht. Ist natürlich auch ein Ding, mit dem man sich beschäftigen muss. Kann aber schon Spass machen - je nachdem.
Jörg W. schrieb: > Früher konnte man ab Cursor bis zum Ende > der Zeile noch mit ^K in der URL-Zeile des Firefox löschen, aber das > geht leider schon lange nicht mehr. Eigentlich schade, jetzt muss man > das umständlich mit der Maus machen. Spricht was gegen Shift+End, gefolgt von einem Del, so wie in 99% aller Textfelder? OK, die Shift-Taste mitgezählt hast du 3 Tasten, aber das hättest du mit d$ auch. Eine Maus ist jedenfalls nicht notwendig.
:
Bearbeitet durch User
Le X. schrieb: > Spricht was gegen Shift+End, gefolgt von einem Del, so wie in 99% aller > Textfelder? Ist im Gegensatz zu ^K nicht in meine Finger verdrahtet :-), und hätte ich ohne deinen Hinweis jetzt auch nicht gekannt.
Jörg W. schrieb: > Ist im Gegensatz zu ^K nicht in meine Finger verdrahtet :-), und hätte > ich ohne deinen Hinweis jetzt auch nicht gekannt. Dafür wusste ich nicht dass ^P und ^N im Terminal funktionieren, ich hab dazu tatsächlich Cursortasten benutzt. Wir sind also quitt ;-)
Harald K. schrieb: > Sheeva P. schrieb: >> Auf einem Solaris, AIX, HP-UX, {Free,Net,Open,Dragonfly}-BSD? > > FreeBSD: pkg install nano > > Mache ich immer als ersten Schritt nach dem Installieren des Systems. In Deinem Wunschkonzert, ja, und ich installiere in meinem den Emacs. Aber ich arbeite oft auf Systemen, auf denen mir schlicht die Privilegien fehlen, etwas zu installieren. Jetzt rate mal, was deren große Gemeinsamkeit ist? Richtig: die haben alle einen vi. Alle. Ausnahmslos. Ohne was zu installieren. > Ich hab' ein bisschen das Gefühl, daß das ein Pseudo-Elitending ist, man > findet sich cool und überlegen, weil man ein maximal unbedienbares > Programm "gemeistert" hat. Es gibt gute Gründe, zumindest die Basisoperationen des vi(m) zu beherrschen, einen davon habe ich Dir gerade genannt: nämlich, daß er auf jedem unixoiden System bereits fix und fertig installiert ist. > Meine Lebenszeit ist mir für derartiges zu schade. Anscheinend ist Dir Deine Lebenszeit auch zu schade, einen Thread zu lesen und zu verstehen, bevor Du hinein klugscheißt. Denn wenn Du diesen Thread auch nur ansatzweise gelesen und verstanden hättest, dann wüßtest Du, daß es haargenau exakt präzise um ebendies ging: daß dieser vi(m), ganz unabhängig davon ob Du ihn magst, nun mal der Standard unter unixoiden Systemen ist.
Oliver S. schrieb: > Eben. Zudem es da nicht um irgend eine BastelWastelBananensoftware geht, > sondern um Linux. Das ist zwar Open Source, aber trotzdem eine > hochprofesionelle Software, und vermutlich zudem Vorreiter von > Leerzeichen in Pfaden und Dateinamen, seit Anbeginn der Zeitrechnung. > Und für alles andere, was es darauf um Kompilieren von C-Programmen > gibt, gilt das genauso. Nichtsdestotrotz bleiben Leerzeichen in Pfaden schlechter Stil.
Sheeva P. schrieb: > Denn wenn Du diesen Thread auch nur ansatzweise gelesen und verstanden > hättest, dann wüßtest Du, daß es haargenau exakt präzise um ebendies > ging: daß dieser vi(m), ganz unabhängig davon ob Du ihn magst, nun mal > der Standard unter unixoiden Systemen ist. Dem TE eher nicht: Dirk schrieb: > Kann man einen C-Compiler direkt als Extension in das VS Code einbinden > und welcher ist empfehlenswert (gibt es dort GCC)?
Rbx schrieb: > Sheeva P. schrieb: >> Trotzdem würde ich sowohl Emacs als auch vi(m) nur Enthusiasten >> empfehlen, die extrem leistungsfähige Allround-Werkzeuge haben wollen, >> und dazu bereit sind, sich einzuarbeiten. > > Willst du damit sagen, dass man sich beispielsweise bei Eclipse oder VS > Code oder bei den Unix/Linux Shells nicht einarbeiten muss? Habe ich das denn gesagt? Nein. Bitte betrachte dies als starkes Indiz dafür, daß ich NICHT das sagen wollte, was Du mir unterstellst. > Letztlich sind Vim oder Emacs gerade für Poweruser sehr wertvolle > Werkzeuge, die muss man jetzt nicht automagisch in die Richtung > "Spinner" lokalisieren. Genau darum habe ich nicht "Spinner", sondern "Enthusiasten" geschrieben. Wenn Du meine Ausführungen gelesen und verstanden hättest, dann wüßtest Du, daß ich selbst einer dieser Poweruser mit Emacs und Shell bin. Deswegen weiß ich, daß das eine Einarbeitung erfordert, die über ein bisschen Eclipse und Co. weit hinausgeht. Und selbst danach muß man sich immer wieder umgewöhnen, weil Emacs und vi(m) für nahezu alles ganz andere Shortcuts benutzen als die meisten anderen Programme. Immerhin, viele Shortcuts des Emacs funktionieren auch in der Bash einwandfrei, yay! Ja, der Emacs und der vi(m) sind insofern ein bisschen unbequem. Also stellt sich die verständliche Frage, warum manche Leute sie trotzdem benutzen. Dazu werden die meisten ihrer Nutzer vermutlich leicht unterschiedliche Antworten geben, die aber alle auf denselben Kern hinauslaufen: weil es sich für diese Benutzer trotzdem lohnt, ganz einfach. > Ganz abgesehen davon reichen für > > Dirk schrieb: >> ich will ein bisschen mit C rumspielen > > sogar Notepad oder Notepad++. Letzteres hat auch den Vorteil, viele Tabs > aufmachen zu können, Das können Kate und Geany natürlich auch, und bestimmt noch etliche andere der Editoren, die nativ unter Linux laufen. > Notepad++ ist wohl nicht so ganz Wine-freundlich - aber das normale > Notepad auf jeden Fall ;) Ehrlich gesagt, fehlen mir die Worte, um zu beschreiben, für wie bescheuert ich die ganze Idee halte, ausgerechnet unter Linux ein Notepad unter Wine zu benutzen. Oder eine andere Software, für die es ein ähnlich leistungsfähiges oder gar viel mächtigere Äquivalente unter Linux gibt. Wine ist ein Notbehelf, mit dem man die (relativ wenigen) Lücken stopfen kann, wenn es keine Linux-Software für eine bestimmte Aufgabe gibt. Aber es ist und bleibt nur eine Notlösung, nicht mehr. Bei einem sehr komplexen Programm, das hohe Einarbeitungsaufwände erfordert, könnte ich einen Ansatz mit Wine auch noch verstehen. Womöglich erleichtert das den Umstieg oder einen häufigen Wechsel zwischen den Systemen. Aber bei einem so simplen Programm wie einem Texteditor? Ernsthaft?
Harald K. schrieb: > Allerdings: Wenn man mit einem alten Röhrenterminal mit 80x25-Auflösung > arbeitet, dann nimmt das standardmäßig eingeblendete Menü schon arg viel > Platz weg. Und mit Termux auf dem Smartphone erstmal...
Le X. schrieb: > Dafür wusste ich nicht dass ^P und ^N im Terminal funktionieren, ich hab > dazu tatsächlich Cursortasten benutzt. Da geht noch viel mehr, siehe [1]. Dort nicht beschriftet, hier aber sehr oft benutzt: "Esc + .", das übernimmt das letzte Argument des vorigen Kommandos in die aktuelle Position, bei Wiederholung das vorletzte, das vorvorletzte... you get the idea. HF! :-) [1] https://gist.github.com/tuxfight3r/60051ac67c5f0445efee
Le X. schrieb: > Sheeva P. schrieb: >> Denn wenn Du diesen Thread auch nur ansatzweise gelesen und verstanden >> hättest, dann wüßtest Du, daß es haargenau exakt präzise um ebendies >> ging: daß dieser vi(m), ganz unabhängig davon ob Du ihn magst, nun mal >> der Standard unter unixoiden Systemen ist. > > Dem TE eher nicht: > > Dirk schrieb: >> Kann man einen C-Compiler direkt als Extension in das VS Code einbinden >> und welcher ist empfehlenswert (gibt es dort GCC)? Okay, stimmt, aber AFAIK ist diese Frage bereits positiv beantwortet worden. Allerdings hätte ich, da hast Du Recht, präzisieren sollen: nicht in diesem Thread, sondern in dem Subthread, in den mein Vorredner eingeworfen hatte. Lieben Dank für die Klarstellung! :-)
Harald K. schrieb: > Allerdings: Wenn man mit einem alten Röhrenterminal mit 80x25-Auflösung > arbeitet, dann nimmt das standardmäßig eingeblendete Menü schon arg viel > Platz weg. Da nano nie wirklich zum produktiven Arbeiten konzipiert war, sondern damit jeder mal eben schnell eine /etc/fstab flicken kann o.ä., ist das schon total in Ordnung. Die eingeblendeten Shortcuts sind da enorm hilfreich. Wer wirklich effizient Text auf dem Terminal bearbeiten will hat genug Alternativen. Sheeva P. schrieb: > Dennoch hat es einen großen Vorzug, daß Emacs und vi(m) einen Modus > haben, in dem sie auf der CLI nutzbar sind -- nämlich immer, wenn ich > keine passende GUI habe, also keinen X-Server oder keine ausreichende > Netzwerkperformance für X-Forwarding habe. VS Code kann auch remote arbeiten, indem die GUI lokal auf dem PC läuft und per SSH eine Verbindung zum Target aufbaut. Dort muss die Server-Komponente von VS Code laufen, die aber keine GUI braucht. Serverseitig sind diverse OSe und Architekturen unterstützt, aber natürlich nicht jedes erdenkliche exotische System: https://code.visualstudio.com/docs/remote/ssh#_system-requirements Die lokale GUI läuft dann schön flüssig mit allgen gewohnten Einstellungen, Erweiterungen etc., während der Code, Compiler und Kompilate nur remote auf dem Target liegen.
Niklas G. schrieb: > VS Code kann auch remote arbeiten, indem die GUI lokal auf dem PC läuft > und per SSH eine Verbindung zum Target aufbaut. Alternativ kann man vscode auch zu "crossentwicklung" verwenden, dazu muss auf dem Target nur ein lldbserver laufen. Compiler etc. laufen lokal. Hat den Vorzug, daß man auf dem (eher leistungsfähigeren) Arbeitsplatzrechner arbeiten kann, und auf dem (im Embedded-Bereich eher schwachbrüstigen Target) Debuggen kann. Für die lldb-Integration gibts eine Extension. Ich nutze sowas, um vscode unter Windows laufen zu lassen, das Target ist ein Raspberry Pi mit FreeBSD.
Niklas G. schrieb: > Sheeva P. schrieb: >> Dennoch hat es einen großen Vorzug, daß Emacs und vi(m) einen Modus >> haben, in dem sie auf der CLI nutzbar sind -- nämlich immer, wenn ich >> keine passende GUI habe, also keinen X-Server oder keine ausreichende >> Netzwerkperformance für X-Forwarding habe. > > VS Code kann auch remote arbeiten, indem die GUI lokal auf dem PC läuft > und per SSH eine Verbindung zum Target aufbaut. Dort muss die > Server-Komponente von VS Code laufen, die aber keine GUI braucht. Ich fürchte, Du hast den Anwendungsfall "keinen X-Server" verfehlt. Zudem würde ich niemals in meinem Leben auf die Idee kommen, meine Server mit der Software eines der übelsten Datenkraken der Welt zu infizieren. Schon gar nicht, wenn er den Gesetzen des orangenen Haßpredigers unterliegt. Schon gar nicht, um damit so simple Aufgaben wie das Editieren von Textdateien zu ermöglichen. Mein Emacs hat für so etwas übrigens TRAMP [1] bereits fertig integriert, das läuft über SSH und funktioniert auch prima mit verschiedenen Möglichkeiten zur Privilegienerweiterung wie su(1), sudo(1) und weiteren. [1] https://www.gnu.org/software/tramp/ > Die lokale GUI läuft dann schön flüssig mit allgen gewohnten > Einstellungen, Erweiterungen etc., während der Code, Compiler und > Kompilate nur remote auf dem Target liegen. Code und Compiler auf einem Server... o tempora, o mores.
Sheeva P. schrieb: > Zudem würde ich niemals in meinem Leben auf die Idee kommen, meine > Server mit der Software eines der übelsten Datenkraken der Welt zu > infizieren. Man kann Paranoia auch über das Krankhafte hinweg bis ins final Pathologische steigern. vscode ist ein Open-Source-Projekt.
Sheeva P. schrieb: > Genau darum habe ich nicht "Spinner", sondern "Enthusiasten" > geschrieben. Nun ja, Verallgemeinerung bleibt Verallgemeinerung. Man könnte noch deutlich schlimmeres Andichten - schreibe ich hier aber lieber nicht. So also finde dich damit ab und schau lieber mal die Herkunft von Enthusiasmus und die die Etymologie des Begriffes nach. Sheeva P. schrieb: > weil es sich für diese Benutzer trotzdem lohnt, ganz > einfach. Beispielsweise Java mit VI programmieren. Man kann die ganzen Sch..Begriffskonstrukte beim Programmieren schnell mal umbenennen - und wenn es zum Übersetzen geht, kann man den Vorgang genau so schnell zurücknehmen, aber wegen den Umdeutungen kann zwischendurch eben schon ein wenig Spaß damit haben ;) Sheeva P. schrieb: > Wenn Du meine Ausführungen gelesen und verstanden hättest, dann wüßtest > Du, daß ich selbst einer dieser Poweruser mit Emacs und Shell bin. Ist mir schon klar, und ich kann schon ganz gut einschätzen, warum der Emacs so beliebt ist. Letztlich verstehe ich den Witz über Editoren auf xkcd* ja auch sehr gut - aber du erwartest, dass andere Leser hier gewissermaßen zwischen den Zeilen erkennen, was dich vom Emacs so abhängig macht. Übrigens, die Nähe zu Python und zu Tramp lassen erkennen, dass es dir um Realtime eher weniger geht. Naja, man kann ja Wissen- Könnenslücken haben, ist ja nicht so schlimm. Und hinsichtlich des Lernens - die KI hilft mir mit Rust so gut, dass ich mir nicht verkneifen kann, auch etwas über Assembler in Linux zu erfragen. Hach.. *die Nummer hier ist auch gut: https://xkcd.com/862/ Sheeva P. schrieb: > Ehrlich gesagt, fehlen mir die Worte, um zu beschreiben, für wie > bescheuert ich die ganze Idee halte, ausgerechnet unter Linux ein > Notepad unter Wine zu benutzen. Notepad kommt automatisch mit der Wine-Installation mit. Darüber hinaus ist Notepad sehr praktisch, um gewisse Schwierigkeiten mit Wine hinsichtlich 32/64 Bit zu überprüfen. Also eher ein Kontrollmonitor, wenn man so will. Backtrack hatte mal das Arbeiten mit Notepad als Editor in Linux vorgestellt, oder auch wie gut man mit IDA unter diesen Bedingungen arbeiten kann. Genaugenommen hatten die Backtrack-Entwickler mir so die Scheu vor diesem oder jenem Hindernis zu Linux genommen und mir so eigentlich auch den Frust über Sidux gemindert. Sheeva P. schrieb: > Wine ist ein Notbehelf, Das ist auch wieder so ein Allgemeinplatz (und abwertend auch noch), der sich so anhört, als wären alle Angelegenheiten mit Emulatoren oder mit Virtuellen Sachen doof.
Beitrag #8021920 wurde vom Autor gelöscht.
Sheeva P. schrieb: > Ich fürchte, Du hast den Anwendungsfall "keinen X-Server" verfehlt. Auf dem Server läuft dann natürlich immer noch kein X-Server. Die GUI ist ja wie gesagt komplett lokal. Sheeva P. schrieb: > Code und Compiler auf einem Server... Code und Compiler lokal zu haben ist natürlich noch einfacher: Harald K. schrieb: > Für die lldb-Integration gibts eine Extension.
Harald K. schrieb: > Man kann Paranoia auch über das Krankhafte hinweg bis ins final > Pathologische steigern. Wenn Deine Ahnung auch nur halb so groß wäre wie Dein Maul, dann wüßtest Du, daß das hier: > vscode ist ein Open-Source-Projekt. nicht wahr ist. Ja, der Quellcode ist als Github-Repo verfügbar, und darin lügt (Vorsicht, ein Wortspiel!) eine MIT-Lizenz. Die Binaries des Datenkraken dagegen unterliegen aber nicht dieser, sondern jener [1] Lizenz. Die solltest Du wirklich mal lesen, einige der interessantesten Punkte sind Punkt 2a: "The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, [...] There may also be some features in the software that may enable you and Microsoft to collect data from users of your applications." -> Microsoft darf also nicht nur Daten über mich sammeln und verwerten, sondern auch über die Benutzer meiner Software. In diesem Zusammenhang kommt dann auch Punkt 4 ins Spiel: "If you give feedback about the software to Microsoft, you give to Microsoft, without charge, the right to use, share and commercialize your feedback in any way and for any purpose." -> Wenn man die gemäß Punkt 2a ausspionierten Daten als "Feedback" ansieht, dann darf der Datenkrake mit meinen Daten also machen, was er will. Auch Punkt 3 ist interessant: "The software may periodically check for updates and download and install them for you. You may obtain updates only from Microsoft or authorized sources. Microsoft may need to update your system to provide you with updates. You agree to receive these automatic updates without any additional notice. Updates may not include or support all existing software features, services, or peripheral devices." -> Ich erlaube Microsoft also nicht nur, ihr Produkt zu aktualisieren -- und dabei bestimmte Features, Dienste oder Peripheriegeräte zu deaktivieren -- sondern auch, an meinem System herumzufummeln, ohne darüber benachrichtigt zu werden. Punkt 5 ist auch spannend, da wird mir untersagt, "remove, minimize, block or modify any notices of Microsoft or its suppliers in the software;". -> Sie dürfen mich also spammen und ich darf nichts dagegen tun. Sieh mal an, der Datenkrake hat aus den ganzen Malware-Attacken gegen seine Produkte etwas gelernt. Leider nicht, wie man diese Attacken abwehrt, aber immerhin erspart er den Angreifern jetzt viel Arbeit und baut das trojanische Pferd und die Spamschleuder gleich selbst in seine Produkte ein, und es verbietet den Usern dabei gleich auch noch, das zu deaktivieren. Klar, das ist natürlich ein viel gründlicherer und effizienterer Ansatz. Weil all diese Umstände weithin bekannt sind -- okay: außer Dir natürlich -- wurde das VSCodium-Projekt ins Leben gerufen. Das schreibt: "Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking." Das Dumme dabei ist allerdings, daß viele von Microsofts Extensions -- also die Erweiterungen, die aus dem schlichten Editor überhaupt erst so etwas wie eine Entwicklungsumgebung machen -- es wiederum in ihren Lizenzbedingungen verbieten, mit etwas anderem als Microsofts originalem Visual Studio Code zu benutzen und einige mit "inoffiziellen Forks" auch gar nicht funktionieren sollen. Du hast also die Wahl, entweder die Schnüffelei zu akzeptieren, oder eine Lizenzverletzung zu begehen und nicht die volle Funktionalität zu erhalten, oder auf einem simplen Texteditor sitzen zu bleiben. Okay, trotz all dieser Punkte hat es der Datenkrake also geschafft, seine Machenschaften so zu verschleiern, daß Du sie nicht nur mit der Behauptung beschönigst, das sei eine OpenSource-Software, sondern mir dann sogar eine pathologische Paranoia unterstellst. Sie haben Dich also erfolgreich über den Tisch gezogen, Dich zu einem Mittäter ihrer Betrügereien und zu einem ihrer Werbebots gemacht. Ich hoffe Du bist stolz auf Dich! Und nun bleibt am Ende nur noch eine Frage offen, denn pathologische Paranoia ist bei Leuten wie mir ja eine anerkannte Berufskrankheit. Aber was ist Deine Entschuldigung für Deine außerordentlich naive Dummheit? [1] https://code.visualstudio.com/license [2] https://vscodium.com/
Sheeva P. schrieb: > Weil all diese Umstände weithin bekannt sind -- okay: außer Dir > natürlich -- wurde das VSCodium-Projekt ins Leben gerufen. Interessante Frage: wenn ich das Ding also aus einem FreeBSD-Port selbst compiliere, dann habe ich effektiv ein "VSCodium", oder wie?
Rbx schrieb: > Nun ja, Verallgemeinerung bleibt Verallgemeinerung. Ach so? > Man könnte noch > deutlich schlimmeres Andichten Ja, das kannst Du offenbar sehr gut. > - schreibe ich hier aber lieber nicht. Ich wundere mich ohnehin, warum Du etwas schreibst, obwohl Du gar nichts mitteilen kannst. > Beispielsweise Java mit VI programmieren. Man kann die ganzen > Sch..Begriffskonstrukte beim Programmieren schnell mal umbenennen - und > wenn es zum Übersetzen geht, kann man den Vorgang genau so schnell > zurücknehmen, aber wegen den Umdeutungen kann zwischendurch eben schon > ein wenig Spaß damit haben ;) Leider scheinen unsere Definitionen von "Spaß haben" zu differieren. > Ist mir schon klar, und ich kann schon ganz gut einschätzen, warum der > Emacs so beliebt ist. Letztlich verstehe ich den Witz über Editoren auf > xkcd* ja auch sehr gut - aber du erwartest, dass andere Leser hier > gewissermaßen zwischen den Zeilen erkennen, was dich vom Emacs so > abhängig macht. Wow, jetzt dichtest Du mir sogar schon eine Abhängigkeit an. > Übrigens, die Nähe zu Python und zu Tramp lassen > erkennen, dass es dir um Realtime eher weniger geht. Ich habe auch eine Nähe zu C, C++, Golang und Perl, halte zudem eine gesunde Distanz zu JavaScript und einen maximalen Abstand zu Java und PHP. Jetzt bin ich gespannt, zu welch wundersamen Erkenntnissen Dich das verleitet. > Naja, man kann ja > Wissen- Könnenslücken haben, ist ja nicht so schlimm. Naja, ich lege bei mir selbst zwar großen Wert auf Kompetenz und Können, habe aber keine Schwierigkeiten damit, wenn Du das für Dich anders siehst. > Und hinsichtlich > des Lernens - die KI hilft mir mit Rust so gut, dass ich mir nicht > verkneifen kann, auch etwas über Assembler in Linux zu erfragen. Hach.. Das tut mir leid. > Notepad kommt automatisch mit der Wine-Installation mit. Darüber hinaus > ist Notepad sehr praktisch, um gewisse Schwierigkeiten mit Wine > hinsichtlich 32/64 Bit zu überprüfen. Also eher ein Kontrollmonitor, > wenn man so will. Alles in Ordnung bei Dir, geht es Dir gut? > Sheeva P. schrieb: >> Wine ist ein Notbehelf, > > Das ist auch wieder so ein Allgemeinplatz (und abwertend auch noch), der > sich so anhört, als wären alle Angelegenheiten mit Emulatoren oder mit > Virtuellen Sachen doof. Das ist bei Emulatoren ja auch die Wahrheit (tm). Die sind immer ineffizient und eine potentielle Fehlerquelle, wie wir ja nicht zuletzt aufgrund Deiner ebenso zahl- wie wortreichen Beschwerden über Linux wissen, weil Skyrim mit Wine auf Deinem veralteten Linux nicht richtig tut. Virtuelle Maschinen und andere Virtualisierungstechniken wie Container sind hingegen häufig sehr sinnvolle Abstraktionsschichten. Sie mit Emulatoren in einen Top zu werfen, wird daher weder dem Einen noch dem Anderen gerecht.
Niklas G. schrieb: > Sheeva P. schrieb: >> Ich fürchte, Du hast den Anwendungsfall "keinen X-Server" verfehlt. > > Auf dem Server läuft dann natürlich immer noch kein X-Server. Die GUI > ist ja wie gesagt komplett lokal. Wieder daneben. Es ging darum, auf dem Client keinen X-Server zu haben. > Sheeva P. schrieb: >> Code und Compiler auf einem Server... > > Code und Compiler lokal zu haben ist natürlich noch einfacher: > > Harald K. schrieb: >> Für die lldb-Integration gibts eine Extension. Toll, aber... das kann ich auch ohne die Schnüffelsoftware vom Datenkraken. Das mache ich schon seit 30 Jahren so.
Jörg W. schrieb: > Interessante Frage: wenn ich das Ding also aus einem FreeBSD-Port selbst > compiliere, dann habe ich effektiv ein "VSCodium", oder wie? Ich würde sagen ja, aber das können die FreeBSD-Maintainer und / oder die Leute vom VSCodium-Projekt Dir sicherlich kompetenter beantworten.
Jörg W. schrieb: > Sheeva P. schrieb: >> "Esc + .", das übernimmt das letzte Argument des vorigen Kommandos > > Also !$ :-) Genau, aber "Esc +." wirkt sofort, und !$ wie eine Variable.
Sheeva P. schrieb: > Wieder daneben. Es ging darum, auf dem Client keinen X-Server zu haben. Ah, meine Linux Clients haben zum Glück alle genug Leistung für X. Und die Windows Clients brauchen kein X. Sheeva P. schrieb: > Toll, aber... das kann ich auch ohne die Schnüffelsoftware vom > Datenkraken. Das mache ich schon seit 30 Jahren so. Man kann auch die Bits auf der Platte einzeln mit einer Magnetnadel bearbeiten...
Sheeva P. schrieb: > Die Binaries des Datenkraken dagegen unterliegen aber nicht dieser, > sondern jener [1] Lizenz. Niemand zwingt einen, diese Binaries zu verwenden. Man kann den Kram auch selbst bauen. Mach ich sowieso, weil ich das Handling von "virtual white space" dem anpassen will, was mir die von mir genutzten Editoren seit 30+ Jahren erlauben. Den Telemetriekackscheißdreck kann man --zumindest derzeit-- auch abschalten. Dein Tonfall aber gefällt mir, weiter so. Da schaffst Du auf völlig anderem Wege es, die Nivea-Dose des alten Knackers zu erreichen.
Hallo, Jörg W. schrieb: > Interessante Frage: wenn ich das Ding also aus einem FreeBSD-Port selbst > compiliere, dann habe ich effektiv ein "VSCodium", oder wie? So wie ich es verstehe sind dann aber immer noch die Telemetriebestandteile im Kompilat enthalten. Da wäre es doch sinnvoller die VSCodium-Quellen auf GitHub zu nutzen. rhf
Hallo, Sheeva P. schrieb: > Das Dumme dabei ist allerdings, daß viele von Microsofts Extensions ... > es wiederum in ihren Lizenzbedingungen verbieten, mit etwas anderem als > Microsofts originalem Visual Studio Code zu benutzen... Ein genialer Schachzug. Damit werden VSC-Forks neutralisiert und Microsoft hat mittels Telemetrie Zugriff auf die Organisationsstruktur einer Softwareentwicklung. Fehlt dann eigentlich nur noch der telemetrische Zugriff auf die Quellcodes der Konkurrenz. rhf
Hallo, Harald K. schrieb: > Den Telemetriekackscheißdreck kann man --zumindest derzeit-- auch > abschalten. Scheinbar aber nicht alles: Sheeva P. schrieb: > You may opt-out of many of these scenarios, but not > all, [...] rhf
Sheeva P. schrieb: > Ich habe auch eine Nähe zu C, C++, Golang und Perl, halte zudem eine > gesunde Distanz zu JavaScript und einen maximalen Abstand zu Java und > PHP. Jetzt bin ich gespannt, zu welch wundersamen Erkenntnissen Dich das > verleitet. Na gut, bleiben wir mal bei C: wie erklärst du, warum C so gut zur Krypto-Programmierung bzw. Kryptoanalyse einläd? Sheeva P. schrieb: > Das ist bei Emulatoren ja auch die Wahrheit (tm). Die sind immer > ineffizient infwiefern? Abwertende Verallgemeinerungen zu verklappen, liegt dir scheinbar auch ganz gut. Sheeva P. schrieb: > Wow, jetzt dichtest Du mir sogar schon eine Abhängigkeit an. Man muss sich aber schon fragen, wieviel man von dir erwarten kann, wenn du keinen Emacs nutzen könntest, sondern sagen wir mal nur Notepad oder Nano oder auf Windows Notepad++. Sheeva P. schrieb: > Naja, ich lege bei mir selbst zwar großen Wert auf Kompetenz und Können, Dann solltest du dich aber wenigstens mehr in Zusammenhänge mit Statistik einarbeiten. Einbildung ist zwar auch eine Bildung - ein Mangel an Selbsthinterfragen oder Humor wirkt dann aber eher narzisstisch. Sheeva P. schrieb: > Das tut mir leid. Die KI war netter, als ich meinte, dass ich CudaText installiert hatte, und dieser Editor zur Assemblerprogrammierung einläd, hatte die KI einige Vorteile von CudaText diesbezüglich aufgezählt, und mich darüber hinaus ermuntert, weitere Projekte durchzuziehen, mit vielen ansprechenden Beispielprogrammen -szenarien und einem praktischen Template (eine Makefile) für die Asm-Programmierung. Also von der Motivationsseite ist die KI sehr entgegenkommend. Sheeva P. schrieb: > Virtuelle Maschinen und andere Virtualisierungstechniken wie Container > sind hingegen häufig sehr sinnvolle Abstraktionsschichten. Sie mit > Emulatoren in einen Top zu werfen, wird daher weder dem Einen noch dem > Anderen gerecht. So musste man deine Aussage oben aber schon verstehen. Darüberhinaus hast du selber keine - oder nur wenig Erfahrung mit Wine, dafür aber reichlich Missgunst - weswegen Argumente gegen dieser eigentlich auch nichts bringen. Sheeva P. schrieb: > denn pathologische > Paranoia ist bei Leuten wie mir ja eine anerkannte Berufskrankheit. Mit Sicherheit nicht. Tatsächlich macht man sich so über Leute mit wirklicher Paranoia lustig. Kann natürlich ein Balance-Akt sein - aber wie man in den Wald hineinruft.. https://www.youtube.com/watch?v=0qanF-91aJo
Niklas G. schrieb: > Sheeva P. schrieb: >> Wieder daneben. Es ging darum, auf dem Client keinen X-Server zu haben. > > Ah, meine Linux Clients haben zum Glück alle genug Leistung für X. Und > die Windows Clients brauchen kein X. Und wieder beantwortest Du Fragen, die niemand gestellt hat. Lies vor Deiner nächsten Antwort doch bitte erst nach, worum es ursprünglich ging. Danke. > Sheeva P. schrieb: >> Toll, aber... das kann ich auch ohne die Schnüffelsoftware vom >> Datenkraken. Das mache ich schon seit 30 Jahren so. > > Man kann auch die Bits auf der Platte einzeln mit einer Magnetnadel > bearbeiten... Dafür hat der Emacs den Befehl C-x M-c magnetic-needle, aber da bin ich etwas altmodisch und bevorzuge daher C-x M-x butterfly. [1] [1] https://xkcd.com/378/
Harald K. schrieb: > Sheeva P. schrieb: >> Die Binaries des Datenkraken dagegen unterliegen aber nicht dieser, >> sondern jener [1] Lizenz. > > Niemand zwingt einen, diese Binaries zu verwenden. Doch, die Lizenzen vieler Extensions, insbesondere der des Datenkraken. Das hatte ich oben bereits erläutert. > Man kann den Kram auch selbst bauen. ... und muß dann auf die besagten Extensions verzichten oder deren Lizenzen verletzen. Das hatte ich oben bereits erläutert. > Den Telemetriekackscheißdreck kann man --zumindest derzeit-- auch > abschalten. Die Lizenzbedingungen des Datenkraken halten ihm jedenfalls offen, nicht alles deaktivieren zu können. Das hatte ich oben bereits erläutert. > Dein Tonfall aber gefällt mir, weiter so. Da schaffst Du auf völlig > anderem Wege es, die Nivea-Dose des alten Knackers zu erreichen. Ach so: zuerst unterstellst Du mir eine krankhafte psychische Störung und gibst jetzt das Mimöschen. Genau mein Humor.
Roland F. schrieb: > Jörg W. schrieb: >> Interessante Frage: wenn ich das Ding also aus einem FreeBSD-Port selbst >> compiliere, dann habe ich effektiv ein "VSCodium", oder wie? > > So wie ich es verstehe sind dann aber immer noch die > Telemetriebestandteile im Kompilat enthalten. > Da wäre es doch sinnvoller die VSCodium-Quellen auf GitHub zu nutzen. Nach meinem Verständnis -- ohne mich tiefer in die Materie hineinarbeiten zu wollen -- ist es wohl so, daß die Telemetrie nicht in dem MIT-lizensierten Quellcode von VSCode enthalten ist. Das wird wohl erst dann eingebaut, wenn der Datenkrake seine Binaries erzeugt. Aus meiner Sicht ist das auch irgendwo logisch, denn wenn diese Teile im quelloffenen Code vorlägen, könnte man sie ja leicht ausbauen, umbiegen, anderweitig deaktivieren oder den Datenkraken mit Unrat füttern. Roland F. schrieb: > Sheeva P. schrieb: >> Das Dumme dabei ist allerdings, daß viele von Microsofts Extensions ... >> es wiederum in ihren Lizenzbedingungen verbieten, mit etwas anderem als >> Microsofts originalem Visual Studio Code zu benutzen... > > Ein genialer Schachzug. Ja, unbedingt, das ist OpenSource-Software ohne die Freiheiten und Rechte, die mit solcher Software gemeinhin einhergehen. > Damit werden VSC-Forks neutralisiert und > Microsoft hat mittels Telemetrie Zugriff auf die Organisationsstruktur > einer Softwareentwicklung. Fehlt dann eigentlich nur noch der > telemetrische Zugriff auf die Quellcodes der Konkurrenz. Und dazu gehören dem Datenkraken auch noch Github sowie ein Teil von OpenAI, und wenn jemand besonders dumm ist, liefert er auch noch seine geschäftlichen Daten über MS365, E-Mails über Outlook und seine Server über Azure. Es dürfte kaum auszudenken sein, welchen Nutzen der Krake (oder sein Gesetzgeber) aus diesen Daten ziehen und welche Schäden er bei seinen Kunden anrichten kann. Roland F. schrieb: > Harald K. schrieb: >> Den Telemetriekackscheißdreck kann man --zumindest derzeit-- auch >> abschalten. > > Scheinbar aber nicht alles: > > Sheeva P. schrieb: >> You may opt-out of many of these scenarios, but not >> all, [...] Zumindest halten die Lizenzbedingungen diese Möglichkeit offen. Inwieweit das bereits umgesetzt ist, weiß ich nicht. Aber das man sich diese Möglichkeiten offensichtlich offenhalten will, finde ich schon erschreckend genug.
Sheeva P. schrieb: > Das Dumme dabei ist allerdings, daß viele von Microsofts Extensions -- > also die Erweiterungen, die aus dem schlichten Editor überhaupt erst so > etwas wie eine Entwicklungsumgebung machen -- es wiederum in ihren > Lizenzbedingungen verbieten Kann sein, dass ich diese im Opensource-Build gar nicht sehe – alles, was ich mir dort mal so angeschaut habe, hat MIT License. Das ist aber insgesamt zumindest trotzdem nicht gerade wenig, was ich da sehe – auf jeden Fall deutlich mehr als dein „schlichter Editor“.
Rbx schrieb: > Sheeva P. schrieb: >> Ich habe auch eine Nähe zu C, C++, Golang und Perl, halte zudem eine >> gesunde Distanz zu JavaScript und einen maximalen Abstand zu Java und >> PHP. Jetzt bin ich gespannt, zu welch wundersamen Erkenntnissen Dich das >> verleitet. > > Na gut, bleiben wir mal bei C: wie erklärst du, warum C so gut zur > Krypto-Programmierung bzw. Kryptoanalyse einläd? Meine Güte, echt jetzt? C ist in vielerlei Hinsicht der kleinste gemeinsame Nenner. Es kann kleine, performance- und speichereffiziente Executables mit hoher Kontrolle, Lowlevel- und Bitoperationen erzeugen, und die meisten mir bekannten TLS-Libraries (OpenSSL, WolfSSL, GnuTLS, Cryptlib, LibreSSL) sind darin implementiert und können daher -- kleinster gemeinsamer Nenner -- von den meisten Programmiersprachen aus genutzt werden. Andererseits muß ich allerdings leider sagen, daß "einladen" jetzt nicht der von mir gewählte Terminus wäre. Kryptografie ist nicht nur mathematisch sehr komplex, sondern besonders auch in der technischen Umsetzung. Und ich stelle mit großem Bedauern fest: das sieht man auch in der Umsetzung von vielen der genannten C-Bibliotheken, die Lowlevel-APIs sind oft einfach widerlich. Beim OpenSSL-Projekt haben sie dann verstanden daß kryptografische Sicherheit mit Benutzbarkeit zu tun hat und ihre Lowlevel-APIs dann mit einer Highlevel-API namens EVP ergänzt, die auch fies, aber wenigstens halbwegs benutzbar ist. Wenn es irgendetwas gibt, das ich an Java mag, dann ist es, daß sie die bösen APIs größtenteils eliminiert haben. Denn -- dazu kommen wir später nocheinmal zurück -- ich bin der festen Überzeugung, daß Komplexität der inhärente Feind von nahezu allem ist. Und das gilt nicht nur auch sondern vor allem im Umfeld kryptografischer Sicherheit, wo kleine Fehler meistens große Folgen haben. Da haben sich Python und Golang ein paar nette Features abgeschaut. :-) > Sheeva P. schrieb: >> Das ist bei Emulatoren ja auch die Wahrheit (tm). Die sind immer >> ineffizient > > infwiefern? Abwertende Verallgemeinerungen zu verklappen, Das ist weder abwertend noch eine Verallgemeinerung, sondern einfach nur die fachliche Sicht darauf. Schau, wenn ich ein Programm habe, das -- vereinfacht gesagt -- eine Instruktion ausführt und 1 Byte Speicher belegt, und ich führe dieses Programm in einem Emulator auf einer anderen Prozessorarchitektur aus, dann muß das emulierte Programm natürlich dieselbe Instruktion und denselben Speicher belegen. Zusätzlich muß aber irgend etwas -- der Emulatur, um genau zu sein -- zwischen der Prozessorarchitektur, für die das Programm übersetzt worden ist, und derjenigen übersetzen, auf der es ausgeführt wird. Das heißt der Emulator liest die Instruktion der Compilearchitektur und schaut, welche Instruktion(en) auf der Laufzeitarchitektur ausgeführt werden müssen, um zum selben Ergebnis zu gelangen. Diese Übersetzung muß natürlich bezahlt werden, nämlich mit den Instruktionen, die der Emulator ausführt, und dem Speicher, welchen er dafür belegen muß. Bitte lies diesen Absatz [1] in der deutschen Wikipedia dazu. [1] https://de.wikipedia.org/wiki/Emulator#Nachteile_der_Software-Emulation > Sheeva P. schrieb: >> Wow, jetzt dichtest Du mir sogar schon eine Abhängigkeit an. > > Man muss sich aber schon fragen, wieviel man von dir erwarten kann, wenn > du keinen Emacs nutzen könntest, sondern sagen wir mal nur Notepad oder > Nano oder auf Windows Notepad++. Schau, mein Beruf -- und mein Hobby -- ist es, komplexe Sachverhalte von der Fachlichkeit in effiziente Software und Konfigurationen umzusetzen. Das ist eine Kopfarbeit mit vielen Komponenten: kommunikative, technische, bisweilen auch kreative Fähigkeiten. Das hat wenig mit einem Editor zu tun. Zudem kann ich andere Editoren natürlich bedienen. Vielleicht bin ich damit zumindest anfangs nicht so effizient, und womöglich auch langfristig nicht, weil mir Funktionen des Emacs fehlen. Bei Notepad würde mich beispielsweise erheblich stören, daß der weder Syntaxhighlighting noch Autocompletion hat, beim Nano müßte ich das erst konfigurieren und mich daran gewöhnen, daß die Bedienung dieser Features eine andere ist, und was ich bei Notepad++ machen müßte, damit er wie gewünscht funktioniert, weiß ich nicht. Beispielsweise hier im Forum nutze ich aber das Standard-Eingabefeld, in dem viele Sachen durchaus ähnlich funktionieren wie in handelsüblichen Editoren: auswählen beispielsweise mit gedrückter Shift-Taste und dem Curser, gegebenenfalls wortweise durch gleichzeitiges Drücken der Ctrl-Taste. Insofern muß "man" -- wer auch immer das sein mag -- sich da überhaupt gar nichts fragen. Selbstverständlich käme ich auch mit anderen Editoren prima zurande. Obwohl die meisten viele Funktionen meines Emacs nicht können und nicht so fein für mich konfiguriert sind wie mein Emacs. > Sheeva P. schrieb: >> Naja, ich lege bei mir selbst zwar großen Wert auf Kompetenz und Können, > > Dann solltest du dich aber wenigstens mehr in Zusammenhänge mit > Statistik einarbeiten. Einbildung ist zwar auch eine Bildung - ein > Mangel an Selbsthinterfragen oder Humor wirkt dann aber eher > narzisstisch. Schwafel doch nicht, sondern komm' mal auf den Punkt. > Sheeva P. schrieb: >> Virtuelle Maschinen und andere Virtualisierungstechniken wie Container >> sind hingegen häufig sehr sinnvolle Abstraktionsschichten. Sie mit >> Emulatoren in einen Top zu werfen, wird daher weder dem Einen noch dem >> Anderen gerecht. > > So musste man deine Aussage oben aber schon verstehen. Nein, das mußte "man" (schon wieder dieser ominöse "man") nicht, und durfte auch nicht. Ich habe nämlich nicht über Virtualisierung geschrieben, sondern ausdrücklich über Emulatoren. Weißt Du, ich habe dieses Wort benutzt, weil es fachsprachlich genau das bezeichnet, was ich gemeint habe. > Darüberhinaus > hast du selber keine - oder nur wenig Erfahrung mit Wine, dafür aber > reichlich Missgunst - weswegen Argumente gegen dieser eigentlich auch > nichts bringen. Doch, natürlich kann ich das. Dazu brauche ich keine Erfahrungen mit Wine. Emulatoren fügen technisch gesehen mindestens einen zusätzlichen Layer zur Programmausführung hinzu, der immer Ressourcen kostet und zudem auch noch zusätzliche Fehlerquellen zur Programmausführung hinzufügt, jenen letzten Aspekt hatte ich oben noch nicht angesprochen. Jeder Emulator macht alles komplizierter und teurer, und das hat nichts mit Mißgunst zu tun, sondern ausschließlich mit einer fachlichen Perspektive. Nebenbei bemerkt, betrifft das nicht nur Wine, das übrigens ausweislich seines selbstreferentiellen Akronyms -- "Wine is not an emulator" -- außerdem, streng genommen, gar kein Emulator ist, sondern nur viele Eigenschaften mit mit einem klassischen Emulator teilt. In Wine müssen die Befehle der Windowssoftware wie in einem Emulator auf eine Linuxplattform umgesetzt werden, und das wird sogar dann CPU-Zyklen und Arbeitsspeicher benötigen, wenn sich diese Befehle direkt eins zu eins umsetzen ließen. Tatsächlich emuliert Wine jedoch "nur" die APIs von Windows, was ich an dieser Stelle sogar für noch aufwändiger, schwieriger und fehleranfälliger halte als die Emulation von CPUs. > Sheeva P. schrieb: >> denn pathologische >> Paranoia ist bei Leuten wie mir ja eine anerkannte Berufskrankheit. > > Mit Sicherheit nicht. Tatsächlich macht man sich so über Leute mit > wirklicher Paranoia lustig. Sag das einfach dem, das mir die pathologische Paranoia unterstellt hat. Ich bin da nicht der richtige Ansprechpartner. Viel Erfolg.
Jörg W. schrieb: > Sheeva P. schrieb: >> Das Dumme dabei ist allerdings, daß viele von Microsofts Extensions -- >> also die Erweiterungen, die aus dem schlichten Editor überhaupt erst so >> etwas wie eine Entwicklungsumgebung machen -- es wiederum in ihren >> Lizenzbedingungen verbieten > > Kann sein, dass ich diese im Opensource-Build gar nicht sehe – alles, > was ich mir dort mal so angeschaut habe, hat MIT License. Wenn ich das richtig verstanden habe, greifen die "freien Kompilate" nicht auf den Extension-Marketplace des Kraken, sondern einen eigenen zu. > Das ist aber > insgesamt zumindest trotzdem nicht gerade wenig, was ich da sehe – auf > jeden Fall deutlich mehr als dein „schlichter Editor“. Mit "schlichter Editor" war jetzt einer ohne Extensions gemeint.
Sheeva P. schrieb: >> Das ist aber >> insgesamt zumindest trotzdem nicht gerade wenig, was ich da sehe – auf >> jeden Fall deutlich mehr als dein „schlichter Editor“. > > Mit "schlichter Editor" war jetzt einer ohne Extensions gemeint. Schon klar, aber zumindest mit den dann vorhandenen Extensions mit offener Lizenz ist es allemal sehr viel mehr als nur das.
Sheeva P. schrieb: > Tatsächlich emuliert Wine jedoch "nur" die APIs von Windows, was ich an > dieser Stelle sogar für noch aufwändiger, schwieriger und > fehleranfälliger halte als die Emulation von CPUs. Nur die CPU zu emulieren ist zu kurz gedacht. Ein Emulator für Windows muss neben der CPU auch die ganze Hardware drumherum emulieren. An der Stelle wird er dann doch aufwändig.
:
Bearbeitet durch User
Sheeva P. schrieb: > Meine Güte, echt jetzt? C ist in vielerlei Hinsicht der kleinste > gemeinsame Nenner. Es kann kleine, performance- und speichereffiziente > Executables mit hoher Kontrolle, Lowlevel- und Bitoperationen erzeugen, > und die meisten mir bekannten TLS-Libraries (OpenSSL, WolfSSL, GnuTLS, > Cryptlib, LibreSSL) sind darin implementiert und können daher -- > kleinster gemeinsamer Nenner -- von den meisten Programmiersprachen aus > genutzt werden. Hinsichtlich der Analogie des Topfschlagens müsste ich jetzt "Kalt" rufen. Sheeva P. schrieb: > Andererseits muß ich allerdings leider sagen, daß "einladen" jetzt nicht > der von mir gewählte Terminus wäre. Weil du vermutlich die Frage gar nicht richtig verstehst - oder verstehen konntest. Weil deine Nähe zu C doch eher nur oberflächlich ist? Sheeva P. schrieb: > Und ich stelle mit großem Bedauern fest: das sieht man auch > in der Umsetzung von vielen der genannten C-Bibliotheken, die > Lowlevel-APIs sind oft einfach widerlich. Hast du keinen Python-Wrapper gefunden? Oder macht es zu oft PENG!, wenn du das tust? Sheeva P. schrieb: > daß Komplexität der > inhärente Feind von nahezu allem ist. In der Psychologie war "Komplexität" damals noch ein kultiger Heilsbegriff nach "Chaos". Sheeva P. schrieb: > Bitte lies diesen Absatz [1] in der deutschen Wikipedia dazu. Man fragt sich, wer den Text da wohl geschrieben hat. Warst du das? Python oder Tramp sind auch alles andere als schnell. Na und? Und wenn man auf Zusammenhangsüberlegungen verzichtet: Skyrim läuft jedenfalls recht performant auf Wine. Ärger machen eher die Grafikkartentreiber-Situationen oder Steam. Dabei stand auf der Verpackung, das Steam nur zur Aktivierung des Spiels nötig ist, und nicht für die volle Kontrolle. Sega Rally läuft sogar deutlich flüssiger mit Wine statt mit Windows8.1 Prinzipiell läuft es aber gut auch auf Windows ME. Sheeva P. schrieb: > Schau, mein Beruf -- und mein Hobby -- ist es, komplexe Sachverhalte von > der Fachlichkeit in effiziente Software und Konfigurationen umzusetzen. Also sowas wie OpenSSL? Sheeva P. schrieb: > Schwafel doch nicht, sondern komm' mal auf den Punkt. Der Hinweis auf mehr Einarbeitung in die Statistik/Wissenschaft ist kein Geschwafel. Werde besser darin, dann schwafele ich auch nicht - um es mal so zu umschreiben. Sheeva P. schrieb: > Weißt Du, ich habe > dieses Wort benutzt, weil es fachsprachlich genau das bezeichnet, was > ich gemeint habe. Jetzt schwafelst du aber. Sheeva P. schrieb: > sondern ausschließlich mit einer fachlichen > Perspektive. Die wohl auch sehr einfach gestrickt ist. Sheeva P. schrieb: > Ich bin da nicht der richtige Ansprechpartner. Da müsste ich dann aber auch schon wieder "kalt" rufen.
Jörg W. schrieb: > Sheeva P. schrieb: >> Mit "schlichter Editor" war jetzt einer ohne Extensions gemeint. > > Schon klar, aber zumindest mit den dann vorhandenen Extensions mit > offener Lizenz ist es allemal sehr viel mehr als nur das. Aber Jörg, darum ging es doch gar nicht. Es ging darum, daß erst Extensions aus einem simplen Editor eine Entwicklungsumgebung machen. Anders gesagt: keine Extensions == simpler Editor mit Extensions == Entwicklungsumgebung Ob es sich um kommerzielle oder freie Extensions handelt, ist von dieser Aussage in keiner Weise betroffen.
Rbx schrieb: > Sheeva P. schrieb: >> Meine Güte, echt jetzt? C ist in vielerlei Hinsicht der kleinste >> gemeinsame Nenner. Es kann kleine, performance- und speichereffiziente >> Executables mit hoher Kontrolle, Lowlevel- und Bitoperationen erzeugen, >> und die meisten mir bekannten TLS-Libraries (OpenSSL, WolfSSL, GnuTLS, >> Cryptlib, LibreSSL) sind darin implementiert und können daher -- >> kleinster gemeinsamer Nenner -- von den meisten Programmiersprachen aus >> genutzt werden. > > Hinsichtlich der Analogie des Topfschlagens müsste ich jetzt "Kalt" > rufen. Was wäre denn Deiner Meinung nach die "heiße", sprich: richtige Aussage?
Sheeva P. schrieb: > Was wäre denn Deiner Meinung nach die "heiße", sprich: richtige Aussage? Frag doch mal die KI. Die KI hatte auf die Frage oben ganz ähnlich darauf wie du geantwortet. Aber wenn man Know How hat, kann man die KI auf gewisse Punkte ansprechen, und dann kam die Erleuchtung. Und danach hatten wir uns wunderbar über Krypto unterhalten, das hatte auch viel Spaß gemacht. Die KI hat mir übrigens auch genauer erklärt, warum die OpenSSL-Situation so schwierig ist. Beim nächsten mal frage ich die KI, ob das mit modularer Programmierung mit Assembler auch so schwierig geworden wäre. Die KI meine aber auch so grob, dass bei OpenSSL nicht mehr allzuviel zu retten ist. Dann ging es noch weiter mit Neuschreiben in Rust, und die KI meinte, das würde aber Jahre bis Jahrzehnte dauern und dann meinte ich, mit besserer Zusammenarbeit ging es vielleicht viel schneller. Dann ging es weiter um die VHS-Situation, und KI-Flüsterei und ich hatte versprochen, genau diese Angelegenheit mal bei den Volkshochschulen anzuregen.
:
Bearbeitet durch User
Rbx schrieb: > Sheeva P. schrieb: >> Was wäre denn Deiner Meinung nach die "heiße", sprich: richtige Aussage? > > Frag doch mal die KI. Ich frage aber Dich. Was wäre die richtige Aussage?
Beitrag #8023289 wurde von einem Moderator gelöscht.
Beitrag #8023591 wurde von einem Moderator gelöscht.
Beitrag #8023647 wurde von einem Moderator gelöscht.
Beitrag #8023699 wurde von einem Moderator gelöscht.
Beitrag #8023866 wurde von einem Moderator gelöscht.
Weil's so schön ist habe ich mein erwähntes Setup hier noch einmal ausführlich beschrieben inkl. Demo-Projekten: https://github.com/Erlkoenig90/VSCodeCMakeDemo Also Verwendung von VS Code mit CMake und Ninja (Multi-Config) unter Windows und Linux inklusive detaillierter Installationsanleitung. Zusätzlich hab ich noch die Verwendung des Paketmanagers Conan mit einbezogen, womit man ziemlich einfach alle möglichen externen Bibliotheken einbinden kann - das ist eine ziemliche Stolperfalle gerade für Einsteiger. Als Beispiel wird damit ein simples OpenGL-Beispiel für 3 Plattformen gebaut, mit ziemlich minimaler Projekt-Konfiguration. Als kleines Gimmick wird auch noch per CI in der Cloud kompiliert. Das ergibt ein skalierbares Rundum-Sorglos-Setup mit modernem und portierbarem Tooling bei überschaubarem Aufwand.
Niklas G. schrieb: > Weil's so schön ist habe ich mein erwähntes Setup hier noch einmal > ausführlich beschrieben inkl. Demo-Projekten: > > https://github.com/Erlkoenig90/VSCodeCMakeDemo > > Also Verwendung von VS Code mit CMake und Ninja (Multi-Config) unter > Windows und Linux inklusive detaillierter Installationsanleitung. Sehr cool, danke. Es ist ja immer wieder spannend, auch mal über den eigenen Tellerrand zu blicken. Einzig "--break-system-packages" gefällt mir nicht so gut, gibt es dabei denn keine Möglichkeit, das mit einem Virtual Environment (Python-Modul venv [1]) zu verwenden? [1] https://docs.python.org/3/library/venv.html
Ein T. schrieb: > Sehr cool, danke. Es ist ja immer wieder spannend, auch mal über den > eigenen Tellerrand zu blicken. Danke, hoffentlich hilft's ;-) Ein T. schrieb: > gibt es dabei denn keine Möglichkeit, das mit einem > Virtual Environment (Python-Modul venv [1]) zu verwenden? Doch das geht auch, ist von conan sogar offiziell empfohlen ;-) Dann muss man die Environment eben vor jedem "conan" Aufruf aktivieren oder den kompletten Pfad zu conan angeben. Ich mag die venv's nicht besonders, ist wohl etwas Geschmackssache.
Niklas G. schrieb: > Ein T. schrieb: >> Sehr cool, danke. Es ist ja immer wieder spannend, auch mal über den >> eigenen Tellerrand zu blicken. > > Danke, hoffentlich hilft's ;-) Naja, VSC und ich werden vermutlich keine Freunde, dazu hatte ich ja weiter oben einige Anmerkungen geschrieben. ;-) > Doch das geht auch, ist von conan sogar offiziell empfohlen ;-) Dann > muss man die Environment eben vor jedem "conan" Aufruf aktivieren oder > den kompletten Pfad zu conan angeben. Ich mag die venv's nicht > besonders, ist wohl etwas Geschmackssache. Der Vorteil ist aus meiner Sicht, daß damit keine Systempackages beschädigt werden können. Das ist unter Windows, das standardmäßig ohnehin kein Python hat, vermutlich keine sonderlich große Gefahr. Aber die Linuxdistributionen haben häufig eine Python-Installation dabei und zum Beispiel Ubuntu und die Derivate davon haben benutzen sie auch für verschiedene Systemdinge. Es wär blöd, wenn da durch Versionsinkompatibilitäten (die sehr selten auftreten, aber zum Beispiel bei PyYAML war da mal was...) etwas kaputt ginge. Mein Rat wäredeswegen, "conan" lieber außerhalb des $PATH zu installieren (etwa in /opt/notinpath/) und stattdessen ein Shellskript zu benutzen: [code] #!/bin/sh . /path/to/venv /opt/notinpath/conan $@ [/path] Trotzdem, lieben Dank und viel Spaß! ;-)
Ein T. schrieb: > Naja, VSC und ich werden vermutlich keine Freunde, dazu hatte ich ja > weiter oben einige Anmerkungen geschrieben. ;-) In den Monderator-gelöschten Kommentaren? 🤔 Ein T. schrieb: > Der Vorteil ist aus meiner Sicht, daß damit keine Systempackages > beschädigt werden können. Ist mir noch nie passiert aber okay... Ein T. schrieb: > Mein Rat wäredeswegen, "conan" lieber außerhalb des $PATH zu > installieren (etwa in /opt/notinpath/) und stattdessen ein Shellskript > zu benutzen: Ich wollte es erstmal möglichst einfach machen und das Rumhantieren mit zusätzlichen Shell-Skripten vermeiden. Vielleicht besser einfach ein Symlink, die sind dafür unter Windows nicht so straight-forward. Ein T. schrieb: > /opt/notinpath/conan $@ Wenn schon dann
1 | exec /opt/notinpath/conan "$@" |
Niklas G. schrieb: > Ein T. schrieb: >> Der Vorteil ist aus meiner Sicht, daß damit keine Systempackages >> beschädigt werden können. > > Ist mir noch nie passiert aber okay... Mir auch nicht, aber ich bin schon seit Jahren mit Docker unterwegs, da habe ich natürlich viel mehr Möglichkeiten und Kontrolle. Und auf meinen Systemen arbeite ich außerdem immer mit Virtual Environments -- schon um eine saubere requirements.txt erzeugen zu können. > Ein T. schrieb: >> /opt/notinpath/conan $@ > > Wenn schon dann > >
1 | exec /opt/notinpath/conan "$@" |
Da hast Du natürlich vollkommen Recht! :-)
Jörg W. schrieb: > Früher konnte man ab Cursor bis zum Ende > der Zeile noch mit ^K in der URL-Zeile des Firefox löschen, aber das > geht leider schon lange nicht mehr. Eigentlich schade, jetzt muss man > das umständlich mit der Maus machen. Wieso mit der Maus? Das geht auch mit Tastatur immer noch recht angenehm - zumindest für meine Wenigkeit. Windows: Shift+Ende, dann Entf Mac: COMMAND+Shift+Cursor rechts, dann Backspace
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.