GoboLinux

	GoboLinux
	GoboLinux 016
Forráskód	nyílt
OS-család	GNU/Linux
Stabil verzió	017; (2020. május 24.)
Kernel	monolitikus
Felhasználói felület	Awesome
Elérhető	német, angol, magyar, portugál, spanyol
Licenc	GNU General Public License
Státusz	aktuális
Weboldal	www.gobolinux.org

A GoboLinux egy alternatív Linux-disztribúció, amely újradefiniálja a fájlrendszer-hierarchiát. A GoboLinuxban nincs szükség külön csomagkezelőre, minthogy maga a fájlrendszer a csomagkezelő: minden program a maga saját, külön mappájában helyezkedik el.

Fejlesztők[szerkesztés]

A GoboLinux-projekt ötletgazdája és elindítója Hisham Hashem Muhammad. A GoboLinux első verzióját Hisham és André Detsch alkotta meg.

„Kezdetben úgy indult, hogy egyszerűen programokat kellett telepítenem közönséges felhasználóként az egyetemen (minthogy számomra nem volt elérhető a hagyományos Linux könyvtárszerkezet, ez jó alkalom volt a fájlrendszer áttervezésére). Egy nap, Hisham számítógépének Nagy Fájlrendszer Pusztulása után, ő újratelepítette az egész rendszert. Azaz, csak az alternatív könyvtárstruktúra ötletét kezdtük használni az új rendszerben (amelyik az előzetesen lepusztított rendszerben, már minden telepített szoftver 80%-ánál kész volt). André szintén gondolkozott a Linux rendszere újratelepítésén, tehát összegyűltek a házában az egyik hétvégén, és lefuttatták az egész Linux From Scratch eljárást, miközben meg is változtatták azt, hogy használják az alternatív könyvtárstruktúrát. Az eredmény a tréfásan elnevezett GoboLinux lett, és ahogy ez általában történni szokott, a név rajta ragadt.”

– Hisham Hashem Muhammad

Később a projekthez többen csatlakoztak.

Leírása[szerkesztés]

A GoboLinux egy moduláris Linux terjesztés, amely a programokat egy forradalmian új logikus módon rendszerezi. Ahelyett, hogy a programok egyes részeit a /usr/bin-be, másokat az /etc-be és megint másokat a /usr/share/valami/vagy/valamimás-ba tenné, minden egyes program megkapja a saját könyvtárát; ezzel megfelelően elkülönülnek, valamint így teljesen egyszerűvé és nyilvánvalóvá válik, hogy milyen szoftverek vannak telepítve, és hogy az egyes fájlok melyik programhoz tartoznak.

Azért hogy a rendszer meg is találja ezeket a fájlokat, logikailag csoportosítjuk őket pár könyvtárban, mint például a /System/Links/Executables. Ebben szimbolikus linkek szerepelnek minden, a Programs könyvtár alatt szereplő végrehajtható állományhoz.

Azért, hogy fenntartsuk a kompatibilitást a hagyományos Unix/Linux alkalmazásokkal, léteznek olyan szimbolikus linkjeink is, amelyek emulálják az Unix-struktúra bejegyzéseit. Például /usr/bin, → /System/Links/Executables, és /sbin → /System/Links/Executables (ez a példa megmutatja, hogy az ugyanazon kategória fájljai közti önkényes megkülönböztetéseket szintén eltávolítottuk).

A GoboLinux rendszer gyökérkönyvtárában ez látható:

~] cd /
/] ls
Programs
Users
System
Files
Mount
Depot

A /Programs könyvtárban található az összes program. Nincsenek kivételek.

A telepített programokat következővel lehet kilistázni:

/] cd /Programs
/Programs] ls

Minden egyes programbejegyzés tartalmazza az adott programhoz tartozó összes fájlt, amelyeket egy verzióval ellátott alkönyvtárból lehet kiolvasni.

/Programs] find Bash
Bash
Bash/3.0
Bash/3.0/bin
Bash/3.0/bin/sh
Bash/3.0/bin/bash
Bash/3.0/bin/bashbug
Bash/3.0/info
Bash/3.0/info/bash.info
Bash/3.0/man
Bash/3.0/man/man1
Bash/3.0/man/man1/bash.1
…

Ugyanazon programnak egyszerre több verziója is lehet telepítve, így lehet választani közöttük, vagy ha szükséges, akár egyszerre is használhatók.

/Programs] ls -l OpenOffice
total 8
drwxr-xr-x  9 root root 4096 2005-09-22 01:07 1.1.4
drwxr-xr-x  3 root root 4096 2005-09-23 04:36 2.0
lrwxrwxrwx  1 root root    5 2005-09-23 04:36 Current → 2.0

/Programs] ls -l GTK+
total 12
drwxr-xr-x  10 root root 4096 2005-10-02 01:39 1.2.10
drwxr-xr-x   9 root root 4096 2005-08-21 05:48 2.6.7
lrwxrwxrwx   1 root root    6 2005-10-02 01:39 Current → 2.6.7
drwxr-xr-x   4 root root 4096 2005-10-02 01:39 Settings

Működése[szerkesztés]

Mint ahogy magát a fájlrendszert a programok rendszerezésére alkalmazzuk, kategóriák szerint is indexeljük a fájlokat, hogy a rendszer könnyen megtalálhassa őket a programbejegyzés ellenőrzése nélkül. A GoboLinuxban ezt az eredeti fájlokra mutató szimbolikus linkek létrehozásával valósítjuk meg. Vegyük észre, hogy ez egy nagyon praktikus módja a „Melyik csomaghoz tartozik XYZ file” probléma megoldásának.

A rendszer úgy konfigurálták, hogy ezeket a mutatókat használja, amikor fájlokat keres. Mindenféle kategóriára mutató linket megtalálható a rendszerben: futtatható állományok, könyvtárak, fejlécek, megosztott adatfájlok, használati útmutatók stb.

Egy másik fontos aspektusa a link-alapú indexelésnek, hogy a nemlétező fájlokra mutató hivatkozások automatikusan törött linkké és ennél fogva inaktívvá válnak. Ez nagyon leegyszerűsíti a problémák észrevételét, segítségével biztosak lehetünk abban, hogy mindig szinkronban vagyunk a rendszerünk valós funkcionális állapotával. Felejtsük el hogy a csomagkezelő panaszkodik, amiért a libXYZ nincs telepítve, amikor rögtön látható, hogy igen. Ha a link mutatója „élő”, akkor a rendszerben is létezik, és ez fordítva is igaz.

Unix kompatibilitása[szerkesztés]

A GoboLinux könyvtárstruktúrája első ránézésre hatalmas eltávolodásnak tűnik a unixos hagyományoktól. Ez azt jelenti, hogy minden programot meg kell buherálni, hogy együtt tudjon működni az új hierarchiával? Szerencsére, a válasz nem. A hagyományos elérési utak Gobolinuxossá linkelésével transzparens módon megőrizzük a kompatibilitást a unixos örökséggel.

Egész egyszerűen: a /bin egy link a /System/Links/Executables-re. Mint ahogy a /usr/bin is, és a /usr/sbin is. Az összes futtatható állományt tartalmazó könyvtár ugyanarra a helyre mutat. Meglepő módon ez még néhány átlagosnak mondható disztribúciónál is kompatibilisebbé teszi a GoboLiuxot. Az összes szabványos útvonal működik az összes fájllal, amíg más disztribúciók kénytelenek nehézségekkel küszködni, amikor például egyes szkriptek használhatatlanok, mert mondjuk az /usr/bin/foo-ra hivatkoznak, pedig a fájl igazából az /usr/local/bin/foo bejegyzésen helyezkedik el.

A szabványos Unix útvonalakat alapesetben nem látható a gyökérkönyvtárban. Valójában ott vannak azok, csak épp a GoboHide kernel patch (=kernelmódosítás) elrejti őket. Ez amúgy csupán esztétikai szempontok miatt van és teljesen opcionális, ennek ellenére a GoboLinux-nak nincs szüksége a kernel, vagy egyéb rendszerkomponensek módosítására, de úgy tűnik, hogy a felhasználóik elégedettek vele.

A leggyakoribb kifogás a GoboLinux ellen[szerkesztés]

A GoboLinux elleni leggyakoribb kifogás természetesen az, hogy könyvtárszerkezete nem POSIX kompatibilis. Ez azonban szándékos, s hogy miért ilyen, arra vonatkozóan leghelyesebb megint csak megalkotójának, Hisham Muhammadnak a szavait idézni:

"Oka van annak, hogy a dolgok olyanok, amilyenek." Ezt 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 könyvtárba helyezése.

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 ez esetben 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 összes gyű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 rendszer adminisztrá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 GoboLinux projekt célja[szerkesztés]

Az első célunk, hogy legyen egy olyan rendszer, amit szeretünk használni, amit nem fog megsemmisíteni valami csomag, ami irányítani, adminisztrálni próbálja helyettünk a gépünket. A legtöbb Linux disztribúció megpróbálja könnyűvé tenni a kezdő felhasználók életét, de ezzel a tapasztaltabb felhasználók életét csak megkeserítik. Nem állítjuk azt, hogy a GoboLinux könnyebb, csak az, hogy ennek van több értelme. Mindazonáltal azok az emberek akik használják, azt mondják, hogy ez valóban könnyebben adminisztrálható, tekintettel arra, hogy ez lehetőséget biztosít a számodra a rendszered megértésére (ha hajlandó vagy megpróbálkozni a megértésével).

A `/Depot` és a `/Files` könyvtárak[szerkesztés]

A /Depot tulajdonképpen egy szabad terület, hogy a dokumentumaidat, mint például a médiafájlokat, letöltött anyagokat stb, tárolja. Gondolhatsz rá afféle „közösségi területként” is, mint afféle „HOME minden felhasználó számára”. (néhány UNIX-rendszernek van egy /pub könyvtára erre a feladatra). A GoboLinux mint rendszer tulajdonképpen figyelmen kívül hagyja a /Depot tartalmát, ez csak azért létezik, hogy a felhasználókat arra biztassa, hogy egyetlen helyen tárolják a mindenféle fájljaikat, és tartsák a rendszer többi részét tisztán.

A /Depot -on belül nincsenek előre meghatározott alkönyvtárak, mindazonáltal része a szabványos GoboLinux fájlrendszer-hierarchiának.

A /Files másfelől egy szabványos GoboLinux könyvtár. Ebben alkönyvtárak vannak, mint például a Fonts és Plugins, ahol olyan fájlokat osztunk meg, amiket bizonyos alkalmazások igényelnek, de nem szükségképpen képezik az ő részeiket.

A GoboLinux könyvtárszerkezetének részletesebb bemutatása[szerkesztés]

A GoboLinux kialakítását korábbi operációs rendszerek, mint például NeXT, AtheOS és BeOS is befolyásolták, amelyek bár eredeti könyvtárszerkezeteket valósítottak meg, de még mindig jelentős mértékű kompatibilitást tartottak fenn az Unix-szal. A GoboLinux fájlrendszer gyökerében hat könyvtár van: Programs, Users, System, Files, Mount és Depot.

/Programs/ – ez a könyvtár egy-egy alkönyvtárat tartalmaz mindegyik programhoz, amely telepítve lett a számítógépre. Mindegyik efféle alkönyvtár egy vagy több további alkönyvtárat tartalmaz, az adott program különböző verzióihoz (Például a /Programs/OpenOffice/1.0.3 és /Programs/OpenOffice/2.0.1 )

és opcionálisan lehet benne egy Settings és Variable alkönyvtár is. Például: /Programs/Bash/3.0/bin/bash és /Programs/Xorg-Server/Settings/X11/xorg.conf.

/Users/ – ez a könyvtár tartalmazza a felhasználók "Home" könyvtárait. Például a "bob" nevű felhasználó "Home" könyvtára az /Users/bob útvonalon lenne elérhető.
/System/ – Kritikus rendszerállományok. Leginkább a létfontosságú rendszeralkalmazások használják (például /System/Settings/passwd) és a GoboLinux szkriptek (például, /rendszer/Links).
- Links/ – Olyan könyvtárakat tartalmaz, amelyek a /Programs alatti fájlokat indexelik.
  - Environment/ – Linkek a környezeti állományokra. Ezeket egy Cache fájlba fordítják be, és a shell tölti be, miközben a programok betöltik a saját környezeti változóikat.
  - Executables/ – Linkek a programok bin és sbin alkönyvtáraiban található fájlokhoz. (Tehát az ún. "végrehajtható" állományokhoz).
  - Headers/ – ez a jegyzék tartalmazza a linkeket a programok fejléckönyvtáraiban található állományokhoz.
  - Libraries/ – Linkek a programok lib könyvtárainak állományaira.
  - Manuals/ – A manuals és info alkönyvtárak tartalma.
  - Shared/ – Linkek a programok share könyvtáraiban található fájlokba.
  - Tasks/ – Linkek programok Resources/Tasks-tartalomjegyzékeikből való indítórutinjaira.
- Settings/ – Konfigurációs fájlok és linkek a programok Settings könyvtáraiban található fájlokra.
  - BootScripts/ – A rendszerindítás alatt használt szkriptek. Ez egy szimbolikus link a /Programs/BootScripts alatti Settings/BootScripts/ könyvtárra.
- Variable/ – a változó adatokat tartalmazó sokrétű könyvtár: ide kerülnek az ideiglenes állományok, spool file-ok, log állományok és a tranziens adatok.
  - tmp/ – Ideiglenes adatok.
- Kernel/ – A kernellel kapcsolatos tartalomjegyzékek.
  - Boot/ – Az operációs rendszer indulása alatt használt programok és konfigurációs fájlok. Itt van elhelyezve a rendszermag és a rendszerbetöltő konfigurációs fájljai is.
  - Devices/ – eszközfájlok (Az Udev kezeli őket).
  - Modules/ – Különböző kernelmodulokat tartalmaz, amiket a kernel változatok használnak.
  - Objects/ – A kernel-eszközökről ad képet (A 2.6 sorozatú kernelek sysfs fájlrendszerével együtt vezették be).
  - Status/ – Kernel státuszfájlok (a proc filerendszer által használt).
/Files/ – A Files olyan strukturált adatokat tartalmaz, amiket bizonyos alkalmazások igényelnek, de nem szükségképpen képezik az ő részeiket. Ilyenek a különböző önálló entitások, mint például a betűtípusok, kodekek és pluginok (és hasonló egyebek, melyek nem igényelnek csomagmenedzselést). Továbbá az alkalmazások úgy definiálhatják a saját alkönyvtáraikat, hogy helyszínspecifikus adatokat tároljanak – a Compile, a GoboLinux csomagkezelője, használja is ezt.
/Mount/ – további helyi vagy távoli fájlrendszerek csatolási pontja. A tipikus alkönyvtárak ezen belül például a CD-ROM, Floppy és Zip.
/Depot/ – a felhasználók fájljainak tárolóhelye, ide kerülhetnek például a letöltött állományok. Leírását fentebb részletesen megadtuk.

Csomagkezelés a GoboLinux alatt[szerkesztés]

Fontos nagyon részletesen kitérnünk a GoboLinux csomagkezelésére, tekintettel arra, hogy ez e disztribúció alatt nagyon más koncepcióra épül, mint más Linux terjesztések esetén.

A csomagkezelés szkriptekkel történik Hisham szerint:

A legtöbb feladatot a GoboLinuxban szkriptek egy gyűjteményével automatizálják. Ahhoz, hogy létrehozzunk egy GoboLinux csomagot, gépeljük be hogy: CreatePackage CoreUtils. A parancs eltárolja a CoreUtils/5.0/ és a CoreUtils/Settings tartalmát egy .tar.bz2 fájlban, aminek a neve CoreUtils—5.0—i686.tar.bz2 lesz. A /Programs/CoreUtils/Current nevű link jelzi, hogy melyik az aktuális verzió éppen. Ezt alapértelmezett verzióként használják a szkriptek. Egy program telepítése 3 lépésből áll: PrepareProgram, ami létrehozza a /Program/ könyvtár hierarchiát, és konfigurálja is a megfelelő opciókkal. A SymlinkProgram létrehozza a szimbolikus linkeket a /System/Links könyvtárban. A CompileProgram szkript hajtja végre a hagyományos configure, make és make install parancsokat (a parancssori opciók esete speciális kezelést igényel).

A fenti leírás megmutatja, milyen könnyű csomagokat készíteni e disztribúcióhoz a CreatePackage paranccsal.

A programok telepítésével kapcsolatban megjegyezzük, hogy a GoboLinux úgynevezett "forráskód alapú" disztribúció, azaz koncepciója az, hogy míg bináris csomag sokféle lehet egy programból, addig forrásprogramja egy és csakis egy van is minden programnak! A GoboLinuxhoz is vannak természetesen kifejezetten a GoboLinux alá elkészített speciális bináris programcsomagok, de más disztribúciókhoz képest szerény mennyiséggel rendelkezik ezekből. A GoboLinux a forrásprogramokból nem készít speciális gyűjteményt magának: a fejlesztők eredeti, fejlesztői honlapon megtalálható forrásprogramjaival dolgozik, azaz a Compile nevű program a GoboLinux alatt az eredeti, nem módosított forrásprogramot tölti le onnan minden esetben, és ezt fordítja le!

A fordítás a GoboLinux speciális könyvtárszerkezete miatt számos esetben igényli a speciális kapcsolók, paraméterek beállítását a fordítóprogram számára. Minthogy nagyon fáradságos lenne ezeket minden alkalommal a felhasználóknak beírni / megadni, sőt ezek kitalálása nem kevés szakismeretet is igényelhet adott esetben, ezért úgynevezett recepteket hoztak létre (Sztenderd Linuxokban ez a make fájl). Minden egyes programhoz tartozik egy recept, ami lényegében egy szöveges állomány, és egyfajta recept a fordítóprogram (a Compile program) számára, mely leírja, az adott programot miként kell lefordítani. E receptgyűjtemény igen gazdag a GoboLinux alatt. Egy forrásprogram telepítése tehát abból áll GoboLinux alatt, hogy a Compile program előbb letölti a központi receptgyűjteményből a picike kis recept fájlt, ennek alapján letölti a megfelelő forrásprogramot tipikusan a fejlesztők honlapjáról, és a recept előírása szerint lefordítja azt.

Lássuk részletesen a GoboLinux lehetőségeit programok telepítésére!

A GoboLinux alá a következő módszerekkel lehet telepíteni programot:

Tegyük fel, az XY program 2.0.1 verzióját akarjuk telepíteni. Belépünk a terminálba, majd root jogokat szerzünk a su – paranccsal. Ezután:

Bináris csomag telepítése létező GoboLinux csomag esetén[szerkesztés]

A

InstallPackage XY

letölti az XY program legfrissebb verzióját, és telepíti. Mindent elintéz, legfeljebb a menübe nem szerkeszti be a programot, de ott lesz a /Programs könyvtárban.

VAGY:

InstallPackage XY 2.0.1

Ekkor a 2.0.1 verziót telepíti az XY programból, akkor is, ha elérhető már újabb verzió. A program nevét (XY) a verziótól (2.0.1) SZÓKÖZ választja el!

Telepítés forráskódból recepttel[szerkesztés]

Compile XY

Ez letölti a recept fájlt a GoboLinux recept tárolójából, majd letölti a forráskódot, és lefordítja a recept alapján. Ez a parancs mindig legfrissebb verzióval dolgozik.

VAGY:

Compile XY 2.0.1

Mint fent, de a 2.0.1 verzióra.

Telepítés forráskódból recept nélkül[szerkesztés]

Csak erősen haladóknak ajánlott ez a mód. Íme egy példa, az XY progi 2.0.1 verziójára. (Itt kötelező verziót megadnod).

Le kell tölteni egy könyvtárba a program forráskódját. Terminálban be kell lépni abba a könyvtárba root jogokkal, majd:

PrepareProgram -t XY 2.0.1 - Ez elkészíti a /Programs alá az alkönyvtárstruktúrát.

PrepareProgram XY 2.0.1 - Ez paraméterezi a konfiguráló szkriptet, és futtatja azt.

Ez után:

make
SandboxInstall XY 2.0.1
SymlinkProgram XY

Nem hivatalos bináris csomagok telepítése[szerkesztés]

Az ilyen csomagot előbb le kell töltsük egy könyvtárba a Gobo honlapján felsorolt "hozzájárulási" csomagok közül, majd el kell menni a könyvtárba ahová letöltöttük root jogokkal, aztán

InstallPackage XY

Ha netán valamelyik invalid signature hibaüzenetet írna ki, akkor (de csak akkor) még ki kell adni a

SymlinkProgram XY

parancsot is.

Telepített program letiltása[szerkesztés]

A telepített program letiltását rootként kell végrehajtani.

DisableProgram XY verziószám

Ekkor megmaradnak a program állományai, csak a szimbolikus linkeket törli ki, azaz nem lesz a rendszernek tudomása róla, hogy van ilyen programunk.

Telepített csomag eltávolítása[szerkesztés]

RemoveProgram XY verziószám

Ekkor a /Programs könyvtárból is törli az összes fájlt, amely a programhoz tartozik. Mondjuk előtte célszerű egy DisableProgram parancsot is kiadni a fentiek szerint, hogy előbb a linkeket is törölje .

Ha töröltünk valamit kézzel, és bennmaradtak a már sehova sem mutató szimbolikus linkek a rendszerben, akkor menjünk rootként a /System/Links/Executables könyvtárba, majd adjuk ki ezt a parancsot:

find | RemoveBroken

Ez törli a sehova se mutató törött linkeket.

Ha korábban DisableProgrammal letiltottunk valamit, de még nem töröltük a fájljait RemoveProgrammal vagy máshogy, és ha mégis kéne a program, nem kell újratelepíteni mindent, elég root-ként ezt a parancsot kiadni:

SymlinkProgram XY verziószám

A Manager grafikus csomagkezelő felület[szerkesztés]

A grafikus csomagkezelő program neve Manager. Részletes, magyar nyelvű, képekkel illusztrált leírás róla itt található.

A GoboLinux kritikája[szerkesztés]

A GoboLinux ellen számos kifogást felhoztak, például hogy a könyvtárszerkezete Windows-szerű lenne stb, e kifogásokra Hisham Muhammad részletes, hosszú választ adott ebben a cikkben.

Komolyabb figyelmet igényel az az ellenvetés, hogy a Gobo Linux egy erősen fejlődő, de emiatt még korántsem "kész" disztribúció. A GoboLinux esetén a fejlesztést megnehezíti a fejlesztőgárda viszonylag kis létszáma.

Honosítás / Magyarítás[szerkesztés]

Minthogy Brazíliában indították útnak a Gobo projektet, a fejlesztési nyelv nem a magyar, s egyelőre nincs is a disztribúcióban semmiféle magyar nyelvi támogatás.

Azaz, ha valaki feltelepíti a GoboLinuxot a számítógépére, egy "angol" Linux rendszere lesz, beleértve természetesen azt is, hogy a disztribúció által felrakott programok, például az OpenOffice és a Firefox is angol nyelvű lesz. A telepítés után azonnal magyaríthatjuk a rendszert a következőképp: erről a linkről letöltjük a KDE-I18N-hu csomagot és felrakjuk. Letöltjük a JRE—1.5.0.08—i686 csomagot is, hogy OpenOffice-unknak legyen Java támogatása, az ugyanott található magyar nyelvű OpenOffice csomagot is letöltjük és felrakjuk.

Az UTF-8 kódolással még továbbra is baj van, ugyanis a parancssorban vagy valamely virtuális terminálban dolgozva tapasztalható, hogy e rendszer még egyáltalán nem UTF-8 kompatibilis, nem támogatja a magyar nyelvet: az "ő" és "ű" betűket nem jeleníti meg helyesen. Az ígéret szerint következő kiadás már orvosolni fogja e problémát, mert a fejlesztők célja - főként a nagyon vegyes, nemzetközi fejlesztőgárda miatt - jelenleg épp az nemzetköziesítés.