Nem vagyok tanácstalan,
avagy
Mítoszok és félreértések a GoboLinux tervezésével kapcsolatban

Hisham H. Muhammad

``Azok a szerencsétlenek akik nem értik az Unixot,
arra vannak kárhoztatva, hogy újra kitalálják.''
- Henry Spencer, 1987

``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éget¹. 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”.

A hosszabb nevek állítólagos felhasználó-jóakarata

Sok-sok ember, amikor rábukkannak a Gobo-Linuxra, és meglátják a hosszú, leíró-jellegű tartalomjegyzék-neveket, így kiált fel: ``Nini! Megváltoztatták a neveket azért, hogy a rendszer barátságosabb legyen!''. Aztán némelyek ezt jónak, mások rossz dolognak tartják. Mindkét oldal téved.

Számos oka van annak, hogy az útvonalnevek a GoboLinuxban olyanok, amilyenek, de ezen okok egyike sem az, hogy ``magához csábítson olyan felhasználókat, akiket megijeszt a /etc, és hasonlók''. Az első számú ok ez: nem ellenkezik az Unix-névtérrel. És amikor Unix-névteret mondok, ténylegesen a Linux névtérre gondolok, ami nem egy nagyon jól megállapodott dolog. Ez nem olyan, mint egy fenntartott kulcsszavakból álló készlet valamely programnyelvből, ami megtiltja például az if, while, repeat változónévként való használatát, a többi viszont oké. Soha nem tudhatod, hogy milyen tartalomjegyzékek, fájlok és programok fognak felbukkanni holnap, tehát úgy gondoltam, a legjobb amit tehetek ha olyan neveket választok, amiket mások valószínűleg soha nem használnak majd. Mások is megtették már ezt előttem, és működött, úgyhogy követtem a példájukat: a NeXT-nek és a Mac OS X-nek el kellett érniük, hogy a saját mappáik Unix-tartalomjegyzékekkel éljenek egymás mellett, úgyhogy „nagybetűsítették” a neveket, és rövidítések helyett teljes szavakat használtak. A rövidítések a régi idők egy jele az Unix eredetének korszakából. Dennis Ritchie egyszer azt mondta, ha vissza tudna menni az időben és csak egy dolgot megváltoztatni az Unix-ban, átkeresztelné a creat rendszer-hívást create-ra.

Az az egyetlen dolog, ami megnyugtat engem a döntésem igazsága felől, az az, hogy amikor a GoboLinuxszal kezdtünk, úgy nagyjából a Linux 2.4. napjaiban, akkor azt kérdezte valaki, hogy ``miért nem a /sys-t választottad a /System helyett? Hiszen azt könnyebb volna gépelni.'' El tudod képzelni, mi történt volna, most, hogy a kernelfejlesztő fickók lefoglalták a /sys-t a sajátjuknak?! Valójában állandóan felvetődik a GoboLinux hierarchiáról szóló vitákban a „gépelés-barátság”. Ehhez csak annyit tudok hozzászólni, hogy egy megfelelően beállított shellben, mint abban is, ami a alapértelmezett a GoboLinuxnál, a /Programs begépelése ugyanannyi billentyűleütést igényel, mint a /usr bevitele: egy „/” jel, kis „p” betű, Tab.

Egy másik felvetett kérdés: de miért kell a tartalomjegyzék-struktúra megváltoztatásával indítani? Miért nem használjuk egyszerűen a hagyományoss tartalomjegyzékfát, és érjük el, hogy „GoboLinuxosan” viselkedjék? Igen, azt gyanítom, hogy ezt nem lett volna lehetetlen elérni, de egy operációs rendszer tervezése szempontjából nem kedvelem az ötletet. Nem tartom kényelmesnek egy olyan rendszer ötletét, ahol jól ismert tartalomjegyzékek más jelentésekkel bírnak azokhoz képest, amikre a legtöbb ember számít. Az AtheOSnak például megvan ez a problémája. Látsz egy /usr mappát, de az nem /usr. Az AtheOSban ez inkább viselkedik úgy, mint az /opt, de a név történelmileg azt jelentette: ``user'' (= „felhasználó” ), később tekintették csak az Unix System Resourcesnek betűszavának. S még akkor is, ha Kurt Skauen hívta azt /opt-nak, ez még mindig furcsa volna; azok nem ``opcionális (szabadon választható) csomagok''.

A GoboLinux tartalomjegyzékek szintén rendelkeznek különböző, az Unix-mappákból ismert jelentéssel. A /Programs a rendszer számára rendelkezésre álló összes program gyűjteménye, ahol mindegyik alkönyvtár tartalmaz minden, az adott programhoz tartozó fájlt (egy programcsomag megkülönböztetése mindegyik projekt esetében a fejlesztőin áll; a különféle eszközök a CoreUtils-ből egyetlen programot alkotnak). Mindegyik alkönyvtár a /System/Linksben egy „lekérdezést” tartalmaz (a kifejezés adatbázis-értelmében) a programgyűjtemény minden egyes fájlosztályáról: könyvtárak, végrehajtható állományok, fejlécek, és így tovább². Mint láthatod, ezek a tartalomjegyzékek nem az Unix-tartalomjegyzékek, adminisztrációs szempontból eltérően működnek. Azt hiszem, hogy jó döntés ezt már a nevekben is világossá tenni.

Szigorúan kompatibilitási okokból mindazonáltal rendelkezünk Unix-nevű szimbolikus linkek egy extra készletével, melyek a legközelibb GoboLinux megfelelőkre mutatnak (még azon az áron is, hogy némi engedményt teszünk a GoboLinux rendszer felépítésében, elősegítve ezzel a kompatibilitást). A tény, hogy ezek linkek, és mi hagyományos bejegyzéseknek nevezzük őket, ezt az elképzelést nagyon tisztán tartja. Lucas Villa Real és Felipe Damasio GoboHide-on végzett munkája, a kernel patch mely igazi rejtett tartalomjegyzékeket valósít meg a Linuxon, méginkább az elszigetelt tartozékok szintjére fokozza le a hagyományos tartalomjegyzék-bejegyzéseket.

Meg akarod változtatni a szabványt?

Természetesen nem. Először is, nem vagyunk annyira naivak, hogy azt higgyük, sikerülhetne. De az a tényleges ok, amiért nem akarjuk megváltoztatni a szabványt, az az, hogy úgy véljük, nem kellene szabványnak lennie. Tudom, hogy ez a nyilatkozat még merészebbnek hangozhat az arról való beszédnél, hogy megváltoztatnánk egy szabványt, de a lényege annak amit mondok, hogy azt hisszük, hogy mindegyik alkalmazásnak kötelessége megengedni azt, hogy bárhová is telepítsék, és együttműködni minden neki szükséges másik alkalmazással, bárhová is vannak azok telepítve (többet erről a következő pontban). Ha volna most egy szabvány, ami kijelenti ezt, aláírnák egy kérvényt, ami támogatja azt. Valójában létezik is ilyen: ugyanis ennek felelnek meg a GNU által kibocsátott szabványok, melyek a GNU Autotools használatát ajánlják, a kapcsolók -prefix családjának támogatásával, felderítendő a configure szkript segítségével az alkalmazások helyét. De azon csak nevetek, amikor egy javasolt szabvány mint az FHS, közli velem a binárisok egy önkényes listáját, hogy azokat nekem meg nem nevezett okok miatt különálló tartalomjegyzékben kellene tartanom.

A különböző helyzetek különböző szükségleteket hoznak létre, és olyan úgynevezett szabványok, amik minden lábat ugyanabba a cipőbe próbálnak beilleszteni, eleve kudarcra vannak ítélve. Ehelyett a rugalmasság a szabványosítandó. Vagyis nem, mi nem javasoljuk, hogy a GoboLinux hierarchiát bárki is szabványként kövesse. Öt, tíz vagy húsz év múlva a maitól teljesen különböző szükségeink lehetnek. Nem akarom azt, hogy a GoboLinux fájlrendszertől való akkori esetleges elszakadás olyan nehéz legyen, mint a hagyományos Unix-fájlrendszertől való mostani eltávolodás. Mely elvezet minket természetesen a következő ponthoz.

Egy fáradságos küzdelem, hogy megváltoztassanak minden alkalmazást

Nem olyan nehéz ez, mint amilyennek látszik. Mielőtt a GoboLinux első verzióját teljesen megépítettük volna, már egy egész éven át dolgoztam rajta és javítgattam azt. Amikor André Detsch és én végül nekikezdtünk és felépítettük az alapjaiból két nap alatt, belészerkesztve az elképzeléseinket, már tudtam, hogy ez tökéletesen megvalósítható.

Egyetemi környezetben dolgozom sok év óta. Ott nem én vagyok a rendszergazda, úgyhogy minden extra alkalmazást amire szükségem van, a saját $HOME könyvtáramba kell telepítenem. Ez teljesen hétköznapi állapot, azaz várható, hogy bármilyen tisztességes alkalmazás meg fogja engedni ezt, és hatalmas többségük így is viselkedett. Valójában, egy erre képtelen alkalmazás tönkreteheti a rendszeredet. Ha telepíteni tudod a Gimpet a /usr, a /opt, vagy a /home/hisham könyvtárakba, akkor képes vagy azt a /Programs/Gimp/2.0/-ba is telepíteni. A tapasztalat megmutatta, hogy nagyon kevés alkalmazásnak van arra szüksége, hogy az együttműködés kedvéért átírkáljuk a Makefile-ját. Még rendszergazda-központú szoftver is rendelkezik (vagy kellene hogy rendelkezzék) ezzel a rugalmassággal: egy szabályos Unix-rendszerben a rendszergazdának kéne hogy legyen lehetősége arra, hogy válasszon, mondjuk, a /sbin és a /usr/sbin között. Nincs oka annak, hogy a programokban és telepítőszoftverekben holmi „fixen behuzalozott útvonalak” legyenek³.

Érdekesebb az a probléma mely akkor merül fel, amikor egy program bár megengedi, hogy bármely altartalomjegyzékbe telepítsék, ám ugyanakkor merőben helytelenül feltételezi, hogy egy másik program amitől ő függ, ugyanoda van telepítve, ahová ő maga. Amint azt sejtheted, ez a GoboLinuxra nehezedő problémák legfőbb forrása, de közbevetőleg megjegyezném, hogy ez az egész szabad szoftverközösség érdekében megoldandó feladat! Térjünk vissza azonban a $HOME tartalomjegyzékhez! Mi van ha a kedvenc GNOME összetevőmet nem telepítette a rendszergazda, és emiatt telepíteni akarom azt a $HOME-omba, miközben a GNOME többi használatban levő része a /usr-be van telepítve? Az ehhez hasonló helyzetek, különösen a sok összetevőből álló szoftverekben gyakorta problematikusak. Ezekben sok program egy $PATH-hoz hasonló környezeti változó használatával oldja meg a problémát: $GTKPATH, $PERL5LIB, $KDEDIRS, $PYTHON_PATH, és így tovább. Azaz nincs indoka a monolitikus telepítésnek.

Tehát a csata, amit a GoboLinux a telepítési útvonalakkal kapcsolatban vív, nem csupán ránk jellemző; mi csupán felfedjük az alkalmazások rugalmasságában (vagy rugalmatlanságában...) rejlő problémákat, mely nemcsak a mi tartalomjegyzék-struktúránkban, de bárhol előbukkanhat, ahol egy felhasználónak valami egyéni telepítésre lehet szüksége. Úgy látom különben, hogy a helyzet az elmúlt néhány évben jelentősen javult, amint egyre több project használja a GNU Autotools-t.

``Könnyebb lefordítani egy programot relatíven ugyanahhoz a könyvtárszerkezethez alkalmazkodva''

Biztos így van. Ez egy olyan pont, ami néha-néha előbukkan a GoboLinux levelezőlistán, amikor az emberek azt javasolják nekünk, hogy tervezzük át a /System/Links-et egy hagyományos Unix-hierarchia szerint alkönyvtárakkal, mint például a bin, lib, stb.; - vagy éppen fordítsunk mindent a /usr-hez viszonyítva, hogy biztosítsuk a hagyományos tartalomjegyzék-struktúra állandó működőképességét. Az ezt javasló emberek implicite e két megoldás egyikét javasolják nekünk: lefordítani egy könyvtárstruktúrához viszonyítva relatívan, azután telepíteni relatívan egy másikba; lefordítani egy könyvtárstruktúrához viszonyítva relatívan, azután a telepítés során használjunk átirányításokat. Nem kedvelem a két megközelítés egyikét sem. Az elsőben bizonyos rugalmasságra számítasz a telepítőrendszer részéről, amivel pedig az nem mindig rendelkezik, épp csak másfajtára, mint amely pontokat az előző szekcióban felemlítettem. Márpedig nem igazolható, hogy az alkalmazás telepítőrendszere okvetlenül kell rendelkezzék ezzel a rugalmassággal⁴. A második esetben pedig, hát nem kedvelem egy olyan operációs rendszer ötletét, amit olyan módszer köré építettek, amit bármelyik pillanatban megkerülhet egy új rendszerhívás, vagy valami szokatlan hozzáférési mód. Lehet, hogy néhányan azt mondják, a GoboHide maga is beleesik a ``szokatlan hozzáférési módok'' tartományába. Ezesetben rá szeretnék mutatni arra, hogy a GoboHide használata nálunk nem elengedhetetlenül szükséges, másrészt úgy terveztük, hogy szabályosan együttműködjék a vanilla Linux kernellel⁵.

De ahelyett, hogy a javasolt alternatívák hibáit pécézzem ki, jobban szeretném alkotó módon megvédeni a tervvel kapcsolatos az eredeti döntéseimet. A GoboLinuxszal kapcsolatos eszménk, hogy elkülönített tartalomjegyzékekkel gyakoroljuk ezt az új megközelítést. Felbecsültük a hatását a rendszermenedzsmentre, és izgalmas eredményeket gyűjtöttünk. Ha helyette arra használtunk volna minden lehetséges módszert, hogy ``megkönnyítsük'' az alkalmazások lefordítását, azt hiszem, hogy csak távolabb kerültünk volna a céltól. Amikor lefuttatom a ls -l /System/Links/Executables parancsot, és minden végrehajtható állományt látok amit a rendszerem tartalmaz, nos, akkor egy tiszta képpel rendelkezem a rendszerről. Utálnék a /System/Links-re nézni (vagy hívják akárhogyan), ha azon belül is csak az Unix-féle rendetlenséget látnám emulálva, holmi /bin, /sbin, és /usr/X11R6 által.

``Windows-szerűvé akarod változtatni a Linuxot!''

Ha mindent elolvastál eddig a pontig, azt hiszem, elég világos kell legyen számodra, hogy nem ez a célunk. Ha az lenne a célunk, hogy magunkhoz csábítsuk a Windows-felhasználókat, azesetben egy szerkezeti átszervezés volna az az utolsó dolog, amit cselekednénk. Ehelyett arra koncentrálnánk, hogy a felhasználói interfész úgy nézzen ki, mint a Windows, miközben Windowshoz hasonló témákat alkalmaz, ikonokat rángatva eközben, talán némiképp a Wine-ot integrálva a disztribúcióba, és így tovább. És léteznek is ilyen disztrók manapság, ezek a Lindows, Lindash, Linspire, vagy bármi is a nevük, de mi nem tartozunk közéjük.

Rendkívül paradoxnak hangozhat, de arra törekszünk, hogy megtartsuk a rendszer Linux-identitását. Hogy pontosabbak legyünk, küzdünk mindegyik projekt önazonosságáért. Amikor csak lehetséges, változatlan forrásokkal szállítunk minden alkalmazást. Ha vetted valaha a fáradságot arra, hogy belenézz bármely jelentősebb disztribúció fájljaiba (Pld .src.rpm), akkor tudod, hogy miről beszélek: a csomagok hatalmas többsége patch-okat tartalmaz, az alkalmazások viselkedésének csekély módosítása érdekében: legyen ez akár az, hogy megváltoztassák egy kapcsolónégyzet alapértelmezett beállítását, vagy akár az is, hogy eltávolítsák egy alkalmazás ``About'' dobozát! Mi nem tesszük ezt. A mi K menünk a KDE logót jeleníti meg, miként annak a KDE-ben lennie kell. Bár van egy témánk amit egyedi tapétával szállítunk, de azt opcióként mutatják be a telepítőprogramban.

Komoly erőfeszítésekre is képesek vagyunk annak érdekében, hogy csomagjaink ne tartalmazzanak GoboLinux-specifikus hibákat. A legrosszabb amit egy Linux felhasználó felfedezhet, hogy egy adott szoftver az X disztrón dolgozik, ám nem működik egy másik Y disztrón, és nem tudja hogy vajon amiatt, mert az Y disztró valami olyan patchet vezetett be ami oka a hibának, avagy mert az X disztró vezetett be egy olyan patchet, ami kijavította a hibát. Ez fejlesztőként is jelentősen megnehezíti a dolgunkat. Alexandre Julliard a Wine fejlesztői közül egyszer azt mondta, hogy a Linux disztribúciók állandó változásai jobban lelassítják a projectet, mint a Win32 API változásai.

Az a tény, hogy a GoboLinuxon minden Unix library-könyvtár bemutat minden libraryt a rendszerből, minden fejléc-könyvtár bemutat minden fejlécet és így tovább, a disztribúciók közt fellépő számos kompatibilitási problémának kihúzza a méregfogát, miközben azt az ironikus helyzetet eredményezi, hogy a szokatlan tartalomjegyzék-struktúra ellenére a legkompatibilisebb disztribúciók egyike lettünk.

Egy disztribúció vizsgálata

Néhány ember, akiket talán felizgatott a tény, hogy oly ``nagy módosítást'' hajtottunk végre az operációs rendszer szerkezetében, alkalmanként azzal fordul hozzánk a levelezési listában, hogy bizonyos más nagy rendszer méretű változtatások figyelemre méltóan javítanák a GoboLinuxot. Néha a nagy ötlet alkalmazható, és alkalmazzuk is, mint például amikor Carlo Calica integrált egy démon-menedzselő eszközt, a Runit-ot a GoboLinuxba⁶. Ám az esetek legnagyobb részében az ötlet olyasmi, ami megkövetelné minden alkalmazástól, hogy agyonmódosítsák, ha ugyan nem kéne akár teljesen át is írni azt. Ezt nyilvánvalóan nem tudjuk, és nem is akarjuk megtenni. Ha korlátozott számú programról lenne szó, lehet, hogy néhány efféle ötlet megvalósítható, de embereknek észben kell tartaniuk, hogy a GoboLinuxszal használható programok világegyeteme potenciálisan végtelen, ahogy napról-napra új Linux alkalmazásokat írnak.

Itt csak néhányat tudok megemlíteni a javasolt, ám megvalósíthatatlan ötletek közül:

• áthelyezhetővé változtatni minden programot - szeretném ha ez megvalósulna, ám megcsinálni elég durva: átírni minden alkalmazást a világban, hogy libprefix-et használjon, tároljon minden függőséget mindegyik programkönyvtárban, és akár százszor is meglegyen a lemezen ugyanaz a néhány könyvtár (és még így is meg kell alkudni azokkal az összeférhetetlenségekkel, amik felmerülnek egy rendszerben, ha az nem felkészült minderre), mindent lefordítani ugyanahhoz a hierarchiához viszonyítva (fent egy egész szekciót szenteltem e kérdéskörnek).
• elérni, hogy minden program egy egységesített konfigurációfájl-formátumot használjon - Természetesen az erőfeszítés, amit egy efféle átdolgozás igényelne, még nagyobb, mint az az előző javaslatnál szükségeltetne. Minden ötlet, ami úgy kezdődik, hogy ``minden program...'', ugyanabba a közös problémába torkollik: abba, hogy a rááldozandó erőfeszítés potenciálisan végtelen; nem tudod ugyanis elérni, hogy a világ minden prodzsektje beleegyezzen a javaslatod használatába; de ha el is tudnád ezt érni, még akkor is kimaradna ebből számos hagyományos rendszer, amelyek akkor sem tudnának megváltozni ha akarnának, annyira inkompatibilisek. Egy másik elképzelés mely ugyanebbe a csoportba tartozik, hogy minden program ugyanazt a grafikai eszközkészletet használja. Igen, ez valóban jó lenne, és egységesítené a Linux desktopot, de ép ez az, ami nem fog megtörténni.
• változtasd meg a /Programs nevét AppDir -rá, mert így nagyon hasonlítasz a RiscOS -ra – Mondhatják hogy ahhoz hasonlítunk, de az azért mégis jócskán különbözik tőlünk. Igen, a /Programs/Emacs mondjuk elhelyezhető volna holmi AppDir -ben. A /Programs/LyX szintén. Ó, sok más is. De mit mondasz a /Programs/FindUtils -ról? Vagy a /Programs/KDE , mi történne, amikor arra kattintasz? Egy másik fontos vitapont, hogy az AppDir-ek természetszerűleg áthelyezhetőek, a GoboLinux csomagok pedig nem, de ezt a témát fentebb már taglaltam.

Internacionalizálás

Gyakran felemlegetik, hogy a nevek kicserélése, például a lib -nek Libraries -re változtatása túl angol-centrikus (``a régi nevek legalább mindenkinek egyformán értelmetlenek''), és vennünk kéne a fáradságot rá, hogy lefordíthatóvá tegyük a tartalomjegyzék-struktúrát. Elhessegethetném ezt a pontot, mint ami sok műszaki kérdést vet fel, használhatatlanná is téve ezáltal, hacsak nem szimbolikus linkekről és GoboHide patchekről beszélünk. De nem fogom ezt tenni. Helyette megkérdem, hogy ha lenne egy tiszta és elegáns mód, hogy lefordítsák minden GoboLinux-tartalomjegyzék nevét, nos, mi változna meg ettől?

Ha az emberek annak érdekében fordítják le a tartalomjegyzék-struktúrát, hogy barátságosabbá tegyék a rendszert az angolul nem beszélők érdekében, hát sajnálom, de az nem fog segíteni. Egy olyan felhasználó, akit legyőz a tény, hogy a /System/Settings -et nem úgy nevezik, hogy /Rendszer/Beállítások, nem fog nagyon előrébb lenni, amint eljön a pillanat, hogy használnia is kell ezeket a tartalomjegyzékeket, és szerkesztenie kell a httpd.conf-ot. A lényeg, amit szeretnék megértetni, az az, hogy annak a fajta felhasználónak, akinek internacionalizálásra van szüksége, nem fog segíteni egy lefordított tartalomjegyzék-struktúra. Az erőfeszítéseket a dokumentációk fordítására, és a programok felhasználói interfészének lefordítására kell koncentrálni ehelyett. Ha a felhasználó el tud olvasni egy kézikönyvet ilyen vagy olyan nyelven, ami azt mondja neki, hogy menjen a /System/Settings-be és végezzen el a httpd.conf -ban ilyen és ilyen változtatást, ez sokkal hasznosabb, mint a tartalomjegyzék nevének megváltoztatása. És ha a felhasználónak van egy barátságos GUI-ja mondjuk az Apache beállításához, hasonló ahhoz amit a Mac OS X szolgáltat, azt a felhasználó valószínűleg sokkal inkább kedveli majd.

Integráció más disztrókkal

Ez egy másik kérdés, amit különböző alakokban, méretekben és színekben vetnek fel néha-néha. Egyetlen okát látom annak, amiért felmerül ez az igény, és ez az, hogy más disztribúcióknak hatalmas készletük van használatra azonnal kész szoftverek gyűjteményéből. Első látásra, az ötlet hogy egyesítsük a GoboLinux újításai közül mindegyiket valamely „X” disztró óriási csomagválasztékával, bámulatosnak látszik. Ha azonban közelebbről is szemügyre vesszük, látni fogjuk hogy nem az.

Először is ott van a függőségrendszerek kérdése. A GoboLinuxnak nagyon laza függőségrendszere van, amit eleve úgy terveztek, hogy rugalmas legyen, a felhasználó által testreszabható⁷. Ha a GoboLinux ezen előnyére építesz, nem leszel rászorulva az „X” disztró automatikus frissítési szolgáltatásaira, és ez fordítva is igaz. Azaz, neked választanod kellene, hogy a GoboLinuxot úgy használod, mintha az egy „X” disztró volna, feladva a GoboLinux rugalmasság nagy részét, vagy figyelmen kívül hagyod az „X” disztró remek automatikus frissítési szolgáltatásait. Akármelyiket választod is, feladnád azon okok egyikét, amiért egyáltalán leginkább elindítottad ezt az integrációs projectet.

És akkor aztán állandóan foglalkozhatnál mindkét disztribúció apró sajátosságaival is: különböző indítószkriptek, a libraryk lehetséges inkompatibilitásai, az „X” disztró állítólagos ``értéknövelő'' csomagmódosításai... s nem is említettük az arra való alkalmatlanságot, hogy megfelelően használják a Compile-t vagy a GoboLinux binársok gyűjteményét, amiatt, mert például a csomagok különböző elnevezési konvenciókat használnak.

Röviden, még akkor is, ha egy egész rendszert átalakítasz az „X” disztró csomagjainak használatára, az, amivel végződni fog, nem egy ``felturbózott'' GoboLinux, hanem egy köntörfalazó disztró. Egyszerű megtenni, hogy veszünk minden RPM csomagot, ami például egy RedHat rendszert alkot, kicsomagoljuk őket, és besymlinkeljük őket, hogy úgy nézzenek ki, mint egy GoboLinux rendszer. Biztos lehetsz afelől, hogy a kapott rendszer végülis sokat csinosítana a RedHat-on. Meg is valósították ezt különböző emberek különböző célokkal (némelyek építettek egy teljes disztrót, mások csak egy vagy két bináris csomagot konvertáltak), RedHattel, Slackware-ral, Debiánnal, és legtöbbször a Gentoo-val. A megfigyelésekből leszűrt általános tapasztalatom az, hogy ez nem éri meg.

A rendszergazda

Természetesen megjegyeztem a legjobbaknak tartottakat. A döntés, hogy a nullás felhasználót nevezzük valami másnak, mint a root, az egyik azok között, amiért minket a leginkább kritizálnak. Ennek az eredete visszanyúlik a GoboLinux keletkezése tájára. A kísérleti rendszeremen a normál felhasználóm neve hisham volt, a superuser pedig lode. Soha nem kedveltem az Unix azon elképzelését, hogy ``egy mindenható root szemben a normál felhasználókkal'', és látni akartam, hogy egy Linux rendszer milyen jól viselkedne gyökérfelhasználó nélkül. Néhány átdolgozás után itt és ott, ez nagyon jól működött. Jó volt tudni, hogy ha valaki bármikor is megpróbálna root-ként bejelentkezni a gépembe, mindig kudarcot vallana.

Amikor végrehajtottuk azt a „hack-sorozatot”, ami aztán a Gobo-Linux első verziójával végződött, André és én úgy döntöttünk, hogy állandósítjuk ezt. A gobo-t választottunk, ami egy belső vicc. A szándék természetesen az, legyen egy olyan rendszer, ami tisztán támogat egy nem-root superusert, de a felhasználók (egy maroknyi ember még csak akkor) soha nem változtatott az alapértelmezésen, és így aztán a gobo valahogy beragadt. Azért még mindig lehetséges különösebb erőfeszítés nélkül megváltoztatni az alapértelmezést. Rövid időn keresztül adminisztráltam egy sereg gépet az egyetemnél, és ott, hogy könnyebben illeszkedjenek be a NIS környezetbe (a hálózat alapvetően RedHat egységekből állt), visszaváltoztattam a superusert gobo-ról root-tá. Most hogy a GoboLinuxnak van egy grafikus telepítőprogramja, az üzembehelyezés ideje alatt opcióként dönthetünk a superuser neve felől.

Most hogy torkig vagyok már a történelmi magyarázattal, egy dologra szeretnék rámutatni még, s ez az a jól ismert tény, hogy ez az egyetlen istenhez hasonló entitás létezése a Linux biztonsági modell gyengeségei közül az egyik, és ez az, ami nyugtalanított engem az „egy mindenható root kontra egyéb felhasználók” elképzelésben; ez hasonló az elosztott rendszerek egyetlen hibás pontjához. Minden projektnek, aminek az a célja, hogy javítsa a Linux biztonságát, legelsősorbanis növelnie kell a biztonsági modell szemcsézettségét, hígítva a root erejét: ACL-ek, képességek, SELinux... Lehet vitázni róla, hogy ezek közül néhány túlzott bonyolultságot ad hozzá a modellhez, de nem fogok belemászni ebbe a beszélgetésbe itt. Az ugyanis teljesen bizonyos, hogy a root-modell túlságosan leegyszerűsített a mai összetett rendszereknél, és az, hogy a ``setuid'' jogosultság a legtöbb biztonsági kérdés forrása. A Plan 9-nek például egyáltalán nincs is superuserje; ehelyett felajánlja az állományrendszer egy virtualizált nézetét mindegyik eljárásnak. A gobo kísérlet volt annak lemérésére is, hogy mennyire ivódott bele a Linux világba az elvárás egy root-felhasználó létével kapcsolatban; szerencsére, nem igazán (ez nem számít természetesen abból a szempontból, hogy a biztonsági modell a #0 felhasználóra csatolt). Egy jövőbeli irány, ami felé szeretném, hogy a GoboLinux tartson (és valójában a Linux általában), az az, hogy át kell vennie a felsorolt technológiák közül néhányat, javítandó az irányítást a rendszerbiztonság és az adminisztráció fölött; a root-tól való leválás volt az első lépés ebben az irányban.

Következtetések

Nos azt hiszem, sok kérdést érintettem ezzel a cikkel. Én biztos vagyok abban, hogy sok kérdést felejtettem el, de azt gondolom, a legfontosabbak azért mind itt vannak. Legfőképp abban reménykedem, sikerült megértetnem, hogy a GoboLinux nem csupán a fájlrendszer esztétikusabbá kozmetikázása. Mi eléggé tudatában vagyunk annak, amit teszünk, és cselekedeteink következményeinek is.

Nem titok, hogy amikor elkészültem ennek a tartalomjegyzék-szerkezetnek az első verzióival, nem számítottam arra, hogy egy Linux disztribúcióvá válik, amit a világ minden táján használnak majd az emberek (bár elég korán disztribúciós projectté formálták, amint Guilherme Bedin csatlakozott). Az egyetlen dolog, ami boldoggá tett akkoriban, amikor ez még nem volt egy megfelelő disztró, az nem más volt, mint egy tiszta terv.

Teljes szívvel egyetértek az idézettel a cikk kezdetében, és határozottan azt hiszem, hogy ez nem az az eset.

Utóirat: Sajtóhibák

Köszönet Varga Péternek, aki felhívta rá a figyelmemet, hogy a híres "creat()" idézet Ken Thompsontól és nem Dennis Ritchietől való.

E dokumentumról...

E dokumentumot a LaTeX2HTML fordító 2002 (1.62) verziójával hozták létre.

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

A parancssori argumentumok:
latex2html -split 0 clueless.tex

A fordítást 2004.06.13-ban kezdeményezte Hisham Hashem Muhammad

Lábjegyzetek

... ¹

Azok számára, akik még mindig csodálkoznak (illetve akik meg szeretnének győződni róla, valóban értem-e a három könyvtár közti különbséget), a három fő könyvtárba csoportosítás lényege: Fájlok, amiket egyfelhasználós rescue-üzemmódban el kell tudni érni a root-partícióról; a disztribúció által szolgáltatott állományok; és a rendszergazda által elkülönítetten telepített programok (ez a megkülönböztetés változhat a különböző Unixokon, de főleg ez az, ami szerint a Linux disztribúciók dolgoznak, olvass utána). A hagyományos programok mennek a /bin-be, és a programok, amiket a rendszergazdának szántak, az /sbin-be.

... ²

A Plan 9-ben ez megoldható lenne egy bind paranccsal; amióta ez nem áll rendelkezésre a vanilla Linux kernelben, szimbolikus kapcsolatokkal tesszük ezt. De el kell ismernem, hogy kedvelem az elképzelést, hogy a lekérdezéseket állandó módon eltárolják.

... ³

Egy önmagában való telepítőprogram ritka fogalom Linuxban; az, amire a telepítőprogram kapcsán ehelyütt gondolok, az általában egy Makefile által végrehajtott install.

... ⁴

Azok kedvéért, akik érdeklődnek eziránt a megközelítés iránt, felhívom a figyelmet a GNU Stow-ra. Nem tudom mindazonáltal, hogy bármilyen rendszer alatt működik-e 100%-osan.

... ⁵

Azt is megtehetjük, hogy a /System/Links-et union-ként mountoljuk fel, ovlfs segítségével.

... ⁶

Az aktuális tendencia a GoboLinux fejlesztésben ennek az integrációnak a lazítása, opcionális Runit összetevő készítésével, ám megtartva a szükséges szerkezetet a működéshez.

... ⁷

A GoboLinux függőségrendszer leírása túlmutat e cikk keretén, de például, ha telepítesz egy A alkalmazást ami a B-től függ, ez nem fog panaszkodni ha B nincs felinstallálva egy vanilla csomaggal, és ha B hiányzik, erről értesítést küld, de nem fogja megakadályozni az installációt.