Login
Login-Name Passwort


 
Newsletter
0
Von asdfszhjddd am Do, 25. Mai 2017 um 17:58

Mein Kommentar war jetzt nicht direkt gegen vi, sondern gegen viele solcher Tools. Linux ist im Moment noch zu konsolenlastig. Heute hast du viel mehr Dinge die du erledigen musst, dann noch für jedes Tool das Manual lesen, die Shortcuts lernen, oder far eine Scriptsprache die sonst nirgendwo Relevanz hat... ist einfach ein Unding. Wenn man ein Neckbeard ist und sonst nichts zu tun hat ist es kein Problem auch die Bugs selbst zu flicken, normale Nutzer zahlen da lieber Geld für eine ordentliche und bugfreie GUI.

Naja, Debian ist zumindest in den letzten Jahren in GUIs deutlich besser geworden. Hoffe es geht so weiter.

0
Von blablabla233 am Do, 25. Mai 2017 um 17:14

Es sagt einfach nichts aus...immer noch nicht.
Windows hat 10000 Bugs, ist das ein Grund keine neuen zu finden? Die Aussage ist etwa so sinnvoll wie:
Jaja wir haben ein Treibhaus Problem, wen interessiert da Plastik im Ocean, verstanden?...na kapiert?

Zudem...den LO-Entwicklern Besoffenheit zu attestieren hat mehr mit Beissreflex zutun, nicht?

Aber Ihr grossen Macher motzt, bekommt aber nicht einmal eine richtige Bug-meldung hin, wisst nicht für was ein Fuzzer ist obwohl der Artikel ziemlich gut darauf hinweist.

PS: Leider für Linux muss alles gratis und besser sein...auch leider für Linux gib es Großkotze die niemals etwas zu einem Projekt beitragen, na? Erkennst Dich wieder?

0
Von asdfsadffdsaf am Do, 25. Mai 2017 um 17:07

Software Fail auf keinen Fall, sonst wäre er nicht so vielen Jahren nicht noch immer präsent.

Unintuitiv mag er sein. Aber wenn man seine Herkunft bedenkt ist das auch nicht verwunderlich. VI kommt aus einer Zeit in der die gansamte Arbeit in einem Terminal erledigt wurde. Damals konnte man für komplexere Dinge nicht einfach auf ein intuitives GUI Tool ausweichen. Ein passender Vergleich für heute wäre IDE vs simplen Text Editor. Du kannst so ziehmlich alles auch mit einem simplen Text-Editor machen, aber wenn du deine IDE beherrschst bis du einfach bei vielen Aufgaben deutlich schneller sicherer und effizienter. Bei der IDE musst dich auch erstmals in die Funktionalität einlesen und Shortcuts lernen, damit du diese effizent bedienen kannst und auch von dem "Schwergewicht" profitierst.
Das erklärt warum sich damals VI und Co auch so populär wurden.

Heute werden meist nur noch Verhältnis wenig - einfach Dinge - im Terminal erledigt, da reicht ein nano sicher auch aus. Andererseit, wenn man VI mal beherrscht, ist man damit sicher nicht langsamer als mit nano, und kann im Zweifelsfall auch mal was komplexeres machen. Darum ist es auch nicht verwunderlich dass er auch heute noch nicht tot zu bekomen ist. Für einen Vollzeit Admin lohnt es sich auch heute noch die Zeit zu investieren VI zu lernen.

0
Von Andre am Do, 25. Mai 2017 um 16:47

Vim gehört sicher zu den wenigen Grundwerkzeugen in die sich jeder GNU/Linux/Unix User rudimentär einarbeiten sollten.
Vielmehr als eine Handvoll Befehle brauchte ich bei der Server-Administration normal auch nicht...

i
ESC
:w
:q
yy
dd
p

Wenns daran schon scheitert sollte man vielleicht besser einen Bogen um Unixartige Systeme machen :-]

0
Von Markus B. am Do, 25. Mai 2017 um 16:36

Verwende statt dessen :x oder noch besser ZZ, und du musst statt vier nur mehr zwei Zeichen eingeben, da auch kein Enter nötig ist.

Bonus: die Datei wird nur geschrieben, wenn was verändert wurde, somit bleibt der Timestamp erhalten, wenn man nur kurz reingeschaut hat.

0
Von asdfszhjddd am Do, 25. Mai 2017 um 15:57

Referenzen sind intern durch Pointer gelöst. Daher kannst du alles auch als Referenz implementieren. Damit erübrigt sich einiges. Bringe dein Wissen mal auf den neuesten Stand. Geschickte Programmierung heisst sich nicht darauf verlassen, dass der Nutzer die ganze Sprache kennt, sondern Fehlerpotential eingrenzen.

0
Von user am Do, 25. Mai 2017 um 15:15

solange man die pointer richtig und nützlich anwendet!
Für Einsteiger, und von kleinen Anwendungen (Cel2Fahr) benötigt mein kleine pointer.

0
Von gol. am Do, 25. Mai 2017 um 14:56

C ohne Pointer, soviel zu Leuten Unsinn beibringen.

0
Von LH_ am Do, 25. Mai 2017 um 14:42

"Und wenn man sich an die Bearbeitung der crontab macht, ist man normalerweise schon so
weit in seinem Wissen, dass man sich seinen Standardeditor und -lister eingestellt hat."

Nicht wirklich. Speziell viele Tutorials zeigen solche Schritte, erklären aber vi/vim nicht.

Fakt ist: Der Artikel beweist, dass die Leute damit Problem haben. Und das auch nicht erst seit gestern. Kenne auch niemanden, der nicht beim ersten Kontakt mit VI mit genau diesem Problem zu kämpfen hatte.
Warum lange diskutieren? Würde der Editor endlich wenigstens in den 90ern (!) ankommen, gäbe es das Problem nicht. Eine einfache Standardleiste, die einem die wesentliche Befehle zeigt und gut wäre es. Kriegen alle anderen doch auch hin ;)

0
Von Manjarone am Do, 25. Mai 2017 um 14:41

Ich denke mal er meint auch Compositoren. WindowManager hat sich eben bei vielen Leuten noch gehalten, wo eigentlich Compositoren gemeint sind.

Dann stimmt das nämlich auch wieder (:

0
Von Einfacher Entwickler am Do, 25. Mai 2017 um 14:34

Ja, von Kisten, auf denen kein vernünfitger Editor (remote) läuft, lasse ich gerne die Finger.
Sofern ich nicht von der schnellen Lösung durch den Admin abhängig bin, ist es immer wieder belustigend zu sehen, wie die meisten "vi ist der einzig echte Editor"-Gurus zehn mal so lange brauchen und sich die Finger verknoten, als die dummen Nichtskönner, die was anderes verwenden.
"Aber guck mal, vi kann auch ... und ... und hier noch der Mega-Trick..." - "Ja, super. Kannst Du jetzt bitte endlich die Zeile X=y durch X=n ersetzen und fertig? Danke."
"Nee, editor X geht nicht, weil nur VT100 und da auch eigentlich nur das originale VT05-subset. Nimm vi." - "Bring Deine Terminalemulation mal bitte ins aktuelle Jahrtausend."
usw usw

0
Von oooh-Nee am Do, 25. Mai 2017 um 14:32

na ja .. jetzt kommen ein paar Sachaussagen. Toll.

Du vergisst, was deine Frage war

Jaaa...Und was willst Du nun damit sagen?

Was wurzel meinte ist absolut klar. Jeder versteht es - nur du nicht. Mach dir nichts draus. Du kannst nichts dafür. Wahrscheinlich willst du es nicht - eben der Beißreflex.

Du bist einfach so. Leider - für Linux. Kannst du nicht ins Redmond-Lager wechseln?

0
Von Wulf am Do, 25. Mai 2017 um 14:18

du -x | sort -n | tail -n 1000

0
Von asdfszhjddd am Do, 25. Mai 2017 um 14:10

Bei C liegt es noch zusätzlich an Stackoverlow und Autoren wie Jürgen Wolf, die einfach nur Unsinn beibringen. Hauptsache der Code sieht nah 1337 h4x0r aus. Heute kann man sehr schön und bequem C und C++ programmieren. Ohne Pointer oder Memory Leaks und hässlichen bind2nd Schrott.

0
Von blablabla233 am Do, 25. Mai 2017 um 14:08

Bei Fuzzer geht es primär um Sicherheit bzw um herauszufinden wie ein Programm auf nicht-erwartete Eingaben reagiert. Dass deine Tabs von Office2003 nicht richtig übernommen werden ist da eher sekundär. Oder hast Du was gegen gefundene Sicherheitslücken?
Auch ist die Annahme dass bei 1000 Bugs nicht 30 weitere hinzukommen dürfen sehr befremdend (für den AfD'ler... befremdend hat nix mit Ausländer zutun)

0
Von WarumLinuxBesserIst am Do, 25. Mai 2017 um 14:04

Wenn ich in Foren, oder sonstigen Seiten immer diese Aussage lese, wie der Schreiber hier beginnt, dann biegen sich mir jedesmal die Zehennägel hoch.
"Jeder, der eine Manpage lesen kann, weiß..."

Eben nicht jeder kann eine Manpage lesen und die meisten deutschsprachigen Leute, können eben keine englischen manpages lesen.
Daher gibt es weltweit tausende verschiedene Sprachen. Wenn jeder englisch könnte, würde es nur eine Sprache geben.
Und smalltalk in Englisch ist was ganz anderes, als eine Technische Handlungsanweisung zu lesen.

Das ist einer der Hauptgründe, warum Linux bei weitem nicht so erfolgreich wie Windows, da immer alles verkompliziert wird und Besserwisser
in Foren mit man xyz antworten.

Genau das macht Ubuntu zur erfolgreichen Linux DIstribution.

Daher ist Ubuntu auch so erfolgreich, weil dort im Code of Conduct (Verhaltenskodex) klar festgelegt ist, das man sich helfen soll
Nachzulesen ist das hier: https://wiki.ubuntuusers.de/Ubuntu/Code_of_Conduct/

0
Von ToKi am Do, 25. Mai 2017 um 13:59

Gibst du zufälligerweise Ctrl+S ein? Dann wird nämlich die Ausgabe im Terminal generell blockiert, egal, welches Programm darin aktuell läuft. Mit Ctrl+Q kommst du da wieder raus.

0
Von blablabla233 am Do, 25. Mai 2017 um 13:55

Achnoe...der AfD'ler hat seinen Liegestuhl ausgegraben. Vendetta!!!

0
Von blablabla233 am Do, 25. Mai 2017 um 13:53

Wow, da liest einer schlecht. Bei 30 Fehler läuft bei Dir was über?

PS: Ein Fuzzer erstellt weder ein Bugreport noch ist der Output so einfach zu lesen
PPS: Aber was Du wirklich damit sagen willst, bleibt immer noch unklar

0
Von Hans L. am Do, 25. Mai 2017 um 13:28

Dass viele Layouts pixel-genau sind, ist mir ehrlich gesagt neu (aber ich bin auch definitiv kein Experte). Was Linien angeht vielleicht ja, obwohl da wie bereits erwähnt worden ist, antialiasing helfen kann. Aber wenn ich an Sachen denke wie z.B. die initiale Breite der Lesenzeichen-Seitenleiste in Firefox, die sollte ein Entwickler doch nicht einfach auf 100px festlegen nur weil das beim Test auf seinem Bildschirm ganz gut aussieht. Da sollte die API eines GUI Toolkist doch entweder die Möglichkeit bieten bei Größenangaben Maßzahl und Maßeinheit anzugeben (im Sinne von `myWidget.width = "42em"`) oder eben per expliziter Umrechnung (`myWidget.width = 42 * emToPx`).
1em ist übrigens die Breite des Buchstaben "m". Z.B. bzgl. der eingestellten Standardschrift. Eine entsprechende Konfiguration erlaubt eigentlich jedes OS (oder DE) und die kann ja auch vom Nutzer angepasst werden (z.B. hinsichtlich der DPI des Displays oder des Abstands vom Display oder der Sehkraft …).
@Lord Eine entsprechende `getEmToPx` Funktion sollte selbstverständlich von dem plattformunabhängigen Toolkit, das man benutzt, bereit gestellt und nicht selbst entwickelt werden.
Gut wäre es natürlich auch wenn man relative Größenangaben (in % des Eltern-Widget o.Ä.) machen kann.


 
Pro-Linux
Traut euch!
Neue Nachrichten