Wie will Gobo Linux da mit umgehen, dass viele Programme essentielle Libs und andere mehrfach genutzte Dateien mitbringen? Die werden dann x-mal installiert und fressen so jede Menge Platz. Erscheint mir nicht gerade intelligent.
Apple setzt auf "Frameworks" die in /Library bzw. in ~/Library residieren. Damit können auch mehrer Applikationen die gleichen Frameworks nutzen. Natürlich ist dies nur ein Teil der Wahrheit und beziet sich nur auf die nativen Cocoa Programme. Darunter verbirgt sich das Unix Derivat "Darwin", dass genau wie Linux oder jedes andere *nix ähnliche System auf die bewährte /etc, /usr etc Struktur aufbaut.
Die einzelnen Graphischen Programme sind in sogenanten Bundles zusammengefasst. Bundles sind nichts anderes als Ordner die das System als Programme erkennt. In den Ordner sind dann alle weiteren Resourcen die ein Programm benötigt enthalten. Es ist sogar möglich binaries für mehrere Architekturen hinzuzufügen. So giebt es Programm-Bundles die sowohl für PPC wie für Intel und zusätlich für 32Bit und 64Bit kompilliert wurden und somit 4 binaries enthalten.
Wenn ein Programm Frameworks installieren will wird meistens ein Installer für das jeweilige Programm verwendet, wenn alle Resourcen nur in einem Application-Bundle vorhanden sind, kann der Ordner einfach in /Application kopiert werden und durch anklicken verwendet werden.
OSX nutzt einerseits das 'Traditionelle' System, biegt aber andererseits eine BSD-Struktur darauf um. Dann gibt es App-'Archive', die im BSD-Userland aber als Ordner erscheinen. Und nebenbei gibt es noch ein haufen Installationsroutinen, die ihr Zeugs einfach irgendwo hinschmeissen. Ein Sauberer Automatismus zur Verwaltung von dem ganzen Schrott existiert sowieso nicht. Einmal installiert, müllt es die Platte voll, niestet sich irgendwo in $LIBARY oder $USER oder $ETC ein und verteilt seine Binarys über $APPLICATION, $USR, $OPT und was nicht alles (PrefPanels landen sogar in $LIBARY!).
Alleine schon der Schwachsinn ständig mehrere Strukturen parallel zu nutzen ist bei OSX schon sehr grenzwertig. Im vergleich dazu ist selbst ein Windows-System Sauber und durchschaubar. Und dabei sprech ich nur von der Standardinstallation. Mit MacPorts oder Fink wird das ganze noch interessanter. Da wird gleich mal noch mal das halbe Userland neu Kompiliert, weil vorhandene $LANGUAGE-Interpreter nutzen geht ja nicht, da muss schon was eigenes her
Wenn die Programme nicht statisch gelinkt sind(was ich mal hoffe) und die Sache nicht mit Abhängigkeiten gelöst wird(z.B. über den Paketmanager), dann sind fast alle Programme auf einen solchen System betroffen. Ich finde nicht, das GaboLinux eine bessere Lösung gefunden hat.
Der Einwand gilt nicht, da das Problem auch alle FHS-Distributionen haben und nicht nur Gobo Linux. Das Verhalten seitens des Systems ist das selbe wie bei allen Distributionen (Links von einem zentralen Lib-Verzeichnis auf die entsprechenden Bibliotheken). Der dynamische Linker arbeitet also genauso wie bei anderen.
Die Frage war, ob es das oben beschriebene Verhalten gibt. Denn ich vermute, dass so etwas kaum passieren wird und wenn ja, dann ist es ein Design-Fehler einer Applikation und kann auch vom FHS nicht abgefangen werden. Deshalb die Frage nach einem konkreten Beispiel.
Eigentlich auch egal. Die Macher von Gabo-Linux halten an ihren Konzept fest, da es ein Alleinstellungsmerkmal ist. Ich finde es gut, das sie es mal anders machen, aber dennoch wirkt das Ganze auf mich etwas krank. Heutzutage würde auch auch niemand mehr eine Datenbankanwendung neu entwickeln und eine hirachische Datenbank verwenden. Vielleicht gibt es ja mal eine vernünftige Lösung(vielleicht vor dem Jahr-2038-Problem), vielleicht ja mit einem Filesystem, welches das gewisse Extra hat, auch wenn es so völlig Unix-unlike ist..
die dateien werden auf platte gespeichert, und mit tags versehen. und die tags in einem katalog versehen. bei den ganzen online-bookmarkdiensten sowie blogs setzt es sich immer mehr gegen hierarchiche strukturen durch.
Das würde sogar Katalogsysteme und lokale Suchmaschinen zum teil überflüssig machen.
Tags erfordern einen sehr hohen Aufwand und sehr viel Disziplin. Schau dir mal Googlemail an, die arbeiten mit Tags statt Mailordnern. Im Endeffekt nicht überschau- und damit nutzbar.
Von Patrick Willam am Di, 19. August 2008 um 20:03 #
Überschaubarkeit ist Sache einer passenden -- i.S.v. möglichst brauchbaren -- UI, die dann natürlich vor die zugrundeliegende Technik gespannt gehört.
Aufwand hängt von der Komplexität und Vielgestaltigkeit der Daten ab, die es zu verwalten gilt, nicht davon, ob ich die Daten etikettiere oder hierarchisch ordne. Im Gegenteil ist es eher so, daß ich mehr Aufwand treiben muß, um eine Hierachie für alles zu entwickeln und zu pflegen, als wenn ich die Qualität der Daten per Etikettierung handhaben kann.
Aufwand und Disziplin braucht man vor allen Dingen, um die mangelnde Unterstützung seitens der UI auszugleichen, wenn es darum geht, Daten anhand ihrer Qualität entsprechend einzuordnen.
Dateiauswahldialoge sind ja heutzutage [fast] die gleiche Katastrophe wie seit ihrer Erfindung. Der beschriebene Aufwand und die Disziplin bleiben ja bisher immer noch am Nutzer hängen, der den passenden Zielordner finden muss. Welcher Dateiauswahldialog macht denn passende Vorschläge für Zielordner, wenn es darum geht ein Dokument oder ein Video abzulegen?! Habe ich bisher weder gesehen noch davon gehört!
Für mich ist es ideal, und für meine Freundin auch. Und so schlimm ist das Taggen nun auch nicht. Besser als Ordneransichten, wo schon bei simpelsten Aufgabenstellungen Ablageprobleme auftauchen. Wie legt man ab? Projektweise? Was ist, wenn sich in den Mails mehrere Diskussionsfäden vermischen? Etc. pp. Tagging ist mE die Ablageform der Zukunft.
Tags sind nichts anderes als ein Index, ein Index nicht viel mehr als eine Registry. Es soll ja Systeme geben, die sowas schon sehr lange erfolgreich einsetzen. Das ist das Gegenteil der Dateihierachie, was ja nicht schlecht sein muss. Viele Leute finden aber die Einfachheit der Hierachie verlockender als die Vorteile des Indexes.
"Ich finde nicht, das GaboLinux eine bessere Lösung gefunden hat."
Erstens heisst es GoboLinux. Zweitens kannst du genausogut statisch gelinkte Binaries verwenden. Und wenn es shared libaries sind ist die Verzeichnisstruktur genauso egal. Die Argumente dagegen sind so lächerlich. Meine Festplatte ist rund 200 Gig gross, grep sed m4 make coreutils und noch ein paar hab ich immer statisch. Und dazu noch busybox (auch statisch, das geht sogar mit glibc. Die busybox Entwickler sind wirklich sehr gut.)
Drittens hast du einen riesigen Vorteil von GoboLinux nicht beachtet: Multiple Versions. Du hast GoboLinux nicht probiert, ansonsten hättest du ihn erwähnt denn jeder der zwischen verschiedenen GCCs wechselt nur anhand der Verzeichnisse wird kaum mehr auf /usr/bin vs /usr/local/bin Chaos zurückgreifen.
Viertens hast du nicht beachtet das die klassischen Unix Varianten nicht vorwärts kommen. Da mag man Gobolinux kritisieren wie man will - probier halt NixOS aus. Oder bastel etwas neues mit einer eigenen Idee.
Fakt ist das die Ideen fehlen. (Und die Umsetzung der Ideen)
Und was machst du bei Sicherheitsupdates? Wenn beispielsweise der DNS-Resolver eine Sicherheitslücke hat, darfst du dann mal eben sämtlichen netzwerkfähigen statischen Binaries austauschen ... Oder hast du eine praktikabel Lösung dafür?
Die Antwort: Symlinks - Merke: erst lesen und dann posten.
Das Konzept erinnert mich allerdings ein wenig zu sehr an Windows, wenn auch mit einigen Verbesserungen. Ich halte es dennoch für überflüssig, das Problem der Paketverwaltung auf das Dateisystem auszulagern. Ein ähnlicher Ansatz wurde von Zero Install versucht, ohne dass sich dieses System auf breiter Ebene durchgesetzt hätte.
Der Ansatz hat zumindest einen ganz großen Vorteil: eine neue Generation von Anwendern, die sich nicht stundenlang mit dem System auseinandersetzen wollen, können sich in dem System zurechtfinden. Das sollte man nicht unterschätzen.
Knoppix brachte die Leute in problemlose Berührung mit Linux, Ubuntu brachte die Leute Linux auf den Rechner und Gobo-Linux bringt den Leuten den Systemaufbau näher.
das sehe ich anders - zentrale paketmanager sind der größte vorteil von linux: * einfache installation von programmen * einfache updaten von programmen (nicht x verschiedene update-routinen) * zuverlässige quellen, automatische prüfsummenkontrolle * shared-libraries * rückstandsfreie deinstallation * eineinander abgestimmtes system * kein nerviges googlen, downloaden, installieren (tja..wer das mag, soll rhel 4 nutzen)
ohne zentrale paketmanager hätten wir das windows-chaos mit fetten binaries und alle 2 jahre neuinstallation.
[] du hast dir die verlinkte gobolinux-seite angeschaut
es ist eben nicht wie bspw. teilweise unter win geregelt (auch da gibts dynamisches linking), sondern das /programs bezieht sich auf jedes paket, und damit auch auf die lib-pakete die dann z.b. unter /programs/gtk-2.6.X liegen. ganz so dumm ist das nicht.
> [x] du hast dir die verlinkte gobolinux-seite angeschaut
Welchen Vorteil bringt mir das noch, wenn jedes Packet in ein eigenes Verzeichnis installiert wird? Die Abhängigkeiten der Pakete bleiben bestehen. Dafür schwillt mir die ld.so.conf extrem an. Das macht den dynamic linker auch nicht gerade schneller.
Sorry, aber das ist vollkommen irrelevant, aus mehreren Gründen:
1.) herkömmliche HDs kommen schon in den Terabytebereich, Platz ist demnach irrelevant 2.) verbrauch libs nicht so viel an Platz. 3.) können parallel Versionen genutzt werden, was sehr oft sehr große Vorteile liefert (z.B. habe ich zwei unterschiedliche Versionen von gnumeric gebraucht, da jeweils ein Bug vorkam, der mich störte 4.) Ist eien Deinstallation viel einfacher. bei diesem Thema Was mich viel mehr interessieren würde, was ist der Unterschied zu BSD/Mac? Ich schreibe gerade von einem Mac (10.5), und dort ist das schon lange Usus).
1) und die meisten Leute haben keine solchen Monster - und wenn wollen sie den Platz anderweitig nutzen. 2) ach wirklich? > 1,5G /usr/lib64 3) andere Distris können das auch - mit einer fast-Standard Struktur! (gentoo+slots zb) 4) um die Deinstallation kümmert sich der pkgmanager, kann also dem Anwender egal sein.
1,5 GB? Wo ist das Problem? 250-500 GB dürfte mittlerweile der Großteil haben, platz satt. Vor allem hängt es ja auch mit der Nutzung ab, was man alles installiert.
Paketmanager ist ja ok, aber warum nicht den Komfort haben einfach Programmpfad löschen = Deinstallation?
Das glaubst du wohl selbst nicht, dass die Distri ganz ohne dafür zuständige Applikationen auskommt. Für was gibt es wohl da CreatePackage, PrepareProgram oder SymlinkProgram?
Einer der großen Vorteile von Linux ist ja, dass das System schlank ist.
a) Es gibt noch viele, die mit alten Rechner <1Ghz arbeiten. (Teilweise sich auch keinen leisten können.)
b) Linux am PDA und Handy muss so schlank wie möglich sein.
Für beide Beispiele wären doppelte Libs oder Ähnliches nur schlecht. Außerdem wäre eine Eigenentwicklung für mobile Geräte wieder eine Teilung und damit verbundenes Anpassungsproblem für Entwickler! (Um genau das geht es ja bei dem genannten Standard )
ladezeiten! je größere die binaries, desto langsamer. aber wer achtet schon darauf wenn er 500gb hdd und quad core hat?
außerdem..schon mal aufgefallen, wie angenehm es ist, wenn alle config-files in /etc liegen? einfach ein 'dvcs deiner wahl'-repository deiner wahl dort anlegen und man hat es wesentlich einfach, wenn eine config verbockt wird.
und ein argument für paranoide: /usr read-only mounten, änderbare-daten nach /var (ist auch allgemein empfehlenswert aufgrund der fs-fragmentierung)
Ich finde die Ansicht "wir ham ja Platz, also immer weg damit" ziemlich irrwitzig - ich will den Plattenplatz für das nutzen, wofür ich auch den Rechner nutze: zum Arbeiten. Platzverschwendung ist auch in Zeiten von TB-Platten einfach nur Verschwendung. Anwendungsdaten werden ja auch immer größer (Stichwort HD-Video) -> nur macht es da Sinn.
Und für Geräte mit begrenzten Ressourcen (embedded Bereich, Router u. ä.) verbietet sich eine solche Einstellung von selbst. Oder willst Du eine 100GB-Flash-Disk kaufen, nur weil Du schon die Hälfte fürs OS brauchst?
Andere Frage: Wie geht denn Gobo-Linux mit veränderlichen Dateien um? Liegen die auch in den Programmverzeichnissen (Konfigs, Logs, temp. Dateien ...)? Wo liegen anwenderspezifische Konfigs?
Ich nehme mir ein paar Vorteile, wenn ich alles an einen Platz packe: Ich kann kein FS mehr read-only mounten und z. B. unter die Kontrolle eines IDS stecken (Sicherheit), Delta-Backups werden deutlich aufwändiger, weil immer der gesamte Baum durchsucht werden muss, Systemüberwachung wird unübersichtlicher, weil ich die Logs überall zusammensuchen muss, ... Dann geht nämlich Platzverbrauch über in allgemeinen Ressourcenverbrauch, weil dann auch Prozessor, I/O-Controller usw. mehr Arbeit haben.
Und wie steht es mit Security-Patches? Nimm eine Situation wie neulich die sshlib-Lücke in Debian: Fängst Du dann an zig statisch gegen die Lib gelinkte Programme auszutauschen und ebenso viele dynamisch gelinkte, die alle die Lib in ihrem Baum haben?
Platz ist zwar irrelevant geworden, aber was Unix-Systeme verschlafen haben sind die austauschbaren Medien. Früher war alles mehr oder weniger fest gemounted, der User durfte Dateiträger nur sehr umständlich hinzufügen bzw. abziehen. Heute sind USB-Disks aller Art auf dem Markt. Da verspricht der Ansatz, ein Programm in nur ein Verzeichnis zu packen einen guten Ansatz. Disk einstecken und schon dürfte das Programm auf der Disk funktionieren.
Trotzdem sollten alle Konfigurationsdateien in einem Verzeichnis verbleiben und Konfigurationsdateien die Hardwarezugriffe enthalten sollten in einem gesonderten Verzeichnis verbleiben - das wäre schon für die Softwareverteilung in kleineren Installation sehr sinnvoll.
Trotzdem sollten alle Konfigurationsdateien in einem Verzeichnis verbleiben und Konfigurationsdateien die Hardwarezugriffe enthalten sollten in einem gesonderten Verzeichnis verbleiben - das wäre schon für die Softwareverteilung in kleineren Installation sehr sinnvoll.
Die Konfigurationsdateien kommen ja wieder in ein Verzeichnis wenn ich das richtig Verstanden habe.
Allerdings sind das dann eben "nur" Symlinks. Also z.B.:
Ich persönlich finde aus Sicht eines (einfachen) Desktopanwenders die Apple-Variante ganze gut bzw. fast am besten. Da muss sich der Anwender am wenigsten Gedanken machen, das Programm kann einfach kopiert, verschoben oder eben gelöscht werden. Ganz ohne Paketmanager oder Software-Deinstallieren-Dialog.
Nur eine Vermutung, aber ich würde mal sagen, dass bei einem Systemupdate einfach nur das Programmverzeichnis, z.B. /programs/sshd/ aktualisiert wird. Der Symlink unter /etc deutet dann immer auf die Konfiguration der aktuellsten installierten Version.
Hm... werde mir das System mal nach der Arbeit genauer ansehen....
Das Problem mit den mehrfach installierten libs ist nicht unbedingt der Speicherplatz. Aber wenn in einer mehrfach installierten lib ein Fehler gefunden wurde, reicht es z.B. nicht diesen einmal zu beheben, sondern jedes Programm das diese Bibliothek benutzt muss ein Update erhalten.
Von Eben das ist der Vorteil am Di, 19. August 2008 um 19:34 #
Da nicht klar ist ob das Bugfix dann noch läuft sollte es nicht automatisch alle Dinge austauschen. Als kommerzieller Softwareentwickler (der kostenlos Support leisten muss) ist das ein absolutes No-Go.
Ich bestimme mit welchen Libs mein Program läuft. Wäre ja noch schöner wenn ich da Zeit investiere und mir nach der 10ten Email der Typ sagt, er hätte da mal libxyz getauscht.
Wenn es bekannte Probleme gibt => Hersteller anrufen => Hersteller muss austauschen, ansonsten mit dem Probleme weiterleben und von Hersteller künftig nicht mehr kaufen.
Die Systemfiles sind dann unter /Winnt und das Userverzeichnis wird /Dokumente und Einstellungen.
Ich sehe da keinen Sinn darin, ausser dass man zum Exot wird der alles wieder anders macht. FHS ist definiert und so unübersichtlich ist das auch nicht, man weiss dann in jedem Linux was wo ist, zumal sich daran jeder schon gewöhnt hat.
Die Medaille hat wie immer zwei Seiten. Hat man sich an FHS gewöhnt, ist das Handling Ok. Verwirrend ist es trotz allem. Am besten zu sehen bei der X11-Implementierung, wo jeder Distributor was anderes macht. Nicht zu reden von selbscompilierten Applikationen. Mittlerweile habe ich es mir angewöhnt diese immer in ein separates Verzeichnis unter /opt abzulegen. So ist es einfacher sie wieder los zu werden.
Bei RHEL (ob in Fedora auch, keine Ahnung) liegen viele www-Inhalte in /usr/share und werden durch eine entsprechende Config dem Apachen bekannt gegeben. Da kann man sich noch mehr den Wolf absuchen...
2.3: This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
Btw: Fedora und Redhat sind was die FHS angeht auch nicht konsequent... Es gibt zwar ein /srv, dies ist aber per default leer. Auch zeigen die DocumentRoot und andere Dinge nach /var/www.
/srv ist einfach nur krank! /var gibt es nicht ohne Grund. Aber hey, mit jeder neuen Version ein bißchen Veränderung und Schwachsinn und schon funzt nichts mehr. Das macht dann die Standardisierer so richtig glücklich.
Tja, es gab mal ein Konzept bei der Aufteilung der Dateien unter Unix. Das war auch eine Weile ganz praktisch, aber mittlerweile blickt doch keiner mehr durch und wir brauchen locate, find und andere Indexierungsprogramme, um einen Überblick im System zu behalten.
Der FHS-Standard sollte nicht von den bestehenden Systemen ausgehen, sondern sich überlegen, wie die Zukunft aussieht. Globale Filesysteme, Wechselmedien, geringere Verständnishürden, ... Solange Konzepte aus den 70ern aufgekocht werden ist es immer die gleiche Suppe die uns vorgesetzt wird. Jetzt aber mit Kräutern und Knoblauch...
Von Schwachfuger am Di, 19. August 2008 um 14:13 #
srv mag krank sein, aber Webinhalte oder Datenbanken nach /var zu schieben, schlimmer noch nach /var/lib (libs haben in var schon mal gar nix zu suchen und content sind eh keine libs) ist an Dämlichkeit nun nicht mehr zu unterbieten.
/var für Anwendungsinhalte zu nutzen war ein kaputter und unbeholfener Versuch, geprägt von der Feigheit, ein neues Vereichnis (wie eben /srv) einzuführen, einen Ort für Content zu finden.
Die Frage war also, wo gehören Anwendungsinhalte hin? apache ging mit seinem docroot früher nach /usr/share. Passte nicht so wirklich. Dann kam /var/(lib), warum auch immer, und irgendwann hat jemand mal srv eingeführt. Welchen Zusammenhang aber Logs, Status/Laufzeit- oder Spooldateien oder andere, variable Systemdaten mit Anwendungsdaten haben sollen, bleibt wohl ein ewiges Geheimmis. Genausogut hätte man /etc oder /tmp nehmen könnenm wäre genauso deplaziert gewesen.
Andere gehen nach /home, mit der Logik, daß das document root ja die Daten vom Anwender apache sind, oder postgres eben die Daten von der gleichnahmigen Datenbank. Auch wenn diese im Gegensat zu joe nicht interaktiv ist.
Insofern ist srv gar nicht so schlecht, aber die Masse der Pseudotraditionalisten ist wohl zu laut. var ist inhaltlich auf jeden Fall varnsinn. Und ignorant oben drein
das hatte windows ja unzweifelhaft vor linux - wenn auch nur für eigenhändig nachinstallierten kram das ist aber nicht so wichtig. viel wichtiger ist dass sich offenbar leute gedanken machen über den status quo, der tatsächlich verbesserungswürdig wäre. eine wirkliche lösung dieser misere bringt wohl erst das noch nicht existierende SFS (Semantic Filesystem) in dem das binary 'konqueror' mit den tags 'konqueror,kde,binary' irgendwo auf der platte verstaut wird, während die manpage dazu die tags 'konqueror,kde,manpage' erhält und ebenfalls irgendwo liegt wo sie anhand der tags wiedergefunden wird. überflüssig zu erwähnen dass ich mich schon wie ein schnitzel auf die nepomuk-integration in KDE freue
>überflüssig zu erwähnen dass ich mich schon wie ein schnitzel auf die nepomuk-integration in KDE freue
Dieser ganze semantische Kram wird nicht funktionieren:
1. Weil irgendjemand sich die Mühe machen muss und *alle* Dateien / Programme etc. erstmal taggen muss.
2. Weil unterschiedliche Menschen ein und dieselben Daten unterschiedlich taggen werden / würden. Ist der Konqueror jetzt ein Webbrowser, ein Filemanager oder beides? Ist das von der KDE-Version abhängig? Und, mir fallen auf Anhieb ca. 10 Möglichkeiten ein, wie man "AC/DC" falsch bzw. anders schreiben könnte ...
2. Wenn ich nicht 100%ig sicher sein kann, dass alle meine Inhalte mittels semantischer Tags erfasst sind, muss ich *immer* noch auf eine rein syntaktische Suche zurückgreifen da ich nie sicher sein kann, ob das gesuchte etwas der semantischen Suche vielleicht durch die Lappen gegangen ist. Ergo: Dopplete Arbeit ohne Sinn.
Naja, den Vergleich finde ich jetzt ein wenig übertrieben.
Solch ein System kann sehr gut funktionieren, wenn alles richtig getagt ist und auch entsprechend gepflegt wird.
Umso mehr verschieden Personen allerdings in dem System "herumpfuschen", umso schwieriger wird es, das System einheitlich und gepflegt zu halten. Und wenn man das nicht schafft, dann kostet das System viel mehr Zeit als eine Klassische Verzeichnisstruktur z.b.
Ich arbeite hier in der Firma mit Dokument-Verwaltungssystemen, welche ebenfalls die Dokumente durch Tags kennzeichnen damit man diese einfach wiederfinden kann - und ich wäre in der Zwischenzeit froh, wenn wir es nicht mehr verwenden würden...
Wie heißt es so schön: "Viele Köche verderben den Brei" ...
Von Kevin Krammer am Di, 19. August 2008 um 14:11 #
Weil irgendjemand sich die Mühe machen muss und *alle* Dateien / Programme etc. erstmal taggen muss.
Auch wenn Tagging aus Benutzersicht erstmal die offensichtlichste Quelle semantischer Informationen sind, so sind sie nur ein Bruchteil der schon verfügbaren Möglichkeiten.
Semantische Integration beginnt in den Applikation die Daten erstellen oder verändern, in dem sie die inherent vorhandenen Zusammenhänge nicht wegwerfen, sondern ebenfalls aufbereiten. Speziell in diesem Bereich lässt sich durch entsprechende bibliothekenbasierte Umsetzung eine sehr große Einheitlichkeit erreichen.
Tagging ist praktisch eine benutzerspezifische Ergänzung, mit der Benutzer ihre persönlichen Zusammenhänge abbilden können.
muss ich *immer* noch auf eine rein syntaktische Suche zurückgreifen
Auch der Dateiname ist Teil der semantischen Basisinformation.
Benutzertags sind Customizing, nicht die Grundlage semantischer Verwaltung.
> Dieser ganze semantische Kram wird nicht funktionieren
Blödsinn.
Punkt 1 kann zu 98% von einem Programm erledigt werden. Die Semantischen Daten existieren schliesslich bereits in jeder normalen Paketverwaltung. Man muss sie nur extrahieren.
Punkt 2 ist irrelevant, denn Konqueror ist nichts davon, hat aber Profile die entsprechende Komponenten laden. Dieses laden wird überdies mit entsprechenden Skripten erledigt, die dann auch wieder entsprechend Automatisch getaggt werden können.
Punkt '3' ist nun wirklich ein albernes Konstrukt. Wenn du deiner Distribution sowenig vertraust, schraub dir deine eigene zusammen.
also gehen wir mal weg vom stino desktop wos eh eigentlich egal ist wo was liegt...mal hin zu irgendner workstation oder thinclient je nachdem.../ liegt auf der maschine selber,weil es die noetigsten programme/libs enthaellt die man unmittelbar zum starten braucht. Dort kann man dann /usr uebers netzwerk mounten...oder noch besser so sachen wie /usr/bin,/usr/lib koennen innerhalb der selben architektur ein netzwerk share verwenden und /usr/include,/usr/share,.. sogar ein share ueber alle architekturen hinweg. wie macht man sowas mit dem GoboLinux layout?
Keine Ahnung, wie das GoboLinux macht, aber mit z.B. unionfs kann der /Programs-Ordner ja eine beliebige Mischung enthalten. Der Nachteil ist auf den ersten Blick halt, dass man nicht auf den ersten Blick sagen kann, auf welcher Maschine die Anwendung liegt. Da wird es aber auch Lösungen geben.
Richtig. Oder auch Server, auf denen /usr und /usr/lib auf phys. getrennten Platten liegen um den Startvorgang der Binaries unter /usr/bin zu beschleunigen.
Alles wichtige Features, die mit dem "Gobo-FS" nicht machbar sind.
Für Windows-Umsteiger sicher ganz interessant, aber sonst?
Ein "tar czvf MyBackup.tgz /etc" enthälz dann lauter Symlinks bei GoboLinux?
Ich finde es ist einer DER Vorteile von UNIX/Linux, dass Dateien ihrem Zweck entsprechend im Dateisystem zu finden sind (Executable, Configfile, Library, Logfile) und eben NICHT alles zusammen. So kann man auch "variable" von "statischen" Teilen trennen und diese auf verschiedene Dateisysteme packen.
Backup ist eine Sache.. Was ist denn z.B. mit gemeinsam genutzen /usr Verzeichnissen (per NFS)..?
Allein auf der Beispielseite ist z.B. Htop was ja für konsole ist. ich stell mir das dann so vor: $ echo $PATH /Programs/Htop/bin:/Programs/bash/bin:/Programs/ls/bin:/Programs/.../bin:...
gut, mit symlinks in /usr/bin gehts, aber das soll dann ja deprecated sein.
Das ist das schöne an Open Source - es gibt neue Ideen! Auch wenn der eine oder andere kritisch dagegenstehen mag, so sollte das Konzept auch von anderen Distributionen diskutiert werden. Das kann nicht schaden und eröffnet neue Sichtweisen auf bestehende und kommende Anforderungen.
Ehrlich gesagt weiß ich nicht, was gegen eine komplette Restrukturierung des Verzeichnisbaums in diesem Sinne spricht. Auch wenn's beim "Bösen Feind" so Standard ist, muss es ja nicht gleich falsch sein, ein "Programme"-Verzeichnis zu haben, in dem die anwendungsspezifischen Dateien und Bibliotheken liegen. Für die Shared Libraries kann man ja immer noch ein separates Verzeichns vorhalten. Übersichtlicher als der Status Quo ist das auf jeden Fall!
Prinzipiell spricht erst mal der Aufwand gegen eine restrukturierung des Dateisystems. Das ist natürlich kein grundsätzliches Argument dagegen, jedoch muß der Grund für eine Restrukturierung daher verdammt gut sein - und zumindest *ich* sehe den momentan nicht.
Ok, oben wurde als Argument für das vorgestellte Konzept eine höhere Ein/Umsteigerfreundlichkeit genannt. Aber ehrlich gesagt habe ich hier die Befürchtung, daß hier im Sinne der größeren Verbreitung von Linux zu sehr der standard Desktop-DAU als Zielgruppe gesehen wird. Ganz abgesehen von den anderen oben angesprochen Problemen (Backup, etc.) finde ich alleine schon den Namen /programs zu lang. Es wird eben nicht mehr davon ausgegangen, daß man einen Verzeichnisnamen (sorry, es heist jetzt ja "Ordner") eingibt, sondern ihn nur noch mit der Maus umherschupst oder klickt. Sogar so elementare Sachen wie die Bluez-Utils (passkey-agent) oder Gnupg (gpg2 erfordert zwingend pinentry) gehen mittlerweile davon aus, daß ein Mausschupser vor der Kiste sitzt. ... Aber ich schweife ab.
Aber ehrlich gesagt habe ich hier die Befürchtung, daß hier im Sinne der größeren Verbreitung von Linux zu sehr der standard Desktop-DAU als Zielgruppe gesehen wird.
Sorry, aber diese Einstellung finde ich schlicht und einfach zum Kotzen! Der von Dir so überheblich als "Desktop-Dau" bezeichnete normale PC-Anwender sieht seinen Computer als ein Werkzeug, mit dem er seine wie auch immer gearteten Aufgaben effizient erledigen kann - und das alles möglichst einfach. Daher spricht absolut nichts dagegen, ein IT-System auch so zu gestalten, dass es dieses Bedürfnis befriedigt.
Man kann nicht Open Source in Behörden und Schulen propagieren und sich gleichzeitig dagegen wehren, dass diese Software benutzerfreundlich gestaltet wird. Ein Desktop-PC muss in erster Linie für den Benutzer einfach sein, nicht für den Administrator.
Der Erfolg eines Autos hängt schließlich auch nicht davon ab, wie toll der Mechaniker ans Getriebe kommt, sondern wie es sich fahren lässt.
Wenn Linux aber wirklich ein Nischenprodukt für Techies und Nerds bleiben sollte, dann sollte man auch damit aufhören, Leute mit dem Thema zu belästigen, die wichtigeres zu tun haben als den ganzen Tag an ihrem System herumzufeilen.
Es ist schlicht unmöglich, einen Computer zu entwickeln, der allen Ansprüchen gerecht wird und in jeder Situation "einfach funktioniert". Die Leute wollen Briefe und E-Mails schreiben und stellen sich dazu ein Gerät auf den Tisch, das technisch dazu in der Lage ist, Video/Musik zu erstellen, Häuser zu entwerfen, FEA-Berechnungen durchzuführen und Roboter und Raumsonden zu steuern. Aber das ist gewollt, denn der PC ist eine offene Plattform die in erster Linie für alle Aufgaben geeignet sein soll. Vielen Benutzern ist das aber überhaupt nicht bewusst. Nimm mal einen typischen Mediamarkt-Kunden beim Wort wenn er sagt, er wolle eigentlich nur Briefe schreiben, ein paar Spiele spielen und videotelefonieren. Dann schick ihn zu den Schreibmaschinen, den Spielekonsolen und den Videotelefonen. Das sind alles hochspezialisierte Geräte, die sehr einfach zu bedienen sind. Aber rate mal, wie der Kunde reagiert: Das will er gar nicht. Das geht doch alles mit dem PC, und ausserdem will er noch Fotos und Videos bearbeiten, den 3D-Gartenplaner installieren und Online-Banking machen. Der nächste will vielleicht noch seinen Synthesizer und die 24-Kanal-Soundkarte ansteuern, und der dritte will vielleicht tatsächlich eine Raumsonde steuern. Das sind die Ansprüche an das Gerät. In der Realität sind aber viele Benutzer schon mit den Touch-Screen-Fahrkartenautomaten am Bahnhof überfordert, obwohl diese Geräte das Höchstmass der zur Zeit möglichen Benutzerfreundlichkeit und einen extrem geringen Funktionsumfang aufweisen. Bei vielen "Desktop-Daus" (man verzeihe mir die Wortwahl, aber wir wissen alle wer gemeint ist) ist die Diskrepanz zwischen Ansprüchen und Fähigkeiten/Lernwille gigantisch.
Man kann dem Ideal des beliebig komplexen und trotzdem intuitiv bedienbaren Gerätes recht nahe kommen, aber auch bei Apple muss man gelegentlich einen WLAN-Schlüssel eingeben, die Ein- und Ausgangsserver für das E-Mail-Konto angeben, Software muss mühsam von Hand gelöscht werden wenn sie über *.pkg installiert wurde, bei per Drag+Drop installierter Software wird keine Verknüpfung im Dock angelegt und (wenn ich mich recht erinnere) Dateitypen werden nicht automatisch mit dem Programm verknüpft etc. Irgendwo müssen immer Kompromisse gemacht werden. Einfachste Bedienbarkeit hat ihren Preis, aber unbegrenzte Funktionsvielfalt ebenfalls.
Um zum Schluss noch den bekannten Autovergleich zu bemühen: Wenn jemand 3-6 Monate und 1000 in eine theoretische und praktische Ausbildung investiert, sein Können in einer theoretischen und praktischen Prüfung beweisen muss, und Wartung und Unterhalt der Hardware in festgelegten Intervallen kostenpflichtig durch ausgebildetes Personal durchführen lässt, wird er relativ wenig Probleme mit Computern haben. Natürlich muss kein Anwender wissen wie ein Getriebe funktioniert (genausowenig muss er in der Lage sein, selber einen Compiler zu programmieren), aber wenn ihm jemand sagt, er müsse die Kupplung treten wenn er den Gang wechselt, muss er es entweder glauben und KONSEQUENT tun, oder mit den Folgen leben. Wenn er hingegen trotz mehrfacher Warnung immernoch auf "Br1tney-Spe4rs: Nude!!!!.jpg.exe"-Attachments klickt, sind komischerweise immer alle anderen Schuld.
zusätzlich: viel freie software wird von programmierern in ihrer freizeit geschrieben (ja..beim linux-kernel ist es anders) und veröffentlicht. nun kommen leute und - nachdem sie das programm gratis _selbst_ heruntergeladen haben, nichts gespendet oder sonst dazu beigetragen haben - meinen, linux müsste sich mehr um diese anwender kümmern. so wie windows und mac.. die seien ja auch einfacher zu bedienen.
wenn ich mir die lizenzkosten spare, kann ich wenigstens die umgerechnete arbeitszeit in wissenserwerb investieren!
Jedes Programm sollte über ein Script gestartet werden, das eine chroot-Umgebung anlegen sollte. Ein Progrämmchen um Fuse herum hätte die Umgebung zusammengestellt und in einen Ordner inerhalb von /tmp gemountet.
Die Vorteile sind klar. Die Programmpakete, müssten nur eine Konfiguartionsdatei enthalten, die sagt wie die chroot-Umgebung zusammen gestellt werden soll, ansonsten könnten sie Strukturiert sein wie sie wollen (selbst komprimiert währe möglich).
Probleme bereiteten mir Deamons und Programme die weitläufig Gebrauch von /etc und ähnlichen "Sammelordnern" machen. Das liefe wieder auf eine Virtualisierung hinaus. Dazu müßten vor jedem Prgrammstart sämmtliche Installierte Pakete Gescant werden, um die nötigen Dateien zusammen zu klauben. Sehr aufwändig und langsam. Leider weiß man nicht ohne weiteres auf welche Dateien das Programm zugreifen wird, das kann ja auch von Benutzereingaben abhängen. Außerdem ist fuse leider nicht sonderlich schnell.
Das ganze liegt erstmal auf Eis bis mir eventuell was einfällt...
Von Crass Spektakel am Mi, 20. August 2008 um 10:36 #
Also nichts für ungut, aber wer MacOx nacheifert der kann ja gleich zu WindowsME zurückkehren. MacOx ist sicherheitstechnisch ein einziger Albtraum. Praktisch jede installierte Applikation ist unter Rechten des zufällig installierenden User untergebracht => Stand Windows95. Weil ja sowieso alles in verschiedenen Hierarchien liegt sind manche Bibliotheken teilweise zehnmal auf dem Rechner installiert, pro Anwendung mindestens einmal. Und Updates werden für diese wilden Bibliotheken nie eingespielt weil wen interessiert schon /Anwendungen/OpenTTD?
finde ich eine gute idee, das mache ich schon lange so für programme welche ich nicht im paketmanager meiner distribution finde und manuell installiere. dazu benutze ich GNU stow: http://www.gnu.org/software/stow/
Die einzelnen Graphischen Programme sind in sogenanten Bundles zusammengefasst. Bundles sind nichts anderes als Ordner die das System als Programme erkennt. In den Ordner sind dann alle weiteren Resourcen die ein Programm benötigt enthalten. Es ist sogar möglich binaries für mehrere Architekturen hinzuzufügen. So giebt es Programm-Bundles die sowohl für PPC wie für Intel und zusätlich für 32Bit und 64Bit kompilliert wurden und somit 4 binaries enthalten.
Wenn ein Programm Frameworks installieren will wird meistens ein Installer für das jeweilige Programm verwendet, wenn alle Resourcen nur in einem Application-Bundle vorhanden sind, kann der Ordner einfach in /Application kopiert werden und durch anklicken verwendet werden.
Alleine schon der Schwachsinn ständig mehrere Strukturen parallel zu nutzen ist bei OSX schon sehr grenzwertig. Im vergleich dazu ist selbst ein Windows-System Sauber und durchschaubar. Und dabei sprech ich nur von der Standardinstallation. Mit MacPorts oder Fink wird das ganze noch interessanter. Da wird gleich mal noch mal das halbe Userland neu Kompiliert, weil vorhandene $LANGUAGE-Interpreter nutzen geht ja nicht, da muss schon was eigenes her
Das ist eine Behauptung ohne rationel Argumente dahinter.
Spontan fällt mir hier keine Applikation ein, die so etwas macht. Kannst du mir hier auf die Sprünge helfen?
Die Frage war, ob es das oben beschriebene Verhalten gibt. Denn ich vermute, dass so etwas kaum passieren wird und wenn ja, dann ist es ein Design-Fehler einer Applikation und kann auch vom FHS nicht abgefangen werden. Deshalb die Frage nach einem konkreten Beispiel.
die dateien werden auf platte gespeichert, und mit tags versehen. und die tags in einem katalog versehen. bei den ganzen online-bookmarkdiensten sowie blogs setzt es sich immer mehr gegen hierarchiche strukturen durch.
Das würde sogar Katalogsysteme und lokale Suchmaschinen zum teil überflüssig machen.
Schau dir mal Googlemail an, die arbeiten mit Tags statt Mailordnern. Im Endeffekt nicht überschau- und damit nutzbar.
Aufwand hängt von der Komplexität und Vielgestaltigkeit der Daten ab, die es zu verwalten gilt, nicht davon, ob ich die Daten etikettiere oder hierarchisch ordne. Im Gegenteil ist es eher so, daß ich mehr Aufwand treiben muß, um eine Hierachie für alles zu entwickeln und zu pflegen, als wenn ich die Qualität der Daten per Etikettierung handhaben kann.
Aufwand und Disziplin braucht man vor allen Dingen, um die mangelnde Unterstützung seitens der UI auszugleichen, wenn es darum geht, Daten anhand ihrer Qualität entsprechend einzuordnen.
Dateiauswahldialoge sind ja heutzutage [fast] die gleiche Katastrophe wie seit ihrer Erfindung. Der beschriebene Aufwand und die Disziplin bleiben ja bisher immer noch am Nutzer hängen, der den passenden Zielordner finden muss. Welcher Dateiauswahldialog macht denn passende Vorschläge für Zielordner, wenn es darum geht ein Dokument oder ein Video abzulegen?! Habe ich bisher weder gesehen noch davon gehört!
lg
Erik
Erstens heisst es GoboLinux. Zweitens kannst du genausogut statisch gelinkte Binaries verwenden. Und wenn es shared libaries sind ist die Verzeichnisstruktur genauso egal. Die Argumente dagegen sind so lächerlich.
Meine Festplatte ist rund 200 Gig gross, grep sed m4 make coreutils und noch ein paar hab ich immer statisch. Und dazu noch busybox (auch statisch, das geht sogar mit glibc. Die busybox Entwickler sind wirklich sehr gut.)
Drittens hast du einen riesigen Vorteil von GoboLinux nicht beachtet: Multiple Versions.
Du hast GoboLinux nicht probiert, ansonsten hättest du ihn erwähnt denn jeder der zwischen verschiedenen GCCs wechselt nur anhand der Verzeichnisse wird kaum mehr auf /usr/bin vs /usr/local/bin Chaos zurückgreifen.
Viertens hast du nicht beachtet das die klassischen Unix Varianten nicht vorwärts kommen. Da mag man Gobolinux kritisieren wie man will - probier halt NixOS aus. Oder bastel etwas neues mit einer eigenen Idee.
Fakt ist das die Ideen fehlen. (Und die Umsetzung der Ideen)
Das Konzept erinnert mich allerdings ein wenig zu sehr an Windows, wenn auch mit einigen Verbesserungen. Ich halte es dennoch für überflüssig, das Problem der Paketverwaltung auf das Dateisystem auszulagern. Ein ähnlicher Ansatz wurde von Zero Install versucht, ohne dass sich dieses System auf breiter Ebene durchgesetzt hätte.
Gruß, LX
Das sagt nichts aus; Betamax hat sich auch nicht durchgesetzt, obwohl VHS angeblich "schlechter" war.
Ich halte den Ansatz von GOBO nicht für überflüssig, denn die zentralen Paketmanager sind immer noch der größte Nachteil von Linux.
Knoppix brachte die Leute in problemlose Berührung mit Linux,
Ubuntu brachte die Leute Linux auf den Rechner
und Gobo-Linux bringt den Leuten den Systemaufbau näher.
Windows kann bald einpacken
* einfache installation von programmen
* einfache updaten von programmen (nicht x verschiedene update-routinen)
* zuverlässige quellen, automatische prüfsummenkontrolle
* shared-libraries
* rückstandsfreie deinstallation
* eineinander abgestimmtes system
* kein nerviges googlen, downloaden, installieren (tja..wer das mag, soll rhel 4 nutzen)
ohne zentrale paketmanager hätten wir das windows-chaos mit fetten binaries und alle 2 jahre neuinstallation.
es ist eben nicht wie bspw. teilweise unter win geregelt (auch da gibts dynamisches linking), sondern das /programs bezieht sich auf jedes paket, und damit auch auf die lib-pakete die dann z.b. unter /programs/gtk-2.6.X liegen. ganz so dumm ist das nicht.
Welchen Vorteil bringt mir das noch, wenn jedes Packet in ein eigenes Verzeichnis installiert wird? Die Abhängigkeiten der Pakete bleiben bestehen. Dafür schwillt mir die ld.so.conf extrem an. Das macht den dynamic linker auch nicht gerade schneller.
1.) herkömmliche HDs kommen schon in den Terabytebereich, Platz ist demnach irrelevant
2.) verbrauch libs nicht so viel an Platz.
3.) können parallel Versionen genutzt werden, was sehr oft sehr große Vorteile liefert (z.B. habe ich zwei unterschiedliche Versionen von gnumeric gebraucht, da jeweils ein Bug vorkam, der mich störte
4.) Ist eien Deinstallation viel einfacher.
bei diesem Thema
Was mich viel mehr interessieren würde, was ist der Unterschied zu BSD/Mac? Ich schreibe gerade von einem Mac (10.5), und dort ist das schon lange Usus).
2) ach wirklich? > 1,5G /usr/lib64
3) andere Distris können das auch - mit einer fast-Standard Struktur! (gentoo+slots zb)
4) um die Deinstallation kümmert sich der pkgmanager, kann also dem Anwender egal sein.
Vor allem hängt es ja auch mit der Nutzung ab, was man alles installiert.
Paketmanager ist ja ok, aber warum nicht den Komfort haben einfach Programmpfad löschen = Deinstallation?
Und was ist wohl einfacher rm -rf 'malüberlegwoesist* und 'wo sind alle symlinks die ich löschen muß' oder 'pmerge --unmerge pkgname'?
erledigt haben dürfte.
Da kann ich auch gleich CONTENTS catten und rm damit füttern.
a) Es gibt noch viele, die mit alten Rechner <1Ghz arbeiten.
(Teilweise sich auch keinen leisten können.)
b) Linux am PDA und Handy muss so schlank wie möglich sein.
Für beide Beispiele wären doppelte Libs oder Ähnliches nur schlecht.
)
Außerdem wäre eine Eigenentwicklung für mobile Geräte wieder eine Teilung und damit verbundenes Anpassungsproblem für Entwickler!
(Um genau das geht es ja bei dem genannten Standard
außerdem..schon mal aufgefallen, wie angenehm es ist, wenn alle config-files in /etc liegen? einfach ein 'dvcs deiner wahl'-repository deiner wahl dort anlegen und man hat es wesentlich einfach, wenn eine config verbockt wird.
und ein argument für paranoide: /usr read-only mounten, änderbare-daten nach /var (ist auch allgemein empfehlenswert aufgrund der fs-fragmentierung)
Ich finde die Ansicht "wir ham ja Platz, also immer weg damit" ziemlich irrwitzig - ich will den Plattenplatz für das nutzen, wofür ich auch den Rechner nutze: zum Arbeiten. Platzverschwendung ist auch in Zeiten von TB-Platten einfach nur Verschwendung. Anwendungsdaten werden ja auch immer größer (Stichwort HD-Video) -> nur macht es da Sinn.
Und für Geräte mit begrenzten Ressourcen (embedded Bereich, Router u. ä.) verbietet sich eine solche Einstellung von selbst. Oder willst Du eine 100GB-Flash-Disk kaufen, nur weil Du schon die Hälfte fürs OS brauchst?
Andere Frage: Wie geht denn Gobo-Linux mit veränderlichen Dateien um? Liegen die auch in den Programmverzeichnissen (Konfigs, Logs, temp. Dateien ...)? Wo liegen anwenderspezifische Konfigs?
Ich nehme mir ein paar Vorteile, wenn ich alles an einen Platz packe: Ich kann kein FS mehr read-only mounten und z. B. unter die Kontrolle eines IDS stecken (Sicherheit), Delta-Backups werden deutlich aufwändiger, weil immer der gesamte Baum durchsucht werden muss, Systemüberwachung wird unübersichtlicher, weil ich die Logs überall zusammensuchen muss, ... Dann geht nämlich Platzverbrauch über in allgemeinen Ressourcenverbrauch, weil dann auch Prozessor, I/O-Controller usw. mehr Arbeit haben.
Und wie steht es mit Security-Patches? Nimm eine Situation wie neulich die sshlib-Lücke in Debian: Fängst Du dann an zig statisch gegen die Lib gelinkte Programme auszutauschen und ebenso viele dynamisch gelinkte, die alle die Lib in ihrem Baum haben?
Jan
Trotzdem sollten alle Konfigurationsdateien in einem Verzeichnis verbleiben und Konfigurationsdateien die Hardwarezugriffe enthalten sollten in einem gesonderten Verzeichnis verbleiben - das wäre schon für die Softwareverteilung in kleineren Installation sehr sinnvoll.
Die Konfigurationsdateien kommen ja wieder in ein Verzeichnis wenn ich das richtig Verstanden habe.
Allerdings sind das dann eben "nur" Symlinks. Also z.B.:
/etc/sshd.conf -> /programs/sshd/-version-/sshd.conf
Ich persönlich finde aus Sicht eines (einfachen) Desktopanwenders die Apple-Variante ganze gut bzw. fast am besten. Da muss sich der Anwender am wenigsten Gedanken machen, das Programm kann einfach kopiert, verschoben oder eben gelöscht werden. Ganz ohne Paketmanager oder Software-Deinstallieren-Dialog.
Hm... werde mir das System mal nach der Arbeit genauer ansehen....
Aber wenn in einer mehrfach installierten lib ein Fehler gefunden wurde, reicht es z.B. nicht diesen einmal zu beheben, sondern jedes Programm das diese Bibliothek benutzt muss ein Update erhalten.
Als kommerzieller Softwareentwickler (der kostenlos Support leisten muss) ist das ein absolutes No-Go.
Ich bestimme mit welchen Libs mein Program läuft. Wäre ja noch schöner wenn ich da Zeit investiere und mir nach der 10ten Email der Typ sagt, er hätte da mal libxyz getauscht.
Wenn es bekannte Probleme gibt => Hersteller anrufen => Hersteller muss austauschen, ansonsten mit dem Probleme weiterleben und von Hersteller künftig nicht mehr kaufen.
Ich sehe da keinen Sinn darin, ausser dass man zum Exot wird der alles wieder anders macht. FHS ist definiert und so unübersichtlich ist das auch nicht, man weiss dann in jedem Linux was wo ist, zumal sich daran jeder schon gewöhnt hat.
;-)
Im FHS ist es definiert, aber so exakt nun auch wieder nicht. Debian lässt /var/www openSUSE nimmt /srv/www...
Wenn ich mir die FHS-Definition durchlese dürfte openSUSE richtig liegen - aber warum gilt Debian dann als FHS-konform?
Oder kennt hier jemand den Grund?
Bis ich das herausgefunden habe sind ein paar Minuten ins Land gegangen - zumal die Fehlermeldung nicht wirklich geholfen hatte...
So ist Debian evt. FHS2.2 konform...
2.2:
Gibt es kein /srv !
2.3:
This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
Btw:
Fedora und Redhat sind was die FHS angeht auch nicht konsequent...
Es gibt zwar ein /srv, dies ist aber per default leer. Auch zeigen die DocumentRoot und andere Dinge nach /var/www.
[root@foobar /srv]# rpm -ql httpd | grep "world1.png"
/var/www/icons/world1.png
Bedeutet:
httpd.conf anpassen und die neuen sites nach /srv/httpd/
Von Hand das Zeugs verfummeln
/srv ist einfach nur krank! /var gibt es nicht ohne Grund. Aber hey, mit jeder neuen Version ein bißchen Veränderung und Schwachsinn und schon funzt nichts mehr. Das macht dann die Standardisierer so richtig glücklich.
Der FHS-Standard sollte nicht von den bestehenden Systemen ausgehen, sondern sich überlegen, wie die Zukunft aussieht. Globale Filesysteme, Wechselmedien, geringere Verständnishürden, ... Solange Konzepte aus den 70ern aufgekocht werden ist es immer die gleiche Suppe die uns vorgesetzt wird. Jetzt aber mit Kräutern und Knoblauch...
/var für Anwendungsinhalte zu nutzen war ein kaputter und unbeholfener Versuch, geprägt von der Feigheit, ein neues Vereichnis (wie eben /srv) einzuführen, einen Ort für Content zu finden.
Die Frage war also, wo gehören Anwendungsinhalte hin? apache ging mit seinem docroot früher nach /usr/share. Passte nicht so wirklich. Dann kam /var/(lib), warum auch immer, und irgendwann hat jemand mal srv eingeführt. Welchen Zusammenhang aber Logs, Status/Laufzeit- oder Spooldateien oder andere, variable Systemdaten mit Anwendungsdaten haben sollen, bleibt wohl ein ewiges Geheimmis. Genausogut hätte man /etc oder /tmp nehmen könnenm wäre genauso deplaziert gewesen.
Andere gehen nach /home, mit der Logik, daß das document root ja die Daten vom Anwender apache sind, oder postgres eben die Daten von der gleichnahmigen Datenbank. Auch wenn diese im Gegensat zu joe nicht interaktiv ist.
Insofern ist srv gar nicht so schlecht, aber die Masse der Pseudotraditionalisten ist wohl zu laut. var ist inhaltlich auf jeden Fall varnsinn. Und ignorant oben drein
das ist aber nicht so wichtig. viel wichtiger ist dass sich offenbar leute gedanken machen über den status quo, der tatsächlich verbesserungswürdig wäre.
eine wirkliche lösung dieser misere bringt wohl erst das noch nicht existierende SFS (Semantic Filesystem) in dem das binary 'konqueror' mit den tags 'konqueror,kde,binary' irgendwo auf der platte verstaut wird, während die manpage dazu die tags 'konqueror,kde,manpage' erhält und ebenfalls irgendwo liegt wo sie anhand der tags wiedergefunden wird.
überflüssig zu erwähnen dass ich mich schon wie ein schnitzel auf die nepomuk-integration in KDE freue
Dieser ganze semantische Kram wird nicht funktionieren:
1. Weil irgendjemand sich die Mühe machen muss und *alle* Dateien / Programme etc. erstmal taggen muss.
2. Weil unterschiedliche Menschen ein und dieselben Daten unterschiedlich taggen werden / würden. Ist der Konqueror jetzt ein Webbrowser, ein Filemanager oder beides? Ist das von der KDE-Version abhängig? Und, mir fallen auf Anhieb ca. 10 Möglichkeiten ein, wie man "AC/DC" falsch bzw. anders schreiben könnte ...
2. Wenn ich nicht 100%ig sicher sein kann, dass alle meine Inhalte mittels semantischer Tags erfasst sind, muss ich *immer* noch auf eine rein syntaktische Suche zurückgreifen da ich nie sicher sein kann, ob das gesuchte etwas der semantischen Suche vielleicht durch die Lappen gegangen ist. Ergo: Dopplete Arbeit ohne Sinn.
muss ja nicht jeder den elektromotor nutzen wenn es doch die dampfmaschine gibt *rolleyes*
Solch ein System kann sehr gut funktionieren, wenn alles richtig getagt ist und auch entsprechend gepflegt wird.
Umso mehr verschieden Personen allerdings in dem System "herumpfuschen", umso schwieriger wird es, das System einheitlich und gepflegt zu halten. Und wenn man das nicht schafft, dann kostet das System viel mehr Zeit als eine Klassische Verzeichnisstruktur z.b.
Ich arbeite hier in der Firma mit Dokument-Verwaltungssystemen, welche ebenfalls die Dokumente durch Tags kennzeichnen damit man diese einfach wiederfinden kann - und ich wäre in der Zwischenzeit froh, wenn wir es nicht mehr verwenden würden...
Wie heißt es so schön: "Viele Köche verderben den Brei" ...
Auch wenn Tagging aus Benutzersicht erstmal die offensichtlichste Quelle semantischer Informationen sind, so sind sie nur ein Bruchteil der schon verfügbaren Möglichkeiten.
Semantische Integration beginnt in den Applikation die Daten erstellen oder verändern, in dem sie die inherent vorhandenen Zusammenhänge nicht wegwerfen, sondern ebenfalls aufbereiten.
Speziell in diesem Bereich lässt sich durch entsprechende bibliothekenbasierte Umsetzung eine sehr große Einheitlichkeit erreichen.
Tagging ist praktisch eine benutzerspezifische Ergänzung, mit der Benutzer ihre persönlichen Zusammenhänge abbilden können.
muss ich *immer* noch auf eine rein syntaktische Suche zurückgreifen
Auch der Dateiname ist Teil der semantischen Basisinformation.
Benutzertags sind Customizing, nicht die Grundlage semantischer Verwaltung.
Blödsinn.
Punkt 1 kann zu 98% von einem Programm erledigt werden. Die Semantischen Daten existieren schliesslich bereits in jeder normalen Paketverwaltung. Man muss sie nur extrahieren.
Punkt 2 ist irrelevant, denn Konqueror ist nichts davon, hat aber Profile die entsprechende Komponenten laden. Dieses laden wird überdies mit entsprechenden Skripten erledigt, die dann auch wieder entsprechend Automatisch getaggt werden können.
Punkt '3'
ist nun wirklich ein albernes Konstrukt. Wenn du deiner Distribution sowenig vertraust, schraub dir deine eigene zusammen.
wie macht man sowas mit dem GoboLinux layout?
Alles wichtige Features, die mit dem "Gobo-FS" nicht machbar sind.
Für Windows-Umsteiger sicher ganz interessant, aber sonst?
Ich finde es ist einer DER Vorteile von UNIX/Linux, dass Dateien ihrem Zweck entsprechend im Dateisystem zu finden sind (Executable, Configfile, Library, Logfile) und eben NICHT alles zusammen. So kann man auch "variable" von "statischen" Teilen trennen und diese auf verschiedene Dateisysteme packen.
Backup ist eine Sache..
Was ist denn z.B. mit gemeinsam genutzen /usr Verzeichnissen (per NFS)..?
Ich sehe keine (oder kaum) Probleme mit dem FHS.
Marc
$ echo $PATH
/Programs/Htop/bin:/Programs/bash/bin:/Programs/ls/bin:/Programs/.../bin:...
gut, mit symlinks in /usr/bin gehts, aber das soll dann ja deprecated sein.
Hoffe geholfen zu haben.
Die Aussage wäre wahr, wenn sie wahr wäre? Schöne Nullaussage.
Ansonsten: danke.
Heiner
Ok, oben wurde als Argument für das vorgestellte Konzept eine höhere Ein/Umsteigerfreundlichkeit genannt. Aber ehrlich gesagt habe ich hier die Befürchtung, daß hier im Sinne der größeren Verbreitung von Linux zu sehr der standard Desktop-DAU als Zielgruppe gesehen wird. Ganz abgesehen von den anderen oben angesprochen Problemen (Backup, etc.) finde ich alleine schon den Namen /programs zu lang. Es wird eben nicht mehr davon ausgegangen, daß man einen Verzeichnisnamen (sorry, es heist jetzt ja "Ordner") eingibt, sondern ihn nur noch mit der Maus umherschupst oder klickt. Sogar so elementare Sachen wie die Bluez-Utils (passkey-agent) oder Gnupg (gpg2 erfordert zwingend pinentry) gehen mittlerweile davon aus, daß ein Mausschupser vor der Kiste sitzt. ... Aber ich schweife ab.
Sorry, aber diese Einstellung finde ich schlicht und einfach zum Kotzen! Der von Dir so überheblich als "Desktop-Dau" bezeichnete normale PC-Anwender sieht seinen Computer als ein Werkzeug, mit dem er seine wie auch immer gearteten Aufgaben effizient erledigen kann - und das alles möglichst einfach. Daher spricht absolut nichts dagegen, ein IT-System auch so zu gestalten, dass es dieses Bedürfnis befriedigt.
Man kann nicht Open Source in Behörden und Schulen propagieren und sich gleichzeitig dagegen wehren, dass diese Software benutzerfreundlich gestaltet wird. Ein Desktop-PC muss in erster Linie für den Benutzer einfach sein, nicht für den Administrator.
Der Erfolg eines Autos hängt schließlich auch nicht davon ab, wie toll der Mechaniker ans Getriebe kommt, sondern wie es sich fahren lässt.
Wenn Linux aber wirklich ein Nischenprodukt für Techies und Nerds bleiben sollte, dann sollte man auch damit aufhören, Leute mit dem Thema zu belästigen, die wichtigeres zu tun haben als den ganzen Tag an ihrem System herumzufeilen.
Man kann dem Ideal des beliebig komplexen und trotzdem intuitiv bedienbaren Gerätes recht nahe kommen, aber auch bei Apple muss man gelegentlich einen WLAN-Schlüssel eingeben, die Ein- und Ausgangsserver für das E-Mail-Konto angeben, Software muss mühsam von Hand gelöscht werden wenn sie über *.pkg installiert wurde, bei per Drag+Drop installierter Software wird keine Verknüpfung im Dock angelegt und (wenn ich mich recht erinnere) Dateitypen werden nicht automatisch mit dem Programm verknüpft etc. Irgendwo müssen immer Kompromisse gemacht werden. Einfachste Bedienbarkeit hat ihren Preis, aber unbegrenzte Funktionsvielfalt ebenfalls.
Um zum Schluss noch den bekannten Autovergleich zu bemühen: Wenn jemand 3-6 Monate und 1000 in eine theoretische und praktische Ausbildung investiert, sein Können in einer theoretischen und praktischen Prüfung beweisen muss, und Wartung und Unterhalt der Hardware in festgelegten Intervallen kostenpflichtig durch ausgebildetes Personal durchführen lässt, wird er relativ wenig Probleme mit Computern haben. Natürlich muss kein Anwender wissen wie ein Getriebe funktioniert (genausowenig muss er in der Lage sein, selber einen Compiler zu programmieren), aber wenn ihm jemand sagt, er müsse die Kupplung treten wenn er den Gang wechselt, muss er es entweder glauben und KONSEQUENT tun, oder mit den Folgen leben. Wenn er hingegen trotz mehrfacher Warnung immernoch auf "Br1tney-Spe4rs: Nude!!!!.jpg.exe"-Attachments klickt, sind komischerweise immer alle anderen Schuld.
zusätzlich: viel freie software wird von programmierern in ihrer freizeit geschrieben (ja..beim linux-kernel ist es anders) und veröffentlicht. nun kommen leute und - nachdem sie das programm gratis _selbst_ heruntergeladen haben, nichts gespendet oder sonst dazu beigetragen haben - meinen, linux müsste sich mehr um diese anwender kümmern. so wie windows und mac.. die seien ja auch einfacher zu bedienen.
wenn ich mir die lizenzkosten spare, kann ich wenigstens die umgerechnete arbeitszeit in wissenserwerb investieren!
Die Vorteile sind klar. Die Programmpakete, müssten nur eine Konfiguartionsdatei enthalten, die sagt wie die chroot-Umgebung zusammen gestellt werden soll, ansonsten könnten sie Strukturiert sein wie sie wollen (selbst komprimiert währe möglich).
Probleme bereiteten mir Deamons und Programme die weitläufig Gebrauch von /etc und ähnlichen "Sammelordnern" machen. Das liefe wieder auf eine Virtualisierung hinaus. Dazu müßten vor jedem Prgrammstart sämmtliche Installierte Pakete Gescant werden, um die nötigen Dateien zusammen zu klauben. Sehr aufwändig und langsam. Leider weiß man nicht ohne weiteres auf welche Dateien das Programm zugreifen wird, das kann ja auch von Benutzereingaben abhängen. Außerdem ist fuse leider nicht sonderlich schnell.
Das ganze liegt erstmal auf Eis bis mir eventuell was einfällt...
daniel