* Jan Trippler schrieb am 12.Aug.2003: > On Mon, 11 Aug 2003 at 08:09 (+0200), Bernd Brodesser wrote:
> Moin, Moin moin, > > /opt ist keine schlechte Idee, aber ein ganz anderes Konzept als die > > �brige Linux/UNIX-Hirachie. Einmal hat man die Libs unter /usr/lib > > und einmal unter /opt/kde/lib > N�, seit System V ist /opt auch unter Unix Standard N�, seit System V Release irgendwas. System V gibt es schon lange, aber egal, das ist nicht der Punkt. Ich meinte Linux - UNIX auch nicht als Gegensatz. Das /opt Konzept pa�t nicht zum �brigen Konzept von System V. [1] > da wird es > sogar deutlich konsequenter benutzt als unter Linux. Der einzige > Nachteil, den ich sehe, ist u. U ein l�ngerer PATH, aber daf�r > herrscht deutlich mehr �bersicht. Ja, l�ngeren PATH ist ein deutlicher Nachteil. Nicht, da� der Pfad so lang ist, sondern da� er st�ndig angepa�t werden mu�. Klar kann man das irgenwo Zentral machen, was die einzelnen Distributionen ja auch machen, aber wenn man das PATH Konzept voll ausleben will, dann kann es durchaus sein, da� jeder User einen anderen PATH hat. Wenn dem so ist, dann wird es kompliziert. > Wenn sich eine Software unter /opt > installiert, dann finde ich eben alles, was dazu geh�rt unter > /opt/Software. Ja, das ist der klare Vorteil. Und mit einem einfachen rm -rf /opt/Software lie�e sich ein Paket deinstallieren. > > Beide Konzepte haben Vor- und Nachteile, nur ein lustiges > > Durcheinander ist eigentlich nur von Nachteil. > > Ja - aber eine unter /opt installierte SW macht es mir trotzdem > leichter, IMHO. Sage ich nichts dagegen, nur warum denn nicht alles so? Au�er vielleicht, was direkt unter / steht. > > > KDE, Gnome usw. _sind_ optionale Anwendungspakete - dann ist /opt > > > genau der richtige Platz daf�r. Mit dem OS haben sie nix zu tun. > > > > X, Sound und Netzwerk sind aber genauso Optional und haben mit dem > > OS nichts zu tun. > > Wieso *aber*? Ist nur ein dummer Satzf�ller, sonst nichts. X, Sound und Netzwerk sind genauso Optional und haben mit dem OS nichts zu tun. > Die Frage ist: Warum liegen sie nicht da? Eben. Wenn schon, denn schon. > Man kann > sicher immer im Zweifelsfall dar�ber streiten, was ein *optional > application package* ist (laut M$ ist ja sogar ein Browser Teil des > OS ;-), aber sp�testens bei einem Window-Manager (oder einem DBMS, > Applikationsserver, Web-Server) w�rde ich schon die Grenze ziehen - > aber auch hier wieder IMHO. Wenn schon, dann richtig und alles au�er dem Kernel geh�ren nicht zum OS. H�chstens noch die Startskripte. > [/usr/local] > > Genau. Der Sysadmin packt hier seine eigene Pakete rein, die er > > entweder selber �bersetzt hat, oder gar selber geschrieben. Aber vom > > Betriebssystem geh�rt hier nichts hin. > Ich w�rde die Aussage lieber umdrehen: Nichts, was der Admin lokal > auf seinem System baut, geh�rt woanders hin als unter /root(/bin) oder > /usr/local(/bin). So ist das nat�rlich auch richtig, aber auch umgekehrt. [1] Die verschiedenen Versionsbezeichnungen sind schon merkw�rdig. System V Release x.y hat mit System V Release x.z wohl weniger zu tun, als System V Release 1 mit System III Bernd -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
