EGLIBC-re vált a Debian projekt

 ( trey | 2009. május 6., szerda - 22:24 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

jo lesz ez nekunk?

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.. :)

ha a cikkben leirtaknak a fele is igaz (a linkelt oldalakat nem ovlastam), akkor imho igen :-)
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Meglepett ez a kijelentés és hogy jó-e? Megkérdezem Aurelien-t, ha már személyesen ismerem remélem nem küld el messzire. :-)

akkormost háromra mindenki plakátolja ki, hogy kit ismer személyesen

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

A blogbejegyzés alapján inkább egy durcás kisgyerek :)

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

Ők a Kommunikációs és Support-tanszék az Első Általános Egyetemen. :))

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Eleg szomoru, hogy mindenki vakon koveti a Debian-t, holott ez egy eleg nagy hordereju dontes. Megkockaztatom, hogy meg a XFree86/X.Org dontesnel is sokkal-sokkal nagyobb.
--

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

"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

Lehet, de nem érzem azonos súlycsoportnak az idióta licencet (amit nem lehet kikerülni) és az idióta karbantartót (akit igen).

Egy folyamatról beszéltem, ami lehet, hogy megismétlődhet. Nem az okra hoztam fel példaként. Nyilván mások az okok mindkét esetben, de a végeredmény lehet ugyanaz.

--
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

nem kizarhato h a redhat sztratoszfera magassagbol szarik ra h arm :)

--
.

Ja, azt tudjuk, hogy a Red Hat nem sz*rozik, ha sz*rni kell a dolgokra. Jött már tőlük olyan gcc verzió, amire az emberek csak néztek, mint lúd a piros kukoricára :D

--
trey @ gépház

ugyerted te vagy azok az adminok akiknek a cege ki tudja fizetni a licensz arat?

--
.

Nem érteni mit szeretnél mondani. Tán túl sokat külföldön voltál felejteni el nyelvet? :D

--
trey @ gépház

nevermind ujrafogalmazom:

hupon olvastad h problema van a redhatos gcc-vel?

--
.

Nem, a néhai MPlayer team sírta tele a világot annak idején vele azt hiszem. :D

--
trey @ gépház

eleg durva relevanci faktorral bir h a mplayer team mit gondol a redhatrol :)

irtam a fonokomnek h csereljuk le a redhatot debianra mert az mplayer team lehuzta oket

--
.

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......

8 eve vagy linux admin es meg nem hallottal a redhat gcc 2.96-rol?

- Use the Source Luke ! -

egeszen pontosan mi a problema denes?

--
.

csak segitettem, hogy mire gondolt trey

- Use the Source Luke ! -

tehat mi a problema azzal a gcc-vel?
--
.

a redhat sajat szakallara kiadta a bugos/inkompatibilis gcc development branch-et
lasd meg google

- Use the Source Luke ! -

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

--
.

te most tenyleg nem erted, hogy az volt a problema, hogy sokan sokaig nem tudtak hogy rossz a fordito, csak bugzottak a leforditott cuccok? Nyilvan ha mar tudtak hogy a fordito a rossz, fel tudtak tenni egy jo forditot.

- Use the Source Luke ! -

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.

> Mire akarsz kilyukadni?

Szerintem elfelejtette hogy mi a téma, mondanivaló híján pedig már csak az unaloműzés hajtja.

SEMMILYEN mas fordito nem volt kompatibilis az object koddal amit a 2.96 gyartott

de ez szerintem csak a c++ kodokra igaz, mert a c++ abi valoban valtozott a gcc 2 es 3 kozott, de a c abi az maradt.

- Use the Source Luke ! -

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
--
.

Nyilvan nem a helloworld, vagy a tesztesetek haltak meg, hanem a real life programok. Van amikor fel lehet dugni a test case-ket. Ez egy ilyen eset volt.
--

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

leirom nagy betukkel

HOGYA RETKES VERERES FAROKBA KERUL EGY NEM TESZTELT SZOFTVER A PRODCUTION KORNYEZETBE?
--
.

Ja kérem. Innen indultunk. Mármint onnan, hogy hogy a méteres, kék eres szögbe került egy nem tesztelt, ki nem adott gcc verzió a Red Hat-nál production környezetbe. :)

--
trey @ gépház

trey,

kenytelen vagyok ismetelten felhivni a figyelmed h semmit sem kommitolunk prod kornyzetbe csak azert mert a redhat betolta akarhova is

mindegy mert ugylatom nem ertitek

iratkozzatok vissza az apt-get update szakra meg ket felevre
--
.

Én Red Hat-ról beszéltem a kezdetek kezdetén is, meg most is. Nem tudom hogy jön ide az, hogy ti mit csináltatok. Azt másokkal beszélted.

--
trey @ gépház

Nem szeretnélek megbántani, de kérném a szóhasználatod felülvizsgálatát bizonyos pontokon... :(

+1
--

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

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.

En nem fogok valtani. Nem latom, hogy miert kene.
Embedded rendszereken uclibc -t hasznalok.
RPC meg kell az NFS -hez, elfer az egy liveCD -n.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

OFF

Az LGPL-hez hogy álltok? uClibc-vel statikusan linkelt alkalmazások forrását is ki kell adni, vagy nem? Vagy ez titeket nem érint?
Tudom, hogy az uClibc karbantartója szerint elég az object-eket kiadni, de a GPL-t értelmező jogászok szerint nem.

Ez nekem hobby, nem erint.
AFIAK statikusan linkelteket ki kell adni, LGPL ertelmezes szerint.
Ha a szerzo megengedni akkor megengedte, es kesz.

pl. SDL -nel, ha pengetsz akkor linkelhetsz statikusan zart kodhoz.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

uclibc-vel nem fordult az nvidia driver (x86 embedded, kellett a dualhead, az meg framebufferből nem megy), ezzel gondolom igen. Nem tudom, mondjuk hogy áll az uclibc-vel szemben, de egy próbát megér, ha kisebb lesz tőle a rendszer, ami ilyen környezetben fontos.

Sztem a uClibC-nel kissebb nem hiszem, hogy lesz, mert feature-kompatibilis a glibc-vel, ezert meretileg biztos nagyobb.
--

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

Szegény debian-userek akkor ebből mind kimaradnak jópár évig?
http://udrepper.livejournal.com/20948.html

Legjobb:
"I hope ubuntu will pick it up, will be good serious testing before it will go to debian stable lol"

Hat valoban, kimaradnak a jobol. Pl. ilyenekbol:

Idézet:
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?" -=-

Mi a baj vele? A printf() mindent elbír, nem kell ehhez függésben lennie semmiféle libxml-el.

Te most minden malloc leinformálás után XPath-ozni akarsz meg XMLDOM-ozni?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

A FAQ szerint korántsem:

"Contributors to EGLIBC should consider contributing to GLIBC. If the GLIBC maintainers accept the contribution, it will find its way into EGLIBC because the EGLIBC maintainers regularly merge GLIBC changes into EGLIBC."

Meg ebből is...

> 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????

ahaha azt nem tudom de gondolom az osszes debianos ksh-t hasznal :)
--
.

Forditasnal config scriptekhez kell shell :-)

"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.

Gentoo velemeny
--

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

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

mirol szol a FOSS?

pont arrol h nem a szakmai ervek dontenek :)
--
.

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.

jo nagy s*ggfej...