Laut a*log und Sofa gab's gestern Probleme bei Blogger. Ich hab mich schon gewundert über die Absenz von Updates auf manchen Logs gestern.

"The log file for database 'pyra' is full" ist keine triviale Fehlermeldung, wie man vermuten könnte. Beim log file handelt es sich nämlich um das transaction log, jenes File, in das alle Änderungen und Updates geschrieben werden bevor sie in der eigentlichen Datenbank durchgeführt werden. In regelmässigen Abständen finden sogenannte Checkpoints statt, bei denen die Datenbank mit dem Logfile abgeglichen wird. Ohne Logfile also keine Updates, und löscht man das transaction log, dann verliert man alle Änderungen seit dem letzten Checkpoint.

Erstaunlich finde ich allerdings, dass Microsoft SQL-Server nicht in der Lage ist, Logfiles zu rotieren, d.h. ein neues anzufangen wenn das alte eine gewisse Größe erreicht wie z.b. die Sleepycat Berkeley DB, die der Hop als Alternative zu externen relationalen DBs verwenden kann.

yeah, blogger wird immer stolpriger... zeit für eine "echte" Alternative für leute wie mich, die nix eigenes am server installieren dürfen...

das problem ist kein so triviales: prinzipiell gibt es drei szenarien für blogging-software. a. die software läuft auf dem eigenen server, b. die software läuft auf dem server irgendeiner firma (bspw. pyra) und spielt die daten auf den eigenen server, und c. die software läuft auf dem eigenen desktop-rechner und spielt die daten auf den server. nachdem a. für viele nicht in frage kommt und b. bei explosionsartigen popularitätssteigerungen nicht zu finanzieren ist, wäre c. eine gute alternative (man kann dann aber nicht mehr vom internet-café in teneriffa aus das log updaten ...) - ein lokal-hop/antville mit spiels-mir-noch-mal-auf-den-server-sam-funktionalität?

Hop-on-the-Desktop wäre sicher möglich, aber ich glaube nicht, dass es das bringt. Ich möchte meine Daten ganz bestimmt nicht auf einem Desktop-Rechner haben, der womöglich nicht immer zugänglich ist oder hinter einer Firewall steht.

In der derzeitigen P2P-Mania geht überhaupt irgendwie verloren, dass das ganze nur als Copyright-Umgehungsstrategie erfunden wurde. (Erfolgreich, und dem letzten Napster-Urteil zufolge auch durchaus legitim - wenn Napster es schaffen würde, den Directory/Lookup-Mechanismus auch noch zu dezentralisieren (sprich: nicht zu kontrollieren), könnte niemand oder jedenfalls nicht amerikanisches und später wahrscheinlich europäisches Recht etwas daran aussetzen. Für mich lesen viele Leute das Napster-Urteil falsch, wenn sie sich jetzt fragen wie Napster zurückrudern kann, anstatt wo Napster zuwenig weit gegangen ist.)

Ich glaube das derzeitige Problem liegt nicht so sehr im was-läuft-wo (sowohl a als auch b sind praktikabel, zu einem gewissen Grad auch c) als aus dem wer-hütet-was. Dave hütet Manila, und Ev hütet Blogger. Ich denke in zwei Jahren wird es mehr Leute geben, die das rückblickend komisch finden.

Naja, den Lookup-Mechanismus zu dezentralisieren ist dann auch die schwierigere Übung von beiden (v.a. stellt sich die Frage, wie dezentral ein solches System überhaupt sein kann, damit es praktikabel bleibt - hast Du das Gnutella-Rebuttal eines der Napstengineers gelesen?). Ceterum censeo, dass Napster sowieso bestenfalls P2P halbe ist - den bandwidth-intensiven (und damit teuren) und copyrightish brisanten File-Transfer auf den Rücken der User-Rechner outgesourced, den (theoretisch) marketing-mässig relevanten Usage-Patterns liefernden Directory-Mechanismus zentralisiert. Sehr klug.

Um zur Log-Infrastruktur zurückzukommen: Szenario a. ist (pour moi) das Optimum - für viele, viele andere dürfte es b. sein. c. hat eher Krückencharakter (obwohl mir irgendetwas an der Idee gefällt ... vor allem in Kombination mit Syncing ...)

Und weil wir grade bei Directory-Mechanismen waren ... ;-)

Ja, stimmt, Variante c hat viel Potential, wenn der lokale Speicher keine Einbahnstrasse ist. Bin gespannt was Userlands Cloud-Fantasien diesbezüglich bringen.

(chronistin, chris, henso) - hey, wieder so ein kleines kühles detail. great idea!

Ja, ich geniesse gerade das Hacken auf henso. Kleine Änderung. Wirken lassen. Entscheiden. And all over again. Für mich gibt's wirklich keinen Ersatz für Lösung a)!

Erst war ich verwirrt wegen der zwei 'Montag, 26...' header. Dann....okay, hier werden (1)dein content und (2)zugehoerige comments gesplittet. Das macht Sinn auch im Zusammenhang mit dem 'Flach-Diskusionssystem', easycome, easygo.
Eine zusaetzliche optische Kennzeichnung der Postingzeit (16:28>16:56), zb. bgcolor, ließe ein update eventuell rascher erkennen. nungut

Not logged in. Click here to log in.