Von Reiner Schischke am Fr, 2. Juli 2004 um 00:51 #
Wieso gehört der Dank Andreas Wozniak? Hieß der nicht immer Steve Wozniak? Da muss ich gleich mal Steve fragen, allerdings Steve Jobs. Nebenbei, ist Rendezvous nicht identisch mit Microsofts Zeroconf? Siehe http://metzner.org/studies/dako/zeroconf.pdf Also Linux konnte es eh schon.
Von wo konnte linux das eh schon? am Fr, 2. Juli 2004 um 08:01 #
die konfiguration von linux-diensten und -clients in kleinen netzen ist nach wie vor eine argerliche frickelei oder gar vollig unmoglich. und ich habe das starke gefuhl, dass rendevouz auch nix an diesem unertraglichen zustand andern wird.
> die konfiguration von linux-diensten und -clients in kleinen netzen ist nach wie vor eine argerliche frickelei oder gar vollig unmoglich.
Wie kommst du jetzt ausgerechnet auf Linux? Das exakt gleiche Problem besteht unter jedem anderen System auch, sei es nun Windows, MacOS X, ein *BSD, ein Unix, ein Mobiltelefon, ein Drucker, ein Scanner oder ein PDA. Natürlich besteht das Problem unter Linux auch, aber das hat nichts mit Linux zu tun, sondern ist ein Problem, das den Internet-Protokollen inhärent ist.
Es gab früher bereits Ansätze für konfigurationsfreie, infrastrukturlose LANs wie z.B. Microsofts und IBMs NetBIOS oder Apples AppleTalk. Diese hatten aber ein paar gravierende Nachteile: sie waren mehr oder weniger proprietär, weder untereinander noch mit Internet-Protokollen interoperabel und ausschließlich für LANs geeignet, das heißt, man war gezwungen, im LAN (NetBIOS, AppleTalk) und im WAN (TCP/IP und Co.) unterschiedliche Protokolle einzusetzen. Diese Nachteile hat Zeroconf nicht: es ist offen und es setzt auf Internet-Protokollen auf, das heißt, es ist interoperabel und man fährt im LAN und WAN dasselbe Protokoll. In den meisten, eventuell sogar allen Bereichen werden bestehende Applikationen ohne eine einzige Änderung automatisch Zeroconf nutzen können. Das ist etwas, was mit AppleTalk oder NetBIOS ebenfalls nicht geht, da muss eine Applikation, die eines der Protokolle oder gar beide nutzen will, diese(s) Protokoll(e) gesondert zusätzlich implementieren.
> und ich habe das starke gefuhl, dass rendevouz auch nix an diesem unertraglichen zustand andern wird.
Konfigurationsfreie, infrastrukturlose LANs auf Basis von NetBIOS oder AppleTalk funktionieren (mehr oder weniger - AppleTalk mehr, NetBIOS weniger) schon seit über 10 Jahren und auf Basis von Zeroconf in MacOS X auch schon ein paar Jahre.
deine ausfuhrungen sind ja ganz interessant (brav!), gehen aber am kern vorbei.
unter windows kann ich dateien und drucker einfach so freigeben und andere konnen dann einfach darauf zugreifen. etwas, was mit linux bis heute nicht gehen will.
Konfigurationsfreie, infrastrukturlose LANs auf Basis von NetBIOS oder AppleTalk funktionieren (mehr oder weniger - AppleTalk mehr, NetBIOS weniger) schon seit über 10 Jahren aber nicht mit linux.
und auf Basis von Zeroconf in MacOS X auch schon ein paar Jahre. aber nicht mit linux.
> unter windows kann ich dateien und drucker einfach so freigeben
Das passiert doch aber auf einer völlig anderen Ebene und hat mit dem, was mit Zeroconf erreicht werden soll, überhaupt nichts zu tun.
Das funktioniert außerdem nur, wenn entweder NetBIOS eingesetzt wird, womit das ganze dann weder interoperabel noch im WAN nutzbar ist oder aber wenn vorher das Netzwerk entweder manuell konfiguriert (Vergabe der IP-Adressen, Einträge der Rechnernamen in die /etc/hosts und die LMHOSTS-Datei) oder die entsprechende Infrastruktur (DHCP-Server, DNS-Server, WINS-Server) eingerichtet wurde - und gerade das ist es, was mit Zeroconf erreicht werden soll: konfigurationsfreie (ohne manuelle Eingabe), infrastrukturlose (ohne DHCP-, BOOTP- oder RARP-Server) Vergabe von IP-Adressen, konfigurationsfreie (ohne Editieren der /etc/hosts-Date), infrastrukturlose (ohne DNS-Server) Umsetzung zwischen Hostnamen und IP-Adressen, konfigurationsfreie (ohne Eingabe des Dienstnamens), infrastrukturlose (ohne Directory-Server) Service Discovery und konfigurationsfreie (ohne manuelle Eingabe), infrastrukturlose (ohne MADCAP-Server) Allozierung von Multicast-Adressen. All das kann Zeroconf leisten, NetBIOS dagegen z.T. nur eingeschränkt, z.T. gar nicht.
Zeroconf ist dazu vollkommen orthogonal.
> und andere konnen dann einfach darauf zugreifen. etwas, was mit linux bis heute nicht gehen will.
Das ist irgendetwas zwischen einer ziemlich gerissenen Formulierung und einer glatten Lüge.
Zunächst mal ist Linux nur ein Betriebssystemkernel. Betriebssystemkernel sind aber nun mal für Datei- und Druckerfreigaben überhaupt gar nicht zuständig, also ist es kein Wunder, dass Linux an sich das nicht leisten kann. In so fern hast du also recht, dass das mit Linux allein nicht geht. Aber mittels Benutzerschnittstellen, die unter anderem auch (aber natürlich nicht nur) unter Linux laufen und Netzwerkdateisystem- bzw. Druckerservern, die unter anderem auch (aber natürlich nicht nur) unter Linux laufen, ist das natürlich unter Linux mit Hilfe von dafür gedachter Software durchaus möglich.
Für Dateifreigaben ist ein Netzwerkdateisystem-Server zuständig, für Druckerfreigaben ein Druckerserver und für die Einrichtung dieser Freigaben eine Benutzerschnittstelle. Der Betriebssystemkernel, egal ob jetzt Linux, Helix oder irgendein anderer, hat damit überhaupt nichts zu tun! Da du nicht spezifiziert hast, was für ein Netzwerkdateisystem du mittels welchen Servers unter Verwendung welcher Benutzeroberfläche konfigurieren willst, ist deine Aussage also bestenfalls wertlos, schlimmstenfalls ein ziemlich billiger Trollversuch.
Natürlich habe ich auch noch ein Gegenbeispiel: Datei- und Druckerfreigaben mittels zwei, drei Mausklicks sind z.B. unter KDE mit Samba (Dateifreigaben über CIFS) und CUPS (Druckerfreigaben über IPP) problemlos möglich, unabhängig davon, welcher Betriebssystemkernel verwendet wird, also natürlich auch unter Linux.
>> Konfigurationsfreie, infrastrukturlose LANs auf Basis von NetBIOS oder AppleTalk funktionieren (mehr oder weniger - AppleTalk mehr, NetBIOS weniger) schon seit über 10 Jahren > aber nicht mit linux.
Aus welchem Grund sollte der NetBIOS- oder AppleTalk-Netzwerkstack von Linux sich anders verhalten als der von Windows oder MacOS? Hast du dafür Beispiele? Diese Technologien sind völlig unabhängig vom darunterliegenden Betriebssystem.
>> und auf Basis von Zeroconf in MacOS X auch schon ein paar Jahre. > aber nicht mit linux.
Aus welchem Grund sollte die Zeroconf-Implementierung von Linux sich anders verhalten als die von MacOS X? (Insbesondere wenn unter Linux ebenfalls die Buchstabe für Buchstabe identische Version von Apples Rendezvous als Zeroconf-Implementierung verwendet wird, die auch in MacOS X zum Einsatz kommt.) Hast du dafür Beispiele? Diese Technologien sind völlig unabhängig vom darunterliegenden Betriebssystem, also sollte es da keine Unterschiede geben, denn offene Protokolle derart zu pervertieren, dass sie mit anderen Implementierungen desselben offenen Protokolls nicht mehr kompatibel sind, ist eigentlich im Freie-Software-Bereich eher unüblich.
Datei- und Druckerfreigaben mittels zwei, drei Mausklicks sind z.B. unter KDE mit Samba (Dateifreigaben über CIFS) und CUPS (Druckerfreigaben über IPP) problemlos m?glich, unabh?ngig davon, welcher Betriebssystemkernel verwendet wird, also nat?rlich auch unter Linux.
garnich! der kde-freigabereiter im kontextmenu eines ordners hat keinerlei funktion und im menu eines druckers im kdeprint gibts so einen reiter nicht.
toll, was du alles uber netzwerke weisst, aber den einfachen anwender interessiert das nicht so.
Wer keine Ahnung von Netzwerken hat, soll auch kein Netzwerk administrieren. Das führt nur zu noch mehr Würmern und offenen SMTP-Relays, über die Spam verschickt wird.
>> Datei- und Druckerfreigaben mittels zwei, drei Mausklicks sind z.B. unter KDE mit Samba (Dateifreigaben über CIFS) und CUPS (Druckerfreigaben über IPP) problemlos möglich, unabhängig davon, welcher Betriebssystemkernel verwendet wird, also natürlich auch unter Linux. > garnich!
Ah! Sehr schön. Eine detaillierte, qualifizierte und messerscharf begründete konstruktive Aussage als Basis für eine interessante Diskussion (-;
Im Ernst: ich liebe Pauschalaussagen, da sie sich so herrlich einfach widerlegen lassen.
Also: in Knoppix 3.5 erfordert das Anlegen eines PDF-Druckers (d.h. eines Druckers, der die Dokumente statt auf Papier als PDF-Datei ausgibt), die Freigabe dieses Druckers über remote LPR (für Linux/Unix) und SMB/IPP (für Windows), die Einrichtung eines Druckerservers, die Einrichtung eines Dateiservers (genauer: zweier Dateiserver) und die Freigabe des Ordners (über SMB für Windows und NFS für Linux/Unix), in dem die PDF-Dateien landen, exakt 12 Mausklicks und die dreimalige Vergabe eines Passwortes. Einige dieser Eingaben und Mausklicks fallen im Normalfall noch weg, sie kommen ganz einfach daher, dass Knoppix eine Live-CD-Distribution ist und daher Konfigurationsdaten, die im Normalfall bei der Installation abgefragt werden, eben immer im laufenden Betrieb erledigt werden müssen. Im Normalfall sollten es 8 Mausklicks und die einmalige Eingabe eines Passwortes sein - so ist es auch, wenn man die notwenigen Konfigurationsarbeiten im Knoppix vorher erledigt.
Zugegeben: das sind jetzt mehr als die zwei bis drei Mausklicks, die ich oben postuliert habe, allerdings handelt es sich ja nicht nur um eine Datei- oder Druckerfreigabe, sondern um jeweilszwei Datei- undzwei Druckerfreigaben sowie eine Druckerinstallation.
> der kde-freigabereiter im kontextmenu eines ordners hat keinerlei funktion
Bei mir (Knoppix 3.5) schon. Die Freigabe eines Ordners benötigt exakt 4 Mausklicks. Damit sind deine Behauptungen widerlegt.
Natürlich hat all das nichts mit Zeroconf zu tun ...
> Nebenbei, ist Rendezvous nicht identisch mit Microsofts Zeroconf?
Doppel-Nein.
Erstens: Rendezvous ist eine Sammlung von Programmen, Zeroconf eine Sammlung von Standards (bzw. genauer Standard-Entwürfen). Die beiden liegen also auf unterschiedlichen Abstraktionsebenen und können daher gar nicht identisch sein. Rendezvous ist eine Implementierung von Zeroconf.
Zweitens: Zeroconf ist nicht von Microsoft. Microsoft hat eine zu Zeroconf inkompatible eigene Technologie mit ähnlichen Zielen namens "Universal Plug and Play (UPnP)", möglicherweise hast du die beiden verwechselt. Zeroconf stammt ursprünglich von Apple (im wesentlichen ist es der Versuch, die konfigurationsfreie und infrastrukturlose Art des Netzwerkens mit dem proprietären AppleTalk-Protokoll auf die offenen Internet-Protokolle zu übertragen), wird inzwischen aber von einer IETF-Arbeitsgruppe vorangetrieben. Inzwischen beteiligt sich auch Microsoft mit der typischen Strategie (versuche agressiv das proprietäre UPnP in den Markt zu bringen und sorge gleichzeitig dafür, dass du bei der offenen Konkurrenz Zeroconf mit im Entscheidungsprozess sitzt) an Zeroconf.
Von Reiner Schischke am Fr, 2. Juli 2004 um 11:42 #
Das ist allerdings aber auch Absicht. Es sollen nur Geräte im LAN zusammenarbeiten. Oder möchtest du deine Gerätekonfiguration im Internet zur Verfügung stellen. Dann besorg schon mal Papier und Toner/Tinte für deine Drucker.
Ein LAN ohne VLANs/Netzsegmente benötigt kein Rendezvous. Die grösstenfalls ca. 24 oder 48 (also minus Server, Cisco, Printserver) Workstations kann man auch ohne Rendezvous verwalten.
Und wenn ich VLANs/Netzsegmente habe, dann hab ich mit Rendezvous verloren. Also da bleib ich lieber bei SLP...
>> Es sollen nur Geräte im LAN zusammenarbeiten > Ein LAN ohne VLANs/Netzsegmente benötigt kein Rendezvous.
Natürlich kann man theoretisch die vier Funktionen von Zeroconf auch mittels Konfiguration von Hand oder mittels geeigneter Infrastruktur erreichen, das ist klar, schließlich wird genau das ja bereits seit über 30 Jahren gemacht. Zeroconf ist aber für die Bereiche gedacht, wo das praktisch nicht geht - zum Beispiel, weil es gar keinen Administrator gibt - oder man es schlicht und ergreifend nicht will - zum Beispiel, weil es den Sinn eines spontanen Ad-Hoc-Netzwerks konterkarieren würde, wenn man erstmal alle Geräte konfigurieren oder eine Netzwerkinfrastruktur installieren müsste.
> Die grösstenfalls ca. 24 oder 48 (also minus Server, Cisco, Printserver) Workstations kann man auch ohne Rendezvous verwalten.
Workstations? Server? Cisco? Es geht hier aber schon noch um Zeroconf bzw. Rendezvous, oder? Zeroconf ist nunmal eine Technologie für konfigurationsfreie, infrastrukturlose Netzwerke. Natürlich ist eine solche Technologie in einem Netz mit Administrator und Netzwerkinfrastruktur völlig fehl am Platz, das ist doch wohl offensichtlich. Bei Zeroconf geht es mehr um Stereoanlagen, Autos, Kühlschränke, Mobiltelefone, PDAs, Armbanduhren etc.. Und es geht eben um konfigurationsfreie, infrastrukturlose Netzwerke, und da kannst du nicht mal eben "Workstations ohne Rendezvous verwalten", weil dann das Netz per definitionem nicht mehr konfigurationsfrei ist und du kannst auch nicht eben mal einen DHCP-Server aufsetzen, weil dann das Netz per definitionem nicht mehr infrastrukturlos ist.
> Und wenn ich VLANs/Netzsegmente habe, dann hab ich mit Rendezvous verloren.
Und wie wahrscheinlich ist dieser Fall in einem spontanen Ad-Hoc-Netzwerk?
> Also da bleib ich lieber bei SLP...
Das bleibt dir unbenommen. Jeder hat die freie Wahl, was er einsetzen möchte. Es ist ja schließlich auch so, dass Zeroconf nichts kann, was man nicht auch mit Infrastruktur oder Konfiguration erreichen könnte - nur kann es das eben ohne Infrastruktur und ohne Konfiguration.
Beispiel: Zeroconf hat die folgenden vier Funktionen:
Allozierung von IP-Adressen,
Umsetzung zwischen Hostnamen und IP-Adressen,
Service Discovery,
Allozierung von Multicast-Adressen.
Diese Funktionen habe ich auch bei einer Konfiguration von Hand. Z.B. für Funktion 1: ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 (Linux 2.0 oder älter) bzw. ip addr add 192.168.1.1/24 broadcast 192.168.1.255 label eth0 dev eth0 (ab Linux 2.2). Für Funktion 2: vi /etc/hosts. 3 und 4 weiß ich jetzt nicht aus dem Kopf, geht aber bestimmt auch irgendwie.
Und natürlich hat man diese Funktionen auch bei Verwendung von Infrastruktur. Z.B. für Funktion 1 unter Verwendung eines RARP-, BOOTP- oder DHCP-Servers. Für Funktion 2 unter Verwendung eines DNS-Servers. Für Funktion 3 unter Verwendung von SLP. Und für Funktion 4 unter Verwendung eines MADCAP-Servers.
Der Punkt ist, dass Zeroconf diese Funktionen bereitstellen kann ohne Konfiguration und ohne eine Netzwerkinfrastruktur zu benötigen.
Nebenbei, ist Rendezvous nicht identisch mit Microsofts Zeroconf?
Siehe http://metzner.org/studies/dako/zeroconf.pdf
Also Linux konnte es eh schon.
A+ (diesmal mit weniger Fehler)
Reiner
Wie kommst du jetzt ausgerechnet auf Linux? Das exakt gleiche Problem besteht unter jedem anderen System auch, sei es nun Windows, MacOS X, ein *BSD, ein Unix, ein Mobiltelefon, ein Drucker, ein Scanner oder ein PDA. Natürlich besteht das Problem unter Linux auch, aber das hat nichts mit Linux zu tun, sondern ist ein Problem, das den Internet-Protokollen inhärent ist.
Es gab früher bereits Ansätze für konfigurationsfreie, infrastrukturlose LANs wie z.B. Microsofts und IBMs NetBIOS oder Apples AppleTalk. Diese hatten aber ein paar gravierende Nachteile: sie waren mehr oder weniger proprietär, weder untereinander noch mit Internet-Protokollen interoperabel und ausschließlich für LANs geeignet, das heißt, man war gezwungen, im LAN (NetBIOS, AppleTalk) und im WAN (TCP/IP und Co.) unterschiedliche Protokolle einzusetzen. Diese Nachteile hat Zeroconf nicht: es ist offen und es setzt auf Internet-Protokollen auf, das heißt, es ist interoperabel und man fährt im LAN und WAN dasselbe Protokoll. In den meisten, eventuell sogar allen Bereichen werden bestehende Applikationen ohne eine einzige Änderung automatisch Zeroconf nutzen können. Das ist etwas, was mit AppleTalk oder NetBIOS ebenfalls nicht geht, da muss eine Applikation, die eines der Protokolle oder gar beide nutzen will, diese(s) Protokoll(e) gesondert zusätzlich implementieren.
> und ich habe das starke gefuhl, dass rendevouz auch nix an diesem unertraglichen zustand andern wird.
Konfigurationsfreie, infrastrukturlose LANs auf Basis von NetBIOS oder AppleTalk funktionieren (mehr oder weniger - AppleTalk mehr, NetBIOS weniger) schon seit über 10 Jahren und auf Basis von Zeroconf in MacOS X auch schon ein paar Jahre.
jwm
unter windows kann ich dateien und drucker einfach so freigeben und andere konnen dann einfach darauf zugreifen. etwas, was mit linux bis heute nicht gehen will.
Konfigurationsfreie, infrastrukturlose LANs auf Basis von NetBIOS oder AppleTalk funktionieren (mehr oder weniger - AppleTalk mehr, NetBIOS weniger) schon seit über 10 Jahren
aber nicht mit linux.
und auf Basis von Zeroconf in MacOS X auch schon ein paar Jahre.
aber nicht mit linux.
Das passiert doch aber auf einer völlig anderen Ebene und hat mit dem, was mit Zeroconf erreicht werden soll, überhaupt nichts zu tun.
Das funktioniert außerdem nur, wenn entweder NetBIOS eingesetzt wird, womit das ganze dann weder interoperabel noch im WAN nutzbar ist oder aber wenn vorher das Netzwerk entweder manuell konfiguriert (Vergabe der IP-Adressen, Einträge der Rechnernamen in die /etc/hosts und die LMHOSTS-Datei) oder die entsprechende Infrastruktur (DHCP-Server, DNS-Server, WINS-Server) eingerichtet wurde - und gerade das ist es, was mit Zeroconf erreicht werden soll: konfigurationsfreie (ohne manuelle Eingabe), infrastrukturlose (ohne DHCP-, BOOTP- oder RARP-Server) Vergabe von IP-Adressen, konfigurationsfreie (ohne Editieren der /etc/hosts-Date), infrastrukturlose (ohne DNS-Server) Umsetzung zwischen Hostnamen und IP-Adressen, konfigurationsfreie (ohne Eingabe des Dienstnamens), infrastrukturlose (ohne Directory-Server) Service Discovery und konfigurationsfreie (ohne manuelle Eingabe), infrastrukturlose (ohne MADCAP-Server) Allozierung von Multicast-Adressen. All das kann Zeroconf leisten, NetBIOS dagegen z.T. nur eingeschränkt, z.T. gar nicht.
Zeroconf ist dazu vollkommen orthogonal.
> und andere konnen dann einfach darauf zugreifen. etwas, was mit linux bis heute nicht gehen will.
Das ist irgendetwas zwischen einer ziemlich gerissenen Formulierung und einer glatten Lüge.
Zunächst mal ist Linux nur ein Betriebssystemkernel. Betriebssystemkernel sind aber nun mal für Datei- und Druckerfreigaben überhaupt gar nicht zuständig, also ist es kein Wunder, dass Linux an sich das nicht leisten kann. In so fern hast du also recht, dass das mit Linux allein nicht geht. Aber mittels Benutzerschnittstellen, die unter anderem auch (aber natürlich nicht nur) unter Linux laufen und Netzwerkdateisystem- bzw. Druckerservern, die unter anderem auch (aber natürlich nicht nur) unter Linux laufen, ist das natürlich unter Linux mit Hilfe von dafür gedachter Software durchaus möglich.
Für Dateifreigaben ist ein Netzwerkdateisystem-Server zuständig, für Druckerfreigaben ein Druckerserver und für die Einrichtung dieser Freigaben eine Benutzerschnittstelle. Der Betriebssystemkernel, egal ob jetzt Linux, Helix oder irgendein anderer, hat damit überhaupt nichts zu tun! Da du nicht spezifiziert hast, was für ein Netzwerkdateisystem du mittels welchen Servers unter Verwendung welcher Benutzeroberfläche konfigurieren willst, ist deine Aussage also bestenfalls wertlos, schlimmstenfalls ein ziemlich billiger Trollversuch.
Natürlich habe ich auch noch ein Gegenbeispiel: Datei- und Druckerfreigaben mittels zwei, drei Mausklicks sind z.B. unter KDE mit Samba (Dateifreigaben über CIFS) und CUPS (Druckerfreigaben über IPP) problemlos möglich, unabhängig davon, welcher Betriebssystemkernel verwendet wird, also natürlich auch unter Linux.
>> Konfigurationsfreie, infrastrukturlose LANs auf Basis von NetBIOS oder AppleTalk funktionieren (mehr oder weniger - AppleTalk mehr, NetBIOS weniger) schon seit über 10 Jahren
> aber nicht mit linux.
Aus welchem Grund sollte der NetBIOS- oder AppleTalk-Netzwerkstack von Linux sich anders verhalten als der von Windows oder MacOS? Hast du dafür Beispiele? Diese Technologien sind völlig unabhängig vom darunterliegenden Betriebssystem.
>> und auf Basis von Zeroconf in MacOS X auch schon ein paar Jahre.
> aber nicht mit linux.
Aus welchem Grund sollte die Zeroconf-Implementierung von Linux sich anders verhalten als die von MacOS X? (Insbesondere wenn unter Linux ebenfalls die Buchstabe für Buchstabe identische Version von Apples Rendezvous als Zeroconf-Implementierung verwendet wird, die auch in MacOS X zum Einsatz kommt.) Hast du dafür Beispiele? Diese Technologien sind völlig unabhängig vom darunterliegenden Betriebssystem, also sollte es da keine Unterschiede geben, denn offene Protokolle derart zu pervertieren, dass sie mit anderen Implementierungen desselben offenen Protokolls nicht mehr kompatibel sind, ist eigentlich im Freie-Software-Bereich eher unüblich.
jwm
garnich! der kde-freigabereiter im kontextmenu eines ordners hat keinerlei funktion und im menu eines druckers im kdeprint gibts so einen reiter nicht.
toll, was du alles uber netzwerke weisst, aber den einfachen anwender interessiert das nicht so.
> garnich!
Ah! Sehr schön. Eine detaillierte, qualifizierte und messerscharf begründete konstruktive Aussage als Basis für eine interessante Diskussion (-;
Im Ernst: ich liebe Pauschalaussagen, da sie sich so herrlich einfach widerlegen lassen.
Also: in Knoppix 3.5 erfordert das Anlegen eines PDF-Druckers (d.h. eines Druckers, der die Dokumente statt auf Papier als PDF-Datei ausgibt), die Freigabe dieses Druckers über remote LPR (für Linux/Unix) und SMB/IPP (für Windows), die Einrichtung eines Druckerservers, die Einrichtung eines Dateiservers (genauer: zweier Dateiserver) und die Freigabe des Ordners (über SMB für Windows und NFS für Linux/Unix), in dem die PDF-Dateien landen, exakt 12 Mausklicks und die dreimalige Vergabe eines Passwortes. Einige dieser Eingaben und Mausklicks fallen im Normalfall noch weg, sie kommen ganz einfach daher, dass Knoppix eine Live-CD-Distribution ist und daher Konfigurationsdaten, die im Normalfall bei der Installation abgefragt werden, eben immer im laufenden Betrieb erledigt werden müssen. Im Normalfall sollten es 8 Mausklicks und die einmalige Eingabe eines Passwortes sein - so ist es auch, wenn man die notwenigen Konfigurationsarbeiten im Knoppix vorher erledigt.
Zugegeben: das sind jetzt mehr als die zwei bis drei Mausklicks, die ich oben postuliert habe, allerdings handelt es sich ja nicht nur um eine Datei- oder Druckerfreigabe, sondern um jeweils zwei Datei- und zwei Druckerfreigaben sowie eine Druckerinstallation.
> der kde-freigabereiter im kontextmenu eines ordners hat keinerlei funktion
Bei mir (Knoppix 3.5) schon. Die Freigabe eines Ordners benötigt exakt 4 Mausklicks. Damit sind deine Behauptungen widerlegt.
Natürlich hat all das nichts mit Zeroconf zu tun ...
jwm
Doppel-Nein.
Erstens: Rendezvous ist eine Sammlung von Programmen, Zeroconf eine Sammlung von Standards (bzw. genauer Standard-Entwürfen). Die beiden liegen also auf unterschiedlichen Abstraktionsebenen und können daher gar nicht identisch sein.
Rendezvous ist eine Implementierung von Zeroconf.
Zweitens: Zeroconf ist nicht von Microsoft. Microsoft hat eine zu Zeroconf inkompatible eigene Technologie mit ähnlichen Zielen namens "Universal Plug and Play (UPnP)", möglicherweise hast du die beiden verwechselt. Zeroconf stammt ursprünglich von Apple (im wesentlichen ist es der Versuch, die konfigurationsfreie und infrastrukturlose Art des Netzwerkens mit dem proprietären AppleTalk-Protokoll auf die offenen Internet-Protokolle zu übertragen), wird inzwischen aber von einer IETF-Arbeitsgruppe vorangetrieben. Inzwischen beteiligt sich auch Microsoft mit der typischen Strategie (versuche agressiv das proprietäre UPnP in den Markt zu bringen und sorge gleichzeitig dafür, dass du bei der offenen Konkurrenz Zeroconf mit im Entscheidungsprozess sitzt) an Zeroconf.
jwm
A+
Reiner
Ein LAN ohne VLANs/Netzsegmente benötigt kein Rendezvous. Die grösstenfalls ca. 24 oder 48 (also minus Server, Cisco, Printserver) Workstations kann man auch ohne Rendezvous verwalten.
Und wenn ich VLANs/Netzsegmente habe, dann hab ich mit Rendezvous verloren. Also da bleib ich lieber bei SLP...
> Ein LAN ohne VLANs/Netzsegmente benötigt kein Rendezvous.
Natürlich kann man theoretisch die vier Funktionen von Zeroconf auch mittels Konfiguration von Hand oder mittels geeigneter Infrastruktur erreichen, das ist klar, schließlich wird genau das ja bereits seit über 30 Jahren gemacht. Zeroconf ist aber für die Bereiche gedacht, wo das praktisch nicht geht - zum Beispiel, weil es gar keinen Administrator gibt - oder man es schlicht und ergreifend nicht will - zum Beispiel, weil es den Sinn eines spontanen Ad-Hoc-Netzwerks konterkarieren würde, wenn man erstmal alle Geräte konfigurieren oder eine Netzwerkinfrastruktur installieren müsste.
> Die grösstenfalls ca. 24 oder 48 (also minus Server, Cisco, Printserver) Workstations kann man auch ohne Rendezvous verwalten.
Workstations? Server? Cisco? Es geht hier aber schon noch um Zeroconf bzw. Rendezvous, oder? Zeroconf ist nunmal eine Technologie für konfigurationsfreie, infrastrukturlose Netzwerke. Natürlich ist eine solche Technologie in einem Netz mit Administrator und Netzwerkinfrastruktur völlig fehl am Platz, das ist doch wohl offensichtlich. Bei Zeroconf geht es mehr um Stereoanlagen, Autos, Kühlschränke, Mobiltelefone, PDAs, Armbanduhren etc.. Und es geht eben um konfigurationsfreie, infrastrukturlose Netzwerke, und da kannst du nicht mal eben "Workstations ohne Rendezvous verwalten", weil dann das Netz per definitionem nicht mehr konfigurationsfrei ist und du kannst auch nicht eben mal einen DHCP-Server aufsetzen, weil dann das Netz per definitionem nicht mehr infrastrukturlos ist.
> Und wenn ich VLANs/Netzsegmente habe, dann hab ich mit Rendezvous verloren.
Und wie wahrscheinlich ist dieser Fall in einem spontanen Ad-Hoc-Netzwerk?
> Also da bleib ich lieber bei SLP...
Das bleibt dir unbenommen. Jeder hat die freie Wahl, was er einsetzen möchte. Es ist ja schließlich auch so, dass Zeroconf nichts kann, was man nicht auch mit Infrastruktur oder Konfiguration erreichen könnte - nur kann es das eben ohne Infrastruktur und ohne Konfiguration.
Beispiel:
Zeroconf hat die folgenden vier Funktionen:
Diese Funktionen habe ich auch bei einer Konfiguration von Hand. Z.B. für Funktion 1: ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 (Linux 2.0 oder älter) bzw. ip addr add 192.168.1.1/24 broadcast 192.168.1.255 label eth0 dev eth0 (ab Linux 2.2). Für Funktion 2: vi /etc/hosts. 3 und 4 weiß ich jetzt nicht aus dem Kopf, geht aber bestimmt auch irgendwie.
Und natürlich hat man diese Funktionen auch bei Verwendung von Infrastruktur. Z.B. für Funktion 1 unter Verwendung eines RARP-, BOOTP- oder DHCP-Servers. Für Funktion 2 unter Verwendung eines DNS-Servers. Für Funktion 3 unter Verwendung von SLP. Und für Funktion 4 unter Verwendung eines MADCAP-Servers.
Der Punkt ist, dass Zeroconf diese Funktionen bereitstellen kann ohne Konfiguration und ohne eine Netzwerkinfrastruktur zu benötigen.
jwm