Karbantartó hiányában repülhet az Itanium támogatás a Linux kernelből

Kernel

Egy az LKML-re küldött RFC szerint az IA64-nek nincs karbantartója, valójában felhasználói bázisa sem, hónapok óta hibás a kódja és a kutya sem törődik ezzel. Így, a javaslat szerint mehetne a kernelből. A kiebrudalásával fejlesztői erőforrás szabadulna fel, illetve a Linux kernel több mint 65 ezer kódsorral karcsúsodna.

( _ventura_ v | 2023. 02. 16., cs – 15:57 )

Hát nem tudom de nekem ez a két félmondat

nincs karbantartója, valójában felhasználói bázisa sem, hónapok óta hibás a kódja és a kutya sem törődik ezzel.

és

fejlesztői erőforrás szabadulna fel

ellentmondásosnak tűnik. Ha fejlesztő szabadul fel, akkor akik felszabadulnak mit csinálnak mert első mondat szerint semmit :D

Fedora 41, Thinkpad x280

( Caro | 2023. 02. 16., cs – 18:35 )

Karbantartó hiányában? Nem felhasználó hiányában?

( uid_6201 v | 2023. 02. 16., cs – 19:04 )

Szerkesztve: 2023. 02. 16., cs – 19:09

Az Itanium mint processzortípus döglött. Végleg.
https://www.hwsw.hu/hirek/63559/intel-itanium-cp-szerver-kittson-proces…

Nem hozta be a hozzá fűzött reményeket, nyögvenyelős termék lett. Már 4 éve eltemette az Intel.
Az utsó Itaniumos 6.x-es kernellel elfut még még vagy 6..7 évet, addig lesz rá kerneltámogatás. Aztán addigra a maradék Itaniumos cucc is kukázva lesz.

Már a kiadásakor halálra volt ítélve, a kutyának nem kellett volna már akkor se, csak az Intel marketingesei erőltették az egészet, hogy csörögjön a kassza. Már akkor a hírek hallatán fogta a fejét, aki értett hozzá, azonnal látszott, hogy nem lesz jövője az egyre erősödő x86 ág mellett. Ráadásul szegény RISC Alpha platformot beszántották miatta, pedig abban talán még lett is volna fantázia. Legendás szégyentermék az egész Itanium platform. Hála istennek sose találkoztam vele sehol a gyakorlatban, de akinek állítólag volt vele ténylegesen is dolga, annak is életre szóló traumát okoz.

Nem lennék meglepődve ha már egy ideje az új Linux kernelek le sem fordulnának vagy futnának rajta, csak azért nem vették észre eddig, mert máris nem használja a kutya sem, az az 1-2 cég, aki rajta ragadt, az is HP-UX-szel vagy valami spéci, zárt legacy OS-sel használja, nem modern Linux fut rajta. Már kukázni kellett volna az egészet egy évtizede, nem még újabb 6-7 évig lélegeztetőgépen tartani.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az Itaniumot vélhetőleg a zsákutcás Netburst keltette életre. Nagyon lassúak voltak a Pentium4 XEON-ok. És persze a 64 bit, a 4GB-nál több lineáris címtér volt a mézesmadzag, aminek az AMD vágott alá.
Nem véletlen tért vissza az Intel a Pentium III vonalra (Core2, XEON 5140 már ez). Persze óvatosan kellett beadagolni a befektetőknek ezt a drága zsákutcát. Innentől az Itanium előnyei (64 bit, gyorsabb a Pentium4 vonalbeli XEON-nál) a 64 bites Core2 korszaktól elolvadtak.

Egy benchmarkot találtam, de csak régi Itanium2 van benne: https://www.7-cpu.com/
Fellelhető valahol valami frissebb Itaniummal összehasonlítás?

Miféle sok-sok évig pátyolgatott Netburst? A NetBurst-ös mikroarchitektúrájú CPU-k 2000-ben jelentek meg, a Netburstos Xeonok 2004-ben, 2008-ban pedig kivezették az egészet. 8 év volt a Netburst. 
Az Itanium tervezése a megjelenéséig több ideig tartott, mint ameddig a Netburst létezett. 

Az egész Itanium vonalnak semmi, de semmi köze az X86-os Intel termékek mikroarchitektúrájához, baromira nem azt a piacot célozta, és nem abból a célból, amire próbálnál utalni.

Az Itanium miért is lett volna sokkal gyorsabb a Netburstös X86 CPU-któl? Szar compilerek voltak rá, emiatt nem tudták jól kihasználni a hardvert. Az Itanium legnagyobb gondja ez volt, hogy szoftverszinten nem volt visszafelé kompatibilis az X86-tal, emiatt lett népszerű az AMD64, és ezért választotta az Intel a Xeon processzorok ISA-jának az AMD64-et az IA-64 helyett: arra egyszerű volt upgradelni, Itaniumra nem.

Az egész Itanium-sorozat a HP igénye volt valójában, semmi más. Semmi köze nem volt sem a Netbursthöz, sem az X86-AMD64 dolgokhoz, az Intel a CPU tervező és építő tudást adta, a HP meg a szerverpiacot hozzá. Csak épp az ISV-ket hagyták ki a képletből, emiatt nem volt rá szoftver és bukott be az egész.

Köszi, akkor eddig én gondoltam ezt rosszul.
Mindenesetre furi volt, hogy a szerverben levő RAM mennyisége miatt egyre inkább "szorító cipő" ellenére a 64 bites módot az Intel nem akarta bedobni és végül az AMD dobta be, az Intel pedig utánaszaladt.
Eddig én az ezidőtájt elég erőteljes Itanium erőltetéshez kapcsoltam. De ekkor ez csak véletlen.
Az viszont látszik, hogy elszaladt felette az idő. Nem váltotta be a hozzá fűzött reményeket. Béke poraira.

Egyébként 32 bites rendszereknél a memória belapozás (PAE) teljesen jól működött, kivéve ha az adott processznek kellett 4 GB-nál több memória. Hiszen nem tudta a processz kicímezni.

Ez így van. Sokáig nagyon drága volt az egész Unix-világ, eleve már a szoftver is sok ezer dollárokat kóstált, annyira, hogy átlag ember meg se tudta venni, csak intézmények, cégek, kormányzati szervek, és akkor az alá való vasakról nem is beszéltünk, amiknek sokszorosan ilyen durva ára volt. Ez csak ilyen modern kori fejlemény, hogy mindenkinek hozzáférhető a normálisabban használható, megfizethető x86-os hardver, és rá ezek a Unix-klónok is elkezdtek FLOSS-osak lenni, régen erről álmodni se lehetett.

Mára tényleg csak az AIX, HP-UX, QNX maradt már a zárt, fizetős Unix-okból, a többi beleállt a földbe, SunOS, SCO Unix, stb., vagy átment free licences nyílt cuccba, pl. Solaris-ból OpenSolaris-ból illumos-alapú disztrók, Minix is nyílt lett egy ideje, stb.. Zárójelesen a MacOS-t lehetne még megjegyezni, de az kb. annyira Unix, ahogy én vagyok kínai néger. Nem érdekel, hogy milyen bash meg zsh hogy elérhető rajta, meg hogy hivatalosan mennyire certified Unix, lényegében egy teljesen zárt, kereskedelmi, GUI, normi OS, csak lehet rajta nyitni terminálban shellt, meg van némi fokú POSIX kompatibiltása, de egy vicc az az egész rendszer, az egész Apple ökoszisztémával együtt. Hasonlóan volt durva vicc a MS-os Xenix is. A Windows POSIX kompatibilitása is vicc kategória természetesen.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Sokáig nagyon drága volt az egész Unix-világ, eleve már a szoftver is sok ezer dollárokat kóstált, annyira, hogy átlag ember meg se tudta venni, csak intézmények, cégek, kormányzati szervek

Egy érdekes mellékhatása is volt: kevésbé kellett tartani a szkript-kölyköktől és hasonló támadási formáktól. Hiszen kutya nem értett hozzá a szűk körön kívül. Ma az olcsó, uniformizált rendszerek ennek pontosan az ellentéte. Bármi apró, de ütős kiderül a legutolsó hackerklubban, az félő hogy Paks2 és hasonló kritikus infrastruktúrát is érintheti, hiszen pontosan ugyanezekből a protokollokból és ugyanezekből az operációs rendszerekből akar ma mindenki építkezni az olcsóság és csereszabatosság okán.

( turul16 v | 2023. 02. 17., p – 08:19 )

Valoszinuleg elni fognak 5 ev mulva is (altalnos celu, mmu -val rendelkezo):
arm 32/64
x86 64
power 64
risc-v 32/64 (128) (hard and soft core)
s390

Nem altalnos celu core-ok lesznek ezeken kivul is, de az nem tul relevans linux/bsd szempontbol.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Ritter | 2023. 02. 17., p – 13:00 )

Érdekes, hogy pont az orosz Elbrusz marad az utolsó VLIW amely talpon maradt. 

De az nem olyan, mint a Transmeta, hogy hardveresen fordít más utasításkészletből? Vagy direktben is lehet programozni?

Amúgy ha most kezdenék a nagyok VLIW-et (és nem lenne ennyire hányattatott történelme), mai fordítókkal is bukta lenne?

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( Celtic v | 2023. 02. 17., p – 13:10 )

Szerkesztve: 2023. 02. 17., p – 13:11

"az IA64-nek nincs karbantartója ..... A kiebrudalásával fejlesztői erőforrás szabadulna fel,"

Ez nekem ellentmondásos. Ha kutya nem nyúl hozzá, akkor mi szabadul fel ?

update: most látom, másnak is feltűnt. Előbb írtam, mint olvastam

http://www.micros~1
Rekurzió: lásd rekurzió.

( sibike | 2023. 02. 18., szo – 20:26 )

Ez is fáj nekik

The largest painpoint IMO is absence of any ability to test ia64 except
sending patches to Adrian in a hope he has time to give them a whirl.

https://lore.kernel.org/lkml/Y+25dZiA+xnZRgVX@kernel.org/

Bár én azt gondoltam, hogy ezek a dolgok '22-ben automatizálhatóak: x időnként bebootol a szerver egy szűz kernelt és lefuttat egy basic test suite-ot.