Leonidas hat geschrieben:Ein Dateisystem-Feature mit einem OS zu vergleichen geht nicht einfach so, es sind eben völlig andere Sachen.
Du hast meinen abstrakten Vergleich auf eine konkrete Ebene gebracht. Dir ist offenbar entgangen, dass dieser Vergleich lediglich symbolisch gemeint war, in Anspielung auf das Schattendasein von Hurd. Der Vergleich funktioniert beispielsweise auch mit dem Konqueror: brauchbarer Browser, fristet aber trotzdem ein Schattendasein.
Hurd ist aber nicht für den Alltag brauchbar. NTFS-Symlinks sind das.
Das ändert auch nichts an der Tatsache, dass NTFS-Symlinks genau so selten benutzt werden wie GNU Hurd.
Ursprünglich hast ja du gemeint, dass Windows-User unfähig sind Symlinks zu nutzen. Das sind sie nicht.
Ob fähig oder nicht, niemand nutzt Symlinks. Das ist eine einfache Tatsache, die jenseits aller Vermutungen und Spekulationen über die Fähigkeiten von Windows-Nutzern steht.
Mit einer brauchbar zu nutzenden Software ist das auch für Windows-Nutzer kein Problem. Und Symlinks sind nicht tiefergehender als Defragmentierung, was wie ich schätzen würde, durchaus vielen Windows-Nutzern was sagt.
Es gibt aber einen bedeutenden Unterschied. Defragmentierung unterstützt Windows out-of-the-box. Dagegen liefert es meines Wissens nicht mal ein Kommandozeilen-Toll für symlinks mit, geschweige denn GUI-Integration.
lunar hat geschrieben:Dann läge nämlich auch der Schluss nahe, dass, wenn eine Anwendung auf die Notwendigkeit von Symlinks verweist, diese Anwendung eher durch eine andere ersetzt wird, die gleiches leistet.
Nein, nicht unbedingt. Wenn eine Software gut ist und auf die Möglichkeit von Symlinks hinweist oder sogar, entsprechende Software mitbringt (unter Windows ja durchaus üblich viele Sachen zusammenzupacken statt Dependencies zu deklarieren) dann ist das überhaupt kein Problem.[/quote]
Man propagiert ein sinnvolles Feature (symlinks) dadurch, dass man die DLL-Hell weiter befördert. Und ganz nebenbei bläst man ein kleines Tool wie lanshark um ein paar MBs auf, nur damit mehrere Share-Verzeichnisse unterstützt werden. Wunderbar, mit diesen Design-Richtlinien wird man garantiert zum guten Programmierer!
Der Hinweis allein wird nicht wirklich ausreichen: Als User fragt man sich dann, warum man ein weiteres Tool installieren muss, nur damit mehrere Shares unterstützt werden. Das der Nutzen von Symlinks in anderen Situationen den Nutzer zu dieser zusätzlichen Installation bewegt, halte ich ebenfalls für ausgeschlossen: "Ich bin doch bisher prima ohne ausgekommen".
Nebenbei ist das ganze auch nicht gerade förderlich für die Usability eines Tools. Immerhin muss jedes Mal eine ganze Anwendung gestartet werden, nur um eine neue Freigabe anzulegen.
lunar hat geschrieben:Diese Argumentation wird der Wirklichkeit aber eh nicht gerecht. Tatsache ist doch, dass selbst erfahrene Nutzer, also solche, die wissen, dass PFs keine Sicherheit bieten und das RAM-Defragmentierer unsinnig sind, meistens nicht wissen, dass NTFS tatsächlich Symlinks unterstützt.
Und das heißt, dass man die User im Dunkeln lassen soll und Symlinks als Insiderwissen behandeln sollte? Für mich fühlt sich das irgendwie an als würde man Kernel-Optionen verstecken, damit Insider ihr System tunen können, ohne dass die Masse was davon mitbekommt (gut, der Vergleich ist nicht so sonderlich gelungen, Symlinks mit OS zu vergleichen ist eben nicht so der Hit). [/quote]
Kernel-Optionen sind doch versteckt. Welcher Linux-User kompiliert denn heute noch seinen Kernel neu? Wie viele Linuxer können den schon genau sagen, welche Optionen im Kernel tatsächlich sinnvoll sind, und welche nicht? Mal ganz ehrlich: Weißt du, was CONFIG_NO_HZ (aka dynticks) genau bewirkt, und ob bzw. wann das Setzen dieser Option sinnvoll ist?
Nur fordert einen niemand penetrant auf, die Bedeutung der Konfigurationsoptionen zu lernen, um das System zu verstehen.
Die meisten Linuxer kommen gut ohne dieses Wissen aus, genauso wie die meisten Windowsianer ohne Symlinks auskommen.
Nebenbei stellt sich die Frage, ob es für einzelne Software-Entwickler wirklich sinnvoll ist, ein bestimmtes Feature zu propagieren, wenn der Hersteller selbst dieses Feature offensichtlich nicht unterstützen will. Es ja auch nicht so, als wären symlinks das Killerfeature schechthin, um multiple Shares zu implementieren. Im Gegenteil, alternative Ansätze sind kaum komplexer in der Implementierung, skalieren besser (siehe unten) und sind weitaus portabler.
Man baut Funktionalität nach, die mit Symlinks schon vorhanden ist. Genauso wie eben mein Beispiel mit den Sprachen von Webseiten.
Nicht alles lässt sich gut mit Symlinks abbilden. Jede Art von Metainformation, die über den eigentlichen Namen hinaus geht, kann man in einer Implementierung mit symlinks kaum sinnvoll unterbringen.