Přejde Ubuntu na rolling-updates?

Ostatic a The Register píší, že Mark Shuttleworth naznačil, že by Ubuntu mohlo v budoucnu přejít na systém rolling-updates, což by znamenalo, že nové verze programů by se do repozitářů dostaly krátce po vydání a nebylo by nutné čekat na příští verzi distribuce. Shuttleworth řekl: „Nyní máme šestiměsíční cyklus vydání. V dnešním světě, který je orientovaný na Internet, musíme být schopní vydávat každý den“. Zdroj: LinuxOS.sk.

24.11.2010 11:35 | Tomáš Heger (geckon) | Komunita

Komentáře

[Jay]

No super, aspoň si nové verzie nebudem musieť inštalovať manuálne.

[Petr Ježek]

Rolling distro je Archlinux, a to nikoli v důsledku prohlášení, ale reálné průběžné aktualizace z repozitářů, které obsahují zvládnutelný objem balíků pro cyklus development-packaging-testing-stable. O tom, jak funguje "rolling" aktualizace v Mintu, je snad již dost známo včetně doporučení "stáhnout iso a přeinstalovat". Moloch jako Ubuntu nikdy nebude splňovat podmínku nejvyšší aktuálnosti při vysoké stabilitě pro profi nasazení. Už se těším, jak francouzská policie začne časem nadávat na "ten šmejd linux"...

[vulgární Nick]

Mohl byste prosím vysvětlit, proč by jim existence RU měla zabránit ve vytvoření "stable" větve (tedy ne-RU větve, která vyjde z nějakého bodu RU větve, ale bude po nějakou dobu podpory "konzervativně" aktualizována)?

[Tutor]

přejít =/= paralelně vytvořit.

opět nechápete psaný text? A nebo máte právo otvírat nesouvisející témata jako minule?

[martin]

jses si jistej?
pokud to spravne ctu, tak pan M rekl: "Nyní máme šestiměsíční cyklus vydání. V dnešním světě, který je orientovaný na Internet, musíme být schopní vydávat každý den". nic vic, nic min...

trochu selfpwn

[Bedňa]

Ale do štátnej správy by len blázon nasadil najaktuálnejší soft. Tam budú stále Long-term support.

[Jardík]

Sory, ale aktuální verze SW nemusí nutně znamenat nestabilitu systému. Pokud např. budou půl roku držet jádro a pár těch nejzákladnějších knihoven (klidně i včetně x serveru či waylandu či to tam daj), ale udržovat zastaralé verze firefoxu, openoffice, thunderbirdu a dalších programů tohoto typu, co uživatel běžně používá a obhajovat to stabilitou, to mi přijde úchylné. Ano, v nových verzích jsou někdy nové chyby, ale za to tam jsou opraveny starší a někdy tam jsou i nové užitečné funkce a rozhodně né na úkor stability. O stabilitu programů by se měli starat jejich vývojáři, né balíčkovači.

[Ivan]

JJ, existuje dost projektu ktery jsou vice-mene mrtvy. Behem pul roku si vyvojari najdou cas na par bugfixu a tim to konci. V takovym pripade opravdu plati ze bleeding-edge je nejlepsi volba. V pripade toho FF je dost nerealny se ze nekomu podari backportovat fix do rok stary verze.

[Stanislav Brabec]

Zkuste argumentovat skvělými novými užitečnými funkcemi zákazníkovi, který právě musel poslat tisíc zaměstnanců domů, protože rolling update obsahoval chybu zrovna ve funkci, kterou používá firemní intranet. Myslíte si, že ho utěší, že příští rolling update, který to možná opraví, bude už pozítří?

Takto se enterprise nasazení dělat nedá! Každý takový update se musí otestovat, a to hned na několika úrovních. Nedivte se, že zákazník touží po stabilním prostředí s minimem změn. Každá sebemenší změna pro něj znamená náklady na testování navíc.

[Jardík]

To je tak labilní kec, jako že rok nemůžu používat HDMI výstup, protože se bude aktualizovat jádro až za rok. Rolling update neznamená, že když zítra vyjde nové OOo, tak jim ho hned hodinu na to musí dát do repozitářů a admin musí ihned aktualizovat 200 stanic. Pan admin si má počkat a na oficiálních stránkách daného SW zkontrolovat bugy, když je daný SW pro něj kriticky důležitý. Nebo jistě není neschopný a tak prostě provede downgrade na původní verzi a počká, než se problém vyřeší.

[Stanislav Brabec]

Zákazník chce, aby systém, který má odladěný, fungoval co nejdéle, a aby opravy zahrnovaly jen bezpečnostní opravy , opravy věcí, které jemu dělají problémy, případně implementaci věcí, které potřebuje.

On si naopak platí distributora za to, že nebude každý den dostávat různé pro něj zbytečné aktualizace. Platí si za to, že příslušnou opravu distributor backportuje na jeho 5 let starou verzi systému, kde má všechno odladěno.

Jak chcete s rolling updaty podporovat verzi, která vyšla dnes, před měsícem, před čtvrt rokem, před půl rokem, před 8 měsíci atd. až k verzi, která vyšla před 5 lety? Buď se správci balíčků zblázní, nebo budete nutit několik vybraných verzí všem (a jsme zpátky u starého modelu).

[Stanislav Brabec]

Takový admin spravující desítky tisíc serverů ani nesmí pomyslet na to, aby na oficiálních stránkách stáhnul poslední verzi, zkompiloval a nasadil ji. Pokud to udělá, okamžitě ztratí podporu od distributora, a nebude mít v ruce výsledky testování. Před vydáním důležité opravy balíček vidí často i desítky lidí. U distributora se provádí množství testů, další testy musí provést testovací oddělení dané firmy.

Představte si, jakou škodu by takový admin způsobil, kdyby po instalaci nové verze HDMI modulu do jádra třeba jen 1% systémů nezvládlo restart. Tím selže provisioning, a dálkový downgrade nebude možný. Obejít osobně stovky serverů rozmístěných po celém světě a ručně provést opravu… To je na vyhazov na hodinu a soud o náhradě škody.

[LuděkS]

Naprosto souhlasím s oběma komentáři výše. Tohle je docela problém a pokud je Linux v produkčním prostředí na desktopech. Mám za sebou několikaletou zkušenost a mohl bych názory výše podepsat. To co chce uživatel je, aby mu to fungovalo, aby měl aktuální verze programů, které používají ostatní a aby se ostatní věci pokud možno neměnily. Není možné používat distro, které po aktualizaci nenaběhne (viz Fedora před lety a problémy s Xorgem a ovladači karet). Je dost těžké použít distro, kterému se "pod rukama" po aktualizaci změní nastavení desktopu (KDE3->KDE4;Gnome2 -> Gnome3 / Unity). Pro produkční prostředí by úplně stačilo, kdyby měl uživatel jistotu, že otevře poslední docx soubory, že mu bude fungovat vše na internetu a že bude co nejvíc kompatibilní s okolním světem. Nastavení desktopu mu může zůstat deset let stejné a nebude mu to příliš vadit, když mu budou ostatní věci fungovat.
Tohle mne na Linuxu trochu mrzí: Místo toho aby se dotáhly podstatné věci, síly se vydávají na změny desktopů, přesun tlačítek zprava doleva a na hádky o tom, co je ergonomické a co ne. Přitom je dost zásadnějších věcí, které kdyby byly dotažené tak by Linuxu v jeho nasazení velmi pomohly..

[Ladicek]

Enterprise nasazení a aktualizace z původních zdrojů? Seriously? Mám dojem, že entrprajzem už se tu ohání příliš mnoho lidí.

[Stanislav Brabec]

Velcí zákazníci mají samozřejmě vlastní zdroje, do kterých pustí jen ty aktualizace, které jejich testovací oddělení uzná za potřebné, otestuje a schválí.

[Grunt]

Tacoví zákazníci by asi mohli ještě na svůj web vyvěsit seznam exploitů k bezpečnostním záplatám (ve kterých je většinou link na bugzillu a přímo bug), které tim neuzavřeli. Když už to teda tak zjednodušují, tak aspoň poctivě.

[Stanislav Brabec]

Na služby, které neprovozují veřejně, nepotřebují všechny bezpečnostní aktualizace. Je na nich, aby zvážili případné riziko od insiderů, a porovnali jej s cenou testování změny.

Jiné potřeby má řízení letového provozu, jiné řízení nepřetržitého provozu, jiné bankovní operace a jiné webová farma.

[scolopes]

"uzná za potřebné"

[Grunt]

Jakože administrátor takového systému neví kde hledat tlačítko Downgrade nebo jak napsat do konzole příkaz gdb?

[Stanislav Brabec]

Ano, v případě bezpečnostní aktualizace si může vybrat mezi verzí se známou bezpečnostní dírou a verzí, která mu nechodí.

[Grunt]

Není nad pořádný výběr.

[vulgární Nick]

Uvědomte si několik věcí:

1. RU v žádném případě nutně neznamená, že se do éteru vpouštějí zcela neotestované balíčky.

2. I na "klasických" releasech založená distribuce může přinést fatální chybu.

Ano, souhlasím, RU je často (asi i většinou) spojeno s menším testováním, ale RU jako takové je o způsobu distribuce balíčků, nikoli o rychlosti. Každý balíček můžu klidně testovat dvacet let, než ho pošlu mezi aktualizace...

Tím neříkám, že bych do podnikového prostředí jednoznačně volil RU - spíš naopak -, jen podotýkám, že RU není nutně špatné.

[scolopes]

Viz odpověď dustinovi dole - RU zvyšuje počet kombinací různých verzí balíčků, které se spolu setkají. Při systémů releasů je to v ideálním případě jen tolik kombinací, kolik je releasů, při systému RU to může být klidně i nová kombinace každý den (pokud v průměru vyjde jedna nová verze něčeho denně).

[vulgární Nick]

Ale i na releasech založené systémy průběžně vydávají aktualizace, takže kombinací je stejně více než releasů.

[scolopes]

Však jsem taky psal "v ideálním případě". V ideálním případě se nemění verze, ale jenom vkládají security bugfixy.

[LuděkS]

Souhlasím s oběma body, a právě proto si myslím, že je klidně možné mít RU i pro produkční prostředí. Jen způsob distribuce balíčků by bylo třeba mít "konzervativnější". Výhodou je hlavně to, že není nutné vždy po čase řešit velký upgrade / povýšení verze (či jak to které distro pojmenovává). To je myslím si velká výhoda RU distra - pokud je dobře dělané..

[Stanislav Brabec]

Ano, RU je možné mít i v produkčním prostředí. Ale proč to dělat, když to zbytečně zvyšuje cenu údržby? Každá aktualizace znamená například práci desítky lidí v testovacím oddělení a několik dnů automatizovaných zátěžových testů.

Velký upgrade sice znamená řádově vyšší nasazení než jednotlivá aktualizace, ale stále řádově nižší, než několik desítek zbytných aktualizací pomocí RU. A omezuje riziko fatální chyby pouze na okamžik velkého upgrade. (A to vůbec nemluvím o systémech, které mají servisní okno jen pár hodin několikrát do roka. Tam si RU vůbec nedovedu představit. Tam se každé servisní okno změní bezmála na velký upgrade.)

Nevím o velké firmě, která by RU na svých systémech požadovala. Naopak ale vím o firmách, které platí nemalé peníze za to, že jim distributor portuje každou požadovanou změnu do systému starého bezmála 10 let.

Ano, jsou výjimky – třeba Firefox nebo Flash na desktopech nebo PHP nabízené na virtuálních serverech. Ale proč zbytečně riskovat regrese povýšením verze nějaké základní knihovny, a to vše jen proto, že je třeba o trochu rychlejší?

[LuděkS]

To je naprostá pravda. Jen bych chtěl dodat, že je ale také rozdíl mezi desktopem a servery. 10 let starý systém na desktopu je nesmysl -> v tom se určitě shodneme. Naopak právě těch několik aplikací, které jsou na desktopu potřeba se vyvíjí poměrně rychle. Já osobně jsem na desktopech používal Ubuntu LTS a ke konci podporovaného cyklu to byl už zastaralý desktop - se všemi problémy z toho vyplývajícími. Osobně ale považuji nápad s LTS a "normálními" verzemi u Ubuntu za skvělý - a také za maximum čeho se dá v poměru stabilita & nové aplikace dosáhnout. Proto jsem Ubuntu v tomto smyslu docela fandil.. až do teď, kdy postupné změny v přístupu k desktopu mne docela znejistěly v tom co dál..

[scolopes]

Osobně ale považuji nápad s LTS a "normálními" verzemi u Ubuntu za skvělý - a také za maximum čeho se dá v poměru stabilita & nové aplikace dosáhnout.

Ještě lepší by bylo, kdyby šly jednoduchým způsobem instalovat nové aplikace do staršího systému. Jenže to by vyžadovalo stabilitu API, což imho zrovna není silná stránka Linuxových systémů...

[LuděkS]

... hmm na tom je kus pravdy. Ale může se to takhle veřejně říkat..?
PS: Předpokládám, že se ozvou hlasy, že to není pravda a že nejlepší je stejně příkazový řádek
[pro jistotu] Nemám naprosto nic proti příkazovému řádku, ale bavíme se o desktopu pro produkční prostředí, že..) [/pro jistotu].

[Stanislav Brabec]

Stabilita API vybraných aplikací a knihoven je zaručena v rámci LSB. Dostat knihovnu do LSB ale není jen tak, a silně to ovlivňuje její vývoj. Nicméně třeba GTK+ se tam již dostalo, a tak AdobeReader nebo Flash ji mohou použivat bez problémů s portabilitou.

[Stanislav Brabec]

10 let starý desktop není nesmysl. Systémy, na kterých běží speciální (a často velmi drahá) desktopová aplikace, řídící grafické konzole, informační kiosky, pokladní systémy. To všechno jsou místa, kde je požadován desktopový systém, a zákazník dokonce požaduje 15 let podpory (očekávaná životnost hardware).

Co myslíte, že je pro zákazníka nasazující linuxový desktop výhodnější? Zaplatit milion za údržbu 10 let starého desktopového systému nebo 10 milionů za kompletní upgrade a recertifikaci nového systému?

Stále přemýšlíte v intencích desktopu s officem a prohlížečem někde v kanceláři. Ale linuxový desktop se nasazuje v široké škále aplikací od jednoúčelových strojů ve výrobním procesu, přes nejrůznější pracovní stanice až třeba po řízení letového provozu.

[LuděkS]

Máte pravdu. Ale já nepíšu o tom, kde je linux "konkurenceschopný" Píšu o situacích, kde se mu to právě nedaří. Tomu co popisujete já říkám "speciální desktop". Můžeme se zde bavit o poště, bankách a různých terminálech a řídících obrazovkách až třeba po displej na ledničce. Já myslím klasický desktop pro uživatele ve firemním prostředí tam, kde se nejedná o hromadné nasazení pro velké množství stanic, které používají i speciálně vyvinuté aplikace atd., Kde se jedná o "obecné" prostředí, tak vývoj desktopu a desktopových aplikací prostě MUSÍ reagovat na vývoj okolo -> jinak je nepoužitelný. A to je právě tento případ. Já s Vámi souhlasím, ale vycházíme oba z odlišného předpokladu. Já se snažím mluvit o prostředí ve kterém Linux potřebuje "prorazit", Vy mluvíte o prostředí, kde už se v řadě případů úspěšně zabydlel. Ano máte pravdu - v této souvislosti mám na mysli desktop v kanceláři - ale také v projekčních kancelářích malých firem, v účetních firmách, grafických studiích, stavebních firmách, hudebních studiích.. atd.,

[Stanislav Brabec]

Snad s výjimkou zcela obecné kanceláře, kde si vystačí s prohlížečem, mailem, officem a pár šablonami, všude jinde potřebujete nějaké speciální aplikace. Pro zjednodušení předpokládejme, že jsou k dispozici pro Linux.

Nejsou ale pro nějaký rolling-update Linux ze dne 4. 5. 2011, ale pro konkrétní verzi konkrétního systému. Tam, kde jí výrobce testuje, a také kompiluje. Pokud na systému zákazníka bude něco jiného, aplikace nejspíš poběží. Ale také nemusí. Nebo za jistých nejasných okolností spadne.

Řešit pád na systému, byla-li aplikace kompilovaná v jiném prostředí, než na kterém je instalovaná, je noční můrou každého vývojáře. Nedivte se proto, že firmy dodávající software nechtějí slowly rolling update systémy podporovat.

Uvedu jednu konkrétní zkušenost: Jeden náš velký zákazník certifikoval svůj software pro dvě různé distribuce. Na jedné z nich aplikace fungovala bez problémů. Na druhé, novější, aplikace také fungovala. Ale pokud uživatel používal určité grafické téma, aplikace záhadně spadla kdesi v libpng. Kolega strávil několik dnů neúspěšným laděním (zdrojový kód jejich aplikace jsme z pochopitelných důvodů nedostali). Po dlouhé debatě se zákazníkem se ukázalo, že si zjednodušil život, a svůj software zkompiloval jen jednou, a pak certifikoval pro dvě různé distribuce. K pádu docházelo na platformě, na které nebyl nativně zkompilován.

[LuděkS]

Ano, to je přesně to co myslím. Čili se dostáváme zpět k tomu, že tu máme určitou konzervativnost & stabilitu versus nejnovější software. Tudíž si myslím, že nabídku Canonicalu na výběr buď LTS se snesitelně zastarávajícími aplikacemi ale s podporou nebo novými v malých upgradech ale s rizikem asi nic nepřekoná. Bavíme se stále o běžném desktopu. Nicméně jsem chtěl říct, že bych si přál... kdyby to bylo možné, aybych nemusel absolvovat velké upgrady. Ani u Fedory /CentOSu /SuSE / Mandrivy, Ubuntu, Mintu.. ani kdekoliv jinde... A to i přes to, že z dlouhodobých zkušeností mohu říci, že u Ubuntu tyto upgrady obvykle dopadly dobře (což nelze vždy říct o jiných distrech.. obvzláště ne o Fedoře, což je - vzhledem k jejímu zaměření - pochopitelné).

[Stanislav Brabec]

Nicméně jsem chtěl říct, že bych si přál... kdyby to bylo možné, aybych nemusel absolvovat velké upgrady.

Možné to není. Jsou okamžiky, kdy jediná změna znamená velký zásah do systému. Z právě probíhajících je to například přechod k systemd, GTK3, GNOME3, z minulých to třeba byla změna síťové vrstvy v jádře, příchod udev, nebo třeba přechod z libc5 na glibc. Jen díky velkému upgrade je možné všechny následné změny ostatních balíčků dodat najednou a předtím je otestovat.

[LuděkS]

To zní velmi logicky a z toho důvodu jsem si donedávna myslel přesně totéž. Ale překvapilo mne, že existuje více distribucí založených na rolling updates, tzn., že jsou lidé, kteří se o něco podobného minimálně snaží.. O tom, že je to mnohem pracnější a s mnoha úskalími není jistě pochyb.. ale asi to jde (i když to asi pořádně "dře" )

[Stanislav Brabec]

Jistě, možná 99% aktualizací takto provést lze.

Ale například zmíněný přechod z libc5 na glibc (kolem roku 1997) znamenal překompilovat (a naportovat) úplně všechny binárky a knihovny v systému, a pak najednou provést výměnu. Jakýkoliv mezistav vždy znamenal polofunkční systém. Ostatní aktualizace nebyly tak zásadního rázu, ale občas se na problémové věci i tak narazí.

Občas se třeba stává, že i velkým distributorům uteče do enterprise distribuce nekompilovatelný zdroják. Zkompilovali a vydali to, pak přišel service pack, ve kterém se odehrála změna, po které už zdroják nejde zkompilovat.

[SPM]

Jaksi jsem si nikdy nevšiml, že by ubuntu bylo enterprise distro nebo že by to dokonce o sobě hlásalo... RU pro enterprise asi opravdu vhodný neni, proto tu jsou distra určená pro enterprise desktopy a ubuntu mezi nima neni, takže v nasazení RU u nich bych až takový problém neviděl...

[imploder]

Nejsem si jistý, co se za tak často skloňovaným výrazem "enterprise" přesně skrývá, ale např. Google (obrovská firma) používá Ubuntu jako hlavní systém na desktopy - to bych řekl, že "enterprise" použítí je.

[Pev]

Google IMHO používá vlastní upravenou verzi Ubuntu.

[Stanislav Brabec]

Ve smyslu Linuxové distribuce se tím většinou míní vysoce stabilní a dlouho testovaná verze s dlouhou dobou podpory, a s provedenou certifikací kompatibility s některými aplikacemi.

Ač je Google určitě „enterprise“ ve smyslu firemního nasazení, tak Google rozhodně nevyžaduje výše zmíněné „enterprise“ parametry. Google sází na vysokou redundanci, softwarový nebo hardwarový pád jednoho stroje je pro ně jen číslo ve statistice.

Je to něco naprosto jiného, než když selže například systém řídící diskové pole.

[imploder]

Pokud Google aktualizuje stroje hromadně a aktualizací se něco rozbije, tak mu redundance nepomůže, protože spadnou všechny. Google si asi kompatibilitu dokáže otestovat sám, určitě má na to lidi.

[Ladicek]

nejvyšší aktuálnosti při vysoké stabilitě pro profi nasazení

[Grunt]

Moje řeč. Ještě k těm parametrům můžeme přidat zlatého jednorožce. Co by ti lidi furt ještě nechtěli?

[clayman]

Jednou na ně budou muset přejít -- až jim dojdou písmena a zvířata.

[vain]

To udělají jak v Praze s registračními značkami, přidají třetí písmeno, něco jako "Relativně Rychlý Racek" atd..

[Nicky726]

Řehot...

[jos]

Pekelně Pomalá Puma

[otula]

Ostentativně Obscénní Osel

[Tutor]

V RedHatu a SUSE se teď jistě smějí...

[Salamek]

v suse ani moc ne

[Tutor]

proč by se nesmáli. Doteď jsou na tom lípe než Canonical, který je dodnes uměle udržovaná neživotaschopná parodie na Linuxový business.

[Zopper]

Obávám se, že v SUSE se teď věnují spíše vlastní budoucnosti, než aby se zajímali o ubuntu... A takhle to asi myslel i autor předchozího komentáře.

[Tutor]

Já bych řekl že v SUSE standardně pracují jako každý jiný den.

[Bedňa]

Aby sme si rozšírili obzory, čo je na ňom neživotaschopné?

[Tutor]

Například to, že je z 93% závislý na Debianu (není si chopen ani sám zabalit balíky), a černá díra na Shuttleworthovy úspory (není schopen si sám na sebe vydělat).

K tomu si připočtěme naprosto zoufalý obraz v opensource komunitě, na kterém každodenně usilovně pracují vymýšlením nových podrazáren, a celkový obraz je myslím zřejmý. Velmi bych se divil, kdyby s nimi ještě vůbec někdo chtěl něco mít.

[Bedňa]

Načo by ich balili znovu, keď ich môžu využívať všetky distrá založené na Debiane? To že nevedia zarobiť je otázka času a keby aj nie môže sa stať vetvou Debianu ako testing ... Ja stále nechápem tú nenávisť. Starám sa o pár Ubuntu desktopov, všetci ich chvália, nemám s nimi prakticky žiadny problém. Ani si nepamätám že by som nejaký riešil okrem prechodov na vyššiu verziu a výpadku elektriny, ale aj to spravili dva magické príkazy :) Spravujem ich už pár rokov a nemám nahlasený jediný pád, to je dosť podstatná informácia, teda aspoň pre mňa a spokojné BFU.

[LuděkS]

Mám stejnou (pozitivní) zkušenost. Ubuntu je docela dobře dotažené právě pro takovéto použití. Včetně aktualizací. Nenávist k němu pline jedna ze závisti a jednak jako reakce na fanatické Ubunťáky, kteří spamují všechna možná fóra a všude píšou o tom, jak je Ubuntu nejlepší. I když.. v poslední době už to asi není tak hrozné.. Mně ale nyní vadí přístup Canonicalu, kdy vnucuje lidem to co považuje za nejlepší. Tlačítka zprava doleva, Unity místo Gnome, atd.). Tohle uživatele moc nepotěší když se jim distro změní pod rukama a bude je přesvědčovat, že je to pro ně to nejlepší i když oni si to nemyslí (co mně to jen připomíná?). Na Linuxu oceňuju právě svobodu volby.. a tady začíná být podle mého názoru trochu ztížená.. A přístup "uživatelé jsou "blbci" a my víme lépe co je pro ně dobré" opravdu rád nemám..

[martin]

lol...ty ses hodne kruda lama. s trochou kultivace bys snad mohl dohnat i ptomese a vnest nejakou tu legraci do nasich zivotu, co? no ja ti budu fandit :)

[Rezza]

Ano, kdyz ted posledni dobou se Fedora snazi napodobit Ubuntu a Ubuntu se rozhodne jit do bleeding edge jeste dal nez kdy Fedora byla :D

[branchman]

Ak nestihaju za pol roka odladit vsetky baliky (na niektorych strojoch aktualizujem vzdy na predposlednu verziu), tak rolling upgrades nechcem vidiet...

[Miška]

Takze uz to nebude freezovanej rebrandovanej debian, ale jen rebrandovanej debian

[astray]

Z Ubuntu Debian SID?

[Pev]

Takze uz to nebude freezovanej rebrandovanej debian, ale jen rebrandovanej debian

+1.

Akorát ořezaný o 12 architektur (9 offic.) :).

Kdyby raději podporovali pořádně Debian a upstream .

[alblaho]

Možná se konečně narodí mnou vytoužené dvourychlostní distro. Stabilní systém (jádro, X, ...) a k tomu aktuální aplikace typy FF, OOo, Inkscape, Gimp, Shotwell. To by bylo labůžo!

[Piškot]

To jo dávalo by to smysl.

[Tutor]

takové distribuce už exisují. Nebylo by první ani poslední.

[Jay]

Existujú, ale zďaleka niesú tak BFU friendly ako Ubuntu...Takže Ubuntu na tom môže len získať.

[Pavel Stárek]

Prosím prosím, které to jsou? Debian stable ne - maximálně věci z Backports. RHEL/CentOS ne - občas někdy tam sice dají novější věc (naposledy to byla OOo z trojkové řady), SLES/SLED neznám, ale myslím si, že to bude podobné RHEL. Mandriva Enterprise server asi taky ne. Tak které to tedy jsou, ty distribuce, které mají nezbytný základ stejný, ale přidávají aplikace z upstremau?

[Miška]

No u enterprise dister bych to moc nehledal, i kdyz u SLE muze v service packu dojit k updateu aplikaci, pokud o to zakaznici stojej, ale vetsinou se jedna o jiny veci, nez firefox Jinak u openSUSE mame v Build Service repa pro ruzne oblasti a uzivatel si tak muze snadno rict, ze chce nejnovejsi verze KDE, OO, nebo Firefoxu. A namixovat si sam, ktery casti chce stable a ktery rolling. Ja treba rad experimentalni kernel a X, ale stable gnome

[bibri]

Podobnou možnost má skoro každé distro, když k němu přidáme neoficiální repa.

Ale tohle je ale něco jiného - tady to Canonical celé zařídí, otestuje a prohlásí za podporované. Navíc nechá možnost zůstat jen u "běžných aktualizací", tzn. půjde to vypnout.

To je něco, co opravdu chybí a moc lidí to zatím nezkoušelo, z výjimek si pamatuji třeba Ulteo (stabilní core, nové apps). Jsem zvědav, jak se s tím v Canonicalu poperou.

[heh]

OBS

[bibri]

OBS je platforma pro buildy, nic víc, všechno ostatní je na komunitě.

[kuba77]

Možná tak Arch Linux s LTS jádrem.

[alblaho]

Myslím, že takového stavu lze dosáhnout na Gentoo. Jenže to má zase hromadu jiných nevýhod.

[Vin]

PCLinuxOS?

[heh]

například v Opensuse můžetě díky buildservice používat před-před-poslední verzi distribuce a aktuální doftware jako firefox, openoffice, atd... Podporovány jsou cca 4 distribuční verze současně. Víc snad ani nemůžete chtít

[Pavel Stárek]

Nojo no. To je právě to. Neříkám že OpenSUSE je špatné distro. Jenže člověk je už příliš stár na to, aby si zase zvykal na nové distro Kdysi jsem to zkoušel s Debianem (stable samozřejmě), nefungoval špatně, ale prostě to bylo jiné (třebas při konfiguraci apache ty příkazy a2enable - no toto, samozřejmě jsem s těmi symlinkama nejdřív šachoval ručně ). Ve Fedoře (RHEL/CentOSu) už prostě vím kam sáhnout. No počkám ještě na CentOS 6, a na Debiana 6 a udělám pokus. Furt říkám, že by to chtělo nějakou Fedoru LTS, ale to je jako když mluvím do větru (a přitom lidé z Red Hatu jsem evidentně chodí na čumendu i pokec, ale je jim to jedno ), asi půjdu do Redhatí bugzilly vyplnit nějaký wish bug

[Václav Kramář]

Fedora LTS se jmenuje Red Hat Enterprise Linux.

[pavlix]

A Fedora LTS bez komerční podpory se jmenuje CentOS.

[Tutor]

BuildService může používat i Fedora (a také tam pro fedoru nějaké balíky jsou). V praxi lze afaik jeden balík chrlit pro všechny možné distribuce.

[Pev]

Prosím prosím, které to jsou? Debian stable ne - maximálně věci z Backports.

Debian testing, vybrané věci z unstable/experimental :). Z určitých podmínek nepoužívám debian stable ani na serveru, natož na desktopu.

RHEL/CentOS ne - občas někdy tam sice dají novější věc (naposledy to byla OOo z trojkové řady), SLES/SLED neznám, ale myslím si, že to bude podobné RHEL. Mandriva Enterprise server asi taky ne. Tak které to tedy jsou, ty distribuce, které mají nezbytný základ stejný, ale přidávají aplikace z upstremau?

Fedora, Archlinux, ... Jak už napsal Miška, enterprise distra prostě nemají aktuální software (je to poslední, co bych doma instaloval).

Možná by se našlo něco jiného zajímavého na http://distrowatch.com/.

[Sešívaný]

Jo, zní to zajímavě. De facto to jen nahradí to, co momentálně suplují PPA, s tím, že tomu bude asi věnována větší pozornost při testování. Nechápu, proč by měli třeba francouzští četníci nadávat. Předpokládám, že to bude v samostatném repozitáři, který bude potřeba povolit. Kdo to nechce, může zůstat u současných zmražených repozitářů a nic se pro něj nezmění.

[Pavel Stárek]

To by bylo, ale jde o to jak danou problematiku uchopí Aby do těch rolling updates nebylo zahrnuto naprosto vše. Ale pro mne by to nebylo, nějak nemám Ubuntu rád

[Ladicek]

Upřímně, to by pro mne byl killer, kvůli kterému bych byl schopný překousnout některé věci, které mi na Ubuntu vadí. Chci!

[Jiri Dobry]

souhlas

[AsciiWolf]

+1

[Pev]

Upřímně, to by pro mne byl killer, kvůli kterému bych byl schopný překousnout některé věci, které mi na Ubuntu vadí. Chci!

A kolik fcí Vám to dá navíc oproti Debian testing/unstable?

[Ladicek]

Aktuální software. Nejpalčivější to je v době freezu, což by měl řešit Debian CUT, ale čert ví, kdy to bude…

[Pev]

Řeč byla o Debian testing/unstable. Zde nemám problém s aktuálním sw ani dnes (buď je v experimental, nebo v unstable). Těsně před vydáním prostě uživatelé stable začínají používat testing a uživatelé testingu unstable.

[Ladicek]

Právě že byla řeč o testingu/unstablu. Experimental nic neřeší, tam spousta věcí vůbec není.

Ale možná jsem jenom otrávenej aktuálním stavem.

[M]

Myslíš jako FreeBSD? :)

[vulgární Nick]

Hezké, ale buď utopické nebo za cenu některých nevýhod. Aktuální aplikace vyžadují aktuální závislosti, aktuální závislosti vyžadují další aktuální závislosti atd. Problém je, když nějaký program závisí na něčem, co je součástí toho "stabilního systému", ale v aktuálnější než stabilní verzi. Jednoznačný střet zájmů.

Kdyby "stabilní systém" a aktuální aplikace byly dva zcela jasně oddělené ekosystémy, šlo by to. Jenže oddělení lze dosáhnout především těmito dvěma způsoby: 1. nesdílením závislostí, 2. vytvořením systému, kde by bylo možné mít nainstalováno několik verzí stejné věci. A to je složité nebo nevýhodné.

[lertimir]

Rolling update dostávají uživatele do role testera. Aby to mělo smysl, měl by uživatel v téhle roli mít zvládnuté alespoň reportování chyb do bugzilly.

Pokud o něco takového nemá zájem, a takových je většina, jenom se bude zlobit. Myslím si že naprostá většina uživatelů, kteří nemají IT jako koníčka, ale jako pracovní nástroj, zajímá primárně stabilita, aby to co funguje dnes fungovalo i zítra, za měsíc a za rok. Takový uživatel minimalizuje čas věnovaný systému, protože ten čas nemůže věnovat něčemu, co ho baví nebo co je jeho práce.

Postavit uživatele asi nejrozšířenější distribuce do role testerů je špatně.

[Václav Kramář]

Stačí, když do bacports budou valit aktuální verze Firefoxu, Thunderbirdu, OpenOffice/LibreOffice, Chromia, Gimpu, Rhythmboxu a podobných aplikací. A jádro systému ať nechají jak je.

[Jardík]

Jenže to někdy nestačí, backportovat do nekonečna nejde a často je po půl roce od vydání nové verze distra s backportama (a kolikrát i s PPA) konec.

[dustin]

Souhlas, navíc oficiálně "podporovaných" verzí ubuntu je už tolik, že to Canonical bezplatně stejně nemůže pořádně a zodpovědně dělat. Je to dobré pro PR, pro novináře, pro IT weby (každých půl roku nové toturiály pro novou verzi - již dnes všichni píší o betě 10.10 místo LTS), ale kvalitu backportů tímto tempem nelze udržet.

[Václav Kramář]

Ty aplikace obvykle nevyžadují nejnovější verze knihoven, takže backportování zas tak nemožné není. Navíc stačí backportovat jenom pro LTS verze. Pro ne-LTS to je zbytečný.

A co se týká počtu souběžně podporovaných verzí, tak ji nic nebrání zkrátit dobu podpory ne-LTS verzí řekněme na 9 měsíců. U půlročních rychlokvašků jsou 3 měsíce přechodného období víc než dost.

Ale dovedu si představit i přechod z rychlokvašků na rolling-release a každé 2 nebo 3 roky udělat freeze a vydat LTS. Ale to už vlastně dělá Debian. Jenom ten jeho freeze není pravidelný. :-P

[PetrHL]

Jenže to bohužel nebude dost dobře možné. Nová verze Firefoxu bude chtít novější verzi konihovny tohohle, OpenOffice támhle toho, Gimp zase toto atd. A nakoc stejně budete muset updatovat půlku systému.

Stavu, kdy budete mít stejný základ systému a aktuální aplikace, asi nepůjde dosáhnout. Bohužel.

[alblaho]

Programy obvykle nevyžadují nejmodernější systémové knihovny. Že jsou proti nim v binárních distrech přeložené, to je jiná věc.

Aktuální binárku FF přímo od mozilly v pohodě rozjedu na dva roky starém Ubuntu.

[bibri]

Přesně tak.

[Michal Vyskočil]

Programy obvykle nevyžadují nejmodernější systémové knihovny. Že jsou proti nim v binárních distrech přeložené, to je jiná věc.

Zrovna Firefox je u většiny distribucí jedním z prubířských kamenů. Nové verze obvykle závisejí na ještě nevydaném release knihovny cairo, dost často přicházejí s novou verzí xulrunneru, se kterou ti přestane chodit kdeco (eclipse, a jiné věcičky). Z hlediska distributora peklo největší. Ale updatovat se musí, anžto každé vydání opravuje kopec CVE.

Aktuální binárku FF přímo od mozilly v pohodě rozjedu na dva roky starém Ubuntu.

Právě za cenu statického linkování, což je přesně to, co distributor dělat nemůže.

[dustin]

Myslím si, že rolling updates s aktuálními a přesto otestovanými a funkčními balíky je zcela reálný. Jenom se tomu testování musí naplno věnovat skupina lidí. A do oběhu pouštět jen dobře otestované a vzájemně odladěné balíky, klidně půl roku starého softu.

Jenže testování je nuda, takže to dlouhodobě nikdo nebude kvalitně dělat zadarmo. U nás ve firmě bych neměl problém platit ročně pár stovek za každý desktop, napojený na takovou enterprise desktop rolling-updates distribuci. Taková zatím neexistuje, alespoň o ní nevím. Ale jsem stále více přesvědčen, že by to mohl být velice zajímavý a výnosný celosvětový B2B byznys s nízkými logistickými náklady - distribucí po internetu. Mít volných pár desítek mil. USD, vážně bych o tom přemýšlel. Zapálené lidi by asi nebyl problém sehnat a střední Evropa mi přijde jako dobrá kombinace know-how vs. náklady.

Máš však pocit, že Shuttleworth tlačí Ubuntu do spotřebky, mimo firemní zaměření, a inspiruje se applem. Stávající model je pro firmy neudržitelný. Na udržování neplacených LTS v Canonicalu nezbývá moc prostředků, protože firma horečně hledá ziskový model (tedy vyvíjí stále nové neotestované technologie), aby se dosavadní obrovské investice vrátily. Zcela to chápu a akceptuji, je to naprosto v pořádku. Ale stále rychlejší tempo zásadních změn mezi verzemi- UI, Unity, Ubuntu One, atd. - to není pro firmy zajímavé.

[M]

Myslím si, že rolling updates s aktuálními a přesto otestovanými a funkčními balíky je zcela reálný. Jenom se tomu testování musí naplno věnovat skupina lidí. A do oběhu pouštět jen dobře otestované a vzájemně odladěné balíky, klidně půl roku starého softu.

To by byl asi trochu problém ne? Release systém má tu vlastnost, že je tam množina softwaru, který je v nějaké verzi, a otestovaná je TATO MNOŽINA. IMHO pro stabilitu je zásadní testovat vazby mezi jednotlivými balíky, ne jenom balíky jako takové.

Jestliže mám otestovanou kombinaci X-1.1, Y-2.2, Z-3.3, a zmenim Z na 3.4, tak musim opet otestovat vsechno, ne jenom Z-3.4. (teda alespoň v případě, že ty balíky mají nějaké vazby, což v praxi bývá). Čím větší ta množina je, tím víc práce přibývá oproti release přístupu.

Přijde mi, že by takový systém přinesl strašně moc práce navíc a není mi moc jasné, jaké má výhody oproti normálnímu release cyklu.

[dustin]

Nemyslím klasický rolling updates (ala arch), ale něco, co bude v několikaměsíčních intervalech (klidně jednou ročně) vydávat aktualizace. OSS softy se stále vyvíjejí, opravují se neoptimální funkce, přidávají nové užitečné a je potřeba jednou za čas aktualizovat. Řešením ale není přeinstalace celého jednou za dva roky, na to nemají firmy čas ani prostředky. Upgrade musí být hladký. Proto bych nedělal upgrade celého, ale jenom na sobě závislých částí a častější. Např. přechod na aktuálnější OpenOffice, nový prohlížeč, smbclienta dobře podporujícího nové MS protokoly, nové cupsy s novými drivery na tiskárny atd. Na to není potřeba upgrade celého systému. A celé by to bylo zaměřené na firemní prostředí, kde mě nepálí konzumní věci typu dvb, itunes, hry atd.

[M]

On by úplně stačil čistý a přehledný systém, kam si ty nový CUPSy bez problémů doinstaluje ze zdrojáků uživatel sám, když je bude chtít :)

[Raduz]

Termíny "bez problémů", "uživatel sám", "ze zdrojáků" a "firemní prostředí" asi moc dobře dohromady nepůjdou.

[M]

První tři jdou docela v klidu dohromady v Archu, *BSD apod. a poslední termín jsem nepoužil, i když stejně nevím, proč by se IT oddělení firmy nemohlo rozhodnout nasadit novou verzi CUPS...

[Raduz]

"Firemní prostředí" zaznělo o příspěvek výš.

i když stejně nevím, proč by se IT oddělení firmy nemohlo rozhodnout nasadit novou verzi CUPS...

Ze zdrojáků? To přeji pracovníkům IT oddělení firmy hodně štěstí a vytrvalosti...tedy hlavně při hledání nového zaměstnání.

[M]

Chceš snad říct, že neexistuje jediná firma*, kde by se kdykoli v minulosti nainstaloval byť jen neden software třetí strany?

A jestliže existuje, nebylo by fajn, kdyby způsob, jak ten software nainstalovat a zabalit, byl jednoduchý jako na FreeBSD nebo Archu a ne krkolomný jako na Debianu?

* "firmy" nejsou jen ty, co mají desetitisíce serverů, ale třeba i ty, co jich mají deset

[pavlix]

A jestliže existuje, nebylo by fajn, kdyby způsob, jak ten software nainstalovat a zabalit, byl jednoduchý jako na FreeBSD nebo Archu a ne krkolomný jako na Debianu?

On na debianu zase tak krkolomný není. Stejně jako na FBSD nebo Arch jde jednoduše instalovat a odinstalovat to, co už někdo připravil, instalovat pomocí svaté trojice a prefixu jde v podstatě cokoli, kde si je člověk vědom závislostí, takže tam bych taky neviděl problém.

Podle mě není potřeba, aby instalace custom software byla jednodušší než na Debianu (kde jem mimochodem dost customly compiled software využíval), důležité je, aby distribuce poskytovala slušný základ a o tohle už se může postarat admin.

[scolopes]

On na debianu zase tak krkolomný není.

Nechci rozjizdet flame, ale na FBSD pokud se rozhodnu si nejaky port prelozit s jinou volbou, nez tam standardne je, tak obvykle staci upravit jeden radek v Makefile :) Podobne na Archu.

Presny postup na debianu uz si nepamatuju, ale ocekaval bych neco jako 1] stahnout zdrojovy balicek 2] rozbalit 3] upravit 4] zabalit 5] prelozit do binarniho balicku 6] nainstalovat.

Nebo to tak bylo jenom na (S)RPM-based distrech? Uz je to nejaky patek, co jsem s tim delal...

Ad svata trojice: problemem neni jenom pracne zjisteni a nainstalovani prerekvizit, ale treba i distro-specific patchu...

důležité je, aby distribuce poskytovala slušný základ

Na tom se shodnem :)

[pavlix]

Presny postup na debianu uz si nepamatuju, ale ocekaval bych neco jako 1] stahnout zdrojovy balicek 2] rozbalit 3] upravit 4] zabalit 5] prelozit do binarniho balicku 6] nainstalovat.

Tak minimálně krok 5 lze vynechat stejně jako na FBSD (a stejně jako na FBSD se může hodit ho zachovat), hádal bych, že krok čtyři taky, ale nemám vyzkoušeno. Bod 2 je triviální, stejně jako bod 1 (i když ten může vyžadovat čekání). Bod 3 není výrazně komplikovanější než u FBSD, bod 6 je společný.

Takže pro instalaci jednotek balíků toto vidím v globální práci jako bezvýznamné. Teď nemluvím o případu, kdy je takto postaven celý systém nebo jeho podstatná část.

Ad svata trojice: problemem neni jenom pracne zjisteni a nainstalovani prerekvizit, ale treba i distro-specific patchu...

Já v tom zase tak velký problém nevidím.

Aby bylo jasno, já netvrdím, že je to na FreeBSD (a jiných) špatně. Popravdě nejvíc mi v tomto vyhovovalo Gentoo (výrazně lépe než FreeBSD). Dokonce netvrdím, že by bylo špatně, aby něco takového bylo pečlivě udržováno pro Debian. Jen si myslím, že to pro stávající userbase Debianu není tak podstatná vlastnost, aby po ni plakali.

[imploder]

Instalování svatou trojicí je tak trochu prasárna, protože je to mimo balíkovací systém, závislosti si musím (nějak, občas není jasné jak) shánět sám, je možné, že to pak už nepůjde odinstalovat; nebo pak odinstaluju něco, co to potřebovalo. To už je lepší způsob instalace ve Windowsech.

[pavlix]

Instalování svatou trojicí je tak trochu prasárna

Je a není.

protože je to mimo balíkovací systém

Ona ta instalace svatou trojicí je i součást tvorby balíčků, jediný rozdíl je, že je někde db, která říká, který soubor patří kterému balíku.

závislosti si musím (nějak, občas není jasné jak) shánět sám

Momentálně používám několik knihoven v git verzích. Všechny závislosti jsem si sehnat dokázal. Obvykle prvně stáhnu závislosti, které jsou v README, a v ojedinělých případech doinstaluju závislosti, které zmíněny nebyly, po nepovedeném volání configure. Nestává se mi, že bych závislosti nesehnal (možná mám štěstí).

je možné, že to pak už nepůjde odinstalovat

To bych musel udělat nějaký hodně velký nesmysl, aby to nešlo jednoduše odinstalovat pomocí příkazu rm (make uninstall nepoužívám).

nebo pak odinstaluju něco, co to potřebovalo.

Chyby se stávají i těm nejlepším.

To už je lepší způsob instalace ve Windowsech.

Chmm, nemám pocit, že by instalace ze zdrojových kódů šla na windows nějak jednodušeji nebo lépe. A nemám pocit, že by na windows šel dobře instalovat software, který není pro danou verzi či skupinu verzí windows připravený.

A... těžko budeme srovnávat potřeby pro instalaci software na každou možnou kombinaci exemplářů z množiny linuxových distribucí a z množiny hardwarových platforem... a na druhé straně nějakou trojici či čtveřici verzí jedné řady operačního systému Microsoft Windows, na jedné architektuře (intel 32bit). Nedostatky v takové úvaze jsou doufám zřejmé.

[scolopes]

jediný rozdíl je, že je někde db, která říká, který soubor patří kterému balíku.

Ve FreeBSD jsou třeba v databázi i md5 soucty nainstalovanych souboru, coz muze byt dost podstatna informace...

Vsechno je to samozrejme otazka politiky nasazovani aplikaci, ale myslim, ze obecne je dobre pouzivat jeden zpusob (balickovani) a ne kombinovat dva zpusoby se zcela rozdilnymi nejen postupy, ale hlavne vystupy...

[imploder]

Ona ta instalace svatou trojicí je i součást tvorby balíčků, jediný rozdíl je, že je někde db, která říká, který soubor patří kterému balíku.

Dá se udělat balík tímto způsobem (checkinstall), ale není to úplně čisté řešení. Nemusí být (a nebývá) nutně dělaný takhle, pokud vím. Binární balík se musí někde zkompilovat, ale to jde klidně udělat v nějakém sandboxu, aby nemohl nic přepsat (rozhodně ne jako root).

To bych musel udělat nějaký hodně velký nesmysl, aby to nešlo jednoduše odinstalovat pomocí příkazu rm (make uninstall nepoužívám).

Pokud se všechno instaluje do jednoho adresáře a jinde make install nic nedělá, tak to takhle jednoduše jde. Běžné (a je to i výchozí nastavení svaté trojice) je ale v unixech instalovat tak, že se program rozprostře různě po adresářovém stromu (/usr/bin/..., /usr/share/..., /usr/lib/..., ...) - to se nedá tak jednoduše odstranit.

Jasně, Linuxy a UNIXy už vůbec nejsou navzájem binárně kompatibilní, v tom mají Windowsy výhodu. Pokud teda nabízím software na Linux nebo nějaký UNIX, tak bych měl nabízet balíky na jednotlivé verze. Prostě běžný uživatel chce funkční výrobek a ne něco kutit a admin taky radši nainstaluje binárku a nebude kompilovat, štelovat volby a sám to balit, když to nepotřebuje. U uzavřeného softwaru ani jiná možnost, než že výrobce dodá software už zkompilovaný, není. Ten rozpor v typickém přístupu k instalaci je docela zřejmý:

• Windows - nejnovější release (a obvykle i dřívější) je zkompilovaný, připravený k nainstalování na jakýkoliv Windows, aktualizace budou fungovat, pokud je aplikace podporuje (každá aplikace si to řeší sama)
• Linux/UNIX - zkompilované a připravené k instalaci a s funkčníma aktualizacema je jenom to, co zařadila do repozitáře mnou používaná distribuce nebo co jsem našel v jiném kompatibilním repozitáři (jen málo aplikací má vlastní); jinak můžu stáhnout zdrojáky a mořit se s (často z nějakého důvodu nefunkční) svatou trojicí, v lepším případě sehnat někde použítelný hotový balík

[Grunt]

Běžné (a je to i výchozí nastavení svaté trojice) je ale v unixech instalovat tak, že se program rozprostře různě po adresářovém stromu (/usr/bin/..., /usr/share/..., /usr/lib/..., ...) - to se nedá tak jednoduše odstranit.

Nechci do toho kecat, ale defaultní prefix je většinou /usr/local a smazat se dá všechno svatou trojicí prostým rm -r /usr/local/*. Takže zase lež jak Brno. Na ostatní lži ani nemám sílu reagovat.

[imploder]

Jaká lež? No tak je to /usr/local/něco místo /usr/něco. Ano, spletl jsem se, že je to u svaté trojice takhle, tomu jsem nevěnoval pozornost. Na principu to nic nemění.

[X]

Hlavni rozdil bych videl spis v tomhle:

Windows: staticky linkovano, popripade dynamicky, ale knihovny soucasti instalace

Linux: dynamicky linkovano

:)

[scolopes]

Já se rád nechám poučit, jak přesně postupy na Debianu vypadají, člověk nikdy neví, co se mu může hodit... :)

Tak rekneme, ze standardni balik mc je prelozeny s volbou --enable-vfs-smb, kterou nechci

FreeBSD:

Standardni instalace: # cd /usr/ports/misc/mc # make install clean ## jdu si uvarit kavu

Instalace s jinou volbou: # cd /usr/ports/misc/mc # sed -i '' 's|--enable-vfs-smb||' Makefile # make install clean ## jdu si uvarit kavu

(predpokladam, ze chci fakt jenom zmenit tuhle volbu a nic jinyho se tim nerozbije...)

Co *presne* musim tead udelat na Debianu, abych dosahl stejnyho efektu?

[scolopes]

Ach to formatovani... :)

Standardni instalace:

# cd /usr/ports/misc/mc 
# make install clean 
## jdu si uvarit kavu

Instalace s jinou volbou:

# cd /usr/ports/misc/mc 
# sed -i '' 's|--enable-vfs-smb||' Makefile 
# make install clean 
## jdu si uvarit kavu

[michich]

V Debianu z hlavy nevím, ale ve Fedoře by to bylo nějak takto:

$ fedpkg clone -a mc  # stáhne specfile a patche z Fedora git
$ cd mc
$ fedpkg switch-branch f14  # pokud chci buildit verzi z Fedory 14 a ne Rawhide
$ sed -i 's|--enable-vfs-smb||' mc.spec
$ fedpkg sources  # tohle by ideálně měl dělat následující příkaz sám :(
$ fedpkg mockbuild  # ... a čekáme

[scolopes]

Tak to je super, ze uz jsou na to takovy prijemny nastroje. Ja si pamatuju, ze za jakychsi drevnich dob jsem musel rucne stahnout SRPM, vybalit spec atd. Nebylo to nic prijemnyho.

[Grunt]

Osobně bych byl teda radši za SRMP.

[michich]

SRPM používat můžeš taky:

yumdownloader --source mc
rpm -ivh mc-*.src.rpm
cd ~/rpmbuild/SPECS
sed -i 's|--enable-vfs-smb||' mc.spec

A pak třeba:

yum-builddep mc
rpmbuild -bb mc.spec

nebo

rpmbuild -bs --nodeps mc.spec
mock -r fedora-14-x86_64 ../SRPMS/mc-*.src.rpm

[Grunt]

On má ten problém jediné jméno: GNU Autoconf. Dokonce už začali vznikat hnutí za jeho smrt.

[Stanislav Brabec]

Každá firma si může dělat cokoliv, nikdo jí nic nepřikazuje.

Když má někdo deset serverů, jejichž pád neohrožuje životy lidí ani nezpůsobí velké materiální škody, a k nim má schopného admina, tak si může dovolit nasadit necertifikované kombinace distribuce a softwaru třetích stran, a věřit, že jejich admin případné problémy vyřeší. Taková firma není cílovou skupinou enterprise distribucí.

Pokud si nechce platit schopného admina, pravděpodobně dá přednost hotovému a odladěnému řešení, za které ručí ona třetí strana, která software dodala. V tomto případě je cílovou skupinou enterprise distribucí většinou ona třetí firma, která dodá hotové řešení.

[dustin]

Dovoluji si upozornit, že jsem od začátku tohoto vlákna mluvil o desktopové distribuci. Na servery jsou kladené jiné požadavky a tam komerční long-term distribuce roky existují a daří se jim dobře.

Vypadlý desktop je v dnešních firmách věc zcela běžná a nikdo se nad tím nijak nepozastavuje. Domnívám se, že dostat "slowly rolling-updates" linuxovou distribuci do stavu dostačujícího pro firemní desktop je v týmu placených profíků zcela reálné.

[Stanislav Brabec]

Třeba prodejní terminál v hypermarketu, u okénka na poště, v bance, terminál telefonní operátorky, terminál operátora řízení letového provozu, to všechno jsou také desktopová distribuce, a pokud tam vypadlý desktop bude něco běžného, rychle s dodavatelem vyběhnou.

To, že v kancelářích (hlavně ve státních firmách) je vypadlý desktop příležitostí k dalšímu kafi, je jiná věc.

[dustin]

To jsou ale všechno případy jednoúčelových zařízení, skoro bych nazval embedded, které shodou okolností mají monitor. Zase požadavky podstatně jiné než na firemní desktop do kanceláře.

[Stanislav Brabec]

Pokud si firemní desktop do kanceláře definujete jako něco, kde je výpadek zcela běžný, a nikdo se nad tím nijak nepozastavuje, pak jistě ano.

Pokud však nastane situace, kdy zaměstnanec takové firmy musí říci: „Tak pane, ten milion si zase vezměte zpátky. Dnes vám nemohu nic prodat, nejede nám fakturační (skladový, produkční) desktop (v novém Firefoxu nám nefunguje intranet),“ vedení firmy většinou velmi rychle přehodnotí požadavky na své firemní IT a názor na slowly-rolling updates.

[imploder]

Překlad ze zdrojáků má dělat výrobce, ne to házet na uživatele. Možnost zkompilovat si to sám podle chuti je dobrá, ale neměla by to mít nutnost.

[M]

Překlad ze zdrojáků má dělat výrobce, ne to házet na uživatele.

To si ale pak uživatel nesmí stěžovat, že výrobce nepřeložil zrovna tu verzi, kterou on chce, chce, chce, s volbama, který chce chce chce...

Pokud uživatel chce svobodu, musí přijmout alespoň elementární zodpovědnost.

[Stanislav Brabec]

Pokud uživatel zaplatí, může od výrobce chtít cokoliv. Třeba může dostávat požadovaný balík na individuální objednávku, samozřejmě po provedení všech předepsaných testů a se zárukou bezpečnostních aktualizací po celou dobu životnosti distribuce. Kontrakt na podporu „one off“ balíků je ovšem hodně drahá legrace.

S tou zodpovědností jste trochu vedle. Představte si, že nová verze CUPS přinese drobnou změnu chování. Takovou, která se v dobře napsaných aplikacích neprojeví, ale ve špatně napsaných vede k pádu. A vy si půjdete stěžovat u podpory distributora, že vám začala nějaká aplikace najednou padat. A on udělá jediné. Požádá vás o konfiguraci systému, najde tam neotestovanou verzi CUPS a řekne vám, ať si to vyřešíte sám.

Pokud chcete uživatel svobodu, musí přijmout absolutní zodpovědnost za svůj systém. Pak je ovšem zbytečné, aby platil drahý enterprise systém, když si může se stejným výsledkem nainstalovat cokoliv.

[scolopes]

Pokud někdo platí podporu, tak by do toho neměl vrtat tak, aby o ni přišel, to je jasné.

Jenže existuje spousta firem, kterým "podporu" dělá jejich IT oddělení (případně externí IT, v extrémním případě jeden člověk s živnosťákem :). I to je "firemni prostredi", ne ze ne.

A v takovych situacich je proste idealni stav takovy, ze je distributorem dodana jakztak otestovana mnozina softwaru ("release") a IT oddeleni si samo lehce muze nasadit novejsi verze neceho, co je pro ne dulezite - cimz samozrejme za tu zmenu nese odpovednost.

[pavlix]

Pokud chcete uživatel svobodu, musí přijmout absolutní zodpovědnost za svůj systém. Pak je ovšem zbytečné, aby platil drahý enterprise systém, když si může se stejným výsledkem nainstalovat cokoliv.

Pokud rozbije systém samotný, tak máte pravdu, tedy alespoň v případě, že existuje odpovídající bezplatná alternativa.

Ale ty změny a ručně dokompilované systémy zdaleka jen záležitostí zásahu do core té distribuce. Proč by jinak vznikaly nadstavby jako například EPEL, že.

[Stanislav Brabec]

Samozřejmě. Tato diskuse ale začala nad tím, proč by se IT oddělení firmy nemohlo rozhodnout nasadit novou verzi CUPS, tedy balíčku, ležícím poměrně hluboko v základním systému.

[pavlix]

Proto jsem v reakci tak opatrný :). Enterprise zákazník by asi spíše tlačil na distributora, aby mu novou či změněnou verzi balíku CUPS dodal on.

[Grunt]

Tohle jde řešit poměrně jednoduše.Svoji verzi nacpat do /opt/cups, spustit a při prvním problému ho killnout a jako fallback zase spustit ten od distributora (a nikdo nemůže říct ani půl slova). Já to tak aspoň na svém domácím počítači dělám zcela běžně.

[dustin]

Jo, dovedl bych si představit takovou službu postavit na archem, čím čistší a blíž k upstreamu, tím snazší je to ustabilizovat :)

[Roger]

Ať to rovnou přejmenují na CUT :)

[Rovano]

http://www.omgubuntu.co.uk/2010/11/ubuntu-is-not-changing-to-a-rolling-release/