[vz-dev] Hallo

Justin Otherguy justin at justinotherguy.org
Thu May 27 01:13:39 CEST 2010


Hi,

Am 25.05.2010 um 11:13 schrieb Steffen Vogel:

> On Tue, 25 May 2010 07:07:53 +0200, Justin Otherguy
> <justin at justinotherguy.org> wrote:
>>> Was hällst du von einem zentralen Wiki? Diese
>>> statische Hauptseite auf volkszaehler.org könnten man damit auch gut
>>> abdecken.
>> ich ziehe derzeit ein extern gehostetes Wiki vor - wenn wir da allerdings
>> nix G'scheites(TM) finden, können wir auch ein $WHATEVERWIKI auf
>> volkszaehler.org aufsetzen.
>> 
> Ich habe mich selber noch nie so mit externem Hosting beschäftigt. Ich
> ziehe die eigene Variante vor.
> Hier hab ich einfach mehr Kontrolle, über Daten, Passwörter etc.. Backups
> etc..
...muss mich aber auch um all das kümmern ;-)

Im Ernst: ich finde, wir sollten das nur dann selbst betreiben, wenn wir einen guten Grund dafür haben.
Wenn wir das selbst machen, ist's halt einfach auch mehr Arbeit. Und die würde ich lieber für das Projekt aufwänden.

Wenn wir uns das dann mal anders überlegen, können wir immer noch wechseln (ist schon klar - der Umzug ist dann aufwändiger - aber: vielleicht kommt's dazu ja nie?)

> Und falls auch ein BT auf dem Server laufen würde. Warum dann kein Wiki?
s.o.: haben wir einen guten Grund, den BT selbst zu betreiben?

> Ein DokuWiki belastet den Server auch kaum. Da viele Sachen statisch in
> eigenen Textdateien abgelegt werden.
es geht mir nicht um die Last auf dem Server, das sollte kein Problem sein. Mir geht's um die Administration, Patchen, ...

> Und wie gesagt es gibt ne Menge Plugins (Auch für Mantis btw.).
nicht falsch verstehen - das ist jetzt der Kern:
welche Features würden wir in diesen Plugins finden, die nicht nur nett, sondern richtig wichtig sind?

>>> Oh hab ich gar nicht gewusst das Github auch einen Bugtracker hat. Ja
>>> dann ist das sicherlich besser. Integriert sich bestimmt auch besser ins
>>> VCS.
>> kenne mantis und finde es gut; haben den BT von github nur gesehen, aber
>> noch nicht genauer angeschaut; lasst uns den doch einfach mal testen
> 
> Ich habe mir das github Issue System gerade mal näher angesehn. Es ist
> wirklich sehr rudimentär.
> Ich würde hier aus den gleichen Gründen wie beim Wiki für ein eigene
> Variante plädieren.
> Es stimmt zwar das Mantis hier sehr komplex ist. Aber github fehlen hier
> wirklich Funktionen,
> die auf lange Sicht unverzichtbar sind: Milestones, Zuweisen an User etc..
meine Meinung: auf lange Sicht sehe ich das genauso.

Ich möchte ungern ein Wiki, den BT (uns fällt sicher noch etwas ein) "jetzt erst mal" selbst betreiben ohne zu wissen, weshalb's jetzt schon (bald) sehr wichtig wäre.

Ich möchte vermeiden, dass wir Zeit mit den falschen Dingen zubringen - also bitte nicht falsch verstehen.

Wenn Euch gute Argumente einfallen, weshalb wir das jetzt schon selbst betreiben sollten: her damit! :-)

> rrdtool ist soweit ich informiert bin dazu bestimmt Werte einem Zeitpunkt
> zuzuweisen.
> Ältere Werte bekommen eine bestimmte Unschärve. Dadurch können wir diese
> Datenbank nicht für den
> Impulsbasierten Ansatz nutzen.
ist das nicht so, dass man den Zeitraum, ab welchem verdichtet wird, angeben kann? Was passiert, wenn man hier einen seeeehr grossen Wert einstellt?
Ist die Verdichtung überhaupt zwingend?
Wenn ja, erscheint mir rrdtool tatsächlich höchstens für die reine "alles in Flukso"-Lösung interessant. Roland schreibt mir, dass PSQL auf OpenWRT wohl vieeel zu langsam ist; mysql ist da wohl deutlich genügsamer. Es wäre spannend, wenn wir hier mal abklopfen könnten, welche DB überhaupt für den Flukso geeignet wäre:
- PSQL scheidet wohl aus
- mysql?
- sqllite?
- rrdtool?
- berkeley-db? (kennst sich damit Jemand von Euch aus?)

> Auch ist rrdtool bei keinem regulären Hoster verfügbar. Ich denke wir
> sollten rrdtool nicht auf dem Server einsetzen.
einverstanden; m.E: ist rrdtool eine Option für den Betrieb des vollständigen Volkszaehlers (Messung, Verarbeitung, Protokollierung, Auswertung) auf einer emb. Linux-Kiste (z.B. Flukso). Sobald ein "ausgewachsener" Linux-Server im Spiel ist, ist PSQL od, MySQL sicher die erste Wahl.

> Vielleicht in Zukunft mal auf einem embedded Device.
genau :-)
So weit in der Zukunft sehe ich das gar nicht mehr.

> Volkszähler soll fürs Volk sein. Das Volk hat keine Ahnung von rrdtool,
> postgresql usw..
bin nicht sicher, ob ich den Punkt richtig verstehe; tendiere zu "das Volk hat auch keine Ahnung von mysql und php und apache..."

> Einfache, quasi standarisierte, Softwarepackete sollten die Basis sein
> (php, mysql).
lass uns nicht über mysql/psql streiten - nachdem wir uns kürzlich darauf geeinigt haben, dass die Daten künftig als ms seit 1.1.1970 gespeichert werden, ist das k.o.-Kriterium für mysql ausgemerzt. Mir scheint es nicht sehr aufwändig, künftig diese beiden (und weitere - s.o.) zu unterstützen.

> Diese werden von jedem Webhostinganbieter unterstützt. Das soll jetzt
> keine Absage an postgresql sein.
> Ich liebe diese Datenbank. In der Realität sehe ich aber ihren Anteil für
> mögliche Volkszähler unter 10%.
Einverstanden - dann sind wir beinander :-)

> Find ich gut :)
> Flusko wird wohl die Auswertung, Speicherung und Visualisierung mit
> rrdtool machen.
korrekt.

> Um diese Auswertungen machen zu können, halte ich es für notwenig jeden
> Impuls in die Datenbank zu legen.
Jens ist wohl in Urlaub - sonst hätte er hier schon widersprochen :-)

Im Ernst:
obwohl ich ein grosser Fan dieser Idee war, glaube ich inzwischen, dass ein Wert pro Minute (!) wohl ausreichen wird, um die allermeisten Fragen beantworten zu können.
Anders rum: fällt Dir ein, welche Fragen sich damit nicht beantworten liessen?
Ich bin nicht sicher, was Du mit dem Leistungsspektrum und den statistischen Auswertungen meinst.

> Hier mal ein Entwurf für die Puls-Tabelle:
...das machen wir ein ander Mal - gute Nacht!

:-)


Gruss, J.



More information about the volkszaehler-dev mailing list