Ein T. schrieb: > spricht eher dafür schrieb: >> Ein T. schrieb: >>> Außerdem >>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von >>> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. >>> Stallman himself. >> >> wann hat er diese Dokumentation geschrieben? ;-) > > Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber > die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The > Extensible, Customizable, Self-Documenting Display Editor", stammt von > 1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen > Jahren heißt es "GNU Emacs Reference Manual" [3]. Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL erfunden hat. rbx schrieb: > Das Referenzbeispiel hier ist aber eher Elvis. > > ( http://elvis.the-little-red-haired-girl.org/ ) Sehr schön. Elvis war schon Anfang der 90er für mich ein abschreckendes Beispiel für einen Editor unter Linux. Habe ihn dann trotzdem gelegentlich genutzt weil immer vorhanden. Später habe ich ihn dann nie mehr gefunden. Auch nicht die Website. Deshalb danke für die Verlinkung. udok schrieb: > Hier noch die Anzahl der Codezeilen. Da sind die Vim "Erweiterungen" > nicht dabei. Auch fehlen etliche externe Libs. > Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr > als 100k Zeilen aber irgendwas falsch. Die neuste Version von vim ist auch schon ganz schön fett geworden.
udok schrieb: > Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr > als 100k Zeilen aber irgendwas falsch. Ich muss gestehen das ich mir noch nie die Anzahl der Zeilen Sourcecode angesehen habe um eine Pro/Contra Entscheidung zu treffen. Ich fand's immer recht angenehm wenn der Editor mich einfach meine Arbeit machen ließ.
Ein T. schrieb: > Außerdem > gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von > einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. > Stallman himself. Original-Dokus sind oft schwer verständlich und didaktisch eine halb- bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere.
Heinz schrieb: > Original-Dokus sind oft schwer verständlich und didaktisch eine halb- > bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere. und der Quellcode erst.. Stallmann meinte mal er hatte den Algoteil (der mit dem Totenkopf in der Originalquelle) noch viel eleganter bzw. smarter hinbekommen. Man stelle sich den Emacs Assembler-Optimiert vor, mit allem was man da heute so hat, mit Profiler einsteigen, Algoschinken, Rip-Mode, SSE, AVX (por Reg (String drin) 20h)(Alternative, OR AH, 20h) viele 64 Bit Register, Cuda als Rechenhilfe (also sowas wie Excel - Ersatz bzw. der neue Emacs- "Excel-Mode") und dann auch noch "Cloud-Optimierung" mit richtig guten Leuten.. Ansonsten scheinen ja keine Dokumentation (etwa wie bei Grafikkarten oder bei ARM hier und da), nur teilweise Dokumentation oder erbärmliche Dokumentation recht beliebt zu sein. Naja, wenn man das Know How hat und den Grips und eine gute Uniausbildung/UniBib auch noch, hat man zumindest einen Wettbewerbsvorteil. Vimscript ohne populäre Schnittstelle hat zumindest den Vorteil, nicht gleich wie mit Java an die Wand fahren zu müssen, oder mit neovim gewissermaßen Skyrim heavily-modded zu spielen. Der Cloud-Gedanke, bzw. das was Stallmann meint, ist ja so schlecht nicht, wenn man z.B. an die Automagie beim Start von Knoppix denkt, oder an den Emacs (der "Ersatzdesktop") bei Cygwin. Bei Cygwin ist (oder war, keine Ahnung) auf jeden Fall der Emacs der beste Editor ;) (da kann glaube ich auch kein WSL mithalten) Bei Fedora Workstation beschäftigt mich auch die Frage, Vim oder Neovim? Viel fesselnder finde ich aber die Frage, wie Neovim in Windows compilieren? Mit Watcom 32 Bit sollte das schon mal (weitgehend) reibungslos gehen. Spannender wird es bei 64 Bit. Wie weit kommt man mit Open Watcom V2? Aber neovim als 16-Bit Variante wäre meiner Meinung nach auch nicht so verkehrt. Back to the roots - würde ich mal so sagen. (das wäre dann z.B. Neovim für DOSBox) (könnte man statt Lua den C-Script Support vom Tiny C Compiler benutzen. Aber ach, der ist ja auch so 32 Bit..) Na, alles nicht so einfach.. https://stackoverflow.com/questions/3827370/h Ein T. schrieb: > rbx schrieb: >> Suchmaschine spukt u.a. aus: > > In Deiner Suchmaschine spukt es? 8-O Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. Das hat natürlich auch gewisse Vorteile, z.B. wenn man als Anrufer (wie ein echter Engel) bevorzugt wird in der ansonsten körperlich anwesenden Wartesschlange.
Hier noch Infos zum Speicherverbrauch und zur Suche unter Windows 10. Gemessen mit ProcessHacker. Der gvim ist auch unter Windows ein guter Allrounder - wenn man ihn bedienen kann... Interessanterweise ist auch der Notepad - über denn ja jeder lästert - vorne dabei. Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze 100MByte File in den Speicher holt. Bei der Suche kackt er aber ab. Alle anderen sind abgeschlagen. Wordpad und Word sind abgeschlagen, aber die konvertieren das Format intern um, und haben daher einen ordentlichen Nachteil.
1 | Peak Speicherverbrauch beim Öffnen von 100 Megabyte File mit 10 Millionen |
2 | Zeilen (Zahlen von 000000000 - 009999999) |
3 | => File Öffnen und Suchen des Strings 009999999, OS = Win 10 |
4 | |
5 | Editor | Peak Speicher [MB] | CPU Cycle [1e9-Cycles] | Kommentar |
6 | ========================================================================== |
7 | WinVi | 4.5 | 22.9 |
8 | gvim | 149 | 6.5 |
9 | Win10 Notepad | 272 | 4.3 |
10 | Notepad++ | 362 | 15.2 |
11 | Notepad2 | 372 | 12.3 |
12 | Visual Studio 2008 | 445 | 10.8 |
13 | Visual Studio 2022 | 616 | 149.8 |
14 | Wordpad | 845 | 236.0 |
15 | WinWord 2010 | 1230 | 579.0 |
16 | Notepad3 | | | Öffnet nicht |
17 | PsPad | | | Öffnet nicht |
18 | vi-Elvis | | | Öffnet nicht |
19 | ========================================================================== |
udok schrieb: > Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze > 100MByte File in den Speicher holt. Bei der Suche kackt er aber ab. > > Alle anderen sind abgeschlagen. Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am Speicherbedarf zu messen. Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei WinVi, Speicher nicht nutzt obwohl er vorhanden ist. Wichtig ist nur, dass er selbst für sich nicht viel braucht, also schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal etwas editieren" ist. Ich hatte, wie bereits gesagt, noch nie die Notwendigkeit solche großen Dateien mit Texteditoren zu öffnen. Was ich schonmal öffnen musste, war eine große Datendatei, für so etwas nutze ich aber einen Hexeditor und da sind drei Kriterien wichtig: 1. Kann der Hexeditor größere Dateien öffnen und bearbeiten als RAM vorhanden ist? 2. Nutzt er für die Bearbeitungsfunktionen das RAM oder lässt er es brach liegen. 3. Kann er auf solche in 1 beschriebenen Dateien auch Search and Replace anwenden ohne auszusteigen? Leider scheiterten da viele HexEditoren, die damit warben, unlimitiert große Dateien öffnen und bearbeiten zu können. Die S&R Funktion ist wohl leider oft so implementiert, dass hier dann nicht an den Speicherbedarf gedacht wird. Vermutlich rührt das daher, dass im RAM zuerst eine Datentstruktur aller gefunden Matches aufgebaut wird und dann der Nutzer gefragt wird, was er mit diesen jeweils einzeln oder auf alle angewendet machen möchte. Und hier steigen viele Hexeditoren dann aus, weil kein RAM mehr vorhanden ist und die aber mehr brauchen um die Sucheinträge unterzubringen. > Visual Studio 2008 | 445 | 10.8 > Visual Studio 2022 | 616 | 149.8 Wer eine 100 MiB große Quellcodedatei in eine IDE lädt, der macht etwas falsch.
Nano schrieb: > Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am > Speicherbedarf zu messen. > Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei > WinVi, Speicher nicht nutzt obwohl er vorhanden ist. > > Wichtig ist nur, dass er selbst für sich nicht viel braucht, also > schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal > etwas editieren" ist. Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist. Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache. Startupzeit ist sicher ein weiteres wichtiges Kriterium. Einfache intuitive Bedienung und Integration ins OS ist auch wichtig, An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie gewöhnen. Schon interessant und frustrierend, das es nach >50 Jahren Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.
udok schrieb: > An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie > gewöhnen. Du kannst Dir die Tastaturbelegung doch beliebig umbasteln :) Ich finde es eher nervig, dass die GVIM packager für Windows immer ein "Windowsuseraugliches" Keymapping aktivieren. Aber das kann man ja zum Glück auch wieder rausschmeissen ;) /regards
udok schrieb: > Einfache intuitive Bedienung ist auch wichtig, Da bist du aber bei vi und Derivaten davon absolut falsch ;)
Ich benutze den vim in der Geschmacksrichtung "cream", das läuft auch unter wine. Für AVR-Assembler habe ich allerdings eine Syntax-highlighting-Datei im Web suchen müssen, die war nicht dabei. Schon von 2005, ist hier angehängt. Aber Geany kann es auch, in letzter Zeit habe ich den Cream nicht mehr benutzt.
Ich habe geany mit gedit verwechselt. Dort heißen die syntax-Dateien (xml) ".lang" und liegen unter /usr/share/gtksourceview->Version>/language-specs Speziell AVR habe ich nicht, aber mit "asm.lang" sieht es schon einigermaßen korrekt aus. Mit cream ist die Druckereinstellung etwas umständlich. Ich habe es für den PDF-Druck in mir angenehme Form eingerichtet.
:
Bearbeitet durch User
Karl Otto II. schrieb: > Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL > erfunden hat. Das stimmt, die Dokumentationen [1] unterliegen der GNU Free Documentation License [2]. Die GFDL ist die Lizenz des GNU-Projekts für Dokumentationen. Irgendwie beschleicht mich das Gefühl, daß Du mir etwas sagen möchtest. Aber leider komme ich nicht darauf, was das sein könnte. [1] https://www.gnu.org/software/emacs/manual/ [2] https://www.gnu.org/licenses/fdl-1.3.de.html
Heinz schrieb: > Ein T. schrieb: >> Außerdem >> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von >> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. >> Stallman himself. > > Original-Dokus sind oft schwer verständlich und didaktisch eine halb- > bis vollkatastrophe ;) Das sehe ich nicht so. > Dazu kommt noch die Sprachbarriere. Englisch kann man lernen, das ist gar nicht so schwierig -- und wer Software oder Elektronik entwickeln will, kommt darum ohnehin nicht herum. Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus, da ist bestimmt auch etwas für Dich dabei.
rbx schrieb: > Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, > hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so > körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche Gesellschaft. ;-)
Ein T. schrieb: > Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für > die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus, > da ist bestimmt auch etwas für Dich dabei. Da habe ich schon vor über 20 Jahren gesucht und nur von der Fernuni Hagen etwas brauchbares zu Emacs gefunden. Aber etwas, das Inhaltlich im Umfang darüber hinausgeht, dann leider nicht. Habe dann mit Emacs sogar meine Diplomarbeit geschrieben. Heute benutze ich vi und emacs nur mal um einen Wert in einer Konfigurationsdatei zu ändern, dazu reichen dann meine Kenntnisse auch. Ansonsten benutze ich heute Notepad++ und VS Code. Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir meine Zeit zu schade. Deren Zeit ist einfach abgelaufen. Ein Editor ist für mich Werkzeug und nicht Selbstzweck.
timol schrieb: > Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir meine > Zeit zu schade. Um mit VScode effizient zu arbeiten, musst du dich genauso einarbeiten. Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal (mindestens die unterschiedliche Modi muss man kennen). Ich staune da immer wieder über meine Kollegen, weil ich mir viele der nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in Ordnung so.
Jörg W. schrieb: > Ich staune da immer wieder über meine Kollegen, weil ich mir viele der > nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs > effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in > Ordnung so. Klar ist es völlig in Ordnung. Mir kann es doch egal sein, womit sich hier wer quälen will. Ich kenne nur keinen Entwickler, der mit vim programmiert, aber ich weiß natürlich dass es welche gibt. In den meisten Firmen gibt es auch sehr strenge Vorgaben womit entwickelt wird, wie dokumentiert wird und wie der Code auszusehen hat. Oft hat da sogar auch der Kunde noch mitzureden. Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders.
Jörg W. schrieb: > Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten > ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal > (mindestens die unterschiedliche Modi muss man kennen). Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man direkt im Insert-Mode, und es können die von Windows bekannten Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S (save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur Verfügung. Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.
timol schrieb: > Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders. Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was du hier gerade heraus hängen lässt.
udok schrieb: . Schon interessant und frustrierend, das es nach >50 Jahren > Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt. Das könnte vielleicht auch daran liegen, dass diese Wünsche ein sehr bewegliches Ziel sind. Der Eine will mal schnell eine Zeile in einer Konfigdatei ändern, ein anderer hingegen grosse Datendateien editieren, wieder einer möchte das Gesamtkunstwerk grafisch, aberauch über eine SSH-Verbindung nutzen, und jeder davon hätte es gerne möglichst komfortabel. Also im eigenen Sinne und für alle möglichen Definitionen des Wortes komfortabel, versteht sich. Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig und/oder unwichtig erklärt.
udok schrieb: > Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist. > Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache. hüstel Äh, bitte entschuldige... mit einem Editor? 8-O
Ein T. schrieb: > udok schrieb: >> Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist. >> Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache. > > hüstel Äh, bitte entschuldige... mit einem Editor? 8-O räusper Er meint bestimmt einen Hexeditor ;-)
alex schrieb: > Da bist du aber bei vi und Derivaten davon absolut falsch ;) Nö die Fanboys finden das Teil super und geilen sich seit hunderten von Beiträgen daran auf. Da müssen dann schon auch mal (Text-) Dateien mit 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch Datendateien mit einem Editor bearbeiten muß, der macht was falsch. Aber gut das Lieblingsspielzeug ist ja so geil, da ist das völlig wurscht ob man am Ende der Datei noch weis was in der 3. Zeile stand. Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen auch vi, vim oder wie sie alle heißen mögen. Damit wird die Arbeit erledigt und gut ist es. Mir würde es im Traum nicht einfallen so ein Gewese um dieses Thema zu machen. Ein Editor ist ein Werkzeug, das für meine Zwecke funktionieren muß - mehr nicht.
Zeno schrieb: > Da müssen dann schon auch mal (Text-) Dateien mit > 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig > derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch > Datendateien mit einem Editor bearbeiten muß, der macht was falsch. Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format enthält? Was sind die Alternativen? Die Software, die die Daten erzeugt neu entwickeln? Einen anderen Job suchen, der nicht mit solchen Dateien zu tun hat? Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen Dateien oder dem Editor meiner Wahl. Meine Kollgen haben keine Probleme mit diesen Dateien oder dem Editor meiner Wahl. Mein Chef hat keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Unsere Kunden haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Nur du und nano haben Probleme damit. Und ihr wisst nichteinmal was das für Dateien sind und was damit gemacht werden muss.
Zeno schrieb: > Mir würde es im Traum nicht einfallen so ein Gewese um dieses Thema zu > machen. Warum machst du es denn dann?
Kiffer schrieb: > Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), > für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die > Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig > und/oder unwichtig erklärt. Nein, so war das nicht. Nano hat eingangs klargestellt für was er welchen Editor verwendet und warum. Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der vim zwar unbestreitbar besser performt, die für ihn aber nicht relevant seien. Das ändert freilich nichts daran dass er sich in den darauf folgenden technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war, überhaupt auf die Beispiele einzugehen.
:
Bearbeitet durch User
Le X. schrieb: > Sein Fehler war, überhaupt auf die Beispiele einzugehen. Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler bezeichnen. ;-) Wofür sollte er überhaupt gut gewesen sein? Irgendein ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen, scheint er nicht zu haben, was man schon an seinem Abqualifzieren derjenigen als "Fanboys" gut erkennen kann.
udok schrieb: > Schon interessant und frustrierend, das es nach >50 Jahren > Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt. Auch nach über 100 Jahren Automobilbau gibt es noch kein Automobil, das alle Wünsche nach Fahrleistung, Transportkapazität, Wirtschaftlichkeit, Umweltfreundlichkeit und Protzigkeit erfüllt. Immerhin scheint bei den Editoren jeder Diskussionsteilnehmer hier einen gefunden zu haben, der zumindest seine persönlichen Erwartungen erfüllt. Somit besteht womöglich gar kein Bedarf an der eierlegenden Wollmilchsau (falls diese überhaupt realisierbar ist).
Nano schrieb: > Petr T. schrieb: >> Openbsd schrieb: >>> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die >>> ultimativen Vorzuege dieses Editors? >> >> Selbstverständlich! >> >> Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du >> z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw. > > Mit JEDEM mit Mausbedienung! > > Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann > 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig! > > Insgesamt also 2 Tasten, nicht 3. Ja, und das ganze dauert 10x so lange und die Chance, dass man mit der Maus nicht ganz genau ist und evtl. mehr oder weniger löscht, ist ziemlich hoch. Das ist weder effizient noch ergonomisch. Alleine die Zeit, die ich dazu brauche meine Hand von der Maus auf die Tastatur zu wechseln ist mindest doppelt so viel wie "5dd" zu drücken. >> Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn >> gesund hält... > > Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus. Meine Güte, so ein Schwachsinn!
Petr T. schrieb: > Meine Güte, so ein Schwachsinn! Eine weitere Diskussion auf diesem Niveau erübrigt sich.
Le X. schrieb: > Kiffer schrieb: >> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), >> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die >> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig >> und/oder unwichtig erklärt. > > Nein, so war das nicht. Aber ja doch, genau so war das. Zu Anfang ist er gleich mal mit einer überheblichen Provokation in diesen Thread eingestiegen (Beitrag "Re: Vi Editor ausgestorben?") und dann hat er das passende Echo nicht vertragen und die Vollmimi gegeben. Und im Laufe dieser Entwicklung, die er mit seiner viel zu großen Klappe selbst bewußt und gezielt provoziert hat, hat er mehrfach die Contenance verloren, die Aufgaben und Wünsche anderer entweder einfach ignoriert oder für unwichtig erklärt, wieder andere wurden von ihm herablassend behandelt, als Straftäter diffamiert und als drogensüchtig bezeichnet. Auf dem Höhepunkt seines Auftritts, der vom ersten Beitrag an nichts als eine gezielte, bewußte und gewollte, maximal herablassende, arrogente und besserwisserische Peovokation war, hat Mr. Mimimi sich soger entblödet, nach den Moderatoren zu rufen, als ob die nicht schon genug mit den anderen ungezogenen Kleinkindern zu tun hätten. Chill mal Deine Base, LeX.
Jörg W. schrieb: > Irgendein > ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen, > scheint er nicht zu haben, was man schon an seinem Abqualifzieren > derjenigen als "Fanboys" gut erkennen kann. Das Wort "Fanboy" hat Nanos (wieder einmal, honi soit qui mal y pense) Beschützer LeX in diese Diskussion eingebracht. Sein Schützling hat das dann nur übernommen.
Kiffer schrieb: > Chill mal Deine > Base, LeX. Chillt am besten alle mal eure Base und kommt wieder zum Thema zurück.
Der Kiffer hier sollte mal weniger Drogen nehmen. Na immerhin passt der Name.
Jörg W. schrieb: > timol schrieb: >> Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders. > > Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was > du hier gerade heraus hängen lässt. Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten mit nachvollziehbaren Argumenten die Welt erklärt, hier haben. So sind die Threads hier im Forum gleich unterhaltsamer. Aber ein Mod kann sich hier ja aufführen wie ein A...
mh schrieb: > Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere > 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format > enthält? Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei entsteht. Eine Datei mit Sourcecode, egal welche Programmiersprache wird wohl kaum so groß werden. Wenn man wirklich soviel Sourcecode unterbringen muß, dann teilt man das Projekt in halbwegs verdauliche Häppchen auf. bei meinem größten Projekt hatte eine Sourcecodedatei, die Hauptdatei des Projektes (insgesamt ca. 800 Sourcecodefiles), knapp 18000 Textzeilen (760kB) und das war eigentlich schon zu viel. Das Teil ist über 20 Jahre gewachsen, weil immer wieder neue Anforderungen dazu gekommen sind. Heute würde ich das anders machen. Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß. Bei dem erwähnten Programm handelt es sich um eine SW zum Auswerten von Messreihen. Die Daten liegen als ASCII Dateien vor sind aber selten größer als 10kB. Ausnahme sind Unixdatenfiles die meist als Wiederholungsprotokolle vorlagen, also noch zusätzlichen Fülltext enthielten. Die von mir entwicklte SW hat die Daten auch wieder im ASCII-Format gespeichert - Dateigröße ca. 10kB, davon aber meist so 10 Stück pro Messreihe, also isgesamt 100kB. Selbst bei sehr umfänglichen Messreihen war das Gesamtdatenvolumen nicht größer als 1MB, also 1% von Deinen 100MB - aufgeteilt auf mehrere Dateien. Mit anderen Worten wer so große Datendateien enstehen läßt macht was falsch. Solche Riesendateien kann kein Mensch mehr überblicken, geschweige denn vernünftig auswerten. Wenn derartige Datenmengen anfallen dann heißt das Stichwort Datenbank, die bringt dann auch die passenden Tools mit um die Daten auszuwerten. Für Logfiles gilt im Prinzip das Gleiche wie für die Daten. Da sollte man als Programmierer dafür sorgen, das die nicht zu groß werden. Ich habe deshalb bei meiner Software die Logfiles auf eine Maximalgröße von 2MB begrenzt. Wenn ein File diese Größe erreicht hat wurde der Name um das aktuelle Datum + Uhrzeit egänzt, dann weg gesichert und ein neues Logfile begonnen. Selbst dieses 2MB File ließ sich schon schlecht auswerten - einfach zu groß und unübersichtlich. Abgesehen davon würde ich ein Logfile auch nicht mit einem Editor öffnen, da gibt es in der GUI Viewer bzw. im Shellfenster cat, more und bei Bedarf grep. Und ja ich hatte auch schon größere Textdateien, aber 100MB sind mir in 30 Berufsjahren nie vor gekommen. Das Beispiel ist einfach nur an den Haaren herbei gezogen, um zu zeigen das der vi, vim etc. das Geilste ever ist. Um das eigentliche Thema geht es doch schon lang nicht mehr.
timol schrieb: > Aber ein Mod kann sich > hier ja aufführen wie ein A... Das tut der Jörg eigentlich nicht - auch wenn ich nicht generell seine Statements teile. Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare halt ab und an entsprechend aus. Man muß ja auch nicht alle Statements von Jörg kommentieren.
timol schrieb: > Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten > mit nachvollziehbaren Argumenten die Welt erklärt, hier haben. Argumente bringst du ja auch keine, nur Behauptungen. Warum erwartest du dann von anderen Argumente? Du behauptest, dass andere "sich quälen", du definierst, wer wo wem was vorschreibt und dass das dann halt so sei. Möglicherweise habe ich schon ein paar "Klitschen" (das scheint dein Begriff für alles das zu sein, was du nicht kennst) mehr gesehen – zwischen 5 und 50000+ Mitarbeitern war da vieles dabei. Zeno schrieb: > Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei > entsteht. Tja, und wenn andere die Datei für ihn in der Form erzeugen? Gehst du zu denen hin und erzählst ihnen, dass sie da was falsch machen? Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien herum editieren würde – aber wenn solche Dateien halt irgendwo entstehen und man auch mal drin editieren muss (oder sie zumindest ansehen, was drin suchen etc.), dann sollte es ein Tool geben, mit dem man das machen kann. Das muss ja auch nicht notwendigerweise das gleiche sein wie das, mit dem man seine täglichen Programmieraufgaben erledigt – es soll Leute geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das Gegenteil von "Fanboys".
Zeno schrieb: > Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß. Veto. Zum Beispiel traces eines beliebigen Bus-Systems sind wesentlich größer. Die werden zwar meist mit dedizierter SW geöffnet, trotzdem kam es schon vor dass ich mit Traces mit einem Editor ansehen musste. Aber es stimmt schon, von der Fähigkeit, beliebig große Dateien öffnen zu können würde ich jetzt nicht die Wahl meines Standard-Editors abhängig machen. Dafür kommt dieser usecase (bei mir) zu selten vor.
Zeno schrieb: > mh schrieb: >> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere >> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format >> enthält? > Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei > entsteht. Natürlich hast du den Rest meines Beitrags nicht zitiert ;-) Du bist also der Meinung, dass ich die XXk€ Software, die mein Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du, wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der Begründung "Nano und Zeno sagen, dass ich etwas falsch mache".
Mombert H. schrieb: > Du bist also der Meinung, dass ich die XXk€ Software, die mein > Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du, > wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der > Begründung "Nano und Zeno sagen, dass ich etwas falsch mache". Also wenn ich Dein Arbeitgeber wäre, würde ich sagen "na klar, wenn diese ausgewiesenen Experten das sagen, müssen wir das sofort machen! Lass uns nochmal XXk€ ausgeben damit die beiden uns eine neue Software bauen, die kann nur besser sein!"
Ein T. schrieb: > rbx schrieb: >> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, >> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so >> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. > > Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit > mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche > Gesellschaft. ;-) Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln könnten?
Yalu X. schrieb: > Jörg W. schrieb: >> Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten >> ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal >> (mindestens die unterschiedliche Modi muss man kennen). > > Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man > direkt im Insert-Mode, und es können die von Windows bekannten > Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S > (save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur > Verfügung. > > Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann > sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen. Das würde ich nicht sagen. Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über das Menü einstellbar. Mit Vim im Easy-Mode und den von Windows bekannten Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S (save) hat man noch lange keinen Zeilenumbruch das Kodierungsschema eingestellt. Sollte man hier den Vim im Eays-Mode mit leistungsfähigeren Editoren vergleichen, die ihre Einstellungen über Menüs erlauben, dann geht hier noch weniger. Der Easy-Mode ahmt also zwar bekannte Tastaturkürzel nach, aber er macht Vim dadurch noch lange nicht zu einem intuitiv benutzbaren Editor. Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren feststellen konnte, kein ESC :q! um vim zu verlassen. Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt. Das einzige was ging war ALT+F4, aber das nur, weil das die Tastenbelegung für KDE zum Schließen von Anwendungen ist und die Konsole daher nachfragte, ob sie mitsamt allem, was darin läuft, geschlossen werden soll.
Nano schrieb: > Auch ein STRG+Q oder ALT+Q oder STRG- Meinte STRG+C > brachte hier keinen Erfolgt. Kiffer schrieb:> > Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), > für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die > Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig > und/oder unwichtig erklärt. Ich habe oben geschrieben, dass ich keine großen in der Regel Binärdateien mit einem Texteditor bearbeite und dafür einen Hexeditor verwende. Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 MiB große Quellcode Datei in einer IDE öffnen will. Tipp: Es macht Sinn, solche großen Quellcodedateien in mehrere kleine aufzuteilen. Bei so einer großen Datenmenge kann man sogar überlegen, ob man nicht vielleicht auch gleich noch eine Bibliothek baut und die dann einbindet.
Nano schrieb: > Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über > das Menü einstellbar. Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben (die berühmte Konfig-Datei). Selbst im Emacs benutze ich die entsprechende Funktion sehr selten, obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als auch Menüs).
Nano schrieb: > Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 > MiB große Quellcode Datei in einer IDE öffnen will. Es ging allerdings nicht um Quellcode, sondern um irgendwelchen Krempel, der in Textform vorliegt (daher keinen Hex-Editor braucht) und den irgendein Programm außerhalb des Einflussbereichs desjenigen produziert, der dann die Daten trotzdem gelegentlich ansehen und anfassen muss. Warum, weshalb und wieso die Daten genau so entstehen, muss man nicht diskutieren, wenn man darauf eh keinen Einfluss hat. Sie sind dann einfach da. Dass hier keiner 100 MB großen Quellcode in eine einzige Datei stopft, bedarf wohl keiner großen Diskussion.
Nano schrieb: > Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 > MiB große Quellcode Datei in einer IDE öffnen will. > Tipp: > Es macht Sinn, solche großen Quellcodedateien in mehrere kleine > aufzuteilen. Ich schreibe alle relevanten Infos mit printf ins Log, da sind bei 1000 Messages / Sekunde * 50 Bytes 30 MB in 10 Minuten erreicht... Das ist dank SSD kein Performanceproblem. Glaub mir, das willst du dir mit keinem Hex Editor anschauen.
Zeno schrieb: > alex schrieb: >> Da bist du aber bei vi und Derivaten davon absolut falsch ;) > > Nö die Fanboys finden das Teil super und geilen sich seit hunderten von > Beiträgen daran auf. Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige mich sogar persönlich angreifen, wie man oben sehen konnte. Der Grund ist einfach: Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann ist das natürlich besonders übel für die Fanboys, wenn ich deren vim nicht nutze. Bei einem IT Laien wäre das nämlich nicht so wichtig oder irrelevant, denn ein Laie kennt sich nicht aus, daher haben dessen Aussagen kein Gewicht, da ich keiner bin, ist das in meinem Fall anders. Dafür werde ich angegriffen, das ist der Grund. @vim fanboys :p > Da müssen dann schon auch mal (Text-) Dateien mit > 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig > derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch > Datendateien mit einem Editor bearbeiten muß, der macht was falsch. ++ So sehe ich das auch. > Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen > auch vi, vim oder wie sie alle heißen mögen. Ganz deiner Meinung.
Nano schrieb: > warum die Fanboys Die wissen, dass du dich allein durch die bloße wiederholte Verwendung dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen abzustempeln ist ein Ausdruck fehlender Argumente.
mh schrieb: > Zeno schrieb: >> Da müssen dann schon auch mal (Text-) Dateien mit >> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig >> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch >> Datendateien mit einem Editor bearbeiten muß, der macht was falsch. > > Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere > 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format > enthält? Ich versuche es mal: Ihr habt oben etwas von Messdaten geschrieben. Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, dann sollte man über ein Binärformat und ein Programm, über das man auf diese zugreift und das diese aufbereitet, nachdenken. Grund: Ein Binärformat spart viel mehr Platz und ist für einen Computer viel besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm schreibt, gleich noch daran denken, die Daten noch zu komprimieren. Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf, dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier zu großen Verlusten führen. Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust mehr Sicherheit und das erlaubt dann auch die alten Dateien zu komprimieren und so Speicherplatz zu sparen. Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei anzulegen. > Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen > Dateien oder dem Editor meiner Wahl. Bis mal der Rechner eine Störung hat. > Mein Chef hat keine > Probleme mit diesen Dateien und dem Editor meiner Wahl. Dann weise ihn mal auf die Punkte hin, die ich gerade genannt habe und dann beobachte ob sich an seiner Einstellung etwas ändert. > Unsere Kunden > haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Gleicher Fall wie beim Chef. > Nur > du und nano haben Probleme damit. Wir haben ja auch Ahnung und würde das so deswegen auch nicht machen. Die Begründung warum wir das anders machen würde, habe ich hier gerade geschrieben. Es liegt jetzt an dir, daraus zu lernen und die Verbesserungen zu übernehmen und umzusetzen und dann brauchst du auch diese großen Dateien nicht mehr. > Und ihr wisst nichteinmal was das für > Dateien sind und was damit gemacht werden muss. Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im einfachsten Fall ASCII Text.
Nano schrieb: > Der Grund ist einfach: > Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also > weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann > ist das natürlich besonders übel für die Fanboys, wenn ich deren vim > nicht nutze. Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du dich aufregst, über was auch immer... dazu gehören aber mindestens 2.
Nano schrieb: > Ein Binärformat spart viel mehr Platz und ist für einen Computer viel > besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm > schreibt, gleich noch daran denken, die Daten noch zu komprimieren. Ist alles richtig, aber dann muss ich erst ein Programm schreiben, das mir die Daten in ASCII umwandelt. Bringt also nix ausser Arbeit. Wir leben auch nicht mehr in den 90'ern. Jedes Handy Spiel installiert heute 100 MB...
Le X. schrieb: > Kiffer schrieb: >> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), >> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die >> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig >> und/oder unwichtig erklärt. > > Nein, so war das nicht. > Nano hat eingangs klargestellt für was er welchen Editor verwendet und > warum. > Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der > vim zwar unbestreitbar besser performt, die für ihn aber nicht > relevant seien. So weit okay. > Das ändert freilich nichts daran dass er sich in den darauf folgenden > technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war, > überhaupt auf die Beispiele einzugehen. Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in MB gedacht habe.
Nano schrieb: > Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich > 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht > aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in > MB gedacht habe. Doch :-) Du machst den Fehler, auf die Argumente überhaupt einzugehen. Und solage du (oder ich) das machen, geht der Thread weiter. Macht aber auch nix, im Fernsehen spielts ja nix gescheites.
Jörg W. schrieb: > Le X. schrieb: >> Sein Fehler war, überhaupt auf die Beispiele einzugehen. > > Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler > bezeichnen. ;-) Ich habe diesen Thread nicht eröffnet. Der ist nicht von mir. Er wurde von dem Nutzer OpenBSD am 06.01.2020 16:38 erstellt. Ich habe auf die Frage des TS erstmals am 8.1.2020 geantwortet.
Nano schrieb: > Der Grund ist einfach: > Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also > weitaus mehr Gewicht zu Du solltest an Deiner Selbstwahrnehmung arbeiten. Niemand hier dürfte Dich für einen Profi halten. Eher für einen Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. Nachweise Deiner angeblichen Kompetenz willst Du ja leider nicht liefern: Beitrag "Vielzahl an IDE, Framworks, usw."
udok schrieb: > Nano schrieb: >> Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich >> 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht >> aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in >> MB gedacht habe. > > Doch :-) Du machst den Fehler, auf die Argumente überhaupt einzugehen. Okay, die Zeit hätte ich mir natürlich sparen können, so hast du natürlich recht. Aber einen technischen Fehler habe ich nicht gemacht, außer dem mit den 8 MB anstatt 8 GB. > Und solage du (oder ich) das machen, geht der Thread weiter. Macht aber > auch nix, im Fernsehen spielts ja nix gescheites. Das ist wahr.
Kiffer schrieb: > ...viel Unsinn... Erstens: Du hast dich im Thread verirrt. Zweitens: Deine Behauptungen und Anschuldigungen hier bezüglich dem anderen Thread sind nicht korrekt. Bist du vielleicht der Straftäter aus dem anderen Thread? Ein Mod könnte und sollte das mal überprüfen, das würde mich interessieren.
vim schrieb: > Nano schrieb: >> Der Grund ist einfach: >> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also >> weitaus mehr Gewicht zu > > Du solltest an Deiner Selbstwahrnehmung arbeiten. > > Niemand hier dürfte Dich für einen Profi halten. Eher für einen > Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen > zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne > Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten. Und was alle anderen außer ihm falsch machen. Und was er viel besser könnte wenn man ihn nur ließe. Er erklärt uns wie groß Dateien werden dürfen. Und das er noch nie Größere gebraucht oder gesehen hat. Er erklärt uns das Binärformate bei größeren Dateien besser sind. Wir alle sollten besser auf ihn hören! ;-)
Jörg W. schrieb: > Nano schrieb: >> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über >> das Menü einstellbar. > > Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben > (die berühmte Konfig-Datei). Nicht zwingend. Früher musste man unter Windows die Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien, die unter Unix mit einem LF Codierung für den Zeilenumbruch abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte. Und README Dateien lesen, das gehört meiner Meinung nach noch zu den administrativen Aufgaben. Heute in Windows 10 kann Notepad glücklicherweise mit diesen Zeilenendencodierungen umgehen, aber früher war das nicht so. Und beim Kodierungsschema ist es nicht viel anderes. Vieles kam aus DOS Zeiten mit z.B. Codetabelle 430, dann musste man das entsprechend umstellen können. > Selbst im Emacs benutze ich die entsprechende Funktion sehr selten, > obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als > auch Menüs). Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte, welcher Editor sich für mein DOS Projekt am besten eignet. Emacs hat beim ersten Start irgendwelche Daten aufbereitet und eine Ewigkeit dafür gebraucht. Danach haben die Starts auch sehr lange gedauert. Ich habe ihn daher gelöscht. Aber wenn du willst, dann kannst du dir das gerne mal unter FreeDOS ansehen. Die Emacs Version darauf ist schon ein paar Jahre alt.
Jörg W. schrieb: > Nano schrieb: >> warum die Fanboys > > Die wissen, dass du dich allein durch die bloße wiederholte Verwendung > dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen > abzustempeln ist ein Ausdruck fehlender Argumente. Oh, mir ging es da jetzt nicht um die normalen Vim Nutzern, sondern tatsächlich um die aggressive Gruppe unter den Vim Nutzern die hier ausrastet, wenn man vim nicht nutzt. Der Einfachheit halber übernehme ich hier lediglich die Begriffsbezeichnung, die Le X. anfangs einbrachte und nutzte, in dem Fall also "Fanboys". Siehe dazu: Beitrag "Re: Vi Editor ausgestorben?"
udok schrieb: > Nano schrieb: >> Der Grund ist einfach: >> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also >> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann >> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim >> nicht nutze. > > Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du > dich > aufregst, über was auch immer... dazu gehören aber mindestens 2. Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den anderen dann zu korrigieren. Du kennst ja sicher folgendes Comic: https://xkcd.com/386/ Ich kann stundenlang diskutieren.
vim schrieb: > Nano schrieb: >> Der Grund ist einfach: >> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also >> weitaus mehr Gewicht zu > > Du solltest an Deiner Selbstwahrnehmung arbeiten. > > Niemand hier dürfte Dich für einen Profi halten. Eher für einen > Informatik-Erstsemester, ... Als vim Fanboy hast du jetzt natürlich keine andere Möglichkeit mich wieder persönlich anzugreifen, anstatt in der Sache, nachdem ich Personen wie dich durchschaut habe. > Deine Beitragsbewertungen sprechen für sich, -13 ohne > Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. Beitragsbewertungen kann man als Gast nicht einsehen, also existieren sie nicht. Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI zu verstehen.
Norbert schrieb: > Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten. > Und was alle anderen außer ihm falsch machen. > Und was er viel besser könnte wenn man ihn nur ließe. > Er erklärt uns wie groß Dateien werden dürfen. > Und das er noch nie Größere gebraucht oder gesehen hat. > Er erklärt uns das Binärformate bei größeren Dateien besser sind. > > Wir alle sollten besser auf ihn hören! ;-) Oben habe ich in meinem Beitrag Beitrag "Re: Vi Editor ausgestorben?" ja ausführlich und argumentativ begründet, warum man für Messdaten keine einzige große Datei nutzen sollte. Es steht dir jetzt frei, diese ganzen von mir genannten Argumente hiermit zu widerlegen, aber warum nutzt du diese Chance nicht und greifst mich stattdessen wieder persönlich an, O Ton: > Aber dafür erklärt er uns doch so schön die Welt... anstatt einfach mal in der Sache mich argumentativ zu widerlegen? Überlege mal! Letzten Endes könntest du jetzt auch einfach zugeben, dass du die genannten Argumente nicht widerlegen kannst.
Nano schrieb: > vim schrieb: >> Deine Beitragsbewertungen sprechen für sich, -13 ohne >> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. > > Beitragsbewertungen kann man als Gast nicht einsehen, also existieren > sie nicht. > Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen > sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an > dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI > zu verstehen. Ups, da fehlte ein Wort. Ich meinte natürlich "nicht zu verstehen".
Nano schrieb: > Oben habe ich in meinem Beitrag > Beitrag "Re: Vi Editor ausgestorben?" > > ja ausführlich und argumentativ begründet, warum man für Messdaten keine > einzige große Datei nutzen sollte. > > Es steht dir jetzt frei, diese ganzen von mir genannten Argumente > hiermit zu widerlegen Diese Hybris ist unbeschreiblich! Du meinst tatsächlich anderen erklären zu müssen, was richtig und was falsch ist? Wer glaubst du eigentlich wer du bist? Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes vorzustellen: Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB. Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht beugen wollen. Diese Anlagen bestehen darauf Daten im Textformat auszuspucken. Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert tadellos. Also nimm dich mal ein wenig zurück und rede (und vor allem urteile) nicht über Dinge die in deiner Welt nicht vorkommen.
Nano schrieb: >> Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann >> sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen. > > Das würde ich nicht sagen. Du nicht, ich schon. > Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über > das Menü einstellbar. Ich habe nicht behauptet, dass EasyVim ein 1:1-Notepad-Klon ist, aber die wesentlichen Funktionen, insbesondere die, die man zum Editieren der berühmten Config-Files braucht, sind gleich oder zumindest leicht in den Menüs auffindbar. Wer deutlich mehr braucht, nutzt nicht den Easy-Mode und erst recht nicht Notepad. Was meinst du mit dem einstellbaren Zeilenumbruch? Die Aktivierung und Deaktivierung des automatischen Zeilenumbruchs? Oder die maximale Zeilenlänge als Parameter für den automatischen Zeilenlänge? Beides lässt sich über das Menü einstellen. Was meinst du mit Kodierungsschema? Die Zeichenkodierung? Defaultmäßig wird diese von der zu editierenden Datei oder – wie beim Nano – vom der Einstellung des aufrufenden Prozesses bzw. des Betriebssystems übernommen. Kein Anfänger möchte diese Einstellung ändern. Falls er fortgeschritten genug ist, um dennoch solche exotischen Funktionen zu brauchen, wird es ihm nicht schwer fallen (auf jeden Fall leichter als beim Nano ;-)), den entsprechenden Befehl nachzuschlagen. > Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren > feststellen konnte, kein ESC :q! um vim zu verlassen. Das soll es auch nicht, denn das wäre ja für den Anfänger nicht easy :) > Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt. Strg+Q sollte gehen und geht bei mir auch. Wenn es bei dir nicht geht, hast du wieder so eine verkrüppelte Vim-Version installiert, oder dein Window-Manager nutzt diese Tastenkombination für eigene Zwecke. Dann bleibt aber immer noch das Menü (File/Exit bzw. Alt+FX) oder eben > ALT+F4 Nano, mittlerweile weiß doch jeder, der diesen Thread liest, dass du kein Freund von Vim bist, und jeder (einschließlich mir) akzeptiert dies, auch ohne dass du ständig neue und immer fadenscheinigere Gründe gegen Vim an den Haaren herbeiziehst.
Norbert schrieb: > Nano schrieb: >> Oben habe ich in meinem Beitrag >> Beitrag "Re: Vi Editor ausgestorben?" >> >> ja ausführlich und argumentativ begründet, warum man für Messdaten keine >> einzige große Datei nutzen sollte. >> >> Es steht dir jetzt frei, diese ganzen von mir genannten Argumente >> hiermit zu widerlegen > > Diese Hybris ist unbeschreiblich! > Du meinst tatsächlich anderen erklären zu müssen, was richtig und was > falsch ist? Wer glaubst du eigentlich wer du bist? Und wieder wiederholst du deinen Angriff auf die Person, anstatt in der Sache meine Argumente zu widerlegen. Lies und lerne: https://de.wikipedia.org/wiki/Argumentum_ad_hominem > Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes > vorzustellen: > Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB. > Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht > beugen wollen. > Diese Anlagen bestehen darauf Daten im Textformat auszuspucken. > Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert > tadellos. Das widerlegt meine Argumente nicht, es zeigt nur, dass diese Geräte von den gleichen Typen programmiert wurde, die alle Messdaten in eine einzige große Datei zu schreiben. Übrigens gibt es das split Kommando, das solltest du dir mal ansehen.
Nano schrieb: > Ihr habt oben etwas von Messdaten geschrieben. > > Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, > dann sollte man über ein Binärformat und ein Programm, über das man auf > diese zugreift und das diese aufbereitet, nachdenken. Du meinst z.B. so wie es systemd tut? Der schreibt seine Logdaten als Binärklumpen raus, so dass man sie nicht mehr einfach mit einem normalen Texteditor öffnen kann. Ansonsten: Was bringt es mir, über ein Binärformat nachzudenken? Wenn ich ein Programm habe, das die Daten als Text ausgibt, dann ist das eben so. Nicht jeder hat die komplette Software, die er benutzt, selbst geschrieben oder die Möglichkeit, diese mal kurz umzuprogrammieren, um ein völlig anderes Format auszugeben. > Grund: > Ein Binärformat spart viel mehr Platz und ist für einen Computer viel > besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm > schreibt, gleich noch daran denken, die Daten noch zu komprimieren. Allerdings muss man dann eben auch das Anzeigeprogramm schreiben. Bei Text nehme ich einfach den bereits vorhandenen Texteditor. > Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei > anzulegen. Sag das mal dem AUTOSAR-Konsortium. Da können auch mal XML-Dateien entstehen, die 2GB groß sind. Das kann ich als Anwender nicht ändern, sondern nur hinnehmen und muss halt irgendwie damit klar kommen.
Nano schrieb: > Ein T. schrieb: >> rbx schrieb: >>> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, >>> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so >>> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. >> >> Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit >> mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche >> Gesellschaft. ;-) > > Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln > könnten? Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und Berührungen geht. ;-)
Nano schrieb: > Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann > aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige > mich sogar persönlich angreifen, wie man oben sehen konnte. > > Der Grund ist einfach: > Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also > weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann > ist das natürlich besonders übel für die Fanboys, wenn ich deren vim > nicht nutze. Bwahahahaha! TY, YMMD... again! ;-)
Nano schrieb: > Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin > da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den > anderen dann zu korrigieren. Davon merke zumindest ich leider wenig. > Ich kann stundenlang diskutieren. Das hingegen ist mir schon aufgefallen. Erstaunlich, nicht wahr?
Nano schrieb: >> Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben >> (die berühmte Konfig-Datei). > > Nicht zwingend. Früher musste man unter Windows die > Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien, > die unter Unix mit einem LF Codierung für den Zeilenumbruch > abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte. Dafür habe ich nie Notepad genommen, sondern Wordpad. Das konnte das sofort. Da man darin aber nichts editieren muss, interessiert mich nicht, wie man da was umstellen würde. > Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 > ausprobiert Das ist ja auch Quatsch, das überhaupt zu versuchen. Du kannst vielleicht einen alten GNU Emacs auf einer PDP-11 benutzen, aber einen aktuellen Emacs auf so einem kastrierten System zu nehmen, das kann nicht gut gehen. Ein aktueller Emacs startet (im GUI-Modus) auf vergleichbarer Hardware unter Unixen zumindest schneller als ein Notepad++ unter Windows.
Jörg W. schrieb: > Ein T. schrieb: >> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr. > > Sie kann mehr, macht aber alles anders, und vor allem kann sie > Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich > schmerzlich feststellen. Von einem User im Python-Forum.de werden das "Windows Terminal" [1] und der "Cmder" [2] empfohlen, vielleicht könnte eines dieser Programme etwas für Dich sein. HF! [1] https://apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701?hl=de-de&gl=DE [2] https://cmder.net/
Nano schrieb: > Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören > und keinen anständigen Diskurs mit Anstand und Niveau führen könenn. hihi... ja die erkennt man echt gut ;)
Le X. schrieb: > Es ist schon interessant wie fanatisch man sein Tool lieben kann. > Überkochende Emotionen sind ein Garant für gute Unterhaltung. Oh ja... bin schon an der zweiten Portion Popcorn...
Nano schrieb: > Meinte STRG+C Das ist das klassische Argument. Das ist dann eher so, wie wenn der Rechner beim Skyrimspiel hängt bzw. das Bild "einfriert". Konsole geht nicht. Alt-F4 auch nicht usw. Aber irgendwas geht. Oft muss man den Rechner nicht neustarten. Bei Windows geht bei solchen Sachen erfahrungsgemäß Strg+Alt+Entf gut. Das kann man auch ab und zu in Linux benutzen. Aber prinzipiell nicht mehr sinnvoll, wenn der Bildschirm einfriert. Im Unterschied zu den Spielstörungen gibt es bei Vi und Vim die ein oder andere Einführungshilfe. Die sollte man mitnehmen/Dabeihaben. Aber auch dann ist das nicht mehr rauskommen blöd und kann vorkommen - vermutlich deswegen, weil es meist nicht in Großbuchstaben im Hilfetest steht. Nano schrieb: > enn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über > das Menü einstellbar. Notepad++ kann das. Open Office, also Libre Office aber auch. Auf jedenfall muss man das öfter machen, wenn man Texte vom Normalen Desktop nach Cygwin überträgt. Nano schrieb: > Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 > ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte, > welcher Editor sich für mein DOS Projekt am besten eignet. Da kannst du den Watcom Vi benutzen :) Und außerdem die 32Bit Debug-Version von Paul Vojta. Ein T. schrieb: > Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und > ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich > andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und > Berührungen geht. ;-) Mir ging es nur darum, den Unterschied zwischen der "Geistform" und der normalen körperlichen Anwesenheit verständlich zu machen. Das scheint mir ja gut gelungen zu sein, und das reicht mir auch. https://www.youtube.com/watch?v=ppmEc56nSFk
Zeno schrieb: > timol schrieb: >> Aber ein Mod kann sich >> hier ja aufführen wie ein A... > Das tut der Jörg eigentlich nicht Aber sicher tut er das - und zwar nicht nur in diesem Thread. > Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare > halt ab und an entsprechend aus. Die Benutzung von Unix rechtfertigt noch lange nicht ein solches Verhalten. Und es betrifft ja auch viele andere Themen. > Man muß ja auch nicht alle Statements > von Jörg kommentieren. Klar, man muss gar nichts. Gilt für andere aber auch.
timol schrieb: > Zeno schrieb: >> timol schrieb: >>> Aber ein Mod kann sich >>> hier ja aufführen wie ein A... >> Das tut der Jörg eigentlich nicht > > Aber sicher tut er das - und zwar nicht nur in diesem Thread. Hm, die Vi Benutzung mit gewissen Formen des Unternehmertums in einen Topf, bzw. eine Schublade zu werfen, ist aber schon spannend. https://de.wikipedia.org/wiki/Generalisierungsgradient
Jörg W. schrieb: > Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien > herum editieren würde Das liest sich aber in seinem Beitrag anders. mh schrieb: > Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen > Dateien ... Ich lese das so, das er öfter mit solchen Dateien zu tun hat. Am Ende ist es mir arber auch Rille. Ich habe mich die letzten 25 Jahren mit Auswertung von Messdaten beschäftigt, sowohl von der SW-Seite (Entwickler) her und auch als Anwender, also selbst Messdaten erzeugt. Derartig große Textdateien, die ich dann noch mit einem Editort bearbeiten müßte, sind mir da nicht untergekommen. Lediglich beim CT gab es eine Datendatei mit ca. 2GB. Da waren aber nur die ersten 2kB reiner Text der Rest war binär. Jörg W. schrieb: > es soll Leute > geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das > Gegenteil von "Fanboys". Schrieb ich ja z.B cat, more, grep und Konsorten. Mombert H. schrieb: > Natürlich hast du den Rest meines Beitrags nicht zitiert ;-) Warum sollte ich das das tun, wenn ich nur Deine Frage beantworte?
Nano schrieb: > Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im > einfachsten Fall ASCII Text. Naja heute ist ja XML die Wunderwaffe. Das hat zwar durchaus seine Berechtigung und die Daten sind sehr gut lesbar, aber es bläht die Datei eben auch deutlich auf. Die Datendateien meines Programmes waren für eine Messung zwischen 7 und 10kB groß, macht für eine vollständige Messreihe mit 7 Messungen 70-100kB. Der Typ der meine Software neu programmieren sollte hat da auf XML gesetzt, woraufhin sich das Datenaufkommen verzehnfacht hat. Gut spielt nunmehr keine Rolle mehr da man die Neuentwicklung nach 6 Jahren eingestellt hat und mit meinem Programm weiter arbeitet. Noch sparsamer im Platzverbrauch war mein Vorgängerprogramm, das hat für einen kompletten Datensatz weniger als 10kB gebraucht. Nachteil war natürlich, das man sich die Daten nur mit dem Programm selbst anschauen konnte, da sie im Binärformat gespeichert waren. Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht. Zum Beispiel bei meiner Wetterstation werden alle 300s die Daten gespeichert (pro Datensatz 52 Werte) und die werden selbstverständlich nicht als Text sondern in einer Datenbank gespeichert. Derzeit sind sind ca. 7100 Datensätze gespeichert bei einer Datenbankgröße von 1,5MB. Und ja man kann sich das mit den passenden Tools, tabellarisch aufbereitet ansehen, allerdings ist das eher ein mühsames Geschäft. Ich stelle mir gerade vor das als ne Textdatei gespeichert und dann mit dem vi angeschaut, dannach wäre man dann reif für die Klappse.
udok schrieb: > Wir leben auch nicht mehr in den 90'ern. Stimmt, Du lebst sogar noch in den 1970'zigern, da wurde der vi erfunden, also zu einer Zeit wo Speicherplatz noch knapp war und das Datenaufkommen in Byte oder kB gemessen wurde.
Beitrag #7124925 wurde von einem Moderator gelöscht.
Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt, dass es eine ältere Version war.
Aber sicher keine von 1990. :)
Alles danach wurde doch nur noch auf VM-Systemen benutzt.
MS-DOS mit gerade mal 64 KiB linear adressierbarem Adressbereich ist nun
so ziemlich das letzte, was man irgendwie als Referenz benutzen würde.
Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt,
Du sagst ziemlich viel, wenn der Tag lang... okay, vergiß das mit dem
Tag. ;-)
Zeno schrieb: > Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit > einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht. Das könnte auch gzipped CSV, JSON oder YAML sein. Dafür gäbe es schon fertige Frontends, Libraries und Tools. Gerade bei großen Datenmengen ist es aufwändig und daher meistens ziemlich dumm, das Rad neu erfinden zu wollen. Meine Güte!
Kiffer schrieb: > Meine Güte! Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie sie sich ihre Arbeit organisieren.
Kiffer schrieb: > Das könnte auch gzipped CSV, JSON oder YAML sein. Klar groß, größer, am größten - für sehr große Datenmengen sind Textdateien ungeeignet. JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt. Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung, und da sind die Datenmengen eher überschaubar.
Zeno schrieb: > Klar groß, größer, am größten - für sehr große Datenmengen sind > Textdateien ungeeignet. > JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man > sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt. > Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung, > und da sind die Datenmengen eher überschaubar. Sieh an, Pippi Langstrumpf erklärt uns die Welt. Selbstverständlich ist JSON für die Speicherung von grossen Datenmengen geeignet und wird dafür benutzt. Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel mit den Werten kostet kaum Overhead und kann prima als Stream verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und getestete, stabile und performante Tools und Libraries dafür, die man nutzen oder drauf aufbauen kann. Solche Eigenschaften müsstest Du mit Deinem unprofessionellen Gebastel erstmal hinbekommen, kleiner Held.
Jörg W. schrieb: > Kiffer schrieb: >> Meine Güte! > > Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie > sie sich ihre Arbeit organisieren. Hab' ich das? Nö. Die einzigen, die hier anderen etwas vorschreiben wollen, sind Na-no und Ze-no. Hast Du da vielleicht etwas verwechselt?
Kiffer schrieb: > Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header > mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel > mit den Werten kostet kaum Overhead und kann prima als Stream > verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und > getestete, stabile und performante Tools und Libraries dafür, die man > nutzen oder drauf aufbauen kann. Das ist ja alles nicht durchaus richtig, aber kannst Du nicht bitte einfach mal auf die Provokationen verzichten? In diesem Thread ist schon genug provoziert worden, simple Besserwisserei sollte fürderhin reichen.
Beitrag #7125414 wurde von einem Moderator gelöscht.
Nano schrieb im Beitrag #7125414: > Lass mich raten, du gehörst zu denen, die sich aus ganz vielen Ecken > dutzende Bibliotheken für die kleinste Funktion ins Projekt einbinden, > weil du das alles nicht selber programmieren kannst und dann prahlst du > hier auch noch damit herum es besonders ineffektiv zu machen. Peinlich! Erwartbar falsch geraten. Mit ein bisschen Erfahrung lernt man, sinnvolle Entscheidungen zu treffen, wann man etwas selbst entwickeln, testen und pflegen sollte, und wann das zu etwas führt, das erfahrene Entwickler als NIH-Problem kennen. Nur Anfänger glauben, alles besser zu können als der Rest der Welt. Weißt Du, Hybris gehört zwar nach Larry Wall, dem Erfinder der Sprache Perl, zu den Kardinaltugenden guter Entwickler. Faulheit aber auch! > Und JSON IST ineffizient für große Datenmenge, da ist sogar CSV um > Welten besser! > JSON ist für kleine Datenmengen gedacht, in erster Linie dafür, wo man > normalerweise XML einsetzen würde. Wo steht das? Wer sagt das? Du? > JSON ist effizienter als XML, aber > bei mehren hundert MB ist es immer noch höchst ineffizient. [ ] Du hast den Teil mit der Komprimierung verstanden. [ ] Du hast den Teil mit dem Datenformat verstanden. > Also arbeite mal an deinem Umgangston, Na das sagt der Richtige.
Endlich! vim 9 ist in Debian sid angekommen. Jetzt steht der weiteren Verwendung nichts mehr im Wege, die Nutzerbasis wird sich erhöhen. Andere Distributionen werden nachziehen. Die Bugbereinigung wird anlaufen. Der tolle Editor lebt weiter. Aber der Resourcenverbrauch hat ja vom einstigen Editor für Minimalisten ordentlich zugelegt. Wer eine schlankere Version bevorzugt, kann es mit vim-tiny versuchen.
Max Mustermann schrieb: > Endlich! > vim 9 ist in Debian sid angekommen. Am Mittwoch letzter Woche bereits – du bist zu langsam. Und am Samstag wurde die Version in Testing aufgenommen – dessen Userbasis ist ja doch ungleich größer, als die von Unstable.
Max Mustermann schrieb: > Endlich! > vim 9 ist in Debian sid angekommen. > ... > Andere Distributionen werden nachziehen. Der Nachzügler ist – nach über 5 Wochen – wohl eher Debian selber. Zum Vergleich: Arch hat dafür 5,7 Stunden gebraucht :)
42 schrieb: > Arch ist bei Aktualisierungen immer top. Nein, nicht immer. Siehe beispielsweise Cura – das ist nun schon drei Monate veraltet.
Siggi schrieb: > Wann wird wohl Ubuntu und Linux-Mint nachziehen? Die neuste Version von vim ist für Mainstream-Distries einfach unwichtig. Standardmäßig haben die ohnehin nur vim-tiny. So als Backup-Lösung wenn die GUI nicht funktioniert und man deshalb keinen richtigen Editor verwenden kann.
Nico schrieb: > und man deshalb keinen > richtigen Editor verwenden kann. Was ist ein richtiger Editor?
Roman schrieb: > Was ist ein richtiger Editor? Kate, Bluefish, VScode, Ultraedit, notepad++(Windows) Minimalistisch für console: nano, pico, joe
Nano schrieb: > Oben habe ich in meinem Beitrag > Beitrag "Re: Vi Editor ausgestorben?" > > ja ausführlich und argumentativ begründet, warum man für Messdaten keine > einzige große Datei nutzen sollte. Du schreibst in dem verlinkten Beitrag: Nano schrieb: > Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, > dann sollte man über ein Binärformat und ein Programm, über das man auf > diese zugreift und das diese aufbereitet, nachdenken. > Grund: > Ein Binärformat spart viel mehr Platz und ist für einen Computer viel > besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm > schreibt, gleich noch daran denken, die Daten noch zu komprimieren. In dieser Argumentation fehlen mir einige praktische und ökonomische Perspektiven. Ja, Textdat(ei)en sind vielleicht um einen Faktor zwei bis fünf größer, dafür aber sofort und ohne weiten Investitionsaufwand für die Softwareentwicklung von jedem Menschen lesbar. Es gibt eine riesige Vielfalt fertiger, leisungsfähiger und sehr feingranular konfigurier- und steuerbarer Programme, um Textdat(ei)en anzeigen und verarbeiten zu können, denk nur mal an grep(1), sed(1), awk(1), oder an perl(1), oder auch gnuplot(1) oder die Programme aus dem graphviz-Paket. Oder an Pandas in Verbindung mit Matplotlib, Seaborn, Plotly oder Bokeh, um nur ein paar Beispiele aufzuführen. Obendrein sind Textdat(ei)en flexibler als Binärdat(ei)en, das heißt: in einer Textdatei kann ich ohne Weiteres verschiedene Logformate speichern und anschauen (denk nur mal an die Systemlogs unter Linux und UNIX), während das bei binären Dateien zwar machbar, aber mit wesentlich mehr Aufwand verbunden ist -- welcher obendrein bei jeder Änderung erneut anfällt. Wenn der, der die Daten verarbeiten soll, dann vielleicht nicht identisch mit dem Softwareentwickler ist, werden Deine Binärdat(ei)en sehr schnell zu einem bösartigen ökonomischen Problem. Meinen Rechner riesige Textdat(ei)en durchsuchen, verarbeiten, anzeigen zu lassen, kostet mich wenig. Einen Softwareentwickler an die Entwicklung eines Binärformates und dann bei jeder Änderung wieder daran zu setzen, kostet mich hingegen erstens Zeit und zweitens Geld. Und wenn mal ein Sensor spinnt und kaputte Daten in eine Binärdatei schreibt, ist womöglich die ganze Datei mit allen Daten verloren, wenn ich nicht schon wieder viel Geld ausgeben und einen Entwickler daran setzen will. Nano schrieb: > Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf, > dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier > zu großen Verlusten führen. Dieses Argument zieht nur, wenn die Daten auch dann nützlich sind, wenn sie nur in Teilen vorliegen. Bei vielen Messungen haben die Daten aber nur dann einen Wert, wenn sie über die gesamte Messung hinweg durchgängig vorliegen. Das heißt: wenn die Aufzeichnung wegen eines Ausfalls mitten während der Erhebung der Daten endet, ist der gesamte Test inklusive aller erhobenen Daten nutz- und wertlos. > Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei > schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust > mehr Sicherheit und das erlaubt dann auch die alten Dateien zu > komprimieren und so Speicherplatz zu sparen. Textdat(ei)en kann man auch komprimieren, wußtest Du das schon? Meistens sogar mit ziemlich guten Kompressionsraten... Mein grundsätzliches Herangehen an solche Datenmengen ist allerdings ohnehin ein gänzlich anderes: egal, wie ich die Dat(ei)en bekomme, pumpe ich sie sofort in meinen Opensearch-Cluster. Nicht, weil der die Daten dann binär speichert, sondern weil der extrem performant und obendrein hochverfügbar ist, meine Daten direkt und trotzdem strukturell flexibel in revertierten Indizes speichert, die sich wiederum unfaßbar schnell durchsuchen, wunderbar mit Opensearch-Dash visualisieren, oder mit allen möglichen Programmier- und Skriptsprachen weiterverarbyten lassen. Deswegen kann ich bei Eurem Gespräch über Speicherformate von Massendaten nur bedauernd mit dem Kopf schütteln -- und dabei vor allem darüber, daß Du die inhärenten Vorzüge von Textdat(ei)en entweder nicht (an)erkennen willst oder nicht kennst. Dateien, Jungs, echt mal... das ist doch total Neunziger. ;-) Zuletzt sei eine Kleinigkeit angemerkt, die Du anscheinend ebenfalls aus Deinen Augen verloren hast. Nämlich, daß man als Profi oft gar keine andere Wahl hat, als Daten so zu verarbeiten, wie man sie bekommt.
Ein T. schrieb: > egal, wie ich die Dat(ei)en bekomme, pumpe > ich sie sofort in meinen Opensearch-Cluster. Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht, dass Data-Mining generell uninteressant ist. Geht aber auch etwas besser mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich Kunstprodukte ein. Das passiert zwar auch bei wichtigen Gutachten - naja, sehr viele Leute sind nicht gut in Statistik (trotz der entsprechenden guten Ausbildung), und ich eigentlich auch nicht, wenn ich mir keine Mühe gebe - ist trotzdem nicht schön, und so wohl eher ein Grund zum schmunzeln trotz des düsteren Hintergrundes.
rbx schrieb: > Ein T. schrieb: >> egal, wie ich die Dat(ei)en bekomme, pumpe >> ich sie sofort in meinen Opensearch-Cluster. > > Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht, > dass Data-Mining generell uninteressant ist. Verrätst Du mir, wie Du an dieser Stelle auf "Data Mining" kommst? War es das Stichwort "Cluster", das Dich getriggert hat, oder wie kam das zustande? Im Kern geht es erst einmal darum, die Daten möglichst schnell und möglichst unaufwändig mir und den Kollegen zugänglich zu machen, damit wir mit den Daten arbeiten können. Dafür werden wir nämlich bezahlt. Vielleicht magst Du Dir die Software mal näher anschauen, um zu verstehen, was sie leistet und was nicht. > Geht aber auch etwas besser > mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich > Kunstprodukte ein. Schon der erste Schritt, nämlich die explorative Datenanalyse (EDA), kann ohne fundierte Kenntnisse der Statistik nicht funktionieren, und für jede Tätigkeit im Bereich des Data Mining gilt dasselbe. Ich bin daher äußerst irrigiert, wie man da irgendwelche Widersprüche ausmachen kann. Kann es sein, daß Du Dich mit Data Mining nicht wirklich auskennst und daher einigen (durchaus populären) Mißverständnissen aufgesessen bist? Oder, anders gefragt: was glaubst Du eigentlich, was wir im Data Mining so machen, wie das funktioniert und, vor allem, wie das ohne fundierteste Kenntnisse in Statistik gehen könnte?
Was hat eure Datenpornografie jetzt mit dem Thema zu tun? Hauptsache irgendwelche vagen Andeutungen machen, damit keiner weiß worum es geht und man dann anderen Ahnungslosigkeit vorwerfen kann? Oder warum antwortet man überhaupt darauf, wenn gar nicht klar ist, worum es geht? Ein Troll gegen den anderen Troll.
prust schrieb: > Was hat eure Datenpornografie jetzt mit dem Thema zu tun? Nach 'nem Monat Pause hat sich wieder jemand an einer (längst widerlegten) Aussage betreffend der Verwendung von großen Textfiles hochgezogen,
Bitte 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.