- A hozzászóláshoz be kell jelentkezni
- 6627 megtekintés
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 hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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'"
- A hozzászóláshoz be kell jelentkezni
+1. (Amugy rolling-rock)..
- A hozzászóláshoz be kell jelentkezni
"When all is one and one is all
To be a rock and not to roll."
Led Zeppelin: Stairway to Heaven
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni
Ezt megkérdeztem én is a szavazás beküldőjétől. Ezt a linket adta.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1, szerintem a tervezett fejlesztésekhez igazított 8-10 hónap jobb. (Amúgy openSUSE változó, van, amiikor 6 hónap.)
- A hozzászóláshoz be kell jelentkezni
Maradjunk annyiba, hogy a milestone-okba félévente, kb. ez a tervezett, +/- pár nap belefér. Jelentősen csak akkor térnek el tőle, ha valami súlyos nem várt hiba/bug van. :)
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Kb. Hasonlóképp gondolom én is (a nem mindegy részét :-D), csak apró eltérés:
Desktop: fél évente frissül (Ubuntu)
Szerver: kiadjuk ha kész van (Debian)
- A hozzászóláshoz be kell jelentkezni
kvázi nincs kiadás, folyamatosan frissülnek a csomagok: Gentoo
ez az egyetlen értelmes, nem?
---
"A legjobb dolgok az életben nem dolgok."
- A hozzászóláshoz be kell jelentkezni
Ha éles rendszered van, nem. Ha tesztelni akarsz, akkor sem. Éles, üzletileg kritikus környezetben eszembe nem jutna ilyesmi.
- A hozzászóláshoz be kell jelentkezni
Te most egy újabb absztrakciós rétegről beszélsz. Stabil vagy nem. Én triviálisan a stabilra asszociáltam.
---
"A legjobb dolgok az életben nem dolgok."
- A hozzászóláshoz be kell jelentkezni
A stabil rendszer nem 0-1 napig stabil, nem napi rendszerességgel jön (vagy nem) frissítés hozzá. Normális esetben nincs automatikus frissítés, van viszont meghatározott időközönként szervízidőszak, amikor lehet matatni, és a tesztelt javításokat telepíteni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
En desktopnak Debian Testing/Experimentalt hasznalok, szervernek viszont kizarolag stable-t, security updatek termeszetesen felmennek ra.
-----
“Firefox, you say? No I don't play Pokémon”
- A hozzászóláshoz be kell jelentkezni
Ezért van külön stable és testing ág a rolling release disztribuciókban (is).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Tehát csinálsz saját bináris repó tokkal-vonóval, build rendszerrel...
- A hozzászóláshoz be kell jelentkezni
Kivéve, amikor az agyontesztelt frissítés lerohasztja a szervereket, volt már rá példa nem is egyszer.
- A hozzászóláshoz be kell jelentkezni
Ezért van az, hogy a hivatalos javítás _sem_ egyből a production környezetbe megy jobb helyen, hanem egy tesztrendszerre, és némi izzasztás után kerül ki élesbe. Ilyen szempontból mindegy, hogy az adott szoftvert ki fejlesztette.
- A hozzászóláshoz be kell jelentkezni
Boldog ember az, akinek van egy az egyben másolata a komplett éles hálózatáról ugyanolyan paraméterekkel...
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem kell a teljes hálózatról, valamennyi eszközről -- megfelelő tesztkörnyezet kialakítható ennél jóval egyszerűbben -- a lényeg, hogy az üzletileg kritikus funkciók tesztelése legyen megoldott.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Meglepetés? Van egy nagy és igen drága vállalatirányítási rendszer. Ha háromszor telepíted teljesen ugyanabba a környezetbe, teljesen ugyanazokkal a paraméterekkel és lépésekkel, akkor is képes három különböző helyen három különböző hibát produkálni...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+1 (Desktopra)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Lehet meg koveznek, de van egyetlen ertelmes disztro a Gentoo-n kivul?:D:D:D
- A hozzászóláshoz be kell jelentkezni
Arch
"Ubuntu is an african word, meaning: 'I don't have enough money to buy a Mac'"
- A hozzászóláshoz be kell jelentkezni
+1
Lehet megköveznek, de van az Archon kívül 'rendes' distro? :)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Persze hogy van, Slackware :-)
--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Éljünk "veszélyesen": Frugalware current :D
- A hozzászóláshoz be kell jelentkezni
Gondoltam már rá. Csak azt nem tudom, hogy mennyire unstable. Azt se szeretném, ha túl gyakran kellene reszelni rajta, akkor már inkább stable. :)
- A hozzászóláshoz be kell jelentkezni
Csak akkor ajánlott, ha tudod mit csinálsz és tényleg szükséged van rá. Amúgy meg mostanában egyre ritkábban kerül bele mindent borító frissítés, mert ezeket egy-egy külön repoban készítjük és egyszerre kerül bele a frissítés a current ágba.
- A hozzászóláshoz be kell jelentkezni
Na akkor marad a stable. Majd ha valami miatt kell csinálnom egy friss telepítést (vinyóhalál, vagy ilyesmi), akkor lehet, hogy current kerül telepítésre.
- A hozzászóláshoz be kell jelentkezni
> Tehát az 1. pont illik rá leginkább szerintem.
en is igy gondoltam, azert is szavaztam az elso pontra. :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 :-) .
- A hozzászóláshoz be kell jelentkezni
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, ...).
- A hozzászóláshoz be kell jelentkezni
+ Via (openchrome) driver...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Desktopra rolling release (nálam Arch), szerverre stabil legyen és agyontesztelt, nem baj, ha régi (Debian).
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
kétszer ment el
- A hozzászóláshoz be kell jelentkezni
Jó neki!
- A hozzászóláshoz be kell jelentkezni
félrenyeltem a kávémat, köszi :D:D:D
- A hozzászóláshoz be kell jelentkezni
LOL :-D
- A hozzászóláshoz be kell jelentkezni
irigykedjek vagy ne ? oO
--
Sony Vaio &
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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')
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
elismétlem: a stratégia 18-24 hónap, rengeteg csak stabil csomagot tartalmazó Debian szerver van.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
asztalra tökéletesen jó a testing, szerverre meg a stable, ha nagyon szeretnéd ott a backports.org
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
Kiadás ha kész, de minden csomag -közel- friss: Slackware 8)
Ha ismered a Slackware-t, ismered a Linuxot.
- A hozzászóláshoz be kell jelentkezni
Base OS: when its done (1-1.5 ev)
Csomagok: negyedevenkenti stabil kiadas
:p
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
Ugyan rolling-release linuxot használok
de mégis ez a legszimpatikusabb.
- A hozzászóláshoz be kell jelentkezni
esetleg ha valakinek tetszene ez a fajta riliz modszer, akkor probaljon ki egy NetBSD 5.0RC2-t :-)
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
Majd a release-t!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+1 az évenkénti fedorára. A két desktop gépemen féléves csúszással frissítek, így mindig használom mindkét támogatott verziót.
Csaba
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
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... :)
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+1
vagy inkább kétévente lts (ahogy most), köztes évben meg egy folyton frissülős verzió bevállalósoknak.
Hiába van most is lts, ha kb semmivel se jut több idő a fejlesztésre, mint a nem lts-eknél.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
+1.
- A hozzászóláshoz be kell jelentkezni
Ha van test kornyeztes es tudsz scipteket irni, akkor eszrevehetelen a plusz munka a buildelessel.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Arról nem beszélve hogy nagy gépparknál sok féle rendszer fordul elő, nálunk pl a p3 astól 4 magos xeonig minden szinte. Szóval kéne bár build rendszer is, meg mindre külön buildelni. Ennyit nem ér.
Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.28.3
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Fö-lös-le-ges szoftvert mi a ...nak? Nem, egy webszerver működéséhez NEM kell gcc. Szerintem... (Anno hogy is terjedt az első worm...?)
- A hozzászóláshoz be kell jelentkezni
Remelem wget, scp,ssh, ftp, curl.. stb. sincs a webservereden.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
üdv: pomm
- A hozzászóláshoz be kell jelentkezni
Nálunk még 3.1 es debian is szaladgál, valószínű azon már más nem is lesz :D
Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.28.3
- A hozzászóláshoz be kell jelentkezni
kiadás 1-3-5 évente: kereskedelmi UNIX-ok, AIX, HP-UX, Solaris
Nincs szerverem, de tudok gondolkodni.
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
Í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!"
- A hozzászóláshoz be kell jelentkezni
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...)
- A hozzászóláshoz be kell jelentkezni
Épp mostanában találtam megy egy Netscape Fsttrack szervert, meg jópár egyéb alkalmazást -- lehet, hogy túrok hozzájuk egy Caldera OpenLinux-ot is, mert azon ment anno...
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
már megtették a "kiadás 6 havonta, ha kész ha nem: Ubuntu, Fedora, OpenSolaris, openSUSE" szinoníma alatt
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"kvázi nincs kiadás, folyamatosan frissülnek a csomagok: Gentoo"
Az Arch is hasonlóan tesz. Számomra ez a legkényelmesebb. :)
- A hozzászóláshoz be kell jelentkezni
Ez gyakorlatilag egyenértékű, a ki mit használ kérdéssel :)
- A hozzászóláshoz be kell jelentkezni
Nem feltétlenül. Én is Kubuntut használok, mert viszonylag keveset kell reszelni, de rolling-release-t jelöltem, mert desktopra szerintem az jobb megoldás.
- A hozzászóláshoz be kell jelentkezni
Majd az eredményből kiderül.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
RedHat azt hiszem 7 evig tamogatott.
- A hozzászóláshoz be kell jelentkezni
Akkor miért nem RedHét? :-)))
- A hozzászóláshoz be kell jelentkezni
És igy CentOS, Scientific Linux, Oracle Enterprise Linux is.
Mielőtt az lenne a panasz, hogy nem lehet miből válogatni =)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
>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).
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni