Drag and drop? I've gotten spoiled by just plugging my iPod in, waiting 30 seconds while it automatically updates everything, and then unplugging
That's not exactly rocket science or a complex programming effort. Rather, it's a five line USB hotplug script on Linux (using rsync) that works with every player: iPod, Zen, whatever.
The bottom line is that Silver sees some cost savings in migrating to the Linux desktop but says the move "will probably not eliminate all of the costs the enterprises expects."
Isn't that all that counts?
Perhaps they should now go back and write "Myths of Windows on the Desktop", like:
Myth: Windows is easy to use
Myth: Everybody runs windows
Myth:.DOC is a good document interchange format
Myth: Windows development tools are high quality and productive
Myth: Windows is professionally supported
Myth: Windows admin tools are easier to use than UNIX's text-based configuration
Myth: Windows NTFS provides reliability and performance
You don't have to patent something to keep it "accessible", you can simply disclose it.
It seems to come down to that the institute is patenting the sequence, they do want to make money from it, they are just trying to put a positive spin on it. And the researcher, while opposed to it, is pretty much powerless to do anything about it and just tries to keep his name off the application.
And yet, you think I would want to put all my trust the sanity of other world leaders to not fire nuclear weapons at the U.S.?
Yes, I want you to put your trust into the general sanity of other nations. Not "all" your trust, but enough trust not to hunker like a paranoid xenophobe under some supposedly impenetrable shield. And not "all" nations--there are going to be rogue nations. And the US should put sufficient trust in the rest of the world that if the US were to be attacked, alliances like NATO would come to their help.
Even without SDI and without international help, the US has more than enough power for a devastating retaliatory strike.
What is happening right now is that US actions are increasingly removed from consequences: the US doesn't have to worry about what anybody else thinks. Bombing Iraq makes France unhappy? Too bad. Threatening North Korea displeases China? Who gives a damn. Iranians are worried about a US invasion? Well, get used to it. Nations are worried about getting flooded because of global warming? We don't care because we don't have to.
In the end, that approach is doomed to failure. No matter how "safe" (i.e., totalitarian) the US becomes internally, it will remain vulnerable to terrorism. And despite all its military power, ultimately, the US stands and falls with its economy, and the US ultimately can't employ its military force without destroying that.
Americans need to think long and hard about the consequences of their foreign policy decisions, or America is heading for disaster. And a feeling of vulnerability is part of that. Without it, the US will just keep making bad decisions until it's too late.
SPEC uses less and less Fortran, while C is almost impossible to optimize for SIMD without (non-standard) hints
No kidding. But that's the language that people happen to use a lot. Adding instructions that speed up code in languages nobody uses isn't going to do much good.
If companies like Motorola, IBM, or Intel want to change that, then they have to come up with non-proprietary solutions. That means, say, an open, standard SIMD C language extension.
Motorola's broken and processor-specific AltiVec extensions and Intel's proprietary P4 compilers just don't cut it, and claiming high performance using such proprietary systems is an underhanded attempt to tie users to specific processor architectures.
IOW SPEC doesn't say much about SIMD speed.
And, as I was saying, that's the way it should be as far as I'm concerned: SIMD speed just isn't interesting beyond what real compilers manage to do automatically with it for real programs written in real languages.
considering that Apple has carefully optimized the vast majority of the system library functions that could benefit from Altivec, and provides routines like FFT, BLAS (matrix multiply),
and other building blocks that usually represent the main bottlenecks for scientific applications.
If there was only one FFT and linear algebra package in the world, you'd have somewhat of a point. However, in the real world, there are dozens, and few of them are optimized for AltiVec. Chances are that if you run a mix of applications, most of them will not be able to take advantage of AltiVec (or SSE2). If you happen to have a single application and you know ahead of time that it relies on AltiVec-optimized libraries, you may be in luck. But, then, there is still the issue that PowerPC-based machines are so expensive that even if everything ran at AltiVec speeds, it's still not clear they would be a good deal.
Altivec, it performs 2-4x better.
Well, that itself is a problem. I don't want a chip that works really fast for some things and is kind of mediocre for others (given its price). The P4 with all its gimmicks actually has a similar problem.
It says exactly what it should say about SIMD speed: "how fast does regular C/Fortran code run when I compile it with a regular compiler". If the compiler can figure out how to transform, say, Fortran array code into SIMD, it will help the SPECmarks. If not, then whatever SIMD features the chip has are useless for most applications, in particular scientific applications. The exception are a few specially crafted apps like Photoshop plugins and MP3 encoders.
You are confusing the word "innovate" with "invent". Innovation is the "introduction of something new".
Yes, "introduction to the world". If you define it as "introduction to the markets", it loses its significance or meaning.
There is a big difference. Journaling filesystems were invented 20 years ago (or more, the time frame doesn't matter). But packaging them, refining them, putting it in a way that is useful for the masses is *exactly* what innovation is - introduction to the masses.
I'm sorry, but what needs to be "refined" about a journaling file system? They are drop-in replacements for regular file systems and pretty much always have been. Microsoft or Apple could have incorporated them into their systems years ago without users even noticing.
Integrating RDBMS features with a JFS and putting them in a format where users can search for their media files without being a computer scientist is innovative,
No, it's not. That idea has been around for decades. It's the kind of idea that just about every beginning computer science student has. And it's a stupid idea because it doesn't actually get at what makes files hard to find and data hard to organize.
doesn't discount MS's achievement of bringing polished features to the masses for $99 (and same goes for Apple).
MS and Apple bring this stuff to the masses because they have significant market shares. Any junk they put out will be brought to the masses. And because they are pretty much the only ones that can do this sort of thing, any junk they put out will be "innovative" by your definition. That just makes the term "innovative" synonymous with "anything Microsoft or Apple release"; I don't think we need an English word for that.
Re:plenty of toolkits like that already
on
Who Needs XFree86?
·
· Score: 1
That doesn't even come close in covering the text-based "windowing" toolkits. Text-based data entry and access using multiple regions existed before that on mainframes.
As an aside, while it contains a useful collection of dates and screenshots, several of the comments are just wrong, and the author has some axes to grind.
Oh, I should add that it looks like IBM will be having a 2.5GHz version of the chip as well; but that will also just be keeping up with equivalent Intel/AMD chips at the time.
Overall, the Intel/AMD architecture used to be a real problem for their chips, but today, those chips are just pretty modern chips internally, with a compatibility layer that turns the x86 instruction stream into something more RISCy. Most of the differences between chips are probably due to the processes used.
The French site is slashdotted, but SPECmark estimates are out on the web here. The relevant quote is:
When the PowerPC 970 first ships in the second half of 2003, it should clock in at around 1.8GHz on a 0.13 micron, 8-layer SOI process with copper interconnects. [...] The estimated SPEC INT and SPEC FP numbers (937 and 1051) would allow the 970 to clearly dominate the desktop scene were it released tomorrow, but by the time we see this chip in a shipping system the performance landscape will look significantly different in both the 32-bit (P4 at 4GHz+ with SMT) and 64-bit (AMD's Hammer) desktop markets. I won't try to predict exactly how it will stack up to the x86 and x86-64 offerings in late 2003/early 2004, but when it finally ships the 970 certainly won't spanking anything from Intel or AMD in the SPEC benchmarks. It should, however, enable Apple to avoid the kind of overpriced embarrassment (from a hardware perspective, at least) that is their current "pro" desktop line. And in fact a dual- or quad-970 system could potentially compare quite nicely in terms of price/performance to a single-processor Prescott or Hammer machine.
Note that a 3GHz P4 system already gets SPECint and SPECfp of 1130 and 1085, and AMD's Opteron may be slightly faster yet (and give you an optional 64 bit mode).
plenty of toolkits like that already
on
Who Needs XFree86?
·
· Score: 4, Insightful
back when most people were computing on vt100s, there were a number of toolkits like that. vt100s even have built in support for text windows.
If Microsoft or Apple had been concerned about performance, they would have dumped (V)FAT and HFS(+) a long time ago. Furthermore, while there may be some overhead, it's not necessarily "major".
90% of MS's users and perhaps 99% of Apple's users gain no benefit from a journaling file-system.
Quite to the contrary: journaling is primarily a consumer feature: it makes it less bad when people turn off their computer accidentally. It is less useful on servers (although widely used).
And to accomodate those 1%-10% of users at the cost of a performance hit to all users is simply non-acceptable.
As several implementations show, it's easy to make the degree of journaling configurable even for the same file system: none, metadata, or data. So, everybody can choose.
Just because a technology is aroudn doesn't mean it should be on everyone's mainstream OS in a few weeks or months or even years.
Sure. The only issue is that Microsoft and Apple claim they are innovating when, as you correctly observe, they actually aren't.
Congratulations: Intel discovers why companies like Ericsson have been working so hard on Bluetooth. And why Apple has been working so hard on Rendezvous.
And devices for this kind of usage are already appearing: Sony, Toshiba, and a few other companies have developed personal wireless file servers. Internet connectivity comes via a Bluetooth phone. Wireless head sets and keyboards give you sound and data entry. And a wirelessly networked PDA gives you a screen.
However, it makes sense to include a small screen on any wireless server you carry around, like Oqo, Antelope, and Tiqit are doing. Also, it makes sense to keep certain functions separate, like the cell phone, file server, and screen.
And Windows users have had since... 1994? NTFS is journaling, and was WELL before e2fs was...
Yes, but merely using a journal doesn't make a file system useful or robust. (Note that NTFS makes almost no guarantees about what it recovers or how it recovers it.)
Of course, implementations of journaling file systems go back pretty much as far as the first relational databases--making the database the file system was one of the first obvious ideas.
(any of you old-school Linux users remember pulling the plug or hitting power on your Linux box back in the day and immediately screaming "OH SHIT!" when you realize you probably just corrupted a whole slew of data? I do.)
And that should still be your reaction because journaling doesn't protect you from that (although they can somewhat lessen the impact because stuff tends to get written to disk much more quickly).
Journaling file systems are a reasonably nice convenience feature, but they are neither necessary nor sufficient for data integrity.
Journaling filesystems are transaction based
similar to how dbms's work.
Yes.
All activity is written to a transaction log and every once and a while the transaction log is written to disk
No. Only some activity is written to a transaction log. What can be recovered from the log depends on when and how stuff is written into the log.
If you crash before a transaction log is written to disk, you lose that transaction, if you crash after the transaction log is written, but before the update log is written, the os can redo the transaction.
No journaling file system can do that for regular software because regular software doesn't use transaction-based APIs to talk to the file system. That is, there are no transactions to redo because there are no well-defined transactions in the first place. I/O subsystems may invent transactional semantics for system calls like "open" and "write", but that doesn't help much because programs don't expect them (and if not done very carefully may actually break things).
Using a journaling file system for general-purpose computing just gives you fast recovery after a crash (at the cost of some runtime performance). It makes no useful guarantees to applications. To get useful transactional guarantees, applications need to use special APIs.
Is this a competition among Microsoft and Apple to see who is less outdated?
Journaling file systems are, what, a couple of decades old? Microsoft didn't invent them. Apple didn't invent them. The real question is: what took either of them so long to incorporate them?
Re:Journaling File System: for those who don't kno
on
Looking at Longhorn
·
· Score: 4, Informative
Journaling file systems are transaction based. If a transaction fails partway through (IE the system crashes) the state of the disk is the same as if the transaction had never started, and is thus always consistent.
That's just wrong on several levels.
First of all, the file system is not consistent after a crash: journaling file systems need to replay the journal in order to make it consistent. This is no different in principle from non-journaling file systems (which, traditionally, also have incorporated various features to permit recovery), it just happens to be faster.
Second, I/O APIs usually do not define a notion of "transaction" at the file system level, and even if they do, there aren't a whole lot of guarantees you can make that are particularly useful. In fact, journaling file systems and transaction-based file systems really are very different things. A journaling file system can be used to implement a transaction-based file system, but it can also be used just to implement fast recovery.
Third, for performance reasons, very few journaling file systems journal file content; they only worry about meta-data. And NTFS falls back a step further by making particularly weak guarantees. For example, if I create files "a", "b", and "c" in that sequence, with three separate programs, after a crash, any combination of those files may be present, and their content may be arbitrarily messed up.
Re:NEWSFLASH, NTFS is a journaling filesystem!
on
Looking at Longhorn
·
· Score: 0, Troll
It may use a journal somewhere, but it makes virtually no useful guarantees about file system integrity. In different words, as usual, marketing and reality are far apart when it comes to Windows.
The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.
Programs compiled for the x86 architecture may well assume that they don't have to set the executable bit on pages because the hardware doesn't support it anyway. Whether such programs are "correct" or not, this patch may break applications.
I don't know what you are referring to. Logging in as root is no different from running a program with "su" or "sudo"--you can screw up your system in the same way. And using X11 as root is also fine--any reasonable X11 installation will default to local-only, UNIX-domain connections, making it as secured as any other root-owned resource on the system.
Logging in as root is the traditional way to administer UNIX systems, and it's still perfectly fine.
According to one expert, the bills are 'tremendously open-ended and create theoretical and potential criminal liabilities for just about anybody on the planet
This may come as a tremendous surprise to lawyers and Americans, but the majority of people on this planet don't get cable and don't have VCRs.
In fact, I would say that the US would be a whole lot better off if fewer people had cable and if fewer people watched junk like Disney, Fox, or CNN.
The fact that it's 64-bit will only help you (double the speed, actually) if you're operating on 64-bit variables, which don't come up in general software very much, but are very good for scientific research, simulations, etc.
No, that's just not true. "64 bit" these days only tells you something about the size of a pointer but not much more. Beyond that, 16 bit, 32 bit, and 64 bit processors have a wide variety of operations, ALUs, and bus widths. There are "32 bit processors" with 16 bit data buses, "32 bit processors" with 128 bit data buses, etc.
It is very unlikely that on a well-defined 64 bit processors, half the processor remains idle when you use 32 bit operations.
In any case, my point was that the main reason for going to 64 bit is not speed. It just happens to be the case that the AMD Opteron is probably also the fastest 32 bit x86 chip around right now.
Breaking the 4G of memory does come at a cost, though. If your code uses a whole lot of pointers (many CAD & EDA packages do), then because the pointers take up twice the space they used to, you'll need up to 8G of physical memory to do the same task you could do with 4G on a 32-bit system. And twice the cache, and twice the memory bandwidth, too. It's a pretty steep cost!
That may be true for your average, poorly written desktop software, but it is false for well-written scientific or engineering software.
Such software usually uses arrays and indexes that are determined by problem size, as opposed to making everything a pointer. Many such programs may use 8 bit or 16 bit indexes for most of their data. Going to a 64 bit processor often will not affect the memory footprint of such programs significantly.
Slashdot Mirror
That's not exactly rocket science or a complex programming effort. Rather, it's a five line USB hotplug script on Linux (using rsync) that works with every player: iPod, Zen, whatever.
Perhaps they should now go back and write "Myths of Windows on the Desktop", like:
- Myth: Windows is easy to use
- Myth: Everybody runs windows
- Myth:
.DOC is a good document interchange format
- Myth: Windows development tools are high quality and productive
- Myth: Windows is professionally supported
- Myth: Windows admin tools are easier to use than UNIX's text-based configuration
- Myth: Windows NTFS provides reliability and performance
I could go on...It seems to come down to that the institute is patenting the sequence, they do want to make money from it, they are just trying to put a positive spin on it. And the researcher, while opposed to it, is pretty much powerless to do anything about it and just tries to keep his name off the application.
Altogether, this is not a good sign.
Yes, I want you to put your trust into the general sanity of other nations. Not "all" your trust, but enough trust not to hunker like a paranoid xenophobe under some supposedly impenetrable shield. And not "all" nations--there are going to be rogue nations. And the US should put sufficient trust in the rest of the world that if the US were to be attacked, alliances like NATO would come to their help.
Even without SDI and without international help, the US has more than enough power for a devastating retaliatory strike.
What is happening right now is that US actions are increasingly removed from consequences: the US doesn't have to worry about what anybody else thinks. Bombing Iraq makes France unhappy? Too bad. Threatening North Korea displeases China? Who gives a damn. Iranians are worried about a US invasion? Well, get used to it. Nations are worried about getting flooded because of global warming? We don't care because we don't have to.
In the end, that approach is doomed to failure. No matter how "safe" (i.e., totalitarian) the US becomes internally, it will remain vulnerable to terrorism. And despite all its military power, ultimately, the US stands and falls with its economy, and the US ultimately can't employ its military force without destroying that.
Americans need to think long and hard about the consequences of their foreign policy decisions, or America is heading for disaster. And a feeling of vulnerability is part of that. Without it, the US will just keep making bad decisions until it's too late.
No kidding. But that's the language that people happen to use a lot. Adding instructions that speed up code in languages nobody uses isn't going to do much good.
If companies like Motorola, IBM, or Intel want to change that, then they have to come up with non-proprietary solutions. That means, say, an open, standard SIMD C language extension.
Motorola's broken and processor-specific AltiVec extensions and Intel's proprietary P4 compilers just don't cut it, and claiming high performance using such proprietary systems is an underhanded attempt to tie users to specific processor architectures.
IOW SPEC doesn't say much about SIMD speed.
And, as I was saying, that's the way it should be as far as I'm concerned: SIMD speed just isn't interesting beyond what real compilers manage to do automatically with it for real programs written in real languages.
If there was only one FFT and linear algebra package in the world, you'd have somewhat of a point. However, in the real world, there are dozens, and few of them are optimized for AltiVec. Chances are that if you run a mix of applications, most of them will not be able to take advantage of AltiVec (or SSE2). If you happen to have a single application and you know ahead of time that it relies on AltiVec-optimized libraries, you may be in luck. But, then, there is still the issue that PowerPC-based machines are so expensive that even if everything ran at AltiVec speeds, it's still not clear they would be a good deal.
Altivec, it performs 2-4x better.
Well, that itself is a problem. I don't want a chip that works really fast for some things and is kind of mediocre for others (given its price). The P4 with all its gimmicks actually has a similar problem.
It says exactly what it should say about SIMD speed: "how fast does regular C/Fortran code run when I compile it with a regular compiler". If the compiler can figure out how to transform, say, Fortran array code into SIMD, it will help the SPECmarks. If not, then whatever SIMD features the chip has are useless for most applications, in particular scientific applications. The exception are a few specially crafted apps like Photoshop plugins and MP3 encoders.
Yes, "introduction to the world". If you define it as "introduction to the markets", it loses its significance or meaning.
There is a big difference. Journaling filesystems were invented 20 years ago (or more, the time frame doesn't matter). But packaging them, refining them, putting it in a way that is useful for the masses is *exactly* what innovation is - introduction to the masses.
I'm sorry, but what needs to be "refined" about a journaling file system? They are drop-in replacements for regular file systems and pretty much always have been. Microsoft or Apple could have incorporated them into their systems years ago without users even noticing.
Integrating RDBMS features with a JFS and putting them in a format where users can search for their media files without being a computer scientist is innovative,
No, it's not. That idea has been around for decades. It's the kind of idea that just about every beginning computer science student has. And it's a stupid idea because it doesn't actually get at what makes files hard to find and data hard to organize.
doesn't discount MS's achievement of bringing polished features to the masses for $99 (and same goes for Apple).
MS and Apple bring this stuff to the masses because they have significant market shares. Any junk they put out will be brought to the masses. And because they are pretty much the only ones that can do this sort of thing, any junk they put out will be "innovative" by your definition. That just makes the term "innovative" synonymous with "anything Microsoft or Apple release"; I don't think we need an English word for that.
As an aside, while it contains a useful collection of dates and screenshots, several of the comments are just wrong, and the author has some axes to grind.
Overall, the Intel/AMD architecture used to be a real problem for their chips, but today, those chips are just pretty modern chips internally, with a compatibility layer that turns the x86 instruction stream into something more RISCy. Most of the differences between chips are probably due to the processes used.
back when most people were computing on vt100s, there were a number of toolkits like that. vt100s even have built in support for text windows.
If Microsoft or Apple had been concerned about performance, they would have dumped (V)FAT and HFS(+) a long time ago. Furthermore, while there may be some overhead, it's not necessarily "major".
90% of MS's users and perhaps 99% of Apple's users gain no benefit from a journaling file-system.
Quite to the contrary: journaling is primarily a consumer feature: it makes it less bad when people turn off their computer accidentally. It is less useful on servers (although widely used).
And to accomodate those 1%-10% of users at the cost of a performance hit to all users is simply non-acceptable.
As several implementations show, it's easy to make the degree of journaling configurable even for the same file system: none, metadata, or data. So, everybody can choose.
Just because a technology is aroudn doesn't mean it should be on everyone's mainstream OS in a few weeks or months or even years.
Sure. The only issue is that Microsoft and Apple claim they are innovating when, as you correctly observe, they actually aren't.
And devices for this kind of usage are already appearing: Sony, Toshiba, and a few other companies have developed personal wireless file servers. Internet connectivity comes via a Bluetooth phone. Wireless head sets and keyboards give you sound and data entry. And a wirelessly networked PDA gives you a screen.
However, it makes sense to include a small screen on any wireless server you carry around, like Oqo, Antelope, and Tiqit are doing. Also, it makes sense to keep certain functions separate, like the cell phone, file server, and screen.
Yes, but merely using a journal doesn't make a file system useful or robust. (Note that NTFS makes almost no guarantees about what it recovers or how it recovers it.)
Of course, implementations of journaling file systems go back pretty much as far as the first relational databases--making the database the file system was one of the first obvious ideas.
(any of you old-school Linux users remember pulling the plug or hitting power on your Linux box back in the day and immediately screaming "OH SHIT!" when you realize you probably just corrupted a whole slew of data? I do.)
And that should still be your reaction because journaling doesn't protect you from that (although they can somewhat lessen the impact because stuff tends to get written to disk much more quickly).
Journaling file systems are a reasonably nice convenience feature, but they are neither necessary nor sufficient for data integrity.
Yes.
All activity is written to a transaction log and every once and a while the transaction log is written to disk
No. Only some activity is written to a transaction log. What can be recovered from the log depends on when and how stuff is written into the log.
If you crash before a transaction log is written to disk, you lose that transaction, if you crash after the transaction log is written, but before the update log is written, the os can redo the transaction.
No journaling file system can do that for regular software because regular software doesn't use transaction-based APIs to talk to the file system. That is, there are no transactions to redo because there are no well-defined transactions in the first place. I/O subsystems may invent transactional semantics for system calls like "open" and "write", but that doesn't help much because programs don't expect them (and if not done very carefully may actually break things).
Using a journaling file system for general-purpose computing just gives you fast recovery after a crash (at the cost of some runtime performance). It makes no useful guarantees to applications. To get useful transactional guarantees, applications need to use special APIs.
Journaling file systems are, what, a couple of decades old? Microsoft didn't invent them. Apple didn't invent them. The real question is: what took either of them so long to incorporate them?
That's just wrong on several levels.
First of all, the file system is not consistent after a crash: journaling file systems need to replay the journal in order to make it consistent. This is no different in principle from non-journaling file systems (which, traditionally, also have incorporated various features to permit recovery), it just happens to be faster.
Second, I/O APIs usually do not define a notion of "transaction" at the file system level, and even if they do, there aren't a whole lot of guarantees you can make that are particularly useful. In fact, journaling file systems and transaction-based file systems really are very different things. A journaling file system can be used to implement a transaction-based file system, but it can also be used just to implement fast recovery.
Third, for performance reasons, very few journaling file systems journal file content; they only worry about meta-data. And NTFS falls back a step further by making particularly weak guarantees. For example, if I create files "a", "b", and "c" in that sequence, with three separate programs, after a crash, any combination of those files may be present, and their content may be arbitrarily messed up.
It may use a journal somewhere, but it makes virtually no useful guarantees about file system integrity. In different words, as usual, marketing and reality are far apart when it comes to Windows.
Programs compiled for the x86 architecture may well assume that they don't have to set the executable bit on pages because the hardware doesn't support it anyway. Whether such programs are "correct" or not, this patch may break applications.
I don't know what you are referring to. Logging in as root is no different from running a program with "su" or "sudo"--you can screw up your system in the same way. And using X11 as root is also fine--any reasonable X11 installation will default to local-only, UNIX-domain connections, making it as secured as any other root-owned resource on the system.
Logging in as root is the traditional way to administer UNIX systems, and it's still perfectly fine.
According to one expert, the bills are 'tremendously open-ended and create theoretical and potential criminal liabilities for just about anybody on the planet
This may come as a tremendous surprise to lawyers and Americans, but the majority of people on this planet don't get cable and don't have VCRs.
In fact, I would say that the US would be a whole lot better off if fewer people had cable and if fewer people watched junk like Disney, Fox, or CNN.
Or get one of these: Icom R3. Far more portable.
No, that's just not true. "64 bit" these days only tells you something about the size of a pointer but not much more. Beyond that, 16 bit, 32 bit, and 64 bit processors have a wide variety of operations, ALUs, and bus widths. There are "32 bit processors" with 16 bit data buses, "32 bit processors" with 128 bit data buses, etc.
It is very unlikely that on a well-defined 64 bit processors, half the processor remains idle when you use 32 bit operations.
In any case, my point was that the main reason for going to 64 bit is not speed. It just happens to be the case that the AMD Opteron is probably also the fastest 32 bit x86 chip around right now.
That may be true for your average, poorly written desktop software, but it is false for well-written scientific or engineering software.
Such software usually uses arrays and indexes that are determined by problem size, as opposed to making everything a pointer. Many such programs may use 8 bit or 16 bit indexes for most of their data. Going to a 64 bit processor often will not affect the memory footprint of such programs significantly.