Jaderné noviny 284 - I

25. 11. 2004 | Robert Krátký

Články - Jaderné noviny 284 - I  

Linux 2.6.9; co je pravdy na tvrzeních SCO? Mohl by arch nahradit BitKeeper jako systém správy revizí jádra? Diskuze o vývojovém modelu řady 2.6.

Pozn. překladatele: Kernel Traffic 284 byl tak rozsáhlý, že jsem se rozhodl vydání Jaderných novin rozdělit do dvou částí. Bylo mi totiž líto vynechat některá ze zajímavých, avšak příliš dlouhých témat.

Do konference přišlo celkem 2980 emailů, nejvíce jich poslali Adrian Bunk, Ingo Molnar a Linus Torvalds.

Linux 2.6.9; co je pravdy na tvrzeních SCO?, 145 e-mailů

18. říj - 31. říj

Linus Torvalds oznámil Linux 2.6.9:

Přes zmatek v pojmenování (vysvětlení: jsem dement) jsem dnes nakonec vydal 2.6.9. A není stejný jako "-final" testovací vydání (viz vysvětlení výše).

Omluvy stranou, není tam moc změn oproti -rc4 (což byl poslední oznámený testovací kernel), hlavně pár UML aktualizací, které nemají vliv na nic dalšího. A dost jednořádkových oprav nebo oprav kvůli kompilátoru. Připojen celý seznam.

Jeff V. Merkey napsal:

Ačkoliv s nimi nepracujeme a jsme vlastně z konkurenčního hlediska na druhé straně Unixware, tak nás SCO kontaktovalo a do posledního detailu identifikovalo a fakticky zdokumentovalo kód a intelektuální vlastnictví v Linuxu, o kterém tvrdí, že bylo převzato z Unixu. Jejich tvrzení jsme prověřili a vypadá to, že dávají vzniknout pochybnostem dostatečným k odstranění dotyčných částí.

My jsme tyto části Linuxu, o kterých SCO tvrdí, že byly ukradeny z Unixu, identifikovali a odstranili z našich produktů. Jedná se o:

JFS, XFS, veškerou podporu SMP a RCU.

Dělají si nároky i na další části Linuxu, ale tato tvrzení už se nezdají být podpořena faktickými důkazy.

Mnoho, mnoho vývojářů jádra se mu buď vysmálo, uráželo ho nebo mu řeklo, že svůj kód nehodlají přelicencovat nebo odstraňovat části, o kterých tvrdil, že na ně má SCO nárok. Diskuze pokračovala všemi směry, Jeff rozdával a přijímal rány na mnoha frontách, dokonce chvíli debatoval s Alexandrem Viro v jazyku Cherokee.

Naprostá většina opakovala, že SCO nemá žádný legitimní nárok, a že Jeff je cvok. David Weinehall dokonce citoval písemný názor soudce Schoefielda:

Merkey ve skutečnosti nejen často přehání, ale i lže. Ne pouze svým nepřátelům, ale i svým obchodním partnerům a soudu. Cíleně popisuje svou vlastní, oddělenou skutečnost.

V jednu chvíli prohlásil Linus:

Mohli byste mi, prosím, přestat posílat kopie zpráv z tohoto vlákna?

Ne, nikdo, koho bych znal (a určitě ne já), není ochoten přelicencovat Linux pod něčím jiným než GPL. Abych řekl pravdu, myslím, že byste měli snazší to prostě celé přepsat.

A ne, jediná nabídka, která mě od SCO zajímá, je veřejná omluva od Darl McSvině. Jejich vymyšlené pohádky o vlastnictví copyrightu nebyly zábavné před rokem, ale teď už jsou úplně nudné a vyčpělé.

Takže mě prosím vás vynechte z CC? OK?

Poblíž řekl Ingo Molnar:

Jeffe, už více než jednou jsi dokázal, že žiješ ve fantastickém světě, který má své vlastní fyzikální zákony, etiku i zákony obecné. Ačkoliv se to zdá být nebezpečným fenoménem, naštěstí je velmi ojedinělý.

Linusovi záměrně a úmyslně lhali, špinili jej a říkali o něm zavádějící věci více než rok a půl. Linus nikoho neklamal, natožpak aby někomu lhal. Ta takzvaná "kontaminační" obvinění nejsou nic jiného než pouhá obvinění. Jednoduchá otázka: víš, co to znamená "pravda"? Další jednoduchá otázka: zajímá tě to vůbec? Ve světě, kde žiju já, dluží SCO více než jen prostou omluvu. Osobně mi připadá obdivuhodné, že jedinou věcí, kterou Linus od SCO očekává, je prostá omluva.

Mohl by arch nahradit BitKeeper jako systém správy revizí jádra?, 161 e-mailů

19. říj - 1. lis

Během diskuze prohlásil Andrea Arcangeli, že proprietární licence BitKeeperu má negativní vliv na schopnost Linuxu rozvíjet se. Měl pocit, že kdyby měli všichni vývojáři přístup ke správě revizí, byla by situace o mnoho lepší. Linus Torvalds reagoval:

Nikdo neví, jak by vesmír vypadal, kdyby rychlost světla nebyla konstatní.

Tvoje argumentace je zbytečná. Žádný takový distribuovaný systém správy revizí neexistuje. A bez BK by lidi, kteří na nich pracují, ani nechápali, co je špatného na CVS.

Vlastně zjišťuji, že lidi _pořád_ povětšinou neví, v čem je problém CVS. A pořád se snaží udělat jen něco dalšího, podobného CVS.

Takže projevte Larrymu uznání, které si zaslouží - i když se vám nelíbí ta licence.

Andrea poukázal na to, že existuje arch (tla) a je úplně stejně distribuovaný jako BK. Linus odpověděl:

A také jsem se na to díval, než jsem začal používat BK. Věř mi, nebylo to ani zdaleka tak použitelné - a o to mi šlo. Nic takového, co popisuješ, tři roky neexistovalo. Kromě BK.

Pochybuji, že by na to dnes arch měl, ale jestli nahradí CVS, určitě si nebudu stěžovat. Jak jsou na tom teď lidi od gcc?

Andrea odpověděl:

Lidi od gcc jsou, pokud vím, zaseknutí na CVS. Zjevně je pro ně CVS dostatečně dobré.

arch není připraven na přímé nasazení pro kernel. Bylo by to možné, pokud bychom jej omezili na řekněme 5000 changesetů a starší changesety by byly čas od času vyřazeny. Aby to zvládal, potřeboval by přepsat backend.

Díky různým vylepšením (já napsal pouze to, které umožňuje kešování natvrdo slinkovaných stromů, Chris a další udělali více) by arch byl již pravděpodobně při běžném zápisu a klonování o hodně rychlejší než BK (nikdo na open source straně to nemůže ověřit, protože nemůžeme používat BK; pokud vím, tak Miles se pokusil BK koupit, ale Larry odmítl prodat - ale silně pochybuji o tom, že BK by měl tak vyspělý mechanismus kešování pevných linků jako arch), ale první instalace na novém stroji by byla velmi neefektivní (v porovnání s CVS) a lokální kopie repozitáře by zabrala více místa (opět ve srovnání s CVS).

Uživatelské rozhraní také není moc dobré. Bylo by dobré se alespoň vyvarovat překrývání funkcí příkazů.

Jsem přesvědčen, že tohle všechno lze napravit. Je pouze potřeba velké množství uživatelů a překonání počátečních potíží.

Jeff Garzik připojil, že: arch není tak škálovatelný jako BK. Řekl jsem Larrymu, že kdyby byly BK a <open source nástroj> z hlediska funkčnosti rovnocenné, používal bych ten open source nástroj. Ale ani arch (škálovatelnost), ani Subversion (škálovatelnost + stabilita) k tomu ještě nedospěly.

Během celé diskuzi nedal Linus nikterak najevo, že by třeba jen uvažoval o něčem jiném než plné podpoře BitKeeperu. V jednu chvíli rozzlobeně napsal:

Andrea, buď zticha.

Nejde o tvé rozhodnutí. Ani si na to rozhodnutí nemáš co stěžovat. Bylo to rozhodnutí vývojářů. Mé, Jeffa, David, Andrewa... Ne tvé.

Tvým rozhodnutím je nepoužívat BK. Fajn. Ale když si pak stěžuješ, že se lidi rozhodli používat nejlepší dostupný nástroj, to je neslušné. Ne jen k Larrymu, ale i k lidem, kteří to rozhodnutí učinili.

Kňouráš, že ti BK upírá tvá práva, ale skutečnost je taková, že BK je možnost, kterou mohou lidí využít. To TY se snažíš ostatní omezit v tom, co dělají.

Je to prosté: BK není problém, ty jsi problém.

O několik zpráv níže Linus řekl: Andrea nedělá ohledně SCM [Source Code Management = správa zdrojového kódu] nic konstruktivního. Jen si stěžuje pokaždé, když někdo řekne něco kladného o produktu, který a) se od něj ničeho nedočkal, b) jej nikdo nenutí používat, a c) dnes nemá žádné skutečné alternativy (natožpak před třemi lety). Ve stejné zprávě ještě dodal:

Žádný SCM nikdy nebude správcem kvality.

A zároveň tvrdím, že lidé, kteří si myslím, že "procesy" představují kvalitní správu (viz iso9000 nebo Dilbert), se velmi pletou.

Obecnou kvalitu udržují lidé. Správní lidé, kteří jsou na kvalitu pyšní. Nakonec se z nich stávají správci - ne protože by si tu práci zvolili, ale protože si je ostatní vybrali.

A pomoci lze těmto lidem tím, že jim usnadníte každodenní práci, takže budou moci věnovat co nejvíce času tomu, na čem záleží: udržování dobrého vkusu (a při té příležitosti udržování vysoké kvality). A tehdy přichází na scénu SCM - ne coby primární zdroj kvality, ale coby způsob sledování detailů, aby se lidi mohli soustředit na to, co je důležité.

A SCM nemusí být nic fešného. Může to být pár skriptů sledujících patche (skripty mají tendenci narůstat a stávají se během času sofistikovanějšími). Neříkám, že BK je "to" pravé. Je dost uživatelů BK, ale zjevně jsou i jiné způsoby správy patchů - a lidé je používají.

Ale stěžovat si, že vývojář používá nástroj, který mu vyhovuje, to je pitomé. Myslet si, že mi můžeš říkat, jak mám dělat svou práci, to je arogantní. Ale je to opravdu hloupé, když mi nedokážeš nabídnout žádné rozumné alternativy, které by mi pomáhaly stejně efektivně.

A přesně to Andrea dělá. Jistě, BK je komerční, ale krucinál, to je i ten 2GHz duální G5 v rohu pokoje. Prostě jsou to nástroje, které používám ke své práci. Kdyby mi Andrea řekl, že mám používat pomalejší stroj proto, že jej používají i ostatní, pomyslel bych si, že je totální idiot. Analogicky mi připadá stupidní stížnost na používání softwarových nástrojů, které lidem jasně pomáhají k větší produktivitě.

Jsou i jiné nástroje, které používám, a díky kterým mohu pracovat produktivněji. Mnohé z nich jsou open source. Některé jsem napsal sám. Ale i tak jsou součástí sady mých nástrojů například "uemacs" a "pine". A pokud si dobře pamatuji, ty také nejsou open source (i když jsem slyšel, že autorovi uemacs už je to jedno, takže by mohl být přelicencován).

Měl bych (nebo kdokoliv jiný) čekat na Andreovo svolení než začnu používat ne-open source nástroje? Ne. Kdyby si Andrea stěžoval na to, že používám "pine", všichni by se mu vysmáli. Možná je příšerně zpátečnický a starý a pouze textový, ale faktem zůstává, že Andreovi do toho vůbec nic není - i když je to z hlaviček poznat na každém emailu, který napíšu.

Andrea také při pohledu na tarbally a patche vidí některé následky toho, že používám BK - syntaktické značky, které dokazují, že byly generovány někým, kdo používá BK. V ničem se to neliší od skutečnosti, že pro komunikaci používám pine. A ne, ani BK, ani pine nemají open source licenci - smiř se s tím.

Může mi Andrea představit open source nástroje a slušně se zeptat, jestli bych je zvážil coby alternativy? Jasně, že jo. Budu rád, když to udělá, až se něco objeví.

Miles opravil Linusovo tvrzení, že Andrea nedělá nic konstruktivního: To není pravda. Andrea v konferenci gnu-arch poskytl několik velmi užitečných postřehů. Rozhodně si jen nestěžuje na BK. Roman Zippel Linusovi napsal: Nikomu nezáleží na tom, co používáš v soukromí. Ale tvá rozhodnutí jako správce jádra lidi ovlivňují - ať už jde o patche, které zařadíš do dalšího vydání, nebo nástroje, které k tomu použiješ. Konec konců je jen na tobě, jaké nástroje použiješ, myslíš-li si, že jejich výhody převáží licenci, která jde proti procesu otevřeného vývoje. To je v pořádku. Ale stejně tak je v pořádku, když s takovým rozhodnutím ostatní nesouhlasí. Možná bys mohl navrhnout způsob, jak takové požadavky formulovat. Linusi, vadí mi na tom, že ani slovem nezmiňuješ licenci BK. Není to tak, že by BK někdo nenáviděl, to je mýtus, který bych čekal od Larryho, ale ne od tebe. BK je docela nevinný a určitě užitečný nástroj. Protivné jsou obchodní praktiky jeho majitele, který se snaží protlačit svou licenci do prostředí, kde bude zákonitě odmítána. Linus odpověděl:

Nesedí ti, nepoužívej. Tak je to prosté.

Je to stejné jako s GPL. Naprosto nesnáším lidi, kteří fňukají kvůli GPL - a těch, kteří nenávidí GPL, je víc než těch, kteří nenávidí BK. Jejich problém.

ÚPLNĚ STEJNÁ VĚC. Nikdo nemá právo stěžovat si na licenci, kterou si zvolí někdo jiný. Máte na výběr: používejte, nebo nepoužívejte. Stěžovat si na licenci autorovi, to k tomu nepatří.

Larry může potvrdit, že jsme licenci BK soukromě probírali, a také bezpochyby ví, že bych byl radši, kdyby byla open source. Ale mám pocit, že by vám Larry řekl, že jsi si nestěžoval. Snažil jsem se navrhnout řešení, které by mu mohlo vyhovovat - s ohledem na to, že má zaměstnance, o které se musí starat, jsem nebyl schopen vymyslet nic, co by ho přesvědčilo. Co se dá dělat.

Protože jde o jeho rozhodnutí. Ne moje. Ne tvoje. Ne Andreovo.

A zatraceně, to rozhodnutí je tak blízko k "posvátnému", jak jen něco může ve světě vývoje software být.

Abych parafrázoval Voltaira - "Možná nesouhlasím s tvým výběrem licence, ale i kdyby mě to stálo život, budu bránit tvé právo si ji vybrat." To se týká Larryho a lidí od BSD a všech dalších, kteří se živí psaním softwaru a používají při tom nepěkné licence.

A totéž platí pro uživatele. Kdokoliv mi řekne, že nemohu používat program, protože není open source, může jít políbit záď RMS. Nezájem. 99 % toho, co používám, je open source, ale to je mé rozhodnutí, kruci.

Flamování pokračovalo a pokračovalo...

Diskuze o vývojovém modelu řady 2.6, 121 e-mailů

22. říj - 29. říj

Espen Fjellvær Olsen nesouhlasil s celým směřováním vývojového modelu Linuxu a řady 2.6; řekl, že místo přidávání nových funkcí by měl být 2.6 zmražen a začleňovány by měly být jen bezpečnostní opravy. Dodal, že pro přidávání nových vlastností by měla být vytvořena větev 2.7. Clemens Schwaighofer souhlasil, ale William Lee Irwin se vyjádřil, že lidi by se místo dohadování o číslech verzí měli spíše věnovat skutečné práci na jádře. A Lee Revell připojil:

Částečným důvodem pro nový vývojový model je to, že chceš-li stabilní jádro, existuje mnoho distributorů, kteří jej poskytnou. Nový model prosazují prodejci a vývojáři, kteří chtějí dostat do hlavního stromu rychleji své funkce. Přináší to s sebou sice určitou daň stabilitě, ale tou trpí pouze ti, kteří chtějí jak stabilitu, tak i nejnovější jádro z kernel.org. Velké ryby se povětšinou shodují v tom, že nový model lépe vyhovuje uživatelům i jim. Distribuce mají stejně lepší pozici k posuzování toho, co vlastně představuje stabilní jádro - mají milióny uživatelů, na kterých mohou testovat. Nechme jak distributory, tak i hackery jádra dělat to, v čem jsou nejlepší.

Potřebujeme pokračovat v rychlém tempu vývoje, protože i když Linux vévodí oblasti malých a středních serverů, jsou i jiné, kde jsou MS a Apple zjevně napřed. Když chceš dělat omeletu, musíš rozbít pár vajíček...

Na jiném místě Hua Zhong poznamenal: Skutečnost je taková, že dneska už nikdo nechce být správcem stabilní řady. Je to nuda. Ale Diego Calleja oponoval: To pochybuji. Lidi jako Alan Cox nebo Marcello to dříve dělali a vsadím se, že mnoho jiných by to mohlo dělat. Poblíž Hua trval na tom, že žádný špičkový vývojář by na sebe nevzal správu stabilního 2.6 stromu, ale Alan odpověděl: Kdyby Linus chtěl, dělal bych to..

Adrian Bunk k tomu napsal: 2.6 je teď více vývojové než stabilní jádro. A dodal: Andrew a Linus by měli brzy vytvořit krátkodobou větev 2.7 a Andrew (nebo někdo jiný) by měl 2.6 spravovat s méně změnami (jako to dělá Marcelo s 2.4).

Willy Tarreau se přidal: Linux už získal reputaci stabilního systému díky svým produkčním jádrům 2.0, 2.2 a 2.4, která byla široce nasazována v citlivých prostředích. 2.6 je dostatečně stabilní pro většinu použití na desktopu a distribuce pro koncové uživatele jej zařazují jako výchozí. To dodává mnoha lidem odvahu k otestování a posílání zpráv o chybách, takže jednou bude konečně možné jej stabilizovat a používat v ostrém provozu. Zprvu jsem nebyl nadšený tím, že bylo prohlášené za "stabilní" trochu moc brzo. Ale teď, soudě podle počtu lidí, kteří jej používají jen proto, že ho jejich distribuce dodává, si uvědomuji, že mělo být naopak prohlášeno za stabilní ještě dříve, takže všechny chyby, které se teď objevují, už mohly být opraveny.

Obecně se vývojáři bližší k vývojovému procesu přikláněli k zachování statu qua, kdežto vývojáři bližší k uživatelům chtěli změnu. Linus nekomentoval, ale Alan se několikrát nabídl s tím, že bych byl ochoten stabilní 2.6 strom spravovat.

---

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

Diskuse k tomuto článku

[Lukáš Zapletal]

Já myslím, že Larry dělá ty licenční naschvály úplně z prostého důvodu -- aby se o BitKeeperu co nejvíc mluvilo. Když je to tak dobrý produkt (jako že asi je), pak mu to může jen prospět.

Dělá to naschvál...

[Robert Krátký]

Konkrétně z tohoto případu mám dojem, že s tím Larry neměl nic společného. Andrea si začal stěžovat... Ostatně, i kdyby to bylo jak říkáš, pochybuji, že by urputným setrváváním na současné licenci získal větší reklamu než náhlým otevřením.

[Leoš Literák]

a jeste vice by se pak o nem hovorilo, az by zkrachoval ..

[skim]

Nechapu proc by to mel delat "Naschval"? A co vlastne?

Doporucuji precist treba toto: http://kerneltrap.org/node.php?id=222

Tam se vsechno pomerne jasne vysvetluje a zbytek jsou jenom zbytecne reci. Od te doby, co to interview bylo vedeno, se prakticky nic nezmenilo.

[Linear]

Zajimave je ze se nikdo nezminuje o darcs jako alternative cvs/bk. Dnes vysel na /. zajimavy interview s tvurcem darcs-u. Dival jsem se do manualu a vypada to velmi dobre. Nemate nekdo prakticke zkusenosti z provozu?

[skim]

To je porad dokola. Projektu, ktere se o neco podobneho jako BK snazi je spousta.

Dalsi projekt treba: http://www.venge.net/monotone/

Ja nechapu, proc se porad o tom dokola mluvi. Dokud se jakykoliv system neodzkousi tak, aby byl bezproblemovy chod, tak neni o cem se bavit. A BK byl odzkousen a nasazen.

[Lienar]

Nevim presne na co reagujes ("to je porad dokola"). Ve svem prispevku jsem napsal ze se mi podle dokumentace zda byt darcs velmi dobry program a ptam se zda nekdo nema prakticke zkusenosti. Take bych uvital odkaz na nejakou recenzi ktera porovnava vlastnosti BK/SVN/arch/monotone/darcs.

[Ondra]

A co je vlastne na CVS spatneho?

[Michal Čihař]

Spousta, viz třeba Better SCM Initiative, je tam i porovnání, které někdo výše chtěl...

[David Jež]

Na cvs v podstate neni nic spatne, jen se proste na spravu Linuxoveho jadra nehodi. Precti si Linusovy maily a lkml par let zpatky, probira se to vpodtstate porad. Lepe receno, pokud uz se to konecne prestane probirat, tak si Andrea rypne. To je proste folklor... Takze bavit co je spatneho nebo neni na cvs/arch/...(dosad tunu dalsich programu)/ nema vubec smysl. Nad podobnyma zpravama z lkml se zasmej a ignoruj. Pro sve pouziti si pouzivej co chces, co ti bude vyhovhovat. Ale Linus i dalsi uz myslim hodnekrat vysvetlovali, proc se pro spravu jadra neda nic jineho nez BK pouzit.
-djz

[Pavel Janousek]

No je fakt, ze je cokoli lepsiho nez Linusuv mailbox, ktery obcas radne promazal aniz by se zabyval jeho obsahem... (a o neexistenci (pred tremi lety) komercnich SCM pripadne komplexnejsich systemu si dovolim silne pochybovat... - ale je fakt, ze pred tou dobou to nebylo pro vyrobce tak sexy aby zdarma sponzoroval pouziti tohoto nastroje pro vyvoj Linux kernelu)

Mne naopak zaujala zminka o nestabilite Subversion, vzhledem k tomu, ze ji jiz nekolik tydnu hackuju jsem na nic takoveho nenarazil a ani pri ruznych hledanich via Google mne nic neuchvatilo, co by se tykalo verze 1.1.1 pripadne 1.1.2... muze mne nekdo nakopnout?

Naopak z jiz zmineneho odkazu na http://better-scm.berlios.de/subversion/ mne zaujalo predevsim Subversion has a very modular and algorithmically-sane design... Its code is of high quality and there are strict coding conventions. All in all it is a very professional product. a dle mych zkusenosti se s tim mohu velmi ztotoznit...

[Leoš Literák]

treba nemoznost prejmenovat soubor, to me pekne stve

[egg]

Nebo více repository pro vývojáře, kteří jsou offline. Ale třeba tyhle dva zásadní problémy jsme v projektu vyřešili přechodem na arch.