Diskussion:Everything is a file

Absolut falsch und irreführend

Dieser Artikel ist absolut irreführend und hat in keinster Weise was mit UNIX(TM) oder Unix zu tun (und wurde deshalb auch offensichtlich nicht in andere Sprachen übersetzt). Wer so etwas schreibt, sollte sich vorher informieren, was UNIX tatsächlich ist/"definiert" - via http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm könnte man einsteigen.

Dieser Artikel ist bereits größtenteils eine Übersetzung des englischen Artikels. Ich frage mich auch, was dir Anlass zur Vermutung gibt, der Autor wüsste nicht, was Unix sei? --Artistoex (Diskussion) 13:05, 6. Okt. 2016 (CEST)

Und BTW, nur weil ein "file descriptor" als handle auf entsprechende Speicherstrukturen benutzt wird, heißt das noch lange nicht, daß damit auf eine Datei zugegriffen wird - der Schluß von "file descriptor" auf "file" ist also absolut falsch. Oftmals ist ein file descriptor sogar nur eine 32 oder 64-bittige Zahl, also ein ganz normaler Zeiger auf irgendwas im Speicher und somit in keinster Weise etwas besonderes, geschweige denn UNIX oder Unix spezifisches! Irgendwelche Fakten einfach in 'nen Mixer zu werfen und das entstandene Gebräu als "State of the art" zu deklarieren, sollte IMHO nicht Wikipedias Anspruch sein.

Aus reiner Anwendersicht mag die Vorstellung, dass ein Gerät, oder gar eine TCP-Verbindung, als Datei repräsentiert ist, verwirrend sein, aber es ist tatsächlich so. Unter Unix ist das Konzept "Datei" einfach weitergefasst, als es vielen Anwendern bewusst ist. Filedescriptoren unter Unix sind keine Zeiger, da hättest du dich vielleicht selber bei der von dir oben angegebenen Quelle informieren können. Es sind sehr kleine, ganze Zahlen, die vom Betriebssystem in aufsteigender Reihenfolge an einen Prozess vergeben werden. Im Artikel wurde das auch nicht als "State of the art" ausgegeben (obwohl es das durchaus ist, schließlich laufen auf praktisch allen mobilen Geräten unixoide Systeme). --Artistoex (Diskussion) 13:05, 6. Okt. 2016 (CEST)

Deshalb sollte dieser Artikel sollte ersatzlos gestrichen werden. (nicht signierter Beitrag von 84.140.12.98 (Diskussion) 13:09, 10. Jul 2016 (CEST))

Nachteile

Im Artikel steht nur: "Der Vorteil dieses Ansatzes ist, dass..."

Es wird jedoch nirgends erwähnt, ob dieser Ansatz auch Nachteile mit sich bringt. Vermutlich ist der Verwaltungsaufwand (Overhead) größer. Da man einer Zahl (z.B. 3) nicht ansieht, für was sie steht, muss der Kernel bei jeden read()-Aufruf zunächst aufwändig die Dateideskriptor-Tabelle durchforsten, um herauszufinden, welches physische Gerät sich hinter diesem Dateideskriptor verbirgt und dann entsprechend den zugehörigen Treiber laden.

Eine effizientere Alternative könnte es sein, beispielsweise die Deskriptoren 0-1000 für reguläre Dateien zu reservieren, 1001-2000 für Netzwerk-Sockets usw. Dann könnte man an der Größenordnung der Zahl sofort ablesen, für welchen Gerätetyp sie steht. --141.30.247.185 12:30, 29. Feb. 2024 (CET)

Nö, wird nicht mit Nachteilen erkauft.

Ist einfach nur eine einheitliche Schnittstelle für alles.

Andere Konzepte müssen dann für jede Konstellation eine eigene Schnittstelle definieren und separat implementieren.

Wenn bei umseitig die Umsetzung auf die Eigenart des physischen Gegenstücks erstmal erfolgt ist, kann der komplette restliche Code wiederverwendet werden. Ist nur einmal vorhanden, einen tic effizienter im Speicher (heutzutage bedeutungslos) und leichter zu pflegen.

Jede Implementierung benötigt irgendeinen Verwaltungsaufwand; der ist für Dateideskriptoren auch nicht größer. Auch jedes andere Konzept muss sein Zeugs irgendwie verwalten.

Durch vereinheitlichte Schnittstelle statt mehrerer unterschiedlicher ist es eine Win-Win-Situation. Gut für Anwendungen, gut für Kernbeißer.

VG --PerfektesChaos 13:41, 29. Feb. 2024 (CET)