diff --git a/hu_HU.ISO8859-2/articles/version-guide/article.sgml b/hu_HU.ISO8859-2/articles/version-guide/article.sgml index 22a9815105..25a2dbfd0f 100644 --- a/hu_HU.ISO8859-2/articles/version-guide/article.sgml +++ b/hu_HU.ISO8859-2/articles/version-guide/article.sgml @@ -1,529 +1,523 @@ %articles.ent; ]>
Válasszuk ki a nekünk igazán megfelelõ &os; verziót! A &os; Dokumentációs Projekt $FreeBSD$ &tm-attrib.freebsd; 2005 A &os; Dokumentációs Projekt Ön a &os; telepítését választotta. Üdvözöljük! Ezt a leírást annak szellemében készítettük, hogy segítsünk eligazodni a telepíthetõ verziók között. Fordította: &a.hu.pgj; Háttér A leginkább megfelelõ verzió kiválasztásához fontos megértenünk néhány alapvetõ fogalmat a &os; fejlesztési modelljével és az ún. Release Engineering (RE, kiadásépítés) folyamatával kapcsolatosan. A &os;-t nagyrészt független önkéntesek hatalmas csoportja fejleszti. A rendszermag, a legalapvetõbb függvénykönyvtárak, valamint a hozzájuk tartozó segédprogramok forrásait egy verziókövetõ rendszerben tárolják, amely bárki által és bármikor tetszõlegesen letölthetõ. Ettõl függetlenül ezek lefordított változatai (binárisai) is rendszeresen elérhetõek. Néhány ilyen binárist alapos és széleskörû tesztelési folyamatnak vetnek alá, majd kiadásnak címkézik fel õket. Kiadások A kiadások (release) általában rendelkeznek egy fõverziószámmal és egy alverziószámmal. A fõverziószámok feladata, hogy jelezze az újabb, nagyobb változtatásokat a rendszerben. Ilyenkor természetesen elkerülhetetlen, hogy ennek következtében komolyabb átszervezéseken menjen át a &os;, vagy éppen a régebbi, már hasztalannak tekintett részei eltûnjenek. Emiatt gyakran még a korábbi fõbb kiadásokkal kapcsolatban is elveszhet bizonyos mértékû kompatibilitás. Az alverziószámok jelzik a megbízhatóságot és a teljesítményt érintõ kisebb hibajavításokat. Ebben az esetben mind a forráskód-, mind pedig a bináris szintû kompatibilitás megtartása egyik elsõdleges feladatunk. Alkalmanként az alverziókba is kerülhetnek újítások, de csak akkor, ha ezek nem fenyegetik a velük szemben kitûzött összes többi célt. Azonban sose szabad elfelejtenünk, hogy egy kiadott verzió nem több, mint a forrásról egy adott idõben és egy adott néven (címkével ellátott) készített pillanatfelvétel. (Például az 5.4-es kiadáshoz a kiadásépítõk a RELENG_5_4_0_RELEASE címkét tették.) A fejlesztés a HEAD néven ismert címkével azonban mindig halad tovább. Fejlesztési ágak Minden kiadás alkalmával létrehoznak egy fejlesztési ágat, mint mondjuk a RELENG_5_4. Habár a RELENG_5_4_0_RELEASE címkével ellátott források már nem fognak a továbbiakban változni, a RELENG_5_4 címkével rendelkezõk ellenben még igen, méghozzá a HEAD ágból származó biztonsági vagy egyéb javítások, esetleg kisebb változtatások nyomán. Egy-egy fõbb kiadáshoz még egy másik címkét is létrehoznak, mint mondjuk a RELENG_5. A biztonsági és egyéb javításokon túl más módosítások is áthozhatóak a HEAD ágból, így tulajdonképpen ez lesz az aktív ág, amikor a következõ kiadást készítik elõ az adott vonalban. <firstterm>STABLE</firstterm> vagy <firstterm>CURRENT</firstterm>? Minden egyes nagyobb kiadás életciklusában létrejön még egy további fejlesztési ág, amelyet STABLE-nek (megbízhatónak) neveznek. Ezzel jelzi a &os; Projekt, hogy véleménye szerint az adott ágban szereplõ módosítások minõsége elegendõ a szélesebb körû használathoz. Azokat az ágakat pedig, amelyeknek további tesztelésre van szükségük a komolyabb használathoz, CURRENT-nek (aktuálisnak) nevezik. A &os; Projekt nem tudja garantálni, hogy stable-ként szállított szoftverek elegendõek egy telepítéshez. Ezt mindenkinek magának kell eldöntenie. Nem szabad elfelejteni, hogy ez a projekt elsõsorban önkéntesekbõl áll és nem képes a mûködésre semminemû szavatosságot vállalni. <firstterm>Portok</firstterm> vagy <firstterm>csomagok</firstterm>? Az említett állományokon kívül a &os; még több ezernyi, külsõ fejlesztõk által készített alkalmazásokat is támogat. (Ilyenek a különbözõ ablakkezelõ rendszerek, böngészõk, levelezõ kliensek, irodai programcsomagok, és így tovább.) Általánosságban véve nem a projekt maga fejleszti ezeket a szoftvereket, csupán egy keretrendszert biztosít a telepítésükhöz (amelyet Ports Collection-nek (portgyûjtemények) neveznek). Attól függõen, ahogy ezt a licenszelésük megengedi, ezek az alkalmazások telepíthetõek forrásból (ezeket nevezik portoknak), vagy elõre lefordított binárisokból (ezeket nevezik csomagoknak). Ahogy eddig ütemeztük a kiadásokat A &os; 5.X verziójának fejlesztése és kiadása során sok-sok olyan tapasztalatot szereztünk, amelyek csak utólag váltak világossá számunkra. Az 5.X-es vonal célkitûzései meglehetõsen agresszívek voltak és magukban foglalták a következõket: Az SMP (Symmetric MultiProcessing) rendszerek támogatása A teljesítmény növelése a kernelen belüli erõforrás-kiosztás egy új stratégia szerinti átdolgozásával Számos új processzor architektúra támogatása Egy új szálkezelési modell bevezetése Egy új ütemezõ bevezetése Új technológiák, mint például az energiagazdálkodás, támogatása (különösen laptopok esetén); és ami a legfontosabb: Addig nem tekintjük ezt a vonalt STABLE-nek, amíg az imént felsorolt feladatok be nem fejezõdnek. Ez egy olyan helyzet kialakulásához vezetett, ahol évek teltek el a 4.X vonal STABLE és az 5.X vonal STABLE kiadásai között. Ez magával hozott néhány tényleges kellemetlenséget: Az egyszerre kivitelezendõ újításokhoz kapcsolódó módosítások nagy száma jelentõs mértékben megnehezítette az egyes módosítások elkülönítését és beolvasztását a STABLE ágba. Ez pedig azt jelentette, hogy azok a felhasználók, akiknek igazán szüksége volt bizonyos újításokra (például, hogy képesek legyenek futattni a rendszer egy modern hardveren), kényszerûen átálltak (mondjuk) a &os; 5.2.1-es verziójára, annak ellenére, hogy az kifejezetten egy fejlesztõi kiadás volt, és hogy CURRENT kiadás lévén nem felelt meg teljes egészében minden igényüknek. A beolvasztások során a fejlesztõk néha olyan helyzetbe kerültek, ahol olyan verzión kellett az újításaikat támogatniuk, amelyeket nem elsõdleges fejlesztõi platformként használtak. A késés továbbá azt jelentette, hogy mire az 5.3 végre STABLE szintû kiadássá válhatott, az idõközben felgyülemlett módosítások terhe kínszenvedéssé tette a frissítési folyamatot. Úgy szólván senki sem volt elégedett ezzel az eredménnyel. A következõket tanultuk mindezekbõl: A fõbb kiadásoknak kevesebb újítást kell tartalmazniuk és gyakrabban kell megjelenniük. A lehetõ legjobban el kell szigetelni egymástól a különbözõ újításokhoz kapcsolódó módosításokat. (Ez egyben arra is utal, hogy bizonyos fejlesztéseket nem az aktív forrásokon belül végezni, és majd csak akkor beolvasztani õket, ha már nem veszélyeztetik egyik párhuzamos fejlesztést sem.) A fõbb kiadások határidejét inkább idõben kell megszabni, nem pedig az újítások mértékében. Ha az egyes újítások nem készülnek el idõre, akkor ki kell õket kapcsolni és meghagyni egy késõbbi kiadásra. Kevesebb újítással és gyakoribb megjelenéssel remélhetõleg csökkeni fog az egyes módosítások beolvasztásához szükséges idõ a HEAD ágból a legfrissebb STABLE ágba (és ezáltal nem csak egyetlen fejlesztési vonalban maradnak támogathatók). Továbbá, mivel ezek az módosítások kellõképpen elszigeltek egymástól, az integrálás során keletkezõ hibák kockázata is csökken. Sõt, az idõben megkötött határidõknek köszönhetõen végre könnyebben tervezhetnek elõre a felhasználók, a külsõ alkalmazások fejlesztõi és maguk a &os; fejlesztõi is egyaránt. - - Nem más operációs rendszerek verzióival - történõ versenyfutás, hanem ezek a - megfontolások indokolják a szándékot, - hogy a jövõben az ütemezésünket - átszervezzük. Ahogyan majd szeretnénk ütemezni a kiadásokat Íme a Projekt jelenlegi céljai az ütemezésben: Minden 18 hónapban új fõbb kiadás megjelentetése; Minden 4 hónapban új kisebb kiadás megjelentetése; Minden fõbb kiadás legfrissebb kiadásához elõkészített csomagokat nyújtani; Minden fõbb kiadás legutóbbi néhány kiadásához biztonsági frissítéseket és kritikus hibajavításokat (biztonsági fejlesztõi ágak) nyújtani; Tekintettel a telepíthetõ verziók kombinációjának nagy számára, nem lehet minden egyes verziót korlátlanul támogatni; ezt részben a rendelkezésre álló gépi erõforrások korlátozzák, de leginkább a projektben résztvevõ önkéntesek által nyújtott segítség mennyisége. Az érdeklõdõk figyelmébe ajánljuk továbbá: The Release Engineering Schedule The Security Branch Schedule Az említett dokumentumok még nagyobb mélységben részletezik a tárgyalt hátteret, és feltárják azokat folyamatokat, amelyek a támogatott fejlesztõi ágakat és azok élettartalmát illetõ döntéseket befolyásolják. Hogyan befolyásolják ezek a tényezõk a döntésünket? Az alábbi kérdések megválaszolása határozhatja meg a döntést a megfelelõ verzió kiválasztásában: Milyen mértékû megbízhatóságot várunk el a rendszertõl? Mennyire vagyunk hajlandóak frissíteni a rendszerünket? Mennyire gyakran szeretnénk frissíteni a rendszerünket? Mennyire fontos számunkra a biztonság? Forráskódból vagy bináris állományokból akarunk telepíteni? Szeretnénk részt venni a &os; fejlesztésében? Néhány további vázlatos útmutatás a döntéshez: Ha rövid idõn belül az elérhetõ legnagyobb mértékû megbízhatóságból szeretnénk profitálni, viszont nincs lehetõségünk frissíteni, akkor minden bizonnyal a legfrissebb STABLE jelzésû kiadást lenne hasznos feltelepítenünk és használnunk. Biztonsági igényeinknek megfelelõen érdemes követni az adott kiadáshoz megjelenõ javításokat. Ha rövid idõn belül vagy szükségünk van a legfrissebb újításokra vagy pedig a biztonsági javításokra, valamint az idõt és erõforrást sem sajnáljuk a frissítésre, érdemes a legújabb STABLE ágat követnünk. Ha nem kívánjuk közvetlenül élesben használni a rendszert és csak bizonyos problémák érdekelnek minket, valamint a következõ nagyobb kiadás néhány hónapon belül megjelenik, valószínûleg érdemes elgondolkodni annak az ágnak telepítésén, ezzel is segítve a projektet a kiadás tesztelésében, megbízhatóvá tételében és úgy egyáltalán jobbá tenni a hosszú távú használatra. Ha csak forrásból szeretnénk telepíteni és hibákat keresni az alaprendszerben, vagy éppen utánajárni az ismert hibáknak, illetve nyomon követni õket az ezzel kapcsolatos levelezõlistán, érdemes a HEAD fejlesztési ágat használnunk. Végszó Reméljük, ez a leírás hasznos kiindulásnak szolgált a &os; fejlesztési modelljének megértésében és az igényeinknek legjobban megfelelõ verzió kiválasztásában!