From a5f768fd925b5f412e39fb5a47794099a8a78538 Mon Sep 17 00:00:00 2001 From: Gabor Kovesdan Date: Mon, 3 Sep 2007 11:18:56 +0000 Subject: [PATCH] - Add translation of version-guide article Submitted by: Gabor Pali Approved by: keramida (mentor) --- .../articles/version-guide/Makefile | 24 + .../articles/version-guide/article.sgml | 526 ++++++++++++++++++ 2 files changed, 550 insertions(+) create mode 100644 hu_HU.ISO8859-2/articles/version-guide/Makefile create mode 100644 hu_HU.ISO8859-2/articles/version-guide/article.sgml diff --git a/hu_HU.ISO8859-2/articles/version-guide/Makefile b/hu_HU.ISO8859-2/articles/version-guide/Makefile new file mode 100644 index 0000000000..152fafc672 --- /dev/null +++ b/hu_HU.ISO8859-2/articles/version-guide/Makefile @@ -0,0 +1,24 @@ +# $FreeBSD$ +# +# Article: FreeBSD Version Guide + +# +# Tidy messes up iso-8859-2 characters +# + +NO_TIDY= yes + +MAINTAINER= pali.gabor@gmail.com + +DOC?= article + +FORMATS?= html +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/hu_HU.ISO8859-2/articles/version-guide/article.sgml b/hu_HU.ISO8859-2/articles/version-guide/article.sgml new file mode 100644 index 0000000000..e1c1851777 --- /dev/null +++ b/hu_HU.ISO8859-2/articles/version-guide/article.sgml @@ -0,0 +1,526 @@ + +%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 + egyesek ú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 az + én 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! + +