GoboLinux

A Wikipédiából, a szabad enciklopédiából.

Ezt a szócikket át kellene olvasni, ellenőrizni a szövegét, tartalmát.
Részletek a cikk vitalapján.
Az ezen a lapon látható jelölés 2007 februárjából származik.

**GoboLinux**
OS-család:	GNU/Linux
Forráskód:	nyílt
Legfrissebb változat:	014.01 / 2008. március 30.
Rendszermag típusa:	monolitikus
Alapért. UI:	KDE
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 van elhelyezve.

A GoboLinux Magyarítási Project logója

Tartalomjegyzék

1 Fejlesztők
2 Leírása
3 Egyáltalán hogyan működhet ez?
4 De mi van az Unix kompatibilitással?
5 A leggyakoribb kifogás a GoboLinux ellen
6 Mik a GoboLinux project céljai?
7 Mi ez a két különleges könyvtár, a /Depot és a /Files?
8 A GoboLinux könyvtárszerkezetének részletesebb bemutatása
9 Csomagkezelés a GoboLinux alatt
10 A GoboLinux kritikája
11 Kapcsolódó cikkek
12 Külső hivatkozások

[szerkesztés] Fejlesztők

A GoboLinux-project ö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 projecthez természetesen többen csatlakoztak.

[szerkesztés] Leírása

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 dobálná, 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 file-ok melyik programhoz tartoznak.
Hogy a rendszer meg is találja ezeket a fájlokat, logikailag csoportosítjuk őket pár tartalomjegyzékben, mint például a /System/Links/Executables, s ebben, mint már kitalálhattad, 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, amik 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).
Ezt láthatod a GoboLinux rendszered gyökérkönyvtárában:

~] cd /

/] ls

Programs

Users

System

Files

Mount

Depot

A /Programs könyvtárban található az összes programod. Nincsenek kivételek. Ha az érdekel, hogy milyen programok vannak telepítve, elég egyszerűen kilistázni:

/] cd /Programs

/Programs] ls

Minden egyes programbejegyzés tartalmazza az adott programhoz tartozó összes file-t, amelyeket egy verzióval ellátott alkönyvtárból olvashatsz ki.

/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 kedved szerint válthatsz közöttük, vagy ha szükséges akár egyszerre is használhatod őket.

/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

[szerkesztés] Egyáltalán hogyan működhet ez?

Mint ahogy magát a fájlrendszert alkalmazzuk a programok rendszerezésére, így kategóriák szerint is indexeljük a fájlokat, hogy a rendszer könnyen megtalálhassa őket a temérdek 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 rendszert aztán úgy konfiguráltuk, hogy ezeket a mutatókat használja, amikor fájlokat keres. Mindenféle kategóriára mutató linket megtalálhatsz 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ő file-okra 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, és ami még lényegesebb: segítségével biztosak lehetünk abban, hogy mindig szinkronban vagyunk a rendszerünk valós funkcionális állapotával. Felejtsd el a régi problémát, hogy a csomagkezelő panaszkodik, amiért a libXYZ nincs telepítve, amikor látod, hogy de igen. Ha a link mutatója „élő”, akkor a rendszerben is létezik, és ez fordítva is igaz.

[szerkesztés] De mi van az Unix kompatibilitással?

A GoboLinux könyvtárstruktúrája első ránézésre hatalmas eltávolodásnak tűnik a Unix-os 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 Unix-os örökséggel.
Nincs ebben semmi egetrengető: 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é tesz bennünket. A GoboLinux-ban az összes szabványos útvonal működik az összes file-val, amíg más disztribúciók kénytelenek nehézségekkel küszködni, amikor pl. 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.

Biztos észrevetted, hogy a szabványos Unix útvonalakat alapesetben nem láthatod a gyökérkönyvtában. Ne aggódj, ott vannak azok, csak épp a GoboHide kernel patch (=kernelmódosítás) eltűnteti ő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óink elégedettek vele.

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

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 megintcsak megalkotójának, Hisham Muhammadnak a szavait idézni:

"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”.

[szerkesztés] Mik a GoboLinux project céljai?

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).

[szerkesztés] Mi ez a két különleges könyvtár, a /Depot és a /Files?

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.

Lásd még részletesebben a következő alcímet, a GoboLinux könyvtárszerkezetéről.

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

A GoboLinux kialakítását korábbi operációs rendszerek, mint például NeXT, AtheOS és BeOS is befolyásolták, amik 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 filerendszer gyökerénél hat tartalomjegyzék van: Programs, Users, System, Files, Mount és Depot. Magyarázatukat lásd lentebb.

/Programs/ – ez a könyvtár egy-egy alkönyvtárat tartalmaz mindegyik programhoz, ami 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 (Pld /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ák:
/Programs/Bash/3.0/bin/bash és /Programs/Xorg-Server/Settings/X11/xorg.conf.

/Users/ – ez a tartalomjegyzék tartalmazza a felhasználók "Home" könyvtárait, úgyhogy egy – mondjuk – "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, amik 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.

[szerkesztés] Csomagkezelés a GoboLinux alatt

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. Ahogy Hisham írja:

A legtöbb feladatot a GoboLinuxban szkriptek egy gyűjteményével automatizáljuk. Ahhoz, hogy létrehozz egy GoboLinux csomagot, gépeld be például, hogy: CreatePackage CoreUtils . Amit e parancs csinál, az az, hogy 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 verzió az aktuális é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/ tartalomjegyzék-hierarchiát, és konfigurálja is a megfelelő opciókkal. A SymlinkProgram létrehozza a szimbolikus kötéseket 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 idézet azt is megmutatja, milyen könnyű csomagokat készíteni e disztróhoz a CreatePackage paranccsal.

A programok telepítésével kapcsolatban előszöris tudni illik, hogy a GoboLinux úgynevezett "forrás alapú" disztribúció, azaz koncepciója az, hogy míg bináris csomag sokféle lehet egy programból, addig forrás csak egy van, de forrása van is minden programnak! Azaz, 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 aránylag szerény mennyiséggel rendelkezik ezekből. Ám forrásprogramokból sem készített 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 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, sőt ezek kitalálása nem kevés szakismeretet is igényelhet adott esetben, ezért úgynevezett "recipéket" hoztak létre, minden egyes programhoz tartozik egy recipe, ami lényegében egy szöveges állomány, s egyfajta recept a fordítóprogram (a Compile) számára, mely megmondja, az adott programot miként kell lefordítani. E recipegyű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 recipegyűjteményből a picike kis recipe-file-ot, ennek alapján letölti a megfelelő forrásprogramot valahonnét a fejlesztők honlapjáról, s a recipe 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 telepíthetsz programot:

Tegyük fel, az XY program 2.0.1 verzióját akarod telepíteni.

ÜGYELJÜNK A KISBETŰ-NAGYBETŰ KÜLÖNBSÉGEKRE A PARANCSOKBAN!

Elmész terminálba, majd root jogokat szerzel a

su –

paranccsal. (a root jelszavadat bekéri). Ezután:

[szerkesztés] Bináris csomag telepítése, ha az megvan a GoboLinux hivatalos csomagbázisában

InstallPackage XY

Erre letölti az XY program legfrissebb verzióját, és telepíti. Mindent elintéz helyetted, 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.
A program nevét (XY) a verziótól (2.0.1) SZÓKÖZ választja el!

[szerkesztés] Telepítés forrásból, recipével

Compile XY

Ekkor letölti a recipe-fileot a GoboLinux recipetárolóból, majd letölti a forrást, és lefordítja a recipe alapján. Ez a legfrissebb verzióval dolgozik.

VAGY:

Compile XY 2.0.1

Mint fent, de a 2.0.1 verzióra.

[szerkesztés] Telepítés forrásból, ha nincs hozzá recipe. (Csak erősen haladóknak).

Íme egy példa, az XY progi 2.0.1 verziójára.
(Itt kötelező verziót megadnod).

Letöltöd egy könyvtárba a progi forrását. Bemész oda terminálban, 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 configure szkriptet, és futtatja azt.

Erre dolgozik egy keveset, majd:

make
SandboxInstall XY 2.0.1
SymlinkProgram XY

[szerkesztés] Nem hivatalos bináris csomagok feltétele

Az ilyen csomagot előbb le kell töltsd valami könyvtárba a Gobo honlapján felsorolt "hozzájárulási" csomagok közül vagy máshonnan, majd elmész a könyvtárba amibe letöltötted, root jogokkal, aztán

InstallPackage XY

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

SymlinkProgram XY

parancsot is.

[szerkesztés] Feltett program letiltása

(Rootként)

DisableProgram XY verziószám

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

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

RemoveProgram XY verziószám

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

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

find | RemoveBroken

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

Ha korábban DisableProgrammal letiltottál valamit, de még nem törölted a fájljait RemoveProgrammal vagy máshogy, akkor ha mégis eszedbe jut hogy neked kéne a progi, nem kell újratelepítened, elég rootként e parancs:

SymlinkProgram XY verziószám

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

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

[szerkesztés] A GoboLinux kritikája

A GoboLinux ellen számos kifogást felhoztak, pld 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 ez egy erősen fejlődő, de emiatt még korántsem "kész" disztribúció (bár igazság szerint egyetlen Linux terjesztés sem nevezhető a szó hagyományos értelmében késznek, mert mind fejlődik...) A GoboLinux esetén a fejlesztést megnehezíti a fejlesztőgárda viszonylag kis létszáma. Minthogy Brazíliában indították útnak a Gobo-Projectet, 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 "szín-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. Ezokból nem is érdemes felrakni az InstallCD-ről nekünk magyaroknak az OpenOffice programcsomagot, hanem 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, s ezek után mindjárt otthonosabban mozgunk új rendszerünkben, mert legalább a legfontosabb programjaink magyarul szólnak majd hozzánk!

Sajnos örömünk így sem lesz felhőtlen, mert parancssorban vagy valamely virtuális terminálban dolgozván tapasztaljuk majd, hogy e rendszer még egyáltalán nem UTF-8 kódolású, emellett ott sem támogatja a magyar nyelvet, legalábbis az "ő" és "ű" betűket nem jeleníti meg helyesen. Állítólag a 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 internacionalizálás.