1. RfD: Entfernung von at.tuwien.lva.*
Reinhard Pamer
Newsgroups: at.usenet.announce,at.usenet.gruppen,at.tuwien.general
Subject: 1. RfD: Entfernung von at.tuwien.lva.*
Followup-To: at.usenet.gruppen
REQUEST FOR DISCUSSION (RFD)
EINLADUNG ZUR DISKUSSION
Dies ist eine formelle Einladung zur Diskussion der Entfernung der
unmoderierten, österreichischen Usenet-Gruppen at.tuwien.lva.*
Dies ist kein Aufruf zur Stimmabgabe (CfV). Eine Abstimmung ist zu
diesem Zeitpunkt nicht möglich. Für weitere Angaben zum Ablauf siehe
unten.
Vorschlag:
----------
Entfernung der Subhierarchie at.tuwien.lva.*
Die Diskussionen wären nach erfolgter Entfernung in at.tuwien.general
on-topic.
Begründung:
-----------
.) Fast alle Gruppen in at.tuwien.lva.* sind dauerhaft nahezu völlig
leer.
Die einzigen Gruppen, die in den letzten 18 Monaten in mehr als einem
Monat mehr als 50 Postings aufwiesen, waren:
- at.tuwien.lva.dataengineering (2 Monate)
- at.tuwien.lva.datenbanken (5 Monate)
- at.tuwien.lva.uebersetzerbau-lu (5 Monate)
.) Unverständliche und teilweise den Einrichtungsregeln für at.*
widersprechende Benennung der Gruppen.
.) Die Benutzerfreundlichkeit bzw Übersichtlichkeit der Hierarchie
leidet, wenn Nutzer, da ihnen die Namen nichts sagen, auf gut Glück
Newsgruppen abonnieren, nur um sie dann leer vorzufinden.
.) Leere Gruppen mit unverständlichen Namen und mangelhafter
Strukturierung führen dazu, dass eine Hierarchie ungeordnet
erscheint. Dies wiederum senkt die Wahrscheinlichkeit guter
Verbreitung.
Traffic laut dem monatlichen Infoposting von Christian Pree:
=======================================================================
Gruppe Tagline
Mai Jun Jul Aug Sep Okt Nov Dez Jan Feb Mar Apr Mai Jun Jul Aug Sep Okt
=======================================================================
at.tuwien.lva.182.et LV Elektrotechnische Grundlagen der Informatik.
1 5 3 1 2 2 1 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.182.ra Rechnerarchitekturen VO+LU.
19 4 5 6 5 2 1 2 38 13 29 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.184.ak3 Ausgewaehlte Kapitel der Informatik (E184).
1 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.cg.ad1 AlgoDat1 UE.
2 1 7 4 2 1 1 2 2 1 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.cg.ad2 AlgoDat2 UE.
4 2 8 4 2 2 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.cg.adl AlgoDat LUE.
1 1 10 2 2 1 3 2 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.cg.cg23 Computer Graphik 23 LUE.
9 3 10 3 2 2 26 32 22 1 2 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.dataengineering
LVA Dataengineering fuer Wirtschaftsinformatiker VO (E1842).
9 7 1 1 3 8 90 44 167 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.datenbanken Datenbanksysteme VO+UE.
7 2 9 2 316 394 258 53 4 4 3 6 3 123
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.eprog Einfuehrung in das Programmieren VO+LU.
13 5 7 1 1 3 26
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.gbl-labor Gebaeudelehre u. Entwerfen Labor LVAs (E252).
1 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.hthm LVA HyperText & HyperMedia.
2 3 10 3 2 1 2 1 2 3 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.internet-services LVA Internet Services.
7 1 9 4 1 3 1 1 2 3 2 1 1 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.nummath LVA Numerische Mathematik fuer Informatiker.
1 3 11 4 1 1 1 2 2 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.programmieren2 LVA Programmieren 2 LU (E188).
3 2 2 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.prozessautomatisierung-lu
Prozessautomatisierung LU (E183-1).
36 50 3 8 4 1 2 21 19 18 12 1 5 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.se-delphi LVA Software Engineering Delphi.
2 3 1 1 1 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.se-java LVA Software Engineering Java.
1 3 5 6 8 7 6 2 1 10 3 5 87
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.se-linux LVA Software Engineering Linux.
4 6 7 7 2 33 67 27 14 4 20 5 5 3 3 26
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.semfv
Seminar Raeumliche Fremdenverkehrsanalyse und -planung.
1 3 8 2 2 1 4 1 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.srf-projekt3
Projekt3 am Inst. f. Stadt- und Regionalforschung.
1 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.uebersetzerbau-lu Uebersetzerbau LU.
120 8 1 7 3 1 1 1 1 90 113 201 70 8 7 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.uid
uSER iNTERFACE dESIGN - Informationen und Diskussionen zur VO & UE.
2 2 7 2 1 2 1 3 2 1 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at.tuwien.lva.xml
LVA XML, XSL and Web Applications VU 2.0 (E1841).
1 2 2 60
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Zum Verfahren:
--------------
.) Dieses Verfahren betrifft nur den _offiziellen_ Gruppenbestand der
Hierarchie at.*. Es hätte nicht zwingend zur Folge, dass die Gruppen
auch vom Newsserver der TU Wien entfernt werden. Dies ist Sache der
Betreiber.
.) Der Wahlschein wird es ermöglichen, für jede Gruppe einzeln eine
Entscheidung zu treffen.
.) Falls es zwingende Gründe gibt, dass eine der Gruppen noch einige
Monate länger im offiziellen Gruppenbestand von at.* verbleibt,
bitten die Proponenten um Nachricht. Es wäre auch möglich, über
eine Entfernung ab einem Zeitpunkt X abzustimmen.
.) Es ist nicht möglich, diesen RfD direkt in alle betroffenen Gruppen
zu posten. Wir werden allerdings dafür sorgen, dass in allen
Gruppen Pointer erscheinen.
Ablauf:
-------
Dies ist eine Einladung zur Diskussion, kein Aufruf zur Stimmabgabe.
Alle potentiellen Probleme mit der vorgeschlagenenen Entfernung
sollten in dieser Phase angeschnitten und gelöst werden. Die
Diskussion sollte ausschließlich in at.usenet.gruppen stattfinden.
Am Ende der Diskussionsphase wird ein Aufruf zur Stimmabgabe (CfV) von
einem unabhängigen Wahlleiter in at.usenet.announce gepostet.
Dieser RfD versucht sich an die "Richtlinien für die Einrichtung und
Entfernung von Newsgruppen in at.*" zu halten. Bei Fragen zum Ablauf
ist zuerst dieses Dokument zu konsultieren. Es wird regelmäßig in
at.usenet.gruppen gepostet und kann auch unter dem URL
<http://www.usenet.at/at-newsgroup-creation.txt> eingesehen werden.
Proponenten:
------------
Reinhard Pamer <rag...@pamer.net>
Franz -STAR- Starhan <franz+...@starhan.org>
Gerhard H Wrodnigg <g...@gmx.net>
Anton Ertl
>
>Vorschlag:
>----------
>
>Entfernung der Subhierarchie at.tuwien.lva.*
>
>Die Diskussionen wären nach erfolgter Entfernung in at.tuwien.general
>on-topic.
Ist zwar nach den ueblichen Regeln folgerichtig, sachlich aber
vollkommener Schwachsinn. at.tuwien.lva.* sind (zumindest soweit ich
damit zu tun habe) Gruppen mit ueberhaupt keiner Ueberschneidung zu
anderen at.tuwien.lva.*-Gruppen und zu at.tuwien.general. Die dann
Kraut-und-Rueben-Maessig zusammenzuwerfen, ist sinnlos und gegen den
Geist der Einteilung in Newsgroups. Falls jemand mit Tagging
argumentiert, stellt derjenige sich hoffentlich selbst zur Verfuegung,
jedes Jahr mehrere hundert Studenten darauf einzuschulen.
Die einzig richtige Loesung im Fall der Entfernung aus dem
at.*-Checkgroups ist, die Gruppen, die benutzt werden, ausserhalb des
at.*-Checkgroups weiterzufuehren.
Uebrigens gibt's auch at.tuwien.lva.*-Gruppen, die in diesem RfD (und
daher wahrscheinlich auch im checkgroups) nicht erwaehnt werden,
z.B. atl.oop und atl.funktional. Wie schaut's denn da mit der
Verbreitung aus? Wenn die auf Wiener Newsservern gut ist, waere das
ein Hinweis, dass at.tuwien.lva.*-Gruppen nicht im at.*-checkgroups
vorkommen muessen, um auf den fuer die Zielgruppe wichtigsten Servern
vorhanden zu sein. Von den Studierenden habe ich uebrigens noch keine
Klage ueber die Verbreitung dieser Newsgroups gehoert.
>.) Falls es zwingende Gründe gibt, dass eine der Gruppen noch einige
> Monate länger im offiziellen Gruppenbestand von at.* verbleibt,
> bitten die Proponenten um Nachricht. Es wäre auch möglich, über
> eine Entfernung ab einem Zeitpunkt X abzustimmen.
Ganz allgemein wuerde ich den Termin der Entfernungen in die
Sommerferien legen. Dann sollten am wenigsten Probleme auftreten.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Christian Pree
>Vorschlag:
>----------
>
>Entfernung der Subhierarchie at.tuwien.lva.*
[X] Dafür.
>.) Falls es zwingende Gründe gibt, dass eine der Gruppen noch einige
> Monate länger im offiziellen Gruppenbestand von at.* verbleibt,
> bitten die Proponenten um Nachricht. Es wäre auch möglich, über
> eine Entfernung ab einem Zeitpunkt X abzustimmen.
Das wäre mir neu.
Christian
Gerhard H Wrodnigg
>>Es wäre auch möglich, über
>> eine Entfernung ab einem Zeitpunkt X abzustimmen.
>
>Das wäre mir neu.
Es wäre auch mäglich, über eine Entfernung zu einem Zeitpunkt X
abzustimmen (um das Verfahren und die eigentliche Entfernung
entsprechend zu timen).
Read: CfV eben zum Zeitpunkt X, Umsetzung dann ein Monat nach X.
Wär das o.k.?
~ghw
--
There are only 10 kinds of people who understand binary digits:
Those who do, and
Those who don't.
Gerhard H Wrodnigg
>Die einzig richtige Loesung im Fall der Entfernung aus dem
>at.*-Checkgroups ist, die Gruppen, die benutzt werden, ausserhalb des
>at.*-Checkgroups weiterzufuehren.
Die hierfür beste Lösung wird an den meisten Unis schon praktiziert:
lokale Hierarchien am lokalen Server, die dann der entsprechenden Uni
direkt unterstehen. Mit wichtigen Partnern können diese problemlos
gepeert werden.
>Uebrigens gibt's auch at.tuwien.lva.*-Gruppen, die in diesem RfD (und
>daher wahrscheinlich auch im checkgroups) nicht erwaehnt werden,
>z.B. atl.oop und atl.funktional.
Das war anzunehmen.
>Wie schaut's denn da mit der Verbreitung aus?
Auf einem gut gewarteten Server gibts diese Gruppen klarerweise nicht.
>Wenn die auf Wiener Newsservern gut ist,
Was meinst du damit?
>waere das
>ein Hinweis, dass at.tuwien.lva.*-Gruppen nicht im at.*-checkgroups
>vorkommen muessen, um auf den fuer die Zielgruppe wichtigsten Servern
>vorhanden zu sein. Von den Studierenden habe ich uebrigens noch keine
>Klage ueber die Verbreitung dieser Newsgroups gehoert.
...wenn diese den TU-Server verwenden, haben sie die Gruppen, sonst
nicht (s.o.).
Reinhard Pamer
>Reinhard Pamer <rag...@pamer.net> writes:
>>Die Diskussionen wären nach erfolgter Entfernung in at.tuwien.general
>>on-topic.
>Ist zwar nach den ueblichen Regeln folgerichtig, sachlich aber
>vollkommener Schwachsinn.
Die Richtlinien erfordern bei einer Löschung die Angabe einer
Ausweichgruppe. Ob, wie und wohin tatsächlich sinnvollerweise
ausgewichen wird, können die Verantwortlichen sicher besser beurteilen
als wir.
>[...]
>ein Hinweis, dass at.tuwien.lva.*-Gruppen nicht im at.*-checkgroups
>vorkommen muessen, um auf den fuer die Zielgruppe wichtigsten Servern
>vorhanden zu sein.
Dazu könnte man wohl am ehesten den jeweils aktuellen Checkgroups mit
http://www.dbai.tuwien.ac.at/proj/usenet/results/ vergleichen.
Anton Ertl
>Anton Ertl schrieb:
>
>>Reinhard Pamer <rag...@pamer.net> writes:
>
>>>Die Diskussionen wären nach erfolgter Entfernung in at.tuwien.general
>>>on-topic.
>
>>Ist zwar nach den ueblichen Regeln folgerichtig, sachlich aber
>>vollkommener Schwachsinn.
>
>Die Richtlinien erfordern bei einer Löschung die Angabe einer
>Ausweichgruppe. Ob, wie und wohin tatsächlich sinnvollerweise
>ausgewichen wird, können die Verantwortlichen sicher besser beurteilen
>als wir.
Man sollte halt auch die sachlich sinnvollen Varianten im RfD/CfV
erwaehnen, wenn man aus formalen Gruenden eine schlechte Variante
erwaehnt.
Die sachlich sinnvolle Variante ist IMO (als "Verantwortlicher" fuer
eine der betroffenen Gruppen) die Weiterfuehrung der benutzten Gruppen
ausserhalb des Checkgroups.
>>[...]
>>ein Hinweis, dass at.tuwien.lva.*-Gruppen nicht im at.*-checkgroups
>>vorkommen muessen, um auf den fuer die Zielgruppe wichtigsten Servern
>>vorhanden zu sein.
>
>Dazu könnte man wohl am ehesten den jeweils aktuellen Checkgroups mit
>http://www.dbai.tuwien.ac.at/proj/usenet/results/ vergleichen.
Der juengste Test ist allerdings vor der Entstehung der beiden von mir
erwaehnten Gruppen, der Link hilft daher diesbezueglich im Moment
nicht weiter.
Aber man findet dort folgendes fuer diesen RfD relevante:
|Server news.tuwien.ac.at
...
|at.tuwien.lva.cg.ad1 fehlt
|at.tuwien.lva.cg.ad2 fehlt
|at.tuwien.lva.cg.adl fehlt
(und sie fehlen noch immer).
Zumindest mit diesen Gruppen sollte es daher keine Probleme bei der
Entfernung geben.
Matthias Wallner
> Vorschlag:
> ----------
>
> Entfernung der Subhierarchie at.tuwien.lva.*
Dagegen!
entweder die komplette at.tuwien.* hierachie wird aus at.* entfernt und
woanders untergebracht, oder es bleibt so.
Gerade einige unter der .lva. hierachie befindlichen Gruppen haben mir als
TuWien student sehr geholfen und würden in at.tuwien.general einfach
durcheinandergemischt.
Verschiebt die ganze hierachie nach tuwien.* oder sowas in der art. (ich
weiß daß das scohn einmal schiefgegangen ist, aber man könnte ja mal
tuwien.* einrichten und at.tuwien.* nachher löschen)
--
mfg, Matthias Wallner
Bitte Antworten nur in die Newsgroup.
Gerhard H Wrodnigg
>Man sollte halt auch die sachlich sinnvollen Varianten im RfD/CfV
>erwaehnen,
Was wären für dich solche sachlich sinnvollen Varianten?
>Die sachlich sinnvolle Variante ist IMO (als "Verantwortlicher" fuer
>eine der betroffenen Gruppen) die Weiterfuehrung der benutzten Gruppen
>ausserhalb des Checkgroups.
Das kann selbstverständlich so gemacht werden.
Eine andere Möglichkeit wäre auch die einrichtung einer eigenen
tu-wien.* Hierarchie (wie es an den meisten Unis gemacht wird)
>Der juengste Test ist allerdings vor der Entstehung der beiden von mir
>erwaehnten Gruppen, der Link hilft daher diesbezueglich im Moment
>nicht weiter.
Nunja, dann ist dies nicht weiter verwunderlich.
>Aber man findet dort folgendes fuer diesen RfD relevante:
>
>|Server news.tuwien.ac.at
>...
>|at.tuwien.lva.cg.ad1 fehlt
>|at.tuwien.lva.cg.ad2 fehlt
>|at.tuwien.lva.cg.adl fehlt
>
>(und sie fehlen noch immer).
Gerade die Diskrepanz zwischen der "offiziellen" und "inoffiziellen"
Liste ist eines der Probleme, die immer wieder auftauchen...
Gerhard H Wrodnigg
>entweder die komplette at.tuwien.* hierachie wird aus at.* entfernt und
>woanders untergebracht, oder es bleibt so.
Eine schon öfters erwähnte Variante wäre die Einrichtung einer eigenen
tu-wien.* Hierarchie.
>Gerade einige unter der .lva. hierachie befindlichen Gruppen haben mir als
>TuWien student sehr geholfen
Weils mich jetzt interessiert: welche waren es denn?
>und würden in at.tuwien.general einfach durcheinandergemischt.
Das wäre eine Alternative, eine andere hast du selbst genannt.
>Verschiebt die ganze hierachie nach tuwien.* oder sowas in der art. (ich
>weiß daß das scohn einmal schiefgegangen ist, aber man könnte ja mal
>tuwien.* einrichten und at.tuwien.* nachher löschen)
Ja, das wurde schon mehrfach vorgeschlagen.
Peter Palfrader
> Aus den Richtlinien:
> ------
> Die folgenden News-Hierarchien verfuegen ueber ein anderes, eigenes
> Verfahren zur Einrichtung und Entfernung von Newsgruppen innerhalb
> ihrer Subhierarchie:
>
> at.tuwien.* Newsgruppen der TU Wien
> at.univie.* Newsgruppen der Uni Wien
> ------
>
> Hast du von der TU Wien eine Zusage das sie für die Entfernung der
> Gruppen jetzt doch dasselbe Verfahren haben wollen wie bei den anderen
> at.* Gruppen?
>
> Wenn nicht wäre eine Abstimmung ziemlich sinnlos.
Punkt 11 der Richtlinien wurde im Mai entfernt. Siehe
<Result-Entfernung_von_Punkt_11_der...@malz.fst.sbg.ac.at>
--
Peter
Arno Fikar
> >Verschiebt die ganze hierachie nach tuwien.* oder sowas in der art. (ich
> >weiß daß das scohn einmal schiefgegangen ist, aber man könnte ja mal
> >tuwien.* einrichten und at.tuwien.* nachher löschen)
>
> Ja, das wurde schon mehrfach vorgeschlagen.
Und warum passiert das dann nicht?
LG
Arno
Daniel Wagner
> Quoting Matthias Wallner <judji6...@sneakemail.com>:
>
>>entweder die komplette at.tuwien.* hierachie wird aus at.* entfernt und
>>woanders untergebracht, oder es bleibt so.
>
> Eine schon öfters erwähnte Variante wäre die Einrichtung einer eigenen
> tu-wien.* Hierarchie.
Dagegen spricht IMHO nichts. Insbesondere da mehr oder weniger leicht
möglich ist, auf den Newsserver der TU Wien zuzugreifen (ssh-Tunnel,
VPN, ...). Ich benutze selber schon seit längerem diese Variante, da
jetzt schon einige der a.t.l Gruppen nicht auf dem von mir normalerweise
genutzen Newsserver zu finden sind. Andererseits wäre es natürlich
zweifellos bequemer nicht mehrer Newsserver benutzen zu müssen.
>>Gerade einige unter der .lva. hierachie befindlichen Gruppen haben mir als
>>TuWien student sehr geholfen
>
> Weils mich jetzt interessiert: welche waren es denn
Für mich waren es:
a.t.l.funktional
a.t.l.security
a.t.l.xml
Ich weis in wieweit in der Diskussion um a.t.l schon auf sides4mi
hingewiesen wurde. Dort gibt es für jede LVA eine Mailingliste. Diese
werden aber nicht wirklich angenommen, obwohl hier durchaus potential
vorhanden wäre (z.B. gäbe es bei Maillinglisten die Problem mit Menschen
die ausserhalb des TU-Domains am Internet hängen nicht).
- Daniel
--
Es muß seyn
(http://kwaxi.org/)
Helmut Reininger
> Die dann
> Kraut-und-Rueben-Maessig zusammenzuwerfen, ist sinnlos und gegen den
> Geist der Einteilung in Newsgroups.
Folglich widerspricht es auch dem Geist von Newsgroups, eine lokale
Hierarchie in einer Internationale (at.*) einzuordnen.
> Die einzig richtige Loesung im Fall der Entfernung aus dem
> at.*-Checkgroups ist, die Gruppen, die benutzt werden, ausserhalb des
> at.*-Checkgroups weiterzufuehren.
Nein. Ich maße mir nicht an, die einzig richtige Lösung präsentieren zu
können, doch was spricht gegen eine tuwien.* auf einem lokalen
Newsserver? Warum die Krücke, wenn man's ordentlich machen kann?
> Wie schaut's denn da mit der
> Verbreitung aus? Wenn die auf Wiener Newsservern gut ist, waere das
> ein Hinweis, dass at.tuwien.lva.*-Gruppen nicht im at.*-checkgroups
> vorkommen muessen, um auf den fuer die Zielgruppe wichtigsten Servern
> vorhanden zu sein.
Wenn sich die Zielgruppe auf den Umkreis der Stadt Wien beschränkt,
warum führt die TU Wien dann Gruppen in einer Hierarchie die weltweit
verbreitet wird? Sitzen so viele Eurer Studenten in Rio oder Tokio?
> Ganz allgemein wuerde ich den Termin der Entfernungen in die
> Sommerferien legen. Dann sollten am wenigsten Probleme auftreten.
Ack.
--
Helmut "Dalmet" Reininger
Helmut Reininger
> Entfernung der Subhierarchie at.tuwien.lva.*
Warum nur diese eine Subhierarchie? Wenn die TU Wien lokale Gruppen
führen möchte, kann sie dies doch auf einem - ebenso lokalem -
Newsserver in einer anderen TLH tun.
Ich sehe diesen RfD als Schritt in die richtige Richtung an, aber leider
eine österreichische Lösung, bei der eigentlich die "Wurzel des Übels"
nicht beseitigt wird. Solange es at.tuwien.* gibt, tut mir
at.tuwien.lva.* auch nicht mehr weh.
--
Helmut "Dalmet" Reininger
Gerhard H Wrodnigg
>>>aber man könnte ja mal tuwien.* einrichten
>> Ja, das wurde schon mehrfach vorgeschlagen.
>Und warum passiert das dann nicht?
Keine Ahnung. Das obliegt den zuständigen am ZID der TUW.
Gerhard H Wrodnigg
>"natuerlich kann die hierarchie als tuwien.* weiterbestehen wenn das die
>tuwien will ..." (etwa als ergaenzung zum ersten absatz unter "Zum
>Verfahren").
Du weißt selbst, wie oft und wie lange darüber schon diskutiert worden
ist...
>ceterum censeo dass eine loeschung der gesamten at.tuwien.*-hierarchie
>logischer waer.
Mir geht es primär mal um jene Gruppen, die am wenigsten Traffic
haben, und die den größten lokalen Charakter haben.
Reinhard Pamer
>Reinhard Pamer <rag...@pamer.net> wrote:
>> Entfernung der Subhierarchie at.tuwien.lva.*
>Warum nur diese eine Subhierarchie?
Damit ein at.tuwien.*-RfD anders ausgeht als der letzte zu dem Thema,
müsste man IMO mehr auf Gruppen eingehen, die noch Traffic haben (egal
ob der nun in at.* gut aufgehoben ist oder nicht).
Und dazu fehlt mir persönlich für at.tuwien.* die Zeit.
Gerhard H Wrodnigg
>> Eine schon öfters erwähnte Variante wäre die Einrichtung einer eigenen
>> tu-wien.* Hierarchie.
>
>Dagegen spricht IMHO nichts.
Theoretisch spricht seit Jahren nichts dagegen...
>a.t.l.funktional
>a.t.l.security
Diese beiden gibts z.B. nur auf dem TUW-Server. Das sind keine
"wirklichen" at.* Gruppen.
>a.t.l.xml
Diese schon.
>Ich weis in wieweit in der Diskussion um a.t.l schon auf sides4mi
>hingewiesen wurde.
Ja, wurde auch schon. Und auf andere Alternativen.
>Dort gibt es für jede LVA eine Mailingliste. Diese
>werden aber nicht wirklich angenommen, obwohl hier durchaus potential
>vorhanden wäre (z.B. gäbe es bei Maillinglisten die Problem mit Menschen
>die ausserhalb des TU-Domains am Internet hängen nicht).
Keine Frage.
Gerhard H Wrodnigg
>Hast du von der TU Wien eine Zusage das sie für die Entfernung der
>Gruppen jetzt doch dasselbe Verfahren haben wollen wie bei den anderen
>at.* Gruppen?
Ich hab das Ergebnis einer Abstimmung:
http://www.usenet.at/at.usenet.announce-Archiv/msg00380.html
>P.S. Ich frage nur nach weil ich in deinem Vorschlag keinen Hinweis
>darauf finde dass eine Zustimmung der TU Wien erfolgt ist.
Der ist IMHO nicht wirklich erforderlich.
Gerhard H Wrodnigg
>Warum nur diese eine Subhierarchie? Wenn die TU Wien lokale Gruppen
>führen möchte, kann sie dies doch auf einem - ebenso lokalem -
>Newsserver in einer anderen TLH tun.
Sicherlich.
>Ich sehe diesen RfD als Schritt in die richtige Richtung an, aber leider
>eine österreichische Lösung, bei der eigentlich die "Wurzel des Übels"
>nicht beseitigt wird.
Ich (und meine Kollegen gehen da IMHO konform) halte einen RfD zur
Entfernung von ganz at.tuw.* für nicht durchführbar.
Einige Gründe dafür hat RP schon dargelegt.
Für manche Gruppen müßten Ersatzgruppen geschaffen werden, das wäre
ein Monsterverfahren.
Heinrich Moser
Gerhard H Wrodnigg <g...@gmx.net> writes:
> Quoting an...@mips.complang.tuwien.ac.at (Anton Ertl):
>> Man sollte halt auch die sachlich sinnvollen Varianten im RfD/CfV
>> erwaehnen,
>
> Was wären für dich solche sachlich sinnvollen Varianten?
Die von Daniel Wagner bereits erwähnte sachlich sinnvolle Variante
Sides4-mi[1]. Das System ist natürlich nicht so komfortabel[2] wie
Newsgroups, aber es könnte ohne weiteren technischen Aufwand (den
z.B. die Einrichung von tu-wien.* mit sich bringen würde) jederzeit
den Traffic übernehmen.
SG,
Heinzi (im Augenblick für die Betreuung von a.t.l.datenbanken
zuständig)
[1] http://www.lzk.ac.at/sides4mi.html
[2] Dass Sides4-mi nicht optimal ist wurde bereits im letzten RfD
ausführlich diskutiert, daher halte ich eine erneute Diskussion
darüber nicht für sinnvoll. Wer interessiert ist, kann auf
groups.google.com nachlesen.
gregor herrmann
> >"natuerlich kann die hierarchie als tuwien.* weiterbestehen wenn das die
> >tuwien will ..." (etwa als ergaenzung zum ersten absatz unter "Zum
> >Verfahren").
> Du weißt selbst, wie oft und wie lange darüber schon diskutiert worden
> ist...
ja klar. mir ging es eher darum das gleich als anmerkung dazuzuschreiben
_bevor_ das wieder lang diskutiert wird.
gregor
--
http://www.comodo.priv.at/ | pgp key ID: 0x00F3CFE4
infos zur usenet-hierarchie at.*: http://www.usenet.at/
member of https://www.vibe.at/ | how to reply: http://learn.to/quote/
keysigningparty in innsbruck, 10.1.2003: http://keysigning.hotze.com/
Peter J. Holzer
> On Mon, 06 Jan 2003 14:09:31 +0100, Reinhard Pamer wrote:
>
>> Wenn du mit tuwien.* die lokale Hierarchie am Server der TU Wien meinst,
>> liegen Gruppeneinrichtungen nicht in unserer Macht, und müssten
>> TU-intern auf die Beine gestellt werden.
>
> macht natuerlich keinerlei sinn darueber abzustimmen aber vielleicht
> waere es fuer manche erfreulich in den CfV explizit reinzuschreiben
> "natuerlich kann die hierarchie als tuwien.* weiterbestehen wenn das die
> tuwien will ..." (etwa als ergaenzung zum ersten absatz unter "Zum
> Verfahren").
Das Einrichten einer völlig neuen Hierarchie als "weiterbestehen" zu
bezeichnen, halte ich für etwas gewagt :-)
In den gleichen Absatz würde ich es nicht hineinschreiben, weil das doch
zwei recht unterschiedliche Alternativen sind: Im ersten Fall führt die
TU die Gruppen lokal weiter, obwohl sie nicht im checkgroups stehen
(AFAIK macht das auch die univie so), im anderen Fall werden die Gruppen
gelöscht und statt dessen andere in einer anderen Hierarchie angelegt
(IMHO die elegantere Methode).
> ceterum censeo dass eine loeschung der gesamten at.tuwien.*-hierarchie
> logischer waer.
Logischer wäre es schon, allerdings ist das schon einmal gescheitert
(http://www.usenet.at/at.usenet.announce-Archiv/msg00372.html). Da
at.tuwien seit der Entfernung von Punkt 11 auch organisatorisch ein Teil
von at.* ist, sehe ich kein Problem darin, über einzelne Gruppen oder
Subhierarchien abzustimmen.
hp
--
_ | Peter J. Holzer | Schlagfertigkeit ist das, was einem
|_|_) | Sysadmin WSR | auf dem Nachhauseweg einfällt.
| | | h...@hjp.at | -- Lars 'Cebewee' Noschinski in dasr.
__/ | http://www.hjp.at/ |
Gerhard H Wrodnigg
>Hmm. Das heisst die Richtlinien die man auf www.usenet.at sind
>hoffnungslos veraltet?
Hmmm... ja :-(
Dautiiiii!
>Wo findet man denn eine aktuelle Version?
Monatlich in:
Newsgroups: at.usenet.gruppen,de.answers,news.answers
Zuletzt: <at0gno$v65gk$3...@ID-2339.news.dfncis.de>
Reinhard Pamer
>Wie gesagt, ich hatte die Richtlinien nur von www.usenet.at genommen.
>Wo findet man denn eine aktuelle Version?
Hier in at.usenet.gruppen. Zuletzt in ...
<news:at0gno$v65gk$3...@ID-2339.news.dfncis.de>
Klaus Maria Pfeiffer
>> Entfernung der Subhierarchie at.tuwien.lva.*
> Dagegen!
> entweder die komplette at.tuwien.* hierachie wird aus at.* entfernt
dafür gab es schon einen RfD/CfV. leider imho ohne erfolg.
> oder es bleibt so.
es gibt ein paar leichen im at usenet, die imho aufgrund der
österreichischen mentalität (des woa scho imma so) nicht ersetzt/gelöscht
werden. :-(
> aber man könnte ja mal
> tuwien.* einrichten und at.tuwien.* nachher löschen)
liegt bei unterschiedlichen zuständigkeiten. :-(
greetings, Klaus
--
Verzeih, aber du kannst doch nicht ernsthaft der Oberflächenkonsistenz
der Shift-Taste zu liebe auf die Groß-Schreibung verzichtet haben, oder?
-- Alexander Griesser in at.linux
Klaus Maria Pfeiffer
>>>>aber man könnte ja mal tuwien.* einrichten
>>> Ja, das wurde schon mehrfach vorgeschlagen.
>>Und warum passiert das dann nicht?
> Keine Ahnung. Das obliegt den zuständigen am ZID der TUW.
Haben die jemals Diskussionsbereitschaft gezeigt?
Greetings, Klaus
Gerhard H Wrodnigg
>Haben die jemals Diskussionsbereitschaft gezeigt?
Nachzulesen bei Google.
Christian Pree
>Quoting Christian Pree <ch...@gmx.net>:
>
>>>Es wäre auch möglich, über
>>> eine Entfernung ab einem Zeitpunkt X abzustimmen.
>>
>>Das wäre mir neu.
>
>Es wäre auch mäglich, über eine Entfernung zu einem Zeitpunkt X
>abzustimmen (um das Verfahren und die eigentliche Entfernung
>entsprechend zu timen).
>
>Read: CfV eben zum Zeitpunkt X, Umsetzung dann ein Monat nach X.
CfV und Umsetzung sollten zeitnah sein, schließlich ist der CfV das
Meinungsbild zu einem bestimmten Zeitpunkt und kann sich mehrere Monate
später schon wieder geändert haben.
>Wär das o.k.?
Das mußt Du Mike fragen. :-)
Christian
--
Wechselseitige Spekulationen darüber, ob, und falls ja, aus welchen
Körperöffnungen dem jeweils anderen beim Verfassen seiner Postings
Schaum oder ähnliches kommt, bringen die Diskussion nicht sonderlich
voran. Michael Ottenbruch in de.admin.news.regeln, 28.08.2000
Klaus Maria Pfeiffer
[ZID der TU Wien bezüglich einrichtung der NGs von at.tuwien.* als tuwien.*]
>> Haben die jemals Diskussionsbereitschaft gezeigt?
> Nachzulesen bei Google.
ja, nein, weiß nicht, bin schüchtern, leck mich am arsch
... hätte ich mir als antwort erwartet.
greetings, Klaus
Christian Pree
... und übermorgen gibts den nächsten Repost.
Alexander Zangerl
Gerhard H Wrodnigg <g...@gmx.net> wrote:
> Quoting Daniel Wagner <dan...@kwaxi.org>:
>
> >> Eine schon öfters erwähnte Variante wäre die Einrichtung einer eigenen
> >> tu-wien.* Hierarchie.
> >
> >Dagegen spricht IMHO nichts.
>
> Theoretisch spricht seit Jahren nichts dagegen...
du solltest deutlicher sagen "aus sicht der at.usenet-gemeinde spricht...".
was die TU-leute schon oder nicht finden ist (leider) nicht
in Unserem Einflußbereich[0] :-/
mfg
az
[0] TINC
--
+ Alexander Zangerl + a...@snafu.priv.at + DSA 42BD645D + (RSA 5B586291)
"How degrading -- to actually have to use a _voice-quality_ line for _speech_."
-- Mike Andrews, a.s.r
Franz -STAR- Starhan
> Warum nur diese eine Subhierarchie? Wenn die TU Wien lokale Gruppen
> führen möchte, kann sie dies doch auf einem - ebenso lokalem -
> Newsserver in einer anderen TLH tun.
Leider zeigt die TU Wien eben keinen Willen, etwas in diese Richtung
zu unternehmen. Das hat u.a. die Diskussion rund um den damaligen
RfD (http://www.usenet.at/at.usenet.announce-Archiv/msg00345.html
bzw. http://www.usenet.at/at.usenet.announce-Archiv/msg00369.html)
gezeigt. Die Abstimmung ist dann ja auch entsprechend ausgegangen
=> http://www.usenet.at/at.usenet.announce-Archiv/msg00372.html
Nachdem es nicht im Big-Bang-Verfahren geht, versuchen wir es eben
schrittweise. Der erste Schritt war die Entfernung von Punkt 11
(http://www.usenet.at/at.usenet.announce-Archiv/msg00380.html)
aus den Einrichtungsregeln und dieser RfD ist sozusagen Stufe 2.
Es gab bereits einige Vorschläge in Richtung tuwien.* (so zB.
Gerald Pfeifer in <u3zogk8...@deneb.dbai.tuwien.ac.at> oder
Gerhard Gonter in <3A6DD191...@zechine.wu-wien.ac.at>.
Passiert ist aber bisher noch nichts.
Als eine Art "offizielle" Stellungnahme des ZID kann das Posting
von Johannes Demel <959g5s$jpd$1...@news.tuwien.ac.at> angesehen werden.
Johann Klasek, meines Wissens Newshamster an der TU Wien, hat dann
in <95ef3m$51b$1...@news.tuwien.ac.at> noch einige weitere Links und
Informationen gepostet.
Franz
Franz -STAR- Starhan
[ZID der TU Wien bezüglich einrichtung der NGs von at.tuwien.* als tuwien.*]
>>> Haben die jemals Diskussionsbereitschaft gezeigt?
>> Nachzulesen bei Google.
> ja, nein, weiß nicht, bin schüchtern, leck mich am arsch
> ... hätte ich mir als antwort erwartet.
Na was davon hättest denn nun gerne? ;)
Bitte meine Link- und MID-Sammlung zu diesem Thema
in <3e1a1631$1...@news.kapsch.co.at> lesen.
In a nutshell: Nein, nicht wirklich.
Franz
Franz -STAR- Starhan
[at.tuwien.general nicht passend als Ersatzgruppe]
> Die einzig richtige Loesung im Fall der Entfernung aus dem
> at.*-Checkgroups ist, die Gruppen, die benutzt werden, ausserhalb
> des at.*-Checkgroups weiterzufuehren.
Nope, nicht wirklich. Sagen wir so, es ist eine mögliche Lösung, aber
optimal ist sie nicht. Gscheiter wäre IMO eine Re-Inkarnation in einer
lokal geführten tu-wien.* (oder tuwien.* oder whatever) Hierarchie.
> Uebrigens gibt's auch at.tuwien.lva.*-Gruppen, die in diesem RfD (und
> daher wahrscheinlich auch im checkgroups) nicht erwaehnt werden,
> z.B. atl.oop und atl.funktional. Wie schaut's denn da mit der
> Verbreitung aus?
Jeder NewsAdmin, der etwas auf sich und seinen Server hält, wird sich
an http://www.usenet.at/checkgroups/checkgroups-latest (den offiziellen
Checkgroups) halten. Und da sind diese Gruppen nicht drin.
Nicht mal Chello hat diese Gruppen, und die bieten immerhin den
Student Connect an, über den viele Studiosos sich zur TU connecten.
> Von den Studierenden habe ich uebrigens noch keine Klage ueber die
> Verbreitung dieser Newsgroups gehoert.
Ich gehe schon davon aus, daß die Studiosos direkt am TU-Wien-Server
ihre News lesen.
> Ganz allgemein wuerde ich den Termin der Entfernungen in die
> Sommerferien legen. Dann sollten am wenigsten Probleme auftreten.
Ack. Wir streben einen CfV-Termin im Mai an; die Umsetzung soll dann
im Juli erfolgen.
Franz
Gerald Pfeifer
> abzustimmen (um das Verfahren und die eigentliche Entfernung
> entsprechend zu timen).
>
> Read: CfV eben zum Zeitpunkt X, Umsetzung dann ein Monat nach X.
>
Alles was "das Volk" entscheidet, ist okay in diesem Kontext, wuerde
ich sagen. ;-)
Und aktive, gut funktionierende Gruppen zu loeschen -- zumal, wenn
eines der Ziele war, den Usern das Usenet naeherzubringen -- wuerde
ich schon mit etwas Ruecksicht durchfuehren, wenn irgend moeglich.
(at.tuwien.lva.datenbanken ist hier gemeint.)
Gerald
--
Gerald "Jerry" pfe...@dbai.tuwien.ac.at http://www.pfeifer.com/gerald/
Gerald Pfeifer
> Die Diskussionen wären nach erfolgter Entfernung in at.tuwien.general
> on-topic.
Kann man machen, ist aber in Wirklichkeit nur eine Pseudo-Loesung,
zumindest im Falle von at.tuwien.lva.datenbanken:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> at.tuwien.lva.datenbanken Datenbanksysteme VO+UE.
> 7 2 9 2 316 394 258 53 4 4 3 6 3 123
Das bedeutet nicht, dass wir das nicht anderweitig unterbringen
koennen oder wollen, nur at.tuwien.general ist wirklich keine
Alternative, angesichts des Traffics.
> .) Falls es zwingende Gründe gibt, dass eine der Gruppen noch einige
> Monate länger im offiziellen Gruppenbestand von at.* verbleibt,
> bitten die Proponenten um Nachricht. Es wäre auch möglich, über
> eine Entfernung ab einem Zeitpunkt X abzustimmen.
Das gefaellt mir. Ein guter Kompromiss, mit Fokus auf etwaige
betroffene Benutzer -- danke!
In Bezug auf at.tuwien.lva.datenbanken waeren wir froh, wenn diese
nicht in den kommenden zwei Monaten entfernt wuerden, ideal waere es
im Sommer, aber ab April waere es wohl auch okay, notfalls eben Maerz.
Gerhard H Wrodnigg
>du solltest deutlicher sagen "aus sicht der at.usenet-gemeinde spricht...".
>was die TU-leute schon oder nicht finden ist (leider) nicht
>in Unserem Einflußbereich[0] :-/
Ja, es liegt irgendwie auf der hand, daß die lokale Administration
ausschließklich von den ewntsprechenden Leuten durchgeführt/umgesetzt
werden kann.
Gerhard H Wrodnigg
>In Bezug auf at.tuwien.lva.datenbanken waeren wir froh, wenn diese
>nicht in den kommenden zwei Monaten entfernt wuerden,
Das ist doch klar, daß wir keine ho-ruck Aktion anstreben.
>ideal waere es
>im Sommer, aber ab April waere es wohl auch okay, notfalls eben Maerz.
Ich denke, das wichtigste wäre, alternative Möglichkeiten zu finden,
und in absehbarer Zeit umzusetzen.
Wie wäre es, wenn sich die Lehrbeauftragten zusammentäten und eine
lokale Hierarchie zu diesem Zwecke beantragten?
Alexander Zangerl
> ausschließklich von den ewntsprechenden Leuten durchgeführt/umgesetzt
> werden kann.
Dir und mir sicher; Anscheinend war aber nicht allen neu hinzugekommenen
diskutierern in diesem thread der administrative status von at.tuwien.*
bewußt.
mfg
az
--
+ Alexander Zangerl + a...@snafu.priv.at + DSA 42BD645D + (RSA 5B586291)
IBM: It may be slow, but it's hard to use. -- Simon Cozens
Philipp Kolmann
> [Ausweichgruppe für at.tuwien.lva.*]
> Gerhard H Wrodnigg <g...@gmx.net> writes:
> > Quoting an...@mips.complang.tuwien.ac.at (Anton Ertl):
> >> Man sollte halt auch die sachlich sinnvollen Varianten im RfD/CfV
> >> erwaehnen,
> >
> > Was wären für dich solche sachlich sinnvollen Varianten?
>
> Die von Daniel Wagner bereits erwähnte sachlich sinnvolle Variante
> Sides4-mi[1]. Das System ist natürlich nicht so komfortabel[2] wie
> Newsgroups, aber es könnte ohne weiteren technischen Aufwand (den
> z.B. die Einrichung von tu-wien.* mit sich bringen würde) jederzeit
> den Traffic übernehmen.
Naja, es gibt bereits eine tuwien.* Hierarchie:
Sender: "Johann E. Klasek" <jkl...@jk.kom.tuwien.ac.at>
Message-ID: <a77ssa$dpp$1...@news.tuwien.ac.at>
From: "Johann E. Klasek" <jkl...@zid.tuwien.ac.at>
Newsgroups: tuwien.general
Subject: Willkommen zur lokalen TU Wien News-Hierarchie
Date: 19 Mar 2002 17:35:06 GMT
Im google leider nicht gefunden. Aber eine Subhierarchie gibt es demnach
seit fast 10 Monaten...
lg
Philipp
--
Life is not fair,
but the root password helps!
Peter J. Holzer
> Naja, es gibt bereits eine tuwien.* Hierarchie:
>
> Sender: "Johann E. Klasek" <jkl...@jk.kom.tuwien.ac.at>
> Message-ID: <a77ssa$dpp$1...@news.tuwien.ac.at>
> From: "Johann E. Klasek" <jkl...@zid.tuwien.ac.at>
> Newsgroups: tuwien.general
> Subject: Willkommen zur lokalen TU Wien News-Hierarchie
> Date: 19 Mar 2002 17:35:06 GMT
>
>
> Im google leider nicht gefunden. Aber eine Subhierarchie gibt es demnach
> seit fast 10 Monaten...
Faszinierend. Das war also während der Diskussion über den Punkt 11 der
Richtlinien. Habe ich das übersehen, oder hat das damals wirklich niemand
erwähnt? Wäre für den CfV relevant gewesen (nicht dass es am Ergebnis
was geändert hätte, es wäre höchstens noch deutlicher ausgefallen).
David Schmitt
> Wenn sich die Zielgruppe auf den Umkreis der Stadt Wien beschränkt,
> warum führt die TU Wien dann Gruppen in einer Hierarchie die weltweit
> verbreitet wird? Sitzen so viele Eurer Studenten in Rio oder Tokio?
In meiner Funktion als Betreuer der allgmeinen Studentenarbeitsplätze
auf der TUWien sind mir schon einige Studenten untergekommen die moniert
haben, daß auf ihrem Newsserver gewisse Gruppen aus at.tuwien.* nicht zu
finden waren.
MfG David
--
* Customer: "My palmtop won't turn on."
* Tech Support: "Did the battery run out, maybe?"
* Customer: "No, it doesn't use batteries. It's Windows powered."
-- http://www.rinkworks.com/stupid/cs_power.shtml
Stefan Froehlich
> In meiner Funktion als Betreuer der allgmeinen Studentenarbeitsplätze
> auf der TUWien sind mir schon einige Studenten untergekommen die moniert
> haben, daß auf ihrem Newsserver gewisse Gruppen aus at.tuwien.* nicht zu
> finden waren.
Das laesst mittelfristig aber eher einen Zustand ganz ohne at.tuwien.* in
Checkgroups wuenschenswert erscheinen, als eine Loesung wie derzeit, wo
man sich (als dieser Verfahren Unkundiger) bei keiner Gruppe sicher sein
kann, ob sie jetzt extern gefuehrt wird, oder nicht und wenn ja, von wem.
Dann ist naemlich eine prinzipielle, neue Loesung gefragt, die ja
hoffentlich in sich konsistent sein wird.
Servus,
Stefan
--
Stefan - die vornehmste Auspraegung von echt!
http://www.sloganizer.de/
Gerhard H Wrodnigg
>Naja, es gibt bereits eine tuwien.* Hierarchie:
>[...]
>Aber eine Subhierarchie gibt es demnach
>seit fast 10 Monaten...
Danke, gut zu wissen.
Gerhard H Wrodnigg
>In meiner Funktion als Betreuer der allgmeinen Studentenarbeitsplätze
>auf der TUWien sind mir schon einige Studenten untergekommen die moniert
>haben, daß auf ihrem Newsserver gewisse Gruppen aus at.tuwien.* nicht zu
>finden waren.
D.h. sie verwenden primär nicht den TU-News Server.
Die Liste der at.tu-wien.* Gruppen wurde vor einiger Zeit mal
angegleichen.
Allerdings können neue Gruppen dieser Subhierarchie nur mehr über ein
allgemeines RfD/CfV-verfahren eingerichtet werden. Wenn in der
Zwischenzeit auf dem Server der TUW neue Gruppen (direkt) eingerichtet
worden sind, dann ist es klar, daß diese auf keinem anderen Server
existieren, weil hierfür eine "offizielle" Steuernachricht nötig wäre.
Dies wäre ein weiteres Argument, die tuwien.* Hierarchie auszubauen
(da hier die Schirmherrschaft beim ZID liegt) und ggf. mit
.at-Providern zu peeren...
Gerhard H Wrodnigg
>Dir und mir sicher; Anscheinend war aber nicht allen neu hinzugekommenen
>diskutierern in diesem thread der administrative status von at.tuwien.*
>bewußt.
Schon klar. Aber inzwischen wissen wir ja, daß tuwien.* ja schon seit
ca. 10 Monaten existiert...
Anton Ertl
>[Ausweichgruppe für at.tuwien.lva.*]
>Gerhard H Wrodnigg <g...@gmx.net> writes:
>> Quoting an...@mips.complang.tuwien.ac.at (Anton Ertl):
>>> Man sollte halt auch die sachlich sinnvollen Varianten im RfD/CfV
>>> erwaehnen,
>>
>> Was wären für dich solche sachlich sinnvollen Varianten?
>
>Die von Daniel Wagner bereits erwähnte sachlich sinnvolle Variante
>Sides4-mi[1].
Definitiv nicht, z.B. weil
> Das System ist natürlich nicht so komfortabel[2] wie
>Newsgroups,
...
>[2] Dass Sides4-mi nicht optimal ist wurde bereits im letzten RfD
>ausführlich diskutiert, daher halte ich eine erneute Diskussion
>darüber nicht für sinnvoll.
Same here.
Da es bessere Varianten gibt, zaehle ich diese nicht zu den sachlich
sinnvollen.
Um es ganz deutlich zu machen: Wenn ich vor die Wahl gestellt wuerde,
atl.uebersetzerbau-lu im at.*-Checkgroups zu behalten oder auf
Sides4mi umzusteigen, wuerde ich fuer ersteres stimmen. Aber zum
Glueck sind das nicht die einzigen Alternativen.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Anton Ertl
>On Sun, 5 Jan 2003, Anton Ertl wrote in aug:
>
>[at.tuwien.general nicht passend als Ersatzgruppe]
>> Die einzig richtige Loesung im Fall der Entfernung aus dem
>> at.*-Checkgroups ist, die Gruppen, die benutzt werden, ausserhalb
>> des at.*-Checkgroups weiterzufuehren.
>
>Nope, nicht wirklich. Sagen wir so, es ist eine mögliche Lösung, aber
>optimal ist sie nicht. Gscheiter wäre IMO eine Re-Inkarnation in einer
>lokal geführten tu-wien.* (oder tuwien.* oder whatever) Hierarchie.
Ja, das ist eine Moeglichkeit der Weiterfuehrung. Ich meinte nicht,
dass sie den gleichen Namen haben muessen (dass das technisch ueber
Loeschung und Neueinrichtung geht, abstrahiere ich einmal weg), nur
dass sie als eigenstaendige Gruppen existieren muessen.
Gerhard H Wrodnigg
>atl.uebersetzerbau-lu im at.*-Checkgroups zu behalten oder auf
>Sides4mi umzusteigen, wuerde ich fuer ersteres stimmen. Aber zum
>Glueck sind das nicht die einzigen Alternativen.
Wie wäre es mit tuwien.lva.uebersetzerbau-lu?
Matthias Wallner
>
>>Gerade einige unter der .lva. hierachie befindlichen Gruppen haben mir als
>>TuWien student sehr geholfen
>
> Weils mich jetzt interessiert: welche waren es denn?
Die Datenbank und Übersetzerbau Gruppen (die beiden hatten als ich die LVA
besucht habe genügend Posts/Tag gehabt um die Gruppe bestehen zu lassen)
Gegen eine selektive löschung der leeren *.lva.* Gruppen habe ich nichts,
aber die paar aktiven (was zugegebenerweise nicht allzu viele sind) sollte
man nicht mitlöschen.
PS: Eigentlich gibts ja für TU Studenten auch eine Mailinglist pro LVA bei
der man sich eintragen kann (und ggf. als Ersatz dienen könnte), aber die
sind meistens ziemlich leer.
--
mfg, Matthias Wallner
Bitte Antworten nur in die Newsgroup.
Helmut Reininger
> Leider zeigt die TU Wien eben keinen Willen, etwas in diese Richtung
> zu unternehmen.
Somit endet auch mein Wille, mich an dieser Diskussion zu beteiligen.
Wenn eine *T*U sowas nicht auf die Reihe kriegt, dann ... ;)
--
Helmut "Dalmet" Reininger
Franz -STAR- Starhan
> Naja, es gibt bereits eine tuwien.* Hierarchie:
>
> Sender: "Johann E. Klasek" <jkl...@jk.kom.tuwien.ac.at>
> Message-ID: <a77ssa$dpp$1...@news.tuwien.ac.at>
> From: "Johann E. Klasek" <jkl...@zid.tuwien.ac.at>
> Newsgroups: tuwien.general
> Subject: Willkommen zur lokalen TU Wien News-Hierarchie
> Date: 19 Mar 2002 17:35:06 GMT
Hmmm... Schade, daß Johann das mir gegenüber nicht erwähnt hat.
Ich war im Zuge der Vorbereitungen für diesen RfD mit ihm in Kontakt.
> Im google leider nicht gefunden. Aber eine Subhierarchie gibt es
> demnach seit fast 10 Monaten...
Ich werde mit Johann diesbezüglich Kontakt aufnehmen und ihn auf die
Diskussion hieramts aufmerksam machen.
LG, Franz
Anton Ertl
Das waere eine sinnvolle Alternative.
Ich habe mir schon ueberlegt, ob wir das nicht gleich im naechsten
Semester so machen sollten, aber wenn nicht starke Argumente dafuer
sprechen, goenne ich den Studenten lieber noch den Vorteil der
besseren Verbreitung (und den diversen Newsadmins ist es wohl auch
lieber, wenn die tuwien.lva-Gruppen in einem Schwung eingerichtet
werden, als einzeln).
Gerhard H Wrodnigg
>>Wie wäre es mit tuwien.lva.uebersetzerbau-lu?
>
>Das waere eine sinnvolle Alternative.
...ich würds gleich im Voraus mal beantragen, parallel fahren und mal
auf Feedback warten...
>aber wenn nicht starke Argumente dafuer sprechen,
Spam in den at.tu-gruppen, dieses Verfahren (wird die Gruppe im SS
aktiv genutzt werden?)...
>goenne ich den Studenten lieber noch den Vorteil der
>besseren Verbreitung
Wie lange "noch"...? ;)
Anton Ertl
>
>>>Wie wäre es mit tuwien.lva.uebersetzerbau-lu?
>>
>>Das waere eine sinnvolle Alternative.
>
>...ich würds gleich im Voraus mal beantragen, parallel fahren
Wie stellst Du Dir das "parallel fahren" vor?
>>aber wenn nicht starke Argumente dafuer sprechen,
>
>Spam in den at.tu-gruppen,
Ein Argument, aber kein starkes.
> dieses Verfahren
Ist bei positivem Ausgang ein Argument, dann umzuziehen, aber vorher?
> (wird die Gruppe im SS
>aktiv genutzt werden?)...
Ja.
Gerhard H Wrodnigg
>Wie stellst Du Dir das "parallel fahren" vor?
Na die gruppe einrichten, und alles, was du an Infos postest, in
beiden Gruppen zu posten...
>>Spam in den at.tu-gruppen,
>Ein Argument, aber kein starkes.
Wens nicht stört...
>> dieses Verfahren
>Ist bei positivem Ausgang ein Argument, dann umzuziehen, aber vorher?
D.h. du wartest lieber mal ab...?
>> (wird die Gruppe im SS
>>aktiv genutzt werden?)...
>Ja.
Danke für die Info.
Anton Ertl
>
>>Wie stellst Du Dir das "parallel fahren" vor?
>
>Na die gruppe einrichten, und alles, was du an Infos postest, in
>beiden Gruppen zu posten...
Das ist sinnlos, weil gelesen wird nur die, von der ueberall
(Homepage, Skriptum, Newsreader-Defaulteinstellung) steht, dass man
sie lesen soll. Insofern sollte ein Umzug unproblematisch sein, wenn
er nicht gerade mitten im Semester erfolgt.
Sollte aus irgendeinem Grund doch jemand (nur) die andere Gruppe lesen
(z.B. ein Wiederholer), waere das insofern problematisch, als es nicht
nur eine Announce-, sondern auch eine Diskussionsgruppe ist.
>>>Spam in den at.tu-gruppen,
>>Ein Argument, aber kein starkes.
Zwischen diesen Zeilen war eine Leerzeile. Bitte lass die drinnen,
siehe .sig und <2002Dec2...@a0.complang.tuwien.ac.at> ff. Im
letzten Posting konntest Du uebrigens noch zitieren, warum hast Du es
inzwischen verlernt?
>Wens nicht stört...
Natuerlich stoert's, aber es ist nicht soviel, dass es ein starkes
Argument waere; und vor Spam bleiben wir in der neuen Gruppe nur
verschont, solange die Verbreitung schlecht ist.
>D.h. du wartest lieber mal ab...?
Wenn keine ueberzeugenden Argumente dafuer kommen, etwas anderes zu
tun, ja.
- anton
--
Leerzeilen zwischen Absaetzen und Zitierebenen dienen der Lesbarkeit.
Sie sind auch beim Zitieren zu erhalten; wenn man das Zitierte nicht
fuer wichtig genug dafuer haelt, sollte man es vielleicht gleich ganz
weglassen. Ich score Leute herunter, die auf diese Weise quotemardern.
Gerhard H Wrodnigg
>Insofern sollte ein Umzug unproblematisch sein, wenn
>er nicht gerade mitten im Semester erfolgt.
Wie wärs mit den Semesterferien?
>Sollte aus irgendeinem Grund doch jemand (nur) die andere Gruppe lesen
>(z.B. ein Wiederholer), waere das insofern problematisch, als es nicht
>nur eine Announce-, sondern auch eine Diskussionsgruppe ist.
Schon klar, aber man kann dort dann ja auf die neue Gruppe
hinweisen...
>Zwischen diesen Zeilen war eine Leerzeile. Bitte lass die drinnen,
Ich find sie kontraproduktiv. Ich laß eine weitere Quoteebene drin,
wenn es Sinn macht, aber den Leerraum dazwischen lösch ich raus, da
der Text ansonst zu zerfleddert wird (lauter Leerzeien, auch zwischen
Zusammengehörendem).
>Im
>letzten Posting konntest Du uebrigens noch zitieren, warum hast Du es
>inzwischen verlernt?
...des gheart so!
>und vor Spam bleiben wir in der neuen Gruppe nur
>verschont, solange die Verbreitung schlecht ist.
Spam aus .kr in einer lökalen Hierarchie?
>Wenn keine ueberzeugenden Argumente dafuer kommen, etwas anderes zu
>tun, ja.
IMHO wäre während der Semesterferien eine gute Gelegenheit für einen
Umzug.
Gerhard H Wrodnigg
>Die Datenbank und Übersetzerbau Gruppen
Zwei von x.
>(die beiden hatten als ich die LVA
>besucht habe genügend Posts/Tag gehabt um die Gruppe bestehen zu lassen)
Nunja, aber da wäre dann noch das Argument, daß diese Gruppen besser
in einer lokalen Hierarchie aufgehoben wären...
>Gegen eine selektive löschung der leeren *.lva.* Gruppen habe ich nichts,
>aber die paar aktiven (was zugegebenerweise nicht allzu viele sind) sollte
>man nicht mitlöschen.
Es muß garnichts "gelöscht" werden. In der tuwien.* Hierarchie können
"Leute der TU" Gruppen anlegen und Löschen, wie es erforderlich ist.
In at.* ist hierzu ein RfD/CfV nötig. Dies führt dann dazu, daß es
neue Gruppen außerhalb der TUW ohnedies nicht mehr gibt.
>PS: Eigentlich gibts ja für TU Studenten auch eine Mailinglist pro LVA bei
>der man sich eintragen kann (und ggf. als Ersatz dienen könnte), aber die
>sind meistens ziemlich leer.
...das ist auch eine Alternative, auf die wir schon hingewiesen
haben...
Gerald Pfeifer
>>>> Spam in den at.tu-gruppen,
>>> Ein Argument, aber kein starkes.
>
> Zwischen diesen Zeilen war eine Leerzeile. Bitte lass die drinnen,
> siehe .sig und <2002Dec2...@a0.complang.tuwien.ac.at> ff. Im
> letzten Posting konntest Du uebrigens noch zitieren, warum hast Du es
> inzwischen verlernt?
Da hast du eine durchaus nicht unbestreitbaren Standpunkt; das Entfernen
derartiger Leerzeilen (vor allem bei "verschachteltem" Quoting) scheint
_mir_ zum Beispiel sogar sehr wuenschenswert.
> Leerzeilen zwischen Absaetzen und Zitierebenen dienen der Lesbarkeit.
Letzteres IMO primaer fuer User mit untauglichen Newsreadern; passable
koenne die Lesbarkeit auch anders gewaehrleisten (etwa mittels Farben
oder ggf. von sich aus derartige vertikale Abstaende einfuegen).
Gerhard H Wrodnigg
>das Entfernen
>derartiger Leerzeilen (vor allem bei "verschachteltem" Quoting) scheint
>_mir_ zum Beispiel sogar sehr wuenschenswert.
Mir auch, deswegen mach ich es auch.
>> Leerzeilen zwischen Absaetzen und Zitierebenen dienen der Lesbarkeit.
>Letzteres IMO primaer fuer User mit untauglichen Newsreadern;
Ich finde es ohne die "überflüssigen" Leerzeilen lesbarer.
>passable koenne die Lesbarkeit auch anders gewaehrleisten (etwa mittels Farben
Also mit (mehr als zwei) Farben könnte ich mich noch nie anfreunden.
Das wird außer bunt nur mehr bunt.
Reinhard Pamer
>.) Falls es zwingende Gründe gibt, dass eine der Gruppen noch einige
> Monate länger im offiziellen Gruppenbestand von at.* verbleibt,
> bitten die Proponenten um Nachricht.
Das wären dann bisher:
- at.tuwien.lva.datenbanken
- at.tuwien.lva.uebersetzerbau-lu
Für diese beiden Gruppen wird es voraussichtlich gegen Ende des
Sommersemesters ein gesondertes Verfahren geben - wahrscheinlich
zusammgefasst mit anderen Gruppen aus at.tuwien.!lva.
Für den Rest folgt demnächst der 2. - und AFAICS wohl letzte - RfD.
Anton Ertl
>
>>Insofern sollte ein Umzug unproblematisch sein, wenn
>>er nicht gerade mitten im Semester erfolgt.
>
>Wie wärs mit den Semesterferien?
Wenn ein starkes Argument dafuer spricht ...
>>Sollte aus irgendeinem Grund doch jemand (nur) die andere Gruppe lesen
>>(z.B. ein Wiederholer), waere das insofern problematisch, als es nicht
>>nur eine Announce-, sondern auch eine Diskussionsgruppe ist.
>
>Schon klar, aber man kann dort dann ja auf die neue Gruppe
>hinweisen...
Und woraus besteht dann das "parallel fahren"?
>>Zwischen diesen Zeilen war eine Leerzeile. Bitte lass die drinnen,
>
>Ich find sie kontraproduktiv. Ich laß eine weitere Quoteebene drin,
>wenn es Sinn macht, aber den Leerraum dazwischen lösch ich raus, da
>der Text ansonst zu zerfleddert wird (lauter Leerzeien, auch zwischen
>Zusammengehörendem).
Warum machst Du dann selbst Leerzeilen in Deine Postings? Wenn Dein
Text und das Zitat zusammengehoeren, solltest Du Deiner Argumentation
nach keine Leerzeilen machen, um den Text nicht zu zerfleddern. Und
wenn sie nicht zusammengehoeren, warum entfernst Du das Zitat nicht?
>>und vor Spam bleiben wir in der neuen Gruppe nur
>>verschont, solange die Verbreitung schlecht ist.
>
>Spam aus .kr in einer lökalen Hierarchie?
Du garantierst, dass das nicht passiert? Ich kann von hier aus in
mit.* posten. Warum sollte jemand aus .kr nicht in tuwien.* posten
koennen?
Anton Ertl
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Leerzeilen zwischen Absaetzen und Zitierebenen dienen der Lesbarkeit.
>
>Letzteres IMO primaer fuer User mit untauglichen Newsreadern; passable
>koenne die Lesbarkeit auch anders gewaehrleisten (etwa mittels Farben
>oder ggf. von sich aus derartige vertikale Abstaende einfuegen).
Warum zuerst weglassen und dann wieder einfuegen? Hat Dein Vorschlag
auch einen Sinn?
Und Du kannst Dich auch nicht auf "letzteres" beschraenken, da diese
Unterart der Quotemarder alle Leerzeilen im Zitat loescht, auch die
zwischen Absaetzen (Beispiel:
<3e09aaa9$0$443$a5ec...@news.ilse.asys-h.de>). Und wie soll der
"taugliche Newsreader" die wieder einfuegen?
Was das Argument mit dem "untauglichen Newsreader" angeht, werden alle
moeglichen Unsitten damit verteidigt, dass "taugliche Clients" sie
ausgleichen koennten, z.B. HTML-Postings, base64-encoding,
quoted-printable, Kammlayout und falsche Zeilenlaengen, oder (im WWW)
Client-"optimierte" Web-Pages. Ich denke, das sollte reichen, um
dieses Argument als Unsinn zu erkennen.
Im uebrigen wurden diese Argumente in
<2002Dec2...@a0.complang.tuwien.ac.at> ff. alle schon einmal
diskutiert und zwar in einer passenden Newsgroup.
Gerhard H Wrodnigg
>Für diese beiden Gruppen wird es voraussichtlich gegen Ende des
>Sommersemesters ein gesondertes Verfahren geben
Naja, wenn die zwei betroffenen Vortragenden einverstanden wären,
könnten wir gleich alles in einem Aufwasch erledigen.
Inzwischen wissen wir ja, daß tuwien.* existiert...
Gerald Pfeifer
>> Sommersemesters ein gesondertes Verfahren geben
> Naja, wenn die zwei betroffenen Vortragenden einverstanden wären,
> könnten wir gleich alles in einem Aufwasch erledigen.
at.tuwien.lva.datenbanken wäre angenehm, wenn wir zumindest noch bis
Mitte März (oder etwas länger) nicht löschen würden, davon abgesehen
können wir das aber gerne in einem Aufwasch erledigen.
Wie wär's mit etwas a la
at.tuwien.lva.datenbanken wird dabei nicht vor dem 31.3.2003
entfernt werden.
im RfD/CfV?
Anton Ertl
>
>>Für diese beiden Gruppen wird es voraussichtlich gegen Ende des
>>Sommersemesters ein gesondertes Verfahren geben
>
>Naja, wenn die zwei betroffenen Vortragenden einverstanden wären,
>könnten wir gleich alles in einem Aufwasch erledigen.
Wenn ihr das Verfahren schon mitten im Sommersemester beenden wollt,
waere das natuerlich ein gewichtiges Argument, davor umzuziehen
(zumindest fuer LVAs, die im Sommer stattfinden).
Reinhard Pamer
> Wenn ihr das Verfahren schon mitten im Sommersemester beenden wollt,
> waere das natuerlich ein gewichtiges Argument, davor umzuziehen
> (zumindest fuer LVAs, die im Sommer stattfinden).
Das wäre natürlich die Ideallösung. Ginge Ende März auch für dich bzw
at.tuwien.lva.uebersetzerbau-lu in Ordnung?
Gerhard H Wrodnigg
>Wenn ihr das Verfahren schon mitten im Sommersemester beenden wollt,
Nunja, die beiden Gruppen mit mehr Traffic sind die gegenständlichen.
Wenn es für Jerry kein Problem wäre (unter der Voraussetzung, daß die
Gruppe noch bis Ende März bestehen bleibt), und in der Zwischenzeit
schon in tuwien.* Ersatz eingerichtet wird.
>waere das natuerlich ein gewichtiges Argument, davor umzuziehen
>(zumindest fuer LVAs, die im Sommer stattfinden).
...wäre das natürlich eine Möglichkeit, das Verfahren im ganzen
durchzuziehen, und mit der Abstimmung beispielsweise im Februar zu
beginnen, daß dann sämtliche regulatorischen Fristen bis Ende März
laufen. Damit würde dann die Umsetzung mit Ende März zusammenfallen.
Was hältst du von dieser Variante?
Gerhard H Wrodnigg
>Wenn ein starkes Argument dafuer spricht ...
Nunja, in <3e2ee492...@news.cis.dfn.de> red ma an anderer Stelle
schon darüber ;)
>>>Sollte aus irgendeinem Grund doch jemand (nur) die andere Gruppe lesen
>>>(z.B. ein Wiederholer), waere das insofern problematisch, als es nicht
>>>nur eine Announce-, sondern auch eine Diskussionsgruppe ist.
>>
>>Schon klar, aber man kann dort dann ja auf die neue Gruppe
>>hinweisen...
>
>Und woraus besteht dann das "parallel fahren"?
Das hätte in der ersten Phase den Vorteil, daß man "Irrläufer"
informieren bzw. umleiten könnte (ich nehm an, deswegen wäre es Jerry
lieber, die Umsetzung würde erst Ende März erfolgen).
>>Spam aus .kr in einer lökalen Hierarchie?
>
>Du garantierst, dass das nicht passiert?
Ich kanns nicht garantieren, ich bin ja nicht Newshamster der TUW. Der
könnte es schon "bewerkstelligen". Obendrein hat ja der ZID die
Oberherrschaft über tuwien.*.
>Ich kann von hier aus in mit.* posten.
>Warum sollte jemand aus .kr nicht in tuwien.* posten
>koennen?
...wenns dorthin nicht verbreitet wird?
Anton Ertl
Ja, tuwien.lva.uebersetzerbau-lu ist frisch eingerichtet, atlu wird
nicht mehr verwendet werden.
Matthias Wallner
> Reinhard Pamer <rag...@pamer.net> writes:
>>Anton Ertl schrieb:
>>
>>> Wenn ihr das Verfahren schon mitten im Sommersemester beenden wollt,
>>> waere das natuerlich ein gewichtiges Argument, davor umzuziehen
>>> (zumindest fuer LVAs, die im Sommer stattfinden).
>>
>>Das wäre natürlich die Ideallösung. Ginge Ende März auch für dich bzw
>>at.tuwien.lva.uebersetzerbau-lu in Ordnung?
>
> Ja, tuwien.lva.uebersetzerbau-lu ist frisch eingerichtet, atlu wird
> nicht mehr verwendet werden.
Es wäre auch ganz praktisch, wenn tuwien.* nicht nur auf dem Tu server
vorhanden wäre. (der ja von außerhalb der Tu-Wien nicht erreichbar ist)
oder den TU Newsserver so zu konfigurieren, daß er (ev. mit
Usernamen/Passwort) auch von aussen verwendbar ist.
Heinrich Moser
> Es wäre auch ganz praktisch, wenn tuwien.* nicht nur auf dem Tu server
> vorhanden wäre. (der ja von außerhalb der Tu-Wien nicht erreichbar ist)
>
> oder den TU Newsserver so zu konfigurieren, daß er (ev. mit
> Usernamen/Passwort) auch von aussen verwendbar ist.
Es gibt zwei Möglichkeiten, die bereits jetzt funktionieren:
1. ssh-Tunnel über Studentenserver, z.B. mit
ssh -L 119:news.tuwien.ac.at:119 -f -N -l eXXXXXXX stud3.tuwien.ac.at
(wobei XXXXXXX deine Matrikelnummer ist) und dann "localhost" als
News-Server eintragen. Bei graphischen SSH-Clients (z.B. PuTTY)
statt der netten Kommandozeile oben einfach einen entsprechenden
lokalen Forward (Connection/SSH/Tunnels) von 119 nach
news.tuwien.ac.at:119 eintragen
oder
2. VPN-Verbindung zur TU öffnen, siehe
http://nic.tuwien.ac.at/tunet/vpn/
Aber natürlich wäre eine komfortablere Lösung (Verbreitung auf
news.cis.dfn.de oder Authentifizierung) zu bevorzugen.
SG,
Heinzi
Franz -STAR- Starhan
> Es wäre auch ganz praktisch, wenn tuwien.* nicht nur auf dem Tu server
> vorhanden wäre. (der ja von außerhalb der Tu-Wien nicht erreichbar ist)
>
> oder den TU Newsserver so zu konfigurieren, daß er (ev. mit
> Usernamen/Passwort) auch von aussen verwendbar ist.
Ich kann mir sehr gut vorstellen, daß das ein Anliegen der Studenten ist.
Allerdings können die RfD-Proponenten dahingehend nicht wirklich etwas
bewirken. Bitte sprecht mit dem Newsmaster der TU Wien, das ist AFAIK
Johann Klasek. Am besten und aussichtsreichsten wäre es wahrscheinlich,
wenn das die LVA-Betreuer tun würden.
Franz
Matthias Wallner
>
> Es gibt zwei Möglichkeiten, die bereits jetzt funktionieren:
>
> 1. ssh-Tunnel über Studentenserver, z.B. mit
Klar, das geht immer bei solchen Problemen. (ist aber für 08/15 User nicht
wirklich einleuchtend)
>
> 2. VPN-Verbindung zur TU öffnen, siehe
> http://nic.tuwien.ac.at/tunet/vpn/
Die bei mir nicht funktioniert... warum auch immer (ist aber egal, brauchs
eh nicht)
>
> Aber natürlich wäre eine komfortablere Lösung (Verbreitung auf
> news.cis.dfn.de oder Authentifizierung) zu bevorzugen.
Ich hab denen schon mal eine Mail deswegen geschickt.
Der hat gemeint: (ich hoffe, daß es ihm nicht stört, wenn ich das email
veröffentliche, aber es beinhaltet ja keine sensiblen Infos)
"Die erste Frage ist allerdings, ob eine Verbreitung dieser Hierarchie
außerhalb der Uni Wien überhaupt gewünscht wird.
Unabhängig davon: Das Aufnehmen von kompletten Hierarchien erfahrungsgemäß
mit einigem Aufwand verbunden, so daß wir frühestens in einigen Wochen
wieder die Zeit dafür finden werden. Ich habe die Hierarchie mal dafür
vorgemerkt, kann aber keinen Erfolg garantieren."
Matthias Wallner
>
> Es gibt zwei Möglichkeiten, die bereits jetzt funktionieren:
>
> 1. ssh-Tunnel über Studentenserver, z.B. mit
Klar, das geht immer bei solchen Problemen. (ist aber für 08/15 User nicht
wirklich einleuchtend)
>
> 2. VPN-Verbindung zur TU öffnen, siehe
> http://nic.tuwien.ac.at/tunet/vpn/
Die bei mir nicht funktioniert... warum auch immer (ist aber egal, brauchs
eh nicht)
>
> Aber natürlich wäre eine komfortablere Lösung (Verbreitung auf
> news.cis.dfn.de oder Authentifizierung) zu bevorzugen.
Ich hab an ne...@news.cis.dfn.de schon mal eine Mail deswegen geschickt.
Der hat gemeint: (ich hoffe, daß es ihm nicht stört, wenn ich das email
veröffentliche, aber es beinhaltet ja keine sensiblen Infos)
"Die erste Frage ist allerdings, ob eine Verbreitung dieser Hierarchie
außerhalb der Uni Wien überhaupt gewünscht wird.
Unabhängig davon: Das Aufnehmen von kompletten Hierarchien erfahrungsgemäß
mit einigem Aufwand verbunden, so daß wir frühestens in einigen Wochen
wieder die Zeit dafür finden werden. Ich habe die Hierarchie mal dafür
vorgemerkt, kann aber keinen Erfolg garantieren."
--
Matthias Wallner
>
> Es gibt zwei Möglichkeiten, die bereits jetzt funktionieren:
>
> 1. ssh-Tunnel über Studentenserver, z.B. mit
Klar, das geht immer bei solchen Problemen. (ist aber für 08/15 User nicht
wirklich einleuchtend)
>
> 2. VPN-Verbindung zur TU öffnen, siehe
> http://nic.tuwien.ac.at/tunet/vpn/
Die bei mir nicht funktioniert... warum auch immer (ist aber egal, brauchs
eh nicht)
>
> Aber natürlich wäre eine komfortablere Lösung (Verbreitung auf
> news.cis.dfn.de oder Authentifizierung) zu bevorzugen.
Ich hab an ne...@cis.dfn.de schon mal eine Mail deswegen geschickt.
Der hat gemeint: (ich hoffe, daß es ihm nicht stört, wenn ich das email
veröffentliche, aber es beinhaltet ja keine sensiblen Infos)
"Die erste Frage ist allerdings, ob eine Verbreitung dieser Hierarchie
außerhalb der Uni Wien überhaupt gewünscht wird.
Unabhängig davon: Das Aufnehmen von kompletten Hierarchien erfahrungsgemäß
mit einigem Aufwand verbunden, so daß wir frühestens in einigen Wochen
wieder die Zeit dafür finden werden. Ich habe die Hierarchie mal dafür
vorgemerkt, kann aber keinen Erfolg garantieren."
--
Gerhard H Wrodnigg
>Es wäre auch ganz praktisch, wenn tuwien.* nicht nur auf dem Tu server
>vorhanden wäre. (der ja von außerhalb der Tu-Wien nicht erreichbar ist)
...ich hab schon mehrfach in solchen Verfahren angeboten, tuw.* zu
führen, und dafür Accounts zu vergeben. Hubert (ich bild mir ein, er
wars) habt das gleiche Angebot gemacht...
Johann Klasek - swap last 2 domainparts
> On Sun, 5 Jan 2003, Anton Ertl wrote in aug:
>
> [at.tuwien.general nicht passend als Ersatzgruppe]
[..]
>
>> Uebrigens gibt's auch at.tuwien.lva.*-Gruppen, die in diesem RfD (und
>> daher wahrscheinlich auch im checkgroups) nicht erwaehnt werden,
>> z.B. atl.oop und atl.funktional. Wie schaut's denn da mit der
>> Verbreitung aus?
>
> Jeder NewsAdmin, der etwas auf sich und seinen Server hält, wird sich
> an http://www.usenet.at/checkgroups/checkgroups-latest (den offiziellen
> Checkgroups) halten. Und da sind diese Gruppen nicht drin.
>
> Nicht mal Chello hat diese Gruppen, und die bieten immerhin den
> Student Connect an, über den viele Studiosos sich zur TU connecten.
Braucht Chello auch nicht, denn die TU SC Anschlüsse können direkt auf
den TU Newsserver zugreifen.
>
>> Von den Studierenden habe ich uebrigens noch keine Klage ueber die
>> Verbreitung dieser Newsgroups gehoert.
>
> Ich gehe schon davon aus, daß die Studiosos direkt am TU-Wien-Server
> ihre News lesen.
Noch dazu, wo es mit SSH Forwarding und VPN-Service auch von
Fremdprovidern relativ einfach geworden ist, zum TU Newsserver zu
gelangen.
Johann Klasek
--
Johann E. Klasek Zentraler Informatikdienst - Kommunikation
Technische Universität Wien Tel: +43 1 58801-42049
A-1040 Wien, Wiedner Hauptstr. 8-10/020C Fax: +43 1 58801-42099
http://pgpkeys.tuwien.ac.at:11371/ PGP Key jklasek
Johann Klasek - swap last 2 domainparts
> Quoting Arno Fikar <arno....@utanet.at>:
>
>>>>aber man könnte ja mal tuwien.* einrichten
>>> Ja, das wurde schon mehrfach vorgeschlagen.
>
>>Und warum passiert das dann nicht?
>
> Keine Ahnung. Das obliegt den zuständigen am ZID der TUW.
Das Einrichten einer tuwien.* oder tu-wien.* Hierarchie ist sicher kein
(rechtlich abgesichertes) Privileg der TU Wien bzw. des ZIDs. Das kann
quasi jeder Newsserverbetreiber machen. G. Gontner hat schon in früheren
Diskussionen die Bereitschaft gezeigt eine solche Hierarchie auf dem wu-
wien-Newsserver anzulegen, wobei sich über das ACOnet-Peering die
Hierarchie bis zum TU-Newsserver durchsprechen hätte können (jeder, der
auf das Newsgroup-Bestellsystem der TU Wien Zugriff hat, hätte diese
Hierarchie dann freischalten können.
Wie auch immer, tuwien.* (derzeit etwa 4 NGs) gibt es seit fast einem
Jahr am Newsserver der TU Wien (war eher als technische Studie zu
sehen, die allerdings keiner offiziell strategischen Planung entspringt).
Anton Ertl
>Es wäre auch ganz praktisch, wenn tuwien.* nicht nur auf dem Tu server
>vorhanden wäre. (der ja von außerhalb der Tu-Wien nicht erreichbar ist)
Ich hab' schon angefragt, und die Antwort ist, dass der Traffic dieser
Hierarchie an's Aconet geht wie alles andere auch. Inwieweit das vom
Aconet dann weitergeleitet wird, ist nicht ganz klar. Jedenfalls sehe
ich auf news.chello.at eine Gruppe tuwien.realtime.jokes (aber sonst
keine tuwien.*-Gruppen).
Johann Klasek - swap last 2 domainparts
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> Die dann
>> Kraut-und-Rueben-Maessig zusammenzuwerfen, ist sinnlos und gegen den
>> Geist der Einteilung in Newsgroups.
>
> Folglich widerspricht es auch dem Geist von Newsgroups, eine lokale
> Hierarchie in einer Internationale (at.*) einzuordnen.
Sie wurde nicht eingeordnet, sondern war schon da.
>
>> Die einzig richtige Loesung im Fall der Entfernung aus dem
>> at.*-Checkgroups ist, die Gruppen, die benutzt werden, ausserhalb des
>> at.*-Checkgroups weiterzufuehren.
>
> Nein. Ich maße mir nicht an, die einzig richtige Lösung präsentieren zu
> können, doch was spricht gegen eine tuwien.* auf einem lokalen
> Newsserver? Warum die Krücke, wenn man's ordentlich machen kann?
Das ist alles schon in vorhergehenden Diskussionen über Jahre hin
breitgetreten worden. Es gibt 2 Gruppen mit unterschiedlichen
Standpunkten, wobei sich die eine Gruppen von der anderen Gruppe nicht
die Benennung bzw. Änderung der NG aufzwingen lassen will und die andere
Gruppe dem USENET es nicht für zumutbar hält, dass diese NGs in der at-
Hierarchie liegen müssen. Jede Gruppe lebt seinen Standpunkt aus. BTW:
ich bin in keiner dieser Gruppen als "Verantwortlicher" zu sehen und es
daher sinnlos mir erklären zu wollen, warum und wieso das Eine oder das
Andere zu machen ist (dafür gibt es entspr. Entscheidungsträger, die
hier aber vielleicht auch mitlesen).
>
>> Wie schaut's denn da mit der
>> Verbreitung aus? Wenn die auf Wiener Newsservern gut ist, waere das
>> ein Hinweis, dass at.tuwien.lva.*-Gruppen nicht im at.*-checkgroups
>> vorkommen muessen, um auf den fuer die Zielgruppe wichtigsten Servern
>> vorhanden zu sein.
>
> Wenn sich die Zielgruppe auf den Umkreis der Stadt Wien beschränkt,
> warum führt die TU Wien dann Gruppen in einer Hierarchie die weltweit
> verbreitet wird? Sitzen so viele Eurer Studenten in Rio oder Tokio?
In der Tat (so wurde mir erzählt) war tatsächlich der Grund für eine
Verbreitung von at.tuwien, dass Newsserver eines anderen Campus die
Chance hat, auf diese NGs zuzugreifen. Ein direkter Zugriff aus aller
Welt (auch nur lesende) war am Newsserver der TU niemals erwünscht. Das
war zu einer Zeit, wo von SSH-Tunneling und VPN nicht wirklich die Rede
war.
Anton Ertl
>Anton Ertl wrote:
>
>> Inwieweit das vom
>> Aconet dann weitergeleitet wird, ist nicht ganz klar. Jedenfalls sehe
>> ich auf news.chello.at eine Gruppe tuwien.realtime.jokes (aber sonst
>> keine tuwien.*-Gruppen).
>
>aconews.univie.ac.at haben oder wird das in Wien anders gehandhabt?
telnet aconews.univie.ac.at nntp
Trying 193.171.255.23...
Connected to aconews.univie.ac.at.
Escape character is '^]'.
502 aconews.univie.ac.at: Access denied to your node - news-...@news.univie.ac.at
Connection closed by foreign host.
Allerdings haben TU Wien-SC-Teilnehmer Zugriff auf news.tuwien.ac.at.
Der Grund, warum ich news.chello.at benutzt habe, war, dass ich sehen
wollte, was es anderswo gibt.
Peter J. Holzer
> Matthias Wallner <judji6...@sneakemail.com> writes:
>>Es wäre auch ganz praktisch, wenn tuwien.* nicht nur auf dem Tu server
>>vorhanden wäre. (der ja von außerhalb der Tu-Wien nicht erreichbar ist)
>
> Ich hab' schon angefragt, und die Antwort ist, dass der Traffic dieser
> Hierarchie an's Aconet geht wie alles andere auch. Inwieweit das vom
> Aconet dann weitergeleitet wird, ist nicht ganz klar. Jedenfalls sehe
> ich auf news.chello.at eine Gruppe tuwien.realtime.jokes (aber sonst
> keine tuwien.*-Gruppen).
8-O
Die ist ein überbleibsel der alten tuwien.*-Hierarchie, aus der Zeit
bevor at.tuwien.* existierte (möglicherweise sogar, bevor at.*
existierte, so genau kann ich mich an die zeitliche Abfolge nicht mehr
erinnern). tuwien.realtime.jokes war die Jokes-Gruppe des
Kopetz-Instituts.
hp
--
_ | Peter J. Holzer | To a database person,
|_|_) | Sysadmin WSR | every nail looks like a thumb.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Jamie Zawinski
Franz -STAR- Starhan
> Das Einrichten einer tuwien.* oder tu-wien.* Hierarchie ist sicher kein
> (rechtlich abgesichertes) Privileg der TU Wien bzw. des ZIDs. Das kann
> quasi jeder Newsserverbetreiber machen.
Es wäre aber schon recht eigenartig, wenn sagen wir mal die WU Wien
die Hierarchie tuwien.* "eröffnen" würde, oder?
> G. Gontner hat schon in früheren Diskussionen die Bereitschaft gezeigt
> eine solche Hierarchie auf dem wu-wien-Newsserver anzulegen, wobei sich
> über das ACOnet-Peering die Hierarchie bis zum TU-Newsserver durchsprechen
> hätte können
Welchen Grund sollte Gerhard haben, ausgerechnet eine tuwien.* Hierarchie
einzurichten?
> Wie auch immer, tuwien.* (derzeit etwa 4 NGs) gibt es seit fast einem
> Jahr am Newsserver der TU Wien (war eher als technische Studie zu
> sehen, die allerdings keiner offiziell strategischen Planung entspringt).
Nagut, aber wie ist die weitere Vorgangsweise geplant? Ist die Hierarchie
ein Experiment? Wenn ja, unter welchen Bedingungen? Wer legt neue Gruppen
an? Wer bestimmt über Feeds und Zugriffe?
Franz
Johann Klasek - swap last 2 domainparts
>
>> Das Einrichten einer tuwien.* oder tu-wien.* Hierarchie ist sicher kein
>> (rechtlich abgesichertes) Privileg der TU Wien bzw. des ZIDs. Das kann
>> quasi jeder Newsserverbetreiber machen.
>
> Es wäre aber schon recht eigenartig, wenn sagen wir mal die WU Wien
> die Hierarchie tuwien.* "eröffnen" würde, oder?
Warum? Es steht nirgendwo das ein Newsgroupname einer Organisation
"gehört", oder sollte ich mich da irren?
Es könnte ja auch ein lose Vereinigung "Freunde der TU Wien" eine
tuwien.* Hierarchie gründen. Schließlich sieht man ja nicht unmittelbar
wer eine Gruppe erstellt hat, wenn Sie mal da ist. Da ist es doch
ziemlich irrelevant auf welchem Server eine Gruppe das erste Mal das
Licht des USENET erblickt hat.
>
>> G. Gontner hat schon in früheren Diskussionen die Bereitschaft gezeigt
>> eine solche Hierarchie auf dem wu-wien-Newsserver anzulegen, wobei sich
>> über das ACOnet-Peering die Hierarchie bis zum TU-Newsserver durchsprechen
>> hätte können
>
> Welchen Grund sollte Gerhard haben, ausgerechnet eine tuwien.* Hierarchie
> einzurichten?
Ist doch egal wer diese Hierarchie einrichtet. Gerhard hat sich da
glaube nur beispielsweise angeboten (theoretisch).
>
>> Wie auch immer, tuwien.* (derzeit etwa 4 NGs) gibt es seit fast einem
>> Jahr am Newsserver der TU Wien (war eher als technische Studie zu
>> sehen, die allerdings keiner offiziell strategischen Planung entspringt).
>
> Nagut, aber wie ist die weitere Vorgangsweise geplant? Ist die Hierarchie
> ein Experiment? Wenn ja, unter welchen Bedingungen? Wer legt neue Gruppen
> an? Wer bestimmt über Feeds und Zugriffe?
Im wesentlichen ein Experiment. Primär aber für die Lehrveranstaltungs-
NG der TU Wien, die wir anlegen. Feed geht über ACOnet ins restliche
USENET.
Johann E. K.
Andreas Pommer
[..]
>> Es wäre aber schon recht eigenartig, wenn sagen wir mal die WU Wien
>> die Hierarchie tuwien.* "eröffnen" würde, oder?
>
> Warum? Es steht nirgendwo das ein Newsgroupname einer Organisation
> "gehört", oder sollte ich mich da irren?
Es gibt Hierarchien, die sind keiner Organisation zugeordnet, wie z.B.
at.* oder comp.*, andere dagegen schon, wie z.B. microsoft.* oder
redhat.*. Es kommt halt drauf an, was man mit dem Namen assoziiert.
Im Prinzip ist es so etwas wie eine Marke.
> Es könnte ja auch ein lose Vereinigung "Freunde der TU Wien" eine
> tuwien.* Hierarchie gründen.
Wenn die TU Wien einer fremden Organisation die Benutzung ihrer "Marke"
ueberlaesst...
> Schließlich sieht man ja nicht unmittelbar
> wer eine Gruppe erstellt hat, wenn Sie mal da ist. Da ist es doch
> ziemlich irrelevant auf welchem Server eine Gruppe das erste Mal das
> Licht des USENET erblickt hat.
Im Prinzip schon richtig. Nicht mehr irrelevant ist es dann, wenn auf
einmal new/rm/checkgroups-Nachrichten daherkommen. Dann sollte man sich
auf eine Quelle geeinigt haben, andernfalls gibts alt.*-Zustaende.
mit anderen Worten: ohne ein mehr-oder-weniger offizielles statement
wuerde ich mir nicht trauen, eine "fremde" Hierarchie zu gruenden. Auch
wenn es derzeit die offensichtliche policy ist, dass das der Leitung
"wurscht" ist - wenn es spaeter eine Meinungsaenderung gibt, ist der
Aerger und das Kompetenzgerangel um die control-messages sicher.
Andreas