A Sun törölte a Rock processzort

 ( trey | 2009. június 16., kedd - 12:04 )

Jelek már korábban is voltak arra, hogy a késhet a Sun "Rock" kódnevű, következő generációs, nagyvállalati rendszerekbe szánt processzora és az csak valamikor 2009 első felében kerülhet az ügyfelekhez. Most azonban úgy fest, hogy a Sun Microsystems több mint öt év fejlesztés után sutba dobta a Rock kódnévre hallgató, 16 magos, UltraSPARC RK processzorának fejlesztését.

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

Gondolom felerősödnek majd a hangok, amelyek úgy vélik, hogy az Oracle-nek nem kell a Sun hardver üzletága, bármit is mondott Ellison. A SEC-hez benyújtott jelentésből állítólag kiderül, hogy az Oracle-nek eredetileg nem volt szándékában megvenni a Sun hardver üzletágát.

"By the way, as Sun revealed in filings with the Securities and Exchange Commission, Oracle didn't originally want Sun's hardware business."

--
trey @ gépház

Nincs kérdőjel, és nem állítólag, hanem tényleg csak a szoftvereket akarta először.

"Az Oracle március 12-én tett egy javaslatot, melynek értelmében felvásárolná a Sun egyes szoftvereit, kisebbségi befektetést tenne a cégben, és további stratégiai megállapodásokat kötne. A Sun elutasította ezt az ajánlatot, és folytatta megbeszéléseit az IBM-mel."

http://href.hu/x/9ak3

A végén a link a SEC filingra.

---------------
mpu.buzz.hu

Értem, hogy nincs kérdőjel, de azon kívül, hogy

"A faithful source - a former Sun employee who requested anonymity and who still has deep ties with the server maker - said that he was told by a high-ranking Sun exec this morning that the Rock chip was canceled. The New York Times is also running a story that cites two people familiar with Sun's plans (and who also requested anonymity) as saying that Sun has canceled the Rock chip project."

Van valami hivatalosabbnak látszó? Mert én még nem találtam. Ezek elég másodkézből származó infók. Nyilván lehetnek igazak is - sőt majdnem biztos, hogy azok - de hát amíg ezt hivatalosan meg nem erősítik...

--
trey @ gépház

A mi anyagunk nem az NYT forrásra épült, és nem volt benne feltételes mód.

Az persze a mi hibánk, hogy nem vagyunk mérvadóak.

---------------
mpu.buzz.hu

Itt az olvasható, hogy a döntés oka nem az Oracle, hanem a Rock zsákutca mivolta...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

kár érte. kiadhatnák a korábbi niagara processzorokhoz hasonlóan a verilog forrást, isa specet, és eddig elkészült szimulációs rock cuccokat gpl alatt. hátha majd egyszer valaki...

________
61>09

Na persze. Azt a par szazmilliot, amit beleoltek, meg dobjak ki az ablakon.
Ha csak 10% eselye is van, hogy el lehet passzolni valakinek 1 milkaert, akkor mar nem fogjak megtenni ezt. Marpedig annyi esely van ra.

már nem így működik a világ. ezelőtt is megtették.
__________
61>09

Niagarák hogy fogytak? Egyáltalán volt rá esély (a jelen gazd. helyzetben), hogy a fejlesztés megtérül?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Szerintem, amikor a Sun felvette a portfóliójába az AMD és utána az Intel-alapú szervereket, azzal gyakorlatilag el is mondta, hogy mennyire megtérülő, vagy jövedelmező a SPARC vonal. Utána kezdtek egy kicsit elkezdeni kapaszkodni felfele.

--
trey @ gépház

V40Z-vel nagy sikert nem értek el.Legalábbis nálunk. Az "újabb" masinák már jobbak! :)

A V40Z nem Sun fejlesztésű volt simán vettek egy OEM gépet és matricázták. És igen keservesen sz*r. :)

Azt nem tudom miért kellett rá a Sun embléma? :)

Így lett belőle brand gép.

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

Hogy a matrica mellett levo arcimket is elfogadjak a managerek :(

a niagara az egyetlen húzótermékük, egyrészt a kisebb us i gépeket konvertálja, másrészt web tierbe állítólag elég jól veszik, vagyis vették a nehalemig.

---------------
mpu.buzz.hu

Azért tegyük hozzá, hogy van, aki agyatlanul, mert bedőlt a marketingnek. Van, amire jó az a CPU, de az jóval kevesebb, mint amire nem.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

biztosan, ugyanakkor az elmúlt négy negyedévben ~1 milliárd dollárnyi Niagara-gépet adtak el, kozenkvensen 300M/negyedév felett. ez azért már nem a tévedés kategória. a Niagara még a válság alatt sem csökkent eddig, a növekedésből stagnálás lett "mindössze".

---------------
mpu.buzz.hu

Csak az általam ismert esetekből ítélve számtalan olyan példát látok, ahol ilyeneket vettek, és nem is tudják, hogy hülyeséget csináltak.
Sőt, ha elmondod nekik, még téged néznek idiótának, mert hát lehet, hogy alig bírom kivárni, míg lefut az a tar, de majd amikor szarrá lesz terhelve a gép, akkor majd igazán durván fogja tolni!

Ja, de addig is, meg akkor is 4-5-ször akkora válaszidővel, mint egy ötödannyiba (kiszámoltuk) kerülő x86-os gépen.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

van ahol nem 1 tar lefutas jellegu a workload...

--
.

Nem értetted meg. Azt érzik, hogy a gépen minden lassabban történik (tar), de anélkül, hogy egyáltalán mértek volna bármit, elhiszik, hogy ha szarrá lesz terhelve, akkor sem lesz szarrá terhelve, mert ez mindent kibír, nyolc inteles gép helyett dolgozik.
Közben meg a legtöbb helyen még ez is csak legfeljebb 40-60%-on pörög, a válaszidő (amit meg nem néznek) meg jóval lassabb, mint x86-on.

Van olyan, ahol ez a CPU nagyon jó, de a helyzet az, hogy azon helyek közül, ahol én eddig ilyet láttam nem ilyen volt. Jobban (pénzben, teljesítményben) jártak volna egy PC szerverrel.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

jah ertem.

hat aki meres nelkul elhisz barmit is annak ugy kell.

valaszido alatt mit ertesz?
--
.

Egy tranzakció kiszolgálási idejét, pld. egy alkalmazásszerver mennyi idő alatt válaszol meg egy kérdést.
Az sem mindegy, hogy ez 50 ms, vagy 500...


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

erdekes.

es miert lassabb ebben a sparc? ez nem hiszem h architechtura fuggo...

--
.

Nem úgy általában a SPARC, hanem a T1/T2. Ezeknél a CPU-knál az egymagos teljesítmény nem túl jó, akkor tudja igazán kipörögni magát a proci, ha sok szálon terhelik (vagy ha a spéci fícsörjeit használod).
De egy lekérdezés (tranzakció) ma még nem túl gyakran tud több szálon párhuzamosan futni, így leginkább a válaszidőben látszik a különbség, maximális terhelésben a TPS hasonló értékeket mutat, mint egy ötödannyiba kerülő Intelen.
A Fujitsu más irányt választott, a SPARC Vx ugyanúgy "kevés" magos, mint az x86-os vonal (bár már ott is vannak 6-8 magos CPU-k), de a magok önmagukban sem lassúak.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

akkor nem veszunk sparcot se! :)

--
.

Jó az pedig, SPARC-on még a Solaris is elviselhetőbb. :)


suckIT szopás minden nap! Sun X4540 teszt

Es menyibe is kerul egy ocso uj sparc proci ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Így külön tételként nem hiszem, hogy szerepelne bármelyik árlistán...


suckIT szopás minden nap! Sun X4540 teszt

"De egy lekérdezés (tranzakció) ma még nem túl gyakran tud több szálon párhuzamosan futni, így leginkább a válaszidőben látszik a különbség, maximális terhelésben a TPS hasonló értékeket mutat"

Van erről valami teszt? Nem kötözködésből, csak érdekel.

T2-n még csak fordítottam több szálon. A gmake -j 60 elég fun tud lenni bizonyos fordítási munkáknál. :)

Nekem sajnos nincs olyanom, amit kiadhatnék, interneten nem tudom van-e.
De ez amúgy is erősen alkalmazásfüggő. Te mire használod/-nád? Azzal kell megnézni...


suckIT szopás minden nap! Sun X4540 teszt

Ez egy T6320 blade, normál esetben még csak egy appszerver fut rajta (bea), meg valami telkós szarság, de alig terheli ki.
Később talán még kerül rá pár dolog, de nemtom mi.
Igazából ami érdekel, hogy mondjuk egy appszerver (vagy egy LAMP jellegű szerver) esetén mennyit változik egy user session válaszideje X szeres terhelés esetén. (Mekkora az a szorzó, ahol jelentősen romlani kezd a teljesítmény.)

Tudom, hogy alkalmazásfüggő, viszont pl. egy apache prefork+php esetén is kb. párhuzamos kiszolgálás van. (Mondjuk egy session válaszideje relatíve lassú, mert a php szereti a gyors cpu-t...)

"Mondjuk egy session válaszideje relatíve lassú, mert a php szereti a gyors cpu-t..."

meg az okos programozokat es a mysqlt ugyanazon a szerevren futtatva
--
.

"meg az okos programozokat"

mi az ami a hülyéket szereti?

"mysqlt ugyanazon a szerevren futtatva"

Nemtom, szerintem tökmindegy hol fut. Nem hiszem, hogy a connect time viszi el a válaszidőt.

hint ironia
--
.

hint:
#include "takemeaw/ironia.h

Vagyis, tudom, hogy te csak ironikus kommenteket írsz, komolyakat nagyon ritkán.

:)

Nézzük, a ping szerint gigabites linken az RTT 200-300 ms körül van. Mennyi ez egy unix socketen, amelynek a másik végén a MySQL van?

Ha a gép megfelelően van méretezve, kifejezetten hasznos, ha az alkalmazás és az adatbázis ugyanabban a kernelben fut, összehasonlíthatatlanul nagyobb a sávszélesség, és alacsonyabb a késleltetés.

Az említett gépnek meg azért van ereje, csak terhelés kell, hogy előjöjjön.


suckIT szopás minden nap! Sun X4540 teszt

A legtöbb esetben nem kivitelezhető.
Pl: webszerver DMZ-ben, adatbázis szerver intraneten.
Komolyabb cégeknél, álltalában ez van, igaz, nem feltétlen mysql, de ez most lényegtelen.

Ráadásul egy appszerver és egy db szerver teljesen más workload, és ha egyébként nagyobb terhelésre csinálod a rendszert már csak azért is érdemes szétszedni, hogy az egyiket az appszerverre hangold, a másikat az adatbázis szerverre.

Megérne az is egy misét, hogy megnézzük, melyik a jobb megoldás (persze ilyen sincs, feladatfüggő).
Szerintem ha egy gép képes elvinni a terhelést, jobb eredményt kell kapj azzal, ha a DB helyben van, persze ha nem bírja, az megint más kérdés.

A különválasztás egyébként rendben van, rengeteg minden indokolhatja amúgy is.

Más workload, viszont ebből eredően akár jól meg is férhetnek egymás mellett.


suckIT szopás minden nap! Sun X4540 teszt

"ping szerint gigabites linken az RTT 200-300 ms körül van"

Akkor abba a gigabites linkbe bekerult meg egy geostacionarius muhold is. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

0, természetesen, elírtam. :)


suckIT szopás minden nap! Sun X4540 teszt

Az jó vas. Nem azt mondtam, hogy a terheléssel emelkedik a válaszidő (ebben pont jobb a T2), hanem hogy terhelés nélkül is jóval magasabb (az alacsony egyszálú teljesítmény miatt), mint egy ötödannyiba kerülő inteles gépen.


suckIT szopás minden nap! Sun X4540 teszt

Ok, de ha 2000hit/s re méretezek vasat, akkor lesza nem érdekel, hogy terhelés nélkül mennyi a válaszidő. (Az meg főleg nem, hogy 1ms, vagy 3 s a válaszidő, mert a legtöbb frontendnél baromira nem ez számít.)

Mérd ki, és ha teheted, oszdd meg, annál okosabbat senki sem fog tudni mondani. Nem tudom mik futnak az alkalmazásszerveredben, de ha pld. userek által cibált webes dolgok (mondjuk egy HUP :), akkor ott nagyon nem lesz mindegy, hogy 1 ms, vagy 3 s.

Én próbáltam egy móricka alkalmazást anno, és az Intelen mért 40-50 ms-os válaszidőhöz képest a SPARC-nak 200-250 ms-os időket is sikerült produkálnia (egy szálon). Értelemszerűen ezen az sem segít, ha 2000 user húzza a fülét, mert attól, hogy az aggregát áteresztőképesség jó lesz, a usernek még homokórázik a cucc.


suckIT szopás minden nap! Sun X4540 teszt

van egy T2000em jatszani, ha megmondod pontosan mi erdekel, kimerem :)

Ez fordítva is elő szokott fordulni, hány olyanra emlékszem, hogy te, ez a sample lekérdezés csak 6% -al gyorsabb, miért kerül ez a gép ennyibe? - Azért, mert 8 ilyen processzorod van. - ??? -Egyszerre nyolc ilyen lekérdezésed futhat. - Whata? - Ez még akkor, amikor nem vagdostak hozzád dual meg 4 magos x86 procikat (de Niagara se volt) Azóta már igen, de ugyanazok az emberek azóta se értenek ennyit se a "multithread feldolgozáshoz". Szóval az a lényeg, hogy vannak emberek, akiknek teljesen mindegy. El lehet adni egyiknek PC-t, másiknak Niagarát. Utóbbi jobb üzlet, nem?

Well said. És utóbbi (eladási oldalról) tényleg jobb üzlet. :)


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Nagyon helyes. A Sparc döglött ló már hosszú évek óta...

A Solaris leginkább csak SPARC-on ér valamit, x86-on szerintem még mindig felejtős, főleg ha a Linux támogatásával, teljesítményével, elterjedtségével hasonlítom össze.
Akkor tehát ha a SPARC döglött, a Solaris is az? (ezt persze befolyásolhatja az, ha a fenti észrevétel csak a sajátom :)


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

sztem azert van boven lehetoseg x86on is solarisnak

ha elfut a HW-en (marpedig sun x86os gepein elfut) akkor tud sokkal __kenyelmesebb__ megoldas lenni mint binux enterspajz kernel+random osszevalogatott userland

eleg ha csak zfs altal nyujtott dolgokat nezed meg vagy a zonakat pl.

--
.

Ezeket mind lehet implementalni linuxba is. Vagy mar epp folyamatban van.
Azutan meg mit tud felmutatni a linux elleneben x86-on?

jah igazad van

lehet taknyolni bashben scripteket h elerd ugyanazt a funckcionalitast

--
.

Ahogy a főnököm mondani szokta: mondj határidőt, vagy mondj határidőt, amikorra tudsz mondani határidőt.

Úgy nem ér választ írni, hogy időgéppel 20 évet előremész. :)

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

Ebben igazad van (bár én például nem találom kényelmesnek a Solarist, és hiába erőszakolják a will-it-be-11-esbe (osol) a GNU szarokat, nem csak ezen múlik), csak hát kellemetlen, amikor az x86-os Solaris azért rendszeresen rohad, vannak vele kompatibilitási problémák (pld. recommended patchek felrakása után a gép nem bootol, lehet visszaállni), ellenben SPARC-on ezek azért nem annyira mindennaposak.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

ez igaz

a sparc vs. x86 tortenethez nem tudok mit szolni nincs sparc itt
--
.

Egyébként olvasom a kommentjeidet, rákkantitottam a blogodra, mondom b+ ez csak a *** lehet, aztán lescrolloztam az első blogbejegyzésig és mintha tényleg.

Azt az arcot már sok helyen láthattad, egyébként meg a tudálékos okostojásokat könnyű összetéveszteni, mint ... öhh ... két tojást.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Igen.

Igen, a Solaris is döglött, IMHO. Legalábbis évek óta kellemetlen érzésem van tőle, és sajnos volt pár szép összeomlása a hiperbiztonságos, ultrastabil kernel api-ra épülő überoprendszernek, tehát a Solaris felsőbbrendűsége akár egy ún. "dzsunkalinux"-szal szemben is, tekinthető bátran városi legendának. Mindkettő pont ugyanolyan kellemetlenül képes hátbaszúrni akkor, amikor az épp a legfájdalmasabb.
Tehát a válasz ezek alapján az, hogy biz lassan a Solaris is döglöttnek tekintendő.

Ezt sajnos már én is megtapasztaltam párszor, gyönyörűen tud a Solaris is (visszautalva a fenti szálra, akár SPARC-on is) a saját hányásában spinlockolni, izé, pörögni. :)


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Valahogy nekem nem sikerült még ilyet látnom 15 év alatt, pedig most is egy 80 SPARC berendezésből álló gépparkot figyelek. Én vagyok az ügyetlen?

Nem, biztosan én/mi. Utasszállító repülővel zuhantál már le? Vagy láttál már olyat a saját szemeddel? :)


suckIT szopás minden nap! Sun X4540 teszt

Sokféleképpen lehet használni egy "80 SPARC berendezésből álló" gépparkot. Lehet úgy is, hogy nem piszkálod, ha nem kell, meg lehet gentoo linux stílusban is, napi upgrade, bleeding edge, mit tudom én. Nem sokan szokták úgy, de lehet. És marha gáz, amikor több napos atom szívás, panic, stb után behatárolod és reprodukálhatóvá teszed a hibát, aztán az egész tetves interneten nem találsz mást, mint a Sun fórumon 1 db bejegyzést valakitől ugyanarról a hibáról - válasz nélkül. Persze, mert mindenki más úgy használja a Solarist, hogy csak akkor nyúl hozzá, ha ütik :) Vacak Linux esetén legalább nem érzed magad annyira egyedül, bug van, de legalább nem csak nálad, konkrétan Sun Cluster vs ZFS témában olyan... jelenségek? bugok? voltak (vannak?), hogy a mai napig kételkedem benne, hogy bárki más használná..

meselsz rola? akar privatban is. persze csak ha nem reportoltad, ha van CR#, akkor azt mond :)

akarsz beszelni rola? :D
--
.

Próbáljuk meg ezt és a kapcsolódó dolgokat: 6583425

Leírva lehet, hogy nem tűnik durvának, de amikor összeraknál 2 db X4600 + némi adalék (hozzá való) ethernet kártya, és nem megy, és olyan hibákat produkál, hogy a hajad égnek áll, és már mindent kicseréltél, aztán megtalálod a jelenséget a Sun fórumokon több embertől különféle körülmények között, no reply, ... Nem reprodukálható, a f***t nem, bármikor megmutatom.

A másik olyan probléma, hogy resource group, zpool-on, rajta 1 db sczbt resource, a zpool SAN-on van. Kicsit nagyobb az _olvasási_ terhelés a zpool-on, (elég nagy), akkor a zpool kissé beállhat, a scz check script eltimeout-ol, a framework migrációt kezdeményez, (zóna leálltás, zpool export, stb lenne a folyamat), ez a gyakorlatban sose ér véget, néha reboot a vége, workaround = scriptekbe belepiszkálás, de annyi erővel már lassan ubuntu linux is lehetne, végleges megoldás UFS használata amivel érdekes módon a korábban 3-4 perc migration is 5 mp lesz, meg be se lassul, amúgy ez a probléma is fent van a Sun fórumokon és meg nem láttam semmi értelmes választ, a környezet HP EVA-n ZFS HAStoragePlus, zone resource, abban DB2 instance, de nem hiszem, hogy számít mivel mások, akik reportolták 6140-el tapasztalták és valami teljesen random alkalmazással, de ez is olyan hogy bármikor elő tudom hozni, ha kell, csak már a hányinger kerülget, ha csak rágondolok.

az szep

--
.

Megkérdezném, hogy egyetlen ilyen hiba megtalálásához hány év kellett (vö: kollegának 15 év alatt egy sem volt), de a ZFS eleve értelmetlenné teszi a feltételét.

Mondjuk csaltál, mert SPARC-ról volt szó, azon biztos nem jönne elő. :)


suckIT szopás minden nap! Sun X4540 teszt

Ha rosszindulatú akarnék lenni, azt mondanám, a ZFS cucc sparcon csak azért nem jön elő, mert nem jutna el odáig az alkalmazás, hogy úgy meghúzza az EVA-t. ;)

De nem vagyok rosszindulatú, szóval maradjunk annyiban hogy V445-ön simán volt a másik bug, de az már részben javítódott

Nem az oprendszer tehet arról, hogy egy fos, taknyolt architektúrán kell futnia. Értsd: x86, és itt pl. nem feltétlenül az ISA-ra gondolok, hanem arra a szörnyűségre, ami x86-on egy bootfolyamat alatt lezajlik. A SPARC és az OFW sokkal letisztultabb.

Mondjuk lehet, hogy az EFI ezen változtatna, de róka fogta csuka: senki nem tér át rá, csak az Apple merte megtenni (de ők is csak azért, mert a userek kognitív disszonanciája úgyis elnyomja az ellenkezésüket :))).

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

A "senki" azért erős túlzás, mert a komplett HP Integrity vonal EFI alapokon nyugszik. Az Apple masinákon meg még bootoláskor se veszed észre, hogy EFI dolgozik benne.

Ave, Saabi.

Tudtommal az Integrityben Itanic van, nem x86/amd64, nem?

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

EFI-ről volt szó, a nextgen BIOS-ról, melyet az Itaniumhoz dolgozott ki az Intel, majd kiterjesztették máshova is. Nem ISA-hoz kötődik, támogatást az OS felől kell kapnia, hogy kihasználhasd az előnyeit.

http://en.wikipedia.org/wiki/Extensible_Firmware_Interface

---------------
mpu.buzz.hu

Nem, nem EFI-ről volt szó, hanem arról, hogy az x86-ok bootfolyamat még mindig taknyolt, 20 éves gány. Az EFI segíthetne ezen, de _x86_-on senki nem tér át rá, mert nem mernek.

Saabi a "senki"-hez szólt hozzá, de a téma szempontjából a !x86 Itanium irreleváns. Az is, hogy az EFI platformfüggetlen elvileg. Attól még x86-on ugyanaz a gány van.

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

Bocs, félreértettem hogy mi mire volt válasz. Szóval nem tudom, mint technológiai felhasználót, kit érdekel, hogyan bootol fel az x86. a cégek láthatóan megoldották, az IBM Nehalem gépei pl. már UEFI-vel érkeznek, nyilván visszafelé kompatibilis a BIOS-szal. A Windows Server 2008 támogatja pl, az RHEL csak a 6.0-tól, tudtommal.

UPD: persze máshol is vannak UEFI-s gépek, pl. a Dellnél is a nehalemes gépek.

---------------
mpu.buzz.hu

Pont ezért nem értem miért nem nyomják az EFI-s mainboardokat a gyártók, mivel simán át lehet kapcsolni BIOS emulációra ha valamiért az kell. Szvsz ez szerintem csak elhatározás kérdése lenne.

Van azért néhány desktop célú lap is ami EFI-s. Pl MSI P45D3

Ez kell teneked:
http://www.openfirmware.info/Open_Firmware

:)


suckIT szopás minden nap! Sun X4540 teszt

:))
--
.

Jó is lenne, bár megnézném R=1 Pistikét, hogy hogyan akarja tuningolni a PC-jét egy OK-prompttal szembenézve. :)

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

Idézet:
a téma szempontjából a !x86 Itanium irreleváns

Hacsak úgy nem. :-)

Ave, Saabi.

(most szivesen lennek en a lix)

hat akkor varhatunk tovabb az elerheto tranzakcionalis VMre :-(

Ezért viszont tényleg kár, nagyon kíváncsi lettem volna rá. De azt gondolom -és erről írnak is a hwsw-s cikkben-, hogy ha ez tényleg egy jó technológia, előbb-utóbb megcsinálja valaki más.


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

az Azul mar megcsinalta, de nem hagyja h a procijain Javan kivul barmi mast futtassunk :-(
amugy ok tranzakcionalis VMel implementaltak a Java monitorokat :-)

Cím frissítve. Egy neve elhallgatását kérő forrás állítja, hogy 100%.

--
trey @ gépház

a nagyz volt

irtam a fonokenek
--
.

nem, valamek blogs.sun.com/sunhu -s gyerek

nagyz van olyan kocsog h nem arul el ilyesmit

nekem a minap bevallotta h kedvel................
--
.

hat hogyne :P

igy hogy irtal a fonokomnek mostmar nem :'(

jo de azt irtam hogy

NEM A NAGYZ VOLT!!!
--
.

Vesszőhiba van a mondatban. :)


suckIT szopás minden nap! Az iparág első hatmagos szerverprocesszora

Így műlik el a világ dicsősége :(