ubuntuusers.de

Hi,

seit geraumer Zeit quält mich eine Frage: Es wird im Zusammenhang mit Linux (allgemein) immer gern auf das sogenannte "KISS" Prinzip gedeutet. Nur, warum findet es in der Programmierung so wenig beachtung?

Beispiel: Anstatt für einen Suchmechanismus auf die locate Datenbank zuzugreifen, wird eine eigene aufgebaut, was nicht nur speicherplatz verschlingt, sondern auch Performance kostet und absolut unnötig ist (Beagle/DesktopSearch) Warum? Nach dem KISS Prinzip müsste auf locate aufgebaut werden (quasi ein grafisches Frontend)

Es wäre allgemein doch viel einfacher, einfach grafische Frontends auf basis der Konsolenbefehle zu bauen...oder übersehe ich da irgendwo etwas?

Ich frage mich jetzt, auf was für Programme du dich konkret beziehen möchtest?

Es gibt reichlich Programme, die ihre Möglichkeiten bei der Ausgabe von Konsolenbefehlen ausschöpfen. Mir ist zwar auch ein Rätsel, warum ich Dateien mit etwas anderem als locate suchen sollte, aber auch dazu gibt es entsprechend grafische Anwendungen - z.B. catfish. Sehe ich mir Programme, wie sysinfo oder gnome-device-manager an, dann sehe ich im Prinzip auch nur die gebündelte Ausgabe verschiedener Konsolenbefehle. Bei sound-juicer und soundconverter schimmern die Befehlzeilen für die Konsole ebenfalls deutlich durch.

Was für "verschiedene" Programme sollten das also sein? Du sprichst zwar davon, nennst aber nur ein konkretes Beispiel.

* dateioperationen (kopieren, verschieben, verknüpfungen erzeugen), wobei ich nicht weiß, ob das da schon gemacht wird...die kann man über mv, cp und ln laufen lassen

* das systemüberwachungstool auf "top" aufbauen lassen * synaptic auf apt-get (ist AFAIK auch ne eigene Lösung...kann mich aber auch täuschen)

* die anzeige von dateien usw. in nautilus auf ls aufbauen lassen

das sind erstmal so die sachen die mir auf anhieb noch einfallen

Es ist eine völlig absurde Idee, für einfache Dateioperationen auf cp, mv und ln zurückzugreifen, da das Betriebssystem derartige Funktionen bereits hinreichend abstrahiert. Beispielsweise kann man das anlegen eines Symlinks mit einem einzigen Systemaufruf erledigen, während allein der Start und das Warten auf das Ende eines Kindprozesses drei Systemaufrufe braucht. Eine zuverlässige Fehlerdiagnose ist noch viel umständlicher, wenn man mit Kindprozessen hantiert. Weiter geht es damit, dass z. B. cp keine Fortschrittsanzeige besitzt, ein darauf aufbauendes GUI also ebenfalls keines bieten könnte.

Ähnlich sieht es mit locate aus. Einen Index aller Dateien kann man mittels nftw64 und gdbm auf einfache Weise erstellen, wozu also locate nutzen? Zumal die Zielsetzung von Beagle & Co. sowieso viel weiter geht als bei locate. Mit dem Code aus locate könnte man einfach nichts anfangen, zumal locate in C und Beagle in C# geschrieben ist.

Solche und ähnliche Probleme gibt es immer, wenn man ein GUI um ein Kommandozeilenwerkzeug herumstricken möchte. Meistens ist das einfach kein sinnvoller Ansatz, da das Gebastel mit Kindprozessen deutlich mehr Arbeit ist, als eine Bibliothek zu nutzen.

detructor15 schrieb:

Beispiel: Anstatt für einen Suchmechanismus auf die locate Datenbank zuzugreifen, wird eine eigene aufgebaut, was nicht nur speicherplatz verschlingt, sondern auch Performance kostet und absolut unnötig ist (Beagle/DesktopSearch) Warum?

Weil locate sehr beschränkt ist.

ChemicalBrother schrieb:

detructor15 schrieb:

Beispiel: Anstatt für einen Suchmechanismus auf die locate Datenbank zuzugreifen, wird eine eigene aufgebaut, was nicht nur speicherplatz verschlingt, sondern auch Performance kostet und absolut unnötig ist (Beagle/DesktopSearch) Warum?

Weil locate sehr beschränkt ist.

? erklärung? ich seh da keine beschränkung...und selbst wenn kann man wenigstens die Datenbank benutzen...

Dann versuch mal, mittels locate z.B. eine Textpassage innerhalb eines als PDF gespeicherten eBooks zu finden. 🙄

?das ist auch nicht die Aufgabe von locate. Genausowenig ist das die Aufgabe einer Desktopsuche sein. Das ist einfach die Aufgabe eines eBookReaders oder PDFViewers...

Das ist eben den große Vorteil der Desktopsuchen - die können das.

detructor15 schrieb:

?das ist auch nicht die Aufgabe von locate. Genausowenig ist das die Aufgabe einer Desktopsuche sein. Das ist einfach die Aufgabe eines eBookReaders oder PDFViewers...

Aha, und womit mache ich das denn bei E-Mails? Oder Textdateien? Oder OpenOffice-Dokumenten? Word-Dokumenten? Calc-Tabellen? Programmcode? HTML-Dateien? ... 😉

jtoegel hat recht, eine Desktopsuche kann das alles. locate kann nichts davon, sorry, blöde Idee.

detructor15 schrieb:

?das ist auch nicht die Aufgabe von locate. Genausowenig ist das die Aufgabe einer Desktopsuche sein. Das ist einfach die Aufgabe eines eBookReaders oder PDFViewers...

Doch, genau das ist die Aufgabe einer Desktopsuche. Vorher besser informieren und dann nochmal versuchen, tolle Ideen rauszuhauen.

ok, wenn ihr meint...IMO sind das 2 vollkommen verschiedene Dinge die von 2 grundverschiedenen Programmen erledigt werden sollten.

Ihr seid einer anderen Meinung, dabei sollte man es belassen

Hier muss man aufpassen wovon man genau spricht. destructor15 spricht gerade von einer einfachen Dateisuche die durchaus auf Basis von locate arbeiten könnte (und dies vielleicht auch tut), die 3 User über dem letzten Posting sprechen von einer Desktopsuche die global die Inhalte der Dateien erfasst. Beides gibt es und beides hat seine Berechtigung nur locate kann letzteres nicht bieten.

Der Hauptgrund dafür dass man nicht viel auf Basis von Konsolenvarianten macht liegt darin dass man damit viel Kontrolle über den Prozess abgibt und man dabei eine ganze Menge falsch machen kann. Ein Stichwort für Python wäre da z.B. os.system, wer es nicht kennt dem sei versichert dass das so auch besser ist.

Der Hauptgrund dafür dass man nicht viel auf Basis von Konsolenvarianten macht liegt darin dass man damit viel Kontrolle über den Prozess abgibt

aber das ist doch gerade das schöne daran: Ich muss mich nicht darum kümmern, was die Funktion (locate, bleiben wir mal bei dem beispiel) tut!

Ich weiß, was ich der Funktion geben muss und was ich zurück bekomme, alles andere braucht mich nicht zu kümmern.

*edit

wenn jetzt ein Fehler auftritt, dann muss ich den an 1 Stelle fixen. Wenn jetzt aber jeder seinen eigenen kram macht und jeder irgendwo den gleichen Systemaufruf benutzt (der sich jetzt geändert hat...was weiß ich, der heißt einfach anders) dann muss ich das bei meinem Szenario nur in locate selbst ändern, bei "eurem" Szenario muss jeder Maintainer sein Projekt abändern.

Das ist irgendwie ineffizient...

DasIch schrieb:

Hier muss man aufpassen wovon man genau spricht. destructor15 spricht gerade von einer einfachen Dateisuche die durchaus auf Basis von locate arbeiten könnte (und dies vielleicht auch tut), die 3 User über dem letzten Posting sprechen von einer Desktopsuche die global die Inhalte der Dateien erfasst.

detructor15 schrieb:

Beispiel: Anstatt für einen Suchmechanismus auf die locate Datenbank zuzugreifen, wird eine eigene aufgebaut, was nicht nur speicherplatz verschlingt, sondern auch Performance kostet und absolut unnötig ist (Beagle/DesktopSearch) Warum?