Figyelj, Zoltán22 ! Én TUDOM (most már…), hogy elméletileg és nagyjából (!) melyik hagyományos könyvtár mire való. Tudja ezt Hisham is. Épp csak ennek manapság már nincs értelme, mert ki lehet találni jobbat is! Erről Hisham írt egy remek cikket, le is fordítottam (nem kis munkával) magyarra, itt olvashatod:
http://www.gobolinux.org/index.php?lang=hu_HU&page=doc/articles/clueless
de ideidézem belőle a legfontosabbat:

„Oka van annak, hogy a dolgok olyanok, amilyenek ”

Ezt valamit, amit állandóan hallok, gyakran követi egy magyarázat a /, /usr és /usr/local, és/vagy a /bin és /sbin közti különbségről. Értem a különbséget1. Ha eltöröltem ezt a három szintű megkülönböztetést, annak az az oka, hogy hiszek abban, miszerint van más mód is azon problémák orvoslására, amik e hagyományos megkülönböztetést életre hívták. Egy GoboLinux rendszerben semmi érv nem szól amellett, hogy legyen különálló /usr és /usr/local azért, hogy elkülönítse a disztribúció által szállított programokat azoktól, amiket a felhasználó fordított magának. Mindegyik program természetes módon elkülönített, és pontosan ez is a legelső helyen említhető szándékunk azok közül, melyek végül a GoboLinux létrejöttéhez vezettek.

Az a történelmi ok, amiért az Unix-rendszerek tartalomjegyzékeinek egy része közvetlenül a gyökérkönyvtárból ered (/bin, /lib, /sbin), ellentétben azokkal amik a /usr könyvtárból nyílnak, nos az nem más, mint hogy így módodban áll bebootolnod egyfelhasználós üzemmódban, csupán ezen, a gyökérből nyíló fájlokat használva, megjavítandó velük a /usr könyvtárfa esetleges hibáit. Ez azonban csak „vallási hittétel”. Amikor meg kell mentenem a rendszeremet, inkább egy teljesértékű Linux rendszerrel felszerelt LiveCD-t használok, ami még grafikus környezetet is biztosít a számomra, az megengedi nekem, hogy böngésszem a világhálót és ott keressek megoldást a problémámra, és egyáltalán, egy teljes rendszer minden lehetőségét felhasználhassam a javítás érdekében. Tisztában vagyok azzal, hogy mi volt az értelme a régi rendszermentési megoldásnak évtizedekkel ezelőtt, de mostanság már sokkal jobb megoldással is rendelkezünk.

A bin és sbin közti megkülönböztetésének nincs értelme a jelenlegi kontextusban. A történelmi evolúció őrült önkényes megkülönböztetésekre vezetett, mint például a ping és traceroute külön tartalomjegyzékbe helyezése (képtelen vagyok felfogni, miként tarthatja valaki bármiképp is különböző programosztályba tartozónak e kettőt).

Egy Unix-rendszer az engedélyek rendszere. Ha az az óhaj, hogy valamely parancs csak rendszergazdai joggal legyen futtatható, akkor a megoldás: chmod 700 a megfelelő állományra, és kész. Azt gyanítom, hogy a programok megkülönböztetésének hagyományos rendszerét talán amiatt találták ki, hogy csökkentse a programok számát a normál felhasználók $PATH-jában. A mai Linux rendszerekben, lévén hogy akad akár 400 vagy 500 program is a $PATH-odban, ennek a megkülönböztetésnek semmi értelme.

Utolsó érvként megemlíthető, mindazonáltal, ami a Linux rendszereket a mai napig is jellemzi: a partícionálás és a távoli menedzsment. Ez ugyanannak a dolognak két különböző oldala, és – különösen a távolról menedzselhetőség – a szememben a kritikusaim legjogosabb aggodalma. Az erről szóló vitákra a legfrappánabb érvelés azonban, úgy vélem, az, hogy „a merevlemezek ma olcsók, és a jó teljesítmény érdekében valószínűleg amúgyis helyben lesz telepítve minden programod”. Bár egyetértek ezzel, de szintúgy megértem azokat is, akik szeretnének dolgokat központosítani, adminisztrációs célok érdekében. Ám egy aránylag nem mindennapos feladat érdekében tovább bonyolítani az egész rendszer komplexitását, hát az általában nem igazán jó dolog, sőt, a hagyományos Unix-megoldás még ezesetben sem elég általános: mi van, ha három vagy négy ablakkezelővel rendelkezel? Telepítesz egyet a /usr-be, egyet a /opt-ba, azután mi lesz? Ott a hagyományos Unix-struktúra. Valójában, a nagyobb Unix-hálózatok többségében amivel kapcsolatba kerültem, a helyi konfigurációk igényelték az Unix-hierarchia nem-standard tartalomjegyzékekkel való kibővítését.

Szerencsére, hála a LiveCD-nek, manapság már a technológiai haladás egy olyan fokát értük el, ami a probléma egy igazi megoldásaként szolgál: ennek neve angolul az „union mount” {bocs de nem találtam megfelelő magyar kifejezést rá – a fordító megjegyzése}, ami „overlay filesystem” {talán „átlapolt fájlrendszerek”?} néven ismert. Az ötlet az, hogy több partíciót is felcsatolhatsz ugyanabba a tartalomjegyzékbe. Ezáltal megtartható a /Programs azon értelme, hogy ez „a rendszerben elérhető programok összgyűjteménye”, függetlenül azok aktuális fizikai elhelyezkedésétől. A fájlrendszerek is pusztán absztrakciók (nem említünk fájlokat a sávjuk, szektoruk és cilinderük alapján), ez tehát pusztán további haladó előrelépés. Az átlapolt fájlrendszerek nagyon rugalmasak: a rendszeradminisztrátor például helyszínspecifikus beállításokat rögzíthet alapértelmezésként az állományok számára. Sajnos érthetetlen okokból ez nincs általánosan elterjedve. A Plan 9 operációs rendszer alapvető fájlrendszerkezelő műveletei közül az egyik a bind parancs (A Plan 9-ben például nincs szükséged $PATH változóra, mert minden tartalomjegyzéket, ami végrehajtható állományokat tartalmaz, egyetlen mappában fognak össze). Az átlapolt fájlrendszer egy Linux alá készült implementációja az „ovlfs”.

Különben elárulom, hogy ellentétben sokak TÉVhitével, én NEM a windowsos emlékeim miatt szeretem a Gobo-féle fájlrendszer-hierarchiát. Az efféle iránti vonzódásom sokkal régebbről származik, tudniillik megboldogult C-64 -es korszakomból. (abban igazi profi voltam, saját programnyelvet, BASIC-bővítéseket írogattam hozzá az assemblerében. Apám cégénél is (országos A-kategóriás nagyvállalat volt) az én bővítéseimet használták, ellentétben az olyan „hivatalos” bővítésekkel, mint pld a „Simon’s Basic”, mert az enyimeket jobbnak tartották). No és annál a gépnél teljesen általános volt az 1 program = 1 állomány kölcsönösen egyértelmű megfeleltetés. Néhány kivétel volt ugyan, az „egészlemezes” programok, de azokat már akkor is gyűlöltem, mert csak a baj volt velük, hogy mindig töltögették a dolgaikat, és emiatt (is) lassúak voltak. Szerencsére ezek jobbára csak játékok voltak.

No most Gobo alatt bár 1 program != 1 állomány általában, de ha már nem lehet 1 állomány (a feltelepített cuccokról beszélek), hát legalább legyen 1 (al)könyvtár(ba telepített minden cucca), így az áttekinthetőség megmarad.

Szóval innen származik a vélekedésem, semmi közöm/köze a Winhez. Amikor C-64 -ről áttértem a PC-re az nekem iszonyatos lelki teher volt. GYŰLÖLTEM a PC-ket (ennek nagyon sok oka volt), s azóta kezdem csak megszeretni őket, amióta Linuxot használok, s pláne amióta rátaláltam (uzsoltnak hála) a GoboLinuxra.

Strapal, amikor én áttértem a Gobóra, már egész jól ment az UhuLinux kezelése, sőt már kipróbáltam a Slackware-ot, Zenwalk-ot, Crux-ot, Arch-ot, s kísérleteztem a Gentoo-val és az LFS-sel is.

Igen, a szememben a Winszarnak valamicsskét logikusabb a felépítése fájlrendszerhierarchiailag mint a „hagyományos” linuxoké, de persze csak LÁTSZATRA, mert pld amit a registryvel művel, az rémálom.

Az meg lehet hogy te csak használni akarod a linuxot, és nem érteni, ez a te dolgod. Én örülök, hogy a Gobo alatt minden világos, áttekinthető, s emiatt ÉRTHETŐ.

Most hirtelenjében nem tudom, mi az ikonok szokásos kiterjesztése, talán .ico? Bár lehet, hogy az csak win alatt. Mindegy, tegyük fel, hogy így van. Ezesetben valahogy a
/System/Links/Shared
könyvtárat kell átnézni, mert Gobo alatt az efféle erőforrások mint a képek, ikonok, stb egy progi esetén a

/Programs/progineve/verziószám/Shared

alá vannak téve, s ez a könyvtár a /System/Links/Shared alá van besymlinkelve.

Különben meg abban igazad van, hogy az is logikus rendezési elv lenne, hogy a progik alkotórészeit típusuk szerint raktározzuk. De:

1. Én messze gyakrabban vagyok kíváncsi arra, hogy egy adott progihoz (csomaghoz) mi tartozik, s erre sokkal ideálisabb a Gobo szervezési elve.
2. Így egy elegáns csuklómozdulatta kitörölhetem a /Programs -ból a nekem nem kellő könyvtárat, s máris megvolt az uninstall, ha nekem úgy tetszik. Azaz a rendszer jobban hekkelhető.
3. A típus szerinti rendezési elvet a hagyományos módszer sem tartja tiszteletben, mert aszerint az összes végrehajtható állomány egyetlen könyvtárba kéne kerüljön, pld a /bin -be, de nem úgy van mert van mellette olyan is hogy

/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin is talán
meg /opt

és még ki tudja mi minden! Még az etc-ből is van egy plusz könyvtár az /usr-ben vagy az /usr/local-ban már nem emlékszem melyikben. Meg minden más vacakságból is. Szörnyű kavar az egész. Na most ha megbolondul valamiért a csomagkezelő, vagy én magam hekkelgetek valamit, s nem jól sikerül, ezt megjavítani rémálom, majdnem képtelenség. Gobo alatt sokkal könnyebb, mert tudom, hogy a hiba okvetlenül VAGY a /Programs/progineve könyvtárban keresendő, VAGY a /System/Links alatti bejegyzéseknél lett elszúrva valami, valszeg ott törött valamelyik link, vagy nincs is olyan link, más baj nemigen lehet. És kész!

Itt ti amiatt utáltok, mert lelkesedem a gobóért. Nem értitek ennek okát. Nos én Uhu1.1-el kezdtem, s másokkal ellentétben még jól emlékszem első linuxos heteimre. Biztosítok róla minden gúny nélkül mindenkit, hogy Linuxra áttérésem messze legnagyobb problémája (>90%) az volt, hogy mi ez a szar a könyvtárrendszerben. Hogy valami hol itt van, hol ott van. Én ugyanis nem nulla számtech tapasztalattal jötte a Linuxba, és rögvest nemcsak kezelni, de megismerni akartam a rendszert. Engem nem elégített ki, hogy valami misztikus, „csomagkezelő”-nek nevezett varázslóprogi feltesz nekem valamit VALAHOVÁ, amiről azt sem tudom hol van. Érteni akartam, mit hová miért…

Amióta gobózom, a rendszert tényleg uralom. És sokkal többet tanultam a Linuxról is. Mostanában már a fejfájásokat nekem legfeljebb a függőségek okozzák, s hogy nem értem/ismerem még a configure és make szintaktikáját.

Gondolj arra is kérlek, az az elv hogy egy progihoz tartozó minden állomány ugyanott legyen, örökké használható, logikus elv. A típus szerinti rendezés nem igazán, mert tegyük fel a jövőben szagmintákat is le tud játszani a hipermultimédiás számítógép, s akkor kitaláljuk majd, hogy a szagminták állományainak kiterjesztése .bűz és akkor minden progi ezen állományait elhelyezzük egy
/bűz
könyvtárba? Igen, de a nagyon büdös, s emiatt veszélyes mert ájulást okozó rendszerprogik szagjai fontosabbak, azokat csak a rencergizda szimatolhassa, akkor lesz egy
/sbűz
könyvtár is. De az user is akar szagmintákat tárolni, s ő akkor ugye a barátnője genitáliáinak halszagát csak a
/usr/bűz könyvtárba pakolhatja, kivéve ha ez neki valamiért nagyon fontos, mert a legújabb ablakkezelőt telepítette fel, amit már szellentéssel is vezérelhet, ahhoz is kell szagminta, na az a
/usr/sbűz könyvtárba kerülhet. Bár lehet hogy nem jól írom, mert ezek igazából a
/usr/local/bűz illetve
/usr/local/sbűz könyvtárakba kerülnek majd, ha valaki nagyokos azokat is kitalálja! De lesznek opcionálisan választható bűzikék is, vagy esetleg optimális bűzök amik nagyon szuperek (feromontartalmúak pld. „Ettől minden bagzó kutya utánad kezd loholni!” – reklámmal), s ezek ugye a /optbűz könyvtárba kell kerüljenek. Vagy a /opt/bűz -be?

S ezt a rémálmot el kell majd játszani minden egyes új fájltípusnál?! Na ne!

Vagy ugye, azt mondják a bűzikék nem olyan fontosak, egyszerű shared állományok, menjenek a többi közé! Na de akkor meg az egyetlen nagy szeméthalom, amiben minden benne van, akkor semmit nem ér a típus szerinti rendezés, akkor pedig már logikus hogy ha típus szerint nem rendezzük a fájlokat, legalább hovatartozás szerint legyen rendezve, az meg éppen pontosan a gobo-elv.