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)?
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?
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.
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.
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:
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.
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.
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.
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.
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...
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.
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...
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.
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.
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.
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?
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?
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.
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.
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. ;-)
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.
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:
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?
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.
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.
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:
[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.
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")
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".
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.
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.
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.
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...
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.
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.
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... :-)
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.
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
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.
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.
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).
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.)
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 ;)
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.
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.
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)
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)
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)¹. :-)
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.
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. :-/
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.
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).
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.
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.
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.
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.
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?
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.
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! :-)
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.
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! :-)
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.
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:
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.
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.
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.
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.
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.
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 ;)
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..
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.
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.
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?
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.
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.
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.
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.
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?
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++.
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.
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.
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.
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
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.
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.
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.
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“.
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. :-)
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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:
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.
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.
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
Wie jetzt, Emacs hat doch bestimmt einen Browser eingebaut, wieso
braucht es da noch einen Browser mit Emacs-Mode?
Gerüchte-weise soll in den neueren Emacs Versionen eine Altersverifikation eingebaut werden, da die Dinger im weitesten Sinne als Betriebssystem gelten.
Gerüchte-weise soll in den neueren Emacs Versionen eine
Altersverifikation eingebaut werden, da die Dinger im weitesten Sinne
als Betriebssystem gelten.
