Žádný distributor Enterprise řešení nedodává poslední jádro, které je k dispozici (kromě "takyenterprise" distribucí, jako je např. Trustix), ale pracují se starším jádrem, které sami testují. Nikdo (rozumný) nepředpokládá, že "latest and greatest" půjde rovnou nasadit na počítač, který je v ostrém provozu. Tedy - jak je vidět - až na experty ze Seznamu. Nicméně za bugreporty děkujeme. Je to jejich příspěvek za to, že svůj byznys můžou dělat na systému, který je zadarmo.
V takovém případě si sednu a pokusím se o backport toho nového do vyzkoušeného jádra (distributoři to tak dělají také). Tím se dosáhne toho, že si nezavlečete do vychytaného jádra nějakou ptákárnu, kterou někdo vyplodil nad desátým kafem v pět ráno. A díky současnému modelu můžete relativně lehce z repozitáře jednotlivé změny vydolovat...
No kdybych backportoval nové plánovače, NPTL, jemnější periodu systémového časovače, podporu LBA64 pro disky nad 2TB, plus různé rošády frameworků okolo SCSI a SATA, co by mi z té 2.4ky zbylo? A jak by ten můj bastl byl asi stabilní?
Ano jistě, hodnotím tu možnost optikou svých vlastních schopností :-)
Viděl jsem tuším backport NPTL. Taky nějaké dílčí "RT" patche (teď nemluvím o řešeních založených na RT mikrokernelu, jako jsou RTAI nebo RTlinux).
Osobně mi s ohledem na pracnost přijde efektivnější podílet se na pilování systémového řešení, kterým je řada 2.6.
Že našli lidi od Seznamu chyby ve 2.6, to ještě neznamená, že jim na tom jelo něco zvlášť důležitého. Naopak bych řekl, že slibné cesty ke zvýšení výkonu a škálovatelnosti je třeba zkoumat. Poté co systém projde dostupnými syntetickými zátěžovými testy, zbývá bohužel jedině zkouška ohněm :-)
Ohledně stability jader 2.6:
vzpomenete si, která první verze jádra 2.4 byla rozumně použitelná a už se v ní nenašly žádné zásadní chyby co do stability při SMP provozu apod.? 2.4.21?
To jste zásadně nepochopil recyklaci už udělané práce (aka hlavní přínos GPL, odečteme-li politický balast RMS & spol). Tj. vezmu jádro od SUSE SLES nebo Red Hat Enterprise (tj. pro mou potřebu nejbližší - např. RHEL3 má 2.4 jádro s NTPL nebo RHEL4 má 2.6.9+ se SELinuxem) a do něj dostrkám JEDEN bonbónek, který mne trápí. Tím má zajištěno, že celek funguje statisícům (platících) klientů (za kterými stojí profesionální support team včetně třeba A. Coxe) a mohu se zaměřit jen na svoji drobnost. Pokud nemáte vlastní team 20 kernelhackerů, tak jiná cesta ani není možná (a ani rozumná, protože máme GPL a nenní potřeba vymýšlet kolo).
Jistě, že nikdo rozumný nepoužívá v ostrém provozu úplně poslední verze jádra. Otázka ale je, proč jsou tyto poslední verze označovány jako "stabilní", když stabilní nejsou. Proč je tedy nenechat trochu delší dobu jako vývojové, když to všichni "rozumní uživatelé" stejně automaticky předpokládají?
Mne se taky nelibi tento vyvojovy model. U 2.4 a nizsich
mohl clovek duverovat zkusenym vyvojarum Linuxu, ze do toho
nezanesou nejake necistoty, ale zkuste duverovat noname
programatorovi z nejake firmy dodavajici distribuci? Navic
pro ty firmy je stabilita tim poslednim, o co by se mely
starat --- na jednu serverovou instalaci jim pripadne 30
BFU, kteri jako hlavni rys distribuce hodnoti uzivatelskou
pritulnost instalacniho programu. Ani ten RHEL neni svatej,
treba do nejake sve 2.4 (nejspis diky pridavani
"enterprise-featur") zavlekli memory-leak, takze server po
case vycerpal pamet a spadnul.
V 2.4 se navic problemy z celeho sveta nahlasi vyvojarum
Linuxu a opravuji, v 2.6 si kazda distribuce opravi to, co
nahlasili jeji uzivatele, a problemy uzivatelu jinych
distribuci ji nezajimaji. Neni zadne centrum, kde by se
vyvijela stabilni verze zalozena na 2.6, do ktere by se
treba 2 roky nepridala zadna featura. (a to je jedina mozna
cesta, jak stability dosahnout) --- pokud nekdo namitne RHEL
--- ano, ale kolik procent uzivatelu ho pouziva ... 5%? ...
tak tam bude opraveno 5% chyb.
Vemte si ten obrovsky patch 2.6.11->2.6.12 (24MB rozbalenych)
a zkuste o kazde jeho zmene rozhodnout, zda je to oprava
zavazne padaci chyby (a do sveho distribucniho jadra byste
ji pustit meli) nebo novy featurismus s moznosti
pridavani chyb, ktery byste meli odmitnout. A tohle
rozhodnuti bude delat nejaky noname clovek placeny nejakou
firmou (=> jde mu spis o plat nez o reputaci) aniz by to
bylo verejne kontrolovano.
Je to skoda, ze to takhle pokazili. 2.6 bych se nedotkl,
ani Linusovy verze, ani verze z distribuce.
Nevim, jestli servery seznamu jsou opravdu tak moc vytizene,
ze by na 2.4 bezet nemohly...
Jenze 2.6.12 byl v Seznamu nasazen proto, ze vyresil chybu, o ktere nikdo netusil kde vezi. Proste s 2.6.9 to padalo (to=kernel, tj oops a poskozeny filesystem) a s 2.6.12 ne .... co bys nasadil ty ? 2.0.34 ?
Z tvrzeni: "I.L. si nedokaze predstavit, ze by provozoval servery s OS, ke kterym nema zdrojaky" a "12 serveru bezi na WindowsNT" usuzuji, ze I.L. ma zdrojove soubory k Windows NT. Nejaky nadstandardni vztah s MS?
nasel jste nekdo, jakymi patchi seznam prispel? At jsem hledal jak jsem hledal, nasel sem od pana M. Feixe sice nejakou aktivitu na LKML, ale tykala se spise DVB a jakehosi konfliktu v .h mezi jadrem a glibc/x.org. Ani jedno si nemyslim, ze by melo zpusobovat naznacene problemy seznamu.
Největší patch měnil skoro každý soubor a nahrazoval slova "Linus Torvalds" za "Ivo Lukačovič, otec cz internetu" v komentářích. Bez těchto úprav systém padal každých pět minut.
To asi neni normalni nasadit v teto dobe 2.6.12? To si netroufnu ani doma na desktopu. A uplne mi prijde vadny si na to v blogu stezovat. To je podobny pripadu, kdy bych na sobe nechal testovat nejnovejsi leky a pak si stezoval, ze je mi spatne. Rekl bych, ze je to zvyk z Woken, mit to posledni. Pan Lukacovic uz se urcite tesi na verzi 3.0.0.
Krasny den,
Pokud ma k dispozici tym lidi kteri dokazou chybu v kernelu najit, opravit a reportovat. Pak muzu klidne pouzivat posledni verzi, obzvlaste pokud opravuje chybi verzi starsich. (Vsimete si ze cela oprava trvala 1,5 hod)
Doporuceni nepouzivat posledni verze v ostrem provozu se spise vztahuje k uzivatelum kteri si stou chybou nedokazi(nechteji) poradit a to z ruznych duvodu.
Druha vec je ze IL si stezuje na neodladenost verze ktera je oznacena jako stabilni.