Von hordipflomp am Mo, 22. September 2014 um 18:45 #
Innerhalb von nur 2 Tagen wächst die Datei auf 100mb an. ... ... Ich benutze nur die Fedora20 defaults
Hier läuft ebenfalls FC20.
Kann bestätigen, dass die Log's auf diesem System auch innerhalb von 2,5 Monaten Betrieb (Desktop-Rechner) auf stolze ~1GB angewachsen sind. Pro Bootvorgang sind 8.000 .. 9.000 Zeilen Fehlermeldungen hinzugekommen, die dem Netzwerkdienst zuzuschreiben waren.
Aber das war einmal - seit ein paar Monaten läuft's rund...
Von Siff Lord am Di, 23. September 2014 um 07:12 #
Tolle Wurst. Wielange gibt es systemD nun schon? Und dann sowas und gerade in FC das ja selbst DIE systemD-Referenz ist (alles RH Leute die sich an systemD austoben). Das ist noch lange nicht ausgereift. Typische Lennartware halt.
Kannst du das bitte etwas naeher erlaeutern? Ein Log-Dienst hat nun mal die Aufgabe zu loggen, und wenn eine Anwendung viele Log-Meldungen ausgibt muss es dementsprechend viele Meldungen speichern. Ich verstehe das Problem somit nicht wirklich.
Nur um ihn ins rechte Licht zu rücken: 1. Der Autor beschwert sich, dass eine embedded DB namens LMDB ignoriert wurde 2. Dieser Autor ist jedoch gleichzeitig der Inhaber von Symas Corp, der Firma hinter LMDB.
Kurzum: Es geht nicht um Kritik an systemd. Es geht um die Bewerbung einer Lösung aus seinem Haus.
Dies bedeutet nicht, das LMDB keine valide Lösung sein mag. Dennoch sollte man sich dann doch lieber auf eine neutrale Quelle zu solch einem Thema stützen, nicht auf eine Partei, die eigene Interessen in solch einem Punkt vertritt.
Sonst müssten wir auch alle Microsoft glauben, das ihre Lösungen immer die besten sind
Nebenher gibt es hunderte vergleichbare Lösungen. Seine Lösung mag aus seiner Sicht die beste sein, aber er ist eben auch nicht zwingend neutral.
Er bemängelt das lieber ein eigenes Format genommen wurde, was nachweislich zu Bugs führt. Abhilfe solle höhere Systemd Versionen schaffen, so Lenny. Tolles Verständnis von Qualität und Verantwortung.
Allerdings hat LP auch gründe für seine Entscheidung genannt. Man mag darin einen Fehler sehen, soweit ich sehe, hat aber niemals jemand die Lösung dieses Herrn vorgeschlagen, auch er selbst nicht.
Insofern ist es etwas heuchlerisch sich im nachhinein zu beschweren. Selbst wenn diese Lib die perfekte Wahl gewesen wäre, so kann man LP kaum vorwerfen, nicht JEDE denkbare Lösung zu kennen.
Es ist immer leicht, im Nachhinein eine Entscheidung anzugreifen. Vor allem, wenn man nichts getan hat, um diese zu Ändern. Das ist eine sehr komfortable Position, findest du nicht auch? ...
Ansonsten sei gesagt, das auch LMDB sicher nicht direkt von der ersten Version an perfekt war. Keine Software ist das. Auch die systemds Komponenten reifen weiter. Daher ja, der Verweis auf eine spätere Version von systemd ist akzeptabel. Gefundene Probleme werden üblicherweise mit neuen Versionen gelöst, dafür werden sie ja gemacht.
Speziell OSS wird nunmal üblicherweise in vielen kurzen Releases veröffentlicht, bei denen Fixe in den neuen Versionen kommen. Da ist systemd keine Ausnahme.
Ob zudem LMDB wirklich die Probleme lösen würde, kann von uns hier keiner sagen. Aktuell ist es eine reine Behauptung aus dem Artikel.
Was heißt hier im Nachhinein? Wenn der Blogautor es selbst schafft sich mal eine Woche hinzusetzen und die Datenbanken nach den Anforderungen zu testen, hätte man das auch von Lenny erwarten können. In den Mailinglist schauts jedenfalls nicht so aus, als hätte er den Markt vorher sondiert.
"Was heißt hier im Nachhinein? Wenn der Blogautor es selbst schafft sich mal eine Woche hinzusetzen und die Datenbanken nach den Anforderungen zu testen,"
Wie gesagt ist das nicht die Situation, die hier vorliegt. Der Blogauto IST der Autor einer der Lösungen (LMDB/MDB), die zudem ziemlich unbekannt ist (im Vergleich zu anderen Lösungen) Die Vergleiche mit den anderen Datenbanken wurde auch nicht für diesen Beitrag erstellt, dies ist Teil der Werbung für diese Lösung. Sie Benchmarks sind bereits deutlich älter.
Das LP zudem keine Evaluation der Lösungen durchgeführt hat, kannst du irgendwie belegen? Da seine Argumente gegen die existierenden Lösungen recht sinnvoll klingen, halte ich eine "nicht-Betrachtung" dieser anderen Lösungen für unwahrscheinlich.
Auch der Fragesteller in einem der Threads stimmt zu, das die meisten Datenbanken die Anforderungen nicht erfüllen, oder viele andere Probleme haben (BerkleyDB...).
Für mich ist die Sache wie folgt: Der Entwickler einer unbeachteten Lösung kommt und beschwert sich, weit nachdem die Entscheidung getroffen wurde, dass seine Eierlegende Wollmilchsau nicht als Basis genommen wurde. Natürlich sprechen seine Benchmarks zu 100% für seine Lösung. Auch alle Vorteile sprechen nur für seine Lösung. So wie bei allen Entwicklern, die man jemals irgendwo fragen wird. Ihre Lösung ist immer sehr gut...
Solche Aussagen sollte man mit großer Vorsicht geniesen. Solange keine neutrale Stelle sich die Mühe gemacht hat, die Punkte zu prüfen, ist das alles erstmal wenig wert.
Wir haben es hier aber NICHT mit einer neutralen Stelle zu tun. Und das sollte man nicht aus den Augen verlieren.
Das bedeutet natürlich auch, das LP falsch liegen kann. Aber nur weil der Entwickler einer DB-Lösung seine für besser hält, hat er nicht automatisch recht.
Kann bestätigen, dass die Log's auf diesem System auch innerhalb von 2,5 Monaten Betrieb (Desktop-Rechner) auf stolze ~1GB angewachsen sind.
Pro Bootvorgang sind 8.000 .. 9.000 Zeilen Fehlermeldungen hinzugekommen, die dem Netzwerkdienst zuzuschreiben waren.
Aber das war einmal - seit ein paar Monaten läuft's rund...
Tolle Wurst. Wielange gibt es systemD nun schon? Und dann sowas und gerade in FC das ja selbst DIE systemD-Referenz ist (alles RH Leute die sich an systemD austoben). Das ist noch lange nicht ausgereift. Typische Lennartware halt.
Kannst du das bitte etwas naeher erlaeutern? Ein Log-Dienst hat nun mal die Aufgabe zu loggen, und wenn eine Anwendung viele Log-Meldungen ausgibt muss es dementsprechend viele Meldungen speichern. Ich verstehe das Problem somit nicht wirklich.
Vielleicht hilft das weiter: https://www.linkedin.com/today/post/article/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd
Was genau soll dieser Beitrag aussagen?
Nur um ihn ins rechte Licht zu rücken:
1. Der Autor beschwert sich, dass eine embedded DB namens LMDB ignoriert wurde
2. Dieser Autor ist jedoch gleichzeitig der Inhaber von Symas Corp, der Firma hinter LMDB.
Kurzum: Es geht nicht um Kritik an systemd. Es geht um die Bewerbung einer Lösung aus seinem Haus.
Dies bedeutet nicht, das LMDB keine valide Lösung sein mag.
Dennoch sollte man sich dann doch lieber auf eine neutrale Quelle zu solch einem Thema stützen, nicht auf eine Partei, die eigene Interessen in solch einem Punkt vertritt.
Sonst müssten wir auch alle Microsoft glauben, das ihre Lösungen immer die besten sind
Nebenher gibt es hunderte vergleichbare Lösungen. Seine Lösung mag aus seiner Sicht die beste sein, aber er ist eben auch nicht zwingend neutral.
Er bemängelt das lieber ein eigenes Format genommen wurde, was nachweislich zu Bugs führt. Abhilfe solle höhere Systemd Versionen schaffen, so Lenny. Tolles Verständnis von Qualität und Verantwortung.
Allerdings hat LP auch gründe für seine Entscheidung genannt.
Man mag darin einen Fehler sehen, soweit ich sehe, hat aber niemals jemand die Lösung dieses Herrn vorgeschlagen, auch er selbst nicht.
Insofern ist es etwas heuchlerisch sich im nachhinein zu beschweren. Selbst wenn diese Lib die perfekte Wahl gewesen wäre, so kann man LP kaum vorwerfen, nicht JEDE denkbare Lösung zu kennen.
Es ist immer leicht, im Nachhinein eine Entscheidung anzugreifen. Vor allem, wenn man nichts getan hat, um diese zu Ändern. Das ist eine sehr komfortable Position, findest du nicht auch? ...
Ansonsten sei gesagt, das auch LMDB sicher nicht direkt von der ersten Version an perfekt war. Keine Software ist das.
Auch die systemds Komponenten reifen weiter. Daher ja, der Verweis auf eine spätere Version von systemd ist akzeptabel. Gefundene Probleme werden üblicherweise mit neuen Versionen gelöst, dafür werden sie ja gemacht.
Speziell OSS wird nunmal üblicherweise in vielen kurzen Releases veröffentlicht, bei denen Fixe in den neuen Versionen kommen. Da ist systemd keine Ausnahme.
Ob zudem LMDB wirklich die Probleme lösen würde, kann von uns hier keiner sagen. Aktuell ist es eine reine Behauptung aus dem Artikel.
Was heißt hier im Nachhinein? Wenn der Blogautor es selbst schafft sich mal eine Woche hinzusetzen und die Datenbanken nach den Anforderungen zu testen, hätte man das auch von Lenny erwarten können. In den Mailinglist schauts jedenfalls nicht so aus, als hätte er den Markt vorher sondiert.
"Was heißt hier im Nachhinein? Wenn der Blogautor es selbst schafft sich mal eine Woche hinzusetzen und die Datenbanken nach den Anforderungen zu testen,"
Wie gesagt ist das nicht die Situation, die hier vorliegt.
Der Blogauto IST der Autor einer der Lösungen (LMDB/MDB), die zudem ziemlich unbekannt ist (im Vergleich zu anderen Lösungen)
Die Vergleiche mit den anderen Datenbanken wurde auch nicht für diesen Beitrag erstellt, dies ist Teil der Werbung für diese Lösung.
Sie Benchmarks sind bereits deutlich älter.
Das LP zudem keine Evaluation der Lösungen durchgeführt hat, kannst du irgendwie belegen? Da seine Argumente gegen die existierenden Lösungen recht sinnvoll klingen, halte ich eine "nicht-Betrachtung" dieser anderen Lösungen für unwahrscheinlich.
Auch der Fragesteller in einem der Threads stimmt zu, das die meisten Datenbanken die Anforderungen nicht erfüllen, oder viele andere Probleme haben (BerkleyDB...).
Für mich ist die Sache wie folgt:
Der Entwickler einer unbeachteten Lösung kommt und beschwert sich, weit nachdem die Entscheidung getroffen wurde, dass seine Eierlegende Wollmilchsau nicht als Basis genommen wurde.
Natürlich sprechen seine Benchmarks zu 100% für seine Lösung. Auch alle Vorteile sprechen nur für seine Lösung. So wie bei allen Entwicklern, die man jemals irgendwo fragen wird. Ihre Lösung ist immer sehr gut...
Solche Aussagen sollte man mit großer Vorsicht geniesen. Solange keine neutrale Stelle sich die Mühe gemacht hat, die Punkte zu prüfen, ist das alles erstmal wenig wert.
Wir haben es hier aber NICHT mit einer neutralen Stelle zu tun. Und das sollte man nicht aus den Augen verlieren.
Das bedeutet natürlich auch, das LP falsch liegen kann. Aber nur weil der Entwickler einer DB-Lösung seine für besser hält, hat er nicht automatisch recht.