Názory k článku
Vypnutí AMD fTPM v generátoru náhodných čísel odhalilo chybu v TPM Intelu a narušilo S3 STR, oprava míří do Linuxu 6.6

Problém je, že to děláme na HW pro který to pak je určené, takže spousta chyb se nemusí ukázat a fTPM ve firemních světě prostě nepoužíváme

To je právě ono, většina těch, kdo testuje pre-release verze, jsou buď vývojáři nebo větší firmy a každý to testuje hlavně "u sebe" (nebo "pro sebe"), což znamená dost specifický hardware a konfigurace.

skoro nikdo to nezkusil použít na fTPM, tomu se divím, mohl to udělat aspoň autor těch změn

Tomu, že to neotestoval autor, se v tomhle konkrétním případě až tak moc nedivím, takhle zvenku to vypadá jako typická "obviously correct" situace, IMHO to prostě bral jako změnu, která se těch konfigurací neměla dotknout vůbec, takže nebyl důvod ji testovat.

A jak to děláš ty?

Když člověk s tím nedělá nějak větší vývoj a je pouze uživatel, tak je logické to testovat hlavně pro sebe. Tím, že každý to má trochu jinak, tak tenhle přístup může přinést potřebnou zpětnou vazbu.

Snažím se do open source přispívat, stejně tak táhnu i kolegy, ale prostě používáme daleko více open source projektů než do kterých jsme reálně schopní přispívat.

Dříve jsme zkoušeli buildovat i pre RC sestavení, ale je tam tolik už nízkoúrovňových věcí, změn, chyb, že to pro nás bylo těžké spravovat a hlavně relevantně reportovat.

A jak to děláš ty?

Tak, jak tu píšeme: na jednom stroji běžím na vývojových verzích jádra, typicky všechny rc a obvykle i pár snapshotů během merge window. Ale to je především kvůli tomu, že mám na starosti větev master v (open)SUSE, takže se ve vlastním zájmu snažím odchytit co nejdřív problémy, na které bych jinak stejně narazil o něco později.

Aby nedošlo k nedorozumění: je mi jasné, že to tak nemůže dělat každý, většina uživatelů má jinou práci než testovat vývojová jádra a analyzovat problémy tak, aby se daly efektivně opravit, to je všechno dost časově náročné. Chtěl jsem poukázat na to, že i když u mnoha chyb, které vydrží až do final, může vypadat na první pohled neuvěřitelně, že na ně nikdo při testování nenarazil, ve skutečnosti to vlastně vůbec překvapivé není. Problém je právě v tom, že rc verze ve skutečnost testuje jen hodně málo uživatelů a navíc jsou to až na výjimky uživatelé dost specifičtí (vývojáři, velké firmy, automatizované testy), takže pokud se chyba takových uživatelů nedotkne, je naopak logické, že se na ni přijde až po final, kdy se jádro začne používat na mnohonásobně širším okruhu systémů.

ale tak to máš také jeden specifický HW, není to hodně podobné?

Ten extrémně rychlý vývoj je u linuxu občas na škodu, vždyť ani ve firmě nestíháme to zkoumat podrobně a hledáme jen regrese ve funkčnosti a performance, to je dost málo.

ale tak to máš také jeden specifický HW, není to hodně podobné?

Spíš přesně totéž. Jak jsem se snažil vysvětlit, nechci kritizovat ten stav, ten je vzhledem k okolnostem víceméně nevyhnutelný. Spíš se pokouším uvádět na pravou míru nereálná očekávání.

Ten extrémně rychlý vývoj je u linuxu občas na škodu, vždyť ani ve firmě nestíháme to zkoumat podrobně a hledáme jen regrese ve funkčnosti a performance, to je dost málo.

To je věčný problém, že představa uživatelů je velmi jednoduchá: "bleeding edge and rock stable". Je potřeba si připustit, že oboje najednou dost dobře nejde a že pokud chcete minimalizovat riziko regresí, mainline jádra (a v současném modelu ani stable) nejsou ta pravá volba.

"Tomu, že to neotestoval autor, se v tomhle konkrétním případě až tak moc nedivím"

Ja teda nevim, asi tomu nerozumim, ale po tech letech v IT vim, ze cokoli muze ovlivnit cokoli. Jakakoli nepartna zmena, i zcela "nesouvisejici" s dotcenym systemem.

A jak to delam? Kdyz neco zmenim, tak alespon upozornim vsechny kolem, ze doslo k nejake zmene, at si to na svych systemech testnou. Mockrat se mi stalo, ze se mi pak vratil report na tema ono to dela to ci ono, a pritom to prece nijak nesouvisi. Nacez se zjistilo, ze souvisi.

Pricemz naprosto typicky zdaleka nejcastesi problemy jsou prave se znenama, ktery prece nic rozbit nemuzou.

Kdyz neco zmenim, tak alespon upozornim vsechny kolem, ze doslo k nejake zmene, at si to na svych systemech testnou.

Tak nevím… bavíme se ještě pořád o linuxovém jádře, tedy projektu používaném miliony uživatelů na ještě více systémech s velmi odlišným způsobem používání, roztodivným hardwarem (včetně různých architektur), kam každých 9-10 týdnů přibude během merge window něco přes 10000 commitů (aka "něco jsem změnil") a další pak ve zbytku cyklu (oprava chyby může přinést regresi úplně stejně)? Kdybyste chtěl všechny potenciálně dotčené kvůli každé jednotlivé změně přímo kontaktovat, skončíte nejspíš rychle na blacklistu, protože na takovou smršť nebudou zvědaví. A co se týká výzvy "ať si to na svých systémech testnou", doporučuji přečíst si pár mailů, kterými Linus oznamuje nové rc, konkrétně co tam na konci (téměř?) nikdy nezapomene napsat.

Bavime se tu o jadre, kde bych testovani na tisicich, spis desitkach tisic ruznych platforem a konfiguraci cekal bydefault.

jadre, kde bych testovani na tisicich, spis desitkach tisic ruznych platforem a konfiguraci cekal bydefault

U enterprise distribucí se testuje velmi důkladně, ale cenou za to holt je, že se obvykle používá základní verze jádra, která je už v době vydání asi tři čtvrtě roku stará. A ani tam není šance otestovat tisíce nebo dokonce desetitisíce různých konfigurací. U upstreamu je pak taková představa zcela mimo realitu, jak časově, tak ekonomicky.