Computer/Konfigurationssprachen an die natürliche Sprache anzulehnen finde ich überhaupt keine gute Idee. Dabei hätte ich übrigens auch fetchmail als negativ Beispiel angeführt, noch schlimmer ist SQL.
Das macht es vielleicht einfacher die Sprache zu lesen, allerdings tendiert man beim schreiben der Sprache auch dazu so variabel zu sein, wie die menschliche Sprache nun mal ist. Und wenn das Programm nicht mit Anweisungen wie "every minute", "twice a day, except sundays" oder "christmas eve" zurechtkommt, sollte man es lieber lassen sich zu nahe an die menschliche Sprache anzulehnen. Allerdings ist cron auch m.M.n. auch kein Beispiel für eine gelungende Konfigurationssprache.
Naja, ist für mich wirklich nicht ohne weiteres zu erkennen, für Cobol bin ich wohl einfach zu jung und noch in der falschen Branche. Und soo krank, das man es nicht gut finden könnte, ist die fetchmal Konfiguration nun auch nicht.
Es ist halt ein zweischneidiges Schwert. Auf der einen Seite soll die Konfiguration einfach sein, auf der anderen aber auch eindeutig. Ich denke es ist Aufgabe begleitender Konfigurationstools, einerseits eine ausgefeilte Erstkonfiguration zu erstellen und andererseits einfache Änderungsmöglichkeiten abzubilden.
Insofern sollte sich ein Tool eher auf die Aufgabe an sich konzentrieren, die Parametrierung auf wohldefinierte Schnittstellen wie optparse, Umgebungsvariablen und Key-Value-Dateien abbilden und den Rest an Benutzerfreundlichkeit speziellen Distributionstools überlassen.
Von Punktlandung am Fr, 24. Februar 2012 um 08:26 #
"wenn man den Entwickler auf fcron aufmerksam gemacht hätte."
Nicht nur die Entwickler, auch die Autoren von Pro-Linux haben wohl fcron vergessen. "Neu" ist nicht die Möglichkeit auf Systemlast usw. zu reagieren, sondern nur die Konfigurationsdatei. Das sollte so auch im Artikel zu lesen sein. Und über Sinn und Unsinn der "Natürlichsprachlichkeit" in einer Konfiguration wurde hier schon hinlänglich diskutiert
fcron ist halt wenig bekannt. Ich bin kürzlich darauf gestoßen, nachdem ich feststellte, dass man mit dem herkömmlichen Cron nur schwer einen Start- und Endtermin für Jobs festlegen kann (es geht, aber ein wenig umständlich). Hatte bisher keine Zeit, mich mit fcron zu befassen.
Vielleicht willst du mal eine kleine Vorstellung von fcron schreiben? Wir suchen ständig neue Artikel!
Leider wird fcron in Debian sehr stiefmütterlich behandelt und nicht als vollwertige Vixie-cron+anacron-Alternative ins System integriert. Mir scheints, dass sie auf irgendeine neu entwickelte Lösung warten, sei es whenjobs, cronie, oder irgendwas im Zusammenhang mit systemd.
Nur Frage ich mich, ob es das Projekt auch geben würde, wenn man den Entwickler auf fcron aufmerksam gemacht hätte.
Und Konfiguration an natürliche Sprache anzulehnen ist eine gute Idee. Hat bei Cobol und fetchmail auch wunderbar geklappt.
Computer/Konfigurationssprachen an die natürliche Sprache anzulehnen finde ich überhaupt keine gute Idee. Dabei hätte ich übrigens auch fetchmail als negativ Beispiel angeführt, noch schlimmer ist SQL.
Das macht es vielleicht einfacher die Sprache zu lesen, allerdings tendiert man beim schreiben der Sprache auch dazu so variabel zu sein, wie die menschliche Sprache nun mal ist. Und wenn das Programm nicht mit Anweisungen wie "every minute", "twice a day, except sundays" oder "christmas eve" zurechtkommt, sollte man es lieber lassen sich zu nahe an die menschliche Sprache anzulehnen.
Allerdings ist cron auch m.M.n. auch kein Beispiel für eine gelungende Konfigurationssprache.
:-)
Hey FL, hiermit bekommst du ein offizielles Zertifikat für schnelles und sichers Ironieerkennen. Glückwunsch!
Naja, ist für mich wirklich nicht ohne weiteres zu erkennen, für Cobol bin ich wohl einfach zu jung und noch in der falschen Branche. Und soo krank, das man es nicht gut finden könnte, ist die fetchmal Konfiguration nun auch nicht.
Es ist halt ein zweischneidiges Schwert. Auf der einen Seite soll die Konfiguration einfach sein, auf der anderen aber auch eindeutig. Ich denke es ist Aufgabe begleitender Konfigurationstools, einerseits eine ausgefeilte Erstkonfiguration zu erstellen und andererseits einfache Änderungsmöglichkeiten abzubilden.
Insofern sollte sich ein Tool eher auf die Aufgabe an sich konzentrieren, die Parametrierung auf wohldefinierte Schnittstellen wie optparse, Umgebungsvariablen und Key-Value-Dateien abbilden und den Rest an Benutzerfreundlichkeit speziellen Distributionstools überlassen.
lg
Erik
"wenn man den Entwickler auf fcron aufmerksam gemacht hätte."
Nicht nur die Entwickler, auch die Autoren von Pro-Linux haben wohl fcron vergessen. "Neu" ist nicht die Möglichkeit auf Systemlast usw. zu reagieren, sondern nur die Konfigurationsdatei. Das sollte so auch im Artikel zu lesen sein. Und über Sinn und Unsinn der "Natürlichsprachlichkeit" in einer Konfiguration wurde hier schon hinlänglich diskutiert
Punktlandung
fcron ist halt wenig bekannt. Ich bin kürzlich darauf gestoßen, nachdem ich feststellte, dass man mit dem herkömmlichen Cron nur schwer einen Start- und Endtermin für Jobs festlegen kann (es geht, aber ein wenig umständlich). Hatte bisher keine Zeit, mich mit fcron zu befassen.
Vielleicht willst du mal eine kleine Vorstellung von fcron schreiben? Wir suchen ständig neue Artikel!
Leider wird fcron in Debian sehr stiefmütterlich behandelt und nicht als vollwertige Vixie-cron+anacron-Alternative ins System integriert.
Mir scheints, dass sie auf irgendeine neu entwickelte Lösung warten, sei es whenjobs, cronie, oder irgendwas im Zusammenhang mit systemd.