Lude: Fragen zur Archivierung und Anzahl der Zugriife

Hi,

zwei Fragen zu diesem Forum:
1.) Wie genau funktioniert die Archivierung? Mich interessiert da schonn die Formel. Eventuell genuegt mir der Code und ein paar erlaeuternde Saetze.
2.) Wieviele Zugriffe pro Stunde hat der Server zu verarbeiten? - Ich darf davon ausgehen, dass jeweils 500KB Daten gesendet werden?

Gruss,
Lude

PS: Eine dritte Frage ist verspaetet hunzugekommen:
Was kann man aus "<META content="MSHTML 6.00.2800.1106" name=GENERATOR>" schliessen?

PPS: Schoene frohe Weihnachten an Alle!

  1. Hallo Lude,

    2.) Wieviele Zugriffe pro Stunde hat der Server zu verarbeiten? - Ich darf davon ausgehen, dass jeweils 500KB Daten gesendet werden?

    dazu dürfte dich http://webalizer.teamone.de/ interessieren (vorallem http://webalizer.teamone.de/selfforum/) - 500KB halte ich aber für etwas sehr viel (was soll so viel haben?)

    Was kann man aus "<META content="MSHTML 6.00.2800.1106" name=GENERATOR>" schliessen?

    das die Seite schrott ist :-) *scnr* - nein, ich vermute mal, dass irgend ein M$-Programm die Seite erstellt hat (vielleicht IE6?).

    PPS: Schoene frohe Weihnachten an Alle!

    ebenfalls :-)

    Grüße aus Nürnberg
    Tobias

  2. 1.) Wie genau funktioniert die Archivierung?
    Mich interessiert da schonn die Formel.
    Eventuell genuegt mir der Code und ein paar
    erlaeuternde Saetze.

    http://cforum.teamone.de/
    http://cvs.teamone.de/selfforum/

    2.) Wieviele Zugriffe pro Stunde hat der
    Server zu verarbeiten? - Ich darf davon
    ausgehen, dass jeweils 500KB Daten gesendet
    werden?

    http://webalizer.teamone.de/selfforum/

    1. Hi ( CK ?),

      1.) Wie genau funktioniert die Archivierung?
      Mich interessiert da schonn die Formel.
      Eventuell genuegt mir der Code und ein paar
      erlaeuternde Saetze.

      http://cforum.teamone.de/
      http://cvs.teamone.de/selfforum/

      ich bat um die Formel, die zu archiviernde Threads aus der "XML-Hauptdatei" entfernt. Kann man mir die betreffende Stelle im Code, eventuell sogar leicht kommentiert, zeigen?

      2.) Wieviele Zugriffe pro Stunde hat der
      Server zu verarbeiten? - Ich darf davon
      ausgehen, dass jeweils 500KB Daten gesendet
      werden?

      http://webalizer.teamone.de/selfforum/

      <<
      aha, nur das Forum. Sehr interessant auch die Stundenstatistik. Zudem einen Rekord(?) in der kalten Winterszeit!

      Gruss,
      Lude

      1. Hallo Lude,

        Hi ( CK ?),

        Steht da 'Christian Kruse' im 'Name'-Feld? :)

        ich bat um die Formel, die zu archiviernde Threads aus der "XML-Hauptdatei" entfernt.

        Gibts nicht.

        Kann man mir die betreffende Stelle im Code, eventuell sogar leicht kommentiert, zeigen?

        Ehm, warum habe ich den Source offengelegt? Ich glaube, das naechste wird closed source... da kann ich dann Geld dafuer verlangen >;)) Aber gut, Ausnahmsweise ;)

        void run_archiver_and_write_to_disk(void) {   /* helper variables */   t_thread *t,*t1 = NULL,*oldest_t,*prev = NULL,**to_archive = NULL,*oldest_prev;   t_posting *p,*oldest,*newest_in_t;   long size,threadnum,pnum;   int status,shall_archive = 0,len = 0;   char buff[256];   pid_t pid;

        /* configuration entries */   t_name_value *max_bytes      = cfg_get_value(&fo_default_conf,"MainFileMaxBytes");   t_name_value *max_posts      = cfg_get_value(&fo_default_conf,"MainFileMaxPostings");   t_name_value *max_threads    = cfg_get_value(&fo_default_conf,"MainFileMaxThreads");   t_name_value  *mpath         = cfg_get_value(&fo_default_conf,"MessagePath");

        /* Helper-Variables for XML-Handling */   GdomeDOMImplementation *impl = gdome_di_mkref();   GdomeException e;   GdomeDocument *doc           = xml_create_doc(impl,FORUM_DTD);   GdomeElement *el             = gdome_doc_documentElement(doc,&e);

        /*    * we archive as long as a criterium matches, but the check has to be done    * at least once.    /   do {     /      * read-lock the head variable      */     if((status = pthread_rwlock_rdlock(&head.lock)) != 0) {       fo_log(LOG_ERR,FILE,LINE,"pthread_rwlock_rdlock: %s\n",strerror(status));       RUN = 0;       return;     }

        /*      * initialization of the helper variables      */     size          = head.cache_invisible.len;     t             = head.thread;     threadnum     = 0;     pnum          = 0;     shall_archive = 0;     oldest        = NULL;     oldest_t      = NULL;     oldest_prev   = NULL;     newest_in_t   = NULL;

        /*      * unlock the head-variable      */     pthread_rwlock_unlock(&head.lock);

        /*      * run through all threads in the forum      /     do {       /        * read-lock the actual thread        */       if((status = pthread_rwlock_rdlock(&t->lock)) != 0) {         fo_log(LOG_ERR,FILE,LINE,"pthread_rwlock_rdlock: %s\n",strerror(status));         RUN = 0;         return;       }

        /*        * we found one more thread        */       threadnum++;

        /*        * find the newest posting in this thread and count the postings        */       newest_in_t = NULL;       for(p=t->postings;p;p=p->next) {         if(!newest_in_t || newest_in_t->date < p->date) {           newest_in_t = p;         }

        pnum++;       }

        /*        * check if the thread has a posting elder than the oldest posting before; if yes,        * re-set the helper variables        */       if(!oldest || newest_in_t->date < oldest->date) {         oldest      = newest_in_t;         oldest_t    = t;         oldest_prev = prev;       }

        /* go to the next thread */       prev = t1;       t1   = t->next;       pthread_rwlock_unlock(&t->lock);       t    = t1;     } while(t);

        /*      * has the main file more bytes than the configuration limit? If yes, archive a thread      */     if(size > max_bytes->lvals[0]) {       shall_archive = 1;       fo_log(LOG_STD,FILE,LINE,"Archiver: Criterium: max bytes, Values: Config: %ld, Real: %ld\n",max_bytes->lvals[0],size);     }

        /*      * are there more postings than allowed via config? If yes, archive the oldest thread      */     if(pnum > max_posts->lvals[0]) {       shall_archive = 1;       fo_log(LOG_STD,FILE,LINE,"Archiver: Criterium: max posts, Values: Config: %ld, Real: %ld\n",max_posts->lvals[0],pnum);     }

        /*      * are there more threads as given in the config? If yes, archive.      */     if(threadnum > max_threads->lvals[0]) {       shall_archive = 1;       fo_log(LOG_STD,FILE,LINE,"Archiver: Criterium: max threads, Values: Config: %ld, Real: %ld\n",max_threads->lvals[0],threadnum);     }

        /*      * does any of the criteriums match? If yes, push the oldest thread in the tree to an      * array.      */     if(shall_archive) {       to_archive        = realloc(to_archive,++len * sizeof(t_thread *));       to_archive[len-1] = oldest_t;

        /*        * is there a thread before? If yes, lock it and re-set the next-pointer. If not,        * we have to re-set the head.thread-pointer.        */       if(oldest_prev) {         if((status = pthread_rwlock_wrlock(&oldest_prev->lock)) != 0) {           fo_log(LOG_ERR,FILE,LINE,"pthread_rwlock_wrlock: %s\n",strerror(status));           RUN = 0;           return;         }

        oldest_prev->next = oldest_t->next;         pthread_rwlock_unlock(&oldest_prev->lock);       }       else {         if((status = pthread_rwlock_wrlock(&head.lock)) != 0) {           fo_log(LOG_ERR,FILE,LINE,"pthread_rwlock_wrlock: %s\n",strerror(status));           RUN = 0;           return;         }

        head.thread = oldest_t->next;         pthread_rwlock_unlock(&head.lock);       }

        /*        * generate a new cache        */       generate_cache(NULL);     }

        /*    * run archiver as long as any of the criteriums matches    */   } while(shall_archive);

        fo_log(LOG_DBG,FILE,LINE,"archiver ran. Writing threadlists...\n");

        /*    * at all, the threads to archive are out of the main-file. So go and write the main file    * and the thread files.    */   if((status = pthread_rwlock_rdlock(&head.lock)) != 0) {     fo_log(LOG_ERR,FILE,LINE,"pthread_rwlock_rdlock: %s\n",strerror(status));     RUN = 0;     return;   }

        t = head.thread;

        sprintf(buff,"m%lld",head.mid);   xml_set_attribute(el,"lastMessage",buff);

        sprintf(buff,"t%lld",head.tid);   xml_set_attribute(el,"lastThread",buff);

        gdome_el_unref(el,&e);   pthread_rwlock_unlock(&head.lock);

        /*    * very nasty workaround for a memory leek in the gdome lib    *    * Hm, this has a nice effect: normally when the archiver runs, the    * server would lag a little bit. But since all expensive operations    * are done in a child process, the server itself would not lag longer    /   pid = fork();   switch(pid) {   / error */   case -1:     fo_log(LOG_ERR,FILE,LINE,"fork: %s\n",strerror(errno));     break;

        /* child actions /   case 0:     / go through the thread list and "stringify" the threads */     do {       if((status = pthread_rwlock_rdlock(&t->lock)) != 0) {         fo_log(LOG_ERR,FILE,LINE,"pthread_rwlock_rdlock: %s\n",strerror(status));         exit(0);       }

        stringify_thread_and_write_to_disk(doc,t);

        t1   = t->next;       pthread_rwlock_unlock(&t->lock);       t    = t1;     } while(t);

        /* write the main file */     snprintf(buff,256,"%s/forum.xml",mpath->cvals[0]);

        if(!gdome_di_saveDocToFile(impl,doc,buff,0,&e)) {       fo_log(LOG_ERR,FILE,LINE,"ERROR! COULD NOT WRITE XML FILE!\n");     }     gdome_doc_unref(doc,&e);

        /* child has done all work */     exit(0);     break;

        /* main program actions. We just wait for the child */   default:     fo_log(LOG_STD,FILE,LINE,"archiver started....\n");     wait(&pid);     break;   }

        /* delete the main file document */   gdome_doc_unref(doc,&e);

        /* are there threads to archive? If yes, write them to the archive. */   if(len) {     long i;     pid = fork();

        /* nasty workaround... */     switch(pid) {     case -1:       fo_log(LOG_ERR,FILE,LINE,"fork: %s\n",strerror(errno));       break;     case 0:       archive_threads(to_archive,len);       exit(0);     default:       fo_log(LOG_DBG,FILE,LINE,"waiting for archive_threads\n");       wait(&pid);       break;     }

        /* when all threads have been written, free allocated memory */     for(i=0;i<len;i++) {       t_posting *p = NULL,*p1 = NULL;

        for(p=to_archive[i]->postings;p;p=p1) {         free(p->user.name);         free(p->user.ip);         free(p->subject);         free(p->unid);         free(p->content);         if(p->user.email) free(p->user.email);         if(p->user.img) free(p->user.img);         if(p->user.hp) free(p->user.hp);         if(p->category) free(p->category);

        p1 = p->next;         free(p);       }     }

        free(to_archive);   }

        /* we don't need any longer the DOM-Implementation */   gdome_di_unref(impl,&e); }

        Gruesse,  CK

        1. Hi.

          schoenes Stueck Code.

          /*
               * has the main file more bytes than the configuration limit? If yes, archive a thread
               */
              if(size > max_bytes->lvals[0]) {
                shall_archive = 1;
                fo_log(LOG_STD,__FILE__,__LINE__,"Archiver: Criterium: max bytes, Values: Config: %ld, Real: %ld\n",max_bytes->lvals[0],size);
              }

          /*
               * are there more postings than allowed via config? If yes, archive the oldest thread
               */
              if(pnum > max_posts->lvals[0]) {
                shall_archive = 1;
                fo_log(LOG_STD,__FILE__,__LINE__,"Archiver: Criterium: max posts, Values: Config: %ld, Real: %ld\n",max_posts->lvals[0],pnum);
              }

          /*
               * are there more threads as given in the config? If yes, archive.
               */
              if(threadnum > max_threads->lvals[0]) {
                shall_archive = 1;
                fo_log(LOG_STD,__FILE__,__LINE__,"Archiver: Criterium: max threads, Values: Config: %ld, Real: %ld\n",max_threads->lvals[0],threadnum);
              }

          Habe allerdings dem Code nicht entnehmen koennen a) wieviele Byte erlaubt sind b)wie viele Postings erlaubt sind c) wieviele Threads erlaubt sind und d) welche(r) Thread(s) dann archiviert wird.

          d) haette ich mit besseren Kenntnissen der verwendeten Sprache vielleicht eruieren koennen, aber ich hatte Angst, dass der Thread archiviert wird; und zwar bevor ich den Code in diesem Punkt verstanden habe.

          Gruss,
          Lude

          PS: Du setzt Klammern (offene und geschweifte) nicht untereinander (selbe "x-Pos"). Ist das "fuer Deine Augen" kein Problem?

          1. Hallo Lude,

            Habe allerdings dem Code nicht entnehmen
            koennen a) wieviele Byte erlaubt sind b) wie
            viele Postings erlaubt sind c) wieviele
            Threads erlaubt sind und

            Das wirst du auch nicht erfahren :) Das ist
            konfigurierbar, die genauen Werte werde ich nicht
            bekannt geben.

            d) welche(r) Thread(s) dann archiviert wird.

            *seufz* Warum liest du es nicht in der FAQ nach?
            Hm, ich sehe gerade, die obigen Punkte stehen
            auch in der FAQ. Warum hast du es nicht dort
            nachgelesen? Zitat:

            |Die Archivierung funktioniert im neuen Forum
            |vollautomatisch. Bei jeder neu geposteten
            |Nachricht werden verschiedene Faktoren überprüft.
            |Dazu gehören die Größe der Forumshauptdatei, die
            |Anzahl der aktuellen Nachrichten, und die Anzahl
            |der aktuellen Threads. In der Forumskonfiguration
            |sind dafür bestimmte Schwellwerte eingestellt.
            |Werden die Schwellwerte durch eine neue Nachricht
            |überschritten, dann werden Threads aus der
            |Forumshauptdatei entfernt, damit die
            |Forumshauptdatei nicht bis in alle Ewigkeit
            |anwächst.
            |
            |Entfernt wird jedoch nicht einfach "unten" in
            |der Forumshauptdatei. Entfernt werden vielmehr
            |jene Threads, in denen am längsten nichts
            |gepostet wurde. Das sind die Threads mit den
            |ältesten Nachrichten, aber nicht unbedingt die
            |ältesten Threads (sofern darin aktuellere
            |Nachrichten enthalten sind). Diese Auswahl hat
            |den Zweck, daß Threads, die zwar jünger, aber
            |längst ausdiskutiert sind, eher verschwinden,
            |als solche, die zwar älter sind, in denen aber
            |noch länger diskutiert wurde. Sehr lebendige
            |Threads können auf diese Weise recht lange in
            |der aktuellen Forumshauptdatei "überleben".

            Und so weiter, und so fort. Quelle:

            </faq/#Q-31>

            PS: Du setzt Klammern (offene und geschweifte)
            nicht untereinander (selbe "x-Pos"). Ist das
            "fuer Deine Augen" kein Problem?

            Nein, im Gegenteil. Die Klammern in die neue
            Ebene zu ziehen erschwert IMHO die Lesbarkeit des
            Codes erheblich.

            Gruesse,
             CK

            1. Hi CK,

              Das wirst du auch nicht erfahren :) Das ist
              konfigurierbar, die genauen Werte werde ich nicht
              bekannt geben.

              Wenn Du die Werte auf Anfrage bekannt gibst, ist die Sache transparent. Andernfalls kann administrativer Eingriff zumindest vermutet werden.

              d) welche(r) Thread(s) dann archiviert wird.

              *seufz* Warum liest du es nicht in der FAQ nach?
              Hm, ich sehe gerade, die obigen Punkte stehen
              auch in der FAQ. Warum hast du es nicht dort
              nachgelesen? Zitat:

              |Entfernt wird jedoch nicht einfach "unten" in
              |der Forumshauptdatei. Entfernt werden vielmehr
              |jene Threads, in denen am längsten nichts
              |gepostet wurde. Das sind die Threads mit den
              |ältesten Nachrichten, aber nicht unbedingt die
              |ältesten Threads (sofern darin aktuellere
              |Nachrichten enthalten sind). Diese Auswahl hat
              |den Zweck, daß Threads, die zwar jünger, aber
              |längst ausdiskutiert sind, eher verschwinden,
              |als solche, die zwar älter sind, in denen aber
              |noch länger diskutiert wurde. Sehr lebendige
              |Threads können auf diese Weise recht lange in
              |der aktuellen Forumshauptdatei "überleben".

              Habe ich natuerlich gelesen. - Mich hat interessiert, ob die Aussage, dass Threads in denen sich zuletzt am wenigsten getan hat, entfernt werden, auch stimmt. - Meine stichprobenartigen Beobachtungen liessen mich darauf nicht schliessen, womit ich natuerlich nichts unterstellen moechte.

              </faq/#Q-31>

              PS: Du setzt Klammern (offene und geschweifte)
              nicht untereinander (selbe "x-Pos"). Ist das
              "fuer Deine Augen" kein Problem?

              Nein, im Gegenteil. Die Klammern in die neue
              Ebene zu ziehen erschwert IMHO die Lesbarkeit des
              Codes erheblich.

              Danke fuer Dein Statement. Ich bin irgendwie whitespace-Fetischist geworden; Einrueckungen fast wie bei Tags ueblich vermisse ich dann dummerweise auch in den Sourcen.

              Gruss,
              Lude

              1. Hi Lude,

                Du willst ja nichts unterstellen, aber...

                Wenn Du die Werte auf Anfrage bekannt gibst, ist die Sache transparent. Andernfalls kann administrativer Eingriff zumindest vermutet werden.

                Entschuldige, wenn ich mich da mal leicht genervt einmische, weil so oft in der letzten Zeit jemand mit solchen "Vermutungen" um die Ecke gekommen ist. Auch wenn es einigen Spaß macht, solche Dinge immer wieder in den Raum zu stellen: Hier wird nicht händisch daran herumgefummelt, missliebige Threads eher zu archivieren. Gelöscht werden lediglich Threads, die aus juristischen Gründen problematisch sind, d.h. Links zu Warez-Seiten, persönliche Beleidigungen usw., manchmal macht sich auch jemand die Mühe, von zwei gleichen Postings, die jemand mit nervösen Fingern direkt hintereinander gesetzt hat, eins zu entfernen.

                Wenn Du die Debatten der letzten Zeit verfolgt hast, müsstest Du wissen, dass auch Postings, in denen Devs massiv angegriffen werden, ohne irgendwelche Manipulationen im Forum bleiben. Wir halten ganz schön was aus, oder? *g*

                Aber: Die Unterstellungen nerven!

                Außerdem: Der Grenzwert für die Größe der Forumshauptdatei liegt doch offen zu Tage, beobachte es doch mal ein paar Tage lang.

                Und: Was willst Du erreichen? Willst Du nachrechnen, welcher Thread jetzt als nächster dran ist? Das dürfte doch außerordentlich schwer fallen, denn Du müsstest Dir den Zustand der Forumshauptdatei genau vor und nach dem Archivierungszeitpunkt sichern und jetzt selbst das Script darüber laufen lassen, was ja sowieso passiert. Ein bisschen Vertrauen in diesen Diskussionszusammenhang wäre vielleicht der bessere Weg.

                In den internen Diskussionen werden solche Fragen ganz anders diskutiert. Um mal zwei Beispiele zu bringen:

                • Welche Größe der Forumshauptdatei ist in Hinsicht auf Ladezeiten, Traffic und die Verbesserung der Software machbar?
                • Welche Wirkung haben extrem große Threads auf das Forum, wie schnell verschwinden dadurch interessante Fragen, auf die man nicht so schnell antworten kann, im Archiv? Die beiden Riesen, die zur Zeit in der Hauptdatei sind, entfalten da einige Wirkung.

                Solche und ähnliche Fragen gibt es und Christian versucht hier immer wieder, durch Feineinstellung das Optimale für alle Poster zu erreichen. Eine inhaltliche Kontrolle findet nur in dem Rahmen statt, der juristisch vorgeschrieben ist, Kriterien siehe FAQ und oben. Wir haben in dieser Hinsicht übrigens wenig Arbeit, hier muss nur sehr sehr selten händisch eingegriffen werden. Und im Zweifelsfall gehen wir eher das Risiko ein, Ärger zubekommen, als eine Diskussion zu unterbinden. Auch das könnte man durch "stichprobenartige Beobachtungen" feststellen, wenn man nur wollte... Ist denn nicht spürbar, dass uns die Offenheit der Diskussion wirklich wichtig ist?

                Habe ich natuerlich gelesen. - Mich hat interessiert, ob die Aussage, dass Threads in denen sich zuletzt am wenigsten getan hat, entfernt werden, auch stimmt. - Meine stichprobenartigen Beobachtungen liessen mich darauf nicht schliessen, womit ich natuerlich nichts unterstellen moechte.

                Au Mann, schon wieder! Na ja, wir werden damit leben müssen.

                Leicht genervte Grüße
                Mathias Bigge

                1. Hi,

                  Leicht genervte Grüße
                  Mathias Bigge

                  also ich habe hier erlebt, dass

                  • Threads verschwinden
                  • Beitraege verschwinden
                  • Threads geloescht werden
                  • Downzeiten hoch sind

                  Natuerlich bearbeite ich solche Vorfaelle sachbezogen objektiv und tendenziell auch mit Humor. Weiss ich doch mittlerweile, dass die Devs (Christian u.a.) gute (ausgezeichnete) Arbeit leisten und sicherlich auch die moralische Berechtigung haben etwas zu spielen (zu forschen).

                  Was mir allerdings einmal sehr missfallen hat, war dass ein von mir in englischem verfasster Beitrag gekillt worden ist (da habe ich dann Herrn Muenz kontaktiert, der die Sache nicht nachverfolgen konnte (wollte)). Ausserdem hege ich den Verdacht, dass gelegentlich administrativ eingegriffen wird. Da ich das nicht belegen kann, sollte ich den Verdacht wahrscheinlich wirklich nicht kommunizieren. Gut.

                  Wenn bestimmte Konfigurationswerte (z.B. Wann wird archiviert?)offengelegt werden und das Loeschen von Threads/Beitragen ebenfalls nachvollziehbar gemacht wird, waere doch die Akzeptanz tendenziell besser, oder nich'?

                  Ich kann aus meinen Erfahrungen im Bereich relationale Datenhaltung sprechen: Da koennen keine Daten "verschwinden", Downzeiten wg. der Datenhaltung gaebe es auch nicht (sagen wir mal im untersten o/oo Bereich :-) und "aus juristischen Gruenden geloeschte Beitraege" wuerden (bei Bedarf) in einer Art Horrorkabinett (oeffentlicher Zugriff z.B. zu Helloween) gepflegt werden.

                  Deine Einmischungen schaetze ich uebrigens ganz besonders, wenn sie humorvoller Art sind.

                  Gruss,
                  Lude

                  1. Hi Lude,

                    Mann, bist Du misstrauisch! Es müsste doch eine Logik in den Löschungen stecken, wenn wir manipulierten. Was siehst Du denn als bevorzugtes Opfer unseres Kontrollwahns? Fragen zu PHP?
                    *g*

                    also ich habe hier erlebt, dass

                    • Threads verschwinden
                    • Beitraege verschwinden
                    • Threads geloescht werden

                    Nenne ein Beispiel, ich überprüfe es dann, wenn es möglich ist. Alle Löschungen aus den in meinem Vorposting genannten juristischen Gründen werden im Dev-Bereich dokumentiert, im Dezember wurde kein einziges gelöscht.

                    • Downzeiten hoch sind

                    Ja, die Umstellung des Forums hat einige Übergangsschwierigkeiten produziert, leider, und gerade, wenn durch Prog-Schwierigkeiten ein Thread verschwindet, ist es auch für uns nicht nachvollziehbar in dem Sinne, dass man ihn rekonstruieren könnte. Das ist ärgerlich, aber bei einer so weitgehenden Umstellung unvermeidbar. Wenn es im Einzelfall ginge, würden wir selbst eine weitere 2-Frames-Frage rekonstruieren....

                    Was mir allerdings einmal sehr missfallen hat, war dass ein von mir in englischem verfasster Beitrag gekillt worden ist (da habe ich dann Herrn Muenz kontaktiert, der die Sache nicht nachverfolgen konnte (wollte)). Ausserdem hege ich den Verdacht, dass gelegentlich administrativ eingegriffen wird. Da ich das nicht belegen kann, sollte ich den Verdacht wahrscheinlich wirklich nicht kommunizieren. Gut.

                    Mal ehrlich, warum verfasst Du hier Beiträge auf Englisch? Ein Löschungsgrund wär's trotzdem nicht. Und Stefan legt wirklich größten Wert auf Vermeidung jeder Zensur und hat es sicher überprüft. Der Beitrag kann nicht manuell gelöscht worden sein!

                    Wenn bestimmte Konfigurationswerte (z.B. Wann wird archiviert?)offengelegt werden und das Loeschen von Threads/Beitragen ebenfalls nachvollziehbar gemacht wird, waere doch die Akzeptanz tendenziell besser, oder nich'?

                    Es wäre aus mehreren Gründen Unfug:
                    1. Während der Optimierungsphase muss Christian jederzeit an den Schräubchen drehen müssen, ohne das jedesmal zu diskutieren.
                    2. Bau Dir die gesamte Umgebung nach, die Codes liegen ja offen. Selbst wenn Du das alles hast, müsste man eine eigene Programmlogik entwickeln, um zu sehen, welchen konkreten Thread eine Änderung der Parameter betreffen würde, und Du verstehst vielleicht, dass es kein Interesse gibt, sowas zu entwickeln.
                    3. Wenn wir die Diskussion gezielt manipulieren wollten, wäre es doch viel einfacher, einzelne Threads von Hand zu löschen, oder? Warum sollte man dazu solch komplexe Mechanismen aufbauen?

                    Ich kann aus meinen Erfahrungen im Bereich relationale Datenhaltung sprechen: Da koennen keine Daten "verschwinden", Downzeiten wg. der Datenhaltung gaebe es auch nicht (sagen wir mal im untersten o/oo Bereich :-) und "aus juristischen Gruenden geloeschte Beitraege" wuerden (bei Bedarf) in einer Art Horrorkabinett (oeffentlicher Zugriff z.B. zu Helloween) gepflegt werden.

                    • Ja, es gibt sie, die kritischen Bereiche, in denen wirklich versucht wird, jeden Fehler zu vermeiden und in dem man die Finanzen hat, neue Programme unter einer entsprechenden Last zu testen. Aber selbst da gibt's peinliche Fehler. Ein Beispiel: Neulich hat mir die tolle relationale Datenhaltung einer bekannten deutschen Krankenkasse ca. 7.500 Euro Monatsbeitrag abgebucht :(

                    • Du überschätzt die Interessantheit der gelöschten Beiträge. Ich nenn Dir mal ein typisches Beispiel: Da gibt's einen Thread zu irgendeinem Microsoft-Programm und jemand setzt ein Posting ab mit nenm Link auf eine Seite, auf der man das Dingen für lau und prima gehackt kriegen kann. Sowas hat in zweifacher Weise mögliche rechtliche Folgen:
                      1. Verletzung des Urheberrechts -> Ärger mit Microsoft.
                      2. Eventuell verlinken wir die neuste Virenproduktionsstätte.

                    Sowas muss man löschen und kann es auch nicht in einem Horrokabinett unterbringen, oder?

                    Ein anderer Typ sind pornographische Abbildungen, auch das wäre weniger was für ein Horrokabinett, oder? Dann gibt's justiziable persönliche Beleidigungen, auch das kann man nicht wieder ins Netz setzen, sowohl aus juristischen als auch aus menschlichen Gründen.

                    Du siehst schon, die von Dir geforderte Transparenz ist schwer realisierbar, ein bisschen Vertrauen musst Du uns schon gönnen. Solche Löschungen erfolgen stets kommentarlos, nur wenn schon jemand geantwortet hat, würden wir ihn per Mail informieren. Meist besteht die Antwort aber in der Aufforderung zur Löschung *g* Eine öffentliche Debatte über ein Warez-Posting, was sollte das bringen?

                    Nochmal zur Information: Die Anzahl der Löschungen ist sehr gering, sie werden jeweils nach Möglichkeit von mehreren Devs abgesegnet und anschließend im Dev-Forum zur Diskussion gestellt, wenn nicht aus klaren juristischen Gründen sofort gehandelt werden muss (WAREZ, Porno, s.o.). Auch bei ziemlich heftigen Angriffen auf einen der Devs mit entsprechenden Kraftausdrücken entscheiden wir eigentlich immer, es hinzunehmen, weil uns die Offenheit des Forums wichtig ist, und weil wir alle ein ziemlich dickes Fell haben, bei Beleidigung von Teilnehmern sind wir da kritischer, erwarten aber auch eine gewisse Toleranz....

                    Deine Einmischungen schaetze ich uebrigens ganz besonders, wenn sie humorvoller Art sind.

                    Danke.

                    Viele Grüße
                    Mathias Bigge

                  2. Hallo Lude,

                    also ich habe hier erlebt, dass

                    • Threads verschwinden

                    Beweis?

                    • Beitraege verschwinden

                    Sind hin und wieder welche verloren gegangen, aber
                    nur in der Anfangsphase des Forums und einigen
                    wenigen Umstellungen. Bugs halt.

                    • Threads geloescht werden

                    Beweis?

                    • Downzeiten hoch sind

                    Die Downzeiten koennen so hoch sein, wie sie
                    wollen. Hier wird keiner bezahlt, und auch du
                    bezahlst nix dafuer, dass du hier posten kannst.
                    Also schoen die Fuesse still halten.

                    Wenn bestimmte Konfigurationswerte (z.B. Wann
                    wird archiviert?)offengelegt werden und das
                    Loeschen von Threads/Beitragen ebenfalls
                    nachvollziehbar gemacht wird, waere doch die
                    Akzeptanz tendenziell besser, oder nich'?

                    Ich werde die genauen Werte nicht
                    offenlegen, denn wenn man sie kennt, kann man das
                    sehr einfach ausnutzen.

                    Ich kann aus meinen Erfahrungen im Bereich
                    relationale Datenhaltung sprechen: Da koennen
                    keine Daten "verschwinden",

                    Oh, doch, die koennen. Der MSSQL-Server hatte vor
                    kurzem noch so einen Bug, der dazu fuehrte, dass
                    Daten verloren gingen. Und auch die MySQL4-Beta
                    hatte einen solchen Bug.

                    Gruesse,
                     CK

                    1. Hi!

                      • Threads verschwinden

                      Beweis?

                      • Beitraege verschwinden
                      • Threads geloescht werden

                      Beweis?

                      Habe doch keine Daten, so dass formal nichts zu beweisen ist. - Ist halt offensichtlich _und_ ich vermute Du (oder das System) haben ihre Gruende.

                      • Downzeiten hoch sind

                      Die Downzeiten koennen so hoch sein, wie sie
                      wollen. Hier wird keiner bezahlt, und auch du
                      bezahlst nix dafuer, dass du hier posten kannst.
                      Also schoen die Fuesse still halten.

                      Wenn bestimmte Konfigurationswerte (z.B. Wann
                      wird archiviert?)offengelegt werden und das
                      Loeschen von Threads/Beitragen ebenfalls
                      nachvollziehbar gemacht wird, waere doch die
                      Akzeptanz tendenziell besser, oder nich'?

                      Ich werde die genauen Werte nicht
                      offenlegen, denn wenn man sie kennt, kann man das
                      sehr einfach ausnutzen.

                      Auf so ein Statement habe ich gehofft. - Es macht also Sinn die Werte nicht offenzulegen. Gut. - Eventuell koennte eine Formel mit "eingebauter Unbestimmtheit" offengelegt werden? OK, mag sein, dass Transparenz dann nichts mehr bringt.

                      Ich kann aus meinen Erfahrungen im Bereich
                      relationale Datenhaltung sprechen: Da koennen
                      keine Daten "verschwinden",

                      Oh, doch, die koennen. Der MSSQL-Server hatte vor
                      kurzem noch so einen Bug, der dazu fuehrte, dass
                      Daten verloren gingen. Und auch die MySQL4-Beta
                      hatte einen solchen Bug.

                      Beweis? (Muss aber nicht kommen; wuerde den Thread moeglicherweise unnoetig aufblaehen.)

                      Gruss,
                      Lude

                      1. Hallo Lude,

                        Habe doch keine Daten, so dass formal nichts
                        zu beweisen ist.

                        Na also.

                        • Ist halt offensichtlich _und_ ich vermute Du
                          (oder das System) haben ihre Gruende.

                        [pref:t=33125&m=180716]

                        Ich werde die genauen Werte nicht
                        offenlegen, denn wenn man sie kennt, kann
                        man das sehr einfach ausnutzen.

                        Auf so ein Statement habe ich gehofft. - Es
                        macht also Sinn die Werte nicht offenzulegen.

                        Natuerlich. Warum sollte ich sowas sonst
                        verschweigen?

                        Gut. - Eventuell koennte eine Formel mit
                        "eingebauter Unbestimmtheit" offengelegt
                        werden?

                        *Es* *gibt* *keine* *Formel*. Nur Grenzwerte.

                        [... RDBS mit Bugs, die zu Datenverlusten
                        fuehren ...]

                        Beweis? (Muss aber nicht kommen; wuerde den
                        Thread moeglicherweise unnoetig aufblaehen.)

                        Nix da, jetzt kriegstes:

                        http://www.heise.de/newsticker/data/lab-16.07.01-002/

                        sowie

                        http://forum.de.selfhtml.org/archiv/2001/7/27142/

                        Fuer MySQL den Bugreport 'rauszusuchen hatte ich
                        jetzt keine Lust.

                        Gruesse,
                         CK

                        1. Hi CK,

                          Habe doch keine Daten, so dass formal nichts
                          zu beweisen ist.

                          Na also.

                          :-)

                          Auf so ein Statement habe ich gehofft. - Es
                          macht also Sinn die Werte nicht offenzulegen.

                          Natuerlich. Warum sollte ich sowas sonst
                          verschweigen?

                          Welches Verhalten von Forumsteilnehmern befuerchtest Du eigentlich konkret, wenn bestimmte Konfigurationsparameter der Archivierungsroutine bekanntwerden? Oder ist das geheim?

                          Gut. - Eventuell koennte eine Formel mit
                          "eingebauter Unbestimmtheit" offengelegt
                          werden?

                          *Es* *gibt* *keine* *Formel*. Nur Grenzwerte.

                          Ich schlug vor, dass die Archivierungsroutine mithilfe einer nichtdeterministische Funktion und bekannten Konfigurationsparametern Threads archiviert. Du verwendest uebrigens durchaus eine Formel, die aber ueber Bedingungen implementiert ist, stimmt's?

                          [... RDBS mit Bugs, die zu Datenverlusten
                          fuehren ...]

                          Beweis? (Muss aber nicht kommen; wuerde den
                          Thread moeglicherweise unnoetig aufblaehen.)

                          Nix da, jetzt kriegstes:

                          http://www.heise.de/newsticker/data/lab-16.07.01-002/

                          sowie

                          http://forum.de.selfhtml.org/archiv/2001/7/27142/

                          Hmm, habe ich gelesen. Deine Aussage, dass "auch bei MSSQL Server Daten verschwinden" (oder so aehnlich) kann ich, nun richtig eingelesen, nicht bestaetigt sehen. - Es handelt sich m.E. um einen leicht hysterischen Bericht fuer die Allgemeinheit. Beim Lesen der Anlage des Artikels stellte ich fest, dass es einen Fehler beim Datenzugriff mit TSQL gibt; und zwar dann wenn u.a. die "Group By" Klausel verwendet wird. Angeblich werden dann existierende Datensaetze nicht angezeigt. (Ich habe uebrigens ansatzweise aehnliche Erfahrungen gemacht mit der gen. Klausel. Eine bestimmte Kombination von "Group By" und "Order By" fuehrte reproduzierbar dazu, dass die Sortierung "am Ende" der Datensatzmenge nicht korrekt war. Wenn man der Sortierung traut und mit der "Top"-Klausel arbeitet hat man also u.U. den "Datenverlust".) - Von (richtigem) Datenverlust bzw. "Daten-Verschwinden" habe ich nichts gelesen; es wurde halt nicht alles selected. Brisant und oeffentlichkeitswirksam war die ganze Sache halt wg. der "Nuklearkomponente". - MSSQL Server hat uebrigens etliche bekannte Bugs; es gibt da natuerlich auch SPs. Dennoch bin ich vom Produkt u.a. i.p. Stabilitaet (Verfuegbarkeit), Wartungsfreundlichkeit und Skalierbarkeit schon "ueberzeugt".

                          Fuer MySQL den Bugreport 'rauszusuchen hatte ich
                          jetzt keine Lust.

                          Der duerfte _auch_ recht ausfuehrlich sein.

                          Gruss,
                          Lude

                        2. Hi,

                          sorry fuer den Nachtrag, aber es musste noch raus:

                          Beweis? (Muss aber nicht kommen; wuerde den
                          Thread moeglicherweise unnoetig aufblaehen.)

                          Nix da, jetzt kriegstes:

                          http://www.heise.de/newsticker/data/lab-16.07.01-002/

                          sowie

                          http://forum.de.selfhtml.org/archiv/2001/7/27142/

                          Hat sich denn irgendein Beitrag des Threads mit dem Problem beschaeftigt? Habe nun 50% gelesen und bin _entsetzt_ ueber das Gesuelze. Das Ausgangsposting von Bio und die Antwort von Martin Speiser.   =>   :-(

                          Gruss,
                          Lude

                  3. Hallo!

                    • Threads verschwinden
                    • Beitraege verschwinden
                    • Threads geloescht werden
                    • Downzeiten hoch sind

                    Natuerlich bearbeite ich solche Vorfaelle sachbezogen objektiv und tendenziell auch mit Humor.

                    Das ist für mich der Spruch des Jahres ;-)

                    Für welche Aufsichts-Behörde arbeitest Du denn? Oder gehörst Du auch zu den zahlenden SELF-Kunden?

                    Grüße
                    Andreas

                    1. Hi,

                      • Threads verschwinden
                      • Beitraege verschwinden
                      • Threads geloescht werden
                      • Downzeiten hoch sind

                      Natuerlich bearbeite ich solche Vorfaelle sachbezogen objektiv und tendenziell auch mit Humor.

                      Das ist für mich der Spruch des Jahres ;-)

                      der eine oder andere dulle Spruch wird mir doch erlaubt sein. Es geht mir ja ansonsten immer um Wahrheit und Klarheit.

                      Gruss,
                      Lude