Kraut und Rüben....

Qbert＠t-online.de

9 Oct 2001 9 Oct '01

12:35

Wer hat sich eigentlich diese haarsträubende Verzeichnisstruktur von Linux ausgedacht und wie alt ist die? Macht die so überhaupt noch Sinn? Ich gewinne immer mehr den Eindruck, das ca. 3/4 des DirTrees überflüssig sind. Ein einziges heilloses Durcheinander. KDE und Gnome sind unter /opt, X unter /usr, Parsec unter /usr/games und Descent3 unter /usr/local/games. Configs, RCs und Umgebungsvariablen verteilen sich homogen auf /etc und /var und ein paar anderen Stellen. Und das sind noch die aufgerämtesten. Sourcen und developer libs vermischen sich mit Applikationen, Apps jenseits von ~ sind auf bestimmte User festgelegt, etc, etc. Hinzu kommt diese seltsame omnipräsente Untertgruppierung in /local. Als ob es auf *nix Sinn macht ausgerechnet via Verzeichnis zwischen lokal beschränkten und im Netz ausführbaren Programmen zu unterscheiden. Regelt man sowas nicht über Usergroups? Würde es nicht auch z.B. Sinn machen unter / ein Verzeichnis festzulegen, wo alles 'reinkommt was im weitesten Sinne zur Entwicklung gehört und alleine erstmal gar nicht lauffähig ist? Für Sourcen, Makefiles, installroutinen, etc.? Dann würde der Rest wahrscheinlich schon durchsichtiger und Standarduser brauchten das alles erstmal garnicht dazunehmen. Gibt es Projekte, die an eine sinnvollen Directory-policy arbeiten? Was ist mit Debian? Die sind doch komplett GPL und müßten doch schon ein bißchen aufgeräumt haben. Wie sieht deren DirTree aus? Nur so ein paar ketzerische Gedanken von einem Linux Newbie...

Show replies by date

Harry Rüter

9 Oct 9 Oct

12:47

Hallo, bitte keine Diskussion um die Verzeichnisstruktur. mfg Harry PS.: Es steht dir frei alles so zu "ordnen" wie es dir gefällt .. PPS.: Tolles Subject Phillip,sowas haben wir hier alle gern ... Phillip Richdale wrote:

...

Wer hat sich eigentlich diese haarsträubende Verzeichnisstruktur von Linux ausgedacht und wie alt ist die? Macht die so überhaupt noch Sinn? Ich gewinne immer mehr den Eindruck, das ca. 3/4 des DirTrees überflüssig sind. Ein einziges heilloses Durcheinander.

Christoph Maurer

12:50

Am Die, 09 Okt 2001, schrieb Phillip Richdale:

...

Wer hat sich eigentlich diese haarsträubende Verzeichnisstruktur von Linux ausgedacht und wie alt ist die?

Vom Prinzip her entspricht sie der Unix-Dateistruktur. SuSE hält sich (mittlerweile) relativ streng an die Linux Standard Base (LSB), wo eine unabhängige Expertengruppe zusammengestellt hat, wie u.a. die Verzeichnisstruktur aussehen sollte.

...

Macht die so überhaupt noch Sinn? Ich gewinne immer mehr den Eindruck, das ca. 3/4 des DirTrees überflüssig sind. Ein einziges heilloses Durcheinander.

Aber nur auf den ersten Blick

...

KDE und Gnome sind unter /opt, X unter /usr, Parsec unter /usr/games und Descent3 unter /usr/local/games. Configs, RCs und Umgebungsvariablen verteilen sich homogen auf /etc und /var und ein paar anderen Stellen. Und das sind noch die aufgerämtesten.

Unter /opt sind optionale Komponenten, die zum Betrieb des Systems nicht unbedingt notwendig sind, es hat sich eingebürgert, daß die großen Desktop Environments sich da installieren, unter /usr sind eigentlich alle Programme und ihre Libs, Shares etc. schön aufgeräumt in Verzeichnissen, Konfigurationsdateien gehören allgemein nach /etc, auch wenn es da sicherlich Ausnahmen gibt.

...

Sourcen und developer libs vermischen sich mit Applikationen, Apps jenseits von ~ sind auf bestimmte User festgelegt, etc, etc.

Letzteres ist erstens nicht ganz richtig (hängt von den Rechten ab), das Prinzip ist aber sinnvoll, Du kannst in Deinem Homeverzeichnes executables halten, die - aus welchem Grund auch immer - nicht systemweit installiert werden sollen.

...

Hinzu kommt diese seltsame omnipräsente Untertgruppierung in /local. Als ob es auf *nix Sinn macht ausgerechnet via Verzeichnis zwischen lokal beschränkten und im Netz ausführbaren Programmen zu unterscheiden. Regelt man sowas nicht über Usergroups?

local bildet die Verz.-Struktur von /usr eine Ebene tiefer noch mal ab und meint in aller Regel, daß dort Programme stehen, die nicht zur Distribution gehören, sondern z.B. selbst kompiliert sind, und das ist extrem sinnvoll, bei mir ist /usr/local eine eigene Partition, und so habe ich, z.B. nach einer Neuinstallation oder sonstigen gravierenden Änderungen am System schön gebündelt die Software, die nicht zur Distri gehört.

...

Würde es nicht auch z.B. Sinn machen unter / ein Verzeichnis festzulegen, wo alles 'reinkommt was im weitesten Sinne zur Entwicklung gehört und alleine erstmal gar nicht lauffähig ist? Für Sourcen, Makefiles, installroutinen, etc.? Dann würde der Rest wahrscheinlich schon durchsichtiger und Standarduser brauchten das alles erstmal garnicht dazunehmen.

Du meinst /usr/src bzw. /usr/local/src?

...

Gibt es Projekte, die an eine sinnvollen Directory-policy arbeiten? Was ist mit Debian? Die sind doch komplett GPL und müßten doch schon ein bißchen aufgeräumt haben. Wie sieht deren DirTree aus?

Wie gesagt, die LSB. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

Thorsten Haude

13:17

Moin, * Christoph Maurer [01-10-09 14:50]:

...

Unter /opt sind optionale Komponenten, die zum Betrieb des Systems nicht unbedingt notwendig sind Da ist der Haken: KDE ist mit Sicherheit 'weniger' optional als tcsh, die Benennung macht also kaum Sinn.

...

local bildet die Verz.-Struktur von /usr eine Ebene tiefer noch mal ab und meint in aller Regel, daß dort Programme stehen, die nicht zur Distribution gehören, sondern z.B. selbst kompiliert sind Stammt das nicht aus der Zeit, als Rechner noch vernetzt waren? /usr wird von allen gemountet, in /usr/local kommen Dinge, die man nur auf einem Host braucht?

Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin

Christoph Maurer

13:25

Am Die, 09 Okt 2001, schrieb Thorsten Haude:

...

Moin,

* Christoph Maurer [01-10-09 14:50]:

...
Unter /opt sind optionale Komponenten, die zum Betrieb des Systems nicht unbedingt notwendig sind Da ist der Haken: KDE ist mit Sicherheit 'weniger' optional als tcsh, die Benennung macht also kaum Sinn.

Darüber kann man sicher streiten, in der heutigen Praxis ist es wohl so, daß nach /opt große zusammenhängende Programmpakete kommen. Was sagt eigentlich der FHS dazu?

...

...
local bildet die Verz.-Struktur von /usr eine Ebene tiefer noch mal ab und meint in aller Regel, daß dort Programme stehen, die nicht zur Distribution gehören, sondern z.B. selbst kompiliert sind Stammt das nicht aus der Zeit, als Rechner noch vernetzt waren? /usr wird von allen gemountet, in /usr/local kommen Dinge, die man nur auf einem Host braucht?

Hört sich plausibel an, paßt auch dazu, daß z.B. die Dateien des lokalen Webservers unter /usr/local liegen. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

Dieter Kluenter

10 Oct 10 Oct

14:34

Hallo, christoph-maurer@gmx.de (Christoph Maurer) writes:

...

Am Die, 09 Okt 2001, schrieb Thorsten Haude:

...
Moin,

* Christoph Maurer [01-10-09 14:50]:

...
Unter /opt sind optionale Komponenten, die zum Betrieb des Systems nicht unbedingt notwendig sind Da ist der Haken: KDE ist mit Sicherheit 'weniger' optional als tcsh, die Benennung macht also kaum Sinn.

Darüber kann man sicher streiten, in der heutigen Praxis ist es wohl so, daß nach /opt große zusammenhängende Programmpakete kommen. Was sagt eigentlich der FHS dazu?

Der Filesystem-Hierachy-Standard sagt dazu /opt is reserved for the installation of add-on application software packages. The use of /opt for add-on software is a well-established practice in the UNIX community... Demnach ist also die Installation von KDE und StarOffice in /opt FHS konform. -Dieter -- chmod +x /usm/bin/laden

ralf

15:29

Hi,

...

From: Dieter Kluenter [mailto:dieter@incode.com] christoph-maurer@gmx.de (Christoph Maurer) writes:

...
Am Die, 09 Okt 2001, schrieb Thorsten Haude:

...
Moin,

...
Unter /opt sind optionale Komponenten, die zum Betrieb des Systems nicht unbedingt notwendig sind Da ist der Haken: KDE ist mit Sicherheit 'weniger'

* Christoph Maurer [01-10-09 14:50]: optional als tcsh, die Benennung macht also kaum Sinn. IMHO schon. Wenn ich zwischen tcsh und kde wählen dürfte, würde tcsh installiert und wenn das teil nicht läuft dann eher windoof. Bevor ich das kde-gemülle auf die kiste lass, würd ich den rechner eher aus lassen ;)) KDE ist wirklich optional. Zumal es sich langsam einer mittleren Bugfree-Zeit nähert, die doch an windoof grenzt.

...

...
Darüber kann man sicher streiten, in der heutigen Praxis ist es wohl so, daß nach /opt große zusammenhängende Programmpakete kommen. Was sagt eigentlich der FHS dazu?

Der Filesystem-Hierachy-Standard sagt dazu

/opt is reserved for the installation of add-on application software packages. The use of /opt for add-on software is a well-established practice in the UNIX community...

Demnach ist also die Installation von KDE und StarOffice in /opt FHS konform.

Sehe ich genauso. Die Kiste muss ohne /opt noch sauber bedienbar sein und das ist wohl eindeutig der Fall.

...

-- chmod +x /usm/bin/laden *g*

Gruss Ralf

Thorsten Haude

16:01

Moin, * ralf [01-10-10 17:29]:

...

...
...
...
Da ist der Haken: KDE ist mit Sicherheit 'weniger' optional als tcsh, die Benennung macht also kaum Sinn. IMHO schon. YHO ist leider recht unrepräsentativ.

...

Wenn ich zwischen tcsh und kde wählen dürfte, würde tcsh installiert und wenn das teil nicht läuft dann eher windoof. Bevor ich das kde-gemülle auf die kiste lass, würd ich den rechner eher aus lassen ;)) KDE ist wirklich optional. Zumal es sich langsam einer mittleren Bugfree-Zeit nähert, die doch an windoof grenzt. Ich weiß nicht recht, was ich von Dir halten soll. Du würdest lieber Windows benutzen als Linux mit bash, ksh oder zsh; Du nennst Windows einigermaßen kindisch "Windoof", schreibst diese Mail aber mit Outlook.

...

...
Demnach ist also die Installation von KDE und StarOffice in /opt FHS konform. Sehe ich genauso. Darum geht es nicht, es ist schlicht inkonsistent.

...

Die Kiste muss ohne /opt noch sauber bedienbar sein und das ist wohl eindeutig der Fall. Die Kiste ist auch ohne tcsh ganz hervorragend bedienbar.

Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin

Martin Schmitz

9 Oct 9 Oct

15:26

Thorsten Haude writes:

...

Da ist der Haken: KDE ist mit Sicherheit 'weniger' optional als tcsh, die Benennung macht also kaum Sinn.

Wie kommst Du denn auf _die_ Idee? Auf meinen Systemen gibt es weder KDE noch tcsh... Davon ab, ist /opt nicht eine (fast) rein SuSE-spezifische Angelegenheit. Bei Debian gibt es kein /opt und auf RedHat-Systemen hab' ich sowas glaub ich auch noch nicht gesehen. Alles was SuSE dahin packt gehört normalerweise ebenfalls unter /usr. Gefällt mir aber nicht schlecht bei SuSE, denn KDE z.B. ist ja unter /opt/kde, bei den anderen Systemen ist es komplett über /usr verteilt (/usr/bin, /usr/share, etc...). -- Martin Schmitz --- Proskauer Straße 28 --- 10247 Berlin --- (030) 62 70 64 48 "Computers are useless. They can only give you answers." -- Pablo Picasso

Thorsten Strusch

16:06

Hi Martin, Martin Schmitz wrote:

...

Thorsten Haude writes:

...
Da ist der Haken: KDE ist mit Sicherheit 'weniger' optional als tcsh, die Benennung macht also kaum Sinn.

Wie kommst Du denn auf _die_ Idee? Auf meinen Systemen gibt es weder KDE noch tcsh...

Davon ab, ist /opt nicht eine (fast) rein SuSE-spezifische Angelegenheit. Bei Debian gibt es kein /opt und auf RedHat-Systemen hab' ich sowas glaub ich auch noch nicht gesehen.

Richtig, bei der aktuellen RH 7.1 ist /opt zwar angelegt, aber leer. Gruß Thorsten

Thorsten Haude

12:55

Moin, * Phillip Richdale [01-10-09 14:35]:

...

Macht die so überhaupt noch Sinn? In weiten Teilen schon, es gibt halt Software, die sich nicht daran hält. Den Sinn von /opt habe ich allerdings auch noch nie verstanden.

...

Gibt es Projekte, die an eine sinnvollen Directory-policy arbeiten? Jepp, dieses File Hierarchy Dingens

...

Was ist mit Debian? Die sind doch komplett GPL und müßten doch schon ein bißchen aufgeräumt haben. Häh? Wo ist da der Zusammenhang?

Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin

Jörg Lippmann

13:02

...

* Phillip Richdale [01-10-09 14:35]:

...
Macht die so überhaupt noch Sinn?

http://www.pathname.com/fhs/ ... öffnet die Augen mit freundlichen Grüßen Jörg Lippmann -- dienstlich: joerg.lippmann@o3-software.de · mobil 0179.4125552 O³ Software GmbH und Co. KG · Eichkamp 1 · 24217 Schönberg http://www.o3-software.de · fon 04344.41417.5 · fax 04344.5385

Martin Schmitz

15:29

Thorsten Haude writes:

...

Moin,

* Phillip Richdale [01-10-09 14:35]:

...
Macht die so überhaupt noch Sinn? In weiten Teilen schon, es gibt halt Software, die sich nicht daran hält. Den Sinn von /opt habe ich allerdings auch noch nie verstanden.

s.o., z.B. um KDE zu entfernen reicht _im_weitesten_Sinne_ ein rm -rf /opt/kde, wenn es unter /usr ist, hast Du's schön verteilt in den einzelnen Verzeichnissen unterhalb von /usr. -- Martin Schmitz --- Proskauer Straße 28 --- 10247 Berlin --- (030) 62 70 64 48 "Computers are useless. They can only give you answers." -- Pablo Picasso

Thorsten Haude

15:52

Moin, * Martin Schmitz [01-10-09 17:29]:

...

Thorsten Haude writes:

...
In weiten Teilen schon, es gibt halt Software, die sich nicht daran hält. Den Sinn von /opt habe ich allerdings auch noch nie verstanden. s.o., z.B. um KDE zu entfernen reicht _im_weitesten_Sinne_ ein rm -rf /opt/kde, Um KDE zu entfernen, reicht ein rpm <irgendwas> eine weiter Methode ist nicht nötig. Nochmal: Besonders störend ist die Inkonsistenz.

Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin

Waldemar Brodkorb

18:25

Hallo Martin , Hallo *,

...

From the keyboard of Martin,

...

Thorsten Haude writes:

...
Moin,

* Phillip Richdale [01-10-09 14:35]:

...
Macht die so überhaupt noch Sinn? In weiten Teilen schon, es gibt halt Software, die sich nicht daran hält. Den Sinn von /opt habe ich allerdings auch noch nie verstanden.

s.o., z.B. um KDE zu entfernen reicht _im_weitesten_Sinne_ ein rm -rf /opt/kde, wenn es unter /usr ist, hast Du's schön verteilt in den einzelnen Verzeichnissen unterhalb von /usr.

IMHO Totaler Bullshit¹. (in deutsch: sehr schlechtes Beispiel!) Wenn du eine Distribution installiert hast, hast du im Allgemeinen einen Paketmanager, der das deinstallieren für dich übernimmt, egal ob er rpm, dpkg oder pkg-add heißt. bye Waldemar ¹ Ausnahme du verwendest entweder ein Linux From Scratch System ohne Paketmanagement oder du bist ziemlich doof und nutzt die Vorteile eines Paketmanagers nicht!

Martin Schmitz

22:15

Waldemar Brodkorb writes:

...

...
s.o., z.B. um KDE zu entfernen reicht _im_weitesten_Sinne_ ein rm -rf /opt/kde, wenn es unter /usr ist, hast Du's schön verteilt in den einzelnen Verzeichnissen unterhalb von /usr.

IMHO Totaler Bullshit¹. (in deutsch: sehr schlechtes Beispiel!) Wenn du eine Distribution installiert hast, hast du im Allgemeinen einen Paketmanager, der das deinstallieren für dich übernimmt, egal ob er rpm, dpkg oder pkg-add heißt.

Schon mal mit Debian unstable gearbeitet? Da kann es schon mal ganz sinnvoll sein, wenn nach einem Update nichts mehr funktioniert (auch und vor allem die Paketverwaltung nicht mehr), zu wissen, was genau wohin gehört. Da hätt' ich mir schon öfter gewünscht, zumindest solch' große Projekte wie KDE, Gnome etc. aus dem Weg zu haben. Außerdem gefällt mir der Gedanke, _alles_ was nicht zum Produktivsystem gehört (Netscape, Mozilla, StarOffice, KDE etc...), unterhalb _eines_ zum jeweiligen Projekt gehörenden Verzeichnisses zu haben. Als ich noch mit Slackware gearbeitet habe, hätte ich das bestimmt auch begrüßt (und hab' es teilweise auch so gehandhabt). Du nennst zwar pkg-add, aber mal ehrlich, Paketmanagement kann man das ja wohl eher nicht nennen. -- Martin Schmitz --- Proskauer Straße 28 --- 10247 Berlin --- (030) 62 70 64 48 "Computers are useless. They can only give you answers." -- Pablo Picasso

Waldemar Brodkorb

10 Oct 10 Oct

11:03

Hallo Martin, Hallo *,

...

From the keyboard of Martin,

...

Waldemar Brodkorb writes:

...
...
s.o., z.B. um KDE zu entfernen reicht _im_weitesten_Sinne_ ein rm -rf /opt/kde, wenn es unter /usr ist, hast Du's schön verteilt in den einzelnen Verzeichnissen unterhalb von /usr.

IMHO Totaler Bullshit¹. (in deutsch: sehr schlechtes Beispiel!) Wenn du eine Distribution installiert hast, hast du im Allgemeinen einen Paketmanager, der das deinstallieren für dich übernimmt, egal ob er rpm, dpkg oder pkg-add heißt.

Schon mal mit Debian unstable gearbeitet?

Täglich seit fast einem Jahr.

...

Da kann es schon mal ganz sinnvoll sein, wenn nach einem Update nichts mehr funktioniert (auch und vor allem die Paketverwaltung nicht mehr), zu wissen, was genau wohin gehört. Da hätt' ich mir schon öfter gewünscht, zumindest solch' große Projekte wie KDE, Gnome etc. aus dem Weg zu haben.

Kann ich nicht nachvollziehen, warum du bei einem nicht funktionierenden System, was durchaus mal vorkommt bei sid, gerade KDE und Gnome aus dem Weg haben willst?

...

Außerdem gefällt mir der Gedanke, _alles_ was nicht zum Produktivsystem gehört (Netscape, Mozilla, StarOffice, KDE etc...), unterhalb _eines_ zum jeweiligen Projekt gehörenden Verzeichnisses zu haben.

Das schließt sich ja nicht aus ;) Da bei Debian sowieso kein Staroffice, jdk, ... per default dabei sind sieht das bei mir eh so aus: ls -la /opt/ total 60 drwxr-xr-x 12 root root 4096 30. Sep 07:08 . drwxr-xr-x 28 root root 4096 29. Sep 19:37 .. drwxr-xr-x 5 root root 4096 5. Apr 2001 bluej drwxrwxr-x 2 root root 4096 14. Apr 14:01 flash5 drwxr-xr-x 11 root root 4096 5. Apr 2001 forte4j drwxr-xr-x 8 root root 4096 27. Nov 2000 jdk-ibm drwxrwxr-x 9 root root 4096 2. Apr 2001 jdk-sun drwxr-xr-x 2 root root 16384 30. Sep 07:04 lost+found drwxr-sr-x 6 root root 4096 18. Nov 2000 office52

...

Als ich noch mit Slackware gearbeitet habe, hätte ich das bestimmt auch begrüßt (und hab' es teilweise auch so gehandhabt). Du nennst zwar pkg-add, aber mal ehrlich, Paketmanagement kann man das ja wohl eher nicht nennen.

Nö, nicht wirklich hast Recht, aber bei anderen Unices ist pkgadd trotzdessen hilfreich (Solaris,(Free|Open|Net)BSD) bye Waldemar

Sebastian Helms

15:29

Moin Martin, * Martin Schmitz schrieb am 10 Oct 2001:

...

Waldemar Brodkorb writes:

...
IMHO Totaler Bullshit¹. (in deutsch: sehr schlechtes Beispiel!) Wenn du eine Distribution installiert hast, hast du im Allgemeinen einen Paketmanager, der das deinstallieren für dich übernimmt, egal ob er rpm, dpkg oder pkg-add heißt.

[...]

Außerdem gefällt mir der Gedanke, _alles_ was nicht zum Produktivsystem gehört (Netscape, Mozilla, StarOffice, KDE etc...), unterhalb _eines_ zum jeweiligen Projekt gehörenden Verzeichnisses zu haben.

Wenn ich ein Paket selber kompiliere und installiere, dann mach ich das immer unter /usr/local/paketname. Wenn ich es brauche, dann linke ich - automatisch *g* - alle bin/sbin/lib/man/... Dateien nach /usr/local/(bin|sbin|lib|man|...) usw... Dann kann man bei Bedarf einfach den gesamten Baum und mit einem kleinen Skript alle leeren Symlinks löschen und gut :-) Gruß, Sebastian -- Do not meddle in the affairs of Wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/

B.Brodesser＠t-online.de

9 Oct 9 Oct

15:20

* Phillip Richdale schrieb am 09.Okt.2001:

...

Wer hat sich eigentlich diese haarsträubende Verzeichnisstruktur von Linux ausgedacht und wie alt ist die?

Teilweise stammt sie von Denis M. Ritchie und Ken Thomson, die Erfinder von UNIX. Das war in den späten 60er Jahren. Genauer /usr, /bin, /lib, /dev, /tmp, /proc, /mnt und /etc gab es schon seit längerem. (Min. seit den späten 70er) Damals gab es noch kein /var, /home und /opt, das war alles in /usr. Besonders das fehlende /home war sehr unbefriedigend. Auch gab es kein /boot und kein /root, das lag unmittelbar in / und kein /sbin, das lag in /etc. Alles nicht als Unterverzeichnisse, sondern die Dateien und Verzeichnisse, die jetzt z.B in /var liegen, lagen in /usr neben denen, die auch jetzt da liegen.

...

Macht die so überhaupt noch Sinn?

imho schon. Jedenfalls das meiste. Die Notwendigkeit von /opt habe ich auch nicht verstanden.

...

Ich gewinne immer mehr den Eindruck, das ca. 3/4 des DirTrees überflüssig sind. Ein einziges heilloses Durcheinander. KDE und Gnome sind unter /opt, X unter /usr, Parsec unter /usr/games und Descent3 unter /usr/local/games. Configs, RCs und Umgebungsvariablen verteilen sich homogen auf /etc und /var und ein paar anderen Stellen.

Konfigurationsdateien sollen sich alle in /etc befinden, oder in Home natürlich.

...

Und das sind noch die aufgerämtesten.

Hm, und was ist mit /dev?

...

Sourcen und developer libs vermischen sich mit Applikationen, Apps jenseits von ~ sind auf bestimmte User festgelegt, etc, etc.

Manchmal habe ich allerdings auch den Eindruck, daß sich nicht alle Programierer mit den UNIX-Geflogenheit auskennen. :((

...

Hinzu kommt diese seltsame omnipräsente Untertgruppierung in /local. Als ob es auf *nix Sinn macht ausgerechnet via Verzeichnis zwischen lokal beschränkten und im Netz ausführbaren Programmen zu unterscheiden. Regelt man sowas nicht über Usergroups?

In /usr/local liegen Programme die nicht zu der Distribution gehören, sondern selber übersetzt hat oder gar selber geschrieben. Ein Sysadmin hat immer paar Skripte, die er der Allgemeinheit zur Verfügung stellt. Wo gehören die wohl hin? In /usr/local eben. Die Unterscheidung zwichen lokalem Rechner und Netzwerk ist bei /usr und /var wichtig. In /usr stehen Netzwerkweite Dateien, die nur gelesen werden, in /var stehen Dateien, die beschrieben werden und von Rechner zu Rechner verschieden sind.

...

Würde es nicht auch z.B. Sinn machen unter / ein Verzeichnis festzulegen, wo alles 'reinkommt was im weitesten Sinne zur Entwicklung gehört und alleine erstmal gar nicht lauffähig ist? Für Sourcen, Makefiles, installroutinen, etc.? Dann würde der Rest wahrscheinlich schon durchsichtiger und Standarduser brauchten das alles erstmal garnicht dazunehmen.

Gibt es doch, das ist /urs/local. Das es unter /usr steht hat die Bewandnis, daß alles was nicht schon beim booten benötigt wird unter /usr steht, denn /usr ist oftmals eine eigene Partition. Eigene Partitionen für /usr, /opt, /var, /tmp und /home ist Sinnvoll. /dev, /etc, /bin, /sbin und /lib dürfen auf keiner anderen Partiton sein, da sie schon zu einem frühen bootzeitpunkt benötigt werden, wo nichts anderes als / gemountet ist. /root woanders zu setzen ergibt nicht viel Sinn. /mnt ist nur ein Mountpoint und /proc ist ein eigenes Dateisystem.

...

Gibt es Projekte, die an eine sinnvollen Directory-policy arbeiten? Was ist mit Debian? Die sind doch komplett GPL und müßten doch schon ein bißchen aufgeräumt haben. Wie sieht deren DirTree aus?

Das meiste ist UNIX-weit üblich. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9

Ralf Corsepius

11 Oct 11 Oct

05:30

Am Die, 2001-10-09 um 17.20 schrieb Bernd Brodesser:

...

* Phillip Richdale schrieb am 09.Okt.2001:

...
Wer hat sich eigentlich diese haarsträubende Verzeichnisstruktur von Linux ausgedacht und wie alt ist die? Im Detail ziemlich neu (Vgl. FHS und LSB), mit langer Historie.

...

...
Macht die so überhaupt noch Sinn?

imho schon. Jedenfalls das meiste. Einiges ist "nicht so ohne weiteres änderbare" Historie (z.B. das X11 Layout)

...

Die Notwendigkeit von /opt habe ich auch nicht verstanden.

Das ist relativ einfach: /usr beinhaltet das eigentliche System /usr/local dient dazu, Installationen in /usr durch lokale Installationen zu überladen, ohne unter /usr eingreifen zu müssen. /opt dient dazu, optioniale Add-On-Pakete konfliktfrei installieren zu können. Add-On-Pakete sind dabei solche, die nicht als integraler Bestandteil des OS angesehen werden. Was darunter fällt, ist allerdings oft Ansichtssache.

...

...
Hinzu kommt diese seltsame omnipräsente Untertgruppierung in /local. Als ob es auf *nix Sinn macht ausgerechnet via Verzeichnis zwischen lokal beschränkten und im Netz ausführbaren Programmen zu unterscheiden.

Ja. Zum einen braucht nicht jeder User im Netz jedes Programm, weiterhin gibt es Programme, die nur auf einzelnen Maschinen installiert werden können oder dürfen (Lizenzen) usw.

...

In /usr/local liegen Programme die nicht zu der Distribution gehören, sondern selber übersetzt hat oder gar selber geschrieben.

Strenggenommen ist das falsch (vgl. oben) und stimmt nur mit Einschränkungen. Ralf

B.Brodesser＠t-online.de

06:48

* Ralf Corsepius schrieb am 11.Okt.2001:

...

Am Die, 2001-10-09 um 17.20 schrieb Bernd Brodesser:

...
* Phillip Richdale schrieb am 09.Okt.2001:

...

...
Die Notwendigkeit von /opt habe ich auch nicht verstanden.

...

Das ist relativ einfach:

/usr beinhaltet das eigentliche System

/usr/local dient dazu, Installationen in /usr durch lokale Installationen zu überladen, ohne unter /usr eingreifen zu müssen.

/opt dient dazu, optioniale Add-On-Pakete konfliktfrei installieren zu können. Add-On-Pakete sind dabei solche, die nicht als integraler Bestandteil des OS angesehen werden. Was darunter fällt, ist allerdings oft Ansichtssache.

Warum liegt denn z.B TeX nicht unter /opt? Ist bestimmt nicht nötig. Streng genommen ist alles was unter /usr liegt nicht nötig, denn / muß ja auch ohne /opt, /usr, /var, /tmp und /home lauffähig sein.

...

...
In /usr/local liegen Programme die nicht zu der Distribution gehören, sondern selber übersetzt hat oder gar selber geschrieben.

Strenggenommen ist das falsch (vgl. oben) und stimmt nur mit Einschränkungen.

Ach und wo würdest Du Netzweite, bzw. Maschienenweite Programme, die nicht nur für einen User da sind, sondern von allen User genutzt werden sollen hinlegen? Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: http://localhost/doc/sdb/de/html/index.html | mit Apache: http://localhost/doc/sdb/de/html/key_form.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2

Ralf Corsepius

08:45

Am Don, 2001-10-11 um 08.48 schrieb Bernd Brodesser:

...

* Ralf Corsepius schrieb am 11.Okt.2001:

...
Am Die, 2001-10-09 um 17.20 schrieb Bernd Brodesser:

...
* Phillip Richdale schrieb am 09.Okt.2001:

...
...
Die Notwendigkeit von /opt habe ich auch nicht verstanden.

...
Das ist relativ einfach:

/usr beinhaltet das eigentliche System

/usr/local dient dazu, Installationen in /usr durch lokale Installationen zu überladen, ohne unter /usr eingreifen zu müssen.

/opt dient dazu, optioniale Add-On-Pakete konfliktfrei installieren zu können. Add-On-Pakete sind dabei solche, die nicht als integraler Bestandteil des OS angesehen werden. Was darunter fällt, ist allerdings oft Ansichtssache.

Warum liegt denn z.B TeX nicht unter /opt? Ja, der Einwand ist berechtigt - Es spricht einiges dafür TeX nach /opt installieren zu wollen und wird auch auf Systemen, auf denen TeX nicht standard-mässig installiert ist auch oft so gemacht. In diesem speziellen Fall ist es aber ähnlich wie bei X11 weitestgehend Historie (/opt gab es unter BSD-Unixen nicht.)

...

Ist bestimmt nicht nötig. Streng genommen ist alles was unter /usr liegt nicht nötig, denn / muß ja auch ohne /opt, /usr, /var, /tmp und /home lauffähig sein. Bootfähig wäre das Stichwort. Unter /usr sollte alles liegen, was Bestandteil des OS/der Distribution ist aber nicht unmittelbar zum Booten benötigt wird.

Dass SuSE kde und gnome unter /opt installiert und nicht (wie andere Distributionen unter /usr), ist Ausdruck, dass SuSE kde und gnome als Add-Ons betrachtet und nicht als integrale Bestandteile ihre Distribution. IMHO, in erster Linie Ansichtssache. Ein zweiter Grund wäre, dass /usr die Tendenz hat "vollzulaufen" und diese Situation durch Auslagerung grosser Pakete auf andere Verzeichnisse entspannt werden kann.

...

...
...
In /usr/local liegen Programme die nicht zu der Distribution gehören, sondern selber übersetzt hat oder gar selber geschrieben.

Strenggenommen ist das falsch (vgl. oben) und stimmt nur mit Einschränkungen.

Ach und wo würdest Du Netzweite, bzw. Maschienenweite Programme, die nicht nur für einen User da sind, sondern von allen User genutzt werden sollen hinlegen? Kommt darauf an - Es gibt keine Vorschrift, die genau vorgibt, was wo zu installieren ist. Kandidaten zur Installation wären /usr, /usr/local, /usr/local/<paket>, /opt/<paket>.

/usr/local hat eine spezielle Bedeutung, die sich u.a. dadurch manifestiert, dass inbs./usr/local/bin vor /usr/bin in $PATH, /usr/local/lib vor /usr/lib in Library-Suchpfaden und /usr/local/include vor /usr/include in Include-Suchpfaden liegen => Nur ist das genau das, was (Insb. Einzelplatz-) User normalerweise wollen (Eigene Pakete sollen andere ersetzen). D.h. /usr/local ist für bindende maschinenweite Installationen geeignet (Im Sinn von "Der Admin weiss es besser, der User soll auf dieser Maschine diese Tools nutzen", er will aber nicht in die Distribution/das OS eingreifen und installiert sie deshalb nicht nach /usr). /opt/<paket> und /usr/local/<paket> sind funktionell gleichwertig, gleichgültig ob netzwerkweit oder nicht. Der FHS tendiert zu /opt/<paket>. Ralf

B.Brodesser＠t-online.de

11:51

* Ralf Corsepius schrieb am 11.Okt.2001:

...

Am Don, 2001-10-11 um 08.48 schrieb Bernd Brodesser:

...

...
Warum liegt denn z.B TeX nicht unter /opt? Ja, der Einwand ist berechtigt - Es spricht einiges dafür TeX nach /opt installieren zu wollen und wird auch auf Systemen, auf denen TeX nicht standard-mässig installiert ist auch oft so gemacht.

Gleiches könnte man für zig andere Programme sagen. Und weil es kein scharfes Kriterium gibt, daß zwichen /usr und /opt entscheidet, finde ich es nicht gut zu trennen. Ich sehe auch keien Notwendigkeit.

...

In diesem speziellen Fall ist es aber ähnlich wie bei X11 weitestgehend Historie (/opt gab es unter BSD-Unixen nicht.)

Unter System V Releas 4 auch nicht. Von System III, Version 7 und Version 6 wollen wir lieber erst gar nicht sprechen. Nun ja, BSD baut ja auch auf Version 6 auf.

...

...
Ist bestimmt nicht nötig. Streng genommen ist alles was unter /usr liegt nicht nötig, denn / muß ja auch ohne /opt, /usr, /var, /tmp und /home lauffähig sein.

...

Bootfähig wäre das Stichwort. Unter /usr sollte alles liegen, was Bestandteil des OS/der Distribution ist aber nicht unmittelbar zum Booten benötigt wird.

Wenn man booten kann, kann man auch damit arbeiten. Jedenfalls wenn einem das ausreicht. Wenn nicht, dann müssen noch andere Pakete her. Das gilt aber für die in /opt in gleicher Weise.

...

Dass SuSE kde und gnome unter /opt installiert und nicht (wie andere Distributionen unter /usr), ist Ausdruck, dass SuSE kde und gnome als Add-Ons betrachtet und nicht als integrale Bestandteile ihre Distribution.

Und gimp ist integraler Bestandteil? Etliche Spiele auch?

...

IMHO, in erster Linie Ansichtssache. Ein zweiter Grund wäre, dass /usr die Tendenz hat "vollzulaufen" und diese Situation durch Auslagerung grosser Pakete auf andere Verzeichnisse entspannt werden kann.

Wie meinst Du das?

...

...
Ach und wo würdest Du Netzweite, bzw. Maschienenweite Programme, die nicht nur für einen User da sind, sondern von allen User genutzt werden sollen hinlegen?

...

Kommt darauf an - Es gibt keine Vorschrift, die genau vorgibt, was wo zu installieren ist. Kandidaten zur Installation wären /usr, /usr/local, /usr/local/<paket>, /opt/<paket>.

/usr/local hat eine spezielle Bedeutung, die sich u.a. dadurch manifestiert, dass inbs./usr/local/bin vor /usr/bin in $PATH, /usr/local/lib vor /usr/lib in Library-Suchpfaden und /usr/local/include vor /usr/include in Include-Suchpfaden liegen => Nur ist das genau das, was (Insb. Einzelplatz-) User normalerweise wollen (Eigene Pakete sollen andere ersetzen).

Dafür gibt es aber auch ~/bin

...

D.h. /usr/local ist für bindende maschinenweite Installationen geeignet (Im Sinn von "Der Admin weiss es besser, der User soll auf dieser Maschine diese Tools nutzen", er will aber nicht in die Distribution/das OS eingreifen und installiert sie deshalb nicht nach /usr).

Ja, so sehe ich es auch.

...

/opt/<paket> und /usr/local/<paket> sind funktionell gleichwertig, gleichgültig ob netzwerkweit oder nicht. Der FHS tendiert zu /opt/<paket>.

hmm. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

Ralf Corsepius

12:52

Am Don, 2001-10-11 um 13.51 schrieb Bernd Brodesser:

...

* Ralf Corsepius schrieb am 11.Okt.2001:

...
Am Don, 2001-10-11 um 08.48 schrieb Bernd Brodesser:

...
...
Warum liegt denn z.B TeX nicht unter /opt? Ja, der Einwand ist berechtigt - Es spricht einiges dafür TeX nach /opt installieren zu wollen und wird auch auf Systemen, auf denen TeX nicht standard-mässig installiert ist auch oft so gemacht.

Gleiches könnte man für zig andere Programme sagen. Und weil es kein scharfes Kriterium gibt, daß zwichen /usr und /opt entscheidet, finde ich es nicht gut zu trennen. Ich sehe auch keien Notwendigkeit. Hier ist Distributor das Stichwort. Normalerweise sollten Distris alles, was nicht zum Booten benötigt wird nach /usr installieren. Normalerweise sind es Dritte, die nach /opt installieren, da denen /opt/<paket> das Leben ganz erheblich erleichtert.

Ansonsten solltest Du bedenken, dass Du es von Linux gewohnt bist, dass zwar einerseits (fast) alles aus einer Hand kommt (Distributor), die Distributoren aber anderseits in der Regel die Freiheit haben, zu wählen, was Sie wohin installieren wollen (Quellcode). Auf kommerziellen Unixen ist dem nicht so, weshalb Dritte ein Problem haben, geeignete Installationspunkte zu finden. /opt bietet sich da als Ausweg an.

...

...
In diesem speziellen Fall ist es aber ähnlich wie bei X11 weitestgehend Historie (/opt gab es unter BSD-Unixen nicht.)

Unter System V Releas 4 auch nicht. Von System III, Version 7 und Version 6 wollen wir lieber erst gar nicht sprechen. Nun ja, BSD baut ja auch auf Version 6 auf. Ich habe /opt zum ersten Mal unter Solaris gesehen. Den genauen Ursprung kenne ich allerdings auch nicht.

...

...
Dass SuSE kde und gnome unter /opt installiert und nicht (wie andere Distributionen unter /usr), ist Ausdruck, dass SuSE kde und gnome als Add-Ons betrachtet und nicht als integrale Bestandteile ihre Distribution.

Und gimp ist integraler Bestandteil? Etliche Spiele auch? SuSE hat sich aus mir unerfindlichen Gründen dazu entschieden Qt und gtk unter /usr zu installieren, kde und gnome aber nicht (gimp ist ein rein gtk-basiertes Tool)

...

...
IMHO, in erster Linie Ansichtssache. Ein zweiter Grund wäre, dass /usr die Tendenz hat "vollzulaufen" und diese Situation durch Auslagerung grosser Pakete auf andere Verzeichnisse entspannt werden kann.

Wie meinst Du das? Traditonell sammelt sich unter /usr alles mögliche an, so dass Platten/Partitionen im Laufe der Zeit belegt sind. Deshalb bietet es sich als einfacher Ausweg an /opt und /usr auf verschiedene Platten/Partitionen zu legen oder eben, wie bei SuSE geschehen, grosse Pakete ala Kde, Gnome, SO, NS nicht in /usr einzuflechten, sondern unter /opt/<gemeinsame-wurzel> zu installieren.

...

...
...
Ach und wo würdest Du Netzweite, bzw. Maschienenweite Programme, die nicht nur für einen User da sind, sondern von allen User genutzt werden sollen hinlegen?

...
Kommt darauf an - Es gibt keine Vorschrift, die genau vorgibt, was wo zu installieren ist. Kandidaten zur Installation wären /usr, /usr/local, /usr/local/<paket>, /opt/<paket>.

/usr/local hat eine spezielle Bedeutung, die sich u.a. dadurch manifestiert, dass inbs./usr/local/bin vor /usr/bin in $PATH, /usr/local/lib vor /usr/lib in Library-Suchpfaden und /usr/local/include vor /usr/include in Include-Suchpfaden liegen => Nur ist das genau das, was (Insb. Einzelplatz-) User normalerweise wollen (Eigene Pakete sollen andere ersetzen).

Dafür gibt es aber auch ~/bin Maschinenweit - Nicht Userweit! ~/bin wäre userweit (d.h. je nach Layout eines Netzwerkes architektur- und maschinen-unabhängig.)

Ralf

B.Brodesser＠t-online.de

13:52

* Ralf Corsepius schrieb am 11.Okt.2001:

...

Am Don, 2001-10-11 um 13.51 schrieb Bernd Brodesser:

...

Hier ist Distributor das Stichwort. Normalerweise sollten Distris alles, was nicht zum Booten benötigt wird nach /usr installieren. Normalerweise sind es Dritte, die nach /opt installieren, da denen /opt/<paket> das Leben ganz erheblich erleichtert.

Das ist ein Argument, das sehe ich ein. Eigene Skripte würde ich aber immer noch nach /usr/local packen.

...

Ansonsten solltest Du bedenken, dass Du es von Linux gewohnt bist, dass zwar einerseits (fast) alles aus einer Hand kommt (Distributor), die Distributoren aber anderseits in der Regel die Freiheit haben, zu wählen, was Sie wohin installieren wollen (Quellcode). Auf kommerziellen Unixen ist dem nicht so, weshalb Dritte ein Problem haben, geeignete Installationspunkte zu finden. /opt bietet sich da als Ausweg an.

Ja.

...

...
Und gimp ist integraler Bestandteil? Etliche Spiele auch?

...

SuSE hat sich aus mir unerfindlichen Gründen dazu entschieden Qt und gtk unter /usr zu installieren, kde und gnome aber nicht (gimp ist ein rein gtk-basiertes Tool)

Ok, durch und durch unlogisch, das ist das Problem, daß ich mit SuSE und /opt habe.

...

...
Dafür gibt es aber auch ~/bin Maschinenweit - Nicht Userweit! ~/bin wäre userweit (d.h. je nach Layout eines Netzwerkes architektur- und maschinen-unabhängig.)

Ja, klar. Für total chaotisch halte ich übrigens auch /usr/lib. Einerseits sind da Libraries, was man erwarten könnte, aber dann sind da auch noch Verzeichnisse von allen möglichen Programmen, wo irgendwelche Datenbestände drin liegen. Bernd -- Homepages von deutschsprachigen Linux-Gurus: Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/ Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10

Christoph Maurer

14:07

Am Don, 11 Okt 2001, schrieb Bernd Brodesser:

...

* Ralf Corsepius schrieb am 11.Okt.2001:

...
Am Don, 2001-10-11 um 13.51 schrieb Bernd Brodesser:

...
Dafür gibt es aber auch ~/bin Maschinenweit - Nicht Userweit! ~/bin wäre userweit (d.h. je nach Layout eines Netzwerkes architektur- und maschinen-unabhängig.)

Für total chaotisch halte ich übrigens auch /usr/lib. Einerseits sind da Libraries, was man erwarten könnte, aber dann sind da auch noch Verzeichnisse von allen möglichen Programmen, wo irgendwelche Datenbestände drin liegen.

Das ist war, /usr/lib ist wirklich chaotisch. Von Bibliotheken (die ich da ja auch erwarte) über Binaries und Doku (qt, java) über Telefontarife (isdnrate) gibts da alles ... QT gehört IMHO entweder auf den /usr-tree verteilt oder nach /opt, viele andere Sachen nach /usr/share. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

Christoph Maurer

14:17

Am Don, 11 Okt 2001, schrieb Christoph Maurer:

...

Am Don, 11 Okt 2001, schrieb Bernd Brodesser:

...
* Ralf Corsepius schrieb am 11.Okt.2001:

...
Am Don, 2001-10-11 um 13.51 schrieb Bernd Brodesser:

...
Dafür gibt es aber auch ~/bin Maschinenweit - Nicht Userweit! ~/bin wäre userweit (d.h. je nach Layout eines Netzwerkes architektur- und maschinen-unabhängig.)

Für total chaotisch halte ich übrigens auch /usr/lib. Einerseits sind da Libraries, was man erwarten könnte, aber dann sind da auch noch Verzeichnisse von allen möglichen Programmen, wo irgendwelche Datenbestände drin liegen.

Das ist war, /usr/lib ist wirklich chaotisch. Von Bibliotheken (die ^^^ Und das darf nicht wahr sein, das ich mich so verschreibe. Soll natürlich heißen!

Das ist wahr! Gruß Christoph P.S. Korrektur deshalb, weil ich den Typo so sinnentstellend fand, daß ich beim Überfliegen meine eigene Mail nicht mehr verstanden habe.

Waldemar Brodkorb

9 Oct 9 Oct

18:29

Hallo Phillip,

...

From the keyboard of Phillip,

...

Wer hat sich eigentlich diese haarsträubende Verzeichnisstruktur von Linux ausgedacht und wie alt ist die?

[ bullshit hoch 10 entsorgt ]

...

Nur so ein paar ketzerische Gedanken von einem Linux Newbie...

... der vorher lieber einiges zum Thema gelesen hätte bevor er hier scheiße verzapft! Ich habe keine Lust dir die Vorteile dieser Verzeichnisstruktur im einzelnen Nahezubringen, dafür existieren sehr viele Bücher und Onlinequellen. Die Zeit in der du diese Mail geschrieben hast, hättest du sinnvoller einsetzen sollen. bye Waldemar

Jens Tautenhahn

19:42

Waldemar Brodkorb schrieb am Dienstag den 09. Oktober 2001:

...

... der vorher lieber einiges zum Thema gelesen hätte bevor er hier scheiße verzapft!

Phillip ist evtl. noch nicht ganz über das DLL-Hell Trauma hinweg ;) Gruß Jens -- printf("*** system failure failed.\n");

Qbert＠t-online.de

10 Oct 10 Oct

08:43

New subject: -10 (flamebait, redundant, troll)

kein Kommentar

8235

Age (days ago)

8237

Last active (days ago)

List overview

Download

29 comments

14 participants

participants (14)

B.Brodesser＠t-online.de
Christoph Maurer
Dieter Kluenter
Harry Rüter
Jens Tautenhahn
Jörg Lippmann
Martin Schmitz
Qbert＠t-online.de
ralf
Ralf Corsepius
Sebastian Helms
Thorsten Haude
Thorsten Strusch
Waldemar Brodkorb

Kraut und Rüben....

Qbert＠t-online.de

Harry Rüter

Christoph Maurer

Thorsten Haude

Christoph Maurer

Dieter Kluenter

ralf

Thorsten Haude

Martin Schmitz

Thorsten Strusch

Thorsten Haude

Jörg Lippmann

Martin Schmitz

Thorsten Haude

Waldemar Brodkorb

Martin Schmitz

Waldemar Brodkorb

Sebastian Helms

B.Brodesser＠t-online.de

Ralf Corsepius

B.Brodesser＠t-online.de

Ralf Corsepius

B.Brodesser＠t-online.de

Ralf Corsepius

B.Brodesser＠t-online.de

Christoph Maurer

Christoph Maurer

Waldemar Brodkorb

Jens Tautenhahn

Qbert＠t-online.de

tags

participants (14)