Wer betreibt eigentlich die Usenet-Server?
Jürgen Fenn
genau das frage ich mich schon seit geraumer Zeit: Wer stellt die Server
zur Verfügung? Gibt es dabei so etwas wie Zensur? Überwiegen
kommerzielle, staatliche, gar kirchliche Server? Welche Interessen sind
da im Spiel? etc.pp.
Ich meine zunächst die Server, die die einzelnen NGs "beheimaten". Wer
z.B. betreibt "de.comm.provider.usenet"?
Und dann die Newsserver, die das ganze für die Öffentlichkeit zugänglich
machen.
Wo kann ich mehr darüber erfahren?
Danke, Jürgen.
Sven Paulus
|> Ich meine zunächst die Server, die die einzelnen NGs "beheimaten". Wer
|> z.B. betreibt "de.comm.provider.usenet"?
de.comm.provider.usenet wird von einer Vereinigung mehrerer
neubuddhistischer Splittergruppen betrieben. Der Ursprungsserver ist
aus rechtlichen Gruenden auf einer China vorgelagerten Insel. Die
Netzanbindung wird primaer durch den Verkauf kleiner Fischskulpturen
mit menschlichen Gesichtern betrieben, was ein Kernelement der dortigen
Kultur ist.
Naehere Informationen dazu bekommst Du, wenn Du auf den untenstehenden
Link klickst.
--
Andreas Loch
> Wer stellt die Server zur Verfügung?
Kommerzielle Provider, Privatpersonen, Universitäten, diverse
Firmen, etc.
> Gibt es dabei so etwas wie Zensur?
Auf einigen Newsservern sicher, das liegt ganz im Ermessen des
Betreibers.
> Überwiegen kommerzielle, staatliche, gar kirchliche Server?
Zahlenmäßig höchstwahrscheinlich private. Aber größere Server sind
wohl meist bei kommerziellen Providern oder großen Bildungseinrich-
tungen zu finden.
> Ich meine zunächst die Server, die die einzelnen NGs "beheimaten".
> Wer z.B. betreibt "de.comm.provider.usenet"?
Newsgroups idR. werden nicht von einzelnen Servern betrieben, sondern
durch ein weltweites Netzwerk sehr vieler Newsserver, die direkt oder
indirekt die Artikel untereinander austauschen.
Es gibt daneben auch lokale Gruppen, die nur auf einem Server auf-
liegen. So betreibt zum Beispiel T-Online interne Gruppen, die nur
für eigene Kunden zugänglich sind.
Andreas
--
http://gigaschatten.de/
Frage: Findest Du es gut, einen Verdächtigen über seine Rechte
aufzuklären?
Hammer: Ich berate ihn lieber in Sargfragen. (Sledge Hammer)
Volker Gringmuth
> genau das frage ich mich schon seit geraumer Zeit: Wer stellt die
> Server zur Verfügung?
Die Provider, jeder seinen eigenen. Deinen z.B. die Uni Frankfurt. Die
stehen alle miteinander in Kontakt, tauschen ihre einzelnen Artikel
aus, und das ergibt das Usenet.
> Gibt es dabei so etwas wie Zensur?
Nope. Technisch kaum machbar.
> Überwiegen kommerzielle, staatliche, gar kirchliche Server? Welche
> Interessen sind da im Spiel? etc.pp.
Sollte sich dadurch beantwortet haben. Eigentlich nur kommerzielle in
dem Sinne, dass sich die Provider für diese Dienstleistung von ihren
Kunden bezahlen lassen.
Die Entscheidung über Neueinrichtungen und Löschungen von Newsgroups
trifft die gesamte Leserschaft durch Abstimmung - auch du kannst
mitreden.
> Ich meine zunächst die Server, die die einzelnen NGs "beheimaten".
> Wer z.B. betreibt "de.comm.provider.usenet"?
Diese "beheimatenden" Server gibt es nicht. Eine NG existiert auf
allen Servern, die sie führen, und sonst nirgends - sie existiert
sozusagen rein virtuell. Das Usenet ist völlig dezentral; es existiert
nur durch die Vernetzung der Server - und die User, die dieses Netz
mit Leben füllen. Du schickst einen Beitrag an einen Server, und der
schickt es an soundsoviele andere, die es dann wieder
weiterverschicken, und irgendwann haben es alle, die diese Gruppe
führen. Es gibt keine Zentrale.
> Und dann die Newsserver, die das ganze für die Öffentlichkeit
> zugänglich machen.
Das sind die selben, die auch die NGs führen.
Gruß von
Volker
--
Meine bewusst vereinfachte und hoffentlich verständliche Einführung
ins Usenet:
http://www.volker-gringmuth.de/usenet1.htm
Peter Ihm
Volker Gringmuth schrieb in Nachricht
<8pmdtu.3...@news01.volker-gringmuth.de>...
>
>Diese "beheimatenden" Server gibt es nicht. Eine NG existiert auf
>allen Servern, die sie führen, und sonst nirgends - sie existiert
>sozusagen rein virtuell.
ausgenommen die firmenspezifischen Newsgroups oder die kommerziellen.
Da kann es z.B. bei Microsoft Newsgroups schon öfters vorkommen, daß
gepostete News nicht auf den MS Servern landen und umgekehrt. Oder bei biz.
Ebenso bei den eingespeisten osteuropäischen Groups. Teilweise laufen die
über gateways, die nur in eine Richtung offen sind oder postings nach dem
verwendeten Schriten (z.B. Kyrillisch) prüfen und alles andere aussortieren.
Aber nur in eine Richtung.
Daraus ergibt sich dann oftmals, daß je nach Anbindung größere Newslöcher
herrschen oder ansich lebende Gruppen tot zu sein scheinen oder sehr wenig
Traffic aufweisen.
Bei news.online.de z.B. sind viele alt Gruppen reiner Einbahnverkehr. Sie
sind gelistet, aber es geht nur was raus, kommt nichts rein.
So was ist mitunter Politik, mitunter Nachlässigkeit bei der Pflege.
Peter
Michael Mantz
software, hardware, internetanbindung, ansprechpartner und wocher wissen
dann die anderen betreiber von mir oder umgekehrt wo erfahre ich wie die
adressen von den anderen sind, fragen ueber fragen aber mit der zeit haben
sich einiege angesammelt und ich habe niergends irgenwelche hinweise
gefunden, vielleicht habe ich jetzt hier einfach glueck. regards michael
Jonas Luster
> Das ist übrigens eine DOS COM-Datei mit dem Inhalt:
> ~$ ndisasm www.usenetinfo.com
> 00000000 FA cli
> 00000001 EBFE jmp short 0x1
>
> ...also eine Endlosschleife. Soll wohl den Rechner zum Aufhängen
> bringen. Sowas gehört ge*PLONK*t.
Wer Programmcode in Signaturen ausfuehrt der gehoert nicht gePlonkt,
der gehoert erschlagen.
Mario Klebsch
>Mario Klebsch schrieb in Nachricht ...
>.
>>>Da kann es z.B. bei Microsoft Newsgroups schon öfters vorkommen, daß
>>>gepostete News nicht auf den MS Servern landen und umgekehrt.
>>
>>Nur wenn das Feeding nicht korrekt funktioniert (konfiguriert ist).
>nein, bei MS ist es die Einstellung, daß jeder Link die News holen *und*
>liefern muß.
Es wäre ja zu gut, wenn Microsoft sich mal an Standards halten
würde...
73, Mario
--
Mario Klebsch ma...@klebsch.de
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
Hergen Lehmann
>> Für einen "richtigen" Feed muß man dann halt mit einem oder mehreren
>> anderen Serverbetreibern persönlich reden (email/telefon) und etwas
>> aushandeln. Eine echte Standleitung mit fester IP-Adresse ist Plicht.
>
>[ ] Du kennst UUCP.
[X] Ja, ich kenne UUCP, habe früher selbst mal damit gearbeitet.
[X] Die meisten Newsadmins geben Dir inzwischen einen Tritt in den
Hintern, wenn Du mit UUCP ankommst. NNTP macht schon mehr als
genug Arbeit.
[X] Den Feed für einen "richtigen" Newsserver mit annähernd
vollständigem Feed (de.*,rec.*,sci.* usw.) per Wählleitung und
UUCP abwickeln zu wollen, ist krank.
(wenn der Traffic eines Tages überhaupt noch in 24h über eine
solche Leitung paßt...)
[X] UUCP ist veraltet und unflexibel.
Wenn es eh nur um einen "kleinen" Feed für den Hobbybedarf, ein
einzelnes Institut o.ä. geht, ist NNTP im Reader-Mode mit mehreren
parallelen Threads für beide Seiten leichter zu warten, sehr viel
flexibler, und annähernd genauso effektiv.
Im Endeffekt ist es oft sogar effektiver, wenn man die Möglichkeiten
zur Vorfilterung unerwünschten Traffics mit berücksichtigt.
Hergen
Joerg Mensmann
> Joerg Mensmann <joerg.m...@gmx.de> scripsit/wrote:
>> Das ist übrigens eine DOS COM-Datei mit dem Inhalt:
> Und? Wer führt denn Programmcode aus Signaturen aus, wenn er nicht
> weiß, was der genau bewirkt?
Es wird ja der Eindruck erweckt, es würde sich um einen Link auf eine
.COM-Domain handeln. Und es gibt leider Newsreader die nicht anzeigen,
um was es sich hier wirklich handelt.
Man muss die Outlook-Kartoffeln ja nicht gleich ins offene Schwert
reinlaufen lassen...
ciao
Jörg
Michael Klingbeil
[...]
> > ...also eine Endlosschleife. Soll wohl den Rechner zum Aufhängen
> > bringen. Sowas gehört ge*PLONK*t.
>
> Wer Programmcode in Signaturen ausfuehrt der gehoert nicht gePlonkt,
> der gehoert erschlagen.
Irgend etwas mach wohl falsch denn hier hängt fast nichts. ;)
Ansonsten selber Schuld wen man so etwas ausführt...
--
micha
Michael Klingbeil
Mario Klebsch
>[X] UUCP ist veraltet und unflexibel.
Gerade in der heutigen Zeit, wo es nur "verkrüppelte" Internetzugänge
gibt, aber auf der anderen Seite Telefonanbieter mit sekundengenauer
Abrechnung existieren, ist UUCP brauchbarer den je. Mangelnde
Flexibilität kann ich übrigens überhaupt nicht sehen.
Ich überlege sogar, meinen News-Feed von NNTP auf UUCP (hier über TCP)
umzustellen, da ich dann z,B, auch komprimieren kann und den
Übertragungskanal leicher gefüllt bekomme (da ich deutlich weniger von
der Round-Trip-Zeit abhängig bin). Ich erwarte auf diese Weise eine
Reduktion meiner durch Newstransfer erreichten Onlinezeit auf unter
10% des jetzigen Wertes.
Hergen Lehmann
<Michae...@de.bosch.com> wrote:
>hi! was braucht man eigentlich um selber einen newsserver zu betreiben,
>software, hardware, internetanbindung,
Hängt sehr stark von den Anforderungen ab.
Für einen kleinen Server mit einer Handvoll Groups und Usern (z.B. zum
privaten Gebrauch oder in einer kleinen Firma) reichen ein gewöhn-
licher Windows-PC mit einem Progrämmchen wie "Hamster" und ein
gewöhnlicher Internetzugang via ISDN oder Modem.
Für einen "richtigen" Newsserver mit halbwegs vollständigem Guppen-
angebot und Tausenden von Usern sollte es dann schon ein Mehrpro-
zessorsystem und/oder eine Serverfarm mit RAM im GByte-Bereich und
RAID-Plattenarray sein. Dazu eine ordentliche Anbindung im MBit-
Bereich zum Netz und 100MBit-Bereich zu den Usern. Sollen auch noch
Binaries drauf, kannst Du die RAID-Kapazität und Netzanbindung gleich
nochmals um 1-2 Zehnerpotenzen aufstocken.
Da wird auch klar, warum sich die Billiganbieter immer häufiger einen
Newsserver sparen. Nicht nur die Hardware, auch die Wartung und
verbrauchte Netzbandbreite sind ein erheblicher Kostenfaktor.
>ansprechpartner und wocher wissen
>dann die anderen betreiber von mir oder umgekehrt wo erfahre ich wie die
>adressen von den anderen sind,
Im einfachsten Fall verhält sich der Server wie ein normaler Benutzer
und fragt die Newsgroups einfach der Reihe nach einfach ab. Dies tut
z.B. der oben erwähnte Hamster. Eine Absprache mit anderen Betreibern
ist dazu nicht erforderlich, das funktioniert (fast) genauso simpel
wie jetzt Dein outlook express.
Für einen "richtigen" Feed muß man dann halt mit einem oder mehreren
anderen Serverbetreibern persönlich reden (email/telefon) und etwas
aushandeln. Eine echte Standleitung mit fester IP-Adresse ist Plicht.
Hergen
Volker Gringmuth
> was braucht man eigentlich um selber einen newsserver zu betreiben
Ein Rechner mit funktionierender SHIFT-Taste wäre schon empfehlenswert.
Und deine Komma-Taste scheint auch nur auf jeden zweiten Druck zu
reagieren... SCNR
Um einen lokalen Newsserver zu betreiben, brauchst du einen
handelsüblichen Rechner (Hardware) und einen lokalen Newsserver
(Software). Dafür gibt's eine eigene Gruppe:
de.comm.software.newsserver. Hier läuft auch einer, kann ich nur
empfehlen.
Um einen Usenet-Server für den Zugriff von außen per Internet zu
betreiben, brauchst du vor allem Zeit, Nerven, viel Ahnung von der
Funktion des Usenet und - last but not least - ein ziemlich gutes
Abuse-Management. Denn wenn dein Server zur Spamschleuder wird, will
sehr schnell keiner mehr was von ihm wissen.
Gruß von
Volker
--
Volker Gringmuth http://www.volker-gringmuth.de
Würde ich dir jemals eine rhetorische Frage stellen?
Kai Garlipp
Volker Gringmuth wrote:
>
> > genau das frage ich mich schon seit geraumer Zeit: Wer stellt die
> > Server zur Verfügung?
>
> Die Provider, jeder seinen eigenen. Deinen z.B. die Uni Frankfurt. Die
> stehen alle miteinander in Kontakt,
Wobei jeder Server nur mit ein paar anderen in Kontakt steht und nicht
mit allen anderen (wobei die Zahl der Usenetserver an sich auch
unbekannt ist). Und da diese anderen Server auch wiederum mit anderen in
Kontakt stehen kommen die Artikel auch auf entfernten Maschinen
irgendwann einmal an, den jeweils durchlaufenen Weg kann man im
Path-Header sehen.
Bye Kai
Sebastian Bork
> Für einen "richtigen" Feed muß man dann halt mit einem oder mehreren
> anderen Serverbetreibern persönlich reden (email/telefon) und etwas
> aushandeln. Eine echte Standleitung mit fester IP-Adresse ist Plicht.
[ ] Du kennst UUCP.
Joerg Mensmann
> Sven Paulus am 12 Sep 2000 23:12:32 +0200:
>> begin 755 www.usenetinfo.com
>> #^NO^
>> `
>> end
Das ist übrigens eine DOS COM-Datei mit dem Inhalt:
~$ ndisasm www.usenetinfo.com
00000000 FA cli
00000001 EBFE jmp short 0x1
...also eine Endlosschleife. Soll wohl den Rechner zum Aufhängen
bringen. Sowas gehört ge*PLONK*t.
ciao
Jörg
Jürgen Fenn
vielen Dank für alle ernsthaften Antworten! Und danke auch für den Tip
zu news://de.newusers.questions . Jetzt verstehe ich auch, weshalb die
Newsgroups nicht gleich aktuell sind auf verschiedenen Servern
(news.cis.dfn.de im Vergleich zu nntp.server.uni-frankfurt.de).
Grüße, Jürgen.
Frank Kloeker
Du brauchst einfach erstmal bissel Hardware (80-100 TDM sollten erstmal
reichen) und eine stabile Internetanbindung in der Groessenordnung von
100 MBit. Die Software gibts meist gratis (z.B. INN auf Unix). Nach dem
Verknoten der Hardware mit der Software schaust Du Dich nach
Peeringpartnern um. http://www.usenet-se.net/peering/index.html waere da
so eine Adresse. Die Leute schreibst Du dann an und vereinbarst ein
Peering mit bestimmten Parametern. Je nach Netztopologie und Bedarf kann
Dein Peering angenommen oder abgelehnt werden. Es kostet nichts und Du
kannst keinen Anspruch drauf erlegen.
Newsfeed kannst Du auch einkaufen zum Beispiel per Sat. Dazu gibts
Firmen, die sowas anbieten und Du bekommst eine Schuessel aufs Dach, wo
dann die News reinlaufen.
--
Don't dream your life, live your dream!
Mario Klebsch
>Volker Gringmuth schrieb in Nachricht
><8pmdtu.3...@news01.volker-gringmuth.de>...
>>
>>Diese "beheimatenden" Server gibt es nicht. Eine NG existiert auf
>>allen Servern, die sie führen, und sonst nirgends - sie existiert
>>sozusagen rein virtuell.
>ausgenommen die firmenspezifischen Newsgroups oder die kommerziellen.
>Da kann es z.B. bei Microsoft Newsgroups schon öfters vorkommen, daß
>gepostete News nicht auf den MS Servern landen und umgekehrt.
Nur wenn das Feeding nicht korrekt funktioniert (konfiguriert ist).
>So was ist mitunter Politik, mitunter Nachlässigkeit bei der Pflege.
So ist es.
Mario Klebsch
>Für einen "richtigen" Newsserver mit halbwegs vollständigem Guppen-
>angebot und Tausenden von Usern sollte es dann schon ein Mehrpro-
>zessorsystem und/oder eine Serverfarm mit RAM im GByte-Bereich und
>RAID-Plattenarray sein.
Ich kenne durchaus Newsserver, die trotz weit über tausen Nutzer eine
deutlich geringere Austattung haben. Dennoch, diese Ausstattung ist
schon gut, ich denke nur, die Grenze der Notwendigkeit liegt etwas
höher.
>Da wird auch klar, warum sich die Billiganbieter immer häufiger einen
>Newsserver sparen. Nicht nur die Hardware, auch die Wartung und
>verbrauchte Netzbandbreite sind ein erheblicher Kostenfaktor.
So einen Newsserver zu betreuen kostet unwahrscheinlich viel Zeit. Ich
war echt froph, als ich diesen Dienst aufgrund einer besseren
Netzwerkanbindung wieder einstellen konnte.
>Für einen "richtigen" Feed muß man dann halt mit einem oder mehreren
>anderen Serverbetreibern persönlich reden (email/telefon) und etwas
>aushandeln. Eine echte Standleitung mit fester IP-Adresse ist Plicht.
Es geht auch prima mit UUCP.
Peter Ihm
Mario Klebsch schrieb in Nachricht ...
.
>>gepostete News nicht auf den MS Servern landen und umgekehrt.
>
>Nur wenn das Feeding nicht korrekt funktioniert (konfiguriert ist).
nein, bei MS ist es die Einstellung, daß jeder Link die News holen *und*
liefern muß.
Dadurch sind sehr oft außerhalb der MS Server massig Postings,die auf dem MS
Server nie oder sehr viel später auftauchen und umgekehrt.
Wer kann, sollte deshalb direkt an msnews.microsoft.com rangehen.
Peter
Thomas Hochstein
> Das ist übrigens eine DOS COM-Datei mit dem Inhalt:
Und? Wer führt denn Programmcode aus Signaturen aus, wenn er nicht weiß,
was der genau bewirkt?
Jungejunge,
-thh
Hergen Lehmann
wrote:
>>[X] UUCP ist veraltet und unflexibel.
>
>Gerade in der heutigen Zeit, wo es nur "verkrüppelte" Internetzugänge
>gibt, aber auf der anderen Seite Telefonanbieter mit sekundengenauer
>Abrechnung existieren, ist UUCP brauchbarer den je.
Inwiefern?
>Mangelnde Flexibilität kann ich übrigens überhaupt nicht sehen.
- Jede Newsgroup, die man lesen möchte, erfordert eine explizite
Bestellung. Einfach mal kurz ´reinschauen, weil jemand auf einen
interessanten Thread in einer anderen Group hingewiesen hat, ist
nicht.
- Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
möglich.
- Newsgroups können immer nur vollständig bezogen werden. Eine
Vorfilterung, z.B. das Ignorieren lästiger Endlosthreads oder das
Löschen von Binary-Postings ist nicht möglich. Ebenso ist es nicht
möglich, bei Groups mir nur sporadisch interessanten Inhalten
erstmal nur die Header zu holen, um später ggf. die wenigen
interessanten Bodies nachzuladen.
- Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
einem Urlaub oder bei verirrten Binaries kann der Spool leicht
einen nicht mehr handhabbaren Umfang annehmen, so daß nur das
komplette Löschen ganzer Spoolfiles bleibt - was einen manuellen
Eingriff des Admin erfordert und Datenverlust bedeutet.
- Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
(bitte jetzt keine Diskussion über den Sinn solcher Gruppen - es
gibt sie und sie werden stark genutzt, womit der Sinn für mich
hinreichend bewiesen ist).
- Mehrfache Feeds sind nicht sinnvoll möglich, da alles doppelt und
dreifach übertragen würde.
- Jeder UUCP-Teilnehmer muß beim Feed einzeln konfiguriert werden. Der
Betrieb mit großen Nutzerzahlen ist dadurch kaum möglich, weil der
Arbeitsaufwand gegen unendlich geht.
hab ich noch was vergessen?
>Ich überlege sogar, meinen News-Feed von NNTP auf UUCP (hier über TCP)
>umzustellen, da ich dann z,B, auch komprimieren kann
Bei Wählverbindungen bietet heute in der Regel schon das Medium
(ISDN/Modem) eine effektive Kompression. Bei Standleitungen erscheint
sie mir nicht so eminent wichtig, da hier in der Regel ausreichend
Bandbreite zur Verfügung steht.
>und den
>Übertragungskanal leicher gefüllt bekomme (da ich deutlich weniger von
>der Round-Trip-Zeit abhängig bin).
Das geht auch mit NNTP ganz gut durch mehrere, simultane Reader-/
Feederthreads. Wo der eine gerade wartet, ist mit großer
Wahrscheinlichkeit gerade einer der anderen in der Übertragungsphase.
>Ich erwarte auf diese Weise eine
>Reduktion meiner durch Newstransfer erreichten Onlinezeit auf unter
>10% des jetzigen Wertes.
Hmm, meine stündlichen NNTP-Polls dauern bei ca. 130 bezogenen Gruppen
und vier Threads zwischen 10 und 30 Sekunden (per ISDN), je nach
Traffic. Wobei da teilweise noch die etwas schwache Maschine (P90/64MB
unter NT4) und die nicht optimale Netzanbindung bei der sekunden-
genauen Einwahlnummer mit bremsen.
Eine Reduktion auf 10% scheint mir heftig zu hoch gegriffen, realis-
tisch dürften eher "Reduktion um 10%-20%" sein.
(Natürlich kann man diesen Wert beliebig verschieben, indem man die
Möglichkeiten eines der beiden Protokolle einfach nicht ausnutzt. Aber
wir wollen ja einen fairen Vergleich, gelle?)
Hergen
Sven Paulus
|> - Jede Newsgroup, die man lesen möchte, erfordert eine explizite
|> Bestellung. Einfach mal kurz ´reinschauen, weil jemand auf einen
|> interessanten Thread in einer anderen Group hingewiesen hat, ist
|> nicht.
Deswegen ist die Kombination von beidem ideal, ich ziehe z.B. de.* via
UUCP in grossen Abstaenden (4/Tag) und hole die wichtigen Gruppen nach
Bedarf via NNTP und schnellbatchendem UUCP-Feed. Nicht bei jeder Gruppe
muss ich unbedingt am Puls der Zeit sein ...
|> - Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
|> zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
|> möglich.
Da man aber Gruppen eh seit ihrer Gruendung abonniert hat, kann man die
Archivierung bei Bedarf auch selbst vornehmen.
|> - Newsgroups können immer nur vollständig bezogen werden. Eine
|> Vorfilterung, z.B. das Ignorieren lästiger Endlosthreads oder das
|> Löschen von Binary-Postings ist nicht möglich. Ebenso ist es nicht
|> möglich, bei Groups mir nur sporadisch interessanten Inhalten
|> erstmal nur die Header zu holen, um später ggf. die wenigen
|> interessanten Bodies nachzuladen.
Das finde ich die perfekte Form von persoenlicher Zeitverschwendung.
Die Artikel haben dann dazusein, wenn ich sie lesen will und nicht
irgendwann spaeter. Dann hab ich eh schon wieder vergessen, dass ich
mich dafuer interessiert habe.
|> - Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
|> einem Urlaub oder bei verirrten Binaries kann der Spool leicht
|> einen nicht mehr handhabbaren Umfang annehmen, so daß nur das
|> komplette Löschen ganzer Spoolfiles bleibt - was einen manuellen
|> Eingriff des Admin erfordert und Datenverlust bedeutet.
Cleanfeed und Groessenlimit auf dem Feed und alles andere steht man
halt einfach durch.
|> - Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
|> (bitte jetzt keine Diskussion über den Sinn solcher Gruppen - es
|> gibt sie und sie werden stark genutzt, womit der Sinn für mich
|> hinreichend bewiesen ist).
Wo liegt der Unterschied, ob ich eine Binary-Gruppe via UUCP oder via
NNTP sauge? Komprimiert wird in beiden Faellen nicht.
|> - Mehrfache Feeds sind nicht sinnvoll möglich, da alles doppelt und
|> dreifach übertragen würde.
Deswegen UUCP-Grundversorgung und Auffuellen via NNTP. Wenn aber der
UUCP-providende Server gut redundant angebunden ist und stabil
durchlaeuft, sollte i.A. dafuer keine Noetigkeit bestehen.
|> - Jeder UUCP-Teilnehmer muß beim Feed einzeln konfiguriert werden. Der
|> Betrieb mit großen Nutzerzahlen ist dadurch kaum möglich, weil der
|> Arbeitsaufwand gegen unendlich geht.
Das kann man aber schon verskripten, wie man letztendlich alles
verskripten kann.
Hergen Lehmann
>Deswegen ist die Kombination von beidem ideal, ich ziehe z.B. de.* via
>UUCP in grossen Abstaenden (4/Tag) und hole die wichtigen Gruppen nach
>Bedarf via NNTP und schnellbatchendem UUCP-Feed. Nicht bei jeder Gruppe
>muss ich unbedingt am Puls der Zeit sein ...
Eine Kombination ist sicher eine sinnvolle Sache, aber auch mit
erhöhtem Aufwand verbunden.
>|> - Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
>|> zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
>|> möglich.
>
>Da man aber Gruppen eh seit ihrer Gruendung abonniert hat, kann man die
>Archivierung bei Bedarf auch selbst vornehmen.
Ähh, hat man Gruppen "eh seit ihrer Gründung" abonniert? In der
Mehrzahl wohl eher nicht.
Es ging mir dabei auch weniger um die Langzeitarchivierung (die muß
man eh selber machen), sondern um Dinge wie "hier in der neu
entdeckten NG laufen ein paar interessante Threads, wie fingen die
denn an?"
>Das finde ich die perfekte Form von persoenlicher Zeitverschwendung.
>Die Artikel haben dann dazusein, wenn ich sie lesen will und nicht
>irgendwann spaeter. Dann hab ich eh schon wieder vergessen, dass ich
>mich dafuer interessiert habe.
Geht mir zugegebenermaßen ähnlich.
Dennoch - ich habe hier etliche High-Traffic-Gruppen mit z.T. mehreren
100 Postings pro Tag, von denen <1% für mich interessant sind. Wenn
ich anfange, über die Reduktion von Onlinekosten nachzudenken, muß ich
auch darüber nachdenken, ob es nicht zweckmäßiger wäre, erstmal diesen
Ballast über Bord zu werfen.
>|> - Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
>[...]
>Cleanfeed und Groessenlimit auf dem Feed und alles andere steht man
>halt einfach durch.
Größenlimit bedeutet aber wieder Datenverlust. Da ist mir NNTP doch
lieber, wo ich sagen kann "hier die 10 Groups will ich vollständig,
bei allen anderen gib mir nur die letzten 50 Postings, die sind mir
nicht so wichtig".
Und durchstehen - naja, ein 100MB-Spool ist für einen Analoguser ein
KO-Kriterium, und mit ISDN zumindest noch hart.
>|> - Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
>[...]
>Wo liegt der Unterschied, ob ich eine Binary-Gruppe via UUCP oder via
>NNTP sauge? Komprimiert wird in beiden Faellen nicht.
Es ist schon ein "kleiner" Unterschied, ob ich mir die interessanten
10MB selber aussuchen kann, oder die kompletten 500MB der Binary-Group
immer erstmal komplett runtersaugen muß.
Und es ist auch für den Server ein Unterschied, ob der die 500MB
multipliziert mit n Usern komplett spoolen muß, oder ob sich die Leute
bei Bedarf das Interessante herauspicken und gezielt abrufen.
>|> - Mehrfache Feeds sind nicht sinnvoll möglich, da alles doppelt und
>|> dreifach übertragen würde.
>
>Deswegen UUCP-Grundversorgung und Auffuellen via NNTP. Wenn aber der
>UUCP-providende Server gut redundant angebunden ist und stabil
>durchlaeuft, sollte i.A. dafuer keine Noetigkeit bestehen.
DAS Argument pro-UUCP ist doch immer die Kostenzeitersparnis durch
bessere Ausnutzung der Tarife. Das schließt aber auch ein, daß ich
mehrere Tarife im Wechsel nutzen, und dabei zwecks optimalem Durchsatz
immer auf den jeweils lokalen Server zugreifen kann.
So hole ich mir z.B. derzeit einmal am frühen Abend den großen Berg
des Tages via T-DSL, um dann für den Rest des Tages stündlich per ISDN
bei einem kleinen lokalen Provider mit sekundengenauer Abrechnung und
lokalem Newsserver zu pollen.
>|> - Jeder UUCP-Teilnehmer muß beim Feed einzeln konfiguriert werden. Der
>|> Betrieb mit großen Nutzerzahlen ist dadurch kaum möglich, weil der
>|> Arbeitsaufwand gegen unendlich geht.
>
>Das kann man aber schon verskripten, wie man letztendlich alles
>verskripten kann.
Kann man. Bedeutet aber auch wieder Arbeit, und wirft zudem neue
Probleme auf.
Wenn sich die User selbst ganz einfach per Script anmelden können,
bekommt man z.B. zwangsläufig eine große Zahl von Leichen, deren nie
abgeholter Spool wertvollen Plattenplatz blockiert. Wie wird man die
wieder los?
Hergen
Wolfgang Jaeth
Thomas Hochstein schrieb in Nachricht ...
>Joerg Mensmann <joerg.m...@gmx.de> scripsit/wrote:
>
>> Das ist übrigens eine DOS COM-Datei mit dem Inhalt:
>
>Und?
Binary in Textgruppen sind doch No-No's, oder?
Wolfgang, nur so zu bedenken gebend
--
Franz Georg Köhler
>>Mangelnde Flexibilität kann ich übrigens überhaupt nicht sehen.
>
> - Jede Newsgroup, die man lesen möchte, erfordert eine explizite
> Bestellung. Einfach mal kurz ´reinschauen, weil jemand auf einen
> interessanten Thread in einer anderen Group hingewiesen hat, ist
> nicht.
Bei NNTP genauso.
> - Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
> zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
> möglich.
Expire kann man konfigurieren.
> - Newsgroups können immer nur vollständig bezogen werden. Eine
das sehe ich als Vorteil.
Ist übriugens bei einem NNTP feed auch hier das Selbe.
> - Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
> einem Urlaub oder bei verirrten Binaries kann der Spool leicht
> einen nicht mehr handhabbaren Umfang annehmen, so daß nur das
> komplette Löschen ganzer Spoolfiles bleibt - was einen manuellen
> Eingriff des Admin erfordert und Datenverlust bedeutet.
man gup.
> - Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
> (bitte jetzt keine Diskussion über den Sinn solcher Gruppen - es
> gibt sie und sie werden stark genutzt, womit der Sinn für mich
> hinreichend bewiesen ist).
Sie werden nicht weniger sinnvoll gehandhabt, als mit NNTP.
> - Jeder UUCP-Teilnehmer muß beim Feed einzeln konfiguriert werden. Der
> Betrieb mit großen Nutzerzahlen ist dadurch kaum möglich, weil der
> Arbeitsaufwand gegen unendlich geht.
man gup.
> Bei Wählverbindungen bietet heute in der Regel schon das Medium
> (ISDN/Modem) eine effektive Kompression. Bei Standleitungen erscheint
> sie mir nicht so eminent wichtig, da hier in der Regel ausreichend
> Bandbreite zur Verfügung steht.
UUCP ist IMHO für Wählverbindungen erste Wahl, da:
> Eine Reduktion auf 10% scheint mir heftig zu hoch gegriffen, realis-
> tisch dürften eher "Reduktion um 10%-20%" sein.
Denke ich auch.
aber 20 - 30 % sind bei Wählleitungen immer noch Spitze.
ich hab hier einen de.* UUCP Feed nach Hasue (über ISDN), keinerlei
Probleme.
Früher habe ich news über suck, nntp.server.uni-frankfurt.de bezogen,
btw ist der Server eine Katstrophe (gewesen?), DNEWS unter NT...
Es wurde immer behauptet, die probleme lägen am router und da käme in
den nächsten Wochen ein Neuer.... das ging ungefähr ein halbes jahr
so....
Naja, ich hatte mir dann irgendwann ein Script geschrieben, daß relativ
fehlertolerant so lange gesuckt hat, bis es alles hatte, was es wollte
(konnte durchaus bis zu einer Stunde am Tag dauern, bei Timeouts von
iirc 300 sec), Feed waren ca. 50 de Gruppen.
Gruß,
Franz Georg Köhler
--
http://www.hanau.net/fgk/ 0x5E7A588D
Alle unsere Unixkisten wurden hingestellt und laufen. Bei Windows läuft
vor allem der Mensch, der versuchen darf, das Zeug in Gang zu halten.
Jens Dittmar in de.comp.advocacy
Mario Klebsch
>>Gerade in der heutigen Zeit, wo es nur "verkrüppelte" Internetzugänge
>>gibt, aber auf der anderen Seite Telefonanbieter mit sekundengenauer
>>Abrechnung existieren, ist UUCP brauchbarer den je.
>Inwiefern?
Als das UUCP-Polls oft nur wenige Sekunden dauern. Für einen Pfennig
kann ich oft sogar mehrere Polls machen.
>>Mangelnde Flexibilität kann ich übrigens überhaupt nicht sehen.
>- Jede Newsgroup, die man lesen möchte, erfordert eine explizite
> Bestellung. Einfach mal kurz ´reinschauen, weil jemand auf einen
> interessanten Thread in einer anderen Group hingewiesen hat, ist
> nicht.
Das ist bei anderen Arten des Feedens nicht anders. Es geht hier
übrigens um ienen News-Server, nicht um einen Endanwender.
>- Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
> zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
> möglich.
Jedes andere Verhalten wäre für einen Newsfeed falsch (und für die
Telefonrechnung fatal)
>- Newsgroups können immer nur vollständig bezogen werden. Eine
> Vorfilterung, z.B. das Ignorieren lästiger Endlosthreads oder das
> Löschen von Binary-Postings ist nicht möglich.
Natürlich geht das, DU musst das in den Batcher einbauen.
>- Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
> einem Urlaub oder bei verirrten Binaries kann der Spool leicht
> einen nicht mehr handhabbaren Umfang annehmen, so daß nur das
> komplette Löschen ganzer Spoolfiles bleibt - was einen manuellen
> Eingriff des Admin erfordert und Datenverlust bedeutet.
Packt Dein Feed etwa keine Batches? Ein Löschen ist normalerweise auf
Batch-Ebene möglich.
>- Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
Wo ist da der Unterschied? Die gehen genau wie andere Gruppen auch
durchs UUCP.
>- Mehrfache Feeds sind nicht sinnvoll möglich, da alles doppelt und
> dreifach übertragen würde.
Wenn Du hier redundante Feeds anführst, kann (und muss) ich Dir da
zustimmen.
>- Jeder UUCP-Teilnehmer muß beim Feed einzeln konfiguriert werden. Der
> Betrieb mit großen Nutzerzahlen ist dadurch kaum möglich, weil der
> Arbeitsaufwand gegen unendlich geht.
Das lieft nur an der verwendeten Software.
>>Ich überlege sogar, meinen News-Feed von NNTP auf UUCP (hier über TCP)
>>umzustellen, da ich dann z,B, auch komprimieren kann
>Bei Wählverbindungen bietet heute in der Regel schon das Medium
>(ISDN/Modem) eine effektive Kompression.
Bei Modems muss ich Dir recht geben, aber bei ISDN wird (zumindest
wenn man wie ich X75 verwendet) überhaupt nichts komprimiert. Noch
dazu habe ich von UUCP over TCP geschrieben, und bei IP over Modem ist
die Komprimierung des Modems reichlich wirkungslos, bei IP over ISDN
gibt es keine Komprimierung.
>>und den
>>Übertragungskanal leicher gefüllt bekomme (da ich deutlich weniger von
>>der Round-Trip-Zeit abhängig bin).
>Das geht auch mit NNTP ganz gut durch mehrere, simultane Reader-/
>Feederthreads. Wo der eine gerade wartet, ist mit großer
>Wahrscheinlichkeit gerade einer der anderen in der Übertragungsphase.
Ja, darüber habe ich auch schon nachgedacht, aber ich schätze mal,
mein Provider wird es weniger Lustig finden, wenn auch nur 10% der
News lesenden Kunden das macht. Da darf er dann mächtig CPUs und RAM
nachrüsten.
>Eine Reduktion auf 10% scheint mir heftig zu hoch gegriffen, realis-
>tisch dürften eher "Reduktion um 10%-20%" sein.
Mein Übertragungskanal hat eine Bandbreite von ca. 85KByte pro Sekunde
(T-DSL). Wenn ich darüber einen POLL per NNTP fahre, dann werden davon
im Mittel maximal 10KByte/Sekunde ausgenutzt. Alleine wenn es mir
gelingt, den Kanal zu sättigen, kann ich die Zeit auf 15% senken, ohne
auch nur ein Byte weniger zu übertragen. Wenn dann noch eine
Kompression dazu kommt und der unnötige Traffic zur Kontrolle der
NNTP-Verbindung vermieden wird, dann macht das sicherlich noch einmal
wenigstens 50%.
Etwas bremsend wird sich die Tatsache auswirken, dass der Rechner, auf
dem ich meine Batches packen lassen will, nur mit 512KBit/Sekunde ans
Internet angeschlossen ist. Er wird daher meinen Link nicht
vollständig sättigen können. Mit der verbleibenden Restbandbreite
kann ich dann zusätzliche Newesserver per NNTP pollen)
>(Natürlich kann man diesen Wert beliebig verschieben, indem man die
>Möglichkeiten eines der beiden Protokolle einfach nicht ausnutzt. Aber
>wir wollen ja einen fairen Vergleich, gelle?)
Ich bleibe dabei, das ich für mich eine Reduzierung auf 10-20% des
derzeitigen Wertes erwarte, und sogar deutlich mehr für möglich
halte.
Mario Klebsch
>Ähh, hat man Gruppen "eh seit ihrer Gründung" abonniert? In der
>Mehrzahl wohl eher nicht.
Als ich mit News-Lesen angefangen habe, gab es so um die 700
Newsgroups. Bei allen, die seit dem dazu gekommen sind, habe ich also
die Gründung miterlebt, und hätte somit auch die Chance gehabt, sie
dann gleich zu abbonieren.
Hergen Lehmann
<fgko...@openunix.de> wrote:
>> Bestellung. Einfach mal kurz ´reinschauen, weil jemand auf einen
>> interessanten Thread in einer anderen Group hingewiesen hat, ist
>> nicht.
>
>Bei NNTP genauso.
Falsch. Bei bekannter Message-ID kann ich per NNTP frei auf jeden
Artikel zugreifen, bei bekannter Group und bekanntem Subject/Autor
zumindest noch die Header holen, und anhand derer dann relativ schnell
den Artikel beziehen.
>> - Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
>> zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
>> möglich.
>
>Expire kann man konfigurieren.
UUCP kennt prinzipbedingt kein Expire.
>> - Newsgroups können immer nur vollständig bezogen werden. Eine
>
>das sehe ich als Vorteil.
Was ist ein Vorteil? Daß man nicht filtern kann?
>Ist übriugens bei einem NNTP feed auch hier das Selbe.
Falsch. Im Reader-Mode kann man erstmal die Header holen, danach
filtern, und hinterher nur die interessanten Artikel holen.
>> - Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
>>[...]
>
>man gup.
Ich finde nach dem Urlaub oder einer sonstigen längeren Betriebsunter-
brechung einen Spool vor, der mir ganz erheblich zu groß ist. Ich
möchte diesen reduzieren, ohne jedoch Inhalte in einer Handvoll groups
zu verlieren, die für mich/meinen Betrieb/mein Institut wirklich
wichtig sind. Wie geht das?
>> - Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
>[...]
>
>Sie werden nicht weniger sinnvoll gehandhabt, als mit NNTP.
Die von mir beobachteten Binary-Groups umfassen täglich grob geschätzt
500MB. Davon interessieren mich bestenfalls mal 50MB, oft sogar tage-
lang gar nichts.
Wie kann ich dies mit UUCP sinnvoll handhaben?
Hergen
Franz Georg Köhler
>>
>>Bei NNTP genauso.
>
> Falsch. Bei bekannter Message-ID kann ich per NNTP frei auf jeden
> Artikel zugreifen, bei bekannter Group und bekanntem Subject/Autor
> zumindest noch die Header holen, und anhand derer dann relativ schnell
> den Artikel beziehen.
Ich spreche von einem NNTP Feed. Da besteht genau das Selbe Problem.
>>> - Es werden nur neu eintreffende Artikel ausgeliefert. Der Zugriff auf
>>> zurückliegende, archivierte Inhalte ist nicht oder nur unter Aufwand
>>> möglich.
>>
>>Expire kann man konfigurieren.
>
> UUCP kennt prinzipbedingt kein Expire.
Aber der Newsserver, der dahinter läuft.
>>> - Newsgroups können immer nur vollständig bezogen werden. Eine
>>
>>das sehe ich als Vorteil.
>
> Was ist ein Vorteil? Daß man nicht filtern kann?
Ja.
So bekommst du alle Artikel einer bestimmten gruppe in ungefähr der
zeit, in der du die interessanten Artikel über NN(T|R)P ausgesucht und
heruntergeladen hättest.
>>Ist übriugens bei einem NNTP feed auch hier das Selbe.
>
> Falsch. Im Reader-Mode kann man erstmal die Header holen, danach
> filtern, und hinterher nur die interessanten Artikel holen.
Readermode mach ich eigentlich nur bei Servern, die recht gut angebunden
sind (ethernet oder ähnliches).
>>> - Einmal gespoolte Daten können nur vollständig abgerufen werden. Nach
>>>[...]
>>
>>man gup.
>
> Ich finde nach dem Urlaub oder einer sonstigen längeren Betriebsunter-
> brechung einen Spool vor, der mir ganz erheblich zu groß ist. Ich
Nein, weil du das vorher mit gup korrigiert hast.
> möchte diesen reduzieren, ohne jedoch Inhalte in einer Handvoll groups
> zu verlieren, die für mich/meinen Betrieb/mein Institut wirklich
> wichtig sind. Wie geht das?
gar nicht, je nachdem wie lange du in Urlaub fährst, sind die news weg
(haltezeit).
>>> - Binary-Groups können per UUCP nicht sinnvoll gehandhabt werden
>>[...]
>>
>>Sie werden nicht weniger sinnvoll gehandhabt, als mit NNTP.
>
> Die von mir beobachteten Binary-Groups umfassen täglich grob geschätzt
> 500MB. Davon interessieren mich bestenfalls mal 50MB, oft sogar tage-
> lang gar nichts.
> Wie kann ich dies mit UUCP sinnvoll handhaben?
Bei einem NNTP feed bekommst du auch alle binary files...
Abgesehen davon sind Binaries im Usenet nicht sinnvoll.
Thomas Hochstein
>> Ist übriugens bei einem NNTP feed auch hier das Selbe.
>
> Falsch. Im Reader-Mode kann man erstmal die Header holen, danach
> filtern, und hinterher nur die interessanten Artikel holen.
Wer bitte betreibt denn auf diese Weise einen News_server_? Das ist dann
doch arg eigenwillig.
-thh
Hergen Lehmann
wrote:
>>- Jede Newsgroup, die man lesen möchte, erfordert eine explizite
>> Bestellung. [...]
>
>Das ist bei anderen Arten des Feedens nicht anders.
Nicht ganz. Wenn ich bei UUCP eine neue Group aufsetze, ist die
erstmal leer. Wenn ich dasselbe bei NNTP tue, habe ich die Möglich-
keit, mir die letzten n Postings/die letzten n Tage/die Postings mit
einem bestimmten Subject/etc. nachliefern zu lassen.
>Es geht hier übrigens um ienen News-Server, nicht um einen Endanwender.
Schon klar. Aber "große" Server mit hoher Gruppenzahl lassen sich per
UUCP ohnehin kaum betreiben, und bei "kleinen" Servern mit handselek-
tierter Gruppenauswahl halte ich Obiges für durchaus nützlich.
>>- Newsgroups können immer nur vollständig bezogen werden. Eine
>> Vorfilterung, z.B. das Ignorieren lästiger Endlosthreads oder das
>> Löschen von Binary-Postings ist nicht möglich.
>
>Natürlich geht das, DU musst das in den Batcher einbauen.
Ja, aber das muß auf Seiten des Feed getan werden, und ist damit
zwangsläufig relativ statisch.
Es ist kaum möglich, mal schnell zu sagen "verdammt, heute waren schon
wieder 200 Postings in diesem §$&§%$-Thread, jetzt bekommt das Ding
einen Killfilter".
>Packt Dein Feed etwa keine Batches? Ein Löschen ist normalerweise auf
>Batch-Ebene möglich.
Wobei unspezifisch Inhalte aus allen Groups verlorengehen, auch
solchen, die für mich wirklich wichtig sind.
>>Bei Wählverbindungen bietet heute in der Regel schon das Medium
>>(ISDN/Modem) eine effektive Kompression.
>
>Bei Modems muss ich Dir recht geben, aber bei ISDN wird (zumindest
>wenn man wie ich X75 verwendet) überhaupt nichts komprimiert.
>dazu habe ich von UUCP over TCP geschrieben, und bei IP over Modem ist
>die Komprimierung des Modems reichlich wirkungslos,
Hmm, die paar Byte IP-Header sollten eigentlich keinen derart
gravierenden Einfluß haben, zumal die V42b-Kompression ohnehin nur auf
128Byte-Blöcken operiert !??
>bei IP over ISDN gibt es keine Komprimierung.
Stimmt nicht. Ich habe jahrelang über snafu und uunet komprimierte
ISDN-Verbindungen (PPP-Stac) genutzt, bevor ich im Frühjahr auf TDSL
gewechselt habe.
>>Das geht auch mit NNTP ganz gut durch mehrere, simultane Reader-/
>>Feederthreads. Wo der eine gerade wartet, ist mit großer
>>Wahrscheinlichkeit gerade einer der anderen in der Übertragungsphase.
>
>Ja, darüber habe ich auch schon nachgedacht, aber ich schätze mal,
>mein Provider wird es weniger Lustig finden, wenn auch nur 10% der
>News lesenden Kunden das macht.
10% dürften es bei weitem nicht werden, da die gängigen Reader das gar
nicht können, und nur ein verschwindender Teil der User eigene Server
betreibt. Das bischen wird der Provider wohl verkraften können, und
ggf. kann er ja auch ein Limit konfigurieren, damit die User nicht
übertreiben.
Außerdem, so ganz ohne CPU-Last ist ein UUCP-Feed auch nicht. Vor
allem wenn der User sehr viele Groups bezieht, und damit fast ohne
Unterbrechung neue Daten für ihn eintrudeln...
>[...]
>Mein Übertragungskanal hat eine Bandbreite von ca. 85KByte pro Sekunde
>(T-DSL). Wenn ich darüber einen POLL per NNTP fahre, dann werden davon
>im Mittel maximal 10KByte/Sekunde ausgenutzt.
Ich nutze auch T-DSL, fahre normalerweise 4 Threads und komme damit
auf im Mittel etwa 40kByte/sek. Da haben wir also ziemlich gleiche
Erfahrungen.
Ich denke, mit noch mehr Threads würde sich der Kanal auch halbwegs
sättigen lassen, aber a) will ich es nicht übertreiben, und b) kotzt
meine etwas schwache Servermaschine (P90) so schon ziemlich.
Hergen
Mario Klebsch
Noch ein kleiner Nachtrag:
Wer nicht glaugt, das UUCP auch (oder gerade) heute noch seine
Daseinsberechtigung hat, dem kann ich nur empfehlen, das mal
auszuprobieren. Ich benutze das auf um fünf Rechner an verschiedenen
Standorten zu koppeln.
Solange es in Deutschland keine "richtigen" Internetanschlüsse auch
für Privatleute gibt, wird UUCP immer eine Daseinsberechtigung
haben. Die 'verkrüppelten' Internetzugänge, die zur Zeit massenweise
unter das Völk gebracht werden, können einfach nicht das leisten, was
speziell für diese Situation entwickelte Software leisten kann.
Mario Klebsch
>On Fri, 15 Sep 2000 21:41:52 +0200, ma...@klebsch.de (Mario Klebsch)
>wrote:
>>>- Jede Newsgroup, die man lesen möchte, erfordert eine explizite
>>> Bestellung. [...]
>>
>>Das ist bei anderen Arten des Feedens nicht anders.
>Nicht ganz. Wenn ich bei UUCP eine neue Group aufsetze, ist die
>erstmal leer. Wenn ich dasselbe bei NNTP tue, habe ich die Möglich-
>keit, mir die letzten n Postings/die letzten n Tage/die Postings mit
>einem bestimmten Subject/etc. nachliefern zu lassen.
Richtig, der Bootstrap dauert länger. Das hast Du aber nicht
bemängelt, sondern nur die Tatsache, dass Du jede Gruppe explizit
anmelden musst.
>>Es geht hier übrigens um ienen News-Server, nicht um einen Endanwender.
>Schon klar. Aber "große" Server mit hoher Gruppenzahl lassen sich per
>UUCP ohnehin kaum betreiben, und bei "kleinen" Servern mit handselek-
>tierter Gruppenauswahl halte ich Obiges für durchaus nützlich.
>>>- Newsgroups können immer nur vollständig bezogen werden. Eine
>>> Vorfilterung, z.B. das Ignorieren lästiger Endlosthreads oder das
>>> Löschen von Binary-Postings ist nicht möglich.
>>
>>Natürlich geht das, DU musst das in den Batcher einbauen.
>Ja, aber das muß auf Seiten des Feed getan werden, und ist damit
>zwangsläufig relativ statisch.
Da muss es aber uch bei Nutzung von NNT eingebaut werden, zumindest
wenn man sich mit Batheded NNTP feeden lasst. Wenn Du IHAVE/SENDME
benutzt, sehe ich aber auch nicht, wie Du da filtern willst.
>Es ist kaum möglich, mal schnell zu sagen "verdammt, heute waren schon
>wieder 200 Postings in diesem §$&§%$-Thread, jetzt bekommt das Ding
>einen Killfilter".
Wir reden hier von Servern, nicht von Readern.
>>Packt Dein Feed etwa keine Batches? Ein Löschen ist normalerweise auf
>>Batch-Ebene möglich.
>Wobei unspezifisch Inhalte aus allen Groups verlorengehen, auch
>solchen, die für mich wirklich wichtig sind.
Aber die alle gleich alt sind (und damit normalerweise schon dem
expiter zum opfer gefallen wären. In diesem Zusammenhang noch ein Wort
zur 'Archivfunktion' eines News-Servers: Ich hasse News-Server, die
ein Expire von über einem Monat fahren (oft sogar in der
Grössenordnung halbes bis ganzes Jahr). Nichts ist uninteressanter,
als die News von gestern (die heisst dann übrigends Olds).
>>>Bei Wählverbindungen bietet heute in der Regel schon das Medium
>>>(ISDN/Modem) eine effektive Kompression.
>>
>>Bei Modems muss ich Dir recht geben, aber bei ISDN wird (zumindest
>>wenn man wie ich X75 verwendet) überhaupt nichts komprimiert.
>>dazu habe ich von UUCP over TCP geschrieben, und bei IP over Modem ist
>>die Komprimierung des Modems reichlich wirkungslos,
>Hmm, die paar Byte IP-Header sollten eigentlich keinen derart
>gravierenden Einfluß haben, zumal die V42b-Kompression ohnehin nur auf
>128Byte-Blöcken operiert !??
Na, wenn Du es sagtst, ich kenne mich mit der Modemkompression nicht
aus. Der Vorteil vom versenden bereits komprimierter Daten besteht
darin, das im Kontext der ganzen Datei bessere Kompressionsraten
erzeilt werden können, als wenn man jeden Happen einzeln komprimiert.
Wenn man jetzt den Strom vom IP-Datagrammen al eine zu komprimierende
Einheit betrachtet, dann machen die vielen kleinen Dinge, die da neben
den Nutzdaten noch über die Leitung gehen, einem einen Grossteil der
Kompressionsmöglichkeiten wieder zu nichte.
>>bei IP over ISDN gibt es keine Komprimierung.
>Stimmt nicht. Ich habe jahrelang über snafu und uunet komprimierte
>ISDN-Verbindungen (PPP-Stac) genutzt, bevor ich im Frühjahr auf TDSL
>gewechselt habe.
Das ist aber keine Komprimierung des ISDN-Modems(auch wenn das
ISDN-Modem eigentlich TA heisst), sondern des darüber auf
Anwendungsseite benutzten Protokolles. Darin unterscheidet sich ein
ISDN-TA erheblich von einem analogen Modem.
>10% dürften es bei weitem nicht werden, da die gängigen Reader das gar
>nicht können, und nur ein verschwindender Teil der User eigene Server
>betreibt.
Na wenn Du Dich da nicht irrst. Ich gebe ja zu, das ich es nicht
sicher sagen kann, aber wir reden hier von News, ubnd die werden
sowiso nur von höchstens einem Prozent der Kunden eines Providers
genutzt, nämlich dem einem Prozent, das sich ein wenig mit dem
Internet auskennt. Ich halte es durchaus für realistisch, das davon
10% einen eigenen Server betreiben könnten (weil es eigentlich für
jeden regelmässigen Nutzer notwendig ist).
>Außerdem, so ganz ohne CPU-Last ist ein UUCP-Feed auch nicht. Vor
>allem wenn der User sehr viele Groups bezieht, und damit fast ohne
>Unterbrechung neue Daten für ihn eintrudeln...
Ok, Damit hast Du natürlich auch recht.
>>Mein Übertragungskanal hat eine Bandbreite von ca. 85KByte pro Sekunde
>>(T-DSL). Wenn ich darüber einen POLL per NNTP fahre, dann werden davon
>>im Mittel maximal 10KByte/Sekunde ausgenutzt.
>Ich nutze auch T-DSL, fahre normalerweise 4 Threads und komme damit
>auf im Mittel etwa 40kByte/sek. Da haben wir also ziemlich gleiche
>Erfahrungen.
Immerhin habe ich zu ISDN-Zeiten den einen ISDN-Kanal zu fast 50%
füllen können. Zu ISDN-Zeiten hätte ich daher auch keine derart
optimistischen Aussagen getroffen.
Hergen Lehmann
<expire...@usenet.th-h.de> wrote:
>> Falsch. Im Reader-Mode kann man erstmal die Header holen, danach
>> filtern, und hinterher nur die interessanten Artikel holen.
>
>Wer bitte betreibt denn auf diese Weise einen News_server_? Das ist dann
>doch arg eigenwillig.
Für kleine Server (kleiner Betrieb, WG, privat, ...) ist das höchst
sinnvoll, weil man so ohne viel Bürokratie, Wartungsaufwand und Suche
nach einem UUCP-Anbieter zum Komfort eines eigenen Servers kommt.
Schau´ Dir z.B. mal den Hamster an, ein kleiner Newsserver, der
speziell für diese Betriebsart konzipiert wurde.
Hergen
Hergen Lehmann
<fgko...@openunix.de> wrote:
>> UUCP kennt prinzipbedingt kein Expire.
>
>Aber der Newsserver, der dahinter läuft.
Ja und? Was nutzt mir das als UUCP-Nutzer?
>> möchte diesen reduzieren, ohne jedoch Inhalte in einer Handvoll groups
>> zu verlieren, die für mich/meinen Betrieb/mein Institut wirklich
>> wichtig sind. Wie geht das?
>
>gar nicht, je nachdem wie lange du in Urlaub fährst, sind die news weg
>(haltezeit).
Und warum widersprichst Du mir dann erstmal, nur um hinterher
zuzugeben, daß es tatsächlich nicht geht?
>Abgesehen davon sind Binaries im Usenet nicht sinnvoll.
Das Netz ist kein Selbstzweck. Es dient dazu, die Bedürfnisse der
Nutzer zu erfüllen. Binary-Groups sind vorhanden und werden sehr
intensiv genutzt, damit ist ihr Sinn IMO mehr als ausreichend
bewiesen.
Außerdem - was gibt es denn an Alternativen?
Webhoster? Größere Datenmengen darf man dort meist nicht ablegen, und
wenn doch, hat man sehr schnell die Kündigung im Haus, wenn auch
tatsächlich darauf zugegriffen wird.
Freedrive&Co? Die sind GÄHNEND langsam, und außerdem sehr umständlich
zu handhaben.
Eigener HTTP/FTP-Server? Zumindest bei vernünftiger Bandbreite haben
dazu nur die wenigsten die Möglichkeit.
Hergen
Holger Petersen
>On Fri, 15 Sep 2000 21:57:52 +0200, Franz Georg Köhler
><fgko...@openunix.de> wrote:
>>Expire kann man konfigurieren.
>UUCP kennt prinzipbedingt kein Expire.
Aus (meiner) crontab von uucp:
uustat -o 666 -c rnews -K -Q
Gruss, Holger
Hergen Lehmann
wrote:
>Richtig, der Bootstrap dauert länger. Das hast Du aber nicht
>bemängelt, sondern nur die Tatsache, dass Du jede Gruppe explizit
>anmelden musst.
Wo Du recht hast, hast Du recht. Ich muß meine Thesen präziser
formulieren :-/
>[Filter]
>>Ja, aber das muß auf Seiten des Feed getan werden, und ist damit
>>zwangsläufig relativ statisch.
>
>Da muss es aber uch bei Nutzung von NNT eingebaut werden, zumindest
>wenn man sich mit Batheded NNTP feeden lasst. Wenn Du IHAVE/SENDME
>benutzt, sehe ich aber auch nicht, wie Du da filtern willst.
Klar, da sieht alles wieder ganz anders aus. Allerdings kommt diese
Betriebsart i.d.R. ohnehin nur bei Standleitungen in Frage.
Bei Wählleitungen, um die es hier ja wohl hier in erster Linie ging,
heißen die Alternativen NNTP-Reader oder UUCP. Und da erscheint mir
NNTP doch um einiges flexibler.
>>Es ist kaum möglich, mal schnell zu sagen "verdammt, heute waren schon
>>wieder 200 Postings in diesem §$&§%$-Thread, jetzt bekommt das Ding
>>einen Killfilter".
>
>Wir reden hier von Servern, nicht von Readern.
Ja, ich auch :).
Ich kann bei meinem Hamster sehr einfach auf lokaler Seite solche
Filter setzen, die unmittelbar beim nächsten Poll wirksam werden.
Mit den "großen" Servern (INN&Co) habe ich mich noch nicht ausreichend
befaßt, aber ich kann mir nicht vorstellen, daß das da nicht möglich
sein soll... !?
>expiter zum opfer gefallen wären. In diesem Zusammenhang noch ein Wort
>zur 'Archivfunktion' eines News-Servers: Ich hasse News-Server, die
>ein Expire von über einem Monat fahren (oft sogar in der
>Grössenordnung halbes bis ganzes Jahr). Nichts ist uninteressanter,
>als die News von gestern (die heisst dann übrigends Olds).
Da bin ich anderer Ansicht.
Bei Announce- und FAQ-Gruppen sind Haltezeiten von möglichst sogar
mehreren Monaten geradezu Plicht, denn alle noch "gültigen" Postings
sollten ständig abrufbar sein.
Aber auch bei den "normalen" Gruppen können solche Haltezeiten Sinn
machen. Sicher wird niemand herkommen, und sich bei einer High-Traffic
Group mit 200 Postings/Tag einen ganzen Monat im Rückblick ansehen.
Aber er will eventuell doch noch mal auf ein einzelnes, älteres
Posting zugreifen. Oder auf einen Thread, an den er sich noch vage
erinnert, und der gerade neue Aktualität bekommen hat.
Schmerzen tun bei den heutigen Plattenkapazitäten solche Archive
niemanden, also warum nicht?
>[...]
>Na, wenn Du es sagtst, ich kenne mich mit der Modemkompression nicht
>aus. Der Vorteil vom versenden bereits komprimierter Daten besteht
>darin, das im Kontext der ganzen Datei bessere Kompressionsraten
>erzeilt werden können, als wenn man jeden Happen einzeln komprimiert.
Völlig klar. Aber so gravierend ist der Unterschied zwischen "gut" und
"weniger gut" komprimiert dann nicht mehr. Die Zeiten von 300baud-
Akustikkopplern, wo man auf jedes gesparte Byte stolz war, sind doch
langsam vorbei...
>>Stimmt nicht. Ich habe jahrelang über snafu und uunet komprimierte
>>ISDN-Verbindungen (PPP-Stac) genutzt, bevor ich im Frühjahr auf TDSL
>>gewechselt habe.
>
>Das ist aber keine Komprimierung des ISDN-Modems(auch wenn das
>ISDN-Modem eigentlich TA heisst),
Auch die meisten externen ISDN-TAs und -Router beherrschen Stac-
Kompression, dann in Hardware. Nur bei den billigen, passiven Karten
muß das die Software tun.
>sondern des darüber auf
>Anwendungsseite benutzten Protokolles. Darin unterscheidet sich ein
>ISDN-TA erheblich von einem analogen Modem.
Für den Anwender ist das aber egal, er bekommt so oder so Kompression
auf IP-Ebene. PPP ist kein Protokoll auf Anwendungsebene!
>>10% dürften es bei weitem nicht werden, da die gängigen Reader das gar
>>nicht können, und nur ein verschwindender Teil der User eigene Server
>>betreibt.
>
>Na wenn Du Dich da nicht irrst. Ich gebe ja zu, das ich es nicht
>sicher sagen kann, aber wir reden hier von News, ubnd die werden
>sowiso nur von höchstens einem Prozent der Kunden eines Providers
>genutzt, [...]
Hmm, ja, das ist natürlich auch wieder ein Argument...
----------------------- snip
>Noch ein kleiner Nachtrag:
>
>Wer nicht glaugt, das UUCP auch (oder gerade) heute noch seine
>Daseinsberechtigung hat, dem kann ich nur empfehlen, das mal
>auszuprobieren. [...]
Moment, ich habe nicht gesagt, daß ich für UUCP keine Daseinsberech-
tigung sehe.
Allerdings sehe ich die weniger beim normalen Usenet-Zugang, wo NNTP
einfach eine Vielzahl von Vorteilen bietet, und UUCP bestenfalls mit
einer minimal effizienteren Übertragung aufwarten kann.
Die große Stärke von UUCP liegt in der weit geringeren Zentralisie-
rung und Abhängigkeit von einer festen Infrastruktur.
Das könnte eines Tages wieder Gold wert sein, wenn die massiven
Zensurbestrebungen angeblich demokratischer Regierungen weiter
anhalten.
>Solange es in Deutschland keine "richtigen" Internetanschlüsse auch
>für Privatleute gibt, wird UUCP immer eine Daseinsberechtigung
>haben. Die 'verkrüppelten' Internetzugänge, die zur Zeit massenweise
>unter das Völk gebracht werden,
Naja, es gibt zum Glück immer noch ausreichend Anbieter, die ein
durchaus rundes Angebot mit Zugang, eigenem Newsserver, eigenem
Webhosting, etc. machen.
Und mit einem ISDN-/DSL-Router stört dann auch der Dialup kaum noch.
Es gibt nur sehr wenige Anwendungen, die wirklich auf statische IPs
und permanente Erreichbarkeit angwiesen sind. Und für die gibt es
immer noch Standleitungen, die heute auch weit preiswerter sind, als
noch vor wenigen Jahren.
>können einfach nicht das leisten, was
>speziell für diese Situation entwickelte Software leisten kann.
Moment, UUCP ist eigentlich für eine ganz andere Situation entwickelt,
nämlich für direkte Dialup-Verbindungen zwischen den beteiligten
Rechnern.
UUCP über IP ist mindestens genauso Mißbrauch, wie NNTP über Dialups.
Hergen
Mario Klebsch
>On Fri, 15 Sep 2000 23:30:49 +0200, Franz Georg Köhler
><fgko...@openunix.de> wrote:
>>> UUCP kennt prinzipbedingt kein Expire.
>>
>>Aber der Newsserver, der dahinter läuft.
>Ja und? Was nutzt mir das als UUCP-Nutzer?
Du sollst ja garnicht UUCP benutzen, sondern Dein News-Server soll das
tun. Aber sollen sollst DU das sowieso nicht, es sollte nur jeder so
machen können, wie er will.
Mario Klebsch
>Aber auch bei den "normalen" Gruppen können solche Haltezeiten Sinn
>machen. Sicher wird niemand herkommen, und sich bei einer High-Traffic
>Group mit 200 Postings/Tag einen ganzen Monat im Rückblick ansehen.
Leider habe ich schon Provider erlebt, die auch in solchen Gruppen ein
Expire von über einem halben Jahr haben. Das macht beim initialen
Abbonieren einer Gruppe immer besonders Spass. Ich musst z.B. leafnode
extra dahingehend ändern, mich dabei nicht mit Telefonkosten zu
ruinieren.
>Aber er will eventuell doch noch mal auf ein einzelnes, älteres
>Posting zugreifen. Oder auf einen Thread, an den er sich noch vage
>erinnert, und der gerade neue Aktualität bekommen hat.
Dazu gibt (und gab es schon immer) News-Archive. Deja-News ist da nur
das bekannteste.
>Schmerzen tun bei den heutigen Plattenkapazitäten solche Archive
>niemanden, also warum nicht?
Sie stören IMHO jeden neuen Leser dieser Gruppen. Wenn ich in eine
neue Gruppe komme, und dort 30000 Postings vorfinde, die mehrere
Monate alt sind, dann suche ich nicht weiter.
>Völlig klar. Aber so gravierend ist der Unterschied zwischen "gut" und
>"weniger gut" komprimiert dann nicht mehr.
Unterschätze bitte die moderne Kompressonsverfahren nicht. Alleine der
in den News verwendete Symbolsatz dürfte bei um die 100 Symbolen
liegen. Wenn Du die News aber per IP überträgst 8und den IP-Stream
komprimieren willst), bist Du schon wieder bei 256 Symbolen.
>>Das ist aber keine Komprimierung des ISDN-Modems(auch wenn das
>>ISDN-Modem eigentlich TA heisst),
>Auch die meisten externen ISDN-TAs und -Router beherrschen Stac-
>Kompression, dann in Hardware. Nur bei den billigen, passiven Karten
>muß das die Software tun.
Bitte korrigiere mich, wenn ich mich irren sollte, aber STAC ist doch
eine Kompression im PPP-Protokoll, und nicht im darunter liegenden
Übertragungsverfahren.
>>Solange es in Deutschland keine "richtigen" Internetanschlüsse auch
>>für Privatleute gibt, wird UUCP immer eine Daseinsberechtigung
>>haben. Die 'verkrüppelten' Internetzugänge, die zur Zeit massenweise
>>unter das Völk gebracht werden,
>Naja, es gibt zum Glück immer noch ausreichend Anbieter, die ein
>durchaus rundes Angebot mit Zugang, eigenem Newsserver, eigenem
>Webhosting, etc. machen.
Ich habe leider noch keinen gefunden, dessen Angebot die Bezeichnung
Internetanschluss verdient hätte, und der dabei noch bezahlbar ist.
>Und mit einem ISDN-/DSL-Router stört dann auch der Dialup kaum noch.
Es würde Dich auch überhaupt nicht stören, wenn das Telefon in Zukunft
nicht mehr klingeln würde (weder das drahtgebundene, noch das
Handy). Für einen Telefonanschluss, an dem Telefone auch klingeln
können, würdest Du gerne das zehn bis hundertfache an Gebühren
bezahlen? Habe ich Dich da in etwa richtig verstanden?
>Es gibt nur sehr wenige Anwendungen, die wirklich auf statische IPs
>und permanente Erreichbarkeit angwiesen sind.
Davon gibt es mehr, als immer so gedacht wird. Aber sie haben sich
(aufgrund mangelnder Benutzbarkeit bei dynamischen IPs) auch nicht so
weit verbreiten können, die die Anwendungen, die auch bei
verkrüppelten Zugängen immer noch funktionieren.
>Und für die gibt es immer noch Standleitungen, die heute auch weit
>preiswerter sind, als noch vor wenigen Jahren.
Schwacher Trost.
>>können einfach nicht das leisten, was
>>speziell für diese Situation entwickelte Software leisten kann.
>Moment, UUCP ist eigentlich für eine ganz andere Situation entwickelt,
>nämlich für direkte Dialup-Verbindungen zwischen den beteiligten
>Rechnern.
Genau dafür will ich es doch verwenden.
>UUCP über IP ist mindestens genauso Mißbrauch, wie NNTP über Dialups.
UUCP geht über TCP, und das ist duchaus als Wählverbindung zu
bezeichnen.
Wolfgang Broeker
> Leider habe ich schon Provider erlebt, die auch in solchen Gruppen
> Abonnieren einer Gruppe immer besonders Spass.
Bis hierhin habe ich Eure Diskussion mit Interesse verfolgt,
aber jetzt versteigst Du Dich. Es kann doch niemals ein Nach-
teil sein, wenn Dein Provider, egal ob er Lebensmittel oder
News anbietet, ein zu großes Angebot hat. Es spricht gegen
*Deine* Konfiguration, wie immer sie aussieht, wenn Du mit
einem zu großen Angebot Probleme hast.
> Dazu gibt (und gab es schon immer) News-Archive. Deja-News
> ist da nur das bekannteste.
Mit Deja wirklich vergleichbares kenne zumindest ich nicht,
und Deja hatte vor einiger Zeit echte Probleme. Zeitweise
schien es fraglich zu sein, ob Deja mit seinem Archiv wieder
ans Netz geht.
> [Große Plattenkapazitäten von Newsservern]
> Sie stören IMHO jeden neuen Leser dieser Gruppen. Wenn ich
> in eine neue Gruppe komme, und dort 30000 Postings vorfinde,
> die mehrere Monate alt sind, dann suche ich nicht weiter.
Nochmal: Das ist einfach ein Problem Deiner Software, wenn
Sie Dir mit Gewalt das gesamte Archiv zum Download aufzwingt.
Gruß - Wolfgang
--
*** Don't Call Us, We'll Call You ***
*** Sat, 16 Sep 2000 17:51 +0200 ***
Jürgen Fenn
> Es spricht gegen
> *Deine* Konfiguration, wie immer sie aussieht, wenn Du mit
> einem zu großen Angebot Probleme hast.
> Nochmal: Das ist einfach ein Problem Deiner Software, wenn
> Sie Dir mit Gewalt das gesamte Archiv zum Download aufzwingt.
Hallo Wolfgang,
das sehe ich ja prinzipiell genauso.
Leider habe ich aber erlebt, daß nur der Netscape auf ein Limit von,
sagen wir mal 150 Kopfdaten UND Nachrichten einstellbar war. Sowohl OE
5 als auch StarOffice laden erst mal alles herunter, was verfügbar
ist. Das heißt dann bei Microsoft- oder bei großen juristischen
Gruppen ca. 40000 Postings :-( Ich bin mal mit OE über eine
Viertelstunde online gewesen, nur um eine NG zu abonnieren. Die
Optimierung der Einstellungen mit Hilfe der OE-NG hatte auch nicht
viel geholfen.
Solange diese Probleme bei den meisten Programmen aber bestehen, halte
ich es somit dennoch für sinnvoll, die Anzahl der Nachrichten auf dem
Server zu begrenzen.
Grüße, Jürgen.
Wilfried Wurch
> Solange diese Probleme bei den meisten Programmen aber bestehen,
> halte ich es somit dennoch für sinnvoll, die Anzahl der Nachrichten
> auf dem Server zu begrenzen.
OE und Staroffice sind aber nicht "die meisten Programme" (viele würde
sie nichtmal als vollwertige Newsreader sehen, mich eingeschlossen). Ich
kenne eigentlich nur Newsreader, denen man ganz genau sagen kann,
wieviele Header sie herunterladen sollen.
Für Leute, die solche Newsreader benutzen, ist eine lange Haltedauer
recht hilfreich - speziell, wenn der Newsreader über Funktionen verfügt,
auf dem Newsserver nach Artikeln zu suchen.
wil
Hergen Lehmann
wrote:
>Leider habe ich schon Provider erlebt, die auch in solchen Gruppen ein
>Expire von über einem halben Jahr haben. Das macht beim initialen
>Abbonieren einer Gruppe immer besonders Spass. Ich musst z.B. leafnode
>extra dahingehend ändern, mich dabei nicht mit Telefonkosten zu
>ruinieren.
Muss man das Ding tatsächlich schon für eine so grundlegende Funktion
patchen? Schwach.
Beim Hamster trage ich einfach im Konfigurationsdialog ein Pull-Limit
von n Postings ein, und gut ist. Dabei kann ich sogar für einzelne
Gruppen Ausnahmen machen, die ich gerne unter allen Umständen
vollständig will.
>Dazu gibt (und gab es schon immer) News-Archive. Deja-News ist da nur
>das bekannteste.
Leider sind diese Archive (dank X-No-Archive und anderer Faktoren)
immer mehr oder weniger unvollständig. Von der grauseligen
Bedienoberfläche ganz zu schweigen.
>Sie stören IMHO jeden neuen Leser dieser Gruppen. Wenn ich in eine
>neue Gruppe komme, und dort 30000 Postings vorfinde, die mehrere
>Monate alt sind, dann suche ich nicht weiter.
[X] Deine Software taugt nix ;)
>Unterschätze bitte die moderne Kompressonsverfahren nicht. Alleine der
>in den News verwendete Symbolsatz dürfte bei um die 100 Symbolen
>liegen. Wenn Du die News aber per IP überträgst 8und den IP-Stream
>komprimieren willst), bist Du schon wieder bei 256 Symbolen.
Gerade ein gutes, modernes Kompressionsverfahren sollte sich NICHT aus
dem Takt bringen lassen, wenn alle 1500 Symbole mal ein paar
auftauchen, die nicht aus dem Satz der 100 vorherrschenden Symbole
stammen.
>Bitte korrigiere mich, wenn ich mich irren sollte, aber STAC ist doch
>eine Kompression im PPP-Protokoll, und nicht im darunter liegenden
>Übertragungsverfahren.
Korrekt. In welcher Schicht die Kompression nun genau stattfindet, ist
aber herzlich egal.
Fakt bleibt: Es ist möglich, über ISDN komprimierte IP-Verbindungen
aufzubauen, und zwar völlig transparent für die Anwendungsschicht.
>>Naja, es gibt zum Glück immer noch ausreichend Anbieter, die ein
>>durchaus rundes Angebot mit Zugang, eigenem Newsserver, eigenem
>>Webhosting, etc. machen.
>
>Ich habe leider noch keinen gefunden, dessen Angebot die Bezeichnung
>Internetanschluss verdient hätte, und der dabei noch bezahlbar ist.
Ja? Also ich hatte damit nie Probleme.
Das Einzige, worauf ich verzichten muß, ist eine statische IP. Das
sehe ich aber gar nicht mal unbedingt als Nachteil (s.unten).
>>Und mit einem ISDN-/DSL-Router stört dann auch der Dialup kaum noch.
>
>Es würde Dich auch überhaupt nicht stören, wenn das Telefon in Zukunft
>nicht mehr klingeln würde (weder das drahtgebundene, noch das
>Handy).
Moment - Das "Dialup-IP-Telefon" klingelt ja nicht gar nicht, sondern
es klingelt ggf. zeitverzögert zu den Zeitpunkten, die ICH bestimmen
kann. Wobei sich dank Flatrate die Verzögerung zur "Geschäftszeit"
durchaus auch auf Null senken läßt.
Ja, das stört mich überhaupt nicht. "Echte" Telefone haben die
unangenehme Angewohnheit, immer genau dann zu klingeln, wenn man es
überhaupt nicht brauchen kann. Und nach Murphy ist dann natürlich auch
immer gerade einer der Leute dran, die extrem mitteilsam sind :-/.
email ist da doch sehr viel angenehmer.
Dazu kommt noch ein weiterer Faktor: Eine permanente Verbindung zum
Internet ist ein zusätzliches Sicherheitsrisko. Ein Hacker hat hier
alle Zeit der Welt, sein Opfer in Ruhe auszukundschaften und schließ-
lich zu einem günstigen Zeitpunkt anzugreifen.
Bei Dialups mit dynamischer IP stellen sich ihm dagegen mehrere Hürden
in den Weg:
- Er muß überhaupt erstmal in dem riesigen Wust der privaten Daddler
ein lohnendes Opfer finden, gezielte Angriffe sind kaum möglich.
- Er hat nur begrenzte Zeit zur Verfügung, bis die Verbindung wieder
getrennt wird.
- Er kann nur zu Zeitpunkten angreifen, wo der Rechner bedient wird,
und ist somit einem erhöhten Entdeckungsrisiko ausgesetzt.
Feste IPs gefährdem zudem die Privatsphäre. Du bist bei Server-
zugriffen jederzeit eindeutig identifizierbar, auch noch nach Monaten
und über die Grenzen eines Servers hinweg.
234.12.34.56 schreibt in den News böse Dinge über uns? Schauen wir
doch mal in unsere Kundendatenbank. Ah ja, der Mario Klebsch, der vor
zwei Monaten mal was bei uns bestellt hat... schreiben wir doch mal
eine nette Abmahnung.
Nein, wenn ich nicht für einen konkreten Zweck eine feste IP
*brauche*, will ich auch gar keine.
>Für einen Telefonanschluss, an dem Telefone auch klingeln
>können, würdest Du gerne das zehn bis hundertfache an Gebühren
>bezahlen? Habe ich Dich da in etwa richtig verstanden?
Nein, hast Du nicht ;)
>Davon gibt es mehr, als immer so gedacht wird. Aber sie haben sich
>(aufgrund mangelnder Benutzbarkeit bei dynamischen IPs) auch nicht so
>weit verbreiten können, die die Anwendungen, die auch bei
>verkrüppelten Zugängen immer noch funktionieren.
Wenn diese Anwendungen offenbar nicht wirklich auf statische IPs
angewiesen sind, ist es gut, daß die Programmierer auf diese Weise
daran erinnert werden, sauber zu programmieren und Ressourcenver-
schwendung zu vermeiden.
Hergen
P.S.: Mit der Verlagerung auf das Thema IP werden wir hier off-topic.
Daher Followup-To: poster gesetzt.
Mario Klebsch
>Jürgen Fenn <fe...@stud.uni-frankfurt.de> schrieb:
>> Solange diese Probleme bei den meisten Programmen aber bestehen,
>> halte ich es somit dennoch für sinnvoll, die Anzahl der Nachrichten
>> auf dem Server zu begrenzen.
>OE und Staroffice sind aber nicht "die meisten Programme" (viele würde
>sie nichtmal als vollwertige Newsreader sehen, mich eingeschlossen). Ich
>kenne eigentlich nur Newsreader, denen man ganz genau sagen kann,
>wieviele Header sie herunterladen sollen.
Ich benutzte nn. Nn ist bekannt als der Newsreader für
Power-User. Aber selbst Da hast Du echt Probloeme, wenn Du bei einer
neuen Newsgroup gleicht 40000 Artikel präsentiert bekommst.
Wenn es ein 'normaler' Betriebszustand für News wäre, einen neuen
Benutzer mit derart vielen Artikeln in jeder neuen Gruppe zu
erschalgen, dann würden die Newsreader mit Sicherheit damit besser
umgehen können. Ein News-Server war nie ein Archiv, und hier geht es
wirklich zu Lasten der Benutzbarkeit.
Frank Kloeker
> OE und Staroffice sind aber nicht "die meisten Programme"
Ach, hast Du ne Ahnung *g*
Postingstatistik fuer den Bereich de.* 08.2000
X-Newsreader|X-Mailer|X-Software|User-Agent TOP100:
Prozent Anzahl Typ
---------------------------------------------------------
30.48 133729 Microsoft Outlook Express [Version]
...
--
Don't dream your life, live your dream!
Christoph Garbers
> Leider habe ich aber erlebt, daß nur der Netscape auf ein Limit von,
> sagen wir mal 150 Kopfdaten UND Nachrichten einstellbar war. Sowohl OE
> 5 als auch StarOffice laden erst mal alles herunter, was verfügbar
> ist. Das heißt dann bei Microsoft- oder bei großen juristischen
> Gruppen ca. 40000 Postings :-(
[...]
> Solange diese Probleme bei den meisten Programmen aber bestehen,
^^^^^^^
OE und Netscape machen zwar in de.* den größten Teil des Traffics aus,
sind aber nur zwei Programme unter vielen. Mein Reader fragt mich vor
Betreten einer Gruppe, wie viele Artikel ich haben will. Finde ich sehr
praktisch und möchte ich auch nicht mehr missen.
> halte ich es somit dennoch für sinnvoll, die Anzahl der Nachrichten auf
> dem Server zu begrenzen.
Ich nicht. Grade wenn ich eine neue Gruppe hole, möchte ich gerne auch
mal mehr Artikel haben als nur die letzten 8 Tage.
Christoph
--
Organisation is as well necessary as inspiration.
- T. S. Eliot
Daniel Weber
news:39C3DA41...@stud.uni-frankfurt.de...
> Leider habe ich aber erlebt, daß nur der Netscape auf ein Limit von,
> sagen wir mal 150 Kopfdaten UND Nachrichten einstellbar war. Sowohl OE
> 5 als auch StarOffice laden erst mal alles herunter, was verfügbar
> ist. Das heißt dann bei Microsoft- oder bei großen juristischen
> Gruppen ca. 40000 Postings :-( Ich bin mal mit OE über eine
> Viertelstunde online gewesen, nur um eine NG zu abonnieren.
Falsch, wenn Du bei OE eine Gruppe "betrittst" ohne vorher zu
synchronisieren holt er 300 "Köpfe" ab. Die Zahl selbst kannst Du in der
Konfiguration beliebig erhöhen.
Bye,
Daniel
Wolfgang Broeker
> Wenn es ein 'normaler' Betriebszustand für News wäre, einen neuen
> Benutzer mit derart vielen Artikeln in jeder neuen Gruppe zu
> umgehen können. Ein News-Server war nie ein Archiv, und hier geht es
> wirklich zu Lasten der Benutzbarkeit.
Ich kann heutzutage keinen wirklichen Grund erkennen, warum News-
server nicht auch als Archiv dienen könnten. Ein Jahr dana z.B.
dürfte kaum mehr Plattenplatz verbraten als ein Tag einer MP3-
Dateien-Gruppe (OK, das ist ein extremes Beispiel).
Mir ist schon klar, dass es früher Zwänge gab, die Haltezeit auf
den Servern kurz zu halten, aber Unzulänglichkeiten der Reader-
Software sollten jedenfalls kein bestimmender Punkt für Parametri-
sierungen auf der Server-Seite sein, wenn diese alten Zwänge ent-
fallen sind.
Gruß - Wolfgang
--
*** Don't Call Us, We'll Call You ***
*** Sun, 17 Sep 2000 08:51 +0200 ***
Florian Kruse
>>Ich erwarte auf diese Weise eine Reduktion meiner durch Newstransfer
>>erreichten Onlinezeit auf unter 10% des jetzigen Wertes.
> Hmm, meine stündlichen NNTP-Polls dauern bei ca. 130 bezogenen Gruppen
> und vier Threads zwischen 10 und 30 Sekunden (per ISDN), je nach
> Traffic. Wobei da teilweise noch die etwas schwache Maschine (P90/64MB
> unter NT4) und die nicht optimale Netzanbindung bei der sekunden-
> genauen Einwahlnummer mit bremsen.
Lassen wir mal Zahlen sprechen:
Meine Batches mit bzip2 komprimierten Batches werden auf ~13 %
herunterkomprimiert. Ich hole mir diese per Modem, bei ca 5 kb/s.
Als ich vorher noch bei news.cis.dfn.de war, pullte ich dort mit 4 Threads
gleichzeitig. Die Übertragungsrate, die ich schaffte, war bei ca. 8 kb/s
dank Modemkomprimierung. Natürlich ist da der Overhead durch die
NNRP-Befehle schon mit drin.
Nehmen wir mal an, ich könnte meine Batches nur auf 15 %
herunterkomprimieren, dann wäre ein übliches 100 kB-Batch unkomprimiert
667 kB groß. Um das runterzuladen brauche ich bei 5 kB/s 20 s.
Für die 667 kB bräuchte ich bei 8 kB/s 83,4 s. Zuzüglich Overhead.
Fazit: Ich brauche noch weniger als 24,0 % der bisherigen Zeit.
Wenn ich jetzt nicht irgendwas falchs gerechnet habe, dann lohnt ein
UUCP-Feed auf jeden Fall. Selbst für Leute, die nur Header und dann
selektierte Bodys runterladen und durch UUCP alles auf einmal runterladen
müssten.
> Eine Reduktion auf 10% scheint mir heftig zu hoch gegriffen, realis-
> tisch dürften eher "Reduktion um 10%-20%" sein.
s.o.
> (Natürlich kann man diesen Wert beliebig verschieben, indem man die
> Möglichkeiten eines der beiden Protokolle einfach nicht ausnutzt. Aber
> wir wollen ja einen fairen Vergleich, gelle?)
Irgendwas bei mir nicht fair? So war bzw. ist es zumindest bei meiner
Anbindung.
FloKru
--
"Na, das war ja einfach", sagt der Mensch und beweist, weil's gerade so schön
war, dass schwarz gleich weiß ist, und kommt wenig später auf einem
Zebrastreifen ums Leben. [Douglas Adams: Per Anhalter durch die Galaxis]
Jürgen Fenn
> Falsch, wenn Du bei OE eine Gruppe "betrittst" ohne vorher zu
> synchronisieren holt er 300 "Köpfe" ab. Die Zahl selbst kannst Du in der
> Konfiguration beliebig erhöhen.
Hi Daniel,
das geht aber nur online, und wenn man danach nur noch "normal"
synchronisieren will, muß man vorher über "Aufholen" und das
Verstellen des Datums tricksen, wie mir erklärt wurde. Die
Einstellung, auf die Du anspielst, ist nur beim online-Lesen wirksam.
Darüberhinaus sei nur durch Formulieren einer vor dem Herunterladen
einegebenen Regel, Nachrichten nach, sagen wir: 7 Tagen zu löschen,
der Download zu begrenzen. Die Header werden aber auf alle Fälle alle
eingelesen. Das sind meine Erfahrungen mit dem OE 5.0. Mal ganz
abgesehen von dem zähen Handling meiner nur 10 NGs.
Da der Forte Free Agent der deutschen Sprache nicht mächtig ist und
StarOffice bei Newsgroups leider unendlich langsam ist, bleibt mir nur
der Netscape, der vor dem Herunterladen tatsächlich nachfragt und den
Download auch hinreichend schnell erledigt.
Grüße, JÜrgen.
Wolfgang Broeker
> Nehmen wir mal an, ich könnte meine Batches nur auf 15 %
> herunterkomprimieren, dann wäre ein übliches 100 kB-Batch unkomprimiert
> 667 kB groß. Um das runterzuladen brauche ich bei 5 kB/s 20 s.
>
> Für die 667 kB bräuchte ich bei 8 kB/s 83,4 s. Zuzüglich Overhead.
>
> Fazit: Ich brauche noch weniger als 24,0 % der bisherigen Zeit.
In Prozentsätzen und Sekunden sieht das auch alles beeindruckend
aus, aber nach Umrechnung in Pfennige zu üblichen IbC-Tarifen
darf die Frage erlaubt sein, ob sich dafür die geringere Fexibi-
lität und der höhere serverseitige Aufwand lohnen.
Gruß - Wolfgang
--
*** Don't Call Us, We'll Call You ***
*** Sun, 17 Sep 2000 15:45 +0200 ***
Wilfried Wurch
> > OE und Staroffice sind aber nicht "die meisten Programme"
>
> Ach, hast Du ne Ahnung *g*
> Postingstatistik fuer den Bereich de.* 08.2000
> X-Newsreader|X-Mailer|X-Software|User-Agent TOP100:
> Prozent Anzahl Typ
> ---------------------------------------------------------
> 30.48 133729 Microsoft Outlook Express [Version]
Die Statistik kenne ich. Sie besagt, daß 30,48% der Artikel in de.* im
August 2000 mittels OE gepostet wurden. Sie besagt nicht, daß OE und
Staroffice die meisten Programme sind (was ja bedeuten würde, daß es
außer OE und Staroffice nur noch ein anderes Programm geben würde).
wil
Wilfried Wurch
> Wenn es ein 'normaler' Betriebszustand für News wäre, einen neuen
> Benutzer mit derart vielen Artikeln in jeder neuen Gruppe zu
> erschalgen, dann würden die Newsreader mit Sicherheit damit besser
> umgehen können.
Hmm, ich hatte in letzter Zeit eigentlich nur mit Newsreadern zu tun,
mit denen es kein Problem war auf NGs mit zigtausend Artikeln
zuzugreifen. Das sogar Unix-Newsreader hier ein Problem haben, hätte ich
nicht gedacht.
> Ein News-Server war nie ein Archiv, und hier geht es wirklich zu
> Lasten der Benutzbarkeit.
Einem OE-User würde man jetzt sagen: "Dann besorg' dir halt einen
*richtigen* Newsreader" ;-)
Ehrlich, einen Newsreader, dem man nicht sagen kann, wieviele der
aktuellsten Artikel er laden soll, halte ich nicht für besonders
komfortabel.
Auf news.cis.dfn.de sind wochenlange Haltezeiten anscheinend die Regel
und ich persönlich finde das echt klasse, hat mir schon mehrmals
geholfen.
Mein Newsreader kommt mit der Menge klar und ich kann zudem den
Newsserver teilweise wesentlich komfortabler als Suchmaschine nutzen als
etwa deja.com.
wil
Daniel Weber
> das geht aber nur online, und wenn man danach nur noch "normal"
> synchronisieren will, muß man vorher über "Aufholen" und das
> Verstellen des Datums tricksen, wie mir erklärt wurde. Die
> Einstellung, auf die Du anspielst, ist nur beim online-Lesen wirksam.
Also wenn ich weiß, dass es sehr viele Postings in einer Group gibt, dann
lese ich sie das erste mal Online, dann gibts maximal 300 Kopfzeilen, stelle
dann die gewünschte synchronisation ein, und mache mit normaler
Synchronisation und Offlinelesen weiter, da hat er noch nie mehrere Tausend
Artikel geholt.
> Das sind meine Erfahrungen mit dem OE 5.0. Mal ganz
> abgesehen von dem zähen Handling meiner nur 10 NGs.
Naja, ich hab hier für den Großteil meiner Groups einen lokalen Newsserver,
damit ist das Handling selbst bei 60 Gruppen noch Flüssig, weils eben mit
100 MBit/s übers LAN rauscht. Mit einer langsamen WAN-Verbindung hab ichs
noch nicht mit mehr als einigen wenigen probiert...
> bleibt mir nur der Netscape, der vor dem Herunterladen tatsächlich
> nachfragt und den Download auch hinreichend schnell erledigt.
Nichts sei mir ferner, Dich zum OE bekehren zu wollen, ich wollte nur mit
obigem Missverständniss aufräumen.
Bye,
Daniel
Franz Georg Köhler
> Florian Kruse schrub[tm]:
>> Nehmen wir mal an, ich könnte meine Batches nur auf 15 %
>> herunterkomprimieren, dann wäre ein übliches 100 kB-Batch unkomprimiert
>> 667 kB groß. Um das runterzuladen brauche ich bei 5 kB/s 20 s.
>>
>> Für die 667 kB bräuchte ich bei 8 kB/s 83,4 s. Zuzüglich Overhead.
>>
>> Fazit: Ich brauche noch weniger als 24,0 % der bisherigen Zeit.
>
> In Prozentsätzen und Sekunden sieht das auch alles beeindruckend
> aus, aber nach Umrechnung in Pfennige zu üblichen IbC-Tarifen
> darf die Frage erlaubt sein, ob sich dafür die geringere Fexibi-
> lität und der höhere serverseitige Aufwand lohnen.
Die Flexibilität ist IMHo bei UUCP größer, da du ja alle Artikel hast,
und nicht dauernd welche Nachladen mußt.
Gruß,
Franz Georg Köhler
--
http://www.hanau.net/fgk/ 0x5E7A588D
Alle unsere Unixkisten wurden hingestellt und laufen. Bei Windows läuft
vor allem der Mensch, der versuchen darf, das Zeug in Gang zu halten.
Jens Dittmar in de.comp.advocacy
Franz Georg Köhler
> On Fri, 15 Sep 2000 23:30:49 +0200, Franz Georg Köhler
> <fgko...@openunix.de> wrote:
>
>>> UUCP kennt prinzipbedingt kein Expire.
>>
>>Aber der Newsserver, der dahinter läuft.
>
> Ja und? Was nutzt mir das als UUCP-Nutzer?
UUCP kann alles mögliche transportieren, unter anderem halt auch news.
Expire hast du auch bei nntp.
>>gar nicht, je nachdem wie lange du in Urlaub fährst, sind die news weg
>>(haltezeit).
>
> Und warum widersprichst Du mir dann erstmal, nur um hinterher
> zuzugeben, daß es tatsächlich nicht geht?
es geht auch bei NNTP nicht, da gibts ja auch die Haltezeit (abgesehen
von Archiven die dejanews).
>>Abgesehen davon sind Binaries im Usenet nicht sinnvoll.
>
> Das Netz ist kein Selbstzweck. Es dient dazu, die Bedürfnisse der
> Nutzer zu erfüllen. Binary-Groups sind vorhanden und werden sehr
> intensiv genutzt, damit ist ihr Sinn IMO mehr als ausreichend
> bewiesen.
Stimmt, Sven hat bewiesen, daß sie genutzt werden.
> Außerdem - was gibt es denn an Alternativen?
> Webhoster? Größere Datenmengen darf man dort meist nicht ablegen, und
> wenn doch, hat man sehr schnell die Kündigung im Haus, wenn auch
> tatsächlich darauf zugegriffen wird.
Ich hab das lange über tripod gemacht, es gab keine Probleme.
> Eigener HTTP/FTP-Server? Zumindest bei vernünftiger Bandbreite haben
> dazu nur die wenigsten die Möglichkeit.
Wenn du ISDN hast, kannst du in einer Stunde 25 Mbyte übertragen, das
reicht doch...
Thomas Hochstein
>> OE und Staroffice sind aber nicht "die meisten Programme"
>
> Ach, hast Du ne Ahnung *g*
Sie mögen "die meistgenutzten" sein, aber sie bilden sicherlich nicht die
Mehrzahl der am Markt befindlichen Newsreader. :-)
-thh
Frank Kloeker
> Sie mögen "die meistgenutzten" sein, aber sie bilden sicherlich nicht die
> Mehrzahl der am Markt befindlichen Newsreader. :-)
Wen interessiert schon die Mehrzahl der am Markt befindlichen Programme?
Ein Drittel aller Teilnehmer im dt. Usenet postet mit Outlock - die
Zahlen sind bezeichnend.
Frank Kloeker
>
> Die Statistik kenne ich. Sie besagt, daß 30,48% der Artikel in de.* im
> August 2000 mittels OE gepostet wurden. Sie besagt nicht, daß OE und
> Staroffice die meisten Programme sind (was ja bedeuten würde, daß es
> außer OE und Staroffice nur noch ein anderes Programm geben würde).
Usenet for the masses - und die Masse benutzt ebend OE.
Aber ich bin ja schon ruhig - ich kenne OE nicht mal und kann eigentlich
gar nicht mitreden ;)
Wilfried Wurch
> Ein Drittel aller Teilnehmer im dt. Usenet postet mit Outlock - die
> Zahlen sind bezeichnend.
Du interpretierst die Statistik falsch: ca. 1/3 der postings in de.*
wurde mit OE erstellt - über die Anzahl der Autoren sagt die Statistik
überhaupt nichts aus.
Außerdem muß man das andersherum sehen: nahezu 70% aller postings
entstehen *nicht* mit Hilfe von OE ;-)
wil
Thomas Hochstein
> Ein Drittel aller Teilnehmer im dt. Usenet postet mit Outlock - die
> Zahlen sind bezeichnend.
Richtig. Das geht aber weitgehend auch mit der inhaltlichen Qualität
dieser Postings konform. ;-)
-thh
Kai 'wusel' Siering
% >>Expire kann man konfigurieren.
% >
% > UUCP kennt prinzipbedingt kein Expire.
%
% Aber der Newsserver, der dahinter läuft.
Das würde dann aber batch-on-dialin voraussetzen, was ab einer be-
stimmten Anzahl an zu batchenden Artikeln reichlich zeitintensiv
wird und die Maschine extrem peakartig belastet. Usus dürfte eher
ein kontinuirliches Batching alle n Minuten sein, dann aber greift
des Newsservers expiry nicht mehr.
Ciao,
kai
--
The views expressed here are not neccessarily those of any employer.
"Usenet seems to run much like the Kif (or, for the TV generation, Klingon)
high command. Whoever takes action and can be heard wins."
-- Peter da Silva <pe...@ferranti.com>
Frank Kloeker
> Du interpretierst die Statistik falsch: ca. 1/3 der postings in de.*
> wurde mit OE erstellt - über die Anzahl der Autoren sagt die Statistik
> überhaupt nichts aus.
Mhmm, entwickelt Dein Newsreader ein Eigenleben?
Das ist aber eigenwillig *g*
> Außerdem muß man das andersherum sehen: nahezu 70% aller postings
> entstehen *nicht* mit Hilfe von OE ;-)
"mit _Hilfe_ von OE" ist auch etwas ungluecklich ausgedrueckt
*scnr*
Wilfried Wurch
> > Du interpretierst die Statistik falsch: ca. 1/3 der postings in de.*
> > wurde mit OE erstellt - über die Anzahl der Autoren sagt die Statistik
> > überhaupt nichts aus.
>
> Mhmm, entwickelt Dein Newsreader ein Eigenleben?
Ist das denn wirklich so schwer zu verstehen?
Im Monat August wurden in de.* 438803 Artikel gepostet. 133729 davon
sind trotz/mit OE gepostet worden. Es könnte sein, daß hier 133729 Leute
jeweils einen Artikel gepostet haben oder auch, daß ein Mensch 133729
Artikel gepostet hat - oder jedes andere Verhältnis zwischen Anzahl der
Postings und Anzahl der Autoren dazwischen.
Über die Anzahl der Autoren macht die Statistik keine Aussage. Jetzt
verstanden?
wil
Joern Bredereck
> Wen interessiert schon die Mehrzahl der am Markt befindlichen Programme?
> Ein Drittel aller Teilnehmer im dt. Usenet postet mit Outlock - die
> Zahlen sind bezeichnend.
ersetze "bezeichnend" mit "besorgniserregend". Dann stimmt der Satz! :-)
Ciao,
jb
Wolfgang Broeker
> Die Flexibilität ist IMHo bei UUCP größer, da du ja alle
> Artikel hast, und nicht dauernd welche Nachladen mußt.
Das ist dann der Punkt, wo sich unsere bescheidenen Meinun-
gen teilen: Das obligatorische Laden *aller* Artikel halte
ich nicht für ein Zeichen von Flexibilität, sondern für ei-
nen Zwang: mein Newsreader erlaubt mir daneben auch, regel-
gesteuert, das Ignorieren von Artikeln je nach Autor, Thread-
zugehörigkeit, im Subject enthaltener Zeichenkette, Anzahl
der Zeilen und einigem anderen mehr.
Zugegebenermaßen müssen die Header immer geholt werden, um
diese Optionen ausüben zu können.
Gruß - Wolfgang
--
*** Don't Call Us, We'll Call You ***
*** Sun, 17 Sep 2000 20:07 +0200 ***
Lars Noschinski
> Thomas Hochstein wrote:
>
>> Sie mögen "die meistgenutzten" sein, aber sie bilden sicherlich
>> nicht die Mehrzahl der am Markt befindlichen Newsreader. :-)
>
> Wen interessiert schon die Mehrzahl der am Markt befindlichen
> Programme? Ein Drittel aller Teilnehmer im dt. Usenet postet mit
> Outlock - die Zahlen sind bezeichnend.
Es kann doch nicht sein, dass die restlichen zwei Drittel Nachteile
(also kürzere Haltezeiten) in Kauf nehmen müssen, weil ein Drittel
einen IMHO völlig kaputten Newsreader benutzt, der sich nur deshalb
durchgesetzt hat, weil er standardmäßig bei Windows dabei ist.
CU Lars Noschinski
Frank Kloeker
> Es kann doch nicht sein, dass die restlichen zwei Drittel Nachteile
> (also kürzere Haltezeiten) in Kauf nehmen müssen, weil ein Drittel
> einen IMHO völlig kaputten Newsreader benutzt, der sich nur deshalb
> durchgesetzt hat, weil er standardmäßig bei Windows dabei ist.
keineswegs.
Frank Kloeker
> Ist das denn wirklich so schwer zu verstehen?
>
> Im Monat August wurden in de.* Artikel gepostet. 133729 davon
> sind trotz/mit OE gepostet worden. Es könnte sein, daß hier 133729 Leute
> jeweils einen Artikel gepostet haben oder auch, daß ein Mensch 133729
> Artikel gepostet hat - oder jedes andere Verhältnis zwischen Anzahl der
> Postings und Anzahl der Autoren dazwischen.
>
> Über die Anzahl der Autoren macht die Statistik keine Aussage. Jetzt
> verstanden?
Ich kann Dir eine Posterstatistik vom letzten Monat zusenden. In der
wirst Du sehen, dass sich die ueber 400.000 Artikel sehr wohl auf eine
breite Masse von Leuten verteilen. Mehr als 1000 Postings pro Monat
schaffen gerade mal ein Dutzend.
Hendrik Weimer
> Thomas Hochstein schrieb in Nachricht ...
> >Joerg Mensmann <joerg.m...@gmx.de> scripsit/wrote:
> >
> >> Das ist übrigens eine DOS COM-Datei mit dem Inhalt:
> >
> >Und?
>
> Binary in Textgruppen sind doch No-No's, oder?
In einer Signatur?
Tschuess,
Hendrik
Philipp Kern
> Es gibt daneben auch lokale Gruppen, die nur auf einem Server auf-
^^^^^
T-O hat doch ein ganzes Serverheer, oder?
> liegen. So betreibt zum Beispiel T-Online interne Gruppen, die nur
> für eigene Kunden zugänglich sind.
>
cu
--
Philipp Kern * PGP: 0x7935588D * ICQ: 66737654 * http://www.philkern.de
>> Ich dachte Wau ist in Jena? :-) > jaja aber wuff lässt auf wau wau schließen
Oh, das bellastet mich jetzt aber, dass ich das nicht erkannt habe.
(Matthias Esken in hamster.de.talk)
Andreas Loch
>> Es gibt daneben auch lokale Gruppen, die nur auf einem Server auf-
> ^^^^^
> T-O hat doch ein ganzes Serverheer, oder?
Ja, aber sie treten nach außen hin wie ein Server auf.
Andreas
--
http://gigaschatten.de/
Ja, ist bald Fasching. Ich gehe dann als Mailclient. ;)
[Andreas Kohlbach in de.admin.net-abuse.mail]
Christoph Garbers
> T-O hat doch ein ganzes Serverheer, oder?
Jupp, haben sie. Sie "sehen" aber wie einer aus.
Christoph
--
Organisation is as well necessary as inspiration.
- T. S. Eliot
Hergen Lehmann
<dcpu0...@garbers.org> wrote:
>> T-O hat doch ein ganzes Serverheer, oder?
>
>Jupp, haben sie. Sie "sehen" aber wie einer aus.
Nein, nicht wirklich. Es handelt sich um separate Server mit eigenen
IP-Adressen und DNS-Namen, die sich durchaus gezielt ansprechen lassen
(newsXX.btx.dtag.de mit XX=fortlaufende Nummer).
Es ist lediglich so, daß das DNS beim Zugriff auf den "Sammelnamen"
news.t-online.de einen ganzen Schwung Adressen ausspuckt, aus denen
dann zufällig eine ausgewählt wird, so daß die User halbwegs
gleichmäßig auf die physikalischen Server verteilt werden.
Hergen
Gerd (i-broker Leipzig)
On Wed, 13 Sep 2000 09:56:05 +0200, ma...@klebsch.de (Mario Klebsch)
wrote:
>Hergen Lehmann <her...@gmx.de> writes:
>
>>Für einen "richtigen" Newsserver mit halbwegs vollständigem Guppen-
>>angebot und Tausenden von Usern sollte es dann schon ein Mehrpro-
>>zessorsystem und/oder eine Serverfarm mit RAM im GByte-Bereich und
>>RAID-Plattenarray sein.
[...]
Ich denke mal, bei einem Server, auf den höchstens 3 Leute
gleichzeitig zugreifen, reicht bereits ein Aldi-PC dicke zu. In
manchen WGs ist "Mail-/Newsserver/Gateway" mit Linux eine Form der
Schrottverwertung, da ab 386 alles prinzipiell dafür verwendet werden
kann.
>>Für einen "richtigen" Feed muß man dann halt mit einem oder mehreren
>>anderen Serverbetreibern persönlich reden (email/telefon) und etwas
>>aushandeln. Eine echte Standleitung mit fester IP-Adresse ist Plicht.
>
>Es geht auch prima mit UUCP.
Davon hört man immer wieder. Mich interessiert vor allem die
Möglichkeit der Komprimierung. Aber wie richtet man einen UUCP-Feed
ein?
...fragt sich
Gerd