Tauschbörsen

[Jan-Benedict Glaw]

On Mon, 2003-02-17 09:52:47 +0100, Martin Mikoleit <martin.mikoleit at t-online.de>
wrote in message <3E50A2DF.2040609 at t-online.de>:
> Deine sehr anspruchsvollen Fragen kann ich kaum beantworten. da aber das 
> Thema nun schonmal da ist, ein paar Erfahrungen von mir dazu:

[...]

> Mich würde Deine endgültige Entscheidung sehr interessieren und Deine 
> Erfahrungen damit.

Wie schon geschrieben - es geht mir nicht in erster Linie darum, _jetzt_
mal gerade schnell 5 Millionen MP3s und 10000 Filme aus dem Netz zu
saugen. Ich suche vielmehr eine Platform, die Inhalte (wiederfindbar)
verteilt, nach denen man suchen kann, bei der man nicht weiß (auf den
Servern resp. p2p-Knoten), was lokal gerade an Daten liegt etc.

Ein Netz, bei dem die Daten nicht lokalisierbar sind, hat IMHO die
größten Chancen, nicht ohne weiteres kaputtzugehen.

Wenn man sich mal so umguckt, was andere haben, etwas Träumerei dazutut,
dann sieht das etwa so aus:

- Google kann wunderbar suchen.
  ...und Google hat "Im Archiv". Das ist *Super*, denn z.B. jetzt gerade
  ist gcc.gnu.org tot, aber ich kann die Seite dennoch angucken. Man
  könnte andersherum auch sagen: "Die originale Datenquelle ist
  totgemacht worden (wodurch auch immer), aber ich kann immernoch
  darauf zugreifen."

  Natürlich wäre es nett zu wissen, zu welchem Zeitpunkt die Kopie
  angefertigt worden ist und ob's nicht vielleicht eine neuere Version
  gibt.

- Proxies können Hierarchien bilden.
  Das ist gut, denn dadurch werden Daten verteilt gehalten; ein Client
  bekommt eine Kopie von einem lokalen Cache, der immernoch laufen kann,
  auch wenn die Original-Quellen nicht mehr sind. Der tut sogar
  immernoch, wenn mehrere seiner Partents und Silbings tot sind.
  Natürlich ist's nett, wenn man dann gleich von mehreren (langsamen)
  Stellen parallel herunterladen darf (a la Edonkey).

- CVS/BK/svn/arch/Wiki können Versionsverwaltung
  Schön, daß man auch die Entwicklungsgeschichte von Daten begucken
  kann. Dann kann man sich einen Eindruck darüber machen, wie der
  Lernweg des Autors gewesen ist. Dadurch versteht man Sachen meisten
  _viel_ besser.

- Datenbanken haben Tabellen, in deren Spalten exakte semantische
                                                       Bedeutungen haben.
  Für viele Typen von Daten hätte ich gerne die Möglichkeit, ganz
  besondere Such-Kriterien anzugeben. Google kann ich "gcc" sagen, und
  ich bekomme (Archiv!) die momentan tote GCC-Seite. Leider kann ich
  Google aber nicht nach
  event=CIT2002,redner=Florian+Lohoff,format=audio/mp3,bitrate=128kBit/sec
  fragen, um 'nen MP3-Mitschnitt eines Vortrages zu bekommen. Anders
  herum möchte ich natürlich, wenn ich die Bitrate nicht angebe, alle
  vorhandenen Aufzeichnungen angezeigt bekommen, sodaß ich eine mir
  gefallende Version herunterladen kann. XML ist da vielleicht das
  passende Modewort...

  Napster und Kazaa haben etwas in der Art, da sie nach
  Album/Titel/Artist sichen können. Aber die sind halt viel zu begrenzt,
  können nur mit Musik umgehen.


...naja, man werfe all das in einen Topf (zusammen mit den anderen
Kommentaren, die ich schon in diesem Thread gegeben habe), und heraus
kommt die nicht zensierbare Tauschbörse 2003. Natürlich gibt's noch
viele Probleme zu bedenken (-> wie kann man verhindern, daß z.B. einfach
Müll in rauhen Mengen in dieses System gepumpt wird, sodaß man praktisch
bei jeder Suche "die Guten ins Töpfchen, die Schlechten ins Kröpfchen"
spielen darf...).

Ich fürchte nur, daß es sowas noch nicht gibt und erst noch geschrieben
werden will...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20030217/9f0b10f1/attachment.sig>