News GoboLinux 017 Alpha: Distribution revolutioniert das Linux-Dateisystem

[mooks]

Mit /var, /usr, /etc etc. kann ich auf den ersten Blick nix anfangen und auch keine Logik erkennen, was wo abgelegt wird

So kompliziert ist es nicht. Aber sieh es mal so, über die ordnerstruktur von C:\Windows\ jammert auch keiner und in Linux ist diese eben auf oberster ebene nur wesentlich aufgeräumter

 

[Snakeeater]

Interessanter Artikel. Für mich als langjährigen Linux"einsteiger" erschließt sich das Dateisystem noch lange nicht, genauso ist es frustrierend wenn die selben Programme auf verschiedenen Distributionen andere Verzeichnisse nutzen.
Zu sagen ein Nutzer müsse sich darum kümmern auf Linux ist auch absolut falsch. Erst diesen Mittwoch hatte ich das Problem das zwei Programme nach einem Update nicht mehr funktionierten und ich manuell irgendwas in irgendwelchen Programmfiles ändern musste, wonach es dann wieder lief.

An die ganzen FHS Verfechter hier, wie bringt man sich den selbst das FHS am schnellsten selbst bei?

 

[Mihawk90]

Eigentlich ist es doch völlig egal wo die Programmdateien liegen, die sind eh alle im $PATH, wenn man mit dem Package Manager installiert.

Das einzig interessante ist doch, wo die Konfigurationsdateien liegen, und da ist es auch nicht so kompliziert.
In /etc für systemweite Konfiguration, in ~/.local (oder direkt im Homeverzeichnis) bei benutzerspezifischer Konfiguration. Und im Zweifel oder wenn man sie an beiden Orten nicht findet, schlägt man einfach mal die man page auf, da steht es in der Regel auch drin wo die Konfigurationsdateien liegen.

 

[Snakeeater]

Ist store.py eine Konfigdatei für dich? Nutzt du Linux auch als Multimedianutzer?

 

[Mihawk90]

store.py ist natürlich schon mal aussagekräftig Was weiß ich was du da für'ne Datei hast...

Übrigens für die Frage vorhin noch:

An die ganzen FHS Verfechter hier, wie bringt man sich den selbst das FHS am schnellsten selbst bei?

https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Und mal so am rande: Natürlich gibt es immer mal die ein oder andere Anwendung, die sich nicht an die Konventionen hält. Das ist aber in Windows nicht anders, und auch da gibt es einen solchen "Standard":
https://de.wikipedia.org/wiki/Sonderverzeichnis

 

[IWSNX]

Kann mir sagen, ob ich das Wallpaper irgendwo herunterladen kann, gefällt mir?

https://pics.computerbase.de/9/1/6/6/9/article-630x354.d08c1b21.jpg

 

[Snakeeater]

Es ist halt definitiv die Frage was man mit Linux macht. Geht man in Multimediagefilde ala Lutris, Steam etc kann es gut sein, dass man schon etwas tiefer in die Materie muss.

 

[Rossie]

Kann mir sagen, ob ich das Wallpaper irgendwo herunterladen kann, gefällt mir?

Wenn die Info auf deren Webseite stimmt, wird der Hintergrund generiert:

And just like the background of this website, the wallpaper is procedurally-generated — you get a new one on every boot.

https://github.com/gobolinux/Enhanc...gs/skel/.config/awesome/themes/neon/theme.lua

 

[Tuxgamer42]

Zu sagen ein Nutzer müsse sich darum kümmern auf Linux ist auch absolut falsch. Erst diesen Mittwoch hatte ich das Problem das zwei Programme nach einem Update nicht mehr funktionierten und ich manuell irgendwas in irgendwelchen Programmfiles ändern musste, wonach es dann wieder lief.

Also wenn dass deine Strategie ist (manuell irgendetwas in irgendwelchen Files ändert) wundert es mich nicht, wenn nach einem Update etwas nicht mehr funktioniert...

Geht man in Multimediagefilde ala Lutris, Steam etc kann es gut sein, dass man schon etwas tiefer in die Materie muss.

Steam lebt - abseits einem simplen Downloader, der den eigentlichen Steam Launcher herunterläd - vollständig im Homeverzeichniss. Und auch bei Lutris passiert alles interessante wohl in /home.

Richtig ist, mit solcher Software kann man durchaus Spaß haben. Das eigentliche Betriebssystem und vor allem Verzeichnissaufbau ist hierbei jedoch eigentlich weniger relevant.

 

[DarkSoul]

Ist diese Ordnerstruktur nicht ein Albtraum für Versionsmanagement? Besonders für Updates... wer zieht die Settings mit um? Bleiben alte Versionen mit Sicherheitslücken erhalten?

 

[Tuxgamer42]

@DarkSoul
Inwiefern? Diese Ordnerstruktur macht "Installieren von Update-Paketen" für den Paketmanager sogar trivial: Packet nehmen, auf /Programs entpacken - fertig.
Verwechsele das nicht mit so etwas wie Flatpak.

Ob du nun die Dateien im Filesystem zerstreust und irgendwo eine Datei hinsetzt z.B.

usr/
usr/bin/
usr/bin/which
usr/share/
usr/share/info/
usr/share/info/which.info.gz
usr/share/man/
usr/share/man/man1/
usr/share/man/man1/which.1.gz

um dir zu merken: Dass sind die Dateien, die zu which gehören. Oder ob du die Dateien, die z.B. zu which gehören in ein und das selbe Verzeichniss haust. Und dann per (für den Nutzer vertseckte) Symbolik Links arbeitest, dass z.B. which irgendwo auf /usr/bin und deine .so auf /usr/lib liegt - das sind Implementierungsdetails, die sonst nicht den großen Unterschied machen.

 

[Linuxfreakgraz]

Mich würde ja interessieren, wie viele hier sich so etwas tatsächlich für Linux gewünscht haben/hätten^^?

Ich nicht.

Statt das jeder sein eigenes Süppchen kocht sollte man eine Vereinheitlichung der Distributionen anstreben bis zu dem Punkt das es nur ein allgemeines Paketformat gibt. Das hat man bei systemd erreicht leider wurde daraus eine träge Bloadware.

Man wird sehen wie sich die Sache weiterentwickelt aber ganz trivial ist es nicht den Dateipfad zu ändern, weil dadurch jedes einzelne Programm daran angepasst werden muss damit es Ordnungsgemäß funktioniert.
Das ist ein unglaublicher Mehraufwand jeden Sourcecode darauf hin zu ändern.
Ich weiß nicht wie es um die Manpower bei dem Projekt bestellt ist. Aber eins kann ich sagen das Konzept wird sehr viel Zeit für sich beanspruchen bei jedem Update. Damit tun sich die Entwickler einiges an.

 

[Mihawk90]

weil dadurch jedes einzelne Programm daran angepasst werden muss damit es Ordnungsgemäß funktioniert.
Das ist ein unglaublicher Mehraufwand jeden Sourcecode darauf hin zu ändern.

Da muss nichts angepasst werden. Die Libs werden dynamisch geladen wo sie gerade gefunden werden, die genauen Pfade sind gar nicht im Sourcecode. Wie tuxgamer oben schon sagte, die passende Lib wird ja auch mit which gefunden, solange sie im $PATH ist. Und solange sie im $PATH ist findet die auch jedes andere Programm, eine Anpassung ist dazu nicht nötig. Sonst müsste ja auch jedes einzelne Programm bei jeder Distro angepasst werden, da sind ja auch schon Abweichungen in den Pfaden (/usr/lib vs. /usr/lib32 vs. /usr/lib64 zum Beispiel).

 

[Serana]

Die Libs werden dynamisch geladen wo sie gerade gefunden werden, die genauen Pfade sind gar nicht im Sourcecode.

Ganz so automagisch funktioniert das aber auch nicht. Vorher muß man dem System nämlich noch mitteilen, an welchen Orten die Libraries überhaupt gesucht werden sollen. Das lernt man spätestens dann, wenn man mal Software direkt aus den Quellen kompiliert die ihrerseits wieder Dependencies hat die aber auch erst mal kompiliert werden müssen. Und plötzlich erzählt einem das System, daß es die Lib die man eben erst kompiliert hat leider nicht finden kann. Die Lösung ist ganz einfach, aber die Mechanik die dahintersteckt sollte man zumindest verstanden haben.

Wer das System jedenfalls wirklich kennenlernen will, sollte anfangen Software selbst aus den Quellen zu kompilieren.

Das Problem bei GoboLinux ist weniger, daß man Schwierigkeiten hätte Software die für GoboLinux packetiert wurde auf anderen Distributionen zum Laufen zu kriegen. Das sollte im Normalfall relativ problemlos funktionieren. Problematisch wird es erst, wenn man Software die für Distributionen packetiert wurde die zumindest so einigermaßen dem FHS folgen, auf GoboLinux zum Laufen bekommen will. In dem Fall muß man nämlich die SymLinks die bei Gobo durch den Packetbetreuer gesetzt werden selbst setzen.

Wobei GoboLinux insofern ein modernes System ist, als es sich dem Trend anschließt das System vor dem Nutzer zu verstecken. Häßlich wird es nur, wenn es tatsächlich mal zu Problemen kommt. Ich kann mich an der Stelle noch gut an Irritationen in Zusammenhang mit dem VirtualStore auf Windows-Systemen erinnern. Wer die zugrundeliegende Mechanik nicht versteht, kann da vor Problemen stehen die zunächst einmal sehr mysteriös erscheinen.

 

[RAMSoße]

Als Linux Neuling, klingt das für mich zunächst sehr logisch was da gemacht wurde. Aber warum das alte System so lange Bestand hat wird schon seine Gründe haben. Oder?

 

[Mihawk90]

Vorher muß man dem System nämlich noch mitteilen, an welchen Orten die Libraries überhaupt gesucht werden sollen.

solange sie im $PATH ist

 

[bluedxca93]

Also das System scheint viel mit Symlinks zu arbeiten.
Im Prinzip sind "nur"
PATH=
und LD_LIBRARY_PATH= anders besetzt als in den anderen Linux Versionen.
Jedes Programm-/Bibliothek hat seinen eigenen Prefix und dort werden die Programmdateien abgespeichert. Die ausführbaren Dateien, Bibliotheken werden dann wieder in ein Systemverzeichnis verlinkt.
Damit erreicht man eine Verzeichnisstruktur wo klarer erkennbar wird welche Datei zu welchem Paket in einer bestimmten Version gehört.

Dieser Versuch die Ordnerstruktur von linux grundlegend umzustellen erschwert Kompatibilität mit anderen Distributionen.

Der Aufwand die Pakete zu bauen ist bestimmt enorm. In vielen müssen sicherlich die Dateipfade im Quellcode gepatcht werden. Auch bei jeder Bibliothek neue symlinks zu erstellen ...

 

[Tuxgamer42]

solange sie im $PATH ist

Na Bibliotheken werden (Linux) nicht über $PATH gesucht. In der Regel übrigens auch nicht über LD_LIBRARY_PATH - auch wenn man LD_LIBRARY_PATH benutzen kann um noch schnell paar libs zu laden (@bluedxca93).
Für libs suchen ist 'ld.so' zuständig - /lib, /usr/lib und alles, was in /etc/ld.so.conf steht.

Problematisch wird es erst, wenn man Software die für Distributionen packetiert wurde die zumindest so einigermaßen dem FHS folgen, auf GoboLinux zum Laufen bekommen will. In dem Fall muß man nämlich die SymLinks die bei Gobo durch den Packetbetreuer gesetzt werden selbst setzen.

Aus der GoboLinux FAQ:

Does this mean all programs need to adjusted so that they work with the new layout? Fortunately, the answer is no. Through a mapping of traditional paths into their GoboLinux counterparts, we transparently retain compatibility with the Unix legacy.

Hast GoboLinux /bin, /lib und so weiter. Sind GoboLinux nur eben Symbolik Links und auch noch versteckt. GoboLinux schreibt sogar:

Amusingly, this makes us even more compatible than some more standard-looking distributions. In GoboLinux, all standard paths work for all files, while other distros may struggle with incompatibilites such as scripts breaking when they refer to /usr/bin/foo when the file is actually in /usr/local/bin/foo.

Der Aufwand die Pakete zu bauen ist bestimmt enorm. In vielen müssen sicherlich die Dateipfade im Quellcode gepatcht werden.

Das eigentlich nicht. Software so Bauen, dass z.B. auf /Programs/XXX installiert ging schon immer (vgl --prefix) und der Rest wird sowieso dynamisch geladen.

 

[Serana]

@Mihawk90
Das worauf ich mich bezogen habe ist nicht die PATH-Variable sondern der Mechanismus hinter ldconfig. Wobei sich aber auch die PATH-Variable darauf verläßt, daß der Administrator sämtliche in Frage kommenden Pfade auflistet.

Mein Kritikpunkt ist, daß auch bei Linux meines Erachtens derzeit Bestrebungen im Gange sind um Nutzer und System immer weiter voneinander zu trennen. Während das bei einigen, anscheinend auch hier, auf Zustimmung stößt, befürchte ich, daß wir am Ende nur ein weiteres Windows (wenn auch auf freier Software basierend) haben werden, bei dem die Leute ein System benutzen das sie in keiner Art und Weise irgendwie verstehen. Auch bei den Desktop Environments verfolgt Gnome meiner Ansicht nach genau diesen Ansatz Nutzer und System voneinander abzukoppeln.

 

[bluedxca93]

@Tuxgamer42 ist technisch gesehen korrekt das diese über ld.so geladen werden.Auf den großen Ditributionen sucht das Programm die Dateien trotzdem in den Ordnern wo in der von mir angegebenen Variable stehen in der Regel.

$PATH beschreibt den Ordner wo linux die ausführbaren Dateien "sucht".

Diese Distribution treibt "quasi" das benutzen der --prefix flags z.B bei ./configure auf die Spitze.

In GoboLinux, all standard paths work for all files, while other distros may struggle with incompatibilites such as scripts breaking when they refer to /usr/bin/foo when the file is actually in /usr/local/bin/foo

und genau da liegt später das Problem beim kompilieren von Software und das was ich gemeint habe mit Paketen zu erstellen. Fast jeder Linux Entwickler achtet mindestens darauf das sein Programm mit prefix=/usr läuft und sich kompilieren lässt. Bei einem anderen Ort muss der Quellcode oder das Buildskript möglicherweise angepasst werden. Für ein Paket in einer Version alleine sicher kein Ding aber bei vielen steigt da der Arbeitsaufwand enorm .

Ergänzung (28. Februar 2020)

Auch bei den Desktop Environments verfolgt Gnome meiner Ansicht nach genau diesen Ansatz Nutzer und System voneinander abzukoppeln.

Gnome 3 Shell Menüleisten weg, Datenträger und Orte werden "versteckt". Grundlegende Optionen wie z.B drucken oder Datei öffnen/kopieren fast nur noch über Tastenkürzel erreichbar die Liste ist lang.

Mate oder Cinnamon verfolgen diesen Ansatz bis jetzt nicht vollständig in dieser Intensität(zum Glück).