Ez az írás segíthet a Linuxszal történő ismerkedés során. Sok olyan embernek segítettem Linux telepítésével, akik azelőtt csak Windowst használtak. Ez az írás főleg az általuk feltett kérdéseken alapul. Rengeteg írás, információ fellelhető az interneten, mindenféle szempont szerint kategorizálva. Ez a leírás nem tartalmaz minden érdekes információt, de igyekszem amennyire lehet tömören összefoglalni (így is jó hosszú lesz), azokat a válaszokat, amiket az évek során a nekem feltett kérdésekre volt alkalmam adni.

Ennek a cikknek az előzménye: https://linuxmint.hu/blog/2022/03/windows-vs-linux-tudorka-4-alkalmazasok-makrok

Igazából más lett volna az aktuális téma, de van egy olyan komplex „egyebek” témakör, amit sehogy nem tudok elkerülni, és bár eléggé lerágott csontnak tűnik, újra és újra előjön.

Tehát valami ilyen kérdéskörök lesznek most terítéken:

• A két rendszer úgy általában összehasonlítva.

• Programok elérhetősége, telepítése.

• Fentivel kapcsolatban a függőségek kérdésköre.

Vegyünk egy egységnyi hardvert, (gépet), és biztosítsuk, hogy évekig csak használjuk, de nem cserélünk benne semmit, úgy értem, hogy még az egeret sem, memóriát pláne nem bővítünk, nem cseréljük a háttértárat, nem cseréljük gyorsabbra a procit. Portalanítás, újra pasztázás megengedett, sőt kötelező.

Az egységnyi gépre Windowst telepítünk, és tudjuk, hogy mely programokat szeretnénk használni, azokat is telepítjük, és a gépnek van internet csatlakozása, a frissítéseket komolyan vesszük, a rendszer mindig naprakész legyen. A lényeg, hogy az idő során ne telepítsünk újabb programokat, minden legyen feltelepítve már az elején, de a telepített programok frissülhetnek, újabb verzióra is.

Általában elmondható, hogy az idő múlásával a rendszer egyre lassabb lesz, és még lassabb, és aztán már bántóan lassú. Sőt, azt is meg lehet figyelni, hogy ha hosszabb ideig nincs bekapcsolva a gép, akkor mindinkább extrém lassan indul, sokáig karikázik. Beleőszül az ember mire használható lesz.

Ugyanerre a gépre telepítünk Linuxot, és évekig használjuk, nem lassul be, több év múlva is mondhatni ugyanolyan gyors, mint amilyen volt telepítéskor. Úgy értem a teljes életciklus alatt tartja a sebességet, tehát az, hogy LM18-at lecseréljük LM19-re, az nem jár, ugyanazon a gépen LM19 nyilván lassabb, mint LM18. És LM20 is lehet lassabb mint LM19...

Ennek a dolognak a manifesztációja olyan gellert kapott, hogy a leharcolt régi gépre, amin már nem fut rendesen a Windows, „majd felrakunk” valami Linuxot…

Most ide kellene valami átkötés a függőségekhez. Hát... az van, hogy különböző témák ezek, de valahogy összefüggenek, hogy is fogjam meg, hogyan kezdjem?

Na, jó, legyen történelem!

Szóval egyszer volt, hol nem volt, volt a DOS, meg aztán Windows 3.x, vagyis inkább volt FAT16. Nos, ennél az allokációs egységek száma FIX volt, ami azt jelenti, hogy minél nagyobb volt a merevlemez, annál nagyobbak voltak az allokációs egységek is, így az icipi fájlok is extrém nagy helyet foglaltak, mert minden fájl egy allokációs egységet lefoglal. A programok jellemzően egy INI kiterjesztésű fájlba mentették a beállításaikat, ebből rengeteg volt és mind nagyon kicsik voltak, de sok helyet foglaltak. Erre a frappáns válasz volt, hogy legyen csak egy fájl, minden program legyen szíves abba menteni a beállításokat. Ez lett a Registry. (Windows 95 alatt jelent meg)

Jó ötletnek tűnt…

Folyományok:

- Egészen addig, a programok telepítése jószerint abból állt, hogy felmásolni a fájlokat a számítógépre. Akár egyik gépről lemásolva mappástul, másik gépre felmásolva jellemzően működött a dolog. Illetve Windows 3.x alatt már megjelentek a függőségek: DLL fájlok. (Linux alatt ezek a lib-ek) Itt már necces volt csak úgy átmásolni, meg eztán egyéb kálvária is lett ebből, de erről majd később. Amikor lett Registry, akkor a sima átmásolás már végképp lehetetlenné vált, mert kritikus információk a helyi Registry-ben maradtak.

- Aki hosszabb ideje űzi az ipart, annak feltűnhetett, hogy létezik olyan, hogy fájl sérülés. Még hosszabb idő alatt az is feltűnhetett, hogy egyes fájlok gyakrabban sérülnek, mint mások. Pl. egy adatbázis kezelő esetén a program az kb. soha nem sérült, de az adatbázis fájlok (DBF) viszont gyakrabban, és az indexek még gyakrabban. Tök mindegy, hogy mi okozza a sérülést, egy napkitörés, vagy kóbor elektron, vagy a Föld mágneses mezejének az ingadozása, a lényeg, hogy statisztikailag igazolható, minél többet van módosítva /írva egy fájl, annál nagyobb eséllyel sérül, azaz a sérülés a fájl írás folyamata során keletkezik. Ez nem rendszer specifikus dolog, azaz nem Windows feature, de az az, hogy lett egy fájl, a Registry, amit minden program használt, azaz folyamatosan módosul, íródik….

 

Ki lett találva a FAT32, ami már az allokációs problémán sokat javított. De addig is, az is felmerült, hogy egy csomó program lényegében ugyanolyan részeket futtat, takarékosabb lenne, ha ezek a részek közösek lennének, mert így elég csak egy közös DLL könyvtár amit minden program használhat. Aha, csakhogy a DLL specifikációban nincs olyan, hogy visszafele kompatibilitás, pláne verzió követés. Mármint verziója van neki, de ez nem jelent semmit, az újabb verzió nem jelenti azt, hogy tudja mindazt, amit a régi tudott.

Frissült valamelyik program, az újabb verziójú DLL-t telepített, amit másik program is használt, ám az a másik program nem frissült, és ebből lett a „DLL hell” -ként elhíresült jelenség. Magyarul DLL -pokol

Ez ugyan nem lassította a gépet, csak használhatatlanná tette, de amit erre aztán kitaláltak, az már igen, lassítja…

Linux alatt is előállhat a probléma, elvileg. De itt jellemzően ez azt eredményezi, hogy függőség ütközés miatt nem telepíthető adott program. A lib-ek jellemzően felülről kompatibilisek, és elkülönülnek a kernel és userspace folyamatok -emiatt nincs olyan, hogy kékhalál, nem roskad össze a rendszer, max. csak a futtatott program.

Jelenleg a Linux dinamikus link kezelését a Windows is magáévá tette, azaz, egyre kevesebb a kékhalál.

Többek között (pontosabban több probléma - melyek között a DLL pokol is ott van) megoldására ki lett találva a Windows side by side technológia, aminek az eredménye a WinSxS mappa és tartalma. Egy csapásra megoldja a DLL pokol problémát, mert minden verzióhoz tartalmazza a kupacot, továbbá így lehetővé teszi eltérő verziójú programok telepítését, de erre épül a frissítések visszavonása is, mert felülírt régebbi verziójú fájlok itt megmaradnak, vissza lehet másolni a helyükre, de különböző jogosultsággal futó programok kezelése is ezen keresztül történik.

A WinSxS mappa a Windows alatt található, és óriásira tud duzzadni. Sok ezer almappát tartalmaz, sok ezer fájllal. Ha van hely, ez nem számít, csakhogy! Ezek kezelése rendszer szinten történik, azaz olyasmi, mint egy adatbázis kezelés. A Registry-ben vannak a hozzá kapcsolódó szabályok.

Minden frissítéskor, minden program indításkor végigelemzi a Windows ezeket az adatokat, ezt a mappát. A Registry-ben nem csak ezek vannak, ott van még egy csomó beállítás, és még azon túl sok minden. Időközben kijött az NTFS, ami hibatűrőbb lett, a Registry szét lett bontva több fájlra, és külön lett a rendszernek, a felhasználónak, és több másolat példányt is őriz a rendszer, hogy elejét vegye a gyakori fájl sérülésnek.

Tudni kell, hogy a fájl műveletek eléggé megterhelő folyamatok. Ezt úgy kell érteni, hogy az allokációs címek kezelése is képes számottevő lenni. Egy példával említve egy kicsi merevlemez (de SSD is) ugyanabban a gépben gyorsabbnak tűnik, mint egy óriási. Azaz, nagyobb lemezen több allokációs egység van, több időt igényel a kezelésük, és ez mérhető időt jelent. Minél több fájl van, annál lassabb a kezelésük.

Menjünk a Windows mappa alá, és nézzük meg a WinSxS mappa méretét, ill. hány fájl van benne?

Persze, a Windowsnak van erre segédeszköze, Rendszer karbantartás alatt pl. el lehet érni az „árva csomagok eltávolítását” – ki tudja takarítani a WinSxS mappát. Jó sokáig elfut, és újra is kell indítani közben a rendszert. Ha elavult, szükségtelen .NET fájlok is törlésre kerülnek, akkor többször is újra kell indítani, és közben a rendszer teljesítmény ellenőrzéseket is végez, hogy beállítson egy optimális teljesítményt. Mindezekért ezt senki nem is futtatja, leginkább úgy marad az egész, hihetetlen mennyiségű árva csomaggal.

A Registry-re is jellemző, hogy ami belement, az benne marad. Vannak Windows alá segédprogramok, amik ezekre a gondokra próbálnak megoldást találni, pl. Ccleaner. Tudja a szükségtelen szemét fájlokat is törölni, Registry-t takarítani, de a WinSxS mappához ez sem nyúl hozzá.

Linux alatt is van olyasmi, amit a Registry csinál, csak ennek nincs neve. Olyasmire van használva pl. hogy nyilvántartsa a telepített csomagokat, illetve Linux alatt minden parancshoz kötelezően van használati útmutató, bár ezt senki nem olvassa. De azt, hogy ez működjön, azt is be kell jegyeznie frissítéskor a rendszernek. Tehát, azt, hogy terminálba működjön a man parancs, hogy az a leírás jelenjen meg, ami az aktuális verzióhoz tartozik, btw melyik fájlt töltse be a man, azt is nyilván kell tartani.

Vírusirtót Windows alatt használni kell. A vírus adatbázis az idők alatt folyamatosan nő. Már csak a mérete is aggasztó a definíciós adatbázisnak. És minden rekord, ami ebben van, olyan tartalommal rendelkezik, ami alapján elemzéseket végez a vírusirtó kvázi minden fájlon egyenként - minden rekorddal. Azaz rekordok száma szorozva fájlok száma művelet fut. Akár a definíciós adatbázis növekedik, akár a fájlok száma növekedik, növeli a műveletek számát.

Mivel minden változatot / verziót megőriz a WinSxS mappa, a fájlok irdatlan ütemben szaporodnak.

A Linux frissítéskor nem tartja meg a régebbi csomagokat. Timeshift viszont igen, de az is csak pár napig. (Van olyan disztribúció, pl. Gobo Linux, amelyik megtartja a régebbi verziójú csomagokat is)

Prefetch: Ez az XP-nél vezették be. Kb. arról van szó, hogy pl. induláskor a feltétlenül szükséges programokat a Windows elmenti úgy, hogy azok memóriába töltött gépi kódját használja a mentéshez, így induláskor egyből betölti a memóriába, ami a Windows betöltési idejét nagyon lerövidíti (A Windows 10 Fast startupja ehhez hasonló, de nem erről van szó).

A Prefetch méretét minden újabb Windows alatt növelték, Windows 10 alatt már 128 bejegyzése is lehet… Miközben eddig mindig is úgy volt, és most is az van, hogy az indulásra feltétlenül szükséges programok (videokártya drivere, vírusirtó) az idők során akkorára híztak, hogy egymagukban sem fértek el a Prefetch tárterületre. Ez is úgy manifesztálódik, hogy a Windows az idő múlásával egyre lassabban indul.

Frissítések:

Linuxnak alatt alapesetben a repóból egy ütemben frissül minden. Illetve lehet még PPA, ha a disztribúció támogatja. Illetve frissülhet a flatpak is, ha rendszer támogatja. De a lényeg, hogy ütemezetten csak egy frissítéskezelő kukucskál kifele, egy csatornán.

Windows alatt a telepített programok maguk gondoskodnak a frissítésről. A Windows maga is. Azaz: a rendszer indulásakor az összes telepített program nyit egy-egy csatornát az internetre, ellenőrzi, hogy van-e frissítés, összehasonlítja a helyi fájljait a neten levőkkel… Mind egyszerre! (Tisztelet a kivételnek, vannak, akik ezt ütemezve oldják meg, pl. az Adobe cuccai, ill. a JAVA RE ilyen)

De ugye megvan az, hogy Windows elindul, majd karikázik, karikázik, kerregteti a HDD-t (világít a HDD LED SSD esetén) oszt úgy 10 perc múlva esetleg használható lesz?

Programok elérhetősége, telepítése:

OK, módosítsunk a szabályokon, lehet telepíteni bármit, amire szükségünk van.

Windows alatt mondhatni nincs ezzel gond. Rá kell keresni a programra aztán letölteni, telepíteni, és slussz. A Windows side by side-nak köszönhetően mondhatni bármilyen régi programot is telepíteni lehet. Kivéve, amit meg nem. De a nagy többség ilyennel nem találkozik, ráadásul jellemzően jobb erőforrással rendelkező kiadók rendszeresen frissítik, kiadják az újabb verzióját a programnak, ami fut újabb Windows alatt is. Pl. a vírusirtók jellemzően olyanok, amiket újabb Windows verzióhoz újra kell írni. De vannak olyan jellemzően hardverhez kapcsolódó programok, (amik drivert is igényelnek), amelyek nem futnak újabb Windows alatt. Lehet ez szkennerrel kapcsolatos alkalmazás, vagy pl. nekem van műholdas vevő kártyám, ami csak XP alatt volt kezelhető, USB3.0 bővítő kártya, de ilyenek a hálózattal kapcsolatos programok is, amik olyan protokollra támaszkodnak, amit az újabb Windows nem támogat.

Windows alatt többféle telepítő létezik, pl. van az MSI, ami a Windows saját installerje, de használhatják mások is, és vannak harmadik féltől származó telepítő programok is, amit használhatnak a programot kiadók, ill. írhat saját telepítőt a programot kiadó szervezet is.

Tehát jellemzően van egy SETUP.EXE telepítő program, ami felmásolja a fájlokat, beregisztrálja amit kell, létrehozza az indítókat az asztalra, a start menübe…

Létezik olyan eset is, hogy a program maga működne a frissebb Windows alatt, de a telepítő már nem. (Nullsoft régi telepítője pl.)

Ugyancsak létezhet olyan, hogy közvetlenül internetről települ valami, ilyen volt pl. a JAVA Webstart programja, de az ilyen műveletek rendszerint biztonsági problémába ütköznek, azaz folyamatosan korlátok kerülnek bevezetésre a sok biztonsági probléma miatt, így ezek folyton háttérbe szorulnak.

Továbbá van olyan, hogy adott alkalmazásnak szüksége van valamelyik Windows programra, és ez egyszer csak leváltásra, vagy korlátozásra kerül. Pl. ActiveX alkalmazások. (mint Internet Explorer bővítmények)

Linux alatt merőben másképp működik a telepítés. Az alaphelyzet az, hogy van egy telepítő szkript. Pl. SETUP.SH. és ennek futtatható attribútummal kell rendelkezni. Namármost, az attribútum az egy fájlrendszer tulajdonság. Attól a pillanattól kezdve, hogy egy fájlt elválasztunk a fájlrendszertől (elküldjük e-mailban, feltöltjük az internetre), annak az attribútumai elvesznek, mármint nem mennek a fájllal együtt. Az ilyen letöltött SH fájlra be kell állítani a futtatható attribútumot.

Mi van akkor, ha tömörítve van? A tömörítő programok tudják tárolni az attribútumot is. Kicsomagoláskor beállítják a fájl eredeti attribútumát is. Az ilyen fájlokra nem kell beállítani a futtatható attribútumot. Mármint ha az előre, a küldő oldalon be lett állítva. Ha ott nem lett beállítva, akkor viszont nekünk kell beállítani.

Logikus, érthető, nem? -(ennek ellenére folyton megkeresnek, hogy nem fut az sh, pedig a múltkori az futott)

Ugyanez igaz az appimage-ra is. Ha közvetlenül volt letöltve, akkor be kell állítani a futtatható attribútumot. Ha ZIP-ben volt letöltve, és be volt eleve állítva – akkor egyből futtatható kicsomagolás után.

Az appimage az egy olyan program Linux alatt, ami tartalmaz minden függőséget, meg ami kell neki ahhoz, hogy fusson, elvileg le kell tölteni, és futtatni, ennyi.

Pl.: Openshot videószerkesztő, ez olyan appimage, amit le kell tölteni, de be kell állítani rá a futtatható attribútumot.

Mindez szokatlan lehet Windowshoz szokott felhasználónak, lévén, hogy Windows alatt nincs olyan, hogy futtatható attribútum, így ilyen gond sincs. Windows alatt kiterjesztés jelzi azt, hogy a fájl futtatható programként.

Az appimage olyasmi, mint Windows alatt a portable program. Ezek olyan programok, amik lényegében rámásolhatók egy pendrájvra, amit másik gépbe bedughatunk, és ott futtathatjuk, azaz, hordozható. Nem biztos, hogy egy fájlról van szó, de egy mappába másolható a programhoz tartozó összes fájl, és úgy lehet használni. Nem minden program hordozható, de pl. az IrfanView, vagy a Total Commander az ilyen.

Linux alatt tehát ilyen az appimage, persze, a pendrájvnak, amire rámásoljuk, ext4 fájlrendszerűnek kell lennie, hogy tárolja a futtatható attribútumot.

Az appimage előnye, hogy minden Linux alatt futtatható (a gépnek azért alkalmasnak kell lennie ehhez), egyben tartalmaz mindent, ami a futáshoz kell. És nem kell Sudo sem a „telepítéshez”, azaz, olyan gépen is lehet használni, aminek nem ismert a rendszergazda jelszava.

Ugyanakkor jóval nagyobb, több helyet foglal, a „normál” csomagkezelővel telepített változathoz képest.

Nem támogatja a rendszer frissítéskezelője, azaz nem frissül automatikusan, ha van frissebb verzió, azt magunknak kell letölteni. Megteheti maga a program is, hogy figyelmeztet a frissebb verzióra, és mutathat egy linket a letöltő oldalhoz, az Openshot pl. ezt tudja.

De létezik az Appimage Launcher programkezelő, amivel karban tarthatók ezek a programok, ez kapcsolatot tart az AppimageHub oldallal, ahonnan képes frissíteni is ezeket a programokat.

Az AppimageHub oldalon közvetlenül is tallózhatunk az alkalmazások között, letölthetjük bármelyiket.

A Flatpak nagyon hasonló az appimagehoz, viszont eltérő technológia. Odáig egyezik a dolog, hogy ez is tartalmaz minden függőséget, viszont ez decentralizált, ami azt jelenti, hogy míg a fentinek van központosított tárhelye, ezeket a saját disztribúciónkon keresztül, annak szoftverközpontjából tölthetjük le. További eltérés, hogy ezek a rendszerben elkülönítve futnak, mintegy homokozóban, így előfordulhat olyan, hogy nem fér hozzá olyan erőforrásokhoz a helyi gépen, amihez külön jogosultság kell. Mivel saját szoftver forrásból telepíthető, a frissítés kezelő támogathatja, kaphatunk automatikus frissítéseket (Linux Mint frissítéskezelője ezt tudja)

Tehát, pl. itt a Flathub.org oldalán böngészhetjük a programokat, bármelyik telepítését kezdeményezhetjük, ám mindez egy flatpakref fájl letöltését jelenti, amit megnyitva az elirányítja a szoftverkezelőnket a kívánt programhoz.

Általában jellemző, hogy ugyanannak a programnak az appimage változata gyorsabb, mint a flatpak változat.

A deb csomag az egy olyan konténer formátum, ami a Debian rendszerben lett kialakítva. Mivel az Ubuntu ennek származéka, a Mint pedig az Ubuntu vagy Debian származéka, mind Ubuntu mind Mint alatt támogatott a formátum. A DEB nyilvántartja a szükséges függőségeket is, a helyi telepítő (ami lehet parancssoros, vagy a grafikus Gdebi) ezeket képes pótolni, letölteni, telepíteni, ha azok elérhetők a rendszerhez.

Nos, ha internetről letöltött DEB fájlt akarunk telepíteni, akkor tudnunk kell, hogy melyik passzol a rendszerünkhöz. Pl. az alábbi ábrán a focal0 (nyíllal jelölt sor) tartozik a Linux Mint 20.x-hez.

Az is lehet, hogy csak egyetlen egy DEB fájlt lehet letölteni, mert előtte a weboldalon minden ki volt választva, hogy melyiket töltsük le, oszt az mégsem működik. Akkor érdemes benézni a saját szoftverkezelőnk kínálatába, előfordulhat, hogy ott is rendelkezésre áll a kívánt szoftver másik, ámde tesztelt, és garantáltan futó verziója.

Oda kell figyelni, hogy mi jelenik meg a képernyőn!

Pl. itt megadjuk, hogy Linux mint, hogy 64 bites, és a 18+ (Mint 18 utáni), letöltjük, és ezt kapjuk ha a DEB csomagon duplán kattintunk:

Ott fent, a narancssárga sávot illik észrevenni. Ha azt írja, hogy 3 csomag telepítését igényli, akkor az tényleg azt is jelenti. Ez nem hiba, ez egy figyelmeztetés. Ha narancssárga helyett piros lenne, akkor az hibát jelent.

Ha a csomag telepítése gombra kattintunk, akkor ez jön velünk szembe:

Ha most itt ENTERT ütünk, akkor a telepítés nem fog sikerülni. Nem kell pánikolni, nyugodtan a folytatás gombra kell kattintani. (A konkrét esetben pánik volt, mert 5 perc múlva zoom konferencia volt esedékes, és nem volt a gépen zoom kliens)

Azt tudni kell, hogy az ilyen módon telepített programokhoz nem lesz indító ikon az asztalon, sem a menüben. Hacsak az nincs felkészítve erre. Azt is jó tudni, hogy ez így nem lesz frissítve a frissítés kezelő által, amikor a program újabb verziója kijön. Kivéve, ha az erre nincs felkészítve.

Pl. a Google Chrome böngészőt ugyanígy letölthetjük, azaz egy DEB fájl formában. Azon duplán kattintva: - felvesz egy PPA-t a rendszerbe, azon keresztül letölti, telepíti a Chrome-t, létre hozza az indítókat, és biztosítja az automatikus frissítéseket is -mivel Ubuntu és ez alapú Mint támogatják a PPA-t.

A PPA az a jelen kontextusban a Personal Package Archive-t jelenti. Ez egy olyan személyes tároló, ami elkülönül a disztribúció saját szoftver forrásától, de fel lehet venni a rendszerbe (Ubuntu és származékai alatt), így azt ugyanúgy kezeli, mint a saját szoftverforrását, képes azon keresztül programokat telepíteni, beleértve az automatikus frissítést is. (A PPA ugyanakkor egy csomó más fogalom és szervezet rövidítése is)

A linuxos PPA fenntartója lehet egyetlen személy, vagy kiterjedt szervezet. Utóbbira példa a Google (Chrome), vagy a Wine.

„Egyetlen emberes” PPA pl. a Double Commander PPA-ja.

A saját rendszer hivatalos szoftverforrása – ezt egyes disztribúciók alatt parancssoron keresztül lehet elérni, más disztribúciók alatt a grafikus Synaptic csomagkezelővel, de Mint alatt van saját grafikus alkalmazás is, amit menüből elérhetünk az Adminisztráció → Szoftverkezelő alatt.

Itt válogathatunk a programok között, és ezek elvileg kipróbált, tesztelt programokat jelentenek, amik biztosan futnak Mint alatt. Ugyanakkor ennek a hátránya mondhatni az, hogy jellemzően a programok régebbi verzióit találjuk itt (Mint alatt). Viszont működnek, és innen telepítve lesz indító a menüben.

A Snap formátum nem túl régi, a Canonical (az Ubuntu kiadója) saját erőltetett megoldása. Előnye, hogy számos eltérő architektúrát támogat, de ilyen olyan okok miatt Mint alatt ez le van tiltva. Lehet engedélyezni… Ez a formátum is konténerben fut, tartalmaz minden szükséges függőséget, viszont méretben túltesz az appimage-n és flatpak-on is. És ugyanaz a program még lassabb is snap formátumban mint az appimage vagy a flatpak.

Egyéb telepítési lehetőség pl. az install4j. Ez keresztplatformos, (lévén JAVA), azaz Windows alatt és Linux alatt is elérhető, Linux alatt tud telepíteni ugyanúgy, és a telepített program frissítését is tudja, mármint tartalmaz java osztályt, amit a programba lehet integrálni, azaz az ilyen programok tudnak automatikusan frissülni - Windows program módon, saját maguk letöltik és telepítik a frissítést.

Telepítés forrásból (pl. github). Van úgy, hogy adott program nem érhető el csak forráskód szinten. A programok forráskódját is le lehet tölteni, azonban ennek használatához tapasztalat szükséges. A dolog ott kezdődik, hogy Mint nem is tartalmaz alapból fejlesztői csomagokat, amik viszont szükségesek a forrás fordításhoz. Fejlesztői csomagból viszont rengeteg van, nem mindegy, hogy melyiket telepítjük. El kell olvasni a fordítási dokumentációt, telepíteni kell a szükséges csomagokat. Ha ezzel készen vagyunk, akkor el lehet indítani a fordítást. És mindezeket a műveleteket terminálban kell végezni, a fordítás során meg lehetnek hibák, hiszen ez nem feltétlenül egy stabil program, ezért is van még a jelenlegi állapotában. A fordítás közben jelentkező hibákat fel kell ismerni, és megoldás után kutakodni.

A függőségek kérdésköre

Függőségek, függőségek -mégis mik ezek? Hát olyan fájlok, amiknek telepítve kell lenniük, ahhoz hogy a dolog működőképes legyen. Hogy mihez lehet kezdeni ezzel az infóval? Mégis mit akar ezzel a Linux?

Először is, függőségek Windows alatt is ugyanúgy vannak. Sőt, ott több szintű módon is. Mert vannak olyan kiterjesztések, amiket fel kell telepíteni adott program miatt, és ezeknek meg külön függőségei vannak. Olyasmik ezek, mint pl. a Java futtató környezet. Windows alá is van, és van továbbá Directx; .NET; MSXML parser; meg anyámtyúkja. Volt idő, amikor a program telepítő CD-je, pl. egy játéké, az tartalmazta a Directx függőséget, amit külön fel kellett telepíteni ahhoz, hogy fusson a játék. Azért volt ez így, mert nem biztos, hogy nem volt a gépen eleve Directx, ám ha nem volt, akkor legyen kéznél. Ám senki nem olvasott dokumentációt, hanem egyből nyomták a telepítőt, oszt ha mégsem volt Directx a gépen, vagy nem olyan verziójú volt, akkor meg ment a szitok. Így később meg lett oldva, hogy a telepítő felrakja a Directx-et is, (ha később volt telepítve a 6-os, mint a gépen levő 7-es, akkor azt felülírta, az aktuálisan telepített játék ment rendesen, de a régebben telepített játékról, hogy az nem fut már, csak később derült ki, és lehetett kutakodni, hogy mi történt. -ez így volt, amíg a Side by Side nem volt bevezetve)

Tehát igen, Windows alatt a telepítők felteszik a háttérben a függőségeket is, Linux alatt is felteszik, ha elérhető, de erről tájékoztatás is van.

= Az ötödik rész vége =