What kind of puns can you make with Rosen? Rosin? Resin? What fills her brain? See, not funny.
Now Bainwol is a name you can really sink your teeth into. I mean, it even sounds evil. And think of the jokes! Swap 'bain' for 'bane' and you're off and running.
When should we expect to hear about Netcraft being sued?
Obviously, netcraft is Blizzard's next hit, wherein the few remaining human loyalists valiantly defend their networks from the hordes of Zerg viruses. Those survey folks are just confusing people.
Ok. Have to remember, in reading future BSA press releases that
"It is welcoming news to learn that the worldwide software piracy problem has improved significantly..."
and
"However, it's critical to recognise that the industry is facing a spiralling Internet piracy problem."
are not mutually exclusive statements. I wonder if that trick would work in board meetings. "Cost projections have improved significantly" sure sounds a lot better than "Costs are spiralling out of control"!
Is that what I have? So "standalone installation" is Microsoft code for "Well, we'll let you delete it (it goes in the recycle bin and all) but it instantly comes back"?
If WinXP wants to protect its help system, that's fine. But the IE frontend shouldn't have anything to do with that. And even so, there's no excuse for Outlook being undeletable. It doesn't show up in the Add/Remove applications window, even under "Windows components"
Harder to copy? Harder than what? You stick it in the drive and hit "copy all files" and presto (10 minutes later), there it is. With all the.ifo files and everything intact. PowerDVD and WinDVD happily play DVD file structures from a hard drive, and should that fail the.vob files are playable by themselves.
An average DVD is around 5-6GB, which at current disk prices costs about $5. Add to that a $2 rental fee, and you've got yourself a half-price DVD (or third, depending). With a bit more effort and a lot more CPU time you can mpeg4 (Divx, Xvid, etc.) encode the main video and cut that $7 in half again, or you can buy a VHS tape and record it to that (but why would you want to?).
Copying DVDs (at least, for personal use) is just as easy as copying CDs: insert, click, wait, eject.
Distribution of movies is harder though because of the size, I'll grant you that. There are 9.4G recordable DVDs, but the lack of a single standard has dramatically slowed adoption of the technology, and with prices what they are, it's cheaper to put things on hard drives and trade them that way.
You can build a pretty nice computer for $500. A good motherboard + XP2000 + 512M RAM + 80G HDD + nice case/PSU comes out under the $500 mark. Just add monitor and keyboard.
Your average computer user needs far less in terms of hardware, and even a geek could hold his head up with a $500 computer these days. It's getting harder and harder to justify spending much more, except on peripherals.
But since I don't play games under Linux, the question's moot. In fact, I have two Redhat machines here and one *BSD machine, none of which even have X installed.
Samba, dhcpd, apache, squid, and the rest don't run any better with X installed, so why bother?
I also don't game much under Windows, so I'm asking out of ignorance rather than malice whether there are enough recent Linux games to justify the hassle. Is linux a reasonable alternative gaming platform to Windows?
Suppose your gateway, rather than forwarding requests, actually creates a new IP packet. Does that mean only one machine is "accessing" your connection?
What if you download a movie onto the net-connected box and then SCP it to another machine. Is that other machine accessing the connection? If not, what delay must exist between data arriving at the gateway and arriving at the eventual destination in order for it not to count as access? A NAT or proxy box basically fetches things on behalf of a different machine. Downloading a movie on the box with the DSL connection and then moving it to a different machine is the same, except it's being done manually.
Anyway, those are my ramblings having not read the article yet.
Example: Seagate 15krpm drive: average seek time 3.6ms. You are correct that the *average* rotational latency will be 2ms, since the full rotational latency is 4ms. However, 2ms out of 3.6ms is more than half, meaning rotational latency dominates (even though you were right about the average rotational latency being important, not the full rotational latency).
Seek time is 3.6ms. Access time is 5.6ms. The seek time is the time it takes for the heads to seek to the proper location. This is followed by (correct, an average of) 2ms of rotational latency, for a total (again, average) 5.6ms access time.
I don't know why you think that seek time on large drives is of no importance... Because for the majority of users, it is.
You're correct that large files can be fragmented, but the fact is that most users' large files (movies, audio, etc.) are never edited, meaning no excess fragments are created. Then the only source of fragmentation is deletions, which produces relatively little fragmentation. Your million files in 100G is still 100K/file, rather larger than my boot drive (which I assume for lack of further evidence to be "normal").
Taking the time to check fragments, I have 13602 fragments in 90G (~6.6M/fragment) for data and 112594 fragments in 5.75G (~50K/fragment) for boot/apps. The ratio is still about the same.
As for concurrent reads, this is a problem of firmware optimization. Two applications making full-out reads of two separate files should be served by firmware in the following manner: the drive reads a buffer-full of one file and then seeks to the other. In an STR-bound application like this, the drive seeks as little as possible. In a situation where applications are making repeated small (but sequential) reads, the firmware should seek to maintain a buffer half-full of one file and half-full of the other, performing read-ahead caching to allow bits of each file to be sent to the host with a minimum of seeking on the drive's part.
There are few circumstances where firmware optimization cannot mask seek performance, and these typically involve small datasets or are not suitable for large drives for other reasons.
You've got some problems with your facts. But, since you're playing the math games that I like to play, I'll cut you some slack. And then I'll expound.
First off, disk access time is dominated by actuator movement (seek time). Rotational latency on a 15,000rpm disk is 2ms, not 4. The fastest 15K drives have 3.5-4ms seek time. Slower drives have slower actuators, meaning the ratio of seek time to rotational latency is about the same, 2:1.
Seek time on large drives is of no importance. Seek time on small drives is of supreme importance. Small drives should be used to store the OS, applications, and small data files. Rapid access to disparate regions of the disk is important since these drives are primarily limited by IO/sec. Large drives are used for mass data storage. Large data storage (media, in my case) is dominated naturally enough by large files whereas applications and user data tend to be tiny. My media drive, for example has about 11,000 files in 95GB, or about 110 seeks/GB. My OS/apps drive, on the other hand, has over 89,000 files in 5.75GB, or 16000 seeks/GB.
Consider that a high-end drive can handle perhaps 600 IO/sec, and a large IDE drive can handle perhaps 150. Clearly then we have a problem: usage patterns differing by 150:1 in terms of number of seeks are not matched well to drives differing by 4:1 in seek performance. As you've demonstrated, physics cannot allow us to increase SCSI's seek performance to 150X that of bulk IDE drives.
The only way to achieve that sort of performance is with solid state storage. RAM costs about $150/GB - let's see someone mass-produce consumer-grade SSDs. Call it the "drive accelerator" and build it into a removable HDD bay. I guarantee that 1GB of RAM caching the most-used files on a hard drive would see performance skyrocket. Sure, it would be expensive, but it would be cheaper than the 15k SCSI boot disk I have, and a whole lot faster.
Proof the USPTO isn't *totally* clueless
on
Prince of Pop-ups
·
· Score: 1
They grant this guy a patent. Then he starts suing people. They either pay up, in which case he has more money to pursue patents, or they refuse and the money that would be spent crafting more intrusive advertising gets wasted on lawyers instead. No matter which way it goes, advertising on the internet just gets that much more expensive.
Maybe he'll make enough money on this little scam to patent Flash.
Not entirely accurate. The patch has 4 modes of operation. Always-on and always-off, as well as "on unless the app says so" or "off unless the app says so" modes. The patch can easily be told not to step on any application's toes.
The average user doesn't need to think too much to realize the following simple facts:
For the same functionality:
That's the fallacy right there. The question is not one of "for the same functionality" but rather "all else being equal". You seem to consider the functionality to be the only important thing to maintain, but if that were the case there would be no reason to program in anything but assembly or machine language. Timeliness of delivery, ease of maintenance, and production cost are all at least as important as functionality. I would agree with you that all else equal, smaller and faster are better, but that's not the way reality works. There are always trade-offs and with hardware so cheap it's pretty obvious to even your average user that faster hardware is the way to go. I'm not condoning wastefulness, but features/hardware requirements isn't the only, and is by no means the most important metric by which to judge application software.
Uncompressed? No. The article claims 680,000 element CCD. Assuming 24-bit color, that's 3 bytes * 30fps * 680,000 elements = 58MB/sec = 3.5GB/min.
Compression is possible though. I don't know if there's any built-in compression, but a Crusoe/600 isn't going to provide much. With my AIW Radeon (original), I could just barely encode to MPEG2 with a Duron/600. With a 1.8GHz Athlon XP I can record straight to divx (from TV, 640x480) at about 1GB/hr, 60-80% CPU usage.
30G probably is a good match for the battery life of the unit, using whatever compression Sony built in. They, as a company, have better sense than to make something horribly mismatched like that. Chewing-gum memory slot excepted, of course.
For the love of Eris, would you grab a cluestick and shove it down your throat? How many distributions are there? Enough that you're complaining about the number? Enough to run on old hardware? Oh, so you really aren't complaining about that then? Good. I'm glad we settled that before it got out of hand. Know what a 1GHz system costs? Me neither; you pretty much can't get anything that slow anymore. Let's see. $50 for a motherboard. $50 for an Athlon XP1700. $50 for RAM. $50 for a PSU if you don't have an ATX power supply. Less than $200 will upgrade pretty much anything that's not a 486. Throw in a $75 videocard if you want to do gaming too.
"provide a spreadsheet of features and which e-mail clients have those features, as well as binary-sizes, RAM-sizes, and benchmarks of run-time performance, load-time; also, user ratings." Are you out of your mind? Benchmarks. Resident memory sizes. These are things the average user wants to spend time on, yeah. Sure. While we're at it, why don't we provide them in convenient gzipped source, so the user can configure them for the RAM size he or she wants?
Fine. You want to argue. That's nice. But pick a position and argue it; don't just pick random and conflicting things to say because they seem to contradict stuff in an article you clearly didn't understand.
You can always buy a comparable Intel part with integrated heatspreader / core protector for twice the price. Or you could buy an extra AMD chip to practice on. Or, my personal favorite: be careful putting the HSF on.
You have to be really careless to kill an Athlon. I've installed heatsinks dozens of times on Durons or Athlons, and haven't cracked a core yet. I've been progressively less careful as I've gotten more confident they're indestructable, but really this isn't a problem.
Test your CPU out with stock components. If it works, get a nicer HSF. If your chip dies a year after you bought it and AMD refuses to replace it because you used a nice Zalman heatsink, buy a new chip. Really. $50 will buy you what a year ago was a cutting-edge part. Take it as a blessing and move on.
Maybe I started playing Oregon Trail when I was too old, but all it taught me was to start with the character with the highest multiplier, and hunt a lot. You can sell about half a ton of food for $100, and end the game with thousands in cash - instant high scores. Definately a case where you have to be careful what you're trying to teach and what is being learned actually mesh!
That depends of course on your definition of "affordable".
Desktop applications won't benefit much at all from SSDs (with a 15,000RPM SCSI disk, my Athlon XP2200 is nearly always the bottleneck), so we're talking about business needs. Most businesses get along just fine with arrays of SCSI disks. Only a select few applications are random enough in their accesses throughout a large dataset that an SSD would benefit performance.
For home or small business use, SSDs won't ever catch on because they'll always be more expensive than mass storage for negligable visible gain. Any motherboard made in the past 2 years or so can easily handle 1.5G of RAM, and many will take more, but your average user has something like 128-256M. Part of the problem is braindead OSes which use the disk to cache RAM rather than the other way around, but even so most users clearly aren't willing to pay the price for the RAM, let alone the manufacturing, design, validation, etc. to make an SSD.
Plugging things in is annoying. I've got a palm pilot cradle, a UPS, and a null modem adapter for network switch testing / configuration all trying to share 2 serial ports. It's not always a pretty picture.
Wireless connectivity is a power drain, and there's no point if you have to plug the device in to charge. The only reasonable way to do this would be the combination wireless power / wireless connectivity I mentioned earlier. Apple is the only company with sufficient control of their sandbox to implement something like this, IMHO.
Bluetooth doesn't have to be fast; it only has to be simple. The iPod should retain the firewire connection it has now for sites w/o the charger/sync mat and for bulk data transfers. Bluetooth would be used for maintenance - that is, add a new CD or two to iTunes, and the next morning it shows up on your iPod. Even at 100K/sec (less than 20% Bluetooth's spec'd speed, IIRC), it would be trivial to keep up with 10-20% of the iPod's inventory changing every day.
We've gotten to the point where the vast majority of consumer electronics have all the power they need. Hopefully the end of that race will herald the begining of a race in terms of usability. People I know with cellphones tend to claim that sticking them in a charger every night isn't an imposition, but these are the same people whose phones die because they forgot to. If it were as simple as "empty your pockets on this table here" and all your gadgets would do the Right Thing(TM), I really think people would come running. I have better things to remember than backing up my laptop, syncing my palm pilot, moving new music onto an iPod, etc. If I'm not going to do it, then a computer has to, and wireless is the only way to accomplish that. The technology exists already; it's just waiting for someone to put it all together into an attractive package with the software to back it up and to sell enough to make it cheap. It's either Apple or Sony, and Sony's busy.
Slashdot Mirror
And if you're unemployed, you're even getting good value for the money!
What do you think all the demo chips AMD has been sending out for the last year or so ran on? Luck?
The 8000-series chipset has been around for ages. From AMD. And is implemented on dozens of different boards.
What kind of puns can you make with Rosen? Rosin? Resin? What fills her brain? See, not funny.
Now Bainwol is a name you can really sink your teeth into. I mean, it even sounds evil. And think of the jokes! Swap 'bain' for 'bane' and you're off and running.
When should we expect to hear about Netcraft being sued?
Obviously, netcraft is Blizzard's next hit, wherein the few remaining human loyalists valiantly defend their networks from the hordes of Zerg viruses. Those survey folks are just confusing people.
start|run|http://www.cygwin.com
download / install cygwin
$ find . -type f | xargs md5sum
10-minute job.
Ok. Have to remember, in reading future BSA press releases that
"It is welcoming news to learn that the worldwide software piracy problem has improved significantly..."
and
"However, it's critical to recognise that the industry is facing a spiralling Internet piracy problem."
are not mutually exclusive statements. I wonder if that trick would work in board meetings. "Cost projections have improved significantly" sure sounds a lot better than "Costs are spiralling out of control"!
So *that*'s what the blank spaces in that page were supposed to be...
Regrettably, the "here's an HTML version" link doesn't seem to work - 404. Anyone else?
Is that what I have? So "standalone installation" is Microsoft code for "Well, we'll let you delete it (it goes in the recycle bin and all) but it instantly comes back"?
If WinXP wants to protect its help system, that's fine. But the IE frontend shouldn't have anything to do with that. And even so, there's no excuse for Outlook being undeletable. It doesn't show up in the Add/Remove applications window, even under "Windows components"
I have never seen a business model that treats their customers so badly.
Been to an airport recently?
Harder to copy? Harder than what? You stick it in the drive and hit "copy all files" and presto (10 minutes later), there it is. With all the .ifo files and everything intact. PowerDVD and WinDVD happily play DVD file structures from a hard drive, and should that fail the .vob files are playable by themselves.
An average DVD is around 5-6GB, which at current disk prices costs about $5. Add to that a $2 rental fee, and you've got yourself a half-price DVD (or third, depending). With a bit more effort and a lot more CPU time you can mpeg4 (Divx, Xvid, etc.) encode the main video and cut that $7 in half again, or you can buy a VHS tape and record it to that (but why would you want to?).
Copying DVDs (at least, for personal use) is just as easy as copying CDs: insert, click, wait, eject.
Distribution of movies is harder though because of the size, I'll grant you that. There are 9.4G recordable DVDs, but the lack of a single standard has dramatically slowed adoption of the technology, and with prices what they are, it's cheaper to put things on hard drives and trade them that way.
You can build a pretty nice computer for $500. A good motherboard + XP2000 + 512M RAM + 80G HDD + nice case/PSU comes out under the $500 mark. Just add monitor and keyboard.
Your average computer user needs far less in terms of hardware, and even a geek could hold his head up with a $500 computer these days. It's getting harder and harder to justify spending much more, except on peripherals.
But since I don't play games under Linux, the question's moot. In fact, I have two Redhat machines here and one *BSD machine, none of which even have X installed.
Samba, dhcpd, apache, squid, and the rest don't run any better with X installed, so why bother?
I also don't game much under Windows, so I'm asking out of ignorance rather than malice whether there are enough recent Linux games to justify the hassle. Is linux a reasonable alternative gaming platform to Windows?
Suppose your gateway, rather than forwarding requests, actually creates a new IP packet. Does that mean only one machine is "accessing" your connection?
What if you download a movie onto the net-connected box and then SCP it to another machine. Is that other machine accessing the connection? If not, what delay must exist between data arriving at the gateway and arriving at the eventual destination in order for it not to count as access? A NAT or proxy box basically fetches things on behalf of a different machine. Downloading a movie on the box with the DSL connection and then moving it to a different machine is the same, except it's being done manually.
Anyway, those are my ramblings having not read the article yet.
Example: Seagate 15krpm drive: average seek time 3.6ms. You are correct that the *average* rotational latency will be 2ms, since the full rotational latency is 4ms. However, 2ms out of 3.6ms is more than half, meaning rotational latency dominates (even though you were right about the average rotational latency being important, not the full rotational latency).
Seek time is 3.6ms. Access time is 5.6ms. The seek time is the time it takes for the heads to seek to the proper location. This is followed by (correct, an average of) 2ms of rotational latency, for a total (again, average) 5.6ms access time.
I don't know why you think that seek time on large drives is of no importance...
Because for the majority of users, it is.
You're correct that large files can be fragmented, but the fact is that most users' large files (movies, audio, etc.) are never edited, meaning no excess fragments are created. Then the only source of fragmentation is deletions, which produces relatively little fragmentation. Your million files in 100G is still 100K/file, rather larger than my boot drive (which I assume for lack of further evidence to be "normal").
Taking the time to check fragments, I have 13602 fragments in 90G (~6.6M/fragment) for data and 112594 fragments in 5.75G (~50K/fragment) for boot/apps. The ratio is still about the same.
As for concurrent reads, this is a problem of firmware optimization. Two applications making full-out reads of two separate files should be served by firmware in the following manner: the drive reads a buffer-full of one file and then seeks to the other. In an STR-bound application like this, the drive seeks as little as possible. In a situation where applications are making repeated small (but sequential) reads, the firmware should seek to maintain a buffer half-full of one file and half-full of the other, performing read-ahead caching to allow bits of each file to be sent to the host with a minimum of seeking on the drive's part.
There are few circumstances where firmware optimization cannot mask seek performance, and these typically involve small datasets or are not suitable for large drives for other reasons.
You've got some problems with your facts. But, since you're playing the math games that I like to play, I'll cut you some slack. And then I'll expound.
First off, disk access time is dominated by actuator movement (seek time). Rotational latency on a 15,000rpm disk is 2ms, not 4. The fastest 15K drives have 3.5-4ms seek time. Slower drives have slower actuators, meaning the ratio of seek time to rotational latency is about the same, 2:1.
Seek time on large drives is of no importance. Seek time on small drives is of supreme importance. Small drives should be used to store the OS, applications, and small data files. Rapid access to disparate regions of the disk is important since these drives are primarily limited by IO/sec. Large drives are used for mass data storage. Large data storage (media, in my case) is dominated naturally enough by large files whereas applications and user data tend to be tiny. My media drive, for example has about 11,000 files in 95GB, or about 110 seeks/GB. My OS/apps drive, on the other hand, has over 89,000 files in 5.75GB, or 16000 seeks/GB.
Consider that a high-end drive can handle perhaps 600 IO/sec, and a large IDE drive can handle perhaps 150. Clearly then we have a problem: usage patterns differing by 150:1 in terms of number of seeks are not matched well to drives differing by 4:1 in seek performance. As you've demonstrated, physics cannot allow us to increase SCSI's seek performance to 150X that of bulk IDE drives.
The only way to achieve that sort of performance is with solid state storage. RAM costs about $150/GB - let's see someone mass-produce consumer-grade SSDs. Call it the "drive accelerator" and build it into a removable HDD bay. I guarantee that 1GB of RAM caching the most-used files on a hard drive would see performance skyrocket. Sure, it would be expensive, but it would be cheaper than the 15k SCSI boot disk I have, and a whole lot faster.
They grant this guy a patent. Then he starts suing people. They either pay up, in which case he has more money to pursue patents, or they refuse and the money that would be spent crafting more intrusive advertising gets wasted on lawyers instead. No matter which way it goes, advertising on the internet just gets that much more expensive.
Maybe he'll make enough money on this little scam to patent Flash.
Not entirely accurate. The patch has 4 modes of operation. Always-on and always-off, as well as "on unless the app says so" or "off unless the app says so" modes. The patch can easily be told not to step on any application's toes.
begin
I'm not surprised IE can't render HTML.
The average user doesn't need to think too much to realize the following simple facts:
For the same functionality:
That's the fallacy right there. The question is not one of "for the same functionality" but rather "all else being equal". You seem to consider the functionality to be the only important thing to maintain, but if that were the case there would be no reason to program in anything but assembly or machine language. Timeliness of delivery, ease of maintenance, and production cost are all at least as important as functionality. I would agree with you that all else equal, smaller and faster are better, but that's not the way reality works. There are always trade-offs and with hardware so cheap it's pretty obvious to even your average user that faster hardware is the way to go. I'm not condoning wastefulness, but features/hardware requirements isn't the only, and is by no means the most important metric by which to judge application software.
Uncompressed? No. The article claims 680,000 element CCD. Assuming 24-bit color, that's 3 bytes * 30fps * 680,000 elements = 58MB/sec = 3.5GB/min.
Compression is possible though. I don't know if there's any built-in compression, but a Crusoe/600 isn't going to provide much. With my AIW Radeon (original), I could just barely encode to MPEG2 with a Duron/600. With a 1.8GHz Athlon XP I can record straight to divx (from TV, 640x480) at about 1GB/hr, 60-80% CPU usage.
30G probably is a good match for the battery life of the unit, using whatever compression Sony built in. They, as a company, have better sense than to make something horribly mismatched like that. Chewing-gum memory slot excepted, of course.
For the love of Eris, would you grab a cluestick and shove it down your throat? How many distributions are there? Enough that you're complaining about the number? Enough to run on old hardware? Oh, so you really aren't complaining about that then? Good. I'm glad we settled that before it got out of hand. Know what a 1GHz system costs? Me neither; you pretty much can't get anything that slow anymore. Let's see. $50 for a motherboard. $50 for an Athlon XP1700. $50 for RAM. $50 for a PSU if you don't have an ATX power supply. Less than $200 will upgrade pretty much anything that's not a 486. Throw in a $75 videocard if you want to do gaming too.
"provide a spreadsheet of features and which e-mail clients have those features, as well as binary-sizes, RAM-sizes, and benchmarks of run-time performance, load-time; also, user ratings."
Are you out of your mind? Benchmarks. Resident memory sizes. These are things the average user wants to spend time on, yeah. Sure. While we're at it, why don't we provide them in convenient gzipped source, so the user can configure them for the RAM size he or she wants?
Fine. You want to argue. That's nice. But pick a position and argue it; don't just pick random and conflicting things to say because they seem to contradict stuff in an article you clearly didn't understand.
You can always buy a comparable Intel part with integrated heatspreader / core protector for twice the price. Or you could buy an extra AMD chip to practice on. Or, my personal favorite: be careful putting the HSF on.
You have to be really careless to kill an Athlon. I've installed heatsinks dozens of times on Durons or Athlons, and haven't cracked a core yet. I've been progressively less careful as I've gotten more confident they're indestructable, but really this isn't a problem.
Test your CPU out with stock components. If it works, get a nicer HSF. If your chip dies a year after you bought it and AMD refuses to replace it because you used a nice Zalman heatsink, buy a new chip. Really. $50 will buy you what a year ago was a cutting-edge part. Take it as a blessing and move on.
Maybe I started playing Oregon Trail when I was too old, but all it taught me was to start with the character with the highest multiplier, and hunt a lot. You can sell about half a ton of food for $100, and end the game with thousands in cash - instant high scores. Definately a case where you have to be careful what you're trying to teach and what is being learned actually mesh!
That depends of course on your definition of "affordable".
Desktop applications won't benefit much at all from SSDs (with a 15,000RPM SCSI disk, my Athlon XP2200 is nearly always the bottleneck), so we're talking about business needs. Most businesses get along just fine with arrays of SCSI disks. Only a select few applications are random enough in their accesses throughout a large dataset that an SSD would benefit performance.
For home or small business use, SSDs won't ever catch on because they'll always be more expensive than mass storage for negligable visible gain. Any motherboard made in the past 2 years or so can easily handle 1.5G of RAM, and many will take more, but your average user has something like 128-256M. Part of the problem is braindead OSes which use the disk to cache RAM rather than the other way around, but even so most users clearly aren't willing to pay the price for the RAM, let alone the manufacturing, design, validation, etc. to make an SSD.
Plugging things in is annoying. I've got a palm pilot cradle, a UPS, and a null modem adapter for network switch testing / configuration all trying to share 2 serial ports. It's not always a pretty picture.
Wireless connectivity is a power drain, and there's no point if you have to plug the device in to charge. The only reasonable way to do this would be the combination wireless power / wireless connectivity I mentioned earlier. Apple is the only company with sufficient control of their sandbox to implement something like this, IMHO.
Bluetooth doesn't have to be fast; it only has to be simple. The iPod should retain the firewire connection it has now for sites w/o the charger/sync mat and for bulk data transfers. Bluetooth would be used for maintenance - that is, add a new CD or two to iTunes, and the next morning it shows up on your iPod. Even at 100K/sec (less than 20% Bluetooth's spec'd speed, IIRC), it would be trivial to keep up with 10-20% of the iPod's inventory changing every day.
We've gotten to the point where the vast majority of consumer electronics have all the power they need. Hopefully the end of that race will herald the begining of a race in terms of usability. People I know with cellphones tend to claim that sticking them in a charger every night isn't an imposition, but these are the same people whose phones die because they forgot to. If it were as simple as "empty your pockets on this table here" and all your gadgets would do the Right Thing(TM), I really think people would come running. I have better things to remember than backing up my laptop, syncing my palm pilot, moving new music onto an iPod, etc. If I'm not going to do it, then a computer has to, and wireless is the only way to accomplish that. The technology exists already; it's just waiting for someone to put it all together into an attractive package with the software to back it up and to sell enough to make it cheap. It's either Apple or Sony, and Sony's busy.