systemd 221

Lennart Poettering oznámil vydání verze 221 správce systému a služeb systemd. Verze 221 vyšla necelý měsíc od vydání verze 220 (zprávička). Vývoj systemd byl mezitím přesunut z freedesktop.org na GitHub (zprávička). Jedná se především o opravnou verzi. Přináší ale také nové vlastnosti a vylepšení. API sd-bus.h a sd-event.h bylo prohlášeno za stabilní, podrobnosti v příspěvku na blogu. Vypnutí podpory kdbus při překladu již není podporováno, podpora chkconfig (--enable-chkconfig) byla odstraněna, ...

20.6.2015 12:13 | Ladislav Hagara | Nová verze

Komentáře

[asdfdsaf2]

A uz tam jsou? Kdo? No prece bulanci...

[Michal Kubeček]

Vypnutí podpory kdbus při překladu již není podporováno

To je dost hloupé i jako vtip…

[Ouser]

Hloupější (pro a proti) názor bych od vás nečekal...

[mankind_boost]

Hloupější reakci od tebe jsem vcelku čekal...

[Bedňa]

Tak Linux enviroment je zatiaľ dosť slobodný aby si mohol používať čo chceš. Lenart sa nijak netají s tým že chce z "roztriešteného" linuxového sveta spraviť jednotný nástroj a o kdbus písal minimálne jeden blog.

Siahni po inom inite a nerieš to.

[Clock]

Jenže SUSE je součástí systemd konspirace.

[Bedňa]

SUSE je enterprise distribúcia, takže priania užívateľa sú až na poslednom mieste :)

[Clock]

Kubeček je vývojář, ne uživatel.

[pavlix]

A nejsou u komerční distribuce přání vývojářů až za přáními uživatelů? :)

[Josef Kufner]

Řekl bych, že na prvním místě budou přání správců.

U přání programátorů je potřeba rozlišovat, zda je tvůrce distribuce platí, nebo ne. Ti neplacení si budou programovat podle nálady a jejich problémů, které potřebují vyřešit. A distribuci nezbude, než se s tím nějak vypořádat, například zaplacením dalších vývojářů, kteří budou ďělat i něco, co by jen tak sami od sebe nedělali.

[Bedňa]

Na toto som v komentári fakt zabudol :)

[Michal Kubeček]

Dobře, tak to rozepíšu. Zatím má kdbus za sebou jeden pokus o merge a ten skončil pořádnou ostudou v okamžiku, kdy se z jeho autorů konečně podařilo vytáhnout nějaký benchmark a profiler ukázal, že celý argument o tom, že D-Bus musí do jádra, protože ho brzdí context switche, je úplně mimo realitu. Kromě toho jsou pořád silné výhrady ke koncepci předávání všemožných metadat pro účely autorizace a vývojáři nesdílejí ani přesvědčení autorů, že je v pořádku smíchat IPC mechanismus a D-Bus protokol do jednoho nedělitelného klubka a zadrátovat jako interface na věky věků. Takže zatím to vypadá spíš na "zpátky k rýsovacím prknům" než na brzké začlenění do mainline.

Přejít v takové situaci se systemd na kdbus-only režim je buď ignorování reality (jako by Lennart Poettering četl jen Gregovo shrnutí "drobné problémy se zamykáním jsme vyřešili a jiné technické připomínky nezazněly") nebo pokus o dost nechutný nátlak na vývojáře z pozice síly.

[Bedňa]

Ja stále verím, že Linus a Ted budú zastávať doterajší postoj, že nech si každý okolo robí čo chce, ale nech to nechce nacpať do jadra.

[Spike]

OLOL

[little.owl]

To vypada, ze je uz po vsem.

[Michal Kubeček]

Až tak černě bych to neviděl. Ale je na tom zarážející (a možná i alarmující), že Linus má podle všeho pořád bezmeznou důvěru v Grega coby reviewera a maintainera (což ostatně potvrdil i v tom nedávném rozhovoru).

[Spike]

Nevím, proč mi v mysli vytanulo… Se stim smiř!

[little.owl]

Nevim jestli bezmeznou, ale s ohledem na Gregovu minulost pri vyvoji kernelu celkem chapu, ze mu duveruje. Ztotoznuji se spise s nazorem dalsiho veterana, Ingo Molnara, zde, treba:

In its current form kdbus really does not hurt the core kernel in any appreciable way: like Android's Binder it sits in its own corner that doesn't hurt anyone.
...
Beyond some vague opportunity cost kdbus is almost zero-cost for the kernel.
...
So there exists a technical vacuum: the kernel does not have any good, modern IPC ABI at the moment that distros can rely on as a 'golden standard'.

Pamatuji si na situaci, kdy byl akceptovan Android Binder, ktery je IMHO technicky problematictejsi a takovy povyk kvuli tomu nebyl - coz mi dava dobry duvod si myslet, ze namitky proti jsou spise motivovany skutecnosti, ze systemd je jeden z uzivatelu a protagonistu kdbus.

[pavlix]

ze systemd je jeden z uzivatelu a protagonistu kdbus

A ti ostatní?

[Michal Kubeček]

Nevim jestli bezmeznou, ale s ohledem na Gregovu minulost pri vyvoji kernelu celkem chapu, ze mu duveruje.

Stačí se podívat, jaké patche se běžně dostávají do stable updatů, aby to vzbudilo přinejmenším vážné pochybnosti o tom, nakolik je Greg zárukou, že co pošle dál, je dostatečně důvěryhodné.

Ztotoznuji se spise s nazorem dalsiho veterana, Ingo Molnara, zde, treba

Ten mail jsem četl včera ráno a okamžitě mi došlo, že v rozporu s tím, co tvrdí na začátku, vlastně neobsahuje naprosto žádný argument, proč by kdbus měl být přijat, ale jen argumenty, proč by to nemusela být úplná katastrofa.

Pamatuji si na situaci, kdy byl akceptovan Android Binder, ktery je IMHO technicky problematictejsi a takovy povyk kvuli tomu nebyl

IMHO to bude tím, že jakkoli je binder stejná hrůza jako kdbus, ne-li větší, je to něco, o čem lze předpokládat, že to stejně nikdo příčetný mimo android používat nebude. Jestliže na kdbusu bude záviset systemd - a zatím vše nasvědčuje tomu, že je jen otázka času, kdy na něm bude záviset natvrdo - bude kdbus klíčovou komponentou výrazné většiny linuxových instalací. To je úplně jiná situace a přijde mi logické, že adekvátně tomu je větší i odpor proti tomu, aby byl začleněn kdbus v současné podobě.

[little.owl]

Stačí se podívat, jaké patche se běžně dostávají do stable updatů, aby to vzbudilo přinejmenším vážné pochybnosti o tom, nakolik je Greg zárukou, že co pošle dál, je dostatečně důvěryhodné.

To je hodne o organizaci jadra vyvojaru a celem rozhodovacim procesu, nemyslim si soucasny model je dlouhodobe udrzitelny.

ale jen argumenty, proč by to nemusela být úplná katastrofa.

Ano, ale o to jde. Ten modul je z hlediska kernelu maly, izolovany, neskodny a volitelny, a nejvetsi dopady bude mit na SW, ktery se ho dobrovolne rozhodne pouzit.

IMHO to bude tím, že jakkoli je binder stejná hrůza jako kdbus, ne-li větší, je to něco, o čem lze předpokládat, že to stejně nikdo příčetný mimo android používat nebude.

Takze kod, na kterem stoji nejuspesnejsi Linuxova platforma v jeho historii, ktery pouzivaji ve svych zarizenich stovky milionu uzivatelu, zaclenime do kernelu bez vetsich starosti o technicke kvality.

Jestliže na kdbusu bude záviset systemd - a zatím vše nasvědčuje tomu, že je jen otázka času, kdy na něm bude záviset natvrdo - bude kdbus klíčovou komponentou výrazné většiny linuxových instalací.

To je bogus. Podstatene je jak bude fungovat systemd, ktery je schopen jakoukoliv kernel implementaci kdbus odstinit.

To je úplně jiná situace a přijde mi logické, že adekvátně tomu je větší i odpor proti tomu, aby byl začleněn kdbus v současné podobě.

Greg zacal pracovat na kdbus v lednu/unoru 2013, tedy pred dvema roky, za tri mesice mel zakladni koncepci. Kod byl k dispozici na GitHub. V podstate od pocatku byl otevren diskuzi, nekdy v polovine roku 2013 dostaval feedback od lidi z IVI, a jak je jeho zvykem, nikoho neposilal do haje. Pokud mel nekdo zakladni pripominky k jeho reseni, respektive zajem po letech diskuze a marnych pokusu s IPC skutecne neco delat, mohl se ozvat a aktivne zapojit. Nemyslim si ze v soucasne dobe je na stole lepsi alternativni navrh ci design, a kdbus rozhodne nedela soucasnou situaci horsi, presne naopak, v podstate se jedna o overeny a pouzivany design.

[Michal Kubeček]

Pokud mel nekdo zakladni pripominky k jeho reseni, respektive zajem po letech diskuze a marnych pokusu s IPC skutecne neco delat, mohl se ozvat a aktivne zapojit.

Přijde mi celkem logické, že dokud se jedná o projekt, který si někdo vystaví na Githubu, vyjadřuje se k němu jen ten, kdo se na něm hodlá aktivně podílet nebo ho aspoň (přímo) využívat. Ale ve chvíli, kdy se pošle pull request, je situace úplně jiná. Ne, tuhle argumentaci metodou "dělali jsme na tom dva roky mimo strom, takže to teď musíte vzít, jak to je, jestli se vám něco nelíbí, měli jste to říct dřív" absolutně neberu.

kdbus rozhodne nedela soucasnou situaci horsi

Dělá, protože pokud projde userspace API v současné podobě, už s ním nepůjde hnout - nebo jen zatraceně obtížně.

[little.owl]

Ale ve chvíli, kdy se pošle pull request, je situace úplně jiná.

Konecne slovo ma Linus, ne ... ?

Ne, tuhle argumentaci metodou "dělali jsme na tom dva roky mimo strom, takže to teď musíte vzít, jak to je, jestli se vám něco nelíbí, měli jste to říct dřív" absolutně neberu.

Ne, to ne. Jinak: pokud ma najednou tolik lidi skutecne uprimny zajem s IPC neco delat, o cemz celkove pochybuji, bylo by efektivnejsi s tim prijit za GKH drive, kdyz to zacal davat pred dvema lety dohromady, zejmena v situaci kdy maloktera featura kernelu byla tolik verejne sledovana.

Kernel code review je dobra vec, a jsou tam vyhrady majici realny zaklad. Ale nejsou IMHO natolik zasadni, aby se to dalo cele splachnout, bez dohledne alternativy, nehlede k tomu ze podle vseho nikdo poradne nevi jak ma toto idealni reseni vubec vypadat.

už s ním nepůjde hnout - nebo jen zatraceně obtížně.

To bezesporu. Nicmene diky izolovanosti modulu, ktery neni invazivni, podle vseho [zatim] s nizkymi "naklady" na udrzbu, a pritom s osvedcenou, uz deset let pouzivanou koncepci, riziko neni tak velke.

[Michal Kubeček]

Konecne slovo ma Linus, ne ... ?

Jistě. Ale to neznamená, že se k tomu nemohou vyjádřit ostatní. Proč by se pull request vůbec posílal do LKML, kdyby to bylo čistě na Linusovi? Připomínám, že ten pull request nedostal ani jedno Acked-by nebo Reviewed-by od nikoho, kdo by se na něm přímo nepodílel.

Ale nejsou IMHO natolik zasadni, aby se to dalo cele splachnout,

Názory jsou od toho, aby se lišily. Pro mne je třeba no-go už samotné zamotání IPC a D-Bus protokolu dohromady (s tím, že je vážná otázka, jestli by při rozumném oddělení pořád ještě byl důvod mít v jádře i tu horní vrstvu). Jiní mají vážné výhrady k samotné koncepci předávání metadat pro potřeby autorizace. Dalším se nelíbí způsob, jak se tam přistupuje k alokaci paměti. Kromě toho se ukázalo, že hlavní argument, proč musí D-Bus za každou cenu do jádra, je od základu vylhaný (v lepším případě - pokud by ho vlastně nikdo ani nezkusil ověřit, bylo by to snad ještě horší).

K tomu jsou tady procesní záležitosti: pull request posílá Greg, ale veškeré technické připomínky bagatelizuje a vyjadřovat se k nim musejí jiní. Celé to vypadá, že Greg s tím kódem moc společného nemá a slouží jen jako ikona, která má svou autoritou zajistit hladký průběh. Takové jednání je možná zvykem jinde, ale při vývoji jádra nevzbuzuje moc důvěry. A teď tomu ještě nasadil korunu Lennart Poettering svou snahou protlačit kdbus do distribucí dřív, než bude v mainline.

Nicmene diky izolovanosti modulu, ktery neni invazivni, podle vseho [zatim] s nizkymi "naklady" na udrzbu, a pritom s osvedcenou, uz deset let pouzivanou koncepci, riziko neni tak velke.

Riziko je zatraceně velké. Lidé kolem systemd nejsou známi svým respektem ke stabilitě rozhraní - tedy aspoň ne tím, že by nějaký měli. Stejný problém je s jejich přístupem k udržování a řešení chyb. A to, že se něco deset let používá v user space, ani zdaleka neznamená, že je to navrženo dost dobře, aby to přežilo review pro začlenění do jádra.

[pavlix]

Pro mne je třeba no-go už samotné zamotání IPC a D-Bus protokolu dohromady (s tím, že je vážná otázka, jestli by při rozumném oddělení pořád ještě byl důvod mít v jádře i tu horní vrstvu).

Díváš se na to podobně jako já. Taky si myslím, že pro míchání mechanismu pro výměnu zpráv a konkrétní formát zpráv není zásadní důvod. A pokud jde o filtrování, tak pokud vím už teď kernel obsahuje nějaký interpret bajtkódu, takže by neměl být problém udělat filtrovací mechanismus zcela univerzální s dodáním filtrů z userspace.

Mimojiné bych očekával konkrétní srovnání se stávajícími mechanismy a to především proto, aby se nepřidal další kód, který poskytuje nesourodou množinu služeb. Nový mechanismus by se podle mě měl vyvarovat regresím oproti těm existujícím, měl by řešit známé palčivé problémy, a především by neměl přidávat zbytečný bloat.

Osobně si myslím, že je v jádře tuna totálních nesmyslů a čím dál tím víc jich přibývá. Nevidím jediný důvod, proč dávat do jádra věci, které nepřinesou zásadní výhodu. Argument, že kdbus samotný ničemu zásadně neuškodí, neberu. Stokrát nic umořilo vola. Už teďka si říkám, že by se mi moc líbilo stát se jaderným vývojářem, ale systému, který není takový bloatware jako Linux.

[Michal Kubeček]

Nějaká vysvětlení, proč stávající IPC nevyhovují, už padla a IMHO leccos z toho dává dobrý smysl. Hlavní problém ale vidím v tom, že vývojáři D-Busu (a asi i mnozí vývojáři desktopových aplikací) to vidí tak, že univerzální IPC není potřeba, protože D-Bus je tím univerzálním IPC: "všichni" ho používají a kdo by chtěl používat to univerzální IPC, může místo stavět na D-Busu. Na to jsem narážel už v tom přirovnání k nedělitelnému síťovému stacku až po HTTP. Obávám se, že už dnes se D-Bus používá na věci, které by šly pohodlněji a efektivněji řešit jinak - a nedělitelná implementace D-Busu v jádře by to nejspíš ještě zhoršila.

[little.owl]

A pokud jde o filtrování, tak pokud vím už teď kernel obsahuje nějaký interpret bajtkódu, takže by neměl být problém udělat filtrovací mechanismus zcela univerzální s dodáním filtrů z userspace.

To by se mi libilo, ale problem by to byl - nekdo by to totiz musel udelat.

Osobně si myslím, že je v jádře tuna totálních nesmyslů a čím dál tím víc jich přibývá. Nevidím jediný důvod, proč dávat do jádra věci, které nepřinesou zásadní výhodu.

Co je a neni nesmysl je relativni a stejne co je a co neni vyhodne.

Kernel potrebuje oficialni samocistici mechanismus, jak se postupne transparentne a planovane zbavovat nektere zastarale ci neoptimalni funkcionality, treba i za cenu pozvolneho omezeni zpetne kompatibility, jinak jsou bloat a ohejbaky z principu nevyhnutelne.

[pavlix]

To by se mi libilo, ale problem by to byl - nekdo by to totiz musel udelat.

U zdravého a silného projektu, kterým jádro kdysi zřejmě bylo, se toto dá řešit tím, že se změny nepřijmou, dokud nemají požadované vlastnosti.

Co je a neni nesmysl je relativni a stejne co je a co neni vyhodne.

Debugovat userspace je vždycky lepší, tudíž osobně považuju za nesmysl všechno, kde není vážný důvod, proč to není v userspace. Ale chápu, že je to relativní, protože třeba i tady na ábíčku většina lidí nadává téměř výhradně na userspace a schovat něco do jádra má tedy zásadní politický význam. Nakonec možná bude výhodné přijmout kdbus proto, aby byl tento pohled přehodnocen.

[little.owl]

Názory jsou od toho, aby se lišily.

Presne tak, jinak by tu byla nuda .

Pro mne je třeba no-go už samotné zamotání IPC a D-Bus protokolu dohromady (s tím, že je vážná otázka, jestli by při rozumném oddělení pořád ještě byl důvod mít v jádře i tu horní vrstvu).

Jak jsem uz psal, oddeleni bych uvital, ale i protokol bych nechal v jadre. Kategorie uzivatelu Linuxu, do niz spada vetsina firem v oblasti kde pracuji, se vyznacuje tim, ze nejsou schopni sami spravovat nejake dlouhodobe konzistentni reseni v teto oblasti a ani se na nem realne schodnout (maximalne vznikne dokument design by committee jako tohle - coz vam jako vyvojari moc nepomuze). Funkcni reseni a sprava v ramci kernel projektu je v takove situaci asi to nejlepsi, co muze se stat, nebot udrzuje spolecnou platformu.

Celé to vypadá, že Greg s tím kódem moc společného nemá a slouží jen jako ikona, která má svou autoritou zajistit hladký průběh.

To je hodne silne obvineni.

[pavlix]

Přitom by nebyl problém spravovat kernel a několik userspace komponent v rámci jednoho projektu s podprojekty, aby byla dodržena jak výhoda společné platformy, tak výhoda rozdělení jádra a userspace.

[little.owl]

Ano, to by bylo dobry pristup ... Pak by se mohly i zacit presouvat i nektere veci z kernelu ven.

Jestli je to dobre reseni i pro kdbus nevim, ale treba casti sitoveho stacku v userspace moc velky uspech nemaji, i pres ruzna kernel-bypass reseni.

[pavlix]

Pokud vím, tak mnohé části síťového stacku jako třeba implementace DHCP a DNS v userspace úspěch mají. Obávám se, že většina z nás moc dobře ví, co je potřeba dát do kernelu a pro co v kernelu žádný důvod není, a Linux se tou cestou vyvíjí, dokud se nejedná o nějaký známý projekt tlačený silnou zájmovou skupinou. A to teď nemám namysli žádné konkrétní projekty, ale obecný přístup, který se podle mě v poslední době uplatňuje.

[little.owl]

Tim jsem mel na mysli spise treba ony protokoly, nez veci jako DHCP. Az se zacne presouvat TCP/IP do userspace, bude cas me vzbudit.

[Michal Kubeček]

U TCP/IP bych to moc nečekal a po pravdě mi to (od transportní vrstvy dolů) ani nepřipadá jako moc dobrý nápad. Ale příkladem může být třeba teaming, který na rozdíl od bondingu nechává v jádře jen to, co je opravdu žádoucí tam nechat.

[pavlix]

Az se zacne presouvat TCP/IP do userspace, bude cas me vzbudit.

To bude nějakej renonc, vzhledem k tomu, že jsem psal o věcech, u kterých není důvod pro to, aby byly v kernel space. Myslím, že u TCP nebude problém dát dohromady hned několik důvodů, proč má být v kernelu.

[Spike]

A teď tomu ještě nasadil korunu Lennart Poettering svou snahou protlačit kdbus do distribucí dřív, než bude v mainline.

:) Fedora's Rawhide Kernel Adds In KDBUS Support, Ready For Testing

[trekker.dk]

Takze kod, na kterem stoji nejuspesnejsi Linuxova platforma v jeho historii, ktery pouzivaji ve svych zarizenich stovky milionu uzivatelu, zaclenime do kernelu bez vetsich starosti o technicke kvality.

Samozřejmě, o technické kvality u telefonů nikdy nešlo a u zařízení pro běžného ferdu spotřebitele ani nepůjde. Co nejrychleji něco zprasit, šup s tím na trh, když to nabootuje. Android výrobcům výrazně zjednodušuje to co nejrychleji, proto měl (má) takový úspěch. Nic jiného v tom nebylo.

[little.owl]

Ano, ale tady mluvime o procesu jakym byl Binder akceptovan jako plnohodnotna soucast stabilni vetve Linux kernelu, nikoliv o nejake Android vetvi, kde si to Google masti jak chce.

[AsciiWolf]

Having looked at the dbus performance, and come to the conclusion that the reason dbus performs abysmally badly is just pure shit user space code, I am not AT ALL impressed by the performance argument. We don't merge kernel code just because user space was written by a retarded monkey on crack.

[pavlix]

Zajímavé shrnutí, skoro škoda, že se k němu nemůžu vyjádřit.

[Lol Phirae]

škoda, že se k němu nemůžu vyjádřit.

Copak? Už nesmíte ani naznačovat?

[wotan]

Koukám, že Redhat a SUSE jsou stejně v prdeli.

[mankind_boost]

Naopak, kvůli RH a jeho šílenostem budou v prdeli všichni ostatní.

[Blue Thunder]

Jo. Mám z toho ten samý pocit.

[Blue Thunder]

Já myslím, že to naznačil pěkně. Kdyby to nebyl nátlak ze strany Red systemd Hat, proč by se k tomu pak Pavlix nesměl vyjadřovat?

[Michal Kubeček]

Jenže pavlix nenapsal že se nesmí vyjádřit, ale že nemůže. Což může klidně znamenat třeba to, že nečetl celý ten dlouhý thread na LKML, takže neví, jestli jsem něco podstatným způsobem nezkreslil nebo něco důležitého nevynechal.

[pavlix]

Mimochodem, myslíš, že to má nějakou souvislost s nedávným slovním útokem na Linuse a pokusem z něj udělat černou ovci komunity?

[Michal Kubeček]

Nemyslím, že je tam přímá souvislost v tom smyslu, že by si tehdy připravoval půdu pro případ ne zrovna vřelého přijetí kdbusu. Spíš jen nepřímo, IMHO ten konkrétní útok na Linuse byl projevem jakési frustrace, že vývojáři jádra jsou jakýsi svět sám pro sebe, který (na rozdíl od většiny linuxového světa) nedokáže příliš ovlivnit; navíc je to svět, kde obecně není příliš populární a jehož filosofie není moc kompatibilní s tou jeho. Takže spíš než promyšlenou přípravu na tlačení kdbusu do jádra bych v tom viděl reakci na některé předchozí konflikty (třeba to, jak Linusovi došla trpělivost s Kayem Sieversem nebo spor o parametr debug na příkazové řádce).

[Hans1024]

Ja myslim, ze Lennartova nenavist k Linusovi saha mnohem dal, viz rozhovor s Linusem (cas 19:20):

Before systemd really got started, on one of the kernel summits ... Lennart was giving a talk about UUIDs to the kernel people, at the kernel summit. And we laughed him out of the room. UUIDs are crazy shit. They're up there with XML as bad ideas and exposing them as something really cool and clever was... I felt just stupid and I wasn't the only one.

[martin]

ona spis zadna takova nenavist neexistuje. ale klidne se presvedcujte o opaku, pokud vam to pomaha...

[mankind_boost]

Ona podle všech indicií taková nenávist na obou stranách jistě existuje. Ale klidně se přesvědčuj o opaku, pokud ti to pomáhá...

[Pali]

"We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled."

Aha, takze ked Linus sa nema k tomu aby ten kdbus pridal do upstreamu, tak Lennart hlada cestu cez downstream ako vnutit tu jeho vec uplne vsade...

[mankind_boost]

Aufs taky snad roky nebylo soucasti jadra a presto ho vsichni pouzivali.

[MadCatX]

Doufám, že žádná soudná distribuce nebude cpát do jádra out-of-tree patche pro něco tak zásadního jako KDBUS. V systemd nechť si to klidně nechají jako runtime volbu. Revertovat příslušný patch by taky nejspíš nebyl problém (https://github.com/systemd/systemd/commit/1b09f548c7f303b486b5b1321c06336bff72ada4).

[trekker.dk]

Můžete se vsadit, že bude. Lennart je sice blbec, s jehož výtvory se nedá rozumně pracovat (přinejmenším dokud je neopustí a někdo jiný je nedotáhne do rozumného stavu), ale je to taky velice schopný politik a dokáže přesvědčit lidi, kteří rozhodují. (Zpravidla na úkor lidí, kteří to rozhodnutí pak musí odpracovat, což většinou nejsou ti samí.)

[2X4B-523P]

zatimco po vytvorech nekterych chytraku je potreba vzdy radne splachnout...

[Michal Kubeček]

Jednorázově revertovat jeden patch pro potřeby distribučního balíčku problém není. Z dlouhodobého hlediska to ale de facto znamená udržovat vlastní fork, což může být čím dál složitější.

[Jindřich Makovička]

Proč by měli ten patch revertovat? To, že systemd podporuje kdbus, neznamená, že ho vyžaduje.

[Michal Kubeček]

Vypadá to, že ten commit opravdu dělá něco trochu jiného, než jak to znělo ve shrnutí. I tak je ale hodně nešťastné natvrdo zakompilovávat podporu pro něco, co je zatím těžce WiP a u čeho není vůbec jasné, kdy a v jaké podobě (a jestli vůbec) se do mainline dostane. Pořád to vypadá jako pokus připravit si klacek na ty, kdo by případně chtěli změnit rozhraní kdbusu, aby šlo říct "to nejde, systemd už to očekává takhle a je to tak v distribucích" (zvlášť v kombinaci s tou výzvou, aby distribuce přidávaly kdbus do svých jader).

[MadCatX]

Ten commit akorát dělá z KDBUSu runtime volbu. Na systému, kde neběží jádro s podporou KDBUSu se nic nemění, akorát bude systemd obsahovat o pár nečinných kB kódu navíc. Vážně doufám, že to Lennartovo doporučení začít nasazovat KDBUS nikdo nebude brát vážně. Vzhledem k tomu, že by to vyžadovalo od maintainerů práci navíc se toho tolik nebojím. Má vůbec KDBUS nějakou větev, kterou je možné jednoduše aplikovat na stable jádro?

Jinde v diskusi je zmíněn nějaký benchmark KDBUSu. Povedlo se mi najít jen jeden, kde se ale porovnává KDBUS proti unixové rouře, což není zrovna relevantní. Benchmarkovalo se to i jinak?

[Michal Kubeček]

Pár nejzajímavějších e-mailů na toto téma z toho megathreadu:

• Jednoduchý benchmark porovnávající rychlost kdbus proti userspace D-Bus
• asynchronní verze benchmarku
• Linus zkusil profiler na ten benchmark (dodatek) a zjistil, že výkonový problém D-Busu je někde úplně jinde než v počtu context switchů
• Havoc Pennington přiznává, že vlastně dávno věděl, jak je D-Bus démon neefektivní, ale že to všem bylo jedno, protože byli stejně rozhodnuti, že to půjde do jádra a basta, tak co se snažit ho optimalizovat.
• A tady Havoc Pennington v podstatě přiznává, že se vlastně ani nedalo čekat, že by benchmark ukázal lepší poměr než 2:1 ve prospěch kdbus

Povedlo se mi najít jen jeden, kde se ale porovnává KDBUS proti unixové rouře, což není zrovna relevantní.

Podle mne je to velmi relevantní. Nedá se asi očekávat, že by se kdbus výkonově vyrovnal rourám nebo PF_UNIX socketům*. Měl by ale být aspoň ve stejné lize, jinak je to znamení, že je něco špatně.

Podle mne je ale hlavní problém současného návrhu v neoddělení IPC mechanismu od implementace vlastního D-Bus protokolu. Autoři mají pohled zkreslený tím, že žijí ve svém světě, kde "všichni používají D-Bus", takže nevidí potřebu univerzálního IPC se sběrnicovým modelem. Podle mne je to ale podobně nesmyslné uvažování, jako kdyby někdo usoudil, že "všichni používají HTTP" a tlačil do jádra kompaktní a nedělitelnou implementaci síťového stacku od driveru karty až po HTTP. Ta by pak nešla použít pro nic jiného než pro HTTP komunikaci (a věci postavené nad ním), ale to by bylo jedno, protože stejně "všichni používají HTTP" a ostatní se dá zabalit do něj. Tady je samozřejmě nesmyslnost té úvahy zřejmá, protože všichni známe další protokoly aplikační a transportní vrstvy, ale základní logika je úplně stejná; koneckonců se nezřídka D-Bus už dnes používá způsobem, který si nezadá s třeba SMTP emulovaným přes HTTP requesty.

[little.owl]

OK, ten thread jsem cetl. GDBus implementace je pomala, a fakt ze to nikomu nevadilo, svedci ze performance neni na desktopu az tak velky problem. Relevantnejsi argumenty mel Harald Hoyer a do znacne miry se to kryje s argumentaci lidi pouzivajici AF_BUS v Genivi (ktery byl bez velke diskuze zamitnut David Millerem), za ktere v soucasnosti jedna spise GKH.

Podle mne je ale hlavní problém současného návrhu v neoddělení IPC mechanismu od implementace vlastního D-Bus protokolu.

S tim vcelku souhlasim. Ja jsem rad, ze kdbus implementace prochazi touto skrutinou, veci to jen prospeje. Obe skupiny - kernel developeri a userspace developeri - ziji ve sve bubline a maji problemy se podivat na vec optikou druhe strany.

[Jindřich Makovička]

Problém s čímkoliv založeným na GObject je mimo jiné v tom, že každá (de)alokace objektu je serializovaná jedním globálním zámkem, takže na víc vláken škáluje velice špatně, spíš vůbec.

[little.owl]

Plus asi zamykani spojene s reference counting, nevim. To neni v soucasnosti problem jen u GLib. Klasicky threading a zamykana shared memory jsou na pytel, tudy cesta dlouhodobe pro velky pocet jader asi nevede.

[Michal Kubeček]

Ne nadarmo se i v jádře řada věcí přepsala (a stále přepisuje) na jiné metody, např. RCU.

[blake]

GDBus implementace je pomala, a fakt ze to nikomu nevadilo, svedci ze performance neni na desktopu az tak velky problem.

Ja jsem rad, ze kdbus implementace prochazi touto skrutinou, veci to jen prospeje.

Kde se da naucit takovy zmrdspeak ? Dalkove studium politologie nebo MBA ? Pokud vim, tak tohle CVUT neprodukovala …

[ivan]

Kde se da naucit takovy zmrdspeak ? Dalkove studium politologie nebo MBA ? Pokud vim, tak tohle CVUT neprodukovala …

Tak treba na FF obor politologie. To slovo se pouziva pri popisu ruznych volebnich systemu. Vzhledem k tomu, ze je jedna o systemd, tak je to relevatni terminologie.

[little.owl]

Tak treba na FF obor politologie.

Staci lekce latiny ci anglictiny, kdekoliv, aby si clovek uvedomil zaklad. Ma to latinsky puvod, scrutinium, kde se vyznam postupne ustalil z prebirani odpadku na podrobnem zkoumani, prohlidku, vy/pro-setreni za ucelem se dobrat [skryte] informace ci podstaty. V anglictine si to v teto forme zive uchovalo vyznam (zde ci zde), v cestine se to skutecne pouziva nejcasteji se scitanim hlasu ci treba s cirkevnimi obrady.

[chrono]

Všetky projekty pod správou Redhat začnú vyžadovať nejakú funkciu, ktorú bude podporovať len nová verzia systemd/udev a nová verzia systemd/udev nebude fungovať bez kdbus. ;)

[R]

Lennart sa pokusa dostat do fazy extend (z Embrace, Extend, Extinguish).

[Delaunay]

Také se obávám. Přesněji pak okamžiku, kdy dojde k zásadnímu konfliktu mezi "jadernými konzervativisty" a "lennartisty". Kdy Lennart již zcela otevřeně obviní některé důležité jaderné vývojáře ze lpění na starých pořádcích a z neschopnosti držet krok s jeho vizionářskými vývojářskými schopnostmi.

Aby nakonec výsledkem takového schizmatu nebyla existence dvou docela odlišných ekosystémů. Na jedné straně "zastaralý" a již značně nesourodý GNU/Linux, a moderní a perspektivní systemd/Lennartux na té druhé.

Zatím si to Lennart nemůže dovolit a moc dobře si to uvědomuje, proto postupuje politicky osvědčenou salámovou metodou. A dělá vše pro to, aby si vykolíkovat dostatečný prostor, získal lepší vyjednávací pozici a tím i vydírací potenciál...

[pavlix]

Aby nakonec výsledkem takového schizmatu nebyla existence dvou docela odlišných ekosystémů.

To by nebylo zase tak zlé, ne?

[hlasovani]

Už pod tím jedou Bulánci?

[2X4B-523P]

na ty je potreba kombinace hal, dcop a dbus, stejne jako na vse ostatni

[j]

Proc ... bulancid ... a staci jim systemd ne? Sak to vsechno uz je stejne integrovany, sitovat to umi ...