Hallo allerseits,
auf meiner Root-Partition wird es langsam eng, daher wollte ich die Logdateien aus
/var/log/fhem gerne auf eine andere, noch völlig leere Partition umziehen.
Theoretisch gibt es nach meinem Verständnis dazu zwei Möglichkeiten:
- Ich ändere in /etc/fhem.cfg alle Einträge /var/log/fhem/ auf den Pfad der anderen Partition
- Ich ändere /etc/fstab und mounte meine zweite Partition als /var/log/fhem/
Ist eines dieser Verfahren dem anderen vorzuziehen? Gibt es bekannte Probleme bei einem dieser Verfahren?
Danke im Voraus für Eure Antworten!
Ich würde in jedem Fall die zweite Methode anwenden, schon allein um spätere Probleme wegen (vergessener?) Konfigurationsprobleme zu vermeiden.
Je nach Größe der Partition würde ich aber eher /var/log oder (je nach Platz) komplett /var mounten...?
Es gibt noch eine ritte Möglichkeit:
3. Symlink
Ein Symlink, der /var/log/fhem woanders hinzeigen lässt
Möglichkeit 4:
In fhem den Pfad für das Logverzeichnis ändern (dafür gibt es ein globales Attribut "logdir") und danach die vorhandenen Logfiles an die neue Stelle kopieren.
Hui, sieht ja fast so aus, als hätte ich die freie Auswahl! :D Sogar Symlinks gehen – das hatte ich irgendwie eher bezweifelt und daher gar nicht erwähnt. Dank für Eure Antworten!
Zitat von: betateilchen am 06 Juli 2016, 08:08:09
Möglichkeit 4:
In fhem den Pfad für das Logverzeichnis ändern (dafür gibt es ein globales Attribut "logdir") und danach die vorhandenen Logfiles an die neue Stelle kopieren.
Aber wenn ich nur das globale Attribut
logdir ändere, dann bleibt doch für alle schon existenten Logdateien in
/etc/fhem.cfg der Pfad
/var/log/fhem/ bestehen, oder übersehe ich da etwas? (Deswegen würde ich ja, wie ich schrieb, erwarten, dass ich
alle /var/log/fhem/-Einträge in
/etc/fhem.cfg durch den neuen Pfad ersetzen muss.
Zitat von: betateilchen am 06 Juli 2016, 08:08:09
[...] danach die vorhandenen Logfiles an die neue Stelle kopieren.
Zitat von: marvin78 am 06 Juli 2016, 10:09:14
[...] danach die vorhandenen Logfiles an die neue Stelle kopieren.
Ja, logo. Nur was nützt das, wenn in
/etc/fhem.cfg noch die alten Pfade stehen? Das wäre doch gerade das Problem, dass die Pfade in der Konfigurationsdatei und die tatsächlichen Dateipfade nicht mehr übereinstimmen.
Ich möchte jetzt nicht schon wieder zitieren. Die Pfade stehen in Attributen und die müssen geändert werden.
Zitat von: marvin78 am 06 Juli 2016, 10:28:23
Ich möchte jetzt nicht schon wieder zitieren. Die Pfade stehen in Attributen und die müssen geändert werden.
?? Öhm, ja eben – das ist doch genau das, was ich eingangs schrieb (
Ich ändere in /etc/fhem.cfg alle Einträge /var/log/fhem/ auf den Pfad der anderen Partition), nur
betateilchen, auf den ich mich bezog, setzte dagegen, ich müsse
nur das globale Attribut
logdir ändern – und das verstand ich eben nicht.
Ich verstehe nicht wirklich, was Du mir sagen willst. ;)
Ihr redet aneinander vorbei. Das globale Attribut logdir wirkt sich auf jeden Fall auf alle neu erstellten Logfile-Definitionen aus.
Ob eine Änderung des Attributes auch bei vorhandenen Definitionen greift, hängt davon ab, wie die bestehenden Logfiles definiert sind.
Beispiel 1:
define log1 FileLog ./log/meinLogfile1.name <regexp>
In dieser Definition muss der Pfad manuell geändert werden.
Beispiel 2:
define log2 FileLog %L/meinLogfile2.name <regexp>
In diesem Fall wird der Pfad bei jedem Neustart aus dem globalen Attribut logdir gelesen und verwendet.
Deshalb wird in diesem Fall eine Änderung des Attributes logdir auch für bestehende Definitionen funktionieren.
Und deshalb sollte man auch FileLog Definitionen am sinnvollsten immer mit dem Platzhalter %L definieren anstatt mit einer konkreten Pfadangabe.
Oder man steigt gleich um auf DbLog, dann muss man sich über so ein Thema gar keine Gedanken mehr machen.
Bitte die commandref zu FileLog beachten (insbesondere bezüglich logdir). Man kann das alles etwas generischer machen und zukünftige Verschiebungen erleichtern.
das hab ich doch grade erklärt ???
Problem ist, dass logdir in der commandref nur einmal erwähnt ist, aber nicht bei global beschrieben wird. Defaultmässig ist es auch nicht gesetzt und mit autocreate angelegte Logs werden wohl als ./log/... definiert.
Peter
Richtig. Du warst schneller.
Aber ich habe an niemandem vorbei geredet sondern darauf gesetzt, dass die commandref Inhalte klar sind.
Zitat von: marvin78 am 06 Juli 2016, 10:49:10
sondern darauf gesetzt, dass die commandref Inhalte klar sind.
Du glaubst wohl auch, dass ein Zitronenfalter Zitronen faltet?
Zitat von: betateilchen am 06 Juli 2016, 10:43:54
Ihr redet aneinander vorbei. Das globale Attribut logdir wirkt sich auf jeden Fall auf alle neu erstellten Logfile-Definitionen aus.
Ob eine Änderung des Attributes auch bei vorhandenen Definitionen greift, hängt davon ab, wie die bestehenden Logfiles definiert sind.
Beispiel 1:
define log1 FileLog ./log/meinLogfile1.name <regexp>
In dieser Definition muss der Pfad manuell geändert werden.
Ah, alles klar! So sehen in der Tat sämtliche Logdatei-Pfade in
/etc/fhem.cfg bei mir aus (de facto sogar mit absolutem Pfad, also eben – wie gesagt –
/var/log/fhem/meineLogdatei). Und die habe auch nicht ich so geschrieben, sondern ausnahmslos FHEM automatisch selbst.
Zitat von: marvin78 am 06 Juli 2016, 10:49:10
Aber ich habe an niemandem vorbei geredet sondern darauf gesetzt, dass die commandref Inhalte klar sind.
Warum sollte ich Teile von
commandref lesen, die mich überhaupt nicht betreffen, da FHEM das alles bereits automatisch gemacht hat? Ich gehe schon davon aus, dass FHEM dann die ,,richtige" Lösung wählt ... 8)
Zitat von: ph1959de am 06 Juli 2016, 10:48:31
und mit autocreate angelegte Logs werden wohl als ./log/... definiert.
Nein.
Mit autocreate angelegte logs werden so angelegt, wie es im Attribut "filelog" von autocreate festgelegt ist.
Man kann auch dort festlegen, dass automatisch erstellte Logs mit %L angelegt werden.
Nur:
man muss es auch tun!Nur wenn sich ein Benutzer überhaupt keine Gedanken um sein Logging macht, wird ein default verwendet.
Und dann kommen genau solche Fragen auf wie die, über die wir hier im Thread gerade diskutieren.
Zitat von: Uli Zappe am 06 Juli 2016, 10:59:03
Ich gehe schon davon aus, dass FHEM dann die ,,richtige" Lösung wählt ... 8)
Falsche Annahme. fhem nimmt Dir nicht das Denken ab.
Zitat von: Uli Zappe am 06 Juli 2016, 10:59:03
Warum sollte ich Teile von commandref lesen, die mich überhaupt nicht betreffen
Diese Frage finde ich ziemlich haarsträubend.
Es betrifft Dich doch - es sind doch schließlich DEINE Logfiles, die Du jetzt umziehen möchtest.
Zitat von: betateilchen am 06 Juli 2016, 11:00:45
Mit autocreate angelegte logs werden so angelegt, wie es im Attribut "filelog" von autocreate festgelegt ist.
Man kann auch dort festlegen, dass automatisch erstellte Logs mit %L angelegt werden.
Nur: man muss es auch tun!
Nur wenn sich ein Benutzer überhaupt keine Gedanken um sein Logging macht, wird ein default verwendet.
Ja. Und man kann mit Fug und Recht davon ausgehen, dass das der bestmögliche ist. Alles andere wäre komplett unsinnig.
Bei jeder Software, die ich verwende, muss ich davon ausgehen, dass alle Voreinstellungen für den Standard-Anwendungsfall optimal sind, sodass ich mich nur um jene Aspekte kümmern muss, wo meine von der Standardsituation abweicht. Andernfalls würde ich mein Leben komplett mit dem Studium von IT-Dokumentationen zubringen; das ist nicht meine Absicht.
Zitat von: betateilchen am 06 Juli 2016, 11:01:37
Falsche Annahme. fhem nimmt Dir nicht das Denken ab.
Das ist schlecht, denn das sollte es (im oben beschriebenen Sinne:
Wo Deine Situation dem Normalfall entspricht, musst Du dir keine Gedanken machen, weil alles optimal voreingestellt ist – anders ist die Komplexität der heutigen Software-Welt überhaupt nicht zu meistern).
ZitatDiese Frage finde ich ziemlich haarsträubend.
Sorry, aber das ist wirklich völlig unsinnig. Die Frage, wohin die Logdateien installiert werden sollen, stellt sich
ganz zu Beginn, bevor überhaupt das erste Gerät von FHEM angelegt wurde – sprich, zu einem Zeitpunkt, wo der zukünftige Anwender noch genau null praktische Erfahrung mit FHEM hat und nur eine vage Ahnung davon, wie das alles funktionieren wird. Die Vorstellung, dass sich jemand in dieser Situation ein extrem nerdig formuliertes, riesig langes Dokument, von dessen Inhalt 90% nie für ihn relevant werden werden, von Anfang bis Ende durchliest (und dabei höchstens ein Zehntel verstehen wird), ist in einem nicht zu überbietenden Maße absurd.
Das ist das alte Elend mit Open-Source-Software: Diejenigen, die sie erstellen, leiden zu oft unter einem fast kompletten Realitätsverlust, was die Erwartungen an das Nutzungsverhalten ,,normaler" Anwender angeht (und dabei bin ich sogar noch ein Wissenschaftler, zu dessen Aufgaben über weite Strecken auch die Softwareentwicklung gehört ...)
ZitatEs betrifft Dich doch - es sind doch schließlich DEINE Logfiles, die Du jetzt umziehen möchtest.
Na und? Wo ist das Problem? Ein
Suche & Ersetze in
fhem.cfg dauert 10 Sekunden ... Und um das zu vermeiden, schlägst Du vor, ich hätte mich stunden- bis tagelang durch
commandref quälen sollen?
Das ist doch alles kein Drama – ich wollte lediglich wissen, ob es gute Gründe gegen die eine oder andere von mir geschilderte Variante gibt. Offenbar nicht – alles wunderbar! :D
Aber wenn die Pfad-Voreinstellung mit %L in Normalfall besser wäre, dann stellt sich doch wirklich die Frage, warum das dann nicht der Defaultwert von FHEM ist.
Ganz einfach, weil FHEM nicht weiß, wie deine Pfade aussehen (sollen) und logdir nicht automatisch setzen kann und sollte. Deshalb kann es in %L auch nichts geben. Aber die Diskussion ist müßig. Du möchtest Recht behalten. Das ist ok. Am Ende kannst du machen, was du möchtest, betateilchen behält trotzdem recht. Die Doku sollte man lesen und beherzigen, wie man die Inhalte anwendet ist dann tatsächlich dem User überlassen. So schön ist FHEM.
Im Übrigen kann eine Software nie die für den einzelnen User optimalen Voreinstellungen verwenden. Hellsehen kann noch keine Software, so weit mir bekannt ist.
Zitat von: marvin78 am 06 Juli 2016, 12:19:00
Ganz einfach, weil FHEM nicht weiß, wie deine Pfade aussehen (sollen) und logdir nicht automatisch setzen kann und sollte. Deshalb kann es in %L auch nichts geben.
Derzeit wird aber doch im
autocreate ein Default von
./log/... angenommen (habe ich jetzt nicht anhand einer neuen Konfiguration überprüft). Diese
Annahme könnte doch genauso gut in
global, attr logdir als Default manifestiert werden. Damit wäre
%L als Default im
autocreate attr filelog verwendbar. Würde sich, solange der Benutzer nichts ändert, genauso verhalten wie bisher, wäre aber flexibler für Anpassungen (bzw. die mit logdir / %L angedachte und beabsichtigte Flexibilität nicht behindern).
Peter
autocreate ist ein Thema für sich, da hast du nicht ganz unrecht. Ich stehe nicht auf autocreate und mag solche Helfer generell nur bedingt. Annahmen sind nie wirklich gut und hier sicher historisch mitgeführt.
Wenn es irgendwie geht, würde ich ohnehin DbLog empfehlen, aber darum ging es ja hier nicht.
Zitat von: ph1959de am 06 Juli 2016, 12:49:47
Derzeit wird aber doch im autocreate ein Default von ./log/... angenommen
Diese falsche Behauptung wird nicht dadurch richtig, dass sie mehrfach wiederholt wird.
####################
my $fl = replace_wildcards($hash, AttrVal($me, "filelog", ""));
my $flname = "FileLog_$name";
delete($defs{$flname}) if($fl); # If we are re-creating it with createlog.
my ($gplot, $filter, $devattr) = ("", $name, "");
my $fp = $modules{$hash->{TYPE}}{AutoCreate};
$fp = \%flogpar if(!$fp);
foreach my $k (keys %{$fp}) {
next if($name !~ m/^$k$/);
$gplot = $fp->{$k}{GPLOT};
$filter = replace_wildcards($hash, $fp->{$k}{FILTER});
$devattr = $fp->{$k}{ATTR};
last;
}
if($fl) {
$cmd = "$flname FileLog $fl $filter";
Log3 $me, 2, "autocreate: define $cmd";
$ret = CommandDefine(undef, $cmd);
if($ret) {
Log3 $me, 1, "ERROR: $ret";
last;
}
$attr{$flname}{room} = $room if($room);
$attr{$flname}{logtype} = "${gplot}text";
Da steht nirgends etwas von ./log/ sondern nur, dass der Pfad aus dem Attribut filelog des autocreate gelesen wird und - falls nichts eingetragen ist - leer bleibt. Damit gilt der Default von FileLog, der beim (automatisch aufgerufenen) define vom Modul FileLog ermittelt wird.
Zitat von: Uli Zappe am 06 Juli 2016, 11:40:00
Das ist das alte Elend mit Open-Source-Software: Diejenigen, die sie erstellen, leiden zu oft unter einem fast kompletten Realitätsverlust, was die Erwartungen an das Nutzungsverhalten ,,normaler" Anwender angeht
Niemand zwingt Dich, open-source-software zu verwenden.
Zitat von: betateilchen am 06 Juli 2016, 14:03:59
Diese falsche Behauptung wird nicht dadurch richtig, dass sie mehrfach wiederholt wird.
Stimmt - ich hätte gleich testweise eine autocreate-Instanz anlegen sollen, dann hätte ich gesehen, dass das filelog Attribut explizit gesetzt werden muss (es da also keinen Default gibt).
Sorry und danke für die Richtigstellung.
Peter
Zitat von: marvin78 am 06 Juli 2016, 12:19:00
Ganz einfach, weil FHEM nicht weiß, wie deine Pfade aussehen (sollen) und logdir nicht automatisch setzen kann und sollte.
Aber irgendwelche Vorannahmen
muss FHEM machen; schließlich läuft es nach der Installation sofort, auch wenn der Nutzer keinerlei Voreinstellungen vorgenommen hat. Bei meiner damaligen Installation war die Vorannahme eben offenbar
/var/log/fhem/; ich habe das nie geändert und mich nie darum gekümmert, weil mir völlig schnuppe ist, in welchem Ordner die Logdateien liegen. Aber so wie es seinerzeit bei mir
/var/log/fhem/ war, hätte es ebensogut was mit %L sein können. Wenn der Konsens hier ist, dass das besser wäre, warum nimmt man dann nicht das als Voreinstellung?
ZitatDu möchtest Recht behalten.
Darum geht es mir als solches nun überhaupt nicht. Ich bin ein großer Fan von FHEM und empfehle es überall, weiß aber eben auch, dass viele potentielle Anwender von dem System im heutigen Zustand komplett überfordert sind, so gerne sie es benutzen würden.
ZitatDie Doku sollte man lesen
Ich kann mich nur wiederholen: Lerntheoretisch ist das eine vollkommen unsinnige Annahme. Niemand lernt dadurch Deutsch, dass er den Duden von vorne bis hinten liest, bevor er die erste Unterhaltung auf Deutsch führt. Niemand eignet sich ein komplexes System wie FHEM dadurch an, dass er komplett trockenschwimmt, bevor er auch nur ein Gerät in einer FHEM-Installation angelegt hat. Ich stimme Dir mit Einschränkungen zu, soweit es das Einführungs-PDF betrifft (aber auch da habe ich damals zunächst nur die, soweit ich das einschätzen konnte, unmittelbar für mich relevanten Passagen gelesen). Bei
commandref ergibt Deine Erwartung null Sinn – wie bei allen Nachschlage-Dokumenten übrigens.
ZitatIm Übrigen kann eine Software nie die für den einzelnen User optimalen Voreinstellungen verwenden. Hellsehen kann noch keine Software, so weit mir bekannt ist.
Darum geht es doch überhaupt nicht.
Die ,,alten Hasen" wissen, welche Werte im statistischen Normalfall besonders sinnvoll sind. Die werden als Default-Werte gesetzt. Somit läuft ,,im Prinzip" erstmal alles nach einer Erstinstallation. Und
dann kann der Nutzer, nachdem er erste Erfahrungen gesammelt hat, genau an den Stellen, wo die Default-Werte für ihn nicht passen, gezielt Anpassungen an seine individuelle Situation vornehmen.
Zitat von: betateilchen am 06 Juli 2016, 14:03:59
Niemand zwingt Dich, open-source-software zu verwenden.
Das weiß ich. :P Ich bin aber ein großer Fan des Open-Source-Prinzips, verwende Open-Source-Software sehr gerne, arbeite selbst an Open-Source-Projekten mit und habe auch schon soziologische Texte veröffentlicht, die die Vorzüge des Open-Source-Prinzips beleuchten.
Und gerade
weil mir Open-Source-Software so wichtig ist, kritisiere ich ihre typischen Schwachstellen, weil hier noch Verbesserungen erforderlich sind.
Zitat von: Uli Zappe am 06 Juli 2016, 23:27:00
Ich kann mich nur wiederholen: Lerntheoretisch ist das eine vollkommen unsinnige Annahme. Niemand lernt dadurch Deutsch, dass er den Duden von vorne bis hinten liest, bevor er die erste Unterhaltung auf Deutsch führt. Niemand eignet sich ein komplexes System wie FHEM dadurch an, dass er komplett trockenschwimmt, bevor er auch nur ein Gerät in einer FHEM-Installation angelegt hat. Ich stimme Dir mit Einschränkungen zu, soweit es das Einführungs-PDF betrifft (aber auch da habe ich damals zunächst nur die, soweit ich das einschätzen konnte, unmittelbar für mich relevanten Passagen gelesen). Bei commandref ergibt Deine Erwartung null Sinn – wie bei allen Nachschlage-Dokumenten übrigens.
Man sollte alle Aspekte einer Dokumentation lesen, die für einen selbst sinnvoll sind. Wenn ich ein Device anlege, das ich noch nicht verwendet habe, lese ich mir die Doku dazu durch. Wenn ich merke, dass die Verwendung dieses Devices auch noch andere Bereiche von FHEM berührt, lese ich ggf. auch dort noch einmal nach. Meine Erwartung, dass jemand der zu einem bestimmten Bereich Hilfe sucht, zu diesem Bereich und den angrenzenden Aspekten, die Doku gelesen hat, ergibt also nicht null sondern vollständig Sinn. Ich werwarte in der Regel sogar noch mehr und da kommt dann dein nicht trocken schimmen ins Spiel: zunächst anhand der Doku und anderen Hilfen selbst probieren und dann bei Scheitern und/oder Problemen im Forum mit diesem Beispiel als Grundlage Hilfe suchen. Das wäre optimal!
Und: Die Schwachstelle, die du meinst entdeckt zu haben, ist nicht wirklich eine. Das ist eine rein subjektive Feststellung deinerseits, die sich mit meiner langjährigen Erfahrung mit OpenSource Software vieler Art in keiner Weise deckt.
Zitat von: marvin78 am 06 Juli 2016, 10:49:10
Aber ich habe an niemandem vorbei geredet sondern darauf gesetzt, dass die commandref Inhalte klar sind.
Danke für das freundliche 15-Minuten lange Kichern. Hat mich sehr aufgemuntert...
Ciao, -MN
Zitat von: marvin78 am 07 Juli 2016, 07:15:42
Man sollte alle Aspekte einer Dokumentation lesen, die für einen selbst sinnvoll sind. Wenn ich ein Device anlege, das ich noch nicht verwendet habe, lese ich mir die Doku dazu durch. Wenn ich merke, dass die Verwendung dieses Devices auch noch andere Bereiche von FHEM berührt, lese ich ggf. auch dort noch einmal nach. Meine Erwartung, dass jemand der zu einem bestimmten Bereich Hilfe sucht, zu diesem Bereich und den angrenzenden Aspekten, die Doku gelesen hat, ergibt also nicht null sondern vollständig Sinn. Ich werwarte in der Regel sogar noch mehr und da kommt dann dein nicht trocken schimmen ins Spiel: zunächst anhand der Doku und anderen Hilfen selbst probieren und dann bei Scheitern und/oder Problemen im Forum mit diesem Beispiel als Grundlage Hilfe suchen. Das wäre optimal!
Ich stimme Dir in all diesen Punkten zu und verfahre auch selbst so.
Mein Argument hier war aber ein anderes: Das von Dir beschriebene Vorgehen, insbesondere
selbst probieren, ist – wenn man einen späteren Umzug der Logdateien vermeiden will – nur möglich,
nachdem der Pfad für Logdateien bereits gesetzt ist: Denn der wird ja sofort nach der Installation benutzt, sobald man FHEM das erste mal startet. Und deswegen gilt Dein Argument für den speziellen Fall der Wahl des Pfades für Logdateien eben nicht, und eine sinnvolle Default-Einstellung von FHEM ist besonders wichtig.
ZitatUnd: Die Schwachstelle, die du meinst entdeckt zu haben, ist nicht wirklich eine. Das ist eine rein subjektive Feststellung deinerseits, die sich mit meiner langjährigen Erfahrung mit OpenSource Software vieler Art in keiner Weise deckt.
Dann haben wir hier sehr unterschiedliche Erfahrungen gemacht; das kommt ja vor. Daraus folgt aber nicht, dass Deine Erfahrungen objektiv richtig sind, meine hingegen rein subjektiv. :P
Zitat von: Uli Zappe am 07 Juli 2016, 19:45:12
Dann haben wir hier sehr unterschiedliche Erfahrungen gemacht; das kommt ja vor. Daraus folgt aber nicht, dass Deine Erfahrungen objektiv richtig sind, meine hingegen rein subjektiv. :P
Das habe ich auch mit keiner Silbe behauptet.
Zitat von: marvin78 am 08 Juli 2016, 07:44:11
Das habe ich auch mit keiner Silbe behauptet.
Doch, sogar mit mehreren:
ZitatDie Schwachstelle, die du meinst entdeckt zu haben, ist nicht wirklich eine.
(Hervorhebung von mir)
vs.
ZitatDas ist eine rein subjektive Feststellung deinerseits
(Hervorhebung von mir)
Das wird mir jetzt aber zu albern; ich werde da nix Weiteres mehr dazu schreiben.
Das ist auch besser so denn dieses Zerpflücken mag zwar eine tolle Wirkung für dich haben, ist aber schlechter Stil. Wir sind hier nicht bei der Presse.
Zitat von: marvin78 am 08 Juli 2016, 09:36:53
Das ist auch besser so denn dieses Zerpflücken mag zwar eine tolle Wirkung für dich haben, ist aber schlechter Stil. Wir sind hier nicht bei der Presse.
Das hat ja System bei dir. Wenn du argumentativ nicht mehr weiter kommt wird dem Gegenüber schnell auch mal "schlechter Stil" oder "schlechtes Benehmen" unterstellt
Ach? Zeige mir das System. W
Wo komme ich denn hier bitte argumentativ nicht mehr weiter? Ich habe klar dargelegt, dass Die entdeckte Schwachstelle keine ist, da es eine rein subjektive Empfindung des Users ist, dass es sie gibt. Eine Schwachstelle ist nur dann eine, wenn sie auch nach objektiven Gesichtspunkten vorhanden ist. Dass man das durch Zerpflücken des Beitrags anders darstellt, ist und bleibt schlechter Stil. Deine Einmischung in Gespräche die mit dir überhaupt nichts zu tun haben, zeigen allerdings wirklich ein System und eine perönliche Antipathie, die du mir gehenüber gerne demnächst persönlich ausdrücken kannst, aus solchen Themen aber raus halten solltest.
1. Bitte beruhigt Euch wieder
2. Ich glaube, hier herrscht ein grundsätzliches Missverständnis vor:
FHEM ist keine "Klicki-Bunti-Software" für unbedarfte Anwender. Diese will und kann es nicht sein! Mann muß sich erst einarbeiten um ein sauberes System zu kriegen. Dafür hat mann dann ein ysterm mit vielen Möglichkeiten.
Ein System, welches wie hier teilweise gewünscht dem User strenge (?richtige?) Vorgaben macht, funktioniert auf die schnelle besser, afür kämpt der User (Admin) am Ende nicht nu mit den Aufgaben, sondern auch GEGEN die Vorgaben ...
*** POPCORN für ALLE! ***
Zitat von: Wernieman am 08 Juli 2016, 10:34:59
2. Ich glaube, hier herrscht ein grundsätzliches Missverständnis vor:
FHEM ist keine "Klicki-Bunti-Software" für unbedarfte Anwender.
Ich glaube nicht, dass
irgendjemand auf die Idee kommen könnte, dem sei so. :P
ZitatEin System, welches wie hier teilweise gewünscht dem User strenge (?richtige?) Vorgaben macht, funktioniert auf die schnelle besser, afür kämpt der User (Admin) am Ende nicht nu mit den Aufgaben, sondern auch GEGEN die Vorgaben ...
Aber von ,,streng" (wohl im Sinne von ,,strikt") hat hier doch gar niemand gesprochen.
Es geht doch letztlich um etwas vollkommen Harmloses: Einen Default-Wert für den Pfad der Logdateien, der jederzeit
problemlos (!) verändert werden kann.
Irgendein Wert
muss hier bei der Installation voreingestellt sein, will man FHEM überhaupt starten können. Bei mir war die Voreinstellung
/var/log/fhem/, und das fest codiert für jede einzelne mit
autocreate erzeugte Logdatei.
Nun meinten einige, eine andere Voreinstellung sei sinnvoller. Falls darüber Einigkeit bestünde, wo wäre das Problem, sie zu ändern?
Wer dann einen anderen Wert will, müsste statt
/var/log/fhem/ eben
/was/weiss/ich/ durch seinen Wert ersetzen – was weder schwieriger noch leichter ist. Niemand muss hier gegen eine Vorgabe ankämpfen, es geht lediglich darum, dass es besser ist, sinnvolle, und schlechter ist, nicht so sinnvolle
Default-Werte zu verwenden.
Das ist alles. Wie kann das überhaupt kontrovers sein? Hier scheinen sich irgendwelche tieferliegenden Konflikte Bahn zu brechen; der Vorschlag, sinnvolle Default-Werte zu verwenden, gibt diese ganze Aufregung wirklich nicht her. ::)
Zitat von: betateilchen am 08 Juli 2016, 10:48:47
*** POPCORN für ALLE! ***
*** Ich will aber Eiskonfekt! :P ***
Zitat von: Uli Zappe am 08 Juli 2016, 10:55:57
*** Ich will aber Eiskonfekt! :P ***
heul doch 8)
push(@ignoreList, "Uli Zappe");
Egal ob Popkorn oder Eiskonfekt, Hauptsache was zu naschen ;o)
@Uli Zappe
Sorry, aber durch Verwendung von "Fett" wird Deine Argumentation nicht besser ....
Zitat von: Wernieman am 08 Juli 2016, 11:37:26
@Uli Zappe
Sorry, aber durch Verwendung von "Fett" wird Deine Argumentation nicht besser ....
Das stimmt.
Die würde wohl eher besser, wenn Du mir zeigen könntest, wo der Denkfehler in dem Argument liegt, Default-Werte – wo FHEM solche verwendet – sollten möglichst sinnvoll gewählt werden.
Bitte greife jetzt nicht MICH an .. diese Argumentationskette habe ich nicht mal beleuchtet!
Und wegen "vernünftiger Defaultwerte" habe ich auch schon mit "echten Serverleuten" wie z.B. Oracle diskutiert .. da werden immer 2 Leute 3 Meinungen haben ...
Zitat von: Wernieman am 08 Juli 2016, 14:34:09
Bitte greife jetzt nicht MICH an .. diese Argumentationskette habe ich nicht mal beleuchtet!
Ich greife Dich nicht an. Du hast sinngemäß geschrieben, meine Argumentation sei schlecht – also wollte ich halt wissen, wo/inwiefern.
ZitatUnd wegen "vernünftiger Defaultwerte" habe ich auch schon mit "echten Serverleuten" wie z.B. Oracle diskutiert .. da werden immer 2 Leute 3 Meinungen haben ...
Klar ist sowas immer schwierig, aber deswegen gar nicht erst versuchen, was Sinnvolles zustande zu bekommen?
Doch diese Diskussion hat sich auf eine absurde Weise verselbständigt. Irgendjemand hatte im Zusammenhang mit meiner ursprünglichen Frage geschrieben, dass die jetzige Default-Einstellung für die Pfade der Logdateien seiner Meinung nach doof ist. Und alles, was ich daraufhin getan habe, ist zu fragen, ob man, wenn darüber Einigkeit bestünde, nicht eine bessere Einstellung als Default wählen sollte. Ich verstehe beim besten Willen immer noch nicht den Aufreger daran.
Ich habe Dir geschrieben das durch "Fettschreibung Deine Argumentation nicht besser wird" .... und habe mich damit auf das "Fett" bezogen ... bei dem Rest wurde genug geschrieben.
Zitat von: Wernieman am 08 Juli 2016, 14:48:33
Ich habe Dir geschrieben das durch "Fettschreibung Deine Argumentation nicht besser wird"
Nö, Du hast geschrieben durch
Fett, nicht durch
Fettschreibung – weswegen ich das darauf bezogen habe, dass Eiskrem mehr Kalorien als Popcorn hat (falls das überhaupt so ist).
Ojemine, da kannst Du mal sehen, wie Missverständnisse entstehen ...
Mein fetter roter Eiskrem-Einwurf war in Anknüpfung an
betateilchens Popcorn-Beitrag ein Versuch, die Atmosphäre hier zu entspannen und aufzuheitern – das ist offenbar schief gegangen ...
Zitat von: Uli Zappe am 08 Juli 2016, 15:08:11
Nö, Du hast geschrieben ...
Du kannst es aber auch nicht einfach mal gut sein lassen ::)
Zitat von: Wernieman am 08 Juli 2016, 14:48:33
Ich habe Dir geschrieben das durch "Fettschreibung Deine Argumentation nicht besser wird" .... und habe mich damit auf das "Fett" bezogen ... bei dem Rest wurde genug geschrieben.
Don't feed the Troll! ;)
Zitat von: marvin78 am 08 Juli 2016, 10:12:37
Deine Einmischung in Gespräche die mit dir überhaupt nichts zu tun haben ...
Vielleicht sollte ich mir das an dieser Stelle auch besser zu Herzen nehmen ;D
*weiter-Popcorn-mampf*
Zitat von: Benni am 08 Juli 2016, 15:25:55
Du kannst es aber auch nicht einfach mal gut sein lassen ::)
Jemine, ich wollte ein offenkundiges Missverständnis erklären ...