EGLIBC-re vált a Debian projekt

Debian

Aurelien blogbejegyzése szerint a Debian projekt EGLIBC-re vált. Ahogy az olvasható, nemrég feltöltötte azt az Embedded GLIBC-t (EGLIBC) az archive-ba, amely nemsokára leváltja a Debian-ban a GNU C Library-t (GLIBC).

Az EGLIBC egy olyan GLIBC variáns, amely forrás és bináris kompatibilis maradt az eredeti GLIBC-vel. Noha elsősorban a beágyazott rendszereket célozza, rendelkezik néhány "szép" tulajdonsággal:

  • More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this).
  • Stable branch with fixes for important bugs (a real one, not like the GLIBC one which is left unchanged).
  • Better support for embedded architectures.
  • Support for different shells (GLIBC only supports bash).
  • Support for building with -Os.
  • Configurable components (do we really need NIS or RPC support in debian-installer?).
  • Better testsuite for optimized or biarch packages.

A részletek itt olvashatók. Hozzászólások az LWN.net-en itt.

Nekem is pont ez a kerdes jutott eloszor az eszembe, aztan rajottem hogy ok biztosan okosabbak mint pl. en, igy ergo jo lesz nekunk, mert ha nekik jo, akkor jobb a Debian => Ubuntu (es a Debian szarmazekok).

Persze az is lehet hogy vakvaganyon gondolkozok, de ugye a rosszul patch-elt kernel sem az elso sor forditasa utan bugzik.. :)

( sandras74 | 2009. 05. 06., sze – 23:13 )

A Debian az úttörő vagy mások is használják már?

Ha a Debian vált az azt jelenti, hogy _valószínűleg_ az összes downstream projekt (Ubuntu, KNOPPIX és a millió Debian alapú cucc) váltani fog. Nem kizárt, hogy megismétlődik az XFree86/X.Org eset.

Használ még valaki XFree86-ot X.Org ellenében?

Egyébként ahogy olvastam, a Slashdot-on Drepper (a glibc karbantartója) hozzáállását kritizálják a legtöbben. Egyesek olyan nevekkel említik együtt kommunikációban, mint Jörg Schilling vagy Theo de Raadt. :)

--
trey @ gépház

"Eleg szomoru, hogy mindenki vakon koveti a Debian-t,"

Ilyet senki sem állított. Én azt mondtam, hogy valószínűleg és még alá is húztam. Ráadásul ez csak az én tippem. :) Egy dologban biztos lehetsz, ha valahol, akkor a Debian-nál ezt a kérdést át fogják rendesen flamelni beszélni. Képesek sokkal kisebb dolgokon is évekig rágódni.

--
trey @ gépház

Ok, de az hogy a debianosok nem szeretik a karbantartót, nem hiszem hogy elég erős ok a nem-debian származékok számára a váltásra, még azzal együtt sem hogy "hát biztos tudják mit csinálnak, utánozzuk őket". Plusz, a redhat már csak politikai okból sem fogja azt mondani, hogy hát igen, ennek az embernek az agyára ment valami (pl. hogy már tizenvalahány éve ugyanez a munkája) :).

Kicsit inkább arra hasonlít ez, mint amikor valakinek elege lett egyes debianosok keményfejűségéből és saját forkot csinált, amit időnként azért szinkronizálnak a Debiannal - emiatt se halt ki a szülőprojekt, helyette mindkettő köszöni jól van.

Tegyük fel, hogy ez a megoldás hozza azt, amit leírtak.

A következő év arról fog szólni, hogy jönnek az ARM-alapú netbookok. Ha ez az új stuff azt jobban támogatja, akkor nem kizárt, hogy mások is váltanak. Állítólag pont ezen vesztek össze. Mármint Drepper és a Debian. Nem véletlenül emelték ki ezt:

"More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this)."

Most képzeld el, hogy van valaminek egy újabb verziója, ami ugyanazt tudja pontosan mint a régi, de még annál többet is kínál? Ki az aki technikai oldalról megközelítve azt mondaná, hogy ne váltsunk?

Max. politikai döntést tudnék ebben az esetben elképzelni, ami ellene meg a jobb megoldás befogadásának. De kérdés, hogy egy rossz döntést meddig lehet védeni politikai okokból.

--
trey @ gépház

Igazabol az mplayer team nem allt egyedul a velemenyevel, sot. Ha jol remlik, akkor kb. azonos velemenyen voltak pl. a GCC fejlesztok is. Kulon kiirtak a gcc honlapra, hogy semmi kozuk a 2.96-os verziohoz.

De hat persze mindenki hibazhat. Meg azota mar van fedora es abba toljak bele az alpha-beta cuccaikat......

szomoru :(

tehat megintcsak megkerdem mi a problema

elmondom nalunk hogy megy

yum install anyad

nincsen sajat forgatott csomagunk mert nem kell... ergo lehet a gcc devel de lefosom ha esetleg kelleni fog es devel es ez problemat okoz AKKOR FELRAKOM A REGEBBIT

tehat 0 problemat okozHATOTT volna h a redhat azt a gcct adta ki

erdekes modon a gettyre rugalmas hires "megpecseltem a kernelt h menjen a matshusita cdrom" denes fennakad egy ennyire aprocska atlagos junior admin altal is megoldhato probleman?

ne rohogtessel mar

--
.

Nem volt hivatalos 2.96-os gcc verzió. A RedHat 7.0-ban a leendő 3.0 aktuális CVS snapshot-ját adták ki 2.96 címén. És vagy fejlesztés közepén voltak a gcc-sek, vagy volt még benne hiba, de a lényeg, hogy a C++ fordító kicsit különbözött a 2.95-től. (Ha jól rémlik, a constructor-ok másképp működtek, de nem biztos.) És ebből a legkülönbözőbb fagyások jöttek elő, de csak ritkán, és csak akkor, ha bináris progikat hurcolt az ember disztrók között. A legszivatósabb az volt, hogy a máshol fordított progik elindultak RedHat alatt is, csak aztán néha-néha lefagytak.

tehat felraktam valamikor egy redhatot es eppen update elott vagyunk, nem nezek bele az update infoba, nem olasok levlistat, leszarom h bugos a fordito es az osszes esetleg azzal forditott csomag, hanem egybol felupdatelem a cluster osszes tagjat, kihagyva a test es staging allpotokat(ahol legrosszabb esetben is heteket fut a updatelt rendszer mielott prod lenne belole)

ennek a valoszinusege a mi cegunknel nulla, nem tudom nalatok hogy megy biztos nem erdekes a folyamatos uzem

legrosszabb esetben on hold-ra baszom az osszes operacios rendszerre vonatkozo updatet amig ki nem jon a fix es utana updatelek ha nagyon muszaj. perpill csak security patcheket rakunk fel 90%ban a gepekre miutan szenneteszteltuk.

"fordító kicsit különbözött a 2.95-től."

tehat volt egy jo allapota egyszer annak a nyomorult linuxnak ugye?

--
.

Mire akarsz kilyukadni? Abban, hogy a RH elb...ta, azt hiszem mar megegyeztunk. Azt, hogy a ti rendszereteket senki es semmi nem tudja elb...ni en keszseggel elhiszem neked.

tehat volt egy jo allapota egyszer annak a nyomorult linuxnak ugye

Nem Linux, GCC, erted? :)

Par adalek a sztorihoz:
- ha jol emlekszem, akkor honapokig nem tortent semmi a RH reszerol, kiveve, hogy a minden websiterol leszedettek a nekik nem tetszo szovegeket, pl. az mplayer websiterol is, hogy "ne forditsd 2.96-tal, mert az szar". Meg a gcc website-ra sem mertek kiirni, hogy a RH elbaszta, hanem csak azt, hogy "egyes linux disztrok".
- egy regebbi fordito semmit nem oldott meg, mert SEMMILYEN mas fordito nem volt kompatibilis az object koddal amit a 2.96 gyartott.

Ha jol emlekszem, de javitson ki barki ha tevedek.

Sajnos nem találtam meg, hogy mi volt a konrét hiba (ez már majdnem 10 éve volt! ), de nekem két dolog rémlik, és lehet, hogy egy harmadik volt a hiba:
- a constructor-ok viselkedése
- függvényelnevezési konvenciók változása (valamiért ez tűnik sanszosabbnak, de nem tudom, hogyan vezethetett kiszámíthatatlan fagyásokhoz). Mert ugye a C++ fordítók a getLength, meg hasonló nevű függvényekből gyártanak valami __xyzgetLengthabcd nevű függvényt, ahol a mindenféle betűk utalnak a paraméterekre. Asszem ez az elnevezési konvenció változott a 2-es és a 3-as gpp között, de egyáltalán nem biztos.

Bammeg, senki nem fogja a changelogba beirni, hogy barom ne frissitsel ra, mert bugosan adtuk ki. Arrol nem beszelve, hogy nem a gcc _binaris_ volt konkretan bugos (ugy ertem, hogy nem segfaultolt forditas kozben, es attol panikoltak be emberek), hanme az _altala gyartott kod_ fagyott random modon. Namarmost, elso korben egy hibas forditott kod _elsodlegesen_ a forras hibajara utal, es csak nagyon sokadlagosan utal fordito hibara, ertem? Tehat, ki kellett minden fejlesztonek tesztelni, hogy nem-e az o kodja bugos, es csak aztan kezdtek a forditot hibaztatni. Mivel ez nem egy gyors folyamat, addigra a fel redhates vilag mar frissitett erre a gcc verziora, downgrade szopas, innentol kezdve sok ut nem volt.

De ha nem ismered a tortenetet, talan nem kellene ilyen vitaba belemenni, hanem meg kellene vegre tanulni hasznalni azt a rohadt Google-t. Borzasztoan unom mar, hogy erteni semmit nem ertesz a dologhoz, de nekiallsz vitatkozni, akkor is, amikor mar regen kiderult, hogy nincs igazad. Egyszer elmegy, ketszer elmegy, de te ebbol mar rendszert csinalsz (nem akarom mondani, hogy elvezed), es az mar senkinek nem jo (max neked).

Jo tanacs:
1) tanulj meg olvasni
2) tanulj meg irni
3) tanulj meg hallgatni
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Bammeg, senki nem fogja a changelogba beirni, hogy barom ne frissitsel ra, mert bugosan adtuk ki"

nem ezt en fogom irni a testcase vegere h nem javaslom a PROD rendszer frissiteset mert szethalt minden a bugos gcc miatt a testing fazisban

Jo tanacs:
1) tanulj meg olvasni
2) tanulj meg irni
3) tanulj meg hallgatni

+1
--
.

Akor nezz meg egy akkori csomagot, gyakorlatilag mindegyikben volt egy compile fix gcc296 patch. Nalunk az mplayer volt a leghangosabb, de kuzdott vele a libc is, ami azert kozel all a redhat-hoz, es ami hirtelen beugrik, a kernelen kivul az a pdns. De SZVSZ, eleg sok volt meg. Ja a samba is. Minden egyeni es ertelmes repoban volt egy "regi" gcc is.

Hat valoban, kimaradnak a jobol. Pl. ilyenekbol:

The new malloc_info function therefore does not export a structure. Instead it exports the information in a self-describing data structure. Nowadays the preferred way to do this is via XML. The format can change over time (it’s versioned), some fields will stay the same, other will change. No breakage. The reader just cannot assume that all the information will forever be available in the same form. There is no reader in glibc. This isn’t necessary, it’s easy enough to write outside glibc using one of the many XML libraries.

Amelyik libc XML-ben akar visszaadni barmit, az az ordogtol valo, es pusztulnia kell. Pont. Es ez csak a sok erv egyike.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( Zahy v | 2009. 05. 07., cs – 14:41 )

> Support for different shells (GLIBC only supports bash).

Nem kerestem utána, de valaki akinek megy fejből, az igazán leírhatná, hogy egy fv-könyvtárba milyen shell-támogatás kell????

( ngaba | 2009. 05. 07., cs – 18:13 )

"More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this)."

Ez egyrészt bullshit marketing duma, másrészt sértődött "hülye a másik" kinyilatkoztatás.

Korrekt írás.
Az biztos, hogy Ulrich elég összeférhetetlen emberke lehet.
érdemes megnézni a commentjei stílusát, sajnos a linkek lemaradtak a hírből:
as opposed to this

Ugyanakkor az is biztos, hogy sokmindent letett már az asztalra, ha jól tudom ő kezdte el portolni linuxra a glibc 1.09 -et, amiből végül lett a glibc 2.0.

Idővel kiderül jó döntés volt-e áttérni :)
__________________________________________
még nincsen kész, de már majdnem elkezdtem

Úgy gondolom, hogy aki ilyen mentalitással dolgozik, azzal senki nem kooperál szívesen. A FOSS meg pont erről szólna.

Legyen bármilyen jó programozó is, ilyen gyerekes hozzáállással húzzon a francba.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Azert kulonbseg van akozott, hogy nincsenek szakmai ervek, es hogy nincsenek _egyaltalan_ ervek. Hogy harapofogoval kell kihuzni valakibol, hogy egy bugot miert zart le worksforme lezarassal, az nagyon nem kicsit durva dolog. Arrol nem beszelve, hogy miutan vegre elmondja, hogy mar atirta a kerdeses kodreszletet, se linket, se commit id-t nem ad, hogy ez bizonyithato legyen.

Az mar csak hab a tortan, hogy szembehelyezkedik RFC-vel, plusz kozli, hogy az o hulyesegehez inkabb majd a alkalmazasfejlesztok igazodjanak. Nevetseges dolog.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.