FreeBSD versijos: kas, kur, kaip, kodėl?

Internete dabar pilna darbinių stočių, kuriose naudojamos įvairios FreeBSD versijos: 4.x, 5.x, 6.x ir gal net senesnės. Kaip atsirinkti, ką naudoti?

FreeBSD kūrėjai rekomenduoja naudoti 6.0 versiją, nes, anot jų, ji jau yra pakankamai stabili ir ištestuota, taip pat yra daug atnaujinimų lyginant su 5.x ar 4.x seriją. Taip pat jie teigia, kad 4.x bus tuoj išvis nepalaikoma, o 5.5 (dabar yra 5.4) bus paskutinė 5.x serijos FreeBSD OS. Tad tai palieku spręsti Jums patiems, o aš renkuosi 6.x seriją.

Kitas dalykas, kuris daugiausiai neduoda ramybės – FreeBSD versijų tipai (CURRENT, STABLE, RELEASE). Pabandysiu paaiškinti, ką jie reiškia:

CURRENT yra dabar kuriama FreeBSD versija, kuri vėliau taps 7.x serija. Kūrėjai stengiasi, kad ši versiją būtų įmanoma sukompiliuoti, bet naudoti jos gali būti neįmanoma. Naudodami šią versiją rizikuojate prarasti savo duomenis.

STABLE yra kūrimo medis (medžiai), kuris naudojamas paskutinėms FreeBSD versijoms. Kiekviena FreeBSD versija (5.x, 6.x ir t.t.) turi STABLE medį. STABLE medis yra sukuriamas iš CURRENT medžio. Šiuo metu yra šie medžiai: 4-STABLE, 5-STABLE ir 6-STABLE. Tai taip pat yra kūrimo stadijos medžiai, bet daug stabilesni už CURRENT. Taip pat jie yra testuojami daug daugiau, nei CURRENT, bet negarantuoja, kad viskas veiks taip, kaip turėtų veikti. CVS tag’ai: RELENG_4, RELENG_5, RELENG_6.

RELEASE versijos yra fiksuotu laiko momentu paimtas STABLE medis. Po šio proceso šios versijos yra aktyviai testuojamos ir tada išleidžiamos kaip pilnai naudojamos operacinės sistemos. Naujausios RELEASE versijos yra 4.11, 5.4 ir 6.0. CVS tag’ai yra tokie: RELENG_4_11_0_RELEASE, RELENG_5_4_0_RELEASE, RELENG_6_0_0_RELEASE ir t.t. Šios versijos yra pateikiamos ISO vaizduose / kompaktiniuose diskuose.
Taip pat pastarosios versijos turi saugumo atnaujinimo versijas/žymes. Šių versijų pavadinimo gale yra pridedama -pX, kur X yra skaičius, kuris nurodo padarytų atnaujinimų skaičių. Pavyzdžiui, FreeBSD 4.11-RELEASE-p18. Tai yra versijos, kurias reiktų naudoti eiliniams/standartiniams FreeBSD vartotojams.

Tags:

4 Responses to “FreeBSD versijos: kas, kur, kaip, kodėl?”

  1. Markas says:

    Va pagaliau radau kazka apie FreeBSD lietuviskai. Jop. 6.x super, sukasi tvarkingai ir lanksciai. Nera tokio stabdymo kaip anksciau.

  2. C says:

    As pradejau su 3.3 ir seku fryshke iki dabar. Mano nuomone be visu graziu (kartais ir mielu) pribombasu, kurie atsirado su 6.x, is 6.x serijos nieko gero.. tikejausi, kad Skotas spes bent jau ULE kartu su 6.x paleisti – deja.. Jus bandet kiek intensyviau panaudoti 6.x native threadus? :). Nzn kaip jum, bet man pvz mysql’as idealiausiai sukosi su 4.x linuxthread’ais, o freebsd native threadam dar oi kaip yra kur tobuleti. O ir siaip, 6.x production’e nesu labai patenkintas. Aisku, tenka naudoti, vien del to, kad 5 saka perejo i legacy stadija, bet kazkaip jauciu, kad freebsd truputi ne i ta puse suka.. Markai, o kas tau anksciau stabdydavo?

  3. Na, čia jau seniai aišku, kad FreeBSD projektas vos vos juda į priekį (pavyzdžiui, lyginant su linux). Nėra didelio finansavimo, nėra žmonių… Šiaip gaila dėl to.

    MySQL’ą su didesniais load’ais teko išbandyti tik po 5.x ir 6.x, tad nežinau, kaip buvo ankščiau. O kaip testuojate pats? Kaip sukompiliuotas dabartinis MySQL’as? Ar daryta kažkokia pačio demono optimizacija?

    O šiaip faktas lieka faktu visvien – FreeBSD reiktų gerokai padirbėti tiek su thread’ais, tiek su SMP.

    Beje, FreeBSD developeriai teigia, kad 6.x yra pridaryta daugybė pakeitimų, kurie turėtų būti sistemai tik į naudą. Ale aš asmeniškai skirtumo nepastebėjau.

  4. C says:

    Negali sakyti, kad juda labai jau letai – paskutiniu metu developeriai tikrai smarkiai suaktyvejo, tik nesu tikras, ar tai i nauda (mano manymu net ir anksciau buvusi freebsd stirpiausia vieta – memory management’as 6.x versijoje siek tiek kreiviau perrasytas). Aisku, dauguma dalyku yra customize’inama, tad negali kaltinti freebsd developeriu, gal jie tiesiog pagal nutylejima sistema labiau taiko silpnensiu parametru serveriam arba ja daro kuo universalesne (kad nekiltu problemu kitose architekturose), o parametru tweakinima hi-performance’o vardan palieka adminam :)

    Linux’a is principo nelabai megstu, bet daugiau apkrovu reikalaujancius mysql serverius pradejau statyti tik ant linux’o. Neseniai praleidau tris dienas ant vienos gan stiprios masinos (Dual Xeon’o su 4G RAM’o ir 4×15kRPM RAID-10 masyvu) atlikinedamas ivairiausius mysql testus (tiek su skirtingom fs ant skirtingu linux’u, tiek su skirtingom freebsd versijom ir pan), rezultatai (ka ir buvo perskaites anksciau, tik norejosi pamatyti savo akimis) – vienareiksmiskai linux’as (zaidziau tik su 2.6), XFS ir mysql AB gaminamos binarines distribucijos.

    MySQL’a paprastai kompiliuoju is portu, statini su visom optimizacijom (man atrodo prie mysql porto rasymo prisidejes pats Jeremis Zawodny) – tai berods yra ir mysql.com rekomendacija, taciau benchmarkinimo metu panaudojus keleta sudetingesniu queriu is production’o ir sudejus i super-smack’a sugebejau pasiekti toki efekta, kad mysql’as gauna viso labo ~700 qps (na, bet ne labai lengvu), sistema praktiskai visiskai idlina (cpu 100% idle, diskai 0% busy), o load’as – tik kyla. Uzklausos praktiskai visiskai ne vyksta. Production’e tokie “bajeriai” man nepatinka :). Tai dabar neberizikuoju. Beje, Jeremis, man atrodo, yahoo mysql serverius irgi is leto kelia i linux’a, nors pat idejo begale pastangu, kad mysql puikiai veiktu freebsd aplinkoje ir eile metu sekmingai naudojo ta kombinacija.

    Su cpu scheduleriu FreeBSD dirba ir dirba.. berods 5.2-pre jau net buvo ULE naudojamas, kaip pagrindinis scheduleris, bet del islindusiu bug’u nusprende dar kuriam laikui atideti. Nors, keletoje serveriuku su freebsd 5.x ULE gan sekmingai sukasi (tai butent mysql serveriai), – performance tikrai geresnis nei su 4BSD. Beda tik ta, kad prie didesniu load’u masina luzta. Laimei, to paskutiniu metu pavyksta sekmingai isvengti :)

Leave a Reply