Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What's Next in CPU Land after Itanium?

Cliff posted more than 12 years ago | from the is-intel-the-only-chip-maker-left dept.

Technology 589

"I work for a major research organization. Of late a lot of the normal big computer companies have been visiting and preaching the gospel of Itanium. My question to them, and to the assembled masses here at Slashdot is what happens next when Itanium is real? My world view is that Itanium based systems will become commodity products very quickly after good silicon is available in reasonable volume. At that point, why should one spend $8-10k for that hardware from the likes of HP, Compaq, Dell and others when one can build it for $2k (or even less)? In other words, has Intel finally done in most of their customers by obliterating all the other CPU choices (except IBM Power4 [& friends G4, et al] and AMD Hammer) and turned the remainder of the marketplace into raw commodity goods? Lest you defend the other CPUs... Sparc is dead, Sun doesn't have the money (more than US$1B we'll guess) to do another round. PA-RISC is done, as HP has given away the architecture group. MIPS lacks funding (and perhaps even the idea people at this point). Alpha is gone too (also because of the heavy investment problem no doubt). Most other CPUs don't have an installed base that makes any difference, especially in the high end computing world. So what's next? I don't like the single track future that Intel has just because it is a single track!"

cancel ×


Sorry! There are no comments related to the filter you selected.

compilers (3, Insightful)

avandesande (143899) | more than 12 years ago | (#3028512)

Itaniums will become commodities when people figure out how to write compilers for them. That will be in about 10 years.

Re:compilers (2)

jgerman (106518) | more than 12 years ago | (#3028556)

Not likely, it would take a couple of weeks max for the first compilers to appear. Wish I could afford one, I'd love to hack away on a compiler for a new machine.

Re:compilers (3, Insightful)

shitfit77 (80494) | more than 12 years ago | (#3028586)

You seem to miss the point on this a little bit. Although there will be compilers available, there is an extreme difference between a compiler and a good compiler. A compiler works, a good compile is able to utilize an architecture to its fullest (or at least close).

Re:compilers (2)

spencerogden (49254) | more than 12 years ago | (#3028592)

first compilers != useful compilers

Re:compilers (3, Insightful)

jmv (93421) | more than 12 years ago | (#3028594)

Not likely, it would take a couple of weeks max for the first compilers to appear.

Sure, but the problem is how long before there are good compilers? That's one of the main problems with architectures like Itanium.

Re:compilers (-1)

Fecal Troll Matter (445929) | more than 12 years ago | (#3028590)

Hi. Are you aware that you have grabbed the ever so popular 'first post'? Celebrate, ingrate, or I shall be forced to remove your colon with a spatula.

Re:compilers (0, Offtopic)

avandesande (143899) | more than 12 years ago | (#3028604)

And at +3. Now where is the turd report?

Re:compilers (-1)

Klerck (213193) | more than 12 years ago | (#3028634)


.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc .Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde <

You fucking rock. (-1)

L.Torvalds (548450) | more than 12 years ago | (#3028663)

Can you do a widening AND lengthening post?

First Goat. (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3028513)

This is my first roast goat.

Not First Post (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3028516)

Not First Post! Yeah, I rule.

Anti-semitic processors (-1)

Ralph JewHater Nader (450769) | more than 12 years ago | (#3028517)

The only way to go.

Re:Anti-semitic processors (-1)

ringbarer (545020) | more than 12 years ago | (#3028538)

I bagsie the first 88-88 processor. SIEG HEIL!!!

3rd p1st (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3028519)

ACs in da hizouse!

What's Next?IBM not INTEL or AMD (0)

Anonymous Coward | more than 12 years ago | (#3028520)

It is all on IBM, they will pick up the slack and the power5 will destroy IA64 once and for all.

imagine... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3028522)

a beowulf cluster of these!!

sorry, had to do it.

Re:imagine... (0)

Anonymous Coward | more than 12 years ago | (#3028613)

..a Beowulf cluster of Natalie Portmans riding these things.

Single track (0)

Anonymous Coward | more than 12 years ago | (#3028523)

There are many reasons to hate the direction that CPUs are going in the future (x86), there being a single track is the least of our problems.

If the Pentium is any guide, the next chip will likely be called Itanium Pro followed by Itanium II.

Re:Single track (2, Funny)

grammar nazi (197303) | more than 12 years ago | (#3028541)

The itanium already has not-an-instruction bits attached to each operation. Perhaps, they need not-a-thread bits for processes and not-a-bug bits for features.

my stock options will go up (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3028527)

Since I'm going to be joining intel in the next 12-18 months...

so fuck you all! Monopolies rock!!!

The Ace of Spades (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3028528)

Ace Of Spades

If you like to gamble, I tell you I'm your man,
You win some, lose some, all the same to me,
The pleasure is to play, makes no difference what you say,
I don't share your greed, the only card I need is The Ace Of Spades

Playing for the high one, dancing with the devil,
Going with the flow, it's all the same to me,
Seven or Eleven, snake eyes watching you,
Double up or quit, double stake or split,
The Ace Of Spades

You know I'm born to lose, and gambling's for fools,
But that's the way I like it baby,
I don't wanna live for ever,
And don't forget the joker!

Pushing up the ante, I know you wanna see me,
Read 'em and weep, the dead man's hand again,
I see it in your eyes, take one look and die,
The only thing you see, you know it's gonna be,
The Ace Of Spades

What's after Itanium? That's easy (3, Funny)

wrinkledshirt (228541) | more than 12 years ago | (#3028530)


That's probably only funny to chem majors.

Okay, maybe not even chem majors.

Nano-technology (0)

masterkool (550633) | more than 12 years ago | (#3028531)

Nano technology is sweeping the R&D community, everthing from carbon nanotubes to 20 nanometer wire to atomic CPU's are in thought at the moment. These ideas are not constrained however to just computing, but that is a large part of the proposed market.

Re:Nano-technology (0)

masterkool (550633) | more than 12 years ago | (#3028565)

I forgot to mention the serious reasearch into chemical computing that was derived from recent brain research. And to clarify, atomic CPU's use the motion of a few atoms to convey complex mesages from place to place. This would mean that an entire computer (provided ram, accelerators and all the other stuff gets smaller too) could fit in your pocket if not smaller. These would not be PDA's but full home computers. Some of the other uses for nano-technology are super strong archetecture, protein mapping, nano-bots for medical purpouses........

Just wondering, not a troll. (0, Offtopic)

AltGrendel (175092) | more than 12 years ago | (#3028532)

How is Intel doing this different from M$ trying to clamping down in the OS arena? Just curious.

Re:Just wondering, not a troll. (2, Interesting)

putzin (99318) | more than 12 years ago | (#3028675)

It's different because they haven't signed exclusive deals and used marketing to force other competitors out of the fray. Essentially, they will have priced the competitors out of the building. I'm not saying they aren't a monopoly, but realistically, it's harder to argue they did it illegally or unjustly.

However, I still think that there will be room for others. AMD will probably succeed doing what they do best, outpace Intel in quality and lower the price by ~10%. This has been successfull (I hope it continues, I own stock) and will probably continue. And I doubt Sun is out. There maybe changes coming, but I figure McNealy would sell his baby prior to using Intel chips. As for the others, they fell and never recovered. You can't charge super high premiums when your competition is charging super low premiums. A lot of corps assumed you could and get away with it and look what happend.

The future is unwritten, so any sort of prediction is just fantasy for the most part. Step back to 95 and tell me who predicted 2000 or 2001? Reality is far more interesting than any professional opinion from the Gartner group et. al.

I don't think we need to worry just yet (4, Insightful)

Indras (515472) | more than 12 years ago | (#3028534)

Think for a minute how long we've been using 32-bit processors. If (and when) 64-bit becomes mainstream, I imagine it will be around for a LONG time, as it becomes standardized and slowly takes over a majority of the market. Also, we'll have the other contenders butting in with equivalent and cheaper options, like Cyrix (tried) and AMD (did).

Just because Intel will pave the way for mainstream 64-bit processors using the Itanium doesn't mean it will monopolize the market until it comes out with a 128-bit processor. No matter what, it will probably be years from now before we have to worry.

I am confused (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3028539)

The article doesn't say: "I_AM_A_FAG writes: "Blah blah blah fuck my ass...."

So WHO wrote it? Is Slashdot having problems? Or is Cliff having problems?

Re:I am confused (1)

spt (557979) | more than 12 years ago | (#3028575)

I work for a major research organization blah blah blah

If I worked for a major "research" organisation which couldn't even find out simple stuff like the short term future of the microprocessor industry then I would want to remain anonymous too.

Re:I am confused (1)

cullenfluffyjennings (138377) | more than 12 years ago | (#3028620)

This is the best response so far.

Re:I am confused (2)

sphealey (2855) | more than 12 years ago | (#3028674)

If I worked for a major "research" organisation which couldn't even find out simple stuff like the short term future of the microprocessor industry then I would want to remain anonymous too.
One sees this comment in every Ask Slashdot thread. It is not only tiresome, it is wrong as well. Seeking multiple opinions from diverse sources is certainly part of research, similar to skimming all the current trade and academic publications.

Sorting out the meaningful comments from the slush is part of good research.


Re:I am confused (0)

masterkool (550633) | more than 12 years ago | (#3028591)

Hey. I have idea, don't worry about it.

Er, is this whole article a troll? (0)

davecb (6526) | more than 12 years ago | (#3028540)

or perhaps a market research person trying to select evidence for a really cool tempest-in-a-teapot? But wait, that's a kind of troll itself...

Required disclaimer: I'm biased toward a well-known non-intel chipset (;-))

Not a troll. Worse. (0)

Anonymous Coward | more than 12 years ago | (#3028664)

It is another "I want someone to do my job foe me for free while I collect a paycheck" post.

Next? (2, Funny)

jgerman (106518) | more than 12 years ago | (#3028542)

In a word, quantum. Or maybe that's two words, actually it might only be a word when you're looking directly at it.

Competition (1)

Jaborandy (96182) | more than 12 years ago | (#3028544)

I believe in competition. I believe that when the cips are cheap, HP and other system manufacturers will sell reasonably priced systems. I believe that AMD will offer a competitive chip... eventually. I believe that there will always be choices.


PS - I agree with another poster that compilers for Itanium are way too complicated, by design. It sucks that there isn't a good compiler yet.

Windows XPi of course (0, Offtopic)

dominic7 (70356) | more than 12 years ago | (#3028549)

I can see it now, All Servers running on Intel Chips running Windows Operating Systems. Unless AMD overcomes their "hobbiest" or second choice image the industry will eventually begin to stagnate.

Logically, it should be Anadium (2, Funny)

PD (9577) | more than 12 years ago | (#3028550)

Itanium is Titanium without the T, so Anadium is Vanadium without the V.

I can't wait until they get to Hassium. They could name their chip Assium!

McKinley and Jackson (1)

spt (557979) | more than 12 years ago | (#3028553)

McKinley is the 64-bit that Intel will sell for real.

Jackson is 32-bit which has simultaneous multithreading.

Links aplenty which simple google search

Itanium vs. Hammer vs. All Others. (4, Interesting)

Talonius (97106) | more than 12 years ago | (#3028554)

AMD's newest chip is supposedly fairly remarkable (don't have specifics, see Tom's Hardware's search engine). What about the Crusoe? VIA's purchase of (I believe) the M3? I wouldn't look at companies that are currently in the business only - I would tend to look at companies that might move into the business, either via investment, startup, or outright purchase.

I'm not too worried about Itaniums, and I don't see them becoming prevalent for quite a while. While the Pentium II, III, and IV moved through the marketplace fairly rapidly they all offered compatibility at some level. If I recall correctly 32 bit programs that are not rewritten for 64 bit run SLOWER on the Itanium than they do the equivalent Pentium line.

In essence consider this: it's like a brand new operating system attempting to break into the monopoly that Microsoft has. (Parallels drawn out of necessity.) While it may be better, faster, superior in every way it doesn't have 20+ years of legacy code behind it - and that will end up being what drags it down.

Only time will tell. Remember the Pentium Pros..


Re:Itanium vs. Hammer vs. All Others. (3, Insightful)

Skirwan (244615) | more than 12 years ago | (#3028660)

If I recall correctly 32 bit programs that are not rewritten for 64 bit run SLOWER on the Itanium than they do the equivalent Pentium line.
When Apple transitioned from the M68K line to the PPC, they were in the same situation - 68K code would run faster on a 40Mhz 68040 than on a 40Mhz PPC 601. The reason consumers didn't mind was that the the PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer), and (to the end user) didn't cost significantly more.

Until Intel gets the Itanium cost down to the point where they run 32-bit code at equivalent speed to a Pentium at the same cost, Itanium probably isn't ready for the consumer market.

Damn the Emperor!

Re:Itanium vs. Hammer vs. All Others. (1)

Cheeko (165493) | more than 12 years ago | (#3028668)

The key here is that Itanium isn't going after the 32 bit market. Intel plans to keep producing its 32 bit chips at least for the time being, the Itanium is purely a move at the high end server market. So while yes, 32 bit apps will run slower, Intel probably doesn't care, as all the customers they are trying to sell to are already on 64 bit, Sparc, Alpha, Power4, what have you.

Three way race... (-1)

bytes256 (519140) | more than 12 years ago | (#3028555)

There are three contenders...

1: AMD...AMD doesn't have the influence to go it's own way and survive for long...expect either bankruptcy or an itanium clone from them.

2: IBM...PowerPC's will live as long as Apple does...and probably longer since they power a decent chunk of IBM high-end hardware.

3: Intel...obviously Intel's gonna win this one...but IBM ain't going anywhere.

Recurring problem (4, Interesting)

colmore (56499) | more than 12 years ago | (#3028558)

This seems to be a recurring problem in a number of technology based industries. Once you get to a certain lever of high-tech, only the (very) big boys can even compete.

So here's the question: how do you keep competition alive when an initial investment costs in the billions of dollars. For any company less than Intel sized, a single bad product cycle spells complete doom. That's no kind of market to be in.

Also, wasn't this inevitable. There are a few Beowulf jokes being posted, but that's really what's going on. Increasingly high performance tasks (Google, render farms etc. etc. etc.) are using massive arrays of low-power CPUs. It costs a lot of money to develop big iron chips, and if people aren't buying them then there's no point in investing that much money.

What I'm worried about are the isolated markets that still require massively powerful, low processor number architectures. Not everything splits into nice packages.

Re:Recurring problem (1)

PoiBoy (525770) | more than 12 years ago | (#3028636)

IBM seems to keep coming up with ways to keep the mainframe alive, so I'd imagine that they'll continue to develop processors for big iron. BTW, what kind of processors do the zSeries use, anyway?

Plus, don't forget IBM has a pretty long roadmap laid out for the G4, ..., G? and the Power series processors.

Re:Recurring problem (1)

Pravada (217899) | more than 12 years ago | (#3028670)

IBM uses RISC Power4 procs I believe...They're really badass - two procs per chip, four chips in a "package" giving you eight processors on the surface area about the size of a dinner I said, badass.

but isn't this what is next? (1)

simpl3x (238301) | more than 12 years ago | (#3028641)

while i am certainly not an engineer, the idea of designing software to divide problems correctly for distributed processing is exactly where the future lies. processing power is a commodity at all levels but the top end. efficient use of resources, as well as useful programs for these platforms would be much more valuable than greater horsepower for most people... that and a t1.

According to Mr. Pearson... (2, Funny)

bobetov (448774) | more than 12 years ago | (#3028561)

Quantum computing, 2007.

Bet on it. ;)

SPARC is dead? (4, Interesting)

bconway (63464) | more than 12 years ago | (#3028570)

That's news to me. I could swear a friend of mine just jumped in on the UltraSPARC 4 project.

Re:SPARC is dead? (0)

Anonymous Coward | more than 12 years ago | (#3028576)

news to me too, i'm on ultra 5

Re:SPARC is dead? (4, Informative)

Anonymous Coward | more than 12 years ago | (#3028612)

Actually, I was just transferred to the UltraSPARC 4 project at Sun [] in Burlington, MA. I don't know of the official release date, though I've heard rumors of early 2003. I'm amazed at the quality of FUD in this "article" and that it actually made it to the front page of Slashdot.

What's next? (0)

Anonymous Coward | more than 12 years ago | (#3028572)

New funky commercials with Intel engineers break-dancing.

Doubt Itanium will make it. (5, Insightful)

ChrisRijk (1818) | more than 12 years ago | (#3028573)

McKinley is 464mm^2! That's a huge CPU. Will be very expensive to product, even though Intel will probably be subsidsing it with their profits from x86. Current Itanium systems start at about $8000 - doubt McKinley will be much cheaper. It'll take a long time for volume to build up, especially as it has so little software ported to it. Even if you have Intel's money, still can't just create a new platform overnight. Intel's optimisticly expect it to be until about 2005 before Itanium has any real market presence.

Also, on what kind of clueless basis do you assume that Sun has little left. Here's what's coming in just the next 2-3 years: 446 []

Sun's CPU division is 1300+ strong and they're planning to hire another 100-200 in the next 2 years.

A lot of HP's PA-RISC customers (and Compaq's Alpha customers) are quite unhappy with being forced to change architectures and are jumping ship to Sun and IBM - HP had a 7% drop in Unix sales Q3 to Q4 last year, while Sun had a 10% rise. By 2003 the significant majority of the $100k+ system market will be owned by Sun and IBM. Very reason for any of those customers to switch to Itanium, so it'll mostly just eat Xeon sales.

Re:Doubt Itanium will make it. (1)

ppetrakis (51087) | more than 12 years ago | (#3028682)

Considering HP is porting their own operating system HP-UX and 'other' software to ALPHA makes you think twice about HP's commitment with Intel.
They (HP) may work together on Itanium but they're not joined at the hip. Oh, It's Compaqs compiler engineers who are doing the itanium compiler work because there is no one else who comes close to the level of expertise they possess. Even with those creditials, they're 'still' having serious performance issues. Weigh that for what it's worth. You don't have to believe me, It doesnt diminish what I know to be fact and true. You want a 64 bit architecture that works and is proven? Wait for EV7 to ship and BUY.

Oh for all those guys who do chip layout and such. There are two platforms for which such softeare is supported. Solaris and HP-UX. Think about how fast you could get your work done compared to a sun box. HP has :-).


Re:Doubt Itanium will make it. (0)

Anonymous Coward | more than 12 years ago | (#3028687)

chortle, guffaw, snicker. Yes, is a very reliable source.

Motorolas? AMDs? (2, Interesting)

SanLouBlues (245548) | more than 12 years ago | (#3028574)

Why not G5's? Or x86-256s? Or those wacky 25x's [] ? Who knows? (rhetorical) Slashdot is not a magic eight ball, and the folks who do have a clue are most likely under NDA's. My guess is either a G(some large number here) or an Itanium(some other large number here) that has a 128bit bus. And God willing, whichever wins will run Irix.

I don't get it. (1)

pmz (462998) | more than 12 years ago | (#3028577)

Sparc is dead


PA-RISC is done


MIPS lacks funding


Alpha is gone


Most other CPUs don't have an installed base that makes any difference


This guy works for either IBM or Intel. Probably IBM, as he favors the Power4 and G4. Don't take him seriously!

For example, SPARC underlies the largest installed base of RISC processors in the is it dead?

Re:I don't get it. (2)

pmz (462998) | more than 12 years ago | (#3028625)

IBM or Intel.

Correction: IBM or AMD.

Misunderstanding of the term FUD (2, Informative)

Anonymous Coward | more than 12 years ago | (#3028632)

I wish people would stop using the term 'FUD' [] as a synonym for 'I don't agree with this bullshit'.

Re:Misunderstanding of the term FUD (1)

pmz (462998) | more than 12 years ago | (#3028690)

This article really is 'FUD' in the true sense of trying to instill fear, uncertainty, and doubt in the minds of people considering buying a RISC-based system. Whoever posted it has a strong bias that doesn't necessarily reflect reality. It is no different than claims against Open Source or Free software (no support, no liability, blah, blah...).

Re:I don't get it. (1)

javiercero (518708) | more than 12 years ago | (#3028700)

"For example, SPARC underlies the largest installed base of RISC processors in the world..."

Well, then you are also responsible for your FUD. The largest base of RISC processors is the PPC, they go from embedded to large systems. SPARC doesn't.

And Alpha is all but done, Compaq only announced a couple of minor improvements for the next few yeards. But there will be no more EV's.

I agree that for the most part the original poster of the article has no idea what he is talking about though...

Re:I don't get it. (5, Informative)

HiredMan (5546) | more than 12 years ago | (#3028702)

Sparc is dead - FUD.
You're right. The new 1.05Ghz Cu chip is pretty frickin' fast - and speed is NOT always been Sun's selling point.

PA-RISC is done - FUD.
Not true. HP is moving to IA-64 - even their boxes are starting to wired to ship with either PA-RISC or McKinley.
McKinley is essentially an HP design... PA has lived longer than expected but that's just because IA-64 is so late.

MIPS lacks funding - FUD.
Actually this probably true. SGI is not a well comany and they will probably need to move to a new chip arch soon. There R14s are G5s rumored - who knows?

Alpha is gone - FUD.
Nope - it's gone. Intel bought it and swallowed it whole. No new development, no new generations, it'll only live on in some parts in IA-64.

This guy works for either IBM or Intel. Probably IBM, as he favors the Power4 and G4. Don't take him seriously!

I can't say where he works, but he has a point. Maybe you should look at the recent server chip landscape before dismissing this guy's claims.


I'll tell you what's next. (0)

Anonymous Coward | more than 12 years ago | (#3028578)

What's Next in CPU Land after Itanium?
That's it. It's over. Nothing more. It's been a great run, but everything has already been done. Go home and spend time with your wife and children.

AMD's 64-bit K8 (2, Informative) (559698) | more than 12 years ago | (#3028579)

AMD has a 64-bit K8 chip in the works right now.

I searched and managed to find an old comparison of the K8 vs. Itanium and a few other chips.

The article (page 5 of 5 of a review) is here: [] :: A Weblog On Crack []

SPARC's death *greatly exagerated* (5, Insightful)

AtariDatacenter (31657) | more than 12 years ago | (#3028580)

Having recently participated in an NDA from Sun regarding the SPARC processor (and even with the knowledge I had walking into the meeting), SPARC is not dead or dying. In fact, I'd say that Sun squarely recognizes it as a strength. Their competition (HP for example), however, is wishing they didn't knife their baby.

As far as money to go another round, remember, Sun doesn't fab CPUs. What Sun does is design them, and they turn it over to Texas Instruments for production. And TI has their own reasons to keep up-to-date with the latest production technologies, so Sun doesn't eat that cost.

BTW: I really wish that I could talk about the SPARC presentation. I liked it a whole lot better than the NDA I attended with HP talking about their Itanic future.

Re:SPARC's death *greatly exagerated* (0)

Anonymous Coward | more than 12 years ago | (#3028645)

Sun's only survival will be as a legacy platform.

It costs lots of money (and time) to make a industry-leading microprocessor. SPARC chips are nowhere near cutting edge (just look at their SPEC numbers) They might have an impressive looking roadmap, but that is all.
Alpha's roadmap looked impressive before it was killed...

Re:SPARC's death *greatly exagerated* (1)

AtariDatacenter (31657) | more than 12 years ago | (#3028683)

Just thought I'd add on a bit here. I just got through viewing the PDF presentation that is on Sun's website about the UltraSPARC. The online version is more of a marketing presentation. If you are a good large customer of Sun, you can probably request the NDA SPARC technical presentation.

The technical presentation has all the goodies you expect to hear when technical people are describing processors. I'm glad I got to see it.

So what CPU is IBM using? (1, Redundant)

joe_n_bloe (244407) | more than 12 years ago | (#3028593)

I could have sworn you missed one.

Itanium (4, Insightful)

crumbz (41803) | more than 12 years ago | (#3028596)

Given the tremendous capital requirements in building a state of the art fab along with the incredible amount of enginnering man-hours required to leap to the next level, I think we are seeing a situation similar to the one for airliners: Airbus or Boeing. They are the only two that matter because the cost of entry into the airliner market is so prohibitive. This does not necessarily apply to Microsoft and it's OS monopoly as the Linux community has illustrated. Mindshare and marketshare are not always linked.

I have hopes for Intel producing the worlds best microprocessors as that would benefit s all. Simply advocating a move to Itanium for marketing reasons or to meet revenue targets does a disservice to the computer industry.

Then again, they are in business to make $$$....

sure (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#3028598)

I don't like the single track future that Intel has just because it is a single track!

Fuck your hairy marketing ass, you Idiot.

Cheap? (1)

wmaheriv (160149) | more than 12 years ago | (#3028601)

Just what gives you the impression that Itaniums will be cheap, commodity items? Everything Intel has said about them seems in contradiction to this basic assumption, which lies at the core of your question.

Itaniums are targetted at the "big iron" market, where SPARC, Alpha and POWER chips currently reign. Intel has said that there will be several remaining iterations of their 32-bit chip lines, and after that, 64-bit chips will enter the mass market, but in a frob'd configuration (id est, not of the same calibre as their Itanium line).

Innovation in the CPU business (1)

eyefish (324893) | more than 12 years ago | (#3028602)

This is what happens when you have a monopoly: One player who will eventually get lazy and stop innovation.

HOWEVER, things like the Java Virtual Machine (JVM), and most recently Microsoft's Common Language Runtime (CLR) should help us eventually write applications independent of the underlying architecture (I know you can do so with Java today, but Java does not drive PC sales like Microsoft's monopoly OS and Office suite currently do). Once we have a mass-market runtime environment between the CPU and the Applications, which CPU you have will not matter at all. That means that we'll have some competition back since now a company like AMD or Transmeta can trully create original products as opposed to products created to be compatible with the Intel instruction set. Of course on the other hand everyone will still be stuck running on Microsoft's CLR.

Re:Innovation in the CPU business (3, Insightful)

GGardner (97375) | more than 12 years ago | (#3028651)

Nice idea, but keep in mind that static compilers are extremely difficult to create for Itanium. Performance results I've seen show that while the theoretical maximum for IA-64 is pretty impressive, the actual results static compilers are generating are not so hot.

Now, try to write a dynamic, JIT compiler for Itanium, which is even hardware than a static compiler. I haven't seen any java or CLR performance numbers for IA-64, and suspect I know the reason why. :-)

Keep Waiting (0)

Anonymous Coward | more than 12 years ago | (#3028605)

No need to get your panties in a twist over the Itanium yet.

a. There aren't any useful compilers out there (at least none that take advantage of its unique features).

b. They currently cost nearly US$3k for just one processor (just the plain ol' chip).

Until (a.) is dealt with, very few organizations are going to spring for the cost of these white elephants since existing 32-bit processors are an order of magnitude cheaper and run current applications faster. I suspect (b.) will continue to be a problem until there is a hint of competition in that niche. Maybe AMD's Hammer will do to the 64-bit market what the athlon has done to the P3/P4/Xeon market. We'll see.



The newest chip will be called... (4, Funny)

RobL3 (126711) | more than 12 years ago | (#3028606)

The Unobtainium

It's release will follow the distribution pattern established by Transmeta.

Desktop processors to quickly be surpassed... (1)

Wulfstan (180404) | more than 12 years ago | (#3028607) mobile processors, I would say. To be honest, I think it's likely (if it isn't already the case) that processors in mobile networked devices will fast surpass desktop and server processors as objects of desire. Instead of one or two souped up power hungry beasts on your desk, you'll have 5-6 devices floating around (phone, pda, mp3 player + more) that will start to displace your desktop machine as what you spend most of your time and money on. PC processors will become an important minority concern in the world of mobility. I think that the ARM [] architecture is the likely future market leader by volume (if it isn't already!)

Different chips for differences (1)

oo7tushar (311912) | more than 12 years ago | (#3028611)

I believe that we're going to see major competition in the future for different use chips. Sure, why spend 10k when you can spend 2k for a nice Itanium machine that does everything. Yet, do you really want to spend 2k on a machine when you cand spend 500 on a nice graphics chip that doesn't need the Itanium power.
So competition isn't dead, it's just beginning of competition and maybe Intel will move into a Monopolistic position and will have to "share" their architecture.

Itanium will be Hammered (4, Interesting)

Brian Stretch (5304) | more than 12 years ago | (#3028614)

The huge die size of the Itanium and its upcoming successor make the chip far more expensive than the Pentium series, so I would not expect Itanium machines for $2K. So far, the CPUs alone are several $thousand. I also haven't seen where its performence is that impressive. x86 code performence, since its emulated, is poor. Recompile or else. Intel has sold, what 500 Itanium CPUs?

The upcoming AMD Hammer series, OTOH, is supposed to be about 30% faster clock-to-clock than the current Athlon XP series (which is considerably faster clock-to-clock than the Intel P4) and start at 2GHz. Sun's recent announcement of Linux x86 platform support, with details to come midyear, suggests that they'll be moving to the Hammer (to ship Q4). Sun would certainly love to take a swipe at Intel, and Sun has made positive comments about AMD's x86-64 Hammer architecture.

Speculation: Intel gets Hammered in the second half of this year.

If any of the rumors of the G5 are true.... (1, Informative)

Anonymous Coward | more than 12 years ago | (#3028615)

and it is a 64bit chip that can also run 32 bit programs for backward compatibility...then I think Itanium will have a run for the money. Especially since IBM released their Power4 which (too my knowledge) is the first to have 2 processor cores on one die...something DEC was planning for the Alpha. It would be nice to see the G5 have something along the lines of the Power4 for sub $5,000 price. Of course now that Intel owns all the DEC stuff they gleen the good stuff from DEC technology and graft it on to their own. I am hoping that the Apple / PPC Linux world will be able to get the rest of the world to move away from x86. But...I also hoped the Alpha would survive. Who knows maybe even stuff from Starbridge Systems [] might be the next best thing....

NVidia? (1)

bobetov (448774) | more than 12 years ago | (#3028622)

These guys have pretty much aced everything they've done to date, and they're slowly but surely moving up the chipset food chain with their integrated motherboard work. I'm curious to see if they'll get involved in the race.

Oh yeah, and I'm not affiliated with/sleeping with/invested in NVidia or any of it's affiliate's, subsidiaries, secretaries... blah blah blah

Next: Anusium (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3028623)

Really, its true. []

Just... (2, Funny)

JonWan (456212) | more than 12 years ago | (#3028624)

name it P-51 and use the 'nickname' Mustang.

Motivation for Improvement? (1)

txtger (216161) | more than 12 years ago | (#3028628)

As far as I can see it, we're in for some big problems if Intel doesn't see some competition. History has told us that Intel likes to stick with architecture designs for a long time (how long have we been x86?), and likes to refuse to make up for advances in technology/speed (little endian?). So, I see it as fairly scary to have Intel running the show completely. The golden handcuff (the marketer's favorite statement, "Yeah, your old software will work with it!"), if applied when Intel has a monopoly, means a computing industry at a standstill until some sort of competition arises.

No, no, and no. (4, Insightful)

hotsauce (514237) | more than 12 years ago | (#3028629)

No, Itanium will not become commodity as soon as you foresee because compilers and software do not exist to make good use of it (some argue nothing can make good use of it [derogatory]).

No, Intel has not killed the competition. AMD is alive and well. The PowerPC family is on the verge of The Next Big Thing (G5). And the reports of Sparc's demise have been greatly exaggerated.

No, other vendors are not irrelevant. Hitachi makes killer chips for big iron, and looks set to increase that trend. If anything, the CPU market is looking less and less like a monopoly than before.

*cough* PoerPC *cough* (4, Interesting)

S-prime (550519) | more than 12 years ago | (#3028631)

Now that the G4 has finally gotten past the 1GHz mark, and Apple has a brand spanking new Unix based OS running on it(and if you don't like it you can run others), this opens a whole new choice for the researcher looking for a new platform.

Re:*cough* PowerPC *cough* (3, Interesting)

joe_n_bloe (244407) | more than 12 years ago | (#3028646)

Also featuring stinking fast floating point.

Intel CPUs will be killed by Microsoft's CLR (3, Insightful)

eyefish (324893) | more than 12 years ago | (#3028637)

It is my opinion that once Microsoft makes its Common Language Runtime a forced deFacto standard, and once they manage to implement it on other CPU architectures, they'll essentially have a hardware-independent Windows platform. Once that happens Microsoft will have sole leverage on the PC business. That means that Intel will NOT be needed at all for running future versions of Windows-compatible programs. Who knows, maybe this could spell a revival on new and innnovative CPU architectures, since they all will now be able to run the CLR. Side note: We *could* do this today with Java, but sadly Sun doesn't have the leverage Microsoft's monopoly does on the PC business.

You are nuts if you think ... (3, Interesting)

joe_n_bloe (244407) | more than 12 years ago | (#3028676)

... that a runtime environment where "Hello World" will require, let's say, several GB of disk, a few hundred MB of RAM, continuous online updating (also requiring continuous hardware updating), and hundreds of old and newly-arriving security holes and exploits, is going to "take over the world."

Granted, it's going to be popular for a while. But isn't what's popular *always* sucky?

What will drive Itanium price down? (2)

sphealey (2855) | more than 12 years ago | (#3028639)

First, you are assuming that Itanium will succeed and drive all other choices from the market. At the moment, this is far from clear, and even Intel is said to be hedging their bets with a P4 follow-on.

Second, what will drive the price of the Itanium down? Historically, Intel have announced that their latest superchip is "targeted at servers, not desktops" about a week before releasing a flood of them into the desktop marketplace (usually the ones that didn't pass spec at the higher speed level), thus driving down the price of the server chips to where no one else could compete. What will be the driver this time? Businesses aren't buying desktops, and when they do start buying again it will be pure commodity: there is zero appeal for Itanium on a business desktop. And treble for home desktops.

Which leaves high-end servers. I don't think that any datacentre manager worth his pay is going to pull out $100,000 HP N-Class boxes in favor of $2,000 Intel clones. There's a bit more that goes into a server than the CPU.


Commodity (0)

Anonymous Coward | more than 12 years ago | (#3028640)

When the cpu becomes a commodity then it becomes less important. It will be come nothing more than any other part of the computer - a transitor, a screw, a power supply. It will be how different folks put it together that will make the difference. Also the CPU will lose the capitial C and specialized chipset will take over - already we see graphics, encryption , and low power chipset. Specialized chipset will be driving the niche markets and the number of niche markets will only grow.

Dead? I doubt it. (5, Interesting)

BlackStar (106064) | more than 12 years ago | (#3028648)

SPARC dead? I'm not sure where you come across that idea. Having listened to a few talks down at JavaOne and chatted briefly with Marc Tremblay (head chip dude down there, father of MAJC and one designer of SPARC) they've already got design down on the next two levels of SPARC as the IV is experimental, and the V is the next production level as I understand it. MAJC seems to be the experimental platform they are using for smaller implementations and alternative ideas to be tried, based on some of Tremblay's theories.

I may be off base on some of the details, but Sun has a unified approach from top to bottom, from tools to silicon for the systems they plan to deliver. I doubt it will just throw in the towel. Ultimately, Sun ships iron, and they lead the market in their segment.

I don't see the basis for your assertion, and where you pulled 1B out of for cost I also don't know.

Alpha is AMD now, as that's where a good chunk of the people went. MIPS is still kicking, with the 14000 so far, but I won't speak to the future of that chip line. There's a lot of chip heads on this site with much better info than I on many of the lines.

One decent, although dated summary is here []

Please tell me there's more information you're basing this on than consumer workstation marketshare....

64bit code (2)

geekoid (135745) | more than 12 years ago | (#3028649)

before everybody starts saying (too late, i'm sure) there is no 64bit software to support this chip, I'd like to point them to here [] .

More importantly... (5, Insightful)

Kerne (42289) | more than 12 years ago | (#3028656)

A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?

Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu. :P

Using a 20 year old peripheral port on last weeks multi-gig cpu is like sucking a McDonalds shake through a coffee stirrer!

4 years ago.. (1, Troll)

Marx_Mrvelous (532372) | more than 12 years ago | (#3028657)

I would never have thought that AMD couldm possibl be successful. I was wrong then. I'm hoping/thinking that some other company will come up with a competing idea, get their foot in the foot, and surprise the world.

NVidia, the next player (4, Interesting)

Animats (122034) | more than 12 years ago | (#3028659)

My own guess for the desktop is that NVidia will put a CPU core, probably from AMD, in the next generation of their nForce part. That puts CPU, graphics, networking, sound, disk control, and the motherboard logic on a single chip. Their current nForce part already has all of that but the CPU.

If you look at the transistor counts, NVidia's graphic chips already are more complicated than most CPU parts. This is quite do-able.

Sure, build your own... (2)

twoflower (24166) | more than 12 years ago | (#3028661)

Sure, build your own box for $2k instead of buying one for three times that much -- if you don't mind being fired.

You don't pay $6k or $8k for a server just because there's high markup on the parts. A lot of it is due to tighter tolerances required for high-availability or high-reliability equipment. There's greater consideration for issues of heat, RF, power consumption and stability -- and then there's the built-in redundancy for many components (power supplies, fans, etc).

It's not as simple as you think.


wide load comin through (-1, Troll)

donglekey (124433) | more than 12 years ago | (#3028667)


.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc .Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde .kermrc .lyxrc .muttrc .nc_keys .pgp .pinerc .profile .seyon .signature .ssh .stonxrc .susephone .tex .uitrc.console .uitrc.vt100 .uitrc.vt102 .uitrc.xterm .urlview .vimrc .xcoralrc .xfm .xim .xinitrc .xsession .xtalkrc.Xdefaults .Xmodmap .Xresources .addressbook .bash_history .bashrc .dayplan .dayplan.priv .dvipsrc .emacs .exrc .gimprc .grok .holiday .hotjava .jazz .kde

Redundant Story (0)

brechin (309008) | more than 12 years ago | (#3028685)

Let's first take a look at Intel's Big Chip [] from Feb. 4th. and look at ExtremeTech's article [] about 64-bit chips.

As someone who works on making clusters of Itaniums (and soon McKinleys), I must say that I love the performance they offer, but the architecture has a few ideosyncracies (like elilo).

I wouldn't count out everyone else yet. (2, Insightful)

jtshaw (398319) | more than 12 years ago | (#3028696)

You talk alot about Sparc, MIPS, and Alpha in that question of yours. Yes, those are all relatively low volume products, yes they do cost a lot of money. However, the Itanium is almost like Intels version of those products, done in a slightly different way. Even though they are made in lower volumes they are still profitable because the people buying them will pay a lot more for a system. Sun can sell a 64-processor UltraSpac III system for in the realm of a million dollars and more. If you don't think they are making a nasty profit of of that you are nuts. That is why they keep advancing the technology.

People love to through buzz words like 64-bit vs. 32-bit and stuff like that but when it comes down to it what do you need on your desktop? If you are using your PC for basic development or coding there is not much to be gained from a 64-bit core at all. You don't really need anymore precision. If you are talking about scientific applications then maybe you do need the 64-bit core.

I am not saying that desktop PC's won't eventually go to 64-bit cores. However, even if you were to get a cheap Itanium right now it would perform no better, and possibly worse then your high end AMD and Intel x86 processors because few of your applications would take advantage of the core.

This question will be better asked for when Intel puts a processor on there desktop timeline that utilizes IA-64 technology.

Sparc dead? And what about SGI? (2, Informative)

wizzy403 (303479) | more than 12 years ago | (#3028697)

Umm... Given how well Sun is entrenched in the financial world, I think you saying the platform is dead is just plain FUD. Check with the IT department at any major financial company and ask them how many 4500 or better systems they have. (I know, I used to work for one) And yes, a lot of them are upgrading to the new UltraSparc III machines.

And for those folks doing hard research (or special effects companies with lots o' money) SGI is still king. Despite what nvidia would like us to believe, SGI's not going anywhere anytime soon for big 3d rendering projects.
Load More Comments