Vlákno názorů k článku Dilema servisního balíčku od juvi - Autor mi s delším životním cyklem mluví z...

  • Článek je starý, nové názory již nelze přidávat.
  • 4. 11. 2008 7:58

    juvi (neregistrovaný)
    Autor mi s delším životním cyklem mluví z duše. Ovšem servisní balíky nevidím jako vhodné řešení. Vzhledem k síle balíčkovacích systémů Linuxu, uvažuji jiným směrem.
    Používám OpenSUSE a 2 roky podpory jsou málo. SLED alternativou není, protože je postavené na GNOME - když jsem zkoušel SLED 10, KDE na něm nechodilo dobře.
    Potřeboval bych systém, který nainstaluji uživatelům a vím, že alespoň 3 roky budou pro něj existovat záplaty. Na druhé straně bych docela uvítal zmenšení balíku stahovaných záplat po prvotní instalaci. Samotné peníze také jako problém nevidím - cca 500-1000 Kč za uživatelskou instalaci s podporou na další 3-4 roky by zákazníci dali - myslím, že tady je na straně poptávky veliká díra.
    Tedy moje představa o životním cyklu linuxové distribuce je asi takováto: Nová verze se vyvíjí nějakou dobu (alfa1-x, beta1-x, RC1..) a objeví se stabilní verze, např. 20.0. Pro tento systém se budou vydávat záplaty a např. po 3 měsících a po krátkém vývojovém cyklu (tak maximálně alfa1 beta1, rc1) se uvolní další verze 20.1 (20.2, 20.n), která bude zahrnovat běžné opravné balíky + aktualizace aplikací na novější verze - po cca. 3-4 měsících. Minor verze by tedy měly zahrnovat jádro, prostředí a aplikace, ale asi ne překladače a knihovny - vývoj by musel být uvnitř major verze velmi konzervativní. Toto období by mělo být dlouhé ~2 roky, potom by přišla verze 21.0. Po nástupu nové verze by nastalo období údržby dlouhé 3-4 roky - například jen pro zakoupenou podporu (za lidový, nikoliv enterprise peníz, za který by byla ještě delší a širší podpora).
    Vedlejším důsledkem takovéhoto modelu by byla nutnost existence nastavitelné 'dvourychlostní' aktualizace - buď jen bezpečnostní záplaty, nebo i novější verze aplikací. Prostě blbuvzdorná aktualizace pro určitou skupinu uživatelů a pro odvážnější otevřené pole.
  • 4. 11. 2008 10:19

    MiG (neregistrovaný)
    A není toto přesně případ RedHat ES, resp. alternativy zdarma CentOS? Můžete jet 5 let se starou verzí, která je neustále udržovaná, nebo časem přejít na novější verzi (u CentOS verze 4.7 a nová 5.2).
  • 4. 11. 2008 10:40

    Karel (neregistrovaný)
    Přesně takhle RedHat funguje. Velmi dlouhá podpora, dlouhý vývojový cyklus, důkladné testování a požadavek 100% stability. Díky tomu:
    1. V podnikové sféře je to velmi oblíbená serverová platforma
    2. Jako distribuce je to komunitou silně opomíjeno, protože "je sto let za opicema"
  • 4. 11. 2008 16:12

    Mard (neregistrovaný)
    Ano. Obvykle platí že každý rub mí i svůj líc, pokud zrovna nejde o Möbiuv proužek. Já také jedu na SUSE (nyní openSUSE) a obvykle každé 2-3 roky přecházím na novou verzi. Tedy několik verzí vynechám. Nevidím přínos v tom, abych každý půlrok měnil prostředí a zjišťoval co a proč nechodí (mluvíme o desktopech!). Asi SP nevidím jako rozumný přístup, spíše pokládám za rozumné přejít na vyšší verzi distribuce (a nyní to již openSUSE umí, že se přeinstaluje přes starou a převezme si nastavení). Co mi spíše vadí je, že se stále mění různé nepodstatnosti (třeba slovníky k Firefoxu či OOO) a uživatelé jsou rozptylováni instalací těchto změn.
  • 5. 11. 2008 14:27

    Standa (neregistrovaný)
    Představte si Linux někde na přepážce, pokladně nebo ve skladu. Funguje, a na svou práci stačí. Po 5 letech chcete přikoupit kompatibilní hardware na další pobočku. Budete řešit problém, že nové čtečky nejsou kompatibilní se starým systémem, a přechod na nový aplikační software by byl nákladný. Pak teprve oceníte význam service packu 5 let po vydání.
  • 4. 11. 2008 11:03

    wolf09 (neregistrovaný)
    Nevim jak vy, ale me SLED 10 s KDE chodi vicemene bez problemu 2 roky. A to ho pouzivam na pracovnim notebooku, takze vlastne porad. Puvodne jsem instaloval SLED 10 a loni jsem ho upgradoval na SP1.
    Jediny problem mam, ze pokud chci nejaky novejsi SW, tak ho musim hledat po ruznych uzivatelskych repozitarich.