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/hEin 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
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
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.
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-Orä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.
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.
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!
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.
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.
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.
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:> 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.
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 :)
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.
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,
