True, and using a 64-bit register with the first 32-bits being zero has the same effect as really being 32-bit. And very true about NT on alpha being really 32-bit (It was *stable* though, a whole lot more than any other windows platform I have used (I and pretty much everyone else haven't used IA-64.)
In addition to the first reply's comments (completely correct), there are no 32-bit alphas. So why the heck do you list them in with the others? The Alpha instruction set is the only one I know of that was purely 64-bit. (There probably are a couple of them hidden in EE, CE, CS projects.)
x86-64 (amd64) is the only one of them (at least sparc, mips, power(pc)) where the number of registers jumped to twice the amount(8->16int, 8fp/mmx, 8->16sse). However, some such as the 21264 alpha (3rd gen core (still in use in the 21364s today)) had 80int, and 80fp (if I recall correctly). Also, The opteron/a64 has an onboard memory controller, which they almost certainly got the inspiration from the alphas.
Basically, on systems that have 32-bit subsets that don't enable new features (all except alpha and x86-64) the 64-bit will likely be a bit slower overall, as the article shows. However, x86-64 will be faster in 64-bit mode almost across the board (at least when compilers take advantage of it) and of course alphas are 64-bit only, so they are infinitely faster in 64-bit mode than 32-bit mode:)
Seriously this is mpeg4-type (divx) & pcm in avi, produced by "Software: MEncoder 0.90-3.2.3" (using most likely libavcodec which mplayer shares with almost anything on linux that wants to support a lot of formats.)
java...around 96-98 or so. How could you not remember all the hype with java programmers jumping on it all over the place?
Remember applets? Almost every website that wanted to be radical had one of the damned thing. Until people realized that most of them were a waste of time...
On that note: welcome to the year of flash ads, Here's hoping that they go the way of java applets (they have purposes and are useful on some websites, but the majority that had them realized that... they suck)
Recalling a comment on this, which is quoted loosely, and I can't remember the source:
"Every year we had been hearing that this year was to be the year of the LAN. Allsorts of hype, and eventually it died down, and when it did, LANs were everywhere."
I highly suspect that it is going to be like this for linux:)
Do you think everthing uses MSI to install to windows? Almost everything for linux comesin rpms or source (-> deb or slack, and gentoo can use any thing that can be scripted...)
the virtual memory address space is 4GB, but the Pentium (pro and 2?) 3 and 4 have Intel's PAE (Physical Address Extension) which allows the p3 & p4 to use their 36-bit physical address bus (64GB). Long live paged memory access.
look at 2.6.1 changelog, they infact mention running an old a.out format (x86) on x86-64 the only thing not working from an early (suse?) was emacs, which the author didn't take the time to track down.
On my own tests: p3-800 dual, 1.5GB ECC RAM, using this person's tests (compile lines) running gentoo linux, gcc 3.3.2 20031022, glibc 2.3.2(-r3), kernel 2.6.0-test11, My cflags are -O3 -pipe -march=pentium3 not including -fomit-frame-pointer, 1) for debugging, 2) see below:) I could recompile to test all of these fully but I don't want to be spending the next several weeks convincing people that on this particular benchmark -fomit-frame-pointer doesn't matter. All were run with the following command from KDE (cvs build) nice -n -20./Benchmark-c, oh and for the people who will attempt to tear this to shreds, they were only run once. Also I haven't yet emerged icc, because in the past I have found it to be more of a problem than a help. (To me anyway, your results are likely to differ).
normal:gcc Benchmark.c -o Benchmark-c -lm
OmitFP:gcc Benchmark.c -o Benchmark-c -lm -fomit-frame-pointer
Optimized builds: (replace the X with the number(2,3) or symbol (s)) for example: O3norm:gcc Benchmark.c -o Benchmark-c -lm -O3
OXnorm:gcc Benchmark.c -o Benchmark-c -lm -OX
OXOmFP:gcc Benchmark.c -o Benchmark-c -lm -fomit-frame-pointer -OX
FHexpe:gcc Benchmark.c -o Benchmark-c -lm -march=pentium3 -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays (http://www.freehackers.org/gentoo/gccflags/flag_g cc3opt.html)
FHEOFP: (FHexpe with -fomit-frame-pointer) gcc Benchmark.c -o Benchmark-c -lm -march=pentium3 -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays
Unsafe: UnsOFP with out (you guessed it: -fomit-frame-pointer) gcc Benchmark.c -o Benchmark-c -lm -march=pentium3 -fforce-addr -falign-functions=4 -ffast-math -O3
UnsOFP: gcc Benchmark.c -o Benchmark-c -lm -fomit-frame-pointer -march=pentium3 -fforce-addr -falign-functions=4 -ffast-math -O3
Bold indicates either leader or within 100ms of leader, Italic indicates a case where omit-frame-pointer is actually faster.
Integer test:
normal: 20990 ms OmitFP: 21410 ms
O3norm: 15230 ms O3OmFP: 15190 ms
O2norm: 15200 ms O2OmFP: 15490 ms
Osnorm: 15190 ms OsOmFP: 15250 ms
FHexpe: 15200 ms FHEOFP: 15500 ms
Unsafe: 15430 ms UnsOFP: 15250 ms Double test:
normal: 22000 ms OmitFP: 23010 ms
O3norm: 17540 ms O3OmFP: 17080 ms
O2norm: 17640 ms O2OmFP: 17370 ms
Osnorm: 21300 ms OsOmFP: 18770 ms
FHexpe: 17180 ms FHEOFP: 17300 ms
Unsafe: 11660 ms UnsOFP: 11710 ms Long test:
normal: 48510 ms OmitFP: 48690 ms
O3norm: 37020 ms O3OmFP: 37770 ms
O2norm: 38040 ms O2OmFP: 38490 ms
Osnorm: 37580 ms OsOmFP: 38290 ms
FHexpe: 38480 ms FHEOFP: 37910 ms
Unsafe: 37560 ms UnsOFP: 38430 ms
Trig test:
normal: 8360 ms OmitFP: 8400 ms
O3norm: 7810 ms O3OmFP: 7890 ms
O2norm: 7970 ms O2OmFP: 8040 ms
Osnorm: 9110 ms OsOmFP: 9000 ms
FHexpe: 7850 ms FHEOFP: 7990 ms
Unsafe: 5600 ms UnsOFP: 5590 ms IO test:
normal: 2110 ms OmitFP: 2200 ms
O3norm: 1950 ms O3OmFP: 2050 ms
O2norm: 2120 ms O2OmFP: 2020 ms
Osnorm: 2120 ms OsOmFP: 2200 ms
FHexpe: 2190 ms FHEOFP: 2120 ms
Unsafe: 2330 ms UnsOFP: 2040 ms Total
normal: 101970 ms OmitFP: 103710 ms
O3norm: 79550 ms O3OmFP: 79980 ms
O2norm: 80970 ms O2OmFP: 81410 ms
Osnorm: 85300 ms OsOmFP: 83510 ms
FHexpe: 80900 ms FHEOFP: 80820 ms
Unsafe: 72580 ms UnsOFP: 73020 ms
"Unsafe" is certainly the fastest, and according to all the printed values, it is accurate, but there is likely a reason why the man page describes -ffast-math as unsafe: I certainly wouldn't use it in anything I would use more than once:) omit-frame-pointer just doesn't seem to be worth losing the debugging capabilities. Suprisingly, after the -ffast-math ones, #3 is simply -O3 without -fomit-frame-pointer (but only by.4 seconds) And another suprise was the IO: I highly suspect that that was mosly being cached in RAM & 7200 rpm drives
But the one area that Open Source is very wanting is easy Application Install packages. You know, click-throughs and what not, fewer compatibility issues, and being able to handle compatibility issues in a more intuitive way.
You need to really look at the strengths of Linux. The Linux package managers are light years ahead of windows. So some random rpm you download doesn't work, using some frontend. You aren't going to have users installing it in the corperate environment. Instead, you will have people issue one command and have it ssh (or other methods) and do an apt-get update, apt-get install new-corperate-package from your private mirror, and possibly apt-get upgrade to install any updates.
The package management is one of the greatest strenghs of Linux. Any GUI Installer thing better work with the native package manager, or it will be as broken as windows is in this area. If you doubt it, test this: install an update to a package (say openoffice) on 6 windows computers, now do the same for 6 linux computers. Up that to 10, 25, 100, 400 computers and you might understand. If you understand it, then the linux command can be one command (admittedly a complex one, but it could be a very simple shell script), but I know of no package managers on Windows that will allow easy installs of packages over a network. (Norton Ghost is $26-36 a seat, and starts to provide equivelent services.)
Those features (and almost every one discussed) are in KDE's Open and Save dialogs.
Howto in KDE #1: icon to the left of the directory, click go to sorting, (un)check case insensitive.
Howto in KDE #2: go to the left side, right click on an icon-> add (or edit) entry, then (un)check "Only show when using this application ($APP_NAME)"
If there are errors, then blame it on the inability to preview,/. gives me error 500...
800cds x 650MB = 520GB for the lossless uncompressed audio. (assuming each CD is 74 minutes long, which seems unlikely)
Now reduce that with flac, or just plain gzip would probably result in something like 100-200GB. Lossy OGG (vorbis), AAC or MP3 could probably reduce it down to approx 50GB (with the vorbis and AAC likely still sounding good) So it's not much more than people hold in their 40GB ipods.
And I will stop refering to Apple users as clueless, when they stop saying the "first 64-bit Personal Computer"
Flashback to 1997: The computer is a 533MHz Alpha Personal Computer from Aspen Systems. 64-bit, still a rather powerful machine, and still in use. (And will be in use for a quite a while via a KVM along with an Opteron)
And btw, your definition of a PC is bunk, because I have a sparc classic workstation, and every single G5 would be larger than that workstation, so by your definition it isn't a Personal Computer.
Running most anything but windows (everyone can probably remember "32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor written by a 2 bit company that can't stand 1 bit of competition.")
The real question is what the 64 bit $BLANK tacked on to the front would be.
Linux: it just works on 64-bit.
Windows: please emulate a 32-bit (or lower) processor*
*I have used NT 4 on alpha (pretty much just acted like it was 32-bit), and know that there is a "64-bit Windows" on Itanium, but if you look at the list of services, a whole lot of windows componets (some of the database stuff even) is emulated x86 code.
There may be an idealogical difference, but frankly there really isn't anything different. And I use IRC nearly the same way as IM. If you really want to get down to it: AIM used to promote the chat rooms/channels...
Ok, so IRC lacks the feature of contact lists, which is fine for any IM service to be somewhat deficient:) Doesn't mean anything more than that.
IM features from some networks: (* indicates IRC has it, client depends on the client)
Person to person chat*
Group chat*
Notifications of status*
File transfers*
Video transfers
Sound play on send/recieve message* (client)
Server side contact lists
Client side contact lists* (client)
Not much difference, just a very suspect idealogical one.
Really though, irc is really no different from most other IMs in the way it can be used. Private message = IM, and a channel = chat room. Just different terms for essentially the same thing.
They may be different server side, but client side, how much difference is there, especially if you use a meta-im (eg kopete). In kopete, adding an AIM, YIM, or IRC contact is the same. Though when you first setup the account you have to specify which of the IRC networks that account connects to, being an extra step over setting up AIM or YIM (one server) on a meta-im client.
PS, Email and IM can work together (psst KDE devs: add kopete into kontact)
Actually this does have benefits (this is relayed from what someone working in the business has said, and seems to agree with most of what I read):
The signal that DTV or HDTV has a lower range (approx 90%) of analog. However, to compensate for that, in that approx 90% range it has the full mpeg-2 stream. No analog artifacts, just digital ones:). It certainly does have advantages, of course the benefits vs cost is a whole other arguement.
The Copy bit is just that... a bit which if you want to using something like gnuradio, you can capture, and flip, or programs under windows, mac etc. Now the legality of doing that may be questionable, but it isn't hard to 'crack'.
Here is the difference, powerpc has had support for 64bit in the arch for a very long time. x86 (or IA-32) has not, and if it were as simple as ppc32->ppc64 then it wouldn't matter on opteron.
You are correct, because it has to change instruction sets.
Opteron changes the instruction set rather radically. The memory addressing becomes different (unlike mac OS X, which still uses 32-bit addressing for apps (kernel can handle 64-bit addresses), and system calls) having 48-bit addresses/pointers.* The largest change in Opteron is the doubling of registers from 32-bit mode (quadrupling if you count the 32-64bit switch), which increases the performance anywhere up to 40% by a simple recompile. 32-bit apps run just fine, but don't get to use the extra registers, so it's rather crippled, of course people rushing to by Opterons for windows are interesting, and foolish. So are the Apple people going: "We're 64-bit, We're 64-bit" Both of those cannot fully take advantage of the processor, nor are they 64-bit. (OS X has some support, but an app doesn't really see it.)
Sadly the main operating system for the two processors is not a full 64-bit OS, for that you have to run Linux or a BSD. (nor is another x86 OS: Solaris) so essentially it's only the free OSes that have 64-bit support, kind of funny waiting for the "Professional", "Innovative" companies to catch up to a bunch of Open-source "hobby" OSes.
*though current Opterons can "only" handle 40-bit physical addresses = 1TB) which will be enough for the moment, or if you have that much money to blow, go talk to someone like cray about custom boxes, because sun & ibm peak at about half of one.
"the FX is one of the most expensive x86 processors on the market - not including the Itanium and large Opteron server CPUs."
Ummmm.... Tom's yet again incorrectly identified a CPU. IA-32 != IA-64 people, however backwards, IA-32 = x86-64... Of course knowing how perceptive people are on/. this has already been posed, right?
Slashdot Mirror
Another Obligatory:Bad RAM Patch for Linux
How long before sizeof(register)?
x86-64 (amd64) is the only one of them (at least sparc, mips, power(pc)) where the number of registers jumped to twice the amount(8->16int, 8fp/mmx, 8->16sse). However, some such as the 21264 alpha (3rd gen core (still in use in the 21364s today)) had 80int, and 80fp (if I recall correctly). Also, The opteron/a64 has an onboard memory controller, which they almost certainly got the inspiration from the alphas.
Basically, on systems that have 32-bit subsets that don't enable new features (all except alpha and x86-64) the 64-bit will likely be a bit slower overall, as the article shows. However, x86-64 will be faster in 64-bit mode almost across the board (at least when compilers take advantage of it) and of course alphas are 64-bit only, so they are infinitely faster in 64-bit mode than 32-bit mode :)
Seriously this is mpeg4-type (divx) & pcm in avi, produced by "Software: MEncoder 0.90-3.2.3" (using most likely libavcodec which mplayer shares with almost anything on linux that wants to support a lot of formats.)
I fail to see your complaint.
Remember applets? Almost every website that wanted to be radical had one of the damned thing. Until people realized that most of them were a waste of time...
On that note: welcome to the year of flash ads, Here's hoping that they go the way of java applets (they have purposes and are useful on some websites, but the majority that had them realized that... they suck)
"Every year we had been hearing that this year was to be the year of the LAN. Allsorts of hype, and eventually it died down, and when it did, LANs were everywhere."
I highly suspect that it is going to be like this for linux :)
Do you think everthing uses MSI to install to windows? Almost everything for linux comesin rpms or source (-> deb or slack, and gentoo can use any thing that can be scripted...)
the virtual memory address space is 4GB, but the Pentium (pro and 2?) 3 and 4 have Intel's PAE (Physical Address Extension) which allows the p3 & p4 to use their 36-bit physical address bus (64GB). Long live paged memory access.
Use Konqueror :) 3.2 betas or cvs and it will spell check. Translation is just a pull down menu away.
look at 2.6.1 changelog, they infact mention running an old a.out format (x86) on x86-64 the only thing not working from an early (suse?) was emacs, which the author didn't take the time to track down.
Note, I am allergic to something in most American cigarettes.
normal:gcc Benchmark.c -o Benchmark-c -lm
OmitFP:gcc Benchmark.c -o Benchmark-c -lm -fomit-frame-pointer
Optimized builds: (replace the X with the number(2,3) or symbol (s)) for example: O3norm:gcc Benchmark.c -o Benchmark-c -lm -O3
OXnorm:gcc Benchmark.c -o Benchmark-c -lm -OX
OXOmFP:gcc Benchmark.c -o Benchmark-c -lm -fomit-frame-pointer -OX
FHexpe:gcc Benchmark.c -o Benchmark-c -lm -march=pentium3 -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays (http://www.freehackers.org/gentoo/gccflags/flag_
FHEOFP: (FHexpe with -fomit-frame-pointer) gcc Benchmark.c -o Benchmark-c -lm -march=pentium3 -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays
Unsafe: UnsOFP with out (you guessed it: -fomit-frame-pointer) gcc Benchmark.c -o Benchmark-c -lm -march=pentium3 -fforce-addr -falign-functions=4 -ffast-math -O3
UnsOFP: gcc Benchmark.c -o Benchmark-c -lm -fomit-frame-pointer -march=pentium3 -fforce-addr -falign-functions=4 -ffast-math -O3
Bold indicates either leader or within 100ms of leader, Italic indicates a case where omit-frame-pointer is actually faster.
Integer test:
:) omit-frame-pointer just doesn't seem to be worth losing the debugging capabilities. Suprisingly, after the -ffast-math ones, #3 is simply -O3 without -fomit-frame-pointer (but only by .4 seconds) And another suprise was the IO: I highly suspect that that was mosly being cached in RAM & 7200 rpm drives
normal: 20990 ms OmitFP: 21410 ms
O3norm: 15230 ms O3OmFP: 15190 ms
O2norm: 15200 ms O2OmFP: 15490 ms
Osnorm: 15190 ms OsOmFP: 15250 ms
FHexpe: 15200 ms FHEOFP: 15500 ms
Unsafe: 15430 ms UnsOFP: 15250 ms
Double test:
normal: 22000 ms OmitFP: 23010 ms
O3norm: 17540 ms O3OmFP: 17080 ms
O2norm: 17640 ms O2OmFP: 17370 ms
Osnorm: 21300 ms OsOmFP: 18770 ms
FHexpe: 17180 ms FHEOFP: 17300 ms
Unsafe: 11660 ms UnsOFP: 11710 ms
Long test:
normal: 48510 ms OmitFP: 48690 ms
O3norm: 37020 ms O3OmFP: 37770 ms
O2norm: 38040 ms O2OmFP: 38490 ms
Osnorm: 37580 ms OsOmFP: 38290 ms
FHexpe: 38480 ms FHEOFP: 37910 ms
Unsafe: 37560 ms UnsOFP: 38430 ms
Trig test:
normal: 8360 ms OmitFP: 8400 ms
O3norm: 7810 ms O3OmFP: 7890 ms
O2norm: 7970 ms O2OmFP: 8040 ms
Osnorm: 9110 ms OsOmFP: 9000 ms
FHexpe: 7850 ms FHEOFP: 7990 ms
Unsafe: 5600 ms UnsOFP: 5590 ms
IO test:
normal: 2110 ms OmitFP: 2200 ms
O3norm: 1950 ms O3OmFP: 2050 ms
O2norm: 2120 ms O2OmFP: 2020 ms
Osnorm: 2120 ms OsOmFP: 2200 ms
FHexpe: 2190 ms FHEOFP: 2120 ms
Unsafe: 2330 ms UnsOFP: 2040 ms
Total
normal: 101970 ms OmitFP: 103710 ms
O3norm: 79550 ms O3OmFP: 79980 ms
O2norm: 80970 ms O2OmFP: 81410 ms
Osnorm: 85300 ms OsOmFP: 83510 ms
FHexpe: 80900 ms FHEOFP: 80820 ms
Unsafe: 72580 ms UnsOFP: 73020 ms
"Unsafe" is certainly the fastest, and according to all the printed values, it is accurate, but there is likely a reason why the man page describes -ffast-math as unsafe: I certainly wouldn't use it in anything I would use more than once
You need to really look at the strengths of Linux. The Linux package managers are light years ahead of windows. So some random rpm you download doesn't work, using some frontend. You aren't going to have users installing it in the corperate environment. Instead, you will have people issue one command and have it ssh (or other methods) and do an apt-get update, apt-get install new-corperate-package from your private mirror, and possibly apt-get upgrade to install any updates.
The package management is one of the greatest strenghs of Linux. Any GUI Installer thing better work with the native package manager, or it will be as broken as windows is in this area. If you doubt it, test this: install an update to a package (say openoffice) on 6 windows computers, now do the same for 6 linux computers. Up that to 10, 25, 100, 400 computers and you might understand. If you understand it, then the linux command can be one command (admittedly a complex one, but it could be a very simple shell script), but I know of no package managers on Windows that will allow easy installs of packages over a network. (Norton Ghost is $26-36 a seat, and starts to provide equivelent services.)
Thank you.
Those features (and almost every one discussed) are in KDE's Open and Save dialogs.
Howto in KDE #1: icon to the left of the directory, click go to sorting, (un)check case insensitive.
Howto in KDE #2: go to the left side, right click on an icon-> add (or edit) entry, then (un)check "Only show when using this application ($APP_NAME)"
If there are errors, then blame it on the inability to preview, /. gives me error 500...
800cds x 650MB = 520GB for the lossless uncompressed audio. (assuming each CD is 74 minutes long, which seems unlikely)
Now reduce that with flac, or just plain gzip would probably result in something like 100-200GB. Lossy OGG (vorbis), AAC or MP3 could probably reduce it down to approx 50GB (with the vorbis and AAC likely still sounding good) So it's not much more than people hold in their 40GB ipods.
Flashback to 1997: The computer is a 533MHz Alpha Personal Computer from Aspen Systems. 64-bit, still a rather powerful machine, and still in use. (And will be in use for a quite a while via a KVM along with an Opteron)
And btw, your definition of a PC is bunk, because I have a sparc classic workstation, and every single G5 would be larger than that workstation, so by your definition it isn't a Personal Computer.
Running most anything but windows (everyone can probably remember "32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor written by a 2 bit company that can't stand 1 bit of competition.")
The real question is what the 64 bit $BLANK tacked on to the front would be.
Linux: it just works on 64-bit.
Windows: please emulate a 32-bit (or lower) processor*
*I have used NT 4 on alpha (pretty much just acted like it was 32-bit), and know that there is a "64-bit Windows" on Itanium, but if you look at the list of services, a whole lot of windows componets (some of the database stuff even) is emulated x86 code.
There may be an idealogical difference, but frankly there really isn't anything different. And I use IRC nearly the same way as IM. If you really want to get down to it: AIM used to promote the chat rooms/channels...
Ok, so IRC lacks the feature of contact lists, which is fine for any IM service to be somewhat deficient :) Doesn't mean anything more than that.
IM features from some networks: (* indicates IRC has it, client depends on the client)
Person to person chat*
Group chat*
Notifications of status*
File transfers*
Video transfers
Sound play on send/recieve message* (client)
Server side contact lists
Client side contact lists* (client)
Not much difference, just a very suspect idealogical one.
They may be different server side, but client side, how much difference is there, especially if you use a meta-im (eg kopete). In kopete, adding an AIM, YIM, or IRC contact is the same. Though when you first setup the account you have to specify which of the IRC networks that account connects to, being an extra step over setting up AIM or YIM (one server) on a meta-im client.
PS, Email and IM can work together (psst KDE devs: add kopete into kontact)
The signal that DTV or HDTV has a lower range (approx 90%) of analog. However, to compensate for that, in that approx 90% range it has the full mpeg-2 stream. No analog artifacts, just digital ones :). It certainly does have advantages, of course the benefits vs cost is a whole other arguement.
The Copy bit is just that... a bit which if you want to using something like gnuradio, you can capture, and flip, or programs under windows, mac etc. Now the legality of doing that may be questionable, but it isn't hard to 'crack'.
You are correct, because it has to change instruction sets.
Opteron changes the instruction set rather radically. The memory addressing becomes different (unlike mac OS X, which still uses 32-bit addressing for apps (kernel can handle 64-bit addresses), and system calls) having 48-bit addresses/pointers.* The largest change in Opteron is the doubling of registers from 32-bit mode (quadrupling if you count the 32-64bit switch), which increases the performance anywhere up to 40% by a simple recompile. 32-bit apps run just fine, but don't get to use the extra registers, so it's rather crippled, of course people rushing to by Opterons for windows are interesting, and foolish. So are the Apple people going: "We're 64-bit, We're 64-bit" Both of those cannot fully take advantage of the processor, nor are they 64-bit. (OS X has some support, but an app doesn't really see it.)
Sadly the main operating system for the two processors is not a full 64-bit OS, for that you have to run Linux or a BSD. (nor is another x86 OS: Solaris) so essentially it's only the free OSes that have 64-bit support, kind of funny waiting for the "Professional", "Innovative" companies to catch up to a bunch of Open-source "hobby" OSes.
*though current Opterons can "only" handle 40-bit physical addresses = 1TB) which will be enough for the moment, or if you have that much money to blow, go talk to someone like cray about custom boxes, because sun & ibm peak at about half of one.
or for most other cards (bt878 or bt848) BTTV (included in the linux kernel)
Ummmm.... Tom's yet again incorrectly identified a CPU. IA-32 != IA-64 people, however backwards, IA-32 = x86-64... Of course knowing how perceptive people are on /. this has already been posed, right?
Kind of says something about Windows 95, no? That a OS for Commodore 64s is almost as usable. :)