๐Ÿš€ go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.admin.mail
Article #331

Re: Monopolbildung und Triumph des Eigennutzes? (war: Re: Diskuss

#331
From: Martin P. Ibert
Date: Sun, 21 Feb 1993 23:02
94 lines
5774 bytes
In <TUXABJPT@math.fu-berlin.de>, Vera Heinau writes:
| cross@cs.tu-berlin.de (Carsten Rossenhoevel) writes:
| >Du willst also allen Ernstes vorschlagen, dass IN-Berlin ueber die
| >Verwendung der mitgliedereigenen Links entscheidet, mit der simplen
| >Argumentation, alles andere wuerde Dir zuviel Arbeit machen?
| Von einer Gesamt-Berliner Entscheidung ist (zumindest noch) keine
| Rede - selbstverstaendlich steht jedem Linkbetreiber frei, mit seinem
| Link zu machen, was er will.

Es beruhigt mich, dass Du das so siehst (ich hatte es allerdings von Dir
auch nicht anders erwartet). Aber aus Uwes Posting kommt es definitiv
anders rueber.

| Ihm jetzt vorzuwerfen, es sei egoistisch,
| wenn er sein Geld nicht mehr fuer andere, nicht der Gemeinschaft angehoe-
| rende einsetzen will, finde ich schon etwas eigenartig.

Darum geht es ja auch nicht. Uwe (so jedenfalls haben ich und wohl auch
Carsten es aus dem Posting von Uwe herausgelesen) moechte am liebsten jedem
IN-Berlin.De-Mitglied Mailtraffic (zumindest einlaufendem) mit domainfremden
Rechnern verbieten. Und das finde ich UEBERHAUPT NICHT WITZIG.

| Gewisse Voraussetzungen heisst:
| - fub geht aus der Submap
Klar. Logisch. Keine Diskussion.

| - automatisches Einspielen der (sub-) map ist auch (und gerade) auf den
|   IN-Berlin-Sites moeglich, die nach MX-Records routen wollen
Das ist mE das Privatproblem derjenigen, die das wollen. Deshalb die
anderen IN-Berlin.De-er, die vielleicht in der Map stehen bleiben wollen,
aus der Map draengen zu wollen finde ich schon mal nicht so toll.

| - moeglichst einfaches Updaten der berlin-internen Struktur bei Neuan-
|   schluessen oder Linkveraenderungen
Das schafft man natuerlich leichter, wenn man Neuanschluesse gleich
verhindert, indem man "pay now, mail later" einfuehrt :-/

| - Einhalten der Vertraege der Provider: Sicherstellung, dass kein uner-
|   laubter Transitverkehr stattfindet
Okay. Klar. Gebongt.

| - Sicherstellung der Erreichbarkeit
"IN-Berlin.De bleibt fuer alle erreichbar!" "Eine Gefahr fuer die
Bevoelkerung hat zu keinem Zeitpunkt bestanden."

| optimales Routing heisst:
| - moeglichst schnelle Wege
... auch von Rechnern, die ausschliesslich nach der Submap routen?

| Falsch. Wir unterstuetzen das subnet ja. Aber eben nur bis zu einem ge-
| wissen Grad an Arbeitsaufwand.
Ihr habt es bisher unterstuetzt. Aber wodurch unterstuetzt Ihr es in
Zukunft? (Nicht dass Ihr Euch schaemen muesstet, es nicht zu tun ...)

| Dazu muessten IN
| und Vz* entweder einen Zusammenschluss vollziehen, einen gemeinsamen
| Dachverband gruenden oder sonstige Vereinbarungen treffen. Das geht
| nicht "aus dem hohlen Bauch heraus".
Wenn Ihr das wirklich wollt, sollte IN-Berlin.De als Bestandteil des IN
keine Entscheidungen herbeifuehren, die eine Ausgrenzung der .sub.org-ler
zur Folge haben.

| Meiner Meinung nach haben beide Konzepte
| ihre Berechtigung und jeder Rechnerbetreiber kann sich aussuchen, was
| fuer ihn das geeignete ist. Aber unterschiedliche Konzepte beinhalten
| eben auch unterschiedliche Moeglichkeiten fuer die Mitglieder.
Bin ich denn wirklich die gesamte Schnittmenge?

| Sage mal - wir sind hier nicht in einer Werbeveranstaltung. Hier bruellt
| doch auch keiner rum "am Montag muessen wir entscheiden, ob wir das
| Nassauern der Sites xyz weiterhin dulden und deren Traffic finanzieren
| wollen" - was soll denn die (Anti-) Propaganda?

Nun gut, das Wort "Nassauer" ist nicht gefallen ...

| Es geht am Montag einzig und allein darum, aus einer vorgegebenen Situa-
| tion etwas Konstruktives aufzubauen. Und ich habe hier zwar viel Kritik
| gelesen (und noch mehr voellig ungerechtfertigte und aus der Luft ge-
| griffene Geruechte), aber noch kein einziges sinnvolles Alternativkon-
| zept.

Natuerlich nicht. Es gilt erst einmal, ein meines Erachtens unausgegorenes
und nicht beschlussreifes Konzept zu kippen. Was habe ich davon, wenn mir
am Dienstag mittag die zuendende Idee kommt, wie es doch geht (and nobody
would get nailed to anything), wenn am Montag abend, waehrend ich ueber
RFCs, pathalias-Doku und Netzplangraphiken sitze, ein gelbes Vogonenschiff
das Berliner Subnetz zerstoert hat, um einen Internetalen Bypass zu bauen?
Was meinst Du, wieviel Zeit es kostet, all diese Artikel zu schreiben?
--
    __*__     | Martin Ibert, Fรผrstenweg 11, D-13589 Berlin, -30/6: 1000B20
----|   |---- | Phone: +4930-3056541 -- E-Mail: martini@cloud9.in-berlin.de
============= | -----------------------------------------------------------
| | |   | | | |        "Blind faith in your leaders, or in anything,
| | |   | | | |          will get you killed." (Bruce Springsteen)
Technical Details
Message-ID: <H.eg.ewms3pk4pmg@cloud9.in-berlin.de>
Path: arc1-ca.pugleaf.net!sparky!uunet!math.fu-berlin.de!fub!heaven7.in-berlin.de!cloud9.in-berlin.de!martini
References: <BNTABKXT@geminix.in-berlin.de> <190293n0551@hactar.uucp> <0ZWABTCC@geminix.in-berlin.de> <1m6kpc$l9s@news.cs.tu-berlin.de> <TUXABJPT@math.fu-berlin.de>

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII
X-Google-Thread: 106481,df047165f633b626
X-Google-Attributes: gid106481,public
X-Google-Thread: 113909,df047165f633b626
X-Google-Attributes: gid113909,public
X-Google-ArrivalTime: 1993-02-21 15:02:48 PST
Path: arc1-ca.pugleaf.net!sparky!uunet!math.fu-berlin.de!fub!heaven7.in-berlin.de!cloud9.in-berlin.de!martini
From: martini@cloud9.in-berlin.de (Martin P. Ibert)
Newsgroups: de.admin.mail,bln.net.mail
Message-ID: <H.eg.ewms3pk4pmg@cloud9.in-berlin.de>
Organization: The Seventh Heaven, Berlin, Germany
Subject: Re: Monopolbildung und Triumph des Eigennutzes? (war: Re: Diskuss
References: <BNTABKXT@geminix.in-berlin.de> <190293n0551@hactar.uucp>
 <0ZWABTCC@geminix.in-berlin.de> <1m6kpc$l9s@news.cs.tu-berlin.de>
 <TUXABJPT@math.fu-berlin.de>
Reply-To: martini@cloud9.in-berlin.de
X-Software: HERMES GUS 1.10 Rev. Feb 18 1993
Date: Mon, 22 Feb 1993 00:02:48 MET
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 94