Melyik kiadási ciklus a legszimpatikusabb számodra? (indokold a hozzászólásokban)

Címkék

fix kiadás 6 havonta, de egy szolgáltatás nincs kész, akkor az nem kerül be: OpenBSD; MVS, OS/390, z/OS; AIX '99ig
14% (98 szavazat)
kiadás körülbelül 4 havonta: FreeBSD
2% (12 szavazat)
kiadás 1-3-5 évente: kereskedelmi UNIX-ok, AIX, HP-UX, Solaris
6% (44 szavazat)
kiadás ha kész, nem baj ha minden csomag x éves: Debian
14% (100 szavazat)
kiadás 6 havonta, ha kész ha nem: Ubuntu, Fedora, OpenSolaris, openSUSE
17% (120 szavazat)
kiadás 1,5 évente: Ubuntu LTS
12% (85 szavazat)
kvázi nincs kiadás, folyamatosan frissülnek a csomagok: Gentoo
30% (210 szavazat)
kiadás marketing szempontok alapján (nem baj ha nincs kész, majd lesz SP1): Windows 95, XP, Vista
0% (2 szavazat)
Egyéb, leírom a hozzászólásban
4% (30 szavazat)
Összes szavazat: 701

Hozzászólások

A kategorizálás szubjektív (flamebait), nem kell a példákat szó szerint venni vagy kiakadni rajtuk.
Vitaindításnak szánom -illetve bővítésre, pontosításra-, de nem arról, h melyik OS-t raktam jó vagy rossz kategóriába, azok csak példák. Pl. lehet a Windowsnál is 3-5 évente van release.

A kerdesben valoban nincs benne, hogy milyen felhasznalasi teruletre. Ahogy a korabbi hozzaszolasokbol is kiderult, egyaltalan nem mindegy, hogy server vagy desktop. En meg nem vagyok olyan regi motoros a Linuxban (kb 5 eve hasznalom desktop es serverfeladatokra) az informatikaban viszont igen, es en nem tudtam eldonteni, hogy melyik lenne a helyes. Tulajdonkeppen mindegyik mellett szol erv. Most Ubuntut hasznalok, meglepodve olvasom, mennyi problemaja van vele mindenkinek, sot van egyfajta ellenseges hangulat ebben a temaban, pedig nekem teljesen jol mukodik a laptopjaimon is, es a desktopjaimon is. (Nemreg meg egy '97es IBM laptopra is feltettem, es hibatlanul ment, vitte az osszes hardwaret is). Ahogy en latom, az LTSre nem fordit kiemelt figyelmet a Canonical, tulajdonkeppen egy release a sok kozul, amint tovabbleptek rola, pont ugy kezelik, mint mondjuk a 7.10et. De talan ez az LTS dolog nem is annyira rolunk szol, mint inkabb rolunk rendszergazdakrol. Ha 100 gepre 10 cegnel felteszel Ubuntut, akkor az LTS neked jo, mert kiismerheted a jellemzoit, hibait, mindent ami az uzemeltetessel jar, es homogen kornyezetet tarthatsz. A hibakra megismerheted a workaroundokat, azokkal felkeszulve mesz eleve a helyszinekre, es stabil mukodesi kornyezetet tudsz csinalni. (A Debian Stable se jobb ebben a tekintetben, arra is ra kell keszulni ugyanigy). A Gentoo koncepcioja ezesetben egy remalom lenne. Serverre valoban hosszutavu stabilitasra es kiforrottsagra torekszik az ember, kulonosen ha uzletileg epit ra. Ezen a teren sokat tett le a Canonical az asztalra ez teny, de a Red Hat messze jar ezen a teren ugy gondolom, igy serverre talan az a szerencsesebb. A jelenlegi 5.3 viszi mar az EXT4et, de a Red Hat 2 meg ugyanugy tamogatott, 7 eves kifutasi idokkel. Ez ugy gondolom valoban megfelelo, 7 ev utan tenyleg el kellhet gondolkodni a hardware es esetleg a software cserejen, mert azert a server szolgaltatasok is avulnak, megha lassan is, ugyanigy valtozik a servervilag is, bar nem muszaj bantani ha viszi amit kell. Belso intraneteken meg adott esetben a bizontsagi kerdesek sem kritikusak azonnal, mondjuk egy nyomtatoserverkent hasznalt gepen (pl).
Mivel a nyilt forrasu fejlesztes annyira sokszalon futo, itt kerdeses hogy mi lenne a jo megoldas. Ahogy en megfigyeltem, gyakorlatilag minden amit bevizsgaltak, az bekerul a repoba, ugyhogy kapjuk az ujat eleg hamar, ez lehet jo es rossz, ahogy neztem a hozzaszolasokat mindenki maskeppen eli ezt meg. Viszont a csomagok kulonbozo jelzokkel jonnek, van ami Canonical supported, van ami nem. Ez a stabilitast keresoknek fontos szempont lehet, leven amit uzletileg tamogatnak, arra nyilvan nagyobb az odafigyeles is.
Ugyanakkor az updatenel vannak valasztasi lehetosegeink. Aki a stabil kornyezetet keresi (ami nem feltetlen azonos a stabil mukodessel) annak csak security update. Aki frissebb csomagokat is szeretne, annak recommended update. Annak aki teljes uj verziokat is szeretne (ami elvileg a kovetkezo releaseben lesz elerheto) annak ott a backports. Aki meg aztan tenyleg bleeding edge, mas distrokbol is testinget nyom, annak ott a proposed. Szerintem ilyen szempontbol le van fedve az igeny.
A problemak inkabb a kulonbozo programok upstreamjeiben vannak (XOrg, OO, stb.) A hibak amiket sokan felsorolnak altalaban ezekben vannak, nem olyanban amit a distro keszitoje kellene hogy orvosoljon. Ilyenkor viszont talan szinten a frissebb verziok jelenthetnek stabilabb mukodest, bar sokszor meg pont az ellentete, ez leginkabb az adott software kerdese. Nem szabad szerintem elfelejteni, hogy az Ubuntu az distro, nem OS. A programok hibaiert nem lehet felelossegre vonni azt aki az ujabb verziot kozzeteszi, max csak azert, hogy ha nem eleg stabil, miert tette kozze. De a tobbtizezer csomag eseten lehetetlen elvaras, hogy minden intenziven tesztelve legyen. Erre van a Canonical supported.
Nekem ez a velemenyem roviden :)

Ubuntu LTS-fele kiadasi ciklus nekem szimpatikus, de nem 1,5 evente, hanem ketto. (6.06 ami eredetileg 6.04 lett volna csak picit csusztattak, utana 8.04). Nekem a felevenkenti release tul gyors es felesleges is. Ugyanakkor van Gentoom is, ahol nincs hagyomanyos ertelemben vett release cycle, jol megfer a ketto egymas mellett (mas celra).

Rolling release, azzal a kitétellel, hogy az alaprender maradjon visszafelé kompatibilis, és egy stabil platformot adjon.

"Ubuntu is an african word, meaning: 'I don't have enough money to buy a Mac'"

Kétféle.

Az egyik az Ubuntu féle, ügyfélnek azt telepítek.

A második pedig a Deian SID, azaz nincs kiadás csak a csomagok frissülnek. Ezt Gentoo néven lehetett szavazni.

Hasonló...

Saját gépre kiadás nélkül, folyamatosan frissülő Debian.

production gépre meg mindenképp (kész) kiadás alapú cucc. Mivel ezt ismerem, ez Debian stable. De lehetne más is. Kiadás sebessége nem lényeges, de csak kész dolgok legyenek benne. Ugyanakkor kereskedelmi szoftverek miatt jó lehet fix kiadási ciklus (mondjuk szerintem fél év ehhez rövid, legyen mondjuk év, másfél év)

Szóval mit is válasszak... :-)

G

Ez a FreeBSD kiadás 4 havonta ez honnan jön? A valóságban az utóbbi időben szerintem inkább 1 évente van release.

FreeBSD 7.0 2008.02
FreeBSD 7.1 2009.01

Szerintem a FreeBSD az amikor készen van elvet követi....

OpenSUSE-nak egyáltalán nem 6 havonta van kiadása, hanem 8-10 havonta és nincs mindenáron kiadási dátum, mint ubuntunál. Szerintem ez lenne a normális.

kiadás 1-3-5 évente: kereskedelmi UNIX-ok, AIX, HP-UX, Solaris

kiadás 1,5 évente: Ubuntu LTS

E két válasz nem fedi egymást? Az Ubuntu LTS két évenként jelenik meg, ami benne van az 1-3-5 éves intervallumban.

AIX miatt tettem csak az 1 évet, inkább 3-5 évente frissülnek a kereskedelmi UNIX-ok, ergo ez a 3-5 év kategória. Az Ubuntu LTS meg többek szerint 2 év, én nem néztem utána, még egy régi táblázatból emlékeztem 1,5 évre.

Mondjuk egy dolog a release meg még egy, hogy az meddig támogatott. Ez kereskedelmi cuccoknál jóval hosszabb.

Production rendszerben az ütemezett, előre tervezhető release-ek célszerűek, de nem túl sűrűn, hogy legyen idő az élesbe kirakás előtti alapvető tesztekre. A féléves kiadási ciklus, "nincs kész, kimarad" elvvel megfejelve szerintem vállalható. Az, hogy (kicsit sarkítva)senki sem tudja megmondani, hogy a tegnapihoz képest a holnapi rendszer miből mit fog tartalmazni, az production rendszernél totálisan elfogadhatatlan szerintem, pláne ha az ember az ITIL-re is gondol...

Szerver vagy desktop? Mert szerintem nem mindegy...

Desktop: rolling release (~Zenwalk)

Szerver: stabil kiadás, securty patchek azonnal, egyébként érintetlen rendszer, amit én frissítek ha valami bugosan működik. (Slackware)

kvázi nincs kiadás, folyamatosan frissülnek a csomagok: Gentoo
ez az egyetlen értelmes, nem?
---
"A legjobb dolgok az életben nem dolgok."

Mitől stabil a rendszer? Mi az, hogy stabil rendszer?

Én pl. jártam úgy Debian testinggel (production környezetben, azt gondolva, jó lesz, mert friss csomagok, és elég stabil), hogy konfigurációs fájl formátum változott, és egyszercsak jött a panasz, hogy nem megy valamelyik szolgáltatás.

Nekem ez nem vállalható be. (ez jó lecke volt, azóta nem is így csinálom).

Production szerveren semmi ne változzon, ha el tudja látni a feladatát, akkor nem érdekel, hogy van újabb verzió, vagy akármi.

security fixek felmennek. Ha valami olyan funkcióra van igény, ami pl. stabil Debianban nincs, de testingben már igen, akkor azt tesztelés után felteszem kézzel. De kb. 4 éve nem volt ilyen.

Amikor új release van, akkor jól kitesztelve frissítés.

G

Az üzletileg kritikus rendszerhez nem nyúlunk, nem telepítgetünk naponta -- a telepítendő cucc megy a tesztkörnyezetbe, majd ha ott megfelelt, megy a DSL-be, és onnan mehet az éles környezetbe, meghatározott forgatókönyv szerint. A Microsoft-os frissítéseket is tesztelik, éles környezetben azokat sem tolja ész nélkül fel az ember production rendszerekre.

Hint: rolling release disztronal nem is csinalunk automatikus udate-t, plusz senki nem kotelez frissitesre. Nyugodtan mehet a sandboxba teszteles, elesbe kirakas politika, mert egy-egy _stabil_ verzio altalaba nem csak 1-2 napot el, hogy menet kozbe eltunjon, es a sandbox teszteles sem szokott evekig huzodni. Persze ehhez mar erteni kell a dolgok mukodeset, nem lehet kezdokent ilyent production-be bevallalni, ez tiszta sor.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha nem teljesen olyan, akkor nem kaphatsz _teljesen olyan_ képet arról, hogy mi fog történni, ha a nem teljesen olyan rendszeredbe deploy-olod a témát. Maximum benned lesz a megnyugtató érzés, hogy "hát előtte leteszteltem". Az elmúlt héten 110 gépre telepítettem egy alkalmazáscsomagot. Ebből 90 munkaállomás volt, a többi szerver. Már 100 feletti sikeres telepítésénél jártam (hasonló konfigurációkon), amikor azt hittem, hogy már nem érhet meglepetés. Egy rendszernél - ami nem sokban különbözött az előzőektől - mégis ért. Hát ennyi.

--
trey @ gépház

Igen, erről beszélek. Nem meglepetés. Sőt arról, hogy képes ugyanaz a szoftvercsomag ugyanazon a virtuális gépen, ugyanarra snapshot-ra többször visszaállva (tehát hardver és szoftverkülönbség teljességgel kizárva) különbözőképpen viselkedni. :)

Persze ezzel nem azt mondom, hogy felesleges tesztelni egy tesztkörnyezetben ha már van ilyenre pénz, hanem azt, hogy azért ebben vagy egy jókora placebo hatás is. Leteszteljük, lemegy, kevésbé remegő kézzel nyúlunk az éles rendszerhez. De ez nem életbiztosítás.

--
trey @ gépház

Persze, ha többszintű változtatást okoz egy új verziójú csomag kreálása, majd aktivitásba kapcsolása, akkor ott vagy tervezési hiba van (ezzel e részről nem lehet mit kezdeni, max fikázni) vagy indolkolt egy új, átfogóbb frissítés(i ciklus) [melyet jelölhetnek akárhogyan is, ez már hitvita].
---
"A legjobb dolgok az életben nem dolgok."

A rolling release jobban tetszik számomra, viszont most se ilyen disztrót használok.

Frugalware-n fix kiadási ciklus van, de meg van oldva, hogy a kiadások megfelelően stabilak legyenek. Tehát az 1. pont illik rá leginkább szerintem.

Amikor kész (+windows esetén az legalább SP1) és inkább 2-5 éves intervallumban hosszabb támogatási ciklussal.

Új verzió lehet sűrűbben (mondjuk évetne max), de ne legyen kvázi rákényszerítve az ember arra, hogy folyamatosan frissítenie kelljen a rendszert, hogy lépést tudjon tartani. Desktopnál, szervernél is működőképes, de szervernél alapfeltétel, hogy ne kényszerítse az embert folyamatos frissítgetésre, hanem évekig rá lehessen bízni.

----------------
Lvl86 Troll

Nincs jelentősége... és szerintem rakás fejlesztői erőforrást elvisz a kiadási időre összerázni valamit, amit később (frissítések során) lecserélünk.

A legszimpatikusabb a "netinstall" "CD" kiadása időnkét, amikor a régi installáló már nem képes ellátni a feladatát. pl. új fájlrendszer (vagy egyéb ami miatt a régi "netinstall" felett eljárt az idő).
Úgyis legtöbben felteszünk egy kedvenc Linuxot disztrót, aztán megtömjük minden jóval. Mindegy az, hogy distró közeli vagy egyéb forrás (csak megbízható legyen), aztán jön frissítés, aztán az újabb kiadás, amit legtöbben csak frissítésként élünk meg.

Ahol ennek szerintem értelme van (mármint az ütemterv + kiadás) az a szerverkörnyezet.

Vagyis túl kis pont vagyok, hogy ebbe beleszólhassak. Így használom a "netinstall"-t oszt kész :-) .

Az Ubuntu is inkább az első kategória (fix kiadás 6 havonta, de egy szolgáltatás nincs kész, akkor az nem kerül be). Sokan háborognak is emiatt, hogy viszonylag új verziók nem kerülnek be az aktuális kiadásba. Az más kérdés, hogy a kész szolgáltatásokból is szoktak hiányosak illetve bugosak lenni. Ez a legutolsó verzió például (Intrepid) elég sokára tudta elérni az induláskor elvárható használhatóságot. És ez a friss csomagok hibája volt (pl. kernel, XOrg, ATI, NVidia driver, ...).

Nem szeretem ha túl régi csomagok vannak a rendszerben, de ennek ellenére a Red Hat és a CentOS kiadási ciklusai bejönnek nekem.

Desktopra rolling release (nálam Arch), szerverre stabil legyen és agyontesztelt, nem baj, ha régi (Debian).

A szavazás olyan szempontból nem egyértelmű, hogy mire a legszimpatikusabb?
Szerverre stabil debiant szoktam tenni és valóban kevésbé érdekel, hogy nem a legfrissebb a csomag fontosabb a stabilitás és a biztonság.
Desktopon sid-et használok, ami - mint írták - "gentoosan" frissül.

üdv: pomm

A "kiadás ha kész" és a "kiadás 2 évente" (hibásan 1,5-nek feltűntetve) közt van az arany középút szerintem: egy hosszú fejlesztési ciklus, amit kritikus bugok esetén késleltethetnek bizonyos időkeretig.

Ugyanis sajnos Ubuntu LTS-nél is érdemes megvárni az "SP1"-et, kiadáskor kivétel nélkül bughalmaz mindegyik úgynevezett "release" változatuk.

Nekem Ubuntunál nem tetszik ez a 6 hónapos kiadásos műszak. Ubuntuék elkezdik fejleszteni, már egyre szűkösebb az határidő, gyorsan csapjunk össze valamit...
Ok, olyan amilyen. Majd felrakjuk a frissítéseket.
Egy User egy szép napon elhatározza, hogy frissíti Ubuntuját, vagy éppen áttér Linuxra és feltelepíti/frissíti a Linuxát.
Jön egy probléma, pl összeomlik az X, bármi.
A lelkes User pedig vagy disztribúciót vált, vagy letölri a Linuxot, és elmondja mindenkinek, hogy a Linux az szar és visszatér a régi rendszerébe, bármi olyan dolog, ami negatív. Azért, mert egy még bugos rendszert adtak ki. Ha a Usernek szerencséje van, és minden hiba nélkül működik (mint pl. nekem), akkor vígan használja a rendszerét.
Ezért én szoktam várni kb. egy hónapot, hogy hagy forrjon még az ubuntu, majd utánna frissítek. De a legjobb az lene, hogy másfél évente adnák ki az új Ubuntukat, addig a csomaglistákat frissítenék. Majdcsak mint Debiannál. Egyszer majdnem Debiant raktam fel egy Ubuntu 8.10-es kaland után.

Nem látok sok összefüggést a mennyi időnként van kiadás és mikor frissítünk az újra elvei között. Akár 6 havonta, akár 6 évente van új kiadás, ésszerűen előbb tesztelünk, aztán használjuk. Nyilván 6 havonta történő kiadás esetén nem érdemes 12 hónapot tesztelni frissítés előtt (egyébként sem) :-)

--
Slapic
http://slapic.hu

Mekkora troll csúsztatás !

A Debian irányelve szerint 18-24 havonta adja ki az LTS univerzális kiadást.

(hard freeze kb. 3 hónappal előtte, ennyire 'elavult minden csomag')

Szervác Attila - http://321.hu/sas

A három hónap nem igazán számít szerintem, de a ~24 hónap (az új verzió megjelenéséig) sokat számíthat ("elavulási" szempontból).

Alap etch-n pl. Lenny megjelenése előtt sokminden nem futott a régi libek miatt.
Persze egy szerveren, ahol minden megfelelően be van állítva és jól működik, ez nem különösebben probléma...

Ha valaki, aki Debian szervert üzemeltet és belegondol, hogy nem tudja mikor fogja tudni az adott szoftver verzióját lecserélni újabbra (pl. új, előre nem látható igény), akkor láthatja, hogy ez a "kiadjuk, ha stabil" nem egy tartható, tervezhető stratégia. Én még nem találkoztam olyan Debian szerverrel, ahol ne lett volna valamilyen külső (nem Debian által fenntartott vagy nem az eredeti kiadásban szereplő verziókat tartalmazó) forrás. Innentől nem beszélhetünk igazából stabilitásról, mert nem azzal a verzióval lett összecsiszolva a rendszer. Az is igaz, hogy nagyon sok olyan szoftver van, amit horror stabillá tenni, hiába van hivatalosan stabilként kiadva (xorg, ext4 driver kernelben).

Hmm... Nem vezettelek még egyszer körbe a szerverszobánkban? Ott láttál volna egy rackre való ilyen Debian szervert! ;-)
Csak gyári debian apt source. Megy minden, ahogy kell neki. Semmi extra repo. Időnként a sajátjaim max. Abban meg olyan csomagok vannak, amiket én fejlesztek a gépek üzemeltetéséhez, és azért van repoban, hogy egy laza apt-gettel a saját cuccaim feltehessem.

A biztonsági hibákat hamar javítják, ezenkívül egy jól működő postfix-en, apache-on, mysql-on, dovecoton, stb. mit frissítsek? (Előre nem látható igény? - szalonnázni akarunk a tetején? :) ). Egy-két ficsörért kockáztatni a biztonságot, nem biztos, hogy okos döntés. Persze ezt szervere és üzemeltetője/rendszergazdája válogatja.

üdv: pomm

Mostanában már csak 3-at, de régebben többet üzemeltettem.

Nem volt külső forrásból telepített cucc a szervereken.

Most sincs. Bár egy djbdns-en gondolkoztam (mondjuk ahhoz is megvan a debian telepítőcsomag, ami letölti, fordítja, elkészíti helyben, szóval akár azt is mondhatnám, hogy az se külső)

Desktopomon van külső program. De szerverre nem teszek akármit.

G

Slackware-t a szavazási listában nem tudom sehova tenni...úgyhogy egyéb. :-)

--------------------
Tegnap beállított hozzám egy Tyrannosaurus Rex és Hamlet. Volt nagy dinóm, dánom...

Base OS: when its done (1-1.5 ev)
Csomagok: negyedevenkenti stabil kiadas

:p

--
When in doubt, use brute force.

Kiadás 6 havonta: Fedora
DE, általában minden 2. verziót frissitem csak.
Tehát egy évente kiadásnak jobban örülnék. Túl gyors a 6 havonta kiadás. Az XP-m alatt ennyi idő alatt szinte semmi nem történt. Még egy SP-t sem adtak ki, kb...

Szinten Fedora-t hasznalok desktop-ra, de az 'Egyeb' kategoriat jeloltem meg. Amennyire vartam az igeretesenek tuno 10-et (most a 11-et), annyira nagyot bukott nalam. Maradtam a 8-nal. Ha valamire szuksegem van, amit alapbol nem tud, az porog forrasbol.
Szerverre szinten ez a vonal jott be CentOS neven. Ami lehet repo-bol telepul, a tobbi szinten forrasbol.

---
Egy jol feltett kerdes mar egy fel valasz... Link

Stabil linux verziókat használok, és addíg használom (apróbb szükséges frissítésekkel)
amíg megfelel az adott feladatokra.
(Jelenleg pl. 2.16.13.xx lkm kernel alapon suse 10.1,
de a telepített cucc annyira testreszabott, hogy szinte már saját disztro.
Ha kőművesmester lennék, azt mondanám, hogy a betont és a téglát a SuSE szállítja,
a többi a két kezem munkája :)
Amikor már nem megoldható vele valami, akkor váltok következő stable release-re.
-
"Attempting to crack SpeedLock can damage your sanity"

Verjetek meg érte, ha gondoljátok, de én többek közt a csomagolási rendszer miatt váltottam OS X-re:

Kiadás 2-3 évente, de ma is fut párduccal a legtöbb program (release date: 2003), én tök jól elvagyok a tigerrel (2005), bár sokan mondják, hogy ideje lenne átállni leopardra, ugyanakkor 2-3 appon kívül ezen is fut minden....

Nem hiszek abban, hogy az OS részének kell lenni a csomagoknak. Azt gondolom, az OS-nek egy stabil binárisan kompatibilis alapot kell adnia, amire tud számítani a csomag - olyannyira, hogy ha nem kellenek neki új szolgáltatások, elfut régebbi OS verziókkal is, ill. az új OS verziók (akár opcionálisan) tartalmazzák a régi rendszereit. Ily módon a csomagolás terhe a program szerzőjére / rajongói körére marad, egy sokkal elosztottabb "ökonómiát" (felépítést) teremtve.

Persze ehhez a linuxon radikális változtatásokra lenne szükség. És persze, fontos, hogy legyen security update (tigerre még most is jön).

(Ja, és nem, a helyet nem a régi libek foglalják el igazán, hanem a .flac meg .avi kiterjesztésű dolgok... :)

"kiadás 6 havonta, ha kész ha nem", ezt jelöltem, mert legtöbbet a desktop gépemet nyúzom, és szeretem, ha frissek a programjaim, és a fellépő hibák aránya annyira kicsi, hogy nem foglalkozom vele. Szerveren kettős érzéseim vannak: az egyik, hogy legyen stabil, a másik viszont, hogy nem szeretem, mikor kiderül, hogy valami azért nem megy, mert a szerveren lévő lib régi, és ami a dev gépemen megy, az a szerveren nem. Egyébként minden frissítési filozófiának meg van a hátulütője, talán szoftware szempontjából a "kvázi nincs kiadás, folyamatosan frissülnek a csomagok" a legjobb, de ez meg nem a rendszergazdák álma.

igazából nekem egyik sem. Ubuntu LTS-t jelöltem, de szívem szerint egy olyan ubuntut használnék, ami évente jön ki, kevesebb buggal és több új feature-el mint ahogy egy féléves szokott.
Attól azért nem kell ugyanis hasraesni hogy a Nautilusban vannak tabok és hasonlók, szóval ez nem feature.

Lehet hogy csinálnék egy experimental tárolót az ubuntuhoz, és aki bevállalja az használja, aki nem az nem. Így kevesebb bug lenne a stabil verziókban, mert jön bugreport mielőtt beteszik az újba, de ha nem megy az nem presztizsveszteség. ill kritikus helyen azt nem használod...

-----------------------------
Ubuntu 8.10

AIX: jelenleg (2-3 eve) az a gyakorlat, hogy egy evben 2 TL-t (technology level) ad ki az IBM, a tavaszi bugfixek gyujtemenye, az osziben pedig egy csomo uj feature van. Kozben pedig service pack-ekben adjak ki a security fixeket. Igy pl egy 5.3 TL9 tavolrol sem emlekeztet a 'TL0-'ra.

A Gentoo-fele 'nincs kiadas'-ra szavaztam, mert evek ota Frugalware -current-et hasznalok gond nelkul, nagyobb problemam soha nem volt.

Ugyan Gentoo-t jeloltem, es igy is gondolom, azonban nem lenne rossz a Debian szeru kiadasi politika sem, ha tarsulna azzal, hogy lehetoseg lenne a rendszer nagyobb bolygatasa nelkul barmibol frisebbet feltenni, mint amit az aktualis rendszer kinal, mert barmikor eloadodhat olyan, hogy adott program ujabb verziojara lenne szukseg, mert kell egy funkcionalitas, amit a felevvel azelotti verzio nem tud. Es a backports repok sem mindig a legfrissebbek/legteljesebbek az ilyen tipusu disztroknal.

Persze, lehet forrasbol feltenni mindent mindenhova, de az nem az egyszeru ut kategoria.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Desktopra én ilyenkor gond nélkül felteszem a szükséges csomagokat testingből (ha elérhető), vagy unstable-ből (, ha csak ott van).

Persze magával hoz pár libet, stb. ezután nem bolygatom, jellemzően ezek a csomagok nem frissülnek maguktól (ez nem biztos, hogy ideális így).

Ennél jobb (és Desktopon mostanában ezt használom), a testing. Időnként, ha kell, unstable csomagokkal, amik aztán testingbe szivárgás után már frissülnek is.

egyéb:

... nyilván a rendszer milyenségétől függ, hogy melyik a legjobb megoldás.

:: by BRI.
:: config :: Acer TravelMate // Ubuntu Intrepid
:: tothab [a] gmail [pötty] kom
:: black rose immortal's weblog

Én megkérdezném a hozzászólókat, hány szervert tartanak karban. Lényeges információ lenne szerintem. Nem mind1, hogy 1 vagy 50. Egy szervernél a Gentoo is tök jó, 50-nél kicsit sok vele a munka.

Nagy számú szerver karbantartásánál bizony jó a lassú kiadás. Simán előfordul, hogy az új Debian kiadás után 6 hónappal még számos szerver az előzőt futtatja és ez jól is van így. Ahol feltétel a 99,9% vagy magasabb rendelkezésre állás, nem lehet ész nélkül frissítgetni. És a 6 hónap igen kevés lenne.
Ahol valami újabb kell, és nincs a már korosodó Debianban, ott ésszel lehet backports.org-ról feltenni csomagokat (ha a régebbi tényleg nem jó). Ez egy köztes út a tapasztalatom szerint a sűrű frissítés és a Debian illetve Ubuntu LTS féle stabilitás között.

Desktopon teljesen jó a 6 havi kiadás és az Ubuntu.

Érdekes kérdés lenne az is, ki hogyan frissíti a rendszerét... majd felteszem :-)

--
Slapic
http://slapic.hu

Kell hozzá saját build rendszer, saját bináris repó -- a tesztkörnyezeteken felül. Ez egy, de inkább két plusz rendszer. A saját build, bár hordozhat minimális performancia-növekedést, a hibakeresésben gondot okozhat, ha saját paraméterekkel történt a build -- teljesen egyedivé válhat a rendszer, ergo nem biztos, hogy a felmerülő probléma másoknál is elő fog kerülni.

Az, hogy mi kell hozza azt ne firtassukm vegtelen lehetoseged van, lehet 0, lehet sokkal tobb plusz rendszer.
Nyilvan teljesen egyedi lesz a rendszer, talan ezert is kerulhetett egy gentoo szeru rendszer kivalasztasara. Nagyon sokan hasznalnak nagyon fura modon opensource dolgokat. Megeshet, hogy egeszen mas OS-en es arhitekturan fogsz hasonlo hibajelensegrol olvasni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

HA forrásban jön a frissítés, akkor neked kell buildelni, majd disztributálni az n+1 darab szerverre. (Nem, nem rakunk mindenhova teljes fordítási környezetet; egy éles szerveren baromira nincs semmi keresnivalója ilyesminek!) Ez igényel minimum egy build környezetet, egy repót, ahova a saját csomagokat leraktad.

Linuxon hibakeresésnél eddig is disztrib, caomag- és kernel verzió, libc, ilbakármi verziók, ésatöbbi kellett az egyértelmű beazonosításhoz. Most még hozzá jönnek a fordítási beállítások is...

Valahol minden bizonyal lefordul es valahol minden bizonyal lesz egy csomag, de ehhez nem kell feltetlen plusz gep.

Distro es csomag is csak a forditasi beallitasok megtudasa miatt lehet erdekes.
Distro erdekes lehet, ha user elkurt valmit a konfig fileokban, de minket ez most nem erdekel.

Kernel verzio, libc szinte teljesen indifferens (futas idoben) a csomag hibak szempontjabol.

"(Nem, nem rakunk mindenhova teljes fordítási környezetet; egy éles szerveren baromira nincs semmi keresnivalója ilyesminek!)"
Nem bant az senkit. Ha azt hiszed, hogy gcc/ld/as komoly veszely forras, akkor tevedsz.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ezek alkalmazások, ha a szolgáltatás működéséhez kapcsolódnak, ahhoz szükségesek, akkor vannak, ha nem, akkor nincsenek. A gcc, ldd, libfoo-dev viszont sem nem szükséges, sem nem kapcsolódik a tényleges szolgáltatáshoz. Mint ahogy a defaultban felmászó pcmcia-cs, ppp és hasonló vackok.

gcc is egy alkalmazas.

Valahogy szinte mindig felkerul valami a gepekre valamilyen oknal fogva amivel lehet uj filet bejutattni userkent.
C filebol binarist eloallito program nem nevezheto alapbol veszejes elemnek. C filet nem konyebb bejutatni, mint binarist.

Ha ultra nagy security-re torekednek biztos nem gcc lepucolasaval kezdenek. Es nem bizonyos programok nem letere epitenek, hanem inkabb arra torkednek, hogy webserverbol ne lehessen barmit meghivni mondjuk. Idegen binarisokat ne lehessen futatni ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

kiadás 1-3-5 évente: kereskedelmi UNIX-ok, AIX, HP-UX, Solaris

Nincs szerverem, de tudok gondolkodni.

"kiadás ha kész, nem baj ha minden csomag x éves: Debian"

Eddig ennél stabilabb terméket produkáló kiadási módszert nem láttam. Persze mindenkinek más a fontos.
Másik előny a ritka kiadásoknál, hogy nem kell frissíteni olyan gyakran, és a disztribúció által nem szállított szoftverek összeszedése is kevesebb gonddal jár.

--
Kum G.
www.kumgabor.hu

Írták néhányan, de szerintem sokkal fontosabb az időszakoknál, hogy az adott rendszer visszafelé is kompatibilis legyen és hosszútávon támogassák. Ahogy látom a gyakori kiadású disztribúciók nem foglalkoznak a visszafelé kompatibilitással:
Ubuntu, Fedora, stb...: az összes program újrafordításra kerül az új rendszer alatt, így többségében elérhető a legtöbb program az új rendszerhez tartozó telepítő csomag formájában. A baj csak akkor van, ha az ember "3rd Party" drivert, programot (esetleg nem is nyílt forrású) használ, aminek a kiadása nem ilyen gyakori vagy nem a kiadáshoz időzített (pl.: DELL, HP, nVidia, ATI driverek, vagy egyéb üzleti szoftverek).
Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"

Azért az elég szomorú, hogy 5-10 éves windows programokat a wine-on keresztül vidáman futtatok, ugyanilyen idős linux binárisok viszont el sem indulnak mindenféle libc vagy akármi függőségek miatt, esetleg a bináris formátuma se stimmel. (próbáljunk egy Mosaic-ot vagy egy Netscape Navigátort Goldot feltenni Ubuntu 8.akármire...)

Szánja meg őket valaki egy vokssal: "kiadás marketing szempontok alapján (nem baj ha nincs kész, majd lesz SP1): Windows 95, XP, Vista"

Kiadás 6-10 havonta, ha a kitűzött funkciók elkészülnek és a célok megvalósulnak: openSuSE

Amúgy szerintem nem volt jó ötlet mellé írni a disztrók nevét, mert több válaszban is érzek ellentmondást. pl az openSuSE Egyáltalán nem hónapra megy, hanem kitűznek egy funkciólistát, és ha azok elkészülnek, akkor készül el az új verzió. Ubuntu-nál meg ragaszkodnak a 6 hónaphoz, ha törik, ha szakad. Szóval ezt szerintem nem kéne összemosni.

Kiadás akkor, ha szükség van rá. Nekem érdekesebb, hogy a csomagok frissüljenek a kiadásokkal párhuzamosan. Nem kell vérző él módon, de azért ne legyen többszörösen meghaladott verziószám, ha lehetséges.
--
Fight / For The Freedom / Fighting With Steel

"kvázi nincs kiadás, folyamatosan frissülnek a csomagok: Gentoo"
Az Arch is hasonlóan tesz. Számomra ez a legkényelmesebb. :)

Ez gyakorlatilag egyenértékű, a ki mit használ kérdéssel :)

Ubuntu kiadási ciklusa tetszik, de azért 1-2 dolgog lehetne másképp

Sima kiadás: 1 évenete, indokolt esetben (pl főbb módosulás esetén.. pl gnome 3.0 stb) 1 éves cikluson belül bármikor amikor elfogadhatóan stabil. A számozásnak pedig inkább egy backports kiadásnak kellene lennie (aki szeretné frissít rá opcionálisan megteheti, aki nem nem) frissítés pedig LTS ciklusonként. Így aki minél frissebbet használ használhat, mégis stabil... de a biztonsági frissítésre inkább az LTS-re koncentrálnak jobban

LTS kiadás: 3 évente és legalább 2 ciklus támogatás Desktopon és 3 ciklus szerveren.

Saját tapasztalatok alapján szerveren ahol vannak saját alkalmazások sokszor macerásabb egy frissítés mint a verzió követés. Új szervereket általában az újabb verzióval telepítek... de van ahol még Dapper fut... és hamarosan azt már senki sem támogatja biztonságilag. Az alkalmazásra amire telepítve lett teljesen jó a Dapper is még mindig... frissítést meg ügye nem éles rendszeren kellene kipróbálni... tesztrendszerre meg nem mindig van idő... energia

Az Ubuntu LTS 2 éves ciklusa szerintem megfelelő, mivel két év alatt igen nagyot változik az software-es világ is. Addig meg marad a régebbi verzió, ami stabil, és legalább az új kiadásig támogatott. Nekem megéri így frissítani, mert ilyen időközökben már kiforranak a fejlesztések, és elég sok, kritikus hibát is tudnak javítani ennyi idő alatt.

van úgy, hogy nincs szükség új funkcióra, egyszerűen csak menjen és legyen security update..

Pl mezei statikus html oldal kiszolgálásra egy pl Debian Woody + apache 1.x ... tökéletesen megfelelő. Csak a security updatet kellene feltenni...

Sokszor fárasztó azzal foglalkozni hogy x évente frissíteni újabb és újabb verzióra... mert nincs már secupdate ahhoz a verzióhoz...

üdv:
Csabka

ui: nem azt mondom hogy ne legyen fejlődés.... legyen az is... csak legyen néhány olyan ág, ami a hosszútávú használatot és biztonságot teszi szeme elé.... és nem az újat és újat és újat hajkurássza

A kerdesben valoban nincs benne, hogy milyen felhasznalasi teruletre. Ahogy a korabbi hozzaszolasokbol is kiderult, egyaltalan nem mindegy, hogy server vagy desktop. En meg nem vagyok olyan regi motoros a Linuxban (kb 5 eve hasznalom desktop es serverfeladatokra) az informatikaban viszont igen, es en nem tudtam eldonteni, hogy melyik lenne a helyes. Tulajdonkeppen mindegyik mellett szol erv. Most Ubuntut hasznalok, meglepodve olvasom, mennyi problemaja van vele mindenkinek, sot van egyfajta ellenseges hangulat ebben a temaban, pedig nekem teljesen jol mukodik a laptopjaimon is, es a desktopjaimon is. (Nemreg meg egy '97es IBM laptopra is feltettem, es hibatlanul ment, vitte az osszes hardwaret is). Ahogy en latom, az LTSre nem fordit kiemelt figyelmet a Canonical, tulajdonkeppen egy release a sok kozul, amint tovabbleptek rola, pont ugy kezelik, mint mondjuk a 7.10et. De talan ez az LTS dolog nem is annyira roluk szol, mint inkabb rolunk rendszergazdakrol. Ha 100 gepre 10 cegnel felteszel Ubuntut, akkor az LTS neked jo, mert kiismerheted a jellemzoit, hibait, mindent ami az uzemeltetessel jar, es homogen kornyezetet tarthatsz. A hibakra megismerheted a workaroundokat, azokkal felkeszulve mesz eleve a helyszinekre, es stabil mukodesi kornyezetet tudsz csinalni. (A Debian Stable se jobb ebben a tekintetben, arra is ra kell keszulni ugyanigy). A Gentoo koncepcioja ezesetben egy remalom lenne. Serverre valoban hosszutavu stabilitasra es kiforrottsagra torekszik az ember, kulonosen ha uzletileg epit ra. Bar ezen a teren sokat tett le a Canonical az asztalra ez teny, de a Red Hat elorebb jar ugy gondolom, igy serverre talan az a szerencsesebb. A jelenlegi 5.3 viszi mar az EXT4et, de a Red Hat 2 meg ugyanugy tamogatott, 7 eves kifutasi idokkel. Ez ugy gondolom valoban megfelelo, 7 ev utan tenyleg el kellhet gondolkodni a hardware es esetleg a software cserejen, mert azert a server szolgaltatasok is avulnak, megha lassan is, ugyanigy valtozik a servervilag is, bar nem muszaj bantani ha viszi amit kell. Belso intraneteken meg adott esetben a bizontsagi kerdesek sem kritikusak azonnal, mondjuk egy nyomtatoserverkent hasznalt gepen (pl).
Desktop eseten teljesen masak a prioritasok. Mivel a nyilt forrasu fejlesztes annyira sokszalon futo, itt kerdeses hogy mi lenne a jo megoldas. Ahogy en megfigyeltem, gyakorlatilag minden amit bevizsgaltak, az bekerul a repoba, ugyhogy kapjuk az ujat eleg hamar, ez lehet jo es rossz, ahogy neztem a hozzaszolasokat mindenki maskeppen eli ezt meg. Viszont a csomagok kulonbozo jelzokkel jonnek, van ami Canonical supported, van ami nem. Ez a stabilitast keresoknek fontos szempont lehet, leven amit uzletileg tamogatnak, arra nyilvan nagyobb az odafigyeles is.
Ugyanakkor az updatenel vannak valasztasi lehetosegeink. Aki a stabil kornyezetet keresi (ami nem feltetlen azonos a stabil mukodessel) annak csak security update. Aki frissebb csomagokat is szeretne, annak recommended update. Annak aki teljes uj verziokat is szeretne (ami elvileg a kovetkezo releaseben lesz elerheto) annak ott a backports. Aki meg aztan tenyleg bleeding edge, mas distrokbol is testinget nyom, annak ott a proposed. Szerintem ilyen szempontbol le van fedve az igeny.
A problemak inkabb a kulonbozo programok upstreamjeiben vannak (XOrg, OO, stb.) A hibak amiket sokan felsorolnak altalaban ezekben vannak, nem olyanban amit a distro keszitoje kellene hogy orvosoljon. Ilyenkor viszont talan szinten a frissebb verziok jelenthetnek stabilabb mukodest, bar sokszor meg pont az ellentete, ez leginkabb az adott software kerdese. Nem szabad szerintem elfelejteni, hogy az Ubuntu az distro, nem OS. A programok hibaiert nem lehet felelossegre vonni azt aki az ujabb verziot kozzeteszi, max csak azert, hogy ha nem eleg stabil, miert tette kozze. De a tobbtizezer csomag eseten lehetetlen elvaras, hogy minden intenziven tesztelve legyen. Erre van a Canonical supported.
Nekem ez a velemenyem roviden :)

(Az elobb a forum elejere ment a hozzaszolasom veletlen :) )

>A kerdesben valoban nincs benne, hogy milyen felhasznalasi teruletre.

Valóban:) De le is írták többen, hogy mire gondolnak ilyen-olyan felhasználási területen.

Egyébként az OS-eket csak példának használtam (ámde becsúsztak az alkalmazások is "kvázi nincs kiadás, folyamatosan frissülnek a csomagok: Gentoo", mondjuk Linux alatt a kernel is egy csomag), mivel engem egy alkalmazás inspirált eredetileg. Persze érdekes kérdés, hogy mi lett volna, ha példának CorelDraw-t, MPlayer-t vagy DB2-t írok (ekkor is hasonló kategóriák lennének: amikorkész, 3 évente, évente, adjukkihajóhanem).

Persze, alkalmazasszinten mas a kerdes jellege, es ott nem kerdes a felhasznalas terulete, hiszen az adott. De valamilyen szinten ott is ha az ember rendszergazda, akkor kell valamilyen supportalhatosag, es stabilitas, nem szerencses, ha barmelyik nap johetnek a patchek, valtoznak a dolgok. Tetelezzuk fel, ha az Office 2007 egy patch formajaban egyik reggel felmenne a ceg osszes munkaallomasara a 2003 helyett. Azt hiszem rendesen megborulna a ceg elete :) Tekintve a gyokeresen mas user interfacet. De ezen a teruleten talan nem is a kiadasok ideje az ami szamit, inkabb azok tartalma. Az Ubuntu backporting filozofiaja epul erre ha jol emlekszem, hogy ha az ki van kapcsolva, akkor az alaklmazasokhoz csak hibajavitasok jonnek, funkcionalitasbeli valtozast nem enged, mig ha a backport be van, akkor az OpenOffice2 updatelhet OpenOffice3ra is akar az egyik reggel. Bocs a sok Ubuntus peldaert, de mivel azt hasznalom most, igy a legegyszerubb :)

Debianban regi csomagok vannak, de megbizhatoak. Ido kell, hogy az apro hibak kideruljenek. Amig nincsen szukseg ujabb verziora a featurek miatt, addig legjobb valasztas az ilyen megoldas.

Kiadás, ha kész-re szavaztam, de hiányzik a Debian mellől az UHU! Én azt használom, az is ilyesmi...

Kodmen
-------------------
...a Linux filozófiája: "Keresd a veszélyt". Hopp! Nem így van. "Csináld magad!" Ez az! (Linus Torvalds)