Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
hype. (Score:0, Redundant)
|
|
|
|
|
|
|
|
naja, was will man mehr sagen? *g*
|
|
|
|
|
| |
|
|
|
|
Von Anonymer Feigling am Friday 05. September, 21:29 MES (#3)
|
|
|
|
|
ja beos hat beim filesystem doch recht viele möglichkeiten eröffnet aber sie wurden auch von sehr wenigen programmen wirklich ausgenutzt, vor allem die beos eigenen programme wie das email und das contact programm.
auch die mp3's konnte man so richtig schon verwalten durch die flexibel erweiterbaren und veränderbaren attributen, nach denen dann gezielt gesucht werden konnte.
naja, vielleicht wird sich ja ein system auf basis einer datenbank eher durchsetzen (ist das nicht die idee hinter dem longhorn fs?) aber für das hab ich dann auch wieder zuwenig ahnung von all dem :-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja ich hab das auch so gehört das Longhorns FS eine Datenbank darstellen soll. Und wenn ich mein Filesystem so anschaue kann ich mir durchaus vorstellen das die ein echte Revolution darstellen könnte. Alleine schon das ewige suchen nach Dateien wird ein ende haben. Man stelle sich vor das vielleicht sogar eine Checksumme automatisch im FS abgespeichert wird. Wie viel einfach können wir dann p2p software benutzen, oder auch für mp3's ein echter Fortschritt...
Hoffentlich skalierts auch gut und hoffentlich gibts eine neues Netzwerkshareprotokoll dafür das die Vorteile auch übers netzwerk nutzen kann.
und wenn wir schon dabei sind, non blocking IO könnten sie gleich auch noch einbauen (hoffentlich auch für CD's usw) (naja man darf ja wohl noch von Fortschritt träumen)
|
|
|
|
|
|
|
|
|
Von kruemelmonster am Saturday 06. September, 08:56 MES (#5)
(User #3 Info)
|
|
|
|
|
Die Hierarchie aus dem Dateisystem zu entfernen finde ich ne gute Idee. Vor allem, wenn man das ganze dann DB-Artig aufbaut!
Für die präsentation für den User könnte man dann immer noch ein Hierarchisches Format wählen. Denn die Darstellung für den User muss ja nicht zwangsläufig damit übereinstimmen, in welcher Struktur etwas gespeichert wurde.
So könnte ich z.B. nen mp3 von Whitney Houston die attribute "sound", wie auch "Whitney Houston" geben. Wenn ich dann noch n Bild von ihr hab, geb ich dem die Attribute "image" und "Whitney Houston".
Wenn ich nun in's "virtuelle Verzeichnis" "sound" wexle, so sehe ich alle dateien mit dem attribut "Verzeichnis" Whitney Houston wexle, so finde ich dort sowohl das Bild wie auch das MP3...
Ich stelle mir vor, dass ein solches Verfahren viele Vorteile bergen könnte, WENN die Attribute denn auch gesetzt werden ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
solange ich die attribute nicht von hand setzen muss.
Das BeOS FS hat mich ebenfalls sehr beeindruckt. Diese Attributgeschichten finde ich gut, wenn die Programme das nutzen können, so dass ich bei einer suche im FS z.b auch mails, mp3 (id3 tag), etc finde - obwohl der suchbegriff sich nicht im dateinamen befindet.
Ein Filesystem ohne Hierarchie kann ich mir allerdings nur schwerlich vorstellen. Schliesslich verstaue ich meine gentoo cds auch nicht irgendwo im Garten. Nein, sie sind im Haus, in einem Raum X, im Möbel Y, in der Schublade Z.
IMHO ist Hierarchie ganz gut und entspricht eigentlich der 'Natur'
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 06. September, 11:28 MES (#7)
|
|
|
|
|
db ja, ohne hierarchie nein danke. Das is was für Anarchisten.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich halte es für sehr schwer Attribute (bzw. jede Technik, die über den Stand der letzten Jahre hinausgeht) durchzusetzen -- dazu müssten sie nämlich ersteinmal auf den wichtigsten Systemen relativ einheitlich zu benutzen sein.
Mal als negativ-Beispiele:
OS/2 hatte schon lange ein Dateisystem mit beliebigen Attributen, die allerdings so gut wie nie genutzt wurden.
Mac OS hatte ebenfalls lange besondere Attribute, bei OSX ist nun fast der Rückschritt erreicht und Datetypen werden (neben dem Attribute-System) doch wieder über ihre Namensendung zugeordnet...
|
|
|
|
|
|
|
|
|
|
|
|
|
Man hat sich halt an Dateiendungen gewoehnt - auch
als nicht-Windows-Nutzer, und es ist einfacher.
Die Endung ist sofort im Blick, und ein Attribut
ist es nicht.
-- mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
Also, das klingt nach einem Riesenchaos. Neenee... nix für mich, danke. Es gibt locate und find, damit finde ich alles, wenn ich mal was nicht finde. Aber meistens find ichs schon. --
Den Symlink-Autoren bei der Arbeit zuhören? MP3 hier
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich sage nur: WENN das Wörtchen WENN nicht wär, wären meine Daten auch jetzt mit ext3 perfekt organisiert. Einigermassen sind sie schon, aber auch mit erweiterten Attributen etc. wäre das nicht anders...
|
|
|
|
|
|
|
|
|
|
|
|
|
Auf Dateisystemen wie 4.4BSD LFS und den ganzen
journalled fs von Linux werden die Daten intern
oft (besonders bei LFS) nicht mehr intern als
"traditionelle" Hierarchie mit Trennung Superblock,
Verzeichnisse, Daten abgespeichert.
LFS zum Beispiel schreibt einfach alles zusammen
in die Bloecke und macht dann (lfs_cleanderd(8))
eine garbage collection.
-- mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
Am besten wäre es wenn ich eine normale Hierarchische Strukur hätte, aber auch gleichzeitig die Möglichkeit habe, so schnell und effizient wie in einer Datenbank, Dateien zu suchen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dafür gibt es derzeit ja "locate"(in findutils-locate zu finden).
Locate liesse sich evtl erweitern, damit änderungen im fs auch sofort in die locatedb wandern
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Hirarchische Struktur ist nicht schlecht und ist für viele Dateien sicherlich geeignet. Sprich, was brint es mir, wenn ich Programmdateien besser finde. Aber bei den Benutzerdaten könnte das sicherlich vorteilhaft sein. Je grösser unsere Datenbestände sind desto mehr muss mit suchen gearbeitet werden. Es ist mir auch schon aufgefallen das ich Dinge einfach mal bei Google gesucht habe, weil es eben schneller zu finden ist, als auf der Festplatte. Ganz klar liegt hier noch einiges an Verbesserungspotenial.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 07. September, 15:38 MES (#12)
|
|
|
|
|
Da wurde es allerdings relativ geschickt vorm Benutzer verborgen und es waren eher die Programmierer die Vorteile davon hatten da das Mitbenutzen von Daten anderer Programme so zum Kinderspiel wurde.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich halte das alles fuer Quatsch. UFS FFS mit
Softupdates ist ein Dateisystem, das bei absoluter
Daten- und Metadatensicherheit hinreichende Per-
formanz bietet. Und wer zu doof ist, seine Dateien
unter $HOME/ zu organisieren, gehoert IMHO nicht
vor einen Computer.
Fuer alles auszerhalb $HOME gibt es den FSSTND
bzw. FHS (GNU), und man 7 hier (UNIX).
-- mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
...ist keine allzuneue Erfindung. Eigentlich waren alle Systeme vor der "Erfindung" der Verzeichnisstruktur so. Egal ob DOS 1.0, IBM SSP etc. ;-)
Ein System wird heute noch verkauft, das teilweise nach diesem Grundsatz funktioniert - die AS/400. Es gibt eine Ebene, vergleichbar mit den Datenbanken in einem MySQL-Server. Der Effekt ist simpel - die Applikationsentwickler finden sich nicht zurecht und IBM musste vor einigen Jahren ein hierarchisches Filesystem einbauen...
Stellt Euch vor was passiert, wenn /usr/src/linux/* ploetzlich keine Hierarchie mehr besitzt sondern ein loser Haufen von Sourcefiles darstellt. Sicher ist es nett, das File mit den Keywords "3Com", "Netzwerk", "Treiber", "Becker" zu suchen. Aber gerade bei den Leuten, die so etwas programmieren, ist die Hierarchie so tief verwurzelt, dass sie mit einer solchen Loesung schlicht nicht arbeiten koennten.
Andererseits interessiert es die Durchschnittssekraetaerin nicht, wie ihre Files abgelegt sind. Weil - sie druckt eh alles aus und legt eine Papierkopie im Schrank ab *schauder*
I saw screens of green, red messages too, then came blue, shubidu And i think to myself, what a wunderful world
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vorallem frag ich mich, was die beiden Merkmale "Hierarchielos" und "Keywords, Suchfunktionen à la DB" miteinander zu tun hat. Die Idee an sich, das Filesystem auf DB umzustellen find ich nicht so schlecht, da die Suchfunktionen etc. sicher ganz überzeugend sein können. Nur kann man auch mit der Lösungen noch Hierarchien abbilden, wenn halt einfach nur emuliert und nicht à la FAT-Hierarchie.
Aber was spricht dagegen, das ganze auf DB umzustellen und die Hierarchie über Attribute abzubilden, so dass das OS die Hierarchie anzeigt, diese aber nicht aus FAT, sondern aus der DB ausliest ?
Oder versteh ich das falsch ?
Natuerlich schaudert mich bei der Idee, dass ein kleiner Bug in der DB mir die ganzen Daten ins Nirwana schicken kann. Bei FAT kann ich noch auf diverse Mittel zurueckgreifen, und das System ist verbreitet. Windows würde da wohl auf die Engine von SQL Server zurueckgreifen, ob da andere Hersteller noch einfach so locker Rescue-Tools programmieren könnten ?
|
|
|
|
|
|
|