In der GNU-Philosophie heißt es: "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." Aber was ist denn jetzt "genau eine" Aufgabe? Wenn ich mal ein Programm nehme, das ich für die Firma geschrieben habe: Da muss ich TCP bedienen, den seriellen Port muss ich bedienen, Daten konvertieren, etc... Nach meinem Verständnis mehrere Aufgaben. Was ist "eine" Aufgabe?
und was macht das programm? pdf's anzeigen? oder auch noch dazu… - pdf's aufs dateisystem zugreifen lassen - forms anbieten in 2 speicherformaten - forms per http versenden - inhalt signieren - inhalt verschlüsseln - inhalt mit berechtigungen versehen - "javascript" ausführen - calls an externe programme erlauben - binäre dateien einbetten - sound, video und animationen einbetten pdf's anzeigen wäre eine aufgabe, der zeitlich dazugewachsene "zusatznutzen" ist featuritis (die das ganze schlechter wartbar und unsicherer macht). eine aufgabe ist ein klar umrissener funktionsumfang. alles was programmiert werden muss um diesen funktionumfang zu ermöglichen ist nötig.
c.m. schrieb: > eine aufgabe ist ein klar umrissener funktionsumfang. alles was > programmiert werden muss um diesen funktionumfang zu ermöglichen ist > nötig. toll. Also wenn ich den Funktionumfang erweitere darf ich alles was gebraucht wird einbauen. Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3 Player mit ein.
Peter II schrieb: > Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3 > Player mit ein. Nein, Du machst eine Konfigurationsoption in der man auswählen kann welcher Player verwendet werden soll um die Musik abzuspielen.
> Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3 > Player mit ein. Da greift folgende Regel: Niemals das Rad neu erfinden!
derElf schrieb: > Niemals das Rad neu erfinden! dann würde es Linux gar nicht geben? Wie viel Editoren gibt es? Wie viele Datenbanken gibt es? Wie viel Shells gibt es? Linux ist doch wohl das beste Beispiel dafür, wie oft dinge neu erfunden werden können.
Peter II schrieb: > derElf schrieb: >> Niemals das Rad neu erfinden! > > dann würde es Linux gar nicht geben? > > Wie viel Editoren gibt es? > Wie viele Datenbanken gibt es? > Wie viel Shells gibt es? > > Linux ist doch wohl das beste Beispiel dafür, wie oft dinge neu erfunden > werden können. Darum gehts nicht. Es geht darum, dass wenn du ein Getriebe baust, nicht gleich das Rad mit dran schweißt
JJ schrieb: > Darum gehts nicht. Es geht darum, dass wenn du ein Getriebe baust, nicht > gleich das Rad mit dran schweißt warum kann dann "find" Dateien löschen? dafür gibt es doch "rm"?
Das kann find auch nicht. Find kann rm aufrufen und benutzen. Genau so etwas ist mit der Philosophie gemeint.
JJ schrieb: > Das kann find auch nicht schon mal die doku gelesen? -delete Delete files; true if removal succeeded. If the removal failed, an error message is issued. If -delete fails, find's exit sta- tus will be nonzero (when it eventually exits). Use of -delete automatically turns on the -depth option. Es macht auch sinn, weil es schneller geht als ständig rm aufzurufen. Das zeigt aber da es nicht viel sinn macht, sich stur an solche regeln zu halten.
Ah, das kannte ich wirklich noch nicht. Das Feature widerspricht tatsächlich der Philosophie. Vermutlich war es einfach nur ziemlich einfach zu implementieren.
Peter II schrieb: > Es macht auch sinn, weil es schneller geht als ständig rm aufzurufen. > Das zeigt aber da es nicht viel sinn macht, sich stur an solche regeln > zu halten. Klar, die Regeln sind ja auch nicht in Stein gemeißelt. Hintergrund ist, dass wenn du etwas einbaust, du es auch warten musst. Wenn der potentielle Aufwand den Nutzen rechtfertigt ist das natürlich ok.
Kaj G. schrieb: > In der GNU-Philosophie heißt es: > "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." Nun, das ist eben die "Tool"-Denkweise, die man bei Unix-Leuten immer noch antrifft. Ist heutzutage eigentlich herzlich überholt. Ausgeschrieben heißt das, sogenannte Tools, also Einzweck-Kommandozeilen-Programme herzunehmen, selbige in Shell-Skripten aufzurufen und daraus "höhere" Funktionalitäten zu bilden. Das ist Murks, denn schon unsere Vorväter haben gewußt, daß ein Ganzes mehr ist als die Summe seiner Einzelteile. Genau deshalb haben sich weltweit ja auch komplexe Programme mit grafischer Oberfläche (Apps) durchgesetzt. Wer benutzt denn noch einen PC ausschließlich mittels Kommandozeile? Naja, vielleich 0.1% aller Anwender, also eine verschwindende Minderheit. Versuche doch mal als Beispiel, dir vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln. Also mal plakativ formuliert: Heutzutage hat man Applikationen und grafische Oberflächen und die Kommandozeile nebst Shell-Skripten, wo dann irgendwelche simplen Einzweck-Programme drin vorkommen, sind Schnee von vor-vor-gestern. Die Welt als solche IST komplex und Programme auf dem PC (und neuerdings auf dem smarten Phone) sind mittlerweile ebenso komplex. W.S.
Peter II schrieb: > c.m. schrieb: >> eine aufgabe ist ein klar umrissener funktionsumfang. alles was >> programmiert werden muss um diesen funktionumfang zu ermöglichen ist >> nötig. > > toll. Also wenn ich den Funktionumfang erweitere darf ich alles was > gebraucht wird einbauen. > > Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3 > Player mit ein. Ist denn MP3 abspielen ein integraler Bestandteil des Anzeigens einer PDF-Datei? Ergibt sich irgendein signifikanter Nachteil, wenn das MP3 nicht im PDF-Viewer, sondern in einem anderen Programm abgespielt wird? Wenn nicht, ist es nicht Teil der Funktion "Anzeigen einer PDF-Datei". Peter II schrieb: > warum kann dann "find" Dateien löschen? GNU-Featuritis? Ich würde die Philosophie "ein Tool pro Aufgabe" nicht unbedingt als GNU-Philosophie bezeichnen, sondern eher als UNIX-Philosophie. Entsprechend findet man in der POSIX-Spezifikation von find auch keine Option zum Löschen von Dateien. Es handelt sich um eine GNU-Erweiterung.
Bevor wir hier Birnen mit Äpfeln........
Stellt sich auch zuallerst mal die Frage, was für eine Art Programm will
ich erstellen?
Will ich nur Dateien löschen, dann brauche ich keinen Dateimanagr mit in
rm einbauen.
Will ich einen Dateimanager "kann der" rm, cp, mv ... .
Ein Officepaket unterscheidet sich in gleicher weise von einer Library
die Exel-Tabellen einliest.
//edit:
Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl
eher:
> find . -exec rm {} \;
Ja - genau so mit der kruden Syntax.
:
Bearbeitet durch User
Nils S. schrieb: > Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl > eher: >> find . -exec rm {} \; > Ja - genau so mit der kruden Syntax. ja nur sau langsam.
GNU Emacs dürfte das beste Beispiel für diese Philosophie sein;) Und Linux hat das Rad nicht neu erfunden, zu der Zeit gab es kein freies Unix(artiges) Betriebsystem für x86 das verfügbar war. Hurd befand sich noch in den frühsten Kinderschuhen, Minix war nicht frei und auf die reine Ausbildung ausgerichtet und (lite)BSDs rechtlichelage war noch nicht klar und es hing eine Klage seitens AT&T an.
Peter, weswegen wahrscheinlich die GNU-Erweiterung dazu kam. Tom, das sind hauptsächlich keine Grunde für die Entwicklung von Linux, sonderrn Umstände, die es sehr früh gefördert haben.
Nils S. schrieb: > Peter, weswegen wahrscheinlich die GNU-Erweiterung dazu kam. > > Tom, das sind hauptsächlich keine Grunde für die Entwicklung von Linux, > sonderrn Umstände, die es sehr früh gefördert haben. Linus wollte ein freies (wenn vielleicht im Sinne von Freibier) unixartiges System für seinen x86 und seine Minix-Erweiterungen haben dafür den Grundstein gelegt. Wäre ein anderes System ob BSD oder Hurd verfügbar gewesen so hätte er vermutlich nicht mit der Entwicklung begonnen. (das ist seine Aussage)
tom schrieb: > Wäre ein anderes System ob BSD oder Hurd verfügbar gewesen so hätte er > vermutlich nicht mit der Entwicklung begonnen. (das ist seine Aussage) Stimmt allerdings nicht ganz. Zu der Zeit, als er mit Linux angefangen hat, war Bill Jolitz mit 386BSD schon deutlich in der Phase, dass das System selbst booten konnte (und von potenziellen juristischen Problemen damit hat da noch keiner was geahnt). Kann allerdings sein, dass er es noch nicht gewusst hat, die Veröffentlichung von Bill Jolitz im Dr. Dobbs Journal könnte sich zeitlich gerade so überschnitten haben mit seinen Anfängen. Da er aber andererseits vor allem deshalb angefangen hat, weil er überhaupt mal den protected mode des i386 kennenlernen wollte, ist es durchaus zweifelhaft, ob ihn ein bereits vorhandenes freies System tatsächlich davon abgehalten hätte, seinen Spieltrieb weiter zu verfolgen. Aber das nur am Rande.
:
Bearbeitet durch Moderator
Das hat sich wohl erledigt. Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte schrieben. Dafür brauchte man kleine Programme, die nur Dateien suchten, oder nur Textzeile aus Ascii-Dateien filterten. Heutzutage benutzt ein normaler Mensch Dateimanager und Office-Paket. Wir haben keine Textdateinen mehr. Wir haben Emails mit Word-Attachment. Was sollen wir da mit den alten Unix-Tools wie sed, grep und sort anfangen? Nicht mal die Programmierer wollen heutzutage noch ein Makefile mit find und sed generieren.
Noch einer schrieb: > Das hat sich wohl erledigt. > > Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte > schrieben. Dafür brauchte man kleine Programme, die nur Dateien suchten, > oder nur Textzeile aus Ascii-Dateien filterten. och die braucht $admin immernoch. und ganz ehrlich mag ich die gnu erweiterungen - es gibt nichts beschisseneres als ein grep das nicht rekursiv suchen kann oder ein tar das bei quelldateien>4GB runzickt. aber ein tar das mir auf eine framebuffer console bilder anzeigen kann braucht kein mensch ;)
Noch einer schrieb: > Nicht mal die Programmierer wollen heutzutage noch ein Makefile mit find > und sed generieren. Dafür nehmen Programmierer (die nicht Klicki-Bunti machen) seit Ewigkeiten die GNU Autotools. Mit dem tollen Nebeneffekt dass es dann sehr (wenn auch leider nicht 100%) Plattform unabhängig wird.
> GNU-Philosophie
macht einheitliche Konfigurationsdateien steht da wohl nicht drin ;-)
> die nicht Klicki-Bunti machen Gibt es überhaupt noch Programmierer, die diese GNU Autotools verstehen? Das letzte mal habe ich 2010 davon gehört. http://geekandpoke.typepad.com/geekandpoke/2010/05/how-to-become-invaluable.html
Noch einer schrieb: > Gibt es überhaupt noch Programmierer, die diese GNU Autotools verstehen? Ob es jemanden gibt, der sie bis in die letzte Ecke versteht, weiß ich nicht. ;-) Aber benutzen kann man sie auch schon dann ganz gut, wenn man die 50 % verstanden hat, die man am häufigsten braucht. Ihr wesentlicher Vorteil gegenüber allen anderen Lösungen ist, dass sie eben bei demjenigen, der den Salat dann compilieren soll, wirklich nur eine Shell und ein paar gängigere Tools benötigen, während man bei scons, cmake, … jeweils noch irgendwas zusätzlich auch auf der Zielplattform braucht.
Jörg W. schrieb: > Ihr wesentlicher Vorteil gegenüber allen anderen Lösungen ist, dass sie > eben bei demjenigen, der den Salat dann compilieren soll Irgendeine unverständliche Fehlermeldung um die Ohren hauen die laut den Entwicklern "überhaupt nicht auftreten dürfte" ;-)
W.S. schrieb: > Unix Robert L. schrieb: >> GNU-Philosophie > > macht einheitliche Konfigurationsdateien steht da wohl nicht drin ;-) So wie die Windows Registry? Auch der große Erfolg überhaupt. Die Unix-Philosophie (GNU kam erst viel später) bei Konfigurationsdateien war eigentlich: - Text - Zeilenorientiert - als dot-rc Datei im Home-Verzeichnis versteckt. Dann kamen die speziellen Helden, die fanden, dass Environment-Variablen besser wären oder eine komplizierte Syntax her muss. Im Ergebnis ist es jetzt genauso wild wie bei Windows. Zeig mir jemanden, der alle Einträge in der Registry versteht.
Kaj G. schrieb: > In der GNU-Philosophie heißt es: > "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." Das stammt noch aus Zeiten der Ur-Unixsteinzeit, wo jedes Gramm zu viel Code den Speicher vollmüllte und Codewiederverwendung anders umgesetzt wurde. Heute schreibt man Programme nach dem Motto: soll Funktion x am einfachsten erfüllen und benutzerfreundlich sein und mir nicht auf den Sack gehen. Das Beispiel von find mit eingebautem Datei löschen zeigt es doch: Das braucht man oft also baut man es direkt ein ohne sich einen mit der Sythax abzubrechen, die zudem noch seltsame Seiteneffekte hat die ich bei bestimmten Sternenkonstellationen neachten muss. Schreib dein Programm wie du es für am sinnvollsten hältst.
W.S. schrieb: > Das ist Murks, denn schon unsere Vorväter haben gewußt, daß ein Ganzes > mehr ist als die Summe seiner Einzelteile. Genau deshalb haben sich > weltweit ja auch komplexe Programme mit grafischer Oberfläche (Apps) > durchgesetzt. Wer benutzt denn noch einen PC ausschließlich mittels > Kommandozeile? Naja, vielleich 0.1% aller Anwender, also eine > verschwindende Minderheit. Versuche doch mal als Beispiel, dir > vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von > Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen > sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln. Das letzte mal als du Linux benutzt hast hatte ein Monitor noch 80 Zeichen breite oder? Es geht garnicht darum NUR konsolenprogramme mit minimaler Funktionalität zur Verfügung zu stellen. Die Sache musst du dir eigentlich andersrum überlegen. Stelle dir vor, jemand möchte ein tolles Programm schreiben um Datenträger zu partitionieren und formatieren. Mit der Windows-Mentalität müsste er dafür alle Dateisysteme und Datenträger-Header selbst implementieren und warten. Unter Linux braucht er nur die entsprechenden Tools aufrufen, fdisk, gdisk, mkfs.* usw. Den User freut es, weil das Programm stabiler Läuft und öfter Updates bekommt. Den Entwickler auch, weil er sich nur um das Interface und die Verbindung der Tools kümmern muss. Und der versierte Nutzer kann, wenn er keine Lust auf die GUI hat, die Tools auch einzeln ausführen. Wo ist da das Problem?
Guest schrieb: > Stelle dir vor, jemand möchte ein > tolles Programm schreiben um Datenträger zu partitionieren und > formatieren. Mit der Windows-Mentalität müsste er dafür alle > Dateisysteme und Datenträger-Header selbst implementieren und warten. oder die passenden Bibliotheken verwenden. > Unter Linux braucht er nur die entsprechenden Tools aufrufen, fdisk, > gdisk, mkfs.* usw. Den User freut es, weil das Programm stabiler Läuft > und öfter Updates bekommt. Den Entwickler auch, weil er sich nur um das > Interface und die Verbindung der Tools kümmern muss. und das ist gar nicht so einfach, weil er die Ausgaben von fdisk usw. parsen muss. Wenn fdisk jetzt auf die Idee kommt ihre Ausgaben anders zu formatieren (und wenn es nur die Sprache ist) geht es schief. Oder FDISK ändert die Parameter oder eingaben ab. Damit muss man hier genauso die "Schnittstelle" pflegen. Sinnvoller ist es Bibliotheken mit einer Definierten API zu schaffen, dann kann man sie überall nutzen.
Peter II schrieb: > parsen muss. Wenn fdisk jetzt auf die Idee kommt ihre Ausgaben anders zu > formatieren (und wenn es nur die Sprache ist) geht es schief. Oder FDISK > ändert die Parameter oder eingaben ab. > > Damit muss man hier genauso die "Schnittstelle" pflegen. > > Sinnvoller ist es Bibliotheken mit einer Definierten API zu schaffen, > dann kann man sie überall nutzen. Was du da für Nachteile aufzählst, gilt doch genau so für Bibliotheken, wenn man da die Schnittstelle ändert. Und außerdem ist man mit Bibliotheken erst einmal auf eine Programiersprache festgelegt. "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." Sieht man, finde ich, am Schönsten beim betrachten der CD/DVD-Brennprogramme. Bei Linux gibt es die Backend-Programme welche auch auf der Konsole Bedienbar sind und zusätzlich noch das Frontend, welches man auch nach belieben Austauschen kann. Und zum Vergleich das völlige Gegenteil dazu ist z.B. Nero(gibt es das noch?), da kannst du dann mit dem Brennprogramm auch noch gleich den Videoschnitt machen ;)
mec schrieb: > Was du da für Nachteile aufzählst, gilt doch genau so für Bibliotheken, > wenn man da die Schnittstelle ändert. Und außerdem ist man mit > Bibliotheken erst einmal auf eine Programiersprache festgelegt. nicht wirklich. Eine Änderung der API bekommt man dann vom Compiler geliefert. API sind etwas stabiler als der Input und Output eines Konsolenprogrammes. Da jede Programmiersprache mehr oder weniger direkt Funktionen vom Betriebssystem aufrufen kann, scheint die "Sprache" wohl kein Problem zu sein.
W.S. schrieb: > Das ist Murks, denn schon unsere Vorväter haben gewußt, daß ein Ganzes > mehr ist als die Summe seiner Einzelteile. Genau deshalb haben sich > weltweit ja auch komplexe Programme mit grafischer Oberfläche (Apps) > durchgesetzt. ...und wenn der Entwickler dieses tollen bunten Programms irgendeine Funktion nicht so implementiert wurde, wie ich sie benötige, schreibe ich einfach das Programm nochmal? soso....
Guest schrieb: > Stelle dir vor, jemand möchte ein > tolles Programm schreiben um Datenträger zu partitionieren und > formatieren. Mit der Windows-Mentalität müsste er dafür alle > Dateisysteme und Datenträger-Header selbst implementieren und warten. Ja, kann ich mir vorstellen: Partition Magic zum Beispiel. Ist alt, sollte deshalb bekannt sein. Wird per nacktem MSDOS gestartet, bringt seine eigene grafische Oberfläche nebst Mausbedienung mit, kann/konnte mit allen damals bekannten Dateisystemen umgehen. Und das MUSS so eine Anwendung auch, denn die Thematik ist zu komplex, um sie in einzelne Kommandozeilenprogramme aufzuteilen. mec schrieb: > Bei Linux gibt es die Backend-Programme welche auch auf der Konsole > Bedienbar sind und zusätzlich noch das Frontend, welches man auch nach > belieben Austauschen kann. > Und zum Vergleich das völlige Gegenteil dazu ist z.B. Nero(gibt es das > noch?), da kannst du dann mit dem Brennprogramm auch noch gleich den > Videoschnitt machen Man könnte glatt auf den Gedanken kommen, daß du so ein Backend-Gewurschtel nebst davon losgelöstem Frontend besser findest als eine richtige Anwendung, die das alles integriert in sich hat, konsistenter funktioniert und schlichtweg benutzerfreundlicher ist. Ich zeig dir mal ein Gegenteil: Kopiere mal ne Datei, sagen wir mal 1 GB, unter Linux von HD nach Stick, benutze dazu Krusader oder nen Dateimanager deiner Wahl. Was passiert? Nun - SCHEINBAR - wird die ganze Datei binnen 2 Sekunden auf den Stick kopiert. Danach steht der Fortschrittsbalken im Popupfenster des (eigentlichen) Kopierprogramms auf 100% - und dort bleibt er dann auch für die nächsten Minuten. Warum? Weil es bei dem tollen Tool-System eben keine sinnvolle Kopplung zwischen Frontend und Backend gibt. Bei der Verfahrensweise, daß ein Frontend ein temporäres Skript oder Kommandozeile generiert und selbige dann quer durch's System zum ausführenden Tool geleitet wird, gibt es keine Echtzeit-verbindung zwischen Front und Back. Das ist saublöd, denn dabei ist in keiner Weise daran gedacht worden, daß vor dem PC ein MENSCHLICHER Benutzer sitzt und sich fragt, ob der PC abgestürzt ist. Bei sowas ist der Fortschrittsbalken völliger Mumpitz, denn er zeigt nicht im Geringsten den eigentlichen Stand der Bearbeitung an. Ich hab's ja weiter oben schon geschrieben, daß diese Tool-Denkweise überholt ist. Mal ganz ordinär gesagt, ist sie scheisse, denn dabei werden immer nur die Befindlichkeiten von Programmierern berücksichtigt, die sich über komplexe Dinge keine Gedanken machen wollen - und die Bedürfnisse der Benutzer bleiben schlichtweg außen vor. OK, Admins, die über "userland" nur mit gerümpfter Nase sprechen, denken so und meinen daß dies die alleinseligmachende Denkweise sei, aber der Rest der Welt sieht das ganz anders. W.S.
W.S. schrieb: > Weil es bei dem tollen Tool-System eben keine sinnvolle Kopplung > zwischen Frontend und Backend gibt. Nö, aber schön, dass du auch ohne Analyse schon weißt, woran es liegt. Da das zugrunde liegende Problem nicht so ganz trivial ist, wäre wohl die Alternative vieler anderer Programme, dann einfach auf (sowieso nicht funktionierende) Prozentzahlen zu verzichten und einen vor sich hin wabernden Fortschrittsbalken anzuzeigen … Ein besonders krasses Exemplar davon hatte ich mal vor Jahren bei irgendeiner Software, die eine ISDN-Verbindung herstellen sollte. Ich musste beide Seiten konfigurieren (den Einwahlrouter und den Client): während der Einwahlrouter innerhalb nullkommanix meldet, dass er den Einwählenden abgewiesen hat, wabert der Fortschrittsbalken „Verbindung wird aufgebaut“ noch 5 Sekunden vor sich hin, bis dann irgendwann die lapidare Meldung „geht nich“ angezeigt wird. In dem Falle dahingehend nicht tragisch, dass ich ja beide Seiten sehen konnte, aber ein Nutzer, der nur den Client vor sich hat, wäre mit einem (optional, braucht man ja nur zum Einrichten) in Echtzeit angezeigten Log des Einwahl-Backends deutlich besser bedient gewesen. Er hätte dann ohne „Kunstpausen“ sofort gesehen, dass das noch was nicht stimmt, und die Logmeldungen hätten ihm vielleicht auch noch verraten, was nicht passt.
:
Bearbeitet durch Moderator
W.S. schrieb: > Ja, kann ich mir vorstellen: Partition Magic zum Beispiel. Ist alt, > sollte deshalb bekannt sein. > > Wird per nacktem MSDOS gestartet, bringt seine eigene grafische > Oberfläche nebst Mausbedienung mit, kann/konnte mit allen damals > bekannten Dateisystemen umgehen. Und das MUSS so eine Anwendung auch, > denn die Thematik ist zu komplex, um sie in einzelne > Kommandozeilenprogramme aufzuteilen. Ganz im Gegenteil: gerade das lässt sich wunderbar in kleine Häppchen aufteilen. > Man könnte glatt auf den Gedanken kommen, daß du so ein > Backend-Gewurschtel nebst davon losgelöstem Frontend besser findest als > eine richtige Anwendung, die das alles integriert in sich hat, > konsistenter funktioniert und schlichtweg benutzerfreundlicher ist. "Man könnte glatt auf den Gedanken kommen, dass du ein bloatiges Anwendungs-Gewurschtel besser findest, als ein richtig gut gemachtes Frontend, dass die Funktionalität schön abstrahiert hat, konsistent funktioniert und schlicht anwenderfreundlicher ist." Das ist genauso sinnvoll. Ja, eine gut gemachte Anwendung ist besser als Gewurschtel - unabhängig davon, nach welchem Prinzip die Anwendung entwickelt ist. > Ich zeig dir mal ein Gegenteil: > Kopiere mal ne Datei, sagen wir mal 1 GB, unter Linux von HD nach Stick, > benutze dazu Krusader oder nen Dateimanager deiner Wahl. Was passiert? > Nun - SCHEINBAR - wird die ganze Datei binnen 2 Sekunden auf den Stick > kopiert. Danach steht der Fortschrittsbalken im Popupfenster des > (eigentlichen) Kopierprogramms auf 100% - und dort bleibt er dann auch > für die nächsten Minuten. Warum? Weil es bei dem tollen Tool-System eben > keine sinnvolle Kopplung zwischen Frontend und Backend gibt. Schlecht gemacht, aber das hat nichts mit der Architektur generell zu tun. Allgemein kenne ich dieses Problem nicht, und Krusader ist, wenn ich das richtig sehe, auch schon in die Jahre gekommen. Letztes stabile Release Anfang 2009, vielleicht solltest du einmal etwas moderneres probieren? > Ich hab's ja weiter oben schon geschrieben, daß diese Tool-Denkweise > überholt ist. Mal ganz ordinär gesagt, ist sie scheisse, denn dabei > werden immer nur die Befindlichkeiten von Programmierern berücksichtigt, > die sich über komplexe Dinge keine Gedanken machen wollen - und die > Bedürfnisse der Benutzer bleiben schlichtweg außen vor. OK, Admins, die > über "userland" nur mit gerümpfter Nase sprechen, denken so und meinen > daß dies die alleinseligmachende Denkweise sei, aber der Rest der Welt > sieht das ganz anders. Interessante Meinung, ich teile sie aber ganz und gar nicht. Irgendwie scheint mir, als wärst du der Meinung, dass sich die Anwender hier ihre Tools generell selbst in der Kommandozeile verketten müssten.
Noch einer schrieb: > Das hat sich wohl erledigt. > > Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte > schrieben. Dafür brauchte man kleine Programme, die nur Dateien suchten, > oder nur Textzeile aus Ascii-Dateien filterten. > > Heutzutage benutzt ein normaler Mensch Dateimanager und Office-Paket. Ja, und man erkennt als jemand, der die alte Philosophie gewöhnt ist, schnell den Nachteil. Die neuen Programme sind Bloatware, vollgestopft mit den Dingen, von denen der Entwickler dachte, daß es das sei, was man braucht. Tausend Funktionen in ein einzelnes Programm gequetscht, und das, was man tatsächlich braucht, ist doch nicht dabei. Man wird in einen Workflow gezwängt, den der Hersteller vorgesehen hat, und wenn man es anders will, wird's hakelig und umständlich. Das System an die eigenen Bedürfnisse anpassen, geht nur noch in sehr engem Rahmen.
>Die neuen Programme
Word und Excel
oder was meinst
das ist alles Neuland für uns..
aber irgendwann werden wird das auch schaffen..!!
Nachtrag: > Man wird in >einen Workflow gezwängt, den der Hersteller vorgesehen hat, und wenn man >es anders will, wird's hakelig und umständlich. du scheinst noch sie ein Programm entwickelt zu haben. die Einstellmöglichkeiten werden versteckt DAS IST ABSICHT..stell dir vor jeder Kunden könnte überall herum-schrauben und du bei jedem Supportfall erstmal schauen muss was er wo/wie unmögliches eingestellte haben könnte..
>Versuche doch mal als Beispiel, dir >vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von >Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen >sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln. super Beispiel ;-) http://ftp6.nero.com/user_guides/utilities/nerocmd/NeroCMDUser.pdf
Robert L. schrieb: > Nachtrag: >> Man wird in >>einen Workflow gezwängt, den der Hersteller vorgesehen hat, und wenn man >>es anders will, wird's hakelig und umständlich. > > du scheinst noch sie ein Programm entwickelt zu haben. > > die Einstellmöglichkeiten werden versteckt > > DAS IST ABSICHT..stell dir vor jeder Kunden könnte überall > herum-schrauben Tja, ich bin dann wohl nicht Zielgruppe solcher Software, denn ich möchte mich nicht an das System anpassen müssen, sondern das System an mich anpassen. Natürlich hat sich die User-Landschaft im Laufe der Jahre geändert. Heute soll ein Computer so leicht zu bedienen sein, wie ein Toaster, so daß auch Leute, die sich damit nicht auskennen und nicht einen großen Teil ihrer Zeit damit verbringen, ihn nutzen können. Schade ist es nur, wenn für den heute wohl "Poweruser" genannten Benutzer dadurch alles umständlicher und schlechter anpassbar wird. W.S. schrieb: > Versuche doch mal als Beispiel, dir > vorzustellen, sowas wie Nero zum Scheiben-Brennen als Bündel von > Einzel-Tools den Leuten anzubieten, wo dann jeder gemäß seinen Wünschen > sich ein Shellskript dazu schreibt, um sein Zeug auf die CD zu brutzeln. Also ich bin mit k3b ganz zufrieden. Das ist ein Frontend für einen ganzen Stall von Kommandozeilentools zum Brennen von CDs und DVDs. Man muß keine Shellskripte schreiben, um es zu benutzen, aber wer irgendeine besondere Anforderung hat, kann die Tools auch direkt einzeln auf der Kommandozeile nutzen.
teil 1: nenn halt mal konkrete programme? wenn ich mir anschauen, wie sich leute ihr Excel "angepasst" haben (mit macros usw.) wird einem eher schlecht... als dass man von "zuwenig Anpassung möglich" sprechen könnte) das war früher allerdings schlimmer als jetzt.. teil 2: CD/DVD brennen interessiert eh keinen mehr..
:
Bearbeitet durch User
Vielleicht sollte man es wirklich als "Philosophie" sehen, und nicht als der Weißheit letzter Schluß, denn manchmal ist dieses Vorgehhen, und dann auch mal wieder das andere Vorgehen, sinnvoller. Einer liebt dies, der andere das. Man sollte sich immer beide Seiten, vor- und Nachteile ansehen, und dann für sich das richtige Wählen. Ich für mich, finde die Unix-Philosophi besser, sie ist anpassbarer, logischer und es dekt sich mit den ganzen Ratschlägen, wie man große und komplexe Dinge angehen sollte. Und wenn man Geld verdienen will, wäre die Windows-Philosophy besser, damit kann man die Kunden viel besser binden und zur Melkkuh machen. Jeder flucht über das System, trozdem will man nicht umlehrnen ;)
Peter II schrieb: > c.m. schrieb: >> eine aufgabe ist ein klar umrissener funktionsumfang. alles was >> programmiert werden muss um diesen funktionumfang zu ermöglichen ist >> nötig. > > toll. Also wenn ich den Funktionumfang erweitere darf ich alles was > gebraucht wird einbauen. > > Ich will Hintergrundmusik haben beim PDF lesen, also baue ich eine MP3 > Player mit ein. ...und dann willst Du noch Funktionen, um einzelne Worte aus Deinem PDF in einem Wörterbuch oder bei Google nachzuschlagen, und baust einen Webbrowser mit ein, danach willst Du bestimmte Textpassagen aus Deinem PDF per E-Mail verschicken und baust einen MUA ein, und dann möchtest Du noch formatierte Notizen in Deinem PDF einfügen und baust einen Wordprozessor ein, ... Am Ende hast Du dann einen unwartbaren, unflexiblen, nicht erweiterbaren und instabilen Monolithen, der zwar alles kann, irgendwie, aber nichts richtig. Und um kurz in ein PDF-Datenblatt zu schauen, braucht alleine der Start Deines Programms zehn Minuten, und während es läuft, belegt es vier Gigabyte Arbeitsspeicher und lastet zwei CPU-Kerne voll aus... Merkst Du was? Genau: das ist total bescheuert. Darum gibt es Programme, um PDFs anzuschauen, und andere, um MP3s anzuhören. Und wenn Du ernsthaft Funktionen für MP3s in Deinem PDF-Viewer haben willst, dann baust Du nur höchstens die Steuerung für einen externen MP3-Player ein, statt gleich einen ganzen MP3-Player.
Peter II schrieb: > JJ schrieb: >> Darum gehts nicht. Es geht darum, dass wenn du ein Getriebe baust, nicht >> gleich das Rad mit dran schweißt > > warum kann dann "find" Dateien löschen? > > dafür gibt es doch "rm"? Trotzdem ist "find" zunächst nur ein Programm, um Dateien und Verzeichnisse zu finden. Wenn es mit den gefundenen Dateien und Verzeichnissen nichts tun kann, wäre das Programm als solches ziemlich sinnlos, oder? Deswegen kann es mit -exec ein externes Programm mit dem Gefundenen aufrufen, mit -print und -print0 das Gefundene ausgeben, oder es mit -delete eben auch löschen. Dabei ist -delete nur ein Shortcut für "-exec rm {} \;" mit dem zusätzlichen Vorteil, daß nicht für jede gefundene Datei eigens ein fork() und exec() zum Starten von /bin/rm ausgeführt werden muß. (Ja, neuere Versionen von find können an dieser Stelle "-exec rm {} +" benutzen, aber das ist hier nicht der Punkt.) Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: find ist besonders gut darin, Dateien und Verzeichnisse zu finden und was damit zu machen, während rm besonders gut darin ist, Dateien und Verzeichnisse zu löschen. Da hättest Du mit ein bisschen Nachdenken aber auch selbst drauf kommen können, wenn Du nicht krampfhaft damit beschäftigt gewesen wärest, irgendwie einen Widerspruch zu konstruieren.
Karl Käfer schrieb: > Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: kann man sich auch einreden. Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm Befehl.
W.S. schrieb: > Kaj G. schrieb: >> In der GNU-Philosophie heißt es: >> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." > > Nun, das ist eben die "Tool"-Denkweise, die man bei Unix-Leuten immer > noch antrifft. Ist heutzutage eigentlich herzlich überholt. Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens "Powershell" gegossen. Insofern sind Deine Aussagen an ignoranter Inkompetenz kaum zu überbieten, aber das ist man von Dir ja gewohnt. :-)
Rolf M. schrieb: > Ja, und man erkennt als jemand, der die alte Philosophie gewöhnt ist, > schnell den Nachteil. Die neuen Programme sind Bloatware, vollgestopft > mit den Dingen, von denen der Entwickler dachte, daß es das sei, was man > braucht. Davon abgesehen gibt es viele Aufgaben, die automatisiert werden müssen, um effizient zu laufen. Natürlich kann der Heimanwender und Büroschreibling gerne mit Excel hantieren, aber das ist für gewisse Aufgaben nicht effizient.
Karl Käfer schrieb: > Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein > paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese > Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens > "Powershell" gegossen. nein, sie arbeiten mit Libs(dlls) und nicht mit einzelnen Programme. Damit haben sie eine definierte API und nicht nur Aufrufparameter und Output der geparst werden muss.
Nils S. schrieb: > Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl > eher: >> find . -exec rm {} \; > Ja - genau so mit der kruden Syntax. Heutzutage kann man auch
1 | find <where> <kriterium> -exec rm {} + |
benutzen -- das übergibt immer so viel Gefundenes an eine Instanz von rm, bis die maximale Länge der Kommandozeile erreicht ist.
Noch einer schrieb: > Diese Philosophie stammt aus einer Zeit, als Anwender noch Shell-Scripte > schrieben. Apples MacOS hat jahrelang gar keine Shell mitgebracht, und Microsoft hat ebensolang versucht, die Kommandozeile aus dem System zu verbannen. Aber irgendwann haben sowohl Apple als auch Microsoft gemerkt, daß so eine Shell keineswegs antiquiert und in den Händen eines Könners ein viel flexibleres, leistungfähigeres, und produktiveres Werkzeug ist als der ganze klickibunte Mist ist. Und siehe da: urplötzlich hat MacOS seit Version X eine moderne, leistungsfähige Bash dabei, während MS mit der Powershell sogar eine eigene Neuentwicklung auf die Beine gestellt hat. Anders gesagt: mittlerweile haben sogar die bornierten Hirnis bei Microsoft und Apple begriffen, was für ein mächtiges Werkzeug so eine Shell ist. Nur Du hast es offensichtlich immer noch nicht gerafft. Warum nur?
Peter II schrieb: > Karl Käfer schrieb: >> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: > > kann man sich auch einreden. > > Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm > Befehl. Wenn find rm aufruft ist es keine eigene Implementierung, weil dann find keinen Sourcecode zum löschen von Dateien hat. Und die Philosophie von jede Aufgabe ein Programm steckt doch im übertragenden Sinne heute auch in der Modularisierung bzw. Objektorientierung. Man schreibt nicht 1000 Zeilen Code sondern Packt das in einzelne Module/Objekte. Peter II, deine Verteufelung von Linux ist manchmal einfach nervend.
Karl schrieb: >> Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm >> Befehl. > > Wenn find rm aufruft ist es keine eigene Implementierung, weil dann find > keinen Sourcecode zum löschen von Dateien hat. find ruft aber nicht rm auf. find hat es aber im Quellcode:
1 | static bool |
2 | perform_delete (int flags) |
3 | {
|
4 | return 0 == unlinkat (state.cwd_dir_fd, state.rel_pathname, flags); |
5 | }
|
> Peter II, deine Verteufelung von Linux ist manchmal einfach nervend.
wo liest du das raus? Ich verwende selber Linux auf Servern.
Karl Käfer schrieb: > Nils S. schrieb: >> Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl >> eher: >>> find . -exec rm {} \; >> Ja - genau so mit der kruden Syntax. > > Heutzutage kann man auch >
1 | > find <where> <kriterium> -exec rm {} + |
2 | > |
> benutzen -- das übergibt immer so viel Gefundenes an eine Instanz von > rm, bis die maximale Länge der Kommandozeile erreicht ist. Der (IMO) UNIXigere weg wäre es, wenn find einfach nur Dateinamen auf die Standardausgabe schreiben könnte. Löschen, etc. kann man dann ja mit | xargs rm o.ä. machen.
:
Bearbeitet durch User
Peter II schrieb: > Karl Käfer schrieb: >> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: > > kann man sich auch einreden. > > Ist es kein Shortcut, es ist einen eigenen Implementierung von dem rm > Befehl. Welchen Teil von "Trotzdem ist "find" zunächst nur ein Programm, um Dateien und Verzeichnisse zu finden." hast Du nicht verstanden? Wie gesagt: wenn Du nicht ständig bemüht wärst, irgendwelche Widersprüche zu konstruieren, nur um widersprechen zu können, wärst Du sicher selbst darauf gekommen. Aber so -- und obwohl Du oben selbst festgestellt hast, daß ein "-exec rm {} \;" bei vielen Fundstellen nicht sonderlich performant ist -- erkennst Du nicht einmal, daß "-delete" nur eine Möglichkeit in Form eines Shortcut für eine der drei Möglichkeiten "-exec rm {} \;", "-exec rm {} +" oder "-print0 | xargs -0 -- rm" ist. Wobei "rm" natürlich noch eine ganze Reihe weiterer Möglichkeiten bietet, die die Option "-delete" von find nicht hat: schau einfach mal in die Manpage von rm.
Karl Käfer schrieb: > Welchen Teil von "Trotzdem ist "find" zunächst nur ein Programm, um > Dateien und Verzeichnisse zu finden." hast Du nicht verstanden? und welchen Teil von "Das hat in einen find nichts zu suchen" nach der GNU-Philosophie hast du nicht verstanden? Es war nur als Beispiel gemeint, das man diese Philosophie nicht stur befolgen sollte, weil es teilweisen keinen Sinn macht.
Peter II schrieb: > Karl Käfer schrieb: >> Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein >> paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese >> Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens >> "Powershell" gegossen. > > nein, sie arbeiten mit Libs(dlls) und nicht mit einzelnen Programme. Willst Du mich verarschen? Das Pipeline-Konzept, die Ausgabe eines Teils als Eingabe für den nächsten Teil zu benutzen und die einzelnen einfachen Teile zu einer wesentlich komplexeren Gesamtfunktion zusammenzusetzen, ist 1:1 von den UNIX-Shells geklaut. Dabei ist es auch unter UNIX egal, ob ein Teil einer Pipe nun ein externes Programm oder ein Shell-Builtin aufruft -- im letzeren Fall ist das genau dasselbe wie bei den meisten Aufrufen in der Powershell, und im ersten Fall ist es genau wie wenn man ein eigenes Cmdlet in der Powershell benutzt.
Karl Käfer schrieb: > Willst Du mich verarschen? Das Pipeline-Konzept, die Ausgabe eines Teils > als Eingabe für den nächsten Teil zu benutzen und die einzelnen > einfachen Teile zu einer wesentlich komplexeren Gesamtfunktion > zusammenzusetzen, ist 1:1 von den UNIX-Shells geklaut. und, was willst du jetzt damit sagen? Hat jemand etwas anders behauptet?
Auf Mathematik übertragen hieße das wohl, man kommt überall mit 1 und + hin. Ein klassischer Text dazu ist ganz gut verständlich http://harmful.cat-v.org/cat-v/ und hier mit verlinkt: http://harmful.cat-v.org/cat-v/unix_prog_design.pdf Haskell funktioniert (und failt, siehe Grafik) ganz gut in dieser gedachten Richtung. Beispielsitzung mit dem Haskellcompiler ghci: Prelude> let add1 = (+1) Prelude> add1 5 6 Prelude> map add1 [1..10] [2,3,4,5,6,7,8,9,10,11] Prelude> drop 5 (map add1 [1..10]) [7,8,9,10,11] Prelude> reverse (drop 5 (map add1 [1..10])) [11,10,9,8,7] Aber Silberkugeln... https://www.lug-ottobrunn.de/wiki/Basisregeln_zur_Softwareentwicklung Letztlich: a) Es kommt auf den Zusammenhang an -> https://xkcd.com/224/ b) einfach modular, (+1) usw. braucht etwas Übung.
Peter II schrieb: > Karl Käfer schrieb: >> Willst Du mich verarschen? Das Pipeline-Konzept, die Ausgabe eines Teils >> als Eingabe für den nächsten Teil zu benutzen und die einzelnen >> einfachen Teile zu einer wesentlich komplexeren Gesamtfunktion >> zusammenzusetzen, ist 1:1 von den UNIX-Shells geklaut. > > und, was willst du jetzt damit sagen? Hat jemand etwas anders behauptet? Fassen wir den Verlauf an dieser Stelle doch einfach mal kurz zusammen: W.S. behauptet, daß die "Tool-Denkweise" wahlweise "saublöd", "scheisse" oder wenigstens "herzlich antiquiert" sei. (Nunja, jeder ist für seine kommunikativen Fähigkeiten selbst verantwortlich...) Sheeva Plug führt daraufhin die Powershell als Beweis dafür an, daß genau diese "Tool-Denkweise" gerade bei Microsoft eine Renaissance erlebt, weil sogar Microsoft mittlerweile erkannt hat, daß diese "Tool-Denkweise" eine hervorragende Automatisierungs- und Benutzerschnittstelle darstellt. Du widersprichst Sheeva Plug daraufhin mit dem, äh, "Argument", daß bei der Powershell keine externen Programme, sondern Bibliotheksfunktionen aufgerufen würden, was erstens einfach falsch ist und zweitens, selbst wenn es stimmen würde, vollkommen irrelevant wäre. Denn gleichgültig, ob die Tools nun aus einer Bibliothek aufgerufen oder als externe Programme ausgeführt werden, gehört kein besonderes Genie zu der schlichten Erkenntnis, daß hinter dem ganzen Konzept der Powershell genau dieselbe "Tool-Denkweise" steckt wie bei den Shells unter Unix.
Sheeva P. schrieb: > Du widersprichst Sheeva Plug daraufhin mit dem, äh, "Argument", daß bei > der Powershell keine externen Programme, sondern Bibliotheksfunktionen > aufgerufen würden, was erstens einfach falsch ist und zweitens, selbst > wenn es stimmen würde, vollkommen irrelevant wäre. genau das ist aber der Unterschied. Bibliotheken mit definierten APIs aufzurufen ist nicht wirklich vergleichbar mit externe Programm starten. Und ja es stimmt. das die Cmdlet, keine einfache externen Programm sind https://technet.microsoft.com/en-us/library/ms714395(v=vs.85).aspx > Denn gleichgültig, ob die Tools nun aus einer Bibliothek aufgerufen oder > als externe Programme ausgeführt werden, gehört kein besonderes Genie zu > der schlichten Erkenntnis, daß hinter dem ganzen Konzept der Powershell > genau dieselbe "Tool-Denkweise" steckt wie bei den Shells unter Unix. nein, ist die die Denkweise das man möglichst viel Code wiederverwendet. Dabei ist das Aufrufen von externen Programm eine extrem "primitive" Version davon. Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen.
Ich glaube da hat der OP auch einiges verwechselt. Er meint wohl die Unix-Philosophie, nicht die GNU-Philosophie. Und die wird im Buch "The Art of UNIX Programming" sehr gut besprochen. http://www.catb.org/esr/writings/taoup/html/
@ Peter II Der fehlender Fortschrittsanzeiger hat weniger mit Programm oder Funktion zu tun als damit, dass es einfach nicht implementiert ist. cp ist schlicht dann fertig, wenn EOF erreicht ist. Es gibt genug Gegenbeispiele, die Ihren Fortschritt auf der Konsole ausspucken oder ihn nach /proc schreiben.
Peter II schrieb: >> Denn gleichgültig, ob die Tools nun aus einer Bibliothek aufgerufen oder >> als externe Programme ausgeführt werden, gehört kein besonderes Genie zu >> der schlichten Erkenntnis, daß hinter dem ganzen Konzept der Powershell >> genau dieselbe "Tool-Denkweise" steckt wie bei den Shells unter Unix. > > nein, ist die die Denkweise das man möglichst viel Code wiederverwendet. Schwachsinn. Mit der "Tool-Denkweise", komplexere Funktionen durch die Verknüpfung einfacher Komponenten zusammensetzen, hat das nichts zu tun. Schwachsinn auch, weil klassische UNIX-Werkzeuge natürlich den Großteil ihres Code aus gemeinsamen Bibliotheken beziehen. > Dabei ist das Aufrufen von externen Programm eine extrem "primitive" > Version davon. Schwachsinn. Kannst Du nicht zwischen Konzept und Umsetzung unterscheiden? > Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen. Schwachsinn. Ohne einen entsprechenden Mechanismus geht sowas bei einer Bibliotheksfunktion auch nicht. Solche Mechanismen kann man natürlich auch beim Aufruf eines externen Programms einbauen, sogar viel einfacher als bei einer Bibliotheksfunktion. Abgesehen davon hat das aber auch nichts mit der hier diskutierten "Tool-Denkweise" zu tun.
Sheeva P. schrieb: > Schwachsinn. > [...] > > Schwachsinn. > [...] > > Schwachsinn. > [...] Man merkt: Hier schreibt der geborene Menschenfänger, der es schafft, Leser und Zuhörer auf seine Seite zu ziehen.
Walter T. schrieb: > Sheeva P. schrieb: >> Schwachsinn. >> [...] >> >> Schwachsinn. >> [...] >> >> Schwachsinn. >> [...] > > Man merkt: Hier schreibt der geborene Menschenfänger, der es schafft, > Leser und Zuhörer auf seine Seite zu ziehen. Ach, weißt Du, ich möchte gar kein "Menschenfänger" sein. Darüber hinaus bin ich nicht dafür verantwortlich, wenn jemand anders Schwachsinn schreibt, und obendrein habe ich meine Aussagen, im Gegensatz zum Vorredner, in der Sache begründet. Nach den weder sachlichen noch begründeten Pöbeleien ("primitiv", "saublöd", "scheisse") finde ich "Schwachsinn" aber geradezu diplomatisch.
Peter II ist so ein ganz besonderer Typ Mensch, welchen man manchmal begegnet. Ich habe nie die Motivation welche hinter diesem Verhalten steckt verstanden. @ Peter II, du musst doch auch Zugeben, das der Ansatz mit den einzelnen Programmen auch einen großen Vorteil hat, nämlich der, dass man diese auch einzeln nutzen kann und bei bedarf auch schnell, ohne das man Programierkentnisse braucht, für Komplexere Aufgaben verknüpfen kann, oder? Wenn man zuerst etwas mit einer Bib Programieren muss, und es dann sogar nur für eine einmalige Angelegenheit ist, hat man einfach zuviel Aufwand sich in die Programierung und API einzuarbeiten, oder?
peter 3 schrieb: > @ Peter II, du musst doch auch Zugeben, das der Ansatz mit den einzelnen > Programmen auch einen großen Vorteil hat, nämlich der, dass man diese > auch einzeln nutzen kann und bei bedarf auch schnell, ohne das man > Programierkentnisse braucht, für Komplexere Aufgaben verknüpfen kann, > oder? richtig. Aber man könnte auch zu jeder lib ein Konsolenprogramm dazu liefern. Dann kann man auch einfach ein GUI Programm ohne aufwand schreiben. man sollte eh Funktionalitätund frontend trennen.
Peter II schrieb: > genau das ist aber der Unterschied. Bibliotheken mit definierten APIs > aufzurufen ist nicht wirklich vergleichbar mit externe Programm starten. Busybox ruft ebenfalls in der Regel keine externen Programme auf -- und auch die Applets von Busybox und die externen Programme haben eine klar definierte Schnittstelle: zeilenorientierten Klartext, den jeder Laie ohne Probleme lesen und verstehen kann. Prima, nicht wahr? > nein, ist die die Denkweise das man möglichst viel Code wiederverwendet. Dazu gibt es Shared Libraries. > Dabei ist das Aufrufen von externen Programm eine extrem "primitive" > Version davon. Das mag zwar primitiv im Sinne von einfach, lesbar, und klar verständlich auch ohne Dokumentation sein. Aber ich halte das für einen großen Vorteil gegenüber einer Powershell, für deren Benutzung man zwingend auf die Dokumentation eines ultrafetten Frameworks wie .Net angewiesen ist. Vermutlich benutzt deswegen ein signifikanter Anteil der UNIX-Anwender gerne die Shell und nimmt ihr UNIX nicht zuletzt deswegen als besonders leistungsfähig, flexibel und mächtig wahr, während sich die Powershell unter Windows eher mäßiger Beliebtheit erfreut und Windows trotz nominell ähnlicher Möglichkeiten immer noch der Nimbus mangelhafter Flexibilität, Automatisierbarkeit und Mächtigkeit anhängt. > Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen. Die ist bei Kommandozeilenprogrammen sogar einfacher zu realisieren (siehe zum Beispiel apt-get(8) oder rpm(8)), weil diese Programme nicht nur über ihren Rückgabewert mit ihrem Aufrufer kommunizieren, sondern zusätzlich über die Standardein- und -ausgabekanäle STDIN, STDOUT, und STDERR. Eine Bibliotheksfunktion hingegen kommuniziert mit ihrem Aufrufer ohne zusätzliche Maßnahmen lediglich über ihren Rückgabewert. Wenn sie ihren Fortschritt an den Aufrufer zurück melden will, muß sie dies über die Modifikation einer Variablen tun, die sowohl dem Aufrufer als auch der Funktion bekannt ist. Unser Aufrufer muß wiederum den Variableninhalt periodisch auf Fortschritte überprüfen, was bedeutet, daß Funktion und Aufrufer mindestens in verschiedenen Prozessen, Threads, oder gar unter einem eigenen Scheduler laufen müssen.
Karl Käfer schrieb: > Eine Bibliotheksfunktion hingegen kommuniziert mit ihrem Aufrufer ohne > zusätzliche Maßnahmen lediglich über ihren Rückgabewert. Wenn sie ihren > Fortschritt an den Aufrufer zurück melden will, muß sie dies über die > Modifikation einer Variablen tun, die sowohl dem Aufrufer als auch der > Funktion bekannt ist. Unser Aufrufer muß wiederum den Variableninhalt > periodisch auf Fortschritte überprüfen, was bedeutet, daß Funktion und > Aufrufer mindestens in verschiedenen Prozessen, Threads, oder gar unter > einem eigenen Scheduler laufen müssen. Unsinn, es reicht einfach eine Callback festzulegen. Dafür braucht man keine Threads oder mehre Prozesse.
Peter II schrieb: > Nils S. schrieb: >> Der "find"-way, find zu benutzen und Dateien dabei zu löschen ist wohl >> eher: >>> find . -exec rm {} \; >> Ja - genau so mit der kruden Syntax. > > ja nur sau langsam. joo, aber man kann eine beliebige menge an dateien löschen.
Peter II schrieb: > Unsinn, es reicht einfach eine Callback festzulegen. Dann mußt Du Deine Callbackfunktion irgendwie übergeben, aber das ist viel komplizierter als den Fortschritt einfach auf STDOUT zu schreiben.
>viel komplizierter als den Fortschritt einfach auf STDOUT zu schreiben.
findest?
STDOUT ist doch "human readable" (für console gedacht)
jedes Programm macht das irgendwie anders..
das aufrufende Programm muss es mühsam Parsen
STDOUT wird u.u. schon für andere Ausgaben gebraucht (die Prozentangabe
müsste irgendwie hineinversteckt werden)
dagegen kannst (könnte man) einen callback für fortschritt ganz einfach,
für jede (ich nenn es mal) Modul einheitlich definieren..
(wie gut/schlecht das ganze funktioniert sieht man IMHO recht gut am
Webserver: CGI vs. "module")
:
Bearbeitet durch User
Karl Käfer schrieb: > Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: > find ist besonders gut darin, Dateien und Verzeichnisse zu finden und > was damit zu machen, während rm besonders gut darin ist, Dateien und > Verzeichnisse zu löschen. Da hättest Du mit ein bisschen Nachdenken aber > auch selbst drauf kommen können, wenn Du nicht krampfhaft damit > beschäftigt gewesen wärest, irgendwie einen Widerspruch zu konstruieren. Ah ja - und das soll tatsächlich BESSER sein, als alles andere? Fall 1: du suchst mit wildcards, also unvollständigem Dateinamen. Find findet da alles mögliche (logo) und rm putzt es von der Platte weg. Klasse. Hättest du als Benutzer des PC nicht vielleicht eher das Bedürfnis, vor dem gnadenlosen Löschen das Ganze erst noch mal in einer netten Listbox anzuschauen - vielleicht hast du dich in irgend einem Kringel geirrt und hättest bei dir selbst richtigen Schaden zugefügt. Also Listbox mit der Möglichkeit, das eine oder andere von der Liste lieber doch zu streichen. Das geht aber nur mit grafischer Oberfläche und nicht per Kommandozeile. Fall 2: du suchst mit qualifiziertem, also vollem Dateinamen. Wozu dann das find, wenn du es schon vorher weißt? Bloß um das Eintippen des Pfades zu vermeiden? Merkst du endlich was? Karl Käfer schrieb: > Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein > paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese > Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens > "Powershell" gegossen. Die Tool-Denkweise IST überholt. Genauso wie die Lehre von der scheibenförmigen Erde. Da hilft dir auch kein vehementes Pfeifen im Walde. So. Erstens ist für mich niemand heilig, weder du noch Microsoft noch der Papst oder sonstwer. Zweitens: Wer benutzt denn sowas wie Powershell? Ich kenne da niemanden, der sowas tut. Es hat auch noch nie viele Leute gegeben, die den Scripting-Host benutzt haben. Die Leute benutzen den Explorer und wer den nicht mag, nimmt den TC. Ja, das ist auch so ein mächtiges Werkzeug, was so überhaupt nicht eurer Denke entspricht. Drittens: Dieser ganze Thread ist ein etwa 10 jähriges deja vu. Auch damals haben Eiferer aus dem Linux-Lager zu jeder Gelegenheit die absolute Unübertrefflichkeit ihres BS betont und im selben Atemzug gegen Windows nebst Bill Gates sämtliche Flüche ausgestoßen, die ihnen einfielen. Und jetzt? - Windows ist immer noch der absolute Marktführer -ätsch. - Wenn überhaupt was anderes angedacht wird, kaufen sich die Leute einen Mac - nochmal ätsch. - Linux, FreeBSD und Konsorten machen zwar allzeit und überall einen Riesentraffic, aber die 5% Hürde haben sie noch lange nicht erklommen. "Bäsch gehabbd" sagt der Sachse dazu. Aber das stimmt nicht. Es war und ist kein Pech, sondern die schiere Dummheit, mit Fleiß sämtliche Bedürfnisse von etwaigen Kunden in den Wind zu schlagen, immer alles besser zu wissen und ein Loblied auf Kommandozeile, Skripte und Steinalt-Progrämmchen zu singen, wo der Rest der Welt es seit Windows 3.1 ganz anders haben will. Und wenn euch gar keine Argumente mehr einfallen, dann spielt ihr beleidigte Leberwurst. Wie kann man auch nur die veralteten Dinge beim Namen nennen. Als nächstes wird vielleicht TAR gelobt, weil man ja neuerdings nach unbestätigten Gerüchten gehört haben will, daß Bill Gates das papierene Lochband wieder aus der Versenkung holen will... W.S.
W.S. schrieb: > Hättest du als Benutzer des PC nicht vielleicht eher das Bedürfnis, vor > dem gnadenlosen Löschen das Ganze erst noch mal in einer netten Listbox > anzuschauen Wenn man das Bedürfnis hat, dann nimmst man ein Tool, welches einen dieses Bedürfnis ausleben lässt. Du tust ja gerade so, als würden alle Unixer noch vor VT100s sitzen und hätten noch nie sowas wie einen grafischen (oder textmäßigen, Norton-Commander-Clones stehen da bei vielen nicht nur Unixern nach wie vor hoch im Kurs) Dateimanager gesehen. Wenn ich aber nach einer Patchorgie alle Dateien, die auf *.orig oder *.rej lauten, löschen lassen will, dann bin ich mir auch mit dem Absenden des find-Kommandos bereits hinreichend sicher, dass ich das jetzt will. Dann brauch' ich nicht noch eine lästige Bestätigungsbox. Wenn ich temporäre Dateien nächtlich bereinigen lassen will, für die sich beispielsweise seit 30 Tagen kein Schwein mehr interessiert hat (die Suche nach Dateien, die eine bestimmte Zeit lang niemand mehr gelesen hat, ist eine der möglichen Optionen), meinst du ich möchte dann nachts um 3 Uhr aufstehen und einen „OK“-Button drücken? Aber genau für solche Fälle ist die -delete Option eben gut.
MoinMoin W.S. schrieb: > Es war und > ist kein Pech, sondern die schiere Dummheit, mit Fleiß sämtliche > Bedürfnisse von etwaigen Kunden in den Wind zu schlagen, immer alles > besser zu wissen und ein Loblied auf Kommandozeile, Skripte und > Steinalt-Progrämmchen zu singen, wo der Rest der Welt es seit Windows > 3.1 ganz anders haben will. Es kommt doch darauf an, welche Bedürfnisse der Benutzer hat! Wenn er der Meinung ist, so wie scheinbar auch du, alles schick bunt und mit Sicherheitsabfragen vorgesetzt zu bekommen, dann ist es gut und soll auch so sein. Für den sind die mächtigen Tools, wie du sie so vehement forderst, auch genau die richtigen. Dann muss man aber auch mit den Unzulänglichkeiten dieser Programme, die nur so gut sind, wie der Entwickler sie geplant und umgesetzt hat, leben. Wer aber Aufgaben auf seinem Rechner zu erledigen hat, die vielleicht nicht in das Schema solcher eierlegenden Wollmilchsäue passen, ist glücklich, wenn er ein Toolset zur Verfügung hat, mit dem er seine Abläufe nach seinem Anforderungen zusammenstellen kann. Das dies vielleicht mehr Aufwand bedeutet, ist unbestreitbar, aber in vielen Fällen die Beste und manchmal einzige Lösung, um eine Aufgabe effektiv und zielgerichtet zu erledigen. ...und die Geschichte ist kein Glaubenskrieg irgendwelcher Betriebssystemfanatikern, die angeblich noch immer vor ASCII-Terminals oder Fernschreibern sitzen, sondern nur einfach eine Möglichkeit, wie man mit einem Rechner arbeitet und arbeiten könnte. Ich bekenne mich auch zu dieser "5%-Minderheit", würde mir aber nie anmaßen, die anderen 95% als Unwissende (noch milde ausgedrückt, im Gegensatz zu dir) zu bezeichnen! Jeder benutzt seinen Rechner und Software, so wie er es möchte und kann. Nebenbei, das ist einer der Grundregeln Freier Software... W.S. schrieb: > Als nächstes wird vielleicht TAR gelobt, weil man ja > neuerdings nach unbestätigten Gerüchten gehört haben will, daß Bill > Gates das papierene Lochband wieder aus der Versenkung holen will... ...naja, den nächsten Streit fängst du gerade an, weil dir vielleicht die Argumente ausgehen. Aber um das qualifiziert zu machen, solltest du erst mal nachlesen, was tar eigentlich ist und kann. Den Zusammenhang zwischen Lochstreifen und tar kannte ich noch nicht, aber ich bin ja nicht allwissend...
:
Bearbeitet durch User
Hallo W.S. W.S. schrieb: > Es war und > ist kein Pech, sondern die schiere Dummheit, mit Fleiß sämtliche > Bedürfnisse von etwaigen Kunden in den Wind zu schlagen, Linux hat KEINE KUNDEN. Es wird rein für sich selber und für andere schräge Vögel, die genauso drauf sind, programmiert. Es ist für halt für Leute, die dem Mainstream nicht viel abgewinnen können, egal wie toll der auch sein mag. ;O) Nebenher: Wieso stört es Dich eigentlich, wenn Leute ihren eigenen Kram machen, wenn er Dich eh nicht interessiert, und der sowieso nach Deiner Ansicht gesellschaftlich irrelevant ist? > immer alles > besser zu wissen und ein Loblied auf Kommandozeile, Skripte und > Steinalt-Progrämmchen zu singen, wo der Rest der Welt es seit Windows > 3.1 ganz anders haben will. Es ist eher selten, dass ich privat bei Linux eine Kommandozeile verwende. Auf der Arbeit mit Windows aber recht häufig. Soviel also zu Deinem Bezug zur Realität. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
das ist ungefähr so wie der Vergleich von Playmobil zu Lego ;)
W.S. schrieb: > Wer benutzt denn sowas wie Powershell? Ich kenne da niemanden, > der sowas tut. Mit dieser Aussage zeigst Du, daß du in der Welt der integrierten, grafischen Werkzeuge zuhause bist. Oder kurz: daß Deine Computernutzung in eine Richtung geht, in der die Frage nach der Modularität von Konsolenwerkzeugen für eine Aufgabe völlig irrelevant ist. Warum willst Du dann unbedingt mitdiskutieren? Warum läßt Du nicht einfach die Kommandozeile und die Leute, die gerne damit arbeiten, in Ruhe? Wir lassen im Gegenzug auch die Leute, die im Jahr 2015 immer noch einen Norton-Commander-Klon benutzen in Ruhe. (Und das fällt mir auch nicht immer leicht.)
:
Bearbeitet durch User
W.S. schrieb: > Karl Käfer schrieb: >> Insofern widerspricht "find -delete" der UNIX-Philosophie keineswegs: >> find ist besonders gut darin, Dateien und Verzeichnisse zu finden und >> was damit zu machen, während rm besonders gut darin ist, Dateien und >> Verzeichnisse zu löschen. Da hättest Du mit ein bisschen Nachdenken aber >> auch selbst drauf kommen können, wenn Du nicht krampfhaft damit >> beschäftigt gewesen wärest, irgendwie einen Widerspruch zu konstruieren. > > Ah ja - und das soll tatsächlich BESSER sein, als alles andere? Ja, das ist es -- weil ich die Dateien und Verzeichnisse nicht nur finden, sondern auch gleich be- und verarbeiten kann. > Fall 1: du suchst mit wildcards, also unvollständigem Dateinamen. Find > findet da alles mögliche (logo) und rm putzt es von der Platte weg. > Klasse. Hättest du als Benutzer des PC nicht vielleicht eher das > Bedürfnis, vor dem gnadenlosen Löschen das Ganze erst noch mal in einer > netten Listbox anzuschauen - vielleicht hast du dich in irgend einem > Kringel geirrt und hättest bei dir selbst richtigen Schaden zugefügt. > Also Listbox mit der Möglichkeit, das eine oder andere von der Liste > lieber doch zu streichen. Das geht aber nur mit grafischer Oberfläche > und nicht per Kommandozeile. Selbstverständlich geht das auch auf der Kommandozeile: da rufe ich find einmal mit meinem Suchmuster ohne "-delete" auf, schon habe ich meine Liste. Ich persönlich bevorzuge allerdings die Lösung mit "-exec rm {} +": die ist fast genau so schnell wie "-delete", aber besser steuerbar. > Fall 2: du suchst mit qualifiziertem, also vollem Dateinamen. Wozu dann > das find, wenn du es schon vorher weißt? Bloß um das Eintippen des > Pfades zu vermeiden? Hin und wieder kommt es vor, daß ich zwar den Dateinamen weiß, aber nicht mehr, wo (Pfad) ich die Datei abgelegt habe. Das ist natürlich mein ganz eigenes Organisationsproblem, ändert aber nichts daran, daß ich dank find eine exrem effiziente Möglichkeit habe, mit dem Problem umzugehen. > Merkst du endlich was? Es bist Du, der nichts merkt und keine Ahnung hat, wovon der redet. Ich arbeite täglich mit der Kommandozeile und weiß deswegen sehr genau, wie effizient, flexibel und schnell das ist. > Karl Käfer schrieb: >> Die Tool-Denkweise ist keineswegs überholt, im Gegenteil: erst vor ein >> paar Jahren hat sogar Dein heiliges Microsoft höchstselbst diese >> Denkweise wieder aus der Versenkung geholt, und in ein Konzept namens >> "Powershell" gegossen. > > Die Tool-Denkweise IST überholt. Genauso wie die Lehre von der > scheibenförmigen Erde. Da hilft dir auch kein vehementes Pfeifen im > Walde. Hört sich für mich so an, als ob Du eigentlich nur neidisch auf die Leute bist, die die Flexibilität und Effizienz der Kommandozeile nutzen können. In so einem Fall hat man zwei Möglichkeiten: die Intelligenten lernen, wie das geht, und die anderen starten einen Kreuzzug, um sich wenigstens noch selbst einreden zu können, sie seien der Held. :-) > Zweitens: Wer benutzt denn sowas wie Powershell? Ich kenne da niemanden, > der sowas tut. Ich kenne einen Exchange-Spezialisten, der die Powershell benutzt, aber der ist auch der Einzige. Und ja, die Powershell wird selten benutzt, weil sie eben keine klar verständliche Plaintext-Schnittstelle benutzt, sondern .NET-Objekte, so daß jeder, der sie benutzen will, dazu zwingend solide .NET-Kenntnisse benötigt. Aber wer ohnehin .NET kennt, nimmt vermutlich lieber VB(A) und Co. Trotzdem ändert das nichts daran, daß alle modernen Betriebssysteme eine leistungsfähige Kommandozeilenumgebung haben, weil deren Hersteller im Gegensatz zu Dir erkannt haben, was für eine leistungsfähige, flexible, moderne und effiziente Möglichkeit zur Bedienung und Steuerung eines Computers das ist. Ob Du das verstehen willst oder nicht, ist dabei vor allem Eines: nämlich vollkommen nebensächlich. > Es hat auch noch nie viele Leute gegeben, die den > Scripting-Host benutzt haben. Die Leute benutzen den Explorer und wer > den nicht mag, nimmt den TC. Ja, das ist auch so ein mächtiges Werkzeug, > was so überhaupt nicht eurer Denke entspricht. Ach Gottchen, ja, der Explorer. Solche Dateimanager gibt es -- in deutlich leistungsfähigeren Versionen -- natürlich auch unter Linux, und für Leute, die mit Kommandozeilen überfordert sind, sind sie eine prima Sache. Aber wer die Kommandozeile beherrscht, kann damit Sachen machen, bei denen die GUI-Benutzer nur noch mit den Ohren schlackern und sich mit ihren dummen grafischen Werkzeugen buchstäblich zu Tode klicken.
Sheeva P. schrieb: > für Leute, die mit Kommandozeilen überfordert sind, sind sie eine prima > Sache. Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden, der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Und nutzt Du echt Lynx, um im Internet zu surfen? Achwas... echte Männer surfen mit "wget". Es gibt Aufgaben, für die GUIs besser geeignet sind. Es gibt Aufgaben, für die Kommandozeilenwerkzeuge besser geeignet sind. Und deswegen nutzt man einfach beide.
Walter T. schrieb: > Achwas... echte Männer surfen mit "wget". Nö, mit "telnet" und "script" (damit die Daten auch gespeichert werden ;).
1 | $ telnet www.mikrocontroller.net http |
2 | Trying 188.40.52.210... |
3 | Connected to www.mikrocontroller.net. |
4 | Escape character is '^]'. |
5 | GET /user/show/nicolas HTTP/1.1 |
6 | Host: www.mikrocontroller.net |
7 | |
8 | HTTP/1.1 200 OK |
9 | Server: nginx/1.6.2 |
10 | Date: Fri, 06 Nov 2015 09:07:30 GMT |
11 | Content-Type: text/html; charset=utf-8 |
12 | Transfer-Encoding: chunked |
13 | Connection: keep-alive |
14 | Vary: Accept-Encoding |
15 | Status: 200 OK |
16 | X-Frame-Options: SAMEORIGIN |
17 | X-XSS-Protection: 1; mode=block |
18 | X-Content-Type-Options: nosniff |
19 | Cache-Control: private |
20 | Vary: Cookie |
21 | ETag: W/"a89c830e807670cd200fdc8b762194dc" |
22 | Set-Cookie: _forum_session=Y3BmSjJMY0RqTmg3SjFWYzRpMWZvSXFMVTlweGl1WUdzV0NTOGZEa2xuK2V5ZktveGN3bWdvejQ3TmtHclVEa0JyVU8wTnNHSUsxcG9jOXp6d3Mzc0lnTTVHb2dwTEdRWld6aXg2OSs4VFlhYUhqcDNXUU9ZWjUyWXlObmM2cXk3QVhFZHBiZmF6RVY0d0paaWNHdnplRVRjaldudHVBZjl1ZC9wWUZWb2lGdkd2ZXk4SDlsN0NQa0gvVTJ3Z0RjLS1iYUs3L1FlWTBOTnJFZ2VpV1RmYkxRPT0%3D--2e3a091170a9a14b39453c0022adc5fcfc22a139; path=/; expires=Mon, 16 Nov 2015 09:07:30 -0000; HttpOnly |
23 | X-Request-Id: 6051532d-6e40-4a0f-856f-3e464f97bec8 |
24 | X-Runtime: 0.061774 |
25 | Alternate-Protocol: 443:npn-spdy/3 |
26 | |
27 | 3096 |
28 | <!DOCTYPE html>
|
29 | <html lang="de" dir="ltr"> |
30 | <head>
|
31 | <title>
|
32 | User information - Mikrocontroller.net |
33 | </title>
|
34 | <meta http-equiv="Content-type" content="text/html; charset=utf-8" /> |
35 | … |
Peter II schrieb: > Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen. Was interessiert mich eine Fortschrittsanzeige in einem Cron-Job, der nachts um ein Uhr läuft, wo ich schlafe? Soll mir der Fortschrittsbalken dann per Mail zugeschickt werden oder was? Merke: Es gibt sinnvolle Aufgaben für die Kommandozeile, nämlich nicht-interaktive (oder wenig interaktive) Programme. Das macht man besser mit der Shell. Genau aus diesem Grunde verwendest Du auch Linux-*Server* (oder habe ich mich da verlesen?), denn Server interagieren ziemlich wenig mit dem Otto-Normal-User. Das machen ausgelagerte Programme wie Web-Browser, File-Manager oder andere Programme, die auf dem Client-System laufen. Man braucht auch in der Regel kein Word oder Excel auf einem "Server". Es gibt sicher sinnvolle Aufgaben, die man besser mit einer graphischen Benutzeroberfläche löst. Das ist aber in den wenigsten Fällen ein Klicki-Bunti-Programm, dem ich sage: Lösche mir ab einem bestimmten Ast im Dateibaum alle *.BAK-Dateien. Daher sehe ich das so: Für jede Aufgabe das geeignete System. Von "antiquierter" Kommandozeile zu sprechen zeugt lediglich von stark beschränkter Sicht.
:
Bearbeitet durch Moderator
jetzt hat nur blöderweise "Kommandozeile vs. GUI" nichts mit der Frage zu tun hat.. (soll ein Ding nur eine Aufgabe können) gibt ja auch Kommandozeilenprogramme die 20 Seiten ausspucken wenn man --help anfügt: da kann dann von "EINER" aufgabe nicht mehr wirklich die rede sein (egal ob jetzt linux oder windows) andererseits gibt auch GUI-Programme die "wiederkehrende Aufgaben" wesentlich besser erstellen (und vorallem debuggen) lassen, als das mit script-sch.. je möglich wäre.. z.b. www.finalbuilder.com
Walter T. schrieb: > Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden, > der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Und > nutzt Du echt Lynx, um im Internet zu surfen? Achwas... echte Männer > surfen mit "wget". Wir sind da schon etwas weiter und benutzen w3m. ;-)
Robert L. schrieb: > gibt ja auch Kommandozeilenprogramme die 20 Seiten ausspucken wenn man > --help anfügt: da kann dann von "EINER" aufgabe nicht mehr wirklich die > rede sein (egal ob jetzt linux oder windows) Manche Kommandozeilenprogramme erledigen eben sehr komplizierte Aufgaben. > andererseits gibt auch GUI-Programme die "wiederkehrende Aufgaben" > wesentlich besser erstellen (und vorallem debuggen) lassen, als das mit > script-sch.. je möglich wäre.. > > z.b. www.finalbuilder.com Wie lustig. Was genau soll dieses klickibunte Machwerk denn bitte besser können als die herkömmlichen Build-Werkzeuge? Wenn ich da nur mal auf die Screenshots schaue... da lob' ich mir GNU Make.
Frank M. schrieb: > Peter II schrieb: >> Es gibt z.b. keine einfache Möglichkeit den Fortschritt anzuzeigen. > > Was interessiert mich eine Fortschrittsanzeige in einem Cron-Job, der > nachts um ein Uhr läuft, wo ich schlafe? > > Soll mir der Fortschrittsbalken dann per Mail zugeschickt werden oder > was? ;-) Zumal der Fortschrittsbalken ja ohnehin häufig nur Unsinn anzeigt. Unter Windows kenne ich das Verhalten, daß der Balken erst zügig bis ca. n% fortschreitet, dann ewig dort hängenbleibt und schließlich ganz schnell auf 100% springt. Was für einen Informationswert soll so eine eindeutig fehlerhaften, irreführenden Anzeige denn haben? Auch bei Dateisystemoperationen sind Fortschrittsbalken unsinnig, weil unter dem Dateisystem ein Dateisystempuffer und ein Journal liegen, deren Zustände sich nicht abfragen lassen. Dabei zeigt der Fortschrittsbalken an, daß die Dateisystemoperation beendet sei, tatsächlich sind die Daten aber gerade nur im Puffer angekommen und müssen jetzt erstmal ins Journal geschrieben und dann ins eigentliche Dateisystem übertragen werden. Dabei zeigt Peter II's toller Fortschrittsbalken an, die Operation sei bereits beendet, aber in Wahrheit werden die Daten erst beim "sicheren Aushängen" des USB-Sticks auf denselben geschrieben.
Karl Käfer schrieb: > Zumal der Fortschrittsbalken ja ohnehin häufig nur Unsinn anzeigt. scheinbar kennst du den Unterschied nicht mal zwischen einen Fortschrittsbalken und einer geschätzten Laufzeit.
Karl Käfer schrieb: > Walter T. schrieb: >> Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden, >> der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Und >> nutzt Du echt Lynx, um im Internet zu surfen? Achwas... echte Männer >> surfen mit "wget". > > Wir sind da schon etwas weiter und benutzen w3m. ;-) Ich bin auch für wget, manchmal villeicht noch curl, telnet und links. links ist der einzige mir bekannte Browser, der die Testseite http://danielabrecht.ch:8080/ korrekt verarbeitet. wget macht auch keine Probleme, aber w3m sagt mir nur "gzip: stdin: not in gzip format"
Karl Käfer schrieb: > Wie lustig. Was genau soll dieses klickibunte Machwerk denn bitte besser > können als die herkömmlichen Build-Werkzeuge? die Frage muss lauten: was kann der "Enduser" mit dem Werkzeug besser machen und da sind GUIs eben doch (viel) selbsterklärender ... wenn du jemanden der das noch nie gemacht hat, beide "Werkzeuge" in die Hand drückst, wird er nach 3 Stunden mit GNU Make genau garnix gemacht haben.. (obwohl es theoretisch irgendwie gehen würde) mit dem "klickibunti" wird er e-mails versenden können, cd-brennen, ftp-uploads machen, regitry einträge ändern, zip-files erstellen, etwas in einem xmlfile ändern, usw. usw und ja, auch eine Compiler aufrufen oder ein help-filer erstellen lassen... (https://www.finalbuilder.com/finalbuilder/feature-matrix) OHEN auch nur ansatzweise im Detail wissen zu müssen wie es im funktioniert (das ganze mit oder ohne userinteraktion, je nach aufgabe) bei gnu make müsste er sich für jedes Programm erstmal ewig einlesen..
Robert L. schrieb: > Karl Käfer schrieb: >> Wie lustig. Was genau soll dieses klickibunte Machwerk denn bitte besser >> können als die herkömmlichen Build-Werkzeuge? > > die Frage muss lauten: was kann der "Enduser" mit dem Werkzeug besser > machen Wir reden hier von einem Build-Werkzeug. Sowas wird üblicherweise nicht von Entenbenutzern benutzt, sondern von Entwicklern. > und da sind GUIs eben doch (viel) selbsterklärender ... Wenn ich mir die Screenshots so anschaue, halte ich das für ein Gerücht. Dieses heillose Chaos aus tausend verschiedenen Eingabemasken ist nicht übersichtlicher als ein dokumentiertes und strukturiertes Makefile. > wenn du jemanden der das noch nie gemacht hat, beide "Werkzeuge" in die > Hand drückst, wird er nach 3 Stunden mit GNU Make genau garnix gemacht > haben.. (obwohl es theoretisch irgendwie gehen würde) Das wage ich zu bezweifeln: alleine die ausufernde Vielfalt von Optionen und Screens (siehe Screenshots) setzen auch bei dem Klickibuntidings eine ziemliche Einarbeitungszeit voraus. Vielleicht kann man damit schon nach drei Stunden ein paar ganz einfache Sachen machen, zum Beispiel ein "Hello World"-Programm übersetzen, aber sowas Einfaches bekommt man mit GNU Make sicher mindestens genauso schnell hin -- sogar ohne ein Makefile schreiben zu müssen, am Rande bemerkt.
Daniel A. schrieb: > Karl Käfer schrieb: >> Walter T. schrieb: >>> echte Männer surfen mit "wget". >> >> Wir sind da schon etwas weiter und benutzen w3m. ;-) > > Ich bin auch für wget, manchmal villeicht noch curl, telnet und links. > > links ist der einzige mir bekannte Browser, der die Testseite > http://danielabrecht.ch:8080/ korrekt verarbeitet. wget macht auch keine > Probleme, aber w3m sagt mir nur "gzip: stdin: not in gzip format" Bei w3m unter Ubuntu 15.10 kommt: "abc test" (genauso übrigens wie bei "GET http://danielabrecht.ch:8080/ | gunzip"). Das ist korrekt, oder?
Robert L. schrieb: > und da sind GUIs eben doch (viel) selbsterklärender ... > > wenn du jemanden der das noch nie gemacht hat, beide "Werkzeuge" in die > Hand drückst, wird er nach 3 Stunden mit GNU Make genau garnix gemacht > haben.. (obwohl es theoretisch irgendwie gehen würde) > > mit dem "klickibunti" wird er e-mails versenden können, cd-brennen, > ftp-uploads machen, regitry einträge ändern, zip-files erstellen, etwas > in einem xmlfile ändern, usw. usw und ja, auch eine Compiler aufrufen > oder ein help-filer erstellen lassen... Diese annahme ist schlicht falsch! Du gehst davon aus, der angenomme User hat schon irgendwann mal mit einem Computer was zu tun gehabt und weiß wie eine GUI aussieht... Nimm für deinen Test einen Nutzer der noch nie was mit einem Computer zu tun gehabt hat (das beinhaltet auch smartphones, handys, etc.), einen, der das wort nicht kennt, und auch technisch keine ahnung hat, was das sein könnte. Dieser Nutzer wird nach 3 Stunden mit sicherheit keine cd brennen können, keine e-mail schreiben können, keine ftp-uploads machen können... der wird nach 3 stunden exakt gar nichts machen können. GUIs sind für uns halbwegs selbsterklärend, weil wir die scheiße schon jahre lang nutzen, und eingetrichtert bekommen: Das ist so, das muss so, das war schon immer so, das wird immer so sein. Nur und ausschließlich deswegen würde ein 'normaler' nutzer nach 3 stunden mit der GUI irgendwas auf die reihe bekommen.
Karl Käfer schrieb: > Bei w3m unter Ubuntu 15.10 kommt: "abc test" (genauso übrigens wie bei > "GET http://danielabrecht.ch:8080/ | gunzip"). Das ist korrekt, oder? Ja, Welche w3m Version war das? Ich hatte es mit w3m/0.5.3+debian-19 unter debian jessie versucht.
Walter T. schrieb: > Sheeva P. schrieb: >> für Leute, die mit Kommandozeilen überfordert sind, sind sie eine prima >> Sache. > > Diesmal hat der Unsinn ein umgekehrtes Vorzeichen. Ich kenne niemanden, > der seine Fotos (ausschließlich) mit der Kommandozeile sortiert. Das ist einer von den Fällen, in denen ein GUI enorm nützlich sein kann, aber dabei geht es eher um das Management von Inhalten. Doch die meisten Aufgaben im Dateimanagement können immer noch sehr bequem und effizient auf der Kommandozeile erledigt werden. Das hängt natürlich auch davon ab, welche Dateiformate genutzt werden. Ein Entwickler, der hauptsächlich mit Quelltexten arbeitet, hat daher mehr von einer Kommandozeile als ein Grafikdesigner, Videobearbeiter oder jene, die schon einfache Notizen in Binärformaten speichern... > Es gibt Aufgaben, für die GUIs besser geeignet sind. Das hat niemand bezweifelt, ... > Es gibt Aufgaben, für die Kommandozeilenwerkzeuge besser geeignet sind. ...jenes hingegen schon. > Und deswegen nutzt man einfach beide. Die Mehrheit der Computerbenutzer tut das eben nicht -- auf der einen Seite, weil Leute wie Peter II und W.S. ihnen einreden, daß das ganz schrecklich kompliziert und total antiquiert sei, und auf der anderen Seite, weil mit dem weitestverbreiteten Betriebssystem ausgelieferten Kommandozeilenwerkzeuge entweder unkomfortabel und wenig leistungsfähig sind, oder weil sie nur mit Programmierkenntnissen des .NET-Framework effektiv benutzt werden können.
> In der GNU-Philosophie heißt es: > "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." Der Gründer des GNU-Projektes, Richard Stallman, hält sich mit seinem Emacs selbst nicht daran. Emacs kann man auch als Editor verwenden. Zum Kaffeekochen allerdings noch nicht. > Mit dem tollen Nebeneffekt dass es dann > sehr (wenn auch leider nicht 100%) Plattform unabhängig wird. Das interessiert heute doch leider nur noch wenige. Die meisten Firmen hätten lieber ihre proprietäre Insellösung um sich von der Konkurrenz abzuheben. Aufs iPhone kann man seine mp3s nur mit einem Spezialprogramm laden. Es wäre zu einfach und zu Plattformunabhängig, wenn das so einfach wie mit einem USB-Stick ginge. Und Microsoft hätte gern ihre eigene HTML-Version, eigene Dateiformate sowieso. Das nur als Beispiel.
Dirk schrieb: >> In der GNU-Philosophie heißt es: >> "Schreibe ein Programm, dass genau eine Aufgabe erfüllt, und diese gut." > > Der Gründer des GNU-Projektes, Richard Stallman, hält sich mit seinem > Emacs selbst nicht daran. Emacs kann man auch als Editor verwenden. Eigentlich hält sich RMS sehr wohl an die UNIX-Philosophie: Emacs ist ein erweiterbarer Editor. Daß es Leute gegeben hat, die alle möglichen und unmöglichen Erweiterungen dafür gestrickt haben, von denen manche nicht unbedingt zu den Kernaufgaben eines Editors und / oder einer IDE gehören, widerspricht dem prinzipiell nicht. > Zum Kaffeekochen allerdings noch nicht. Aber natürlich kann er das: http://www.emacswiki.org/emacs/CoffeeMode
Karl Käfer schrieb: > Trotzdem ist "find" zunächst nur ein Programm, um Dateien und > Verzeichnisse zu finden. Wenn es mit den gefundenen Dateien und > Verzeichnissen nichts tun kann, wäre das Programm als solches ziemlich > sinnlos, oder? Deswegen kann es mit -exec ein externes Programm mit dem > Gefundenen aufrufen, mit -print und -print0 das Gefundene ausgeben, oder > es mit -delete eben auch löschen. Dabei ist -delete nur ein Shortcut für > "-exec rm {} \;" mit dem zusätzlichen Vorteil, daß nicht für jede > gefundene Datei eigens ein fork() und exec() zum Starten von /bin/rm > ausgeführt werden muß. (Ja, neuere Versionen von find können an dieser > Stelle "-exec rm {} +" benutzen, aber das ist hier nicht der Punkt.) Besser: find . -print0 -name 'foo' | xargs -0 rm Und wenn mehrere rm gleichzeitig laufen sollen: find . -print0 -name 'foo' | xargs -P <jobs> -n <max_per_job> -0 rm Das ist damit gemeint.
CQ_One schrieb: > Nimm für deinen Test einen Nutzer der noch nie was mit einem Computer > zu tun gehabt hat (das beinhaltet auch smartphones, handys, etc.), > einen, der das wort nicht kennt, und auch technisch keine ahnung hat, > was das sein könnte. Dieser Fall ist nicht der Maßstab für Alles, oder warum macht man Platinenlayouts nicht mit einem Malprogramm?
W.S. schrieb: > Fall 1: du suchst mit wildcards, also unvollständigem Dateinamen. Find > findet da alles mögliche (logo) und rm putzt es von der Platte weg. > Klasse. Hättest du als Benutzer des PC nicht vielleicht eher das > Bedürfnis, vor dem gnadenlosen Löschen das Ganze erst noch mal in einer > netten Listbox anzuschauen - vielleicht hast du dich in irgend einem > Kringel geirrt und hättest bei dir selbst richtigen Schaden zugefügt. > Also Listbox mit der Möglichkeit, das eine oder andere von der Liste > lieber doch zu streichen. Das geht aber nur mit grafischer Oberfläche > und nicht per Kommandozeile. find kann mehr als löschen.
Tunix schrieb: > Karl Käfer schrieb: >> Trotzdem ist "find" zunächst nur ein Programm, um Dateien und >> Verzeichnisse zu finden. Wenn es mit den gefundenen Dateien und >> Verzeichnissen nichts tun kann, wäre das Programm als solches ziemlich >> sinnlos, oder? Deswegen kann es mit -exec ein externes Programm mit dem >> Gefundenen aufrufen, mit -print und -print0 das Gefundene ausgeben, oder >> es mit -delete eben auch löschen. Dabei ist -delete nur ein Shortcut für >> "-exec rm {} \;" mit dem zusätzlichen Vorteil, daß nicht für jede >> gefundene Datei eigens ein fork() und exec() zum Starten von /bin/rm >> ausgeführt werden muß. (Ja, neuere Versionen von find können an dieser >> Stelle "-exec rm {} +" benutzen, aber das ist hier nicht der Punkt.) > > Besser: > > find . -print0 -name 'foo' | xargs -0 rm "find . -print0 -name 'foo' -exec rm {} +" macht ziemlich genau dasselbe. > Und wenn mehrere rm gleichzeitig laufen sollen: > > find . -print0 -name 'foo' | xargs -P <jobs> -n <max_per_job> -0 rm Gute Idee... Aber wenn ich mal so viele Dateien löschen müssen, daß sich eine Parallelisierung lohnen würde, habe ich schon vorher einen Fehler gemacht, fürchte ich. ;-)
Sheeva P. schrieb: >> Und deswegen nutzt man einfach beide. > > Die Mehrheit der Computerbenutzer tut das eben nicht -- auf der einen > Seite, weil Leute wie Peter II und W.S. ihnen einreden, daß das ganz > schrecklich kompliziert und total antiquiert sei, Gröhl... Junge, den Leuten braucht man garnix einzureden, denn sie haben schon lange mit den Füßen abgestimmt. Erzähl mal deiner Tochter, daß sie ihre email oder mms per Kommandozeile abschicken soll - sie wird dich schlichtweg auslachen. Nee, hier greinen Außenseiter vor sich hin. Leute, die schon längst auf dem Abstellgleis gelandet sind und die vehement versuchen, sich das auch noch schönzureden. Ich hab da mal einen kleinen Vergleich zur Hand: Anno 1994 war das: Da haben extrem von sich selbst überzeugte OS/2 Leute eine ziemlich ähnliche Diskussion geführt. Alles was außerhalb von OS/2 war, wurde als unqualifiziert und lächerlich bezeichnet. Selbst von herzlich unqualifizierten Vergleichen schreckten diese Knaller nicht zurück - und hier kommt das Beispiel: Da schrieb einer, daß alle, die auf Windows setzen, doch vergleichbar seien mit Leuten die aus dem 1. Gang ihres Autos nicht herauskämen. Nun, auf sowas antwortete unsereiner, daß ich bei meinem Auto nur 2 und 3 kenne, aber normalerweise nur D nehme und daß das Auto damit weitaus besser fährt als mit dem 1. Gang. Kapiert haben diese Trottel es aber nicht. So, nun faßt euch an eure jeweiligen Nasen. W.S.
An die Nase fassen wäre eine Aufgabe. An die Nase fassen, sich dabei gleichzeitig den Kopf kratzen, Hänschen Klein sächsisch singen (alternativ pfeifen) und mit den Augen eine virtuelle (etwa doppelt Carrerabahn groß) Acht verfolgen und mit dem linken Fuß in etwa nach Süden zeigen, mit dem rechten Fuß in etwa nach Norden, wäre irgendwie...
W.S. schrieb: > Gröhl... > > Junge, den Leuten braucht man garnix einzureden, denn sie haben schon > lange mit den Füßen abgestimmt. Erzähl mal deiner Tochter, daß sie ihre > email oder mms per Kommandozeile abschicken soll - sie wird dich > schlichtweg auslachen. Es ist Samstagnacht, da fällt es zum Glück nicht so auf, wenn du herumgröhlst :) Falls du trotzdem noch einigermaßen aufnahmebereit bist, lass dir gesagt sein, dass es Leute gibt, die einen Computer nicht ausschließlich für E-Mail, Word und Internet-Surfen einsetzen. Ursprünglich wurden Computer ja dazu erfunden, um benutzerdefinierte, häufig wiederkehrende Abläufe automatisch abzuarbeiten. Und genau für diese Sorte von Anwendungen stellt die Unix-Philosophie eine große Hilfe dar, da damit das Rad nicht immer wieder neu erfunden werden muss. Und diese Anwendungen gibt es auch heute mehr denn je, nur vielleicht nicht bei dir. Mittlerweile wird der Computer aber zusätzlich auch für interaktive Anwendungen genutzt, wo ein Großteil der Arbeit nicht vom Computer, sondern vom Benutzer gemacht werden muss, weil bspw. dessen Erfahrung oder Kreativität gefordert sind. Zu diesen Anwendungen zählen u.a. Textverarbeitungs- , Mal- und CAD-Programme. Da diese Programme i.Allg. immer als Ganzes benötigt werden, ist es hier wenig sinnvoll, sie in Einzelwerkzeuge aufzuteilen. Da hast du völlig recht. Für diese interaktiven Anwendungen hat sich aber ein anderer Trend durchgesetzt, der ebenfalls aus dem Unix-Umfeld kommt: Skripting. Die besseren dieser Programme (und sogar Word und Excel) verfügen praktisch alle über einen Interpreter für eine Skriptsprache, mit der innerhalb der Anwendung Abläufe automatisiert werden können. Und für die einzelnen Funktionen, die der Interpreter zur Verfügung stellt, gilt wiederum: Jede Funktion sollte eine einzelne, klar abgegrenzte Aufgabe erfüllen. Ein VBA-Skript in Word oder ein ULP in Eagle unterscheidet sich vom Prinzip her kaum von einem Shell-Skript, nur die Syntax und die Basisfunktionen sind anders. Man hat hier also die Unix-Philosophie von der Betriebssystemsebene (wo sie nach wie vor gültig ist) in die Anwendungsebene übertragen. Auch in der Anwendungsebene gilt: Nicht jeder braucht diese Möglichkeit der Automatisierung, es gibt aber welche, die damit sehr viele Stunden ihrer wertvollen Arbeitszeit einsparen können. Und genau dafür sind Computer gemacht: um Zeit zu sparen.
:
Bearbeitet durch Moderator
> Die Mehrheit der Computerbenutzer
Die Mehrheit der Computerbenutzer benutzt den Computer nur sehr
ineffizient und viele Dinge die theoretisch der Computer für sie
erledigen könnte tun sie lieber von Hand weil sie nicht nicht wissen wie
sie dem Computer überhaupt mitteilen könnten was sie erledigt haben
wollen.
Das liegt daran daß ihr Dialog mit der Maschine, bzw die Sprache in der
er geführt wird, nur aus Zeigen und Klicken besteht. Deshalb können sie
nur vorgefertigte Vorgänge auslösen. Deshalb sind sie für jede einzelne
neue Aufgabe die sie erledigt haben wollen entweder darauf angewiesen
sich von der kleinen Minderheit der Computerprogrammierer ein neues
Programm (Äpp) mit neuen Buttons und Menüs anfertigen zu lassen auf die
sie klicken können, oder sie verzichten schlichtweg darauf und erledigen
die Aufgabe von Hand.
Die Minderheit der Computerprogrammierer jedoch beherrscht den Dialog
mit der Maschine über Sprachen und Kommunikationskanäle die weit über
Zeigen und Klicken hinausgehen, sie sind in der Lage neue
Aufgabenstellungen so zu formulieren daß der Computer sie versteht und
ausführen kann, das nutzen sie dann entweder für ihre eigenen Zwecke
oder sie verpacken es in einer "Äpp" und verkaufen es dem
Computerbenutzer, auf daß er drauf klicken möge.
So war das schon immer, so wirds auch immer bleiben.
Und nichts davon ist antiquiert. Ohne die kleine Gruppe der
Programmierer die den reichhaltigen schriftlichen Dialog mit der
Maschine nutzen weil mit der Babysprache allein (Zeigen auf Bilder und
"dada" sagen (Mausklick)) einfach keine neuen Ideen oder komplexe
Anweisungen vermittelt werden können, ohne diese kleine Gruppe von
Leuten die mit dem Gerät wirklich in ganzen Sätzen mit Punkt und Komma
sprechen können (und dafür gerne dieses kleine schwarze Chat-Fenster
nehmen) hätte die große Gruppe der Anwender überhaupt nichts worauf sie
klicken könnten.
W.S. schrieb: > Gröhl... > > Junge, den Leuten braucht man garnix einzureden, denn sie haben schon > lange mit den Füßen abgestimmt. Erzähl mal deiner Tochter, daß sie ihre > email oder mms per Kommandozeile abschicken soll - sie wird dich > schlichtweg auslachen. > > Nee, hier greinen Außenseiter vor sich hin. Leute, die schon längst auf > dem Abstellgleis gelandet sind und die vehement versuchen, sich das auch > noch schönzureden. YMMD.
Yalu X. schrieb: > Mittlerweile wird der Computer aber zusätzlich auch für interaktive > Anwendungen genutzt, wo ein Großteil der Arbeit nicht vom Computer, > sondern vom Benutzer gemacht werden muss, weil Korrigiere bitte mal dein verzerrtes Weltbild. Heutzutage sind die von dir genannten interaktiven Anwendungen der Haupteinsatzbereich und nicht nur "zusätzlich". Nahezu jeder Mitarbeiter (auch die meisten Bildungsfernen) haben heutzutage Zugriff auf solche interaktiven Anwendungen. Damit meine ich nicht nur die reinen Bürokräfte (die anzahlmäßig in den meisten Firmen die Mehrheit bilden) wo jeder seinen Windows-PC hat. Dazu zählt der Produktionshelfer genauso wie der Ingenieur, der mit einer grafischen IDE programmiert. Dazu kommt noch die große Anzahl der embedded Systems in Maschinen, die der Anwender nicht sieht und die er auch nicht direkt bedient. Auf die trifft deine Aussage eher zu. Aber die werden nur von den jeweiligen Spezialisten programmiert und konfiguriert. Der Maschinenbediener bekommt davon nichts mit. Für ihn gibt es eine intuitive interaktive Benutzerschnittstelle mit vom Entwickler vorgegebener Features.
Bernd K. schrieb: > Die Mehrheit der Computerbenutzer benutzt den Computer nur sehr > ineffizient und viele Dinge die theoretisch der Computer für sie > erledigen könnte tun sie lieber von Hand weil sie nicht nicht wissen wie > sie dem Computer überhaupt mitteilen könnten was sie erledigt haben > wollen. > > Das liegt daran daß ihr Dialog mit der Maschine, bzw die Sprache in der > er geführt wird, nur aus Zeigen und Klicken besteht. Das ist die eine Seite der Medaille. Die andere Seite der Medaille ist, daß viele eine irrationale Angst davor haben, sich effizientere Mechanismen zur Mensch-Maschine-Kommunikation anzueignen. Das liegt nicht zuletzt an Leuten, die ihnen erzählen, wie kompliziert das sei, sowie auch an Werkzeugen, die unnötig unkomfortabel und unnötig kompliziert sind. Beide Sorten müssen die eigene Faulheit, Dummheit oder Angst vor sich selbst zu rechtfertigen -- spätestens dann, wenn ihnen jemandem begegnet, der diese effizienteren Mechanismen beherrscht und benutzt. Das führt dann zu solchen aggressiven Pöbeleien, wie sie unser kleiner Troll hier aufführt -- aber am Ende dokumentiert (und kompensiert) er mit seinem Verhalten lediglich seine eigenen charakterlichen, technischen und kommunikativen Defizite. :-)
Linuxnutzer, der auch vi, sed, awk nutzt schrieb: > Korrigiere bitte mal dein verzerrtes Weltbild. Heutzutage sind die von > dir genannten interaktiven Anwendungen der Haupteinsatzbereich und nicht > nur "zusätzlich". Hm... regelmäßig sind diese interaktiven Anwendungen lediglich ein Frontend für Anwendungen, die im Hintergrund ablaufen. Beispielsweise ein Webbrowser greift auf einen Webserver zu, ein Mailprogramm auf einen Mailserver, ein Layout-CAD-Programm auf eine Bauteiledatenbank, ein Dateimanager auf einen Dateiserver und ein Geldautomat ... you get the idea: viele, und vielleicht sogar die meisten interaktiven Anwendungen nutzen im Hintergrund eine nicht-interaktive Anwendung. Wo ist die Grenze, und was ist da der "Haupteinsatzbereich"?
Linuxnutzer, der auch vi, sed, awk nutzt schrieb: > Korrigiere bitte mal dein verzerrtes Weltbild. Heutzutage sind die von > dir genannten interaktiven Anwendungen der Haupteinsatzbereich und nicht > nur "zusätzlich". Klar sind die interaktiven Anwendungen "zusätzlich", denn sonst wären sie ja nicht nur der "Haupteinsatzbereich", sondern der "alleinige, ausschließliche Einsatzbereich". Und das ist definitiv nicht der Fall, auch wenn ein W.S. und noch ein paar andere gebetsmühlenartig versuchen, diesen Irrglauben unters Volk zu bringen.
Trollversuch oder meine Aussage wirklich nicht verstanden? Nach meinen bisherigen Erfahrungen mit den Moderatoren dieses Forums tippe ich auf ersteres. > Beispielsweise > ein Webbrowser greift auf einen Webserver zu, ein Mailprogramm auf einen > Mailserver, ein Layout-CAD-Programm auf eine Bauteiledatenbank, ein > Dateimanager auf einen Dateiserver und ein Geldautomat ... dto. Wieviele Webserver laufen auf dieser Welt und wieviele Webbrowser sind in Betrieb und was merkt der Endanwender des Webbrowsers von der Benutzerschnittstelle des Webbrowsers für den Administrator? Also wieviel Endanwender gibt es für die Webbrowser und wieviel Administratoren für die Server? Wobei heutzutage ja auch immer mehr Server mit GUI konfiguriert werden. Nur mal als Gedankenanstoß.
:
Wiederhergestellt durch Moderator
Linuxnutzer, der auch vi, sed, awk nutzt schrieb: > Trollversuch Keineswegs. > oder meine Aussage wirklich nicht verstanden? Möglicherweise. > Nach meinen bisherigen Erfahrungen mit den Moderatoren dieses Forums > tippe ich auf ersteres. Diese Bemerkung hättest du dir sparen können :-/ Es könnte aber auch sein, dass du es bist, der meinen Beitrag nicht verstanden hat (Trollerei möchte ich dir jetzt einmal nicht unterstellen). Vielleicht noch einmal zur Klarstellung: Mit dem "zusätzlich" wollte ich nicht ausdrücken, dass die interaktiven Anwendungen in der Minderheit sind. Oder formal ausgedrückt ;-)
1 | A = K; // die klassischen Anwendungen |
2 | A += I; // hinzu kommen die Interaktiven Anwendungen |
impliziert für mich nicht I < K. Dewegen verstehe ich nicht, warum ich mein Weltbild verzerrt sein sollte und warum ich es korrigieren sollte. Du sagst: I > K, und dem stimme ich, zumindest wenn man die Zahlen über alle Computeranwender mittelt, zu. W.S. sagt (wenn ich ihn richtig verstanden habe): K = 0 oder zumindest K <<< I, und dem stimme ich eben icht zu.
Linuxnutzer, der auch vi, sed, awk nutzt schrieb: > Wieviele Webserver laufen auf dieser Welt und wieviele Webbrowser sind > in Betrieb Na, dann benutz deinen Webbrowser doch ohne einen Webserver. Hat doch keiner was dagegen. ;-)
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.