Ulrich Drepper eltávolította az ia64 támogatást a glibc-ből

Programozás

Ulrich Drepper karácsonykor egy levelet küldött a libc-hacker levelezési listára, amelyben gyakorlatilag közölte, hogy amint megindul a glibc 2.16-os verziójának fejlesztése, eltávolítja az ia64 (Intel Itanium, nem keverendő az x86_64-gyel) támogatást a fő forrásfából és áthelyezi a ports-ba. Ulrich azzal magyarázta a lépést, hogy úgy hiszi, mindenki egyetért abban, hogy az Itanium halott. Hat nappal ezelőtt a 2.16 fejlesztése megkezdődött. Ulrich pedig ígéretéhez híven nekiállt az ia64 támogatás eltávolításának.

( Boobek | 2012. 01. 08., v – 12:51 )

Nem vagyok nagy tudor ezen a téren de:
Ez minimális gyorsulással is jár vagy csak kód tisztulást eredményez?
Milyen egyéb pozitívum származik ebből?

Ezért is írtam a parentbe a string függvényeket és nem az egész libc-t, Mr Cpt. Obvious.

A lényegi posztom: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamo…

Ha már egyszer visszalinkelték ezt a topicot, gondoltam tisztázom már ezt. :P

--
GPLv3-as hozzászólás.

> De igen, a string függvények elég jól kandidálnak a feladat specifikus optimalizálandó függvények csoportjába. ^^

http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamo…

Ez az én parentem a te stringes posztodhoz. Tehát én írtam. És soha ne sajnáld.

--
GPLv3-as hozzászólás.

Nézd az eredeti posztom tényleg könnyen félre érthető volt, ezt elismerem. Viszont egy későbbi posztomba sztem tisztáztam, hogy mire gondoltam.

Eredeti poszt: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamo…

És a javító posztom: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamo…

Majd megemlítésre kerültek a string fgv-ek: http://hup.hu/cikkek/20120108/ulrich_drepper_eltavolitotta_az_ia64_tamo…

Egyébként volt már alkalmam olyan projektben részt venni ahol feladat specifikus string függvényeket kellett írni a számottevő gyorsulás érdekében. (Majd ha még eszembe jut másik eset is, azt is megosztom ha kell.)

--
GPLv3-as hozzászólás.

Semmi extra, kukáztak egy halott arch támogatását. Gyakorlatilag töröltek egy valagnyi fájlt, mást még nagyon nem csináltak. Ezek viszont csak IA64-es glibc-be fordultak be, semmi egyebet nem érintett.

Nem értem, miért kellene, hogy bármi kapcsolata legyen más archokkal :)

----------------
Lvl86 Troll

( Zahy v | 2012. 01. 08., v – 12:54 )

Kivéve az Intelt :-) (meg persze a HP-t.)

( malcolm | 2012. 01. 08., v – 13:09 )

Véletlenül került a hír a Progeny Linux kategóriába?
Vagy van valami köze a Progeny-hez?

( Replaced | 2012. 01. 08., v – 13:54 )

szoval igy akar a red hat tisztessegtelen elonyt szerezni a hp-val szemben...

--
NetBSD - Simplicity is prerequisite for reliability

drepperrol mindenki tudja, hogy csak a paycheck-je erdekli, szoval kinek volt az erdeke? :p

Még mindig nem értem. Vegyül pl. a RHEL-t. Az a döntés, hogy a RHEL-6 nem fogja támogatni az IA64-et (valamint az, hogy a RHEL-5 igen), sokkal korábban meghozatott, mint Drepper idei karácsonya. Vagyis az, hogy Drepper most a 2.16-ból kiirtja az IA64 támogatást, nagyjából édesmindegy kell legyen a HP-nek. Csak akkor számítana, ha valamelyik hivatalosan támogatott disztribúció Drepper lépése miatt dobná az IA64-et. Nincs ok-okozati összefüggés glibc és disztrók között. Az IA64-re visszaesett a kereslet, ezt követik (egymástól függetlenül) különféle gyártók.

http://en.wikipedia.org/wiki/Itanium#Software_support

However, Microsoft announced in 2010 that Windows Server 2008 R2 will be the last version of Windows Server to support the Itanium, and that it would also discontinue development of the Itanium versions of Visual Studio and SQL Server.[12] Likewise, Red Hat Enterprise Linux 5 was the last Itanium edition of Red Hat Enterprise Linux[13] and Canonical's Ubuntu 10.04 LTS was the last supported Ubuntu release on Itanium.[58] HP will not be supporting or certifying Linux on Itanium 9300 (Tukwila) servers.[59]

Oracle Corporation announced in March 2011 that it would drop development of application software for Itanium platforms, with the explanation that "Intel management made it clear that their strategic focus is on their x86 microprocessor and that Itanium was nearing the end of its life."[60]

(Magánvélemény.)

Az pedig 100%-ig rendben van, hogy Dreppert csak a paycheck-je érdekli. Feltehetően iszonyat munka a glibc karbantartása. A kód licensze adott, Drepper meg arra fordítja az idejét, amire akarja / amiért megfizetik. Ha nem tetszik, amerre a glibc-t viszi, lehet neki pénzt adni, vagy lehet forkolni a glibc-t. (Ahogy meg is történt pl. az eglibc-vel.)

Soha nem értettem a szájhabzást Drepperrel kapcsolatban. Eddig egy glibc hibát jelentettem (getconf probléma), villámgyorsan megfixálta. Az strlcpy() témában szimplán igaza van. Szabad szoftveren dolgozni nem jelenti azt, hogy a felhasználók dirigálnának neki. És így tovább. Emellett rendkívül értékes szöveges anyagokat készített.

Hű, ez a posztod frissülhetett, mióta utolszor olvastam. Na, ráugrok még egyszer. Köszi :)

... Ez tényleg gáz. Visszagondolva, már legutóbb is azért nem kommenteltem a posztod alá, mert Drepper álláspontja itt nem védhető. A POSIX-ra való hivatkozással mondjuk nem értek egyet (a libc részét képezi a POSIX implementációnak, tehát belül azt csinál, amit akar (szerk.: legalábbis "összerakott", tanúsításra szánt kernel kíséretében, bár ennek megjelölésével Drepper szintén adós maradt)), ugyanakkor ha máshol nem is, ott mindenképpen megbukik a dolog, hogy egyszerűen nincs olyan kernel, amely garantálná az mprotect() sikerességét minden körülmények között: http://sourceware.org/bugzilla/show_bug.cgi?id=12492#c4

( kisauto | 2012. 01. 08., v – 15:43 )

Az itánium halott?

Jó, hát törjék el a kezem, ha Itániumon glibc -t akarnék használni, de akkor is, hogy lehet már ilyet írni?:)

Szer: amúgy válaszként a HP álljon már le a Linux eröltetésével. Imho teljesen felesleges.

lsd parisc :)
de akkor sem ertem, miert halott.

Kell legyen annak oka, hogy a HP eloszor PA-RISC -et majd Itaniumot rakott a gepeibe.
Trivialisabb lett volna egy HP-Ux for X86_64 release, de valahogy ez nem kovetkezett be.

Nyilvan gazdasagi az erdek pl. oracle oldalan. Minek tobb architekturara fejleszteni es optimalizalni, ha egyszer a piac jelentos resze x86.

Kell legyen annak oka, hogy a HP eloszor PA-RISC -et majd Itaniumot rakott a gepeibe.

Természetesen van oka: The architecture originated at Hewlett-Packard (HP), and was later jointly developed by HP and Intel. (wikipedia).

Bizonyára láttál már IA64 assembly-t; az egész brutális out-of-order execution-re, spekulációra, a pipeline megtöltve tartására van kihegyezve. A "sufficiently smart compiler" alá készült platformnak; a fordító feladata (mondjuk) C-ből előállítani azt az IA64 assembly-t, amely a processzor számára lehetővé teszi a maximális párhuzamosítást, spekulációt és így tovább. Sajnos ezeket a fordítókat azóta sem sikerült megírni (parafrázis Knuth-tól, lásd ismét a wikipedia-t és az onnan linkelt interjút). A gcc-nél pl. nem ritka, ha jól láttam, hogy a lényeget belerakja az insn bundle 0-s slot-jába, a másik két slot-ot meg kitölti nop.i-vel.

Az Intel C fordító nem tudom, milyen assembly-t generál, de ha tökéletesen kihasználná a processzor képességeit, valószínűleg nem léptek volna ennyien olajra.

Trivialisabb lett volna egy HP-Ux for X86_64 release, de valahogy ez nem kovetkezett be.

Nem, mert ha már volt processzor, akkor bizonyára használni kellett ("majd idővel lesz jobb fordítónk is"), valamint az x86_64 is kétségkívül egy fostalicska (nem (csak) az utasításkészlet, hanem az egész architektúra, úgy, ahogy van).

Ami betűszó az architektúra kapcsán eszedbe juthat, az mind toldott-foldott. Például van benne egy valag óra (tsc hpet pit pmtimer rtc), részlegesen átfedő felhasználási területekkel. A PCI konfiguráció szét van szórva minimum PCI config space-be meg ACPI táblákba. Ötvenféle cache van. Az MTRR inicializació (rendezvous) többmagos gépen külön diplomát igényel. Nehéz eldönteni, hogy az UEFI kínosabb-e, vagy a BIOS. MSI, MSI-X. Szegmentáció. És így tovább.

Természetesen ezek legtöbbjével csak igen felületesen találkozom, de ilyenkor mindig előkerülnek a manual-ok, és egyre jobban gúvad a szemem, hogy hogyan bírtak ilyet összehozni. Semmi sincs, ami önálló, szeparált lenne; minden mindenbe belelóg. Addig persze semmi baj nincs velük, amíg nincs hiba :)

Nem tudom, hogyan lehetett volna szebben-jobban megcsinálni (ráadásul a piacra koncentrálva), de ettől még hajmeresztő.

Na igen. En ugyan csak messzirol szagolgatom ezeket, de azert elborzaszto latni, hogy a hackintoshnal is mit ossze kinlodnak a fejlesztok. Es egyaltalan nem amiatt, mert meg kell kerulni az apple vedelmeit, az bakfitty. Ilyen hardver, olyan driver, most acpi-t kell hekkelni, most ki kell kapcsolni a BIOS-ban a legacy USB tamogatast, mert nem bootol tole a gep, CPU-t kell konfiguralni, mert hulyesegek jonnek ki belole... doh. De lehet, hogy mivel en nem ertek hozza, ezert csak a problemakat latom.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

amúgy válaszként a HP álljon már le a Linux eröltetésével. Imho teljesen felesleges.

"HP is not planning to certify or support any Linux distribution on the new Integrity servers based on the Intel Itanium processor 9300 series."

http://h20341.www2.hp.com/integrity/w1/en/os/linux-on-integrity-overvie…

( hrgy84 | 2012. 01. 10., k – 19:42 )

Mar nem tudom kovetni, ez most akkor a sima glibc, vagy az eglibc, vagy valami mas?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal