Debian se vrací k glibc (diskuse)

[leo]

hagaro, hagaro, zapomněl si na spoustu událostí:

1) Byl odhalen tajný seznam patentů, kterými chce Microsoft zaútočit na Android

2) Je nový Fedora Project Leader

3) Skype 4.3 for Linux has been released

4) Ukázalo se, že Nokia v r. 2008 zaplatila výkupné několik mil. eur za klíč

Kdepak jsou o tom zprávičky? Si zprávičkář na slabé baterky.

[hm]

Jak tohle souvisí s čímkoliv?

[sonicpp]

No co to je Leo, kde jsi byl celou dobu, že ho kritizuješ až půl hodiny po zprávičce?

[Max]

Prosím, zdrž se offtopic diskusí.
díky
Zdar Max

[BigBoss]

Zase něco osobního. Kašli na to.

[Aleš Kapica]

Jestli sis toho doposud nevšimnul, tak dole pod zprávičkami je mimo jiné i link "Napsat", takže pokud jsi ty věci považoval za dostatečně zajímavé i pro jiné, tak jsi to měl napsat sám a ne se tady navážet do aktivnějších lidí než jsi sám.

[pavlix]

To je skvělá zpráva.

[Foo Bar]

Já myslím, že se to po odchodu UD[1] a jeho agresivního útočného stylu, který představoval, dalo docela čekat...

1. Což byla taky skvělá zpráva :)

[kralyk z abclinuxu]

UD odešel? Haleluja

[Pavel Píša]

Ulrich Drepper na určitě měl své mouchy a nakonec se stal brzdou a možná i hrozbou vývoje GLIBC. Přes to všechno si ho nesmírně vážím a všichni mu máme co děkovat. Díky němu je Linux více něž konkurenceschopný v synchronizaci vláken/procesů a škálovatelnosti. Podílel se na integraci FUTEXu do GLIBC, byl ochotný si udělat čas na dokumentaci http://www.akkadia.org/drepper/futex.pdf , když idetifikoval problémy GLIBC a standardu POSIX v oblasti bezpečnosti, tak si dal práci s návrhem rozumných nových rozhraní a systémových volání včetně spolupráce na jejich následné standardizaci (openat, ...) atd. Byl soudný a měl představu o paměťové náročnosti a optimalizaci práce s pamětí atd. V době, kdy proti němu sílila vlna nevole a forkovalo se EGLIBC, tak stál za transformací správy GLIBC na GIT, který by distribuovaný vývoj umožnil. Setrvání EGLIBC u SVN a backportování především jeho práce do SVN jsem bral jako krok zpět, když podmínky pro spravování plnohodnotných forků vytvořil. Je i docela možné, že nespokojenost s často nesmyslným chováním druhých u něho přerostla v alergii a trucovité chování.

Takže celkově si zaslouží úctu.

[pavlix]

Nejsem si jistý, zda si člověk bez úcty k druhým zaslouží úctu. Nicméně Ulrich je pryč, spousta jeho textů je překonaná. Třeba co mě věčně lidé odkazují na jeho zápisky o getaddrinfo, IPv6 a spol, to mi vyloženě leze na nervy, vzhledem k tomu, že jsou založené na čisté teorii a nulové praxi.

Nicméně pokud si máme vážit Ulricha, pak si budem muset stejně vážit i Lennarta a Kaye ;).

[Petr Tomášek]

Nejsem si jistý, zda si člověk bez úcty k druhým zaslouží úctu.

Pavlixi, takovou sebereflexi jsem od tebe nečekal

[pavlix]

Od tebe to zrovna sedí.

[PavelC]

Pred lety utekli od glibc aby se k nemu vratili, nedavno zase opustili dosavadni init system ve prospech jineho aby opakovali stejnou chybu ? Na to za jak konzervativni distribuci je Debian povazovan mi prijdou jejich rozhodnuti dost unahlena.

[Foo Bar]

Důvody pro migraci na eglibc byly tou dobou popsané, a pochopitelné.

Ten trolí můstek, který jste předvedl, si s prosím strčte za klobouk.

[Milan Uhrák]

Přesně tak, časy a situace se prostě mění .. nechceme snad tvůrce Debianu podezřívat z bezhlavosti. Prostě se snaží jít s dobou, ale zároveň mají odvahu říct : "Hm, tak tohle nebyla správná cesta, jak se nám zdálo prve". Ještě aby podobně jednali někde u vývoje gnome ...

Debian (ani gnome) nepoužívám.

[Lol Phirae]

ale zároveň mají odvahu říct : "Hm, tak tohle nebyla správná cesta, jak se nám zdálo prve".

Ale to evidentně byla v té době správná cesta. "Spolupráce" s UD byla asi podobně příjemná jako s DJB nebo JS, nebo aktuálně s duem Lennart/Kay.

[Milan Uhrák]

Nevím vo co go ....

nechceme snad tvůrce Debianu podezřívat z bezhlavosti

.

V té době meli pro přechod dobré důvody, a dnes je mají opět

příspěvek nade mnou :

Důvody pro migraci na eglibc byly tou dobou popsané, a pochopitelné.

Přesně tak, časy a situace se prostě mění

[pta]

Asi by to chtelo priste ubrat na hysterii.
Pokud vim tak Debian bude jedinou "velkou" distribuci, ktera tu zmenu provedla. Pro ARMy a jine ne-x86 architektury bali i Gentoo, Arch, Fedora a Slackware a ty na elibc nepresly. Ve svetle poslednich udalosti Debian prakticky odepsal kFreeBSD, tak se ta sirka platforem zacina ztencovat.

[pavlix]

Pred lety utekli od glibc

Pokud vím z dobrých důvodů.

aby se k nemu vratili

Bezpečně dlouho po pominutí těchto důvodů.

Na to za jak konzervativni distribuci je Debian povazovan mi prijdou jejich rozhodnuti dost unahlena.

To, že Debian zareaguje na změnu situace v glibc po několika letech, ti přijde unáhlené?

[erino72]

Niekde som videl aj novsiu implementaciu glibc a mala v porovnaniach vykonu navrch ale nemozem si spomenut na nazov...

[pavlix]

Nejspíš to nebyla novější implementace glibc, ale novější implementace libc, a dost možná konkrétně musl libc.

[R]

Ale systemd vyzaduje glibc...

[pavlix]

Pokud vím, tak okiáš spustil nějaké Gentoo nad musl libc po pár úpravách, a to je takový milovník systemd, že bych tiše předpokládal, že nad ním pustil i systemd.

[erino72]

presne tak, musl som mal na mysli...

[erino72]

a nie je dost dobra aby nahradila musl?

[Nobody]

Lennart by mohl pripsat libc do systemd, aby v tom nebyl takovy zmatek.

[R]

To by mohol, aj tak systemd bez glibc nefunguje.

[rbc]

To asi bude ten hlavni duvod proc to zase vraci. Odvolavam co jsem odvolal, slibuju co jsem slibil

[pavlix]

Já se trochu obávám, že to s tou závislostí na glibc je alespoň částečná mystifikace.

[pta]

Zas tak intenzivne to nesleduju, ale jak na svym blogu tak na mailing listech opakovane uvadel pozadavek na glibc a ze to vyviji s ni a jine implementace ho nezajimaji. Zmenilo se na tom od te doby neco ?

Jako ono je to pekny kdyz to po upravach ted nekdo prelozi s jinou knihovnou, ale na to se prece neda spolehat. Nebo se ocekava, ze kvuli systemd budou vsichni resit kompatibilitu s glibc ?

[pavlix]

Zas tak intenzivne to nesleduju, ale jak na svym blogu tak na mailing listech opakovane uvadel pozadavek na glibc a ze to vyviji s ni a jine implementace ho nezajimaji.

Já chápu, že to interpretuješ jako že to bez glibc nepojede, ale je potřeba číst trochu mezi řádky. Není cílem zabránít běhu jinak než s glibc, ale odpálkovat kohokoliv, kdo si stěžuje, že to jinde nechodí.

Co je implementováno v glibc vzhledem k jejímu rozšíření tvoří de facto standard (a teď očekávám vlnu alternativců, jak mi to začnou vyvracet) a tudíž je pravděpodobnější, že se nekompatibilita mezi systemd a alternativními libc bude řešit na straně těch alternativních libc a ne na straně systemd. Což při pevné závislosti na linuxu vcelku dává smysl.

Jako ono je to pekny kdyz to po upravach ted nekdo prelozi s jinou knihovnou, ale na to se prece neda spolehat.

To je relativní.

Nebo se ocekava, ze kvuli systemd budou vsichni resit kompatibilitu s glibc?

Ano. Osobně předpokládám, že maintainerům systemd je to jedno. Takže pokud chce někdo zajišťovat kompatibilitu systemd s jinou knihovnou, tak ji musí zajistit na straně té knihovny. Není to nijak překvapivé ani pobuřující, zvláště pokud je takový postoj otevřeně deklarován.

[Michal Kubeček]

Já chápu, že to interpretuješ jako že to bez glibc nepojede, ale je potřeba číst trochu mezi řádky. Není cílem zabránít běhu jinak než s glibc, ale odpálkovat kohokoliv, kdo si stěžuje, že to jinde nechodí.

Já tam rozdíl vidím. Jedna věc je říct: "Nebudeme se zabývat bugreporty, které se týkají (jen) fungování s jinými libc." Jenže oni říkají: "Nestojíme o patche, které řeší jen kompatibilitu s jinými glibc." Proti tomu prvnímu bych nic nenamítal, to druhé mi vadí.

Z mého pohledu je odmítání oprav zajišťujících kompatibilitu s jinými libc oprávněné pouze v případě, že jde o chybu příslušné libc. A na rozdíl od Lennartova fanclubu za chybu implementace libc považuji to, když se chová v rozporu se specifikacemi ISO C nebo POSIX, ne to, že se chová jinak než glibc. Samozřejmě se najdou výjimky, třeba chybějící interface pro nějaký syscall, ale prohlásit obecně, že jakýkoli rozdíl oproti glibc je automaticky považován za chybu té druhé knihovny (a má se "opravit" tam), to je něco, s čím nemůžu souhlasit.

[pavlix]

Proti tomu prvnímu bych nic nenamítal, to druhé mi vadí.

Já neříkám, že je to kdovíjak super, ale rozhodně to není tak fatální, jak to tu někteří prezentují. To dokazuje už jen to, že se systemd s jinými libc používá. Navíc mi není jasné, vzhledem k historii projektu, co lidi na tomto velkohubém prohlášení ještě překvapuje.

[little.owl]

A cim to, ze systemd 213 jde sestavit bez velkeho patchovani i pod malou uclibc?

Nech uz toho nekonecneho FUDu ...

[Petr Ježek]

Protože místní neznalci jsou tupci.

[kralyk z abclinuxu]

Zas taková blbost to není, jestli se dobře vzpomínám, Lennart prohlásil něco ve smyslu, že kašle na standard a jestli chce někdo sestavit systemd nad jinými libc, musí být ta libc kompatibilní s glibc.

Takže se určitě nedá říct, že systemd funguje nad jakoukoli (standard dodržující) libc.

[rbc]

Hle kdo dorazil

[lima]

V tom pripade siri FUD sam autor: Vyjadreni L. Potteringa k nezkompilovatelnosti systemd nad uclibc

Humm, I know this will disappoint you, but we are not particularly interested in merging patches supporting other libcs, if those are not compatible with glibc. We don't want the compatibility kludges in systemd, and if a libc which claims to be compatible with glibc actually is not, then this should really be fixed in the libc, not worked around in systemd.

Davas tu odkaz na experimentalni pokus zkompilovat systemd nad uclibc pro embedded linux. Sorry, ale to je hack ktery pozadavek na glibc vubec nevyvraci. Nebylo by neco presvedcivejsiho ?

[little.owl]

we are not particularly interested in merging patches supporting other libcs, if those are not compatible with glibc.

Pokud to neni kompatibilni s glibc, muze se stat, ze se to nepodari zkompilovat, nebude to s nicim jinym testovano, a nebude se hledat minimalni prunik. Otazka spise zni, jak casto se to v praxi stava.

Davas tu odkaz na experimentalni pokus zkompilovat systemd nad uclibc pro embedded linux. Sorry, ale to je hack ktery pozadavek na glibc vubec nevyvraci. Nebylo by neco presvedcivejsiho ?

Za prve, to je falesna argumentace, vy odkazujete jiny zastaraly vyvojovy commit resici specificke problemy Buildroot:

... because we have uClibc patches that add support for execvpe(), but we also have a patch for systemd that adds execvpe(), which was added when the internal uClibc didn't support execvpe() ...

Za druhe, execvpe() je tak strasne glibc vec, ze to ma i QNX a ostatne uclibc take celkem dlouho - embedded distribuce jsou obcas pozadu, veci se bezne patchuji/backportuji.

Od tohoto commitu - akceptovaneho upstreamem systemd - a to jsou tri roky - jsem nemel problemy s embedded kompilaci i pro minimal-uclibc - a musi se toho patchovat cim dale mene - jak muzete videt u 213 - to vam prijde malo presvedcive?

[lima]

Celkove si odporujete, kdyz jinymi slovy vlastne potvrzujete co se snazite vyvratit.

Jinde se teda musi hackovat zdrojaky systemd nebo doplnovat a prizpusobovat api pozadovane verze glibc. Sam jste to potvrdil odkazem do buildrootu, ze bez patchu ani soucasnou verzi systemd s uclibc neprelozite. A to nemluvim o testovani.

Momentalni rozsah nebo pocet potrebnych patchu prece neni argument, protoze s novymi verzemi systemd se bude muset zase dolepovat nebo udrzovat uplnou kompatibilitu s glibc.

O FUD zjevne neslo, s glibc nekompatibilinimi se v upstreamu systemd nadale nepocita.

[little.owl]

Celkove si odporujete, kdyz jinymi slovy vlastne potvrzujete co se snazite vyvratit.

Ne, vy michate vsechny problemy dosti pitome dohromady.

ze bez patchu ani soucasnou verzi systemd s uclibc neprelozite.

Se soucasnou ano, ale ne s neopatchovanou starsi v Buildrootu - to je problem jejich update cyklu - zmena uclibc je bolestny proces a tak backportuji jednotlive zmeny a postupne upravuji cely system.

Patche pro v213 jsou kosmeticke - 4 patche, ktere vubec nesouvisi glibc. Ve Fedore, s glibc, v208, jich je - ~470, tedy uclibc je dle vasich meritek vlastne kompatibilnejsi!

udrzovat uplnou kompatibilitu s glibc.

To je jeden z cilu uclibc, udrzovat minimalistickou kompatibilitu s glibc, v cem je problem?

O FUD zjevne neslo, s glibc nekompatibilinimi se v upstreamu systemd nadale nepocita.

Prectete si tedy znovu predchozi tvrzeni, neolikrat:

aj tak systemd bez glibc nefunguje.

a odpoved je - nepravdive tvrzeni - pouziti uclibc je dukazem.

[lima]

- systemd zavisi na glibc, jine C knihovny primo nepodporuje
- ostatni C knihovny musi mit potrebnou kompatibilitu s glibc
=> systemd bez glibc nebo kompatibilni nefunguje
Q.E.D.

[pavlix]

Pokud vím, tak tato zkratka se používá pro důkazy, tedy postupy, které dokazují nějaké jednoznačné tvrzení na základě jiných jednoznačných tvrzení. Lennart se prostě vyblil na téma nezájmu o cokoliv jiného než linux/glibc, jak je jeho dobrým zvykem.

Ve skutečnosti ta knihovna nemusí mít vůbec žádný vztah ke glibc, jediné, co musí, je být kompatibilní se systemd. Jediná knihovna projektem deklarovaná jako podporovaná je glibc, to je všechno. Konec konců je to jenom knihovna, takže jakákoliv nekompatibilita mezi použitou libc lze řešit třemi způsoby:

1) Změnou systemd, aby nevyžadovalo nepodporovanou feature. To je jediná věc, kde tě upstream systemd může poslat (a pravděpodobně pošle), kam slunce nesvítí.

2) Změnou knihovny. Vzhledem k tomu, že systemd pravděpodobně nebude jediným uživatelem nestandardních vlastností glibc, tak tahle cesta pomůže i dalším projektům. Dá se předpokládat, že upstream knihovny takové změny přijme.

3) Dolepením mezivrstvy, která nekompatibilní části vyřeší. Vzhledem k #2 by toto nemělo být nikdy potřeba.

[lima]

Nema cenu jinymi slovy znovu preformulovavat co uz bylo receno.

Pokud to se zavislosti na glibc pravda neni, tak bych ocekaval nove prohlaseni a zmenu ve zdrojacich systemd pro podmineny preklad nebo osekani na nizsi spolecny jmenovatel, aby slo prelozit a fungovalo treba s diet libc, musl, bsd libc apod. O nicem takovem ale nevim. K sireni FUDu kvuli kteremu tohle vlakno vzniklo podle vsecho nedoslo.

[pavlix]

Nema cenu jinymi slovy znovu preformulovavat co uz bylo receno.

Alespoň jsem se snažil.

K sireni FUDu kvuli kteremu tohle vlakno vzniklo podle vsecho nedoslo.

Došlo ke zjevně nepravdivému prohlášení, že systemd bez glibc nefunguje. Několik lidí nezávisle na sobě toto prohlášení zpochybnilo na základě zcela konkrétních faktů. Pokud to někdo dosud nechápe, a potřebuje k tomu prohlášení od boha nebo alespoň lennarta, je to jen jeho problém.

[lima]

Zacina to byt komedie ;) Cemu nerozumite ve vyrazu "glibc nebo glibc kompatibilni, jine nejsou podporovany" ?

[pavlix]

Výrok zněl:

To by mohol, aj tak systemd bez glibc nefunguje.

[little.owl]

systemd zavisi na glibc, jine C knihovny primo nepodporuje

To neznamena, ze nefunguje s jinymi.

glibc samotna ma extensions prevzate z jinych systemu, v pripade kdy to vyzaduje SW nebo to ma pro ne smysl, no a co?

[Michal Kubeček]

Jistě, neznamená to, že to v téhle konkrétní verzi s touto konkrétní knihovnou nefunguje. Ale znamená to, že se nemohu spolehnout, že to bude fungovat i ve verzi, která vyjde za týden nebo za půl roku, a co hůř, je dost velké riziko, že když to fungovat nebude a já pošlu patch, který to opraví, že bude odmítnut.

[Sid]

Mate pravdu, ale otazka je nakolko to ludi pali. Ked 99% nema problem s glibc tak potom sa to 1% musi prisposobit. V idealnom svete by samozrejme zavislost na konretnej implementacii nemala byt ale deje sa to bezne. Ked to prezeniem trocha tak sa staci pozriet na STL. Je sice pekne ze existuje a je x implementacii ale potom prichadza prakticka cast a to je, ze rozne implementacie implemntuje jednotlive algoritmy (struktury) rozne a to co vam niekde bezi v urcitej casovej zavisloti zistite ze na inej implemntacii je zufalo pomale atd. Takze riesenie bude, ze bud si napisete nieco vlastne co mate istotu ako sa sprava ale jednoducho sa zafixujete na konkretnu implementaciu o ktorej ako ma co implementovane.

[lima]

Hele, to uz asi nema cenu. Nikde nepopiram, ze to nejde prelozit s vetsim ci mensim usilim s jinyma knihovnama. Ani nevylucuju ze bude dochazet postupne k vetsi harmonizaci s glibc a formalne vzato s eglibc nebo uclibc ktere tu kompatibilitu deklaruji by melo jit zkompilovat rovnou. Nicmene pokud nedoslo v upstreamu systemd ke zmenam a plati ty puvodni proklamace, tak vsichni musi pocitat ze podporovana je jen glibc a ostatni se budou muset porad prizpusobovat zmenam, ke kterym v novych verzich muze dojit. A to nemluvim jak se LP a spol. uhlidaji, aby nevyuzivali implementacni detaily glibc.

[pavlix]

a odpoved je - nepravdive tvrzeni - pouziti uclibc je dukazem.

+1

Blbec není ten, kdo udělá chybu, ale ten, kdo na ní trvá.

[lima]

Blbec je ten, kdo popira pravidla formalni logiky a jeste to priznava.

[mankind_boost]

+1

[kralyk z abclinuxu]

aj tak systemd bez glibc nefunguje.

a odpoved je - nepravdive tvrzeni - pouziti uclibc je dukazem.

Ano, to je čistě formálně pravda, ale je to neúplná. Úplná pravda, je, že s uclibc to funguje jen díky tomu, že je dostatečně kompatibilní s glibc.

Nebo snad existuje libc, která je kompatibilní "pouze" se standardem, s glibc ne, ale funguje na ní systemd?

[pavlix]

Ano, to je čistě formálně pravda, ale je to neúplná. Úplná pravda, je, že s uclibc to funguje jen díky tomu, že je dostatečně kompatibilní s glibc.

Nebo díky tomu, že je dostatečně kompatibilní se systemd.

[Sid]

Nepiste ked tomu nerozumiete, to ze sa v embedded svete celkom normalne opatchuju niektore veci je bezne. Nakoniec ten SW je pisany povacsine tak aby bol co najminimalistickejsi (a obcas je trochu pozadu). Takze ked clovek nieco potrebuje tak si to sam fixne a urobi si novy image. Od toho nakoniec ma zdrojaky. Ked to poviem za seba tak napriklad ked sme chceli pouzit novsi boost a crosscompiler bol v starsej verzii tak sme proste drobne upravili zdrojaky a bolo. Vsetko je funkcne a to co vy vyvodzujete z tej odpovede co napisal tvorca systemd je blbost. Boost tie ma nejaku sadu podporovanych prekladacov ale to neznamena ze na inych nefunguje. To iba vy ste si dali rovnatko medzi nepodporovany a nefunkcny.

[lima]

To ja chapu, ale tady se nekdo nepravem obouval do jineho ze siri FUD. Tim ze musite opatchovat systemd nebo doplnit funkcionalitu glibc v jine C knihovne vlastne potvrzujete ze glibc je vyzadovano. S podobnou logikou byste mohl zavrhnout princip zavislosti, protoze teoreticky lze upravit api abyste cokoliv zkompiloval s cimkoli. GNOME 3.8+ taky vyzaduje systemd, bez ohledu ze se v openbsd podarilo rozsahlym patchovanim zprovoznit.

[Sid]

Robili ste niekedy nejaky vyvoj? mam pocit ze nie. Normalne pri hocicom je, ze sa stanovia podporovane platformy a prednostne sa riesia iba chyby ktore su tam. To ale automaticky neznamena, ze zvysok nefunguje akurat, ze team povacsine nema zdroje na riesenie vsetkych moznych variant. Takze kludne glibc moze byt vyzdaovane ale to stale neznamena, ze systemd nebezi na inej kniznici. A to ze nieco sa musi opatchovat je v poriadku. Casom sa mozno urobi aj oficialna podpora pre ine alternativy k glibc. Takze miesto vytrhavania veci z kontextu a nekonecnym opakovanim toho isteho to proste akceptujte ako fakt, ze takto to bezne funguje.

[Lol Phirae]

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář