Yeah. Actually what I was getting at is, this new version of JavaScript is preferable. I have nothing against Java. However, Microsoft wants 1) total domination of IE, 2) total domination of.NET, and this is a reasonable (and arguably straightforward) way of achieving this. And the scary thing is, from a technology point of view, it makes great sense.
Microsoft wants a new language for client-side scripts. Just-so-coincidentally, Microsoft has this new "language" ready to go for us. It's called.NET and the CLR.
C#, VB.NET, J#. Whatever. Microsoft wants a.NET runtime in the browser. Probably a sandboxed one that can only access the DOM and browser. But you still get all the.NET benefits, like multithreading and bytecode compilation. And all the.NET drawbacks, like you can't implement it outside of IE because it's patented from here to hell and back.
Zodiac, whilst perhaps not as good a novel, would make for a far better screen translation than Snow Crash.
+1 to that.
Zodiac is probably the best Neal Stephenson novel for translation into film. It's got everything Hollywood needs - helicopters, guns, explosions, sex, biological terrorism, an asshole protagonist, and sweeping views of Boston Harbor. Plus it's around the right scope (read: it's short and simple enough) for a 90-minute film.
As a yardstick as to how much effort you need to maintain the code part of a port: Blizzard has four (4) Mac developers on staff, and they're split amongst World of Warcraft and Other Secret Blizzard Stuff. (Of course, they're probably the four greatest Mac developers out there. And it's not counting QA, support, etc.) Source
First of all, yes, S/PDIF can be externally clocked. If it couldn't, I'd have to trust by Behringer V-Amp Pro to provide clocking for my whole studio since it has only outputs and no (non-clock) inputs. *shiver* I like being able to operate at something other than 44.1 kHz....
I wasn't referring originally to externally clocked S/PDIF or any other magical digital transports; just plain coaxial versus optical and the differing characteristics thereof. I thought I covered my ass sufficiently with talk of reclocking but people will just pick on any minor details I missed.
Second, the bit clocks are irrelevant to the audio generation process. The DAC doesn't get updated a bit at a time. The bits get shoved into a latch and pushed to the DAC one entire sample at a time. That means that variations in bit timing don't matter except when they throw things off far enough to cause the derived sample clock to be skewed. I'd be very surprised if this timing skew were enough to be audible, as half a percent of 44.1 kHz would, I believe, result in a false "signal" in the 8 MHz range and humans can't hear those frequencies.
It wouldn't just result in a false signal; the energy from it has to come from somewhere. In this case, I suspect it'd come from right in the audio band. (Ain't DSP grand.)
The problems are largely the same, and have pretty much been solved by computer science. (Otherwise, computers just wouldn't be possible.)
Well, let's remember what the context is. We're talking 2 pieces of audio equipment (sender and receiver), separated by a single fibre-optic line, with all its drawbacks - reflections, the speed of light, cheap LEDs, etc. Everything's gotta happen on that line. It's not like a single-chip (or single-whatever) solution where you can just move things around or draw more electrical connections to sync the clocks, or whatever.
The solutions we have are good - this is no less a solved problem than in a computer hardware perspective. The only "problem" is that, from an audiophile perspective, it ain't perfect.
now is S/PDIF has some retarded unbuffered implementation which allows bit errors due to slight timing differences that has nothing to do with digital and everything to do with retarded implementation
getting a bitstream from one place to another undamaged is a problem that has been solved for a long time, now any work on such subjects is either doing it cheaper or doing it faster.
Oh yes, no doubt about this one.
But let's remember the context here. The original poster made a point that "old audio nuts" could hear a difference between two digital transports, without considering that the real-world implementation could account for that difference. That's what I was addressing.
Dude the ears of old audio nuts claim that DIGITAL data sounds different when sent through fiber optic digital links rather than other digital links.
Digital ain't digital.
There are two main transports for S/PDIF digital data: optical (pulses of light) and coaxial (electric signals). The internal circuitry of your audio player is electric signals, so when your transport is optical, you've got to translate between electrons and light, then back again at the other end.
Ah, but it's all digital, right? The problem is timing: although you think that your light is instantly either on or off, in reality it takes time to switch on and off. So the receiver has to "guess" when the transition to 1 or 0 is complete. These guesses mean that you get jitter: your data doesn't come at a perfectly constant rate, there's a few % difference in each "beat".
But we can assume that it's coming at 44,100Hz, and eliminate the jitter that way, right? Well, not really. Unless both sender and receiver use the same clock (which I don't think S/PDIF allows for), you're going to have two different clocks. The thing about clocks is, they're not all the same. Your source and receiver both claim that they run at 44,100Hz. But one could be running at 44,102Hz and the other at 43,999Hz. This means you can't "reclock" your incoming data in an easy way. (There are more elaborate solutions.)
So. We get jitter. Certainly it can be detected by metering equipment. But can anyone actually hear it? That's the big question...
It's called artistic licence, people. You know, the type of thing that gets ordinary people to gape in wonder at the beauty of the solar system, etc. etc. They could call it the "Peak of Eternal Light Except During Lunar Eclipses Where It Only Gets Refracted Sunlight, Also It's Not Really Eternal as the Sun Will Go Nova in 5 Billion Years". Or the "Peak That's a Good Place For Solar Collectors". And nobody would care.
NASA and ESA are trying to get people interested in this, not recruit engineers. (Unless they're artistic engineers.)
Want to cut gas consumption in half? Start by clearing up the traffic people sit in every day. There, billions saved. It's a start.
Want to cut gas consumption in half? Put two people in your car instead of one. That will clear up traffic queues, which as above, will probably cut gas consumption in half again...
And yes, many readers already do this, good stuff. But next time you're stuck in traffic, look at all the cars around you, and imagine if all the cars with one person were carrying two instead, and those with two were carrying three.
In this case, Capital 10 stepped over the line and was enabling children to view filthy content via the Internet. The dominant audience for Big Brother is the 12-14 year old teen market. Do you think it's appropriate for young teens to see a bunch of dimwitted Big Brother contestants teabagging a female contestant who was being held down against her will? I don't.
If your 12-14 year old kids are watching live Internet streaming at 4:30 a.m. (which, for everyone else, is the time that this was streamed), you have worse things to worry about.
Don't get me wrong, I totally understand what you are saying about the x-height and how it makes text more readable, but the thing about the web is that you can't know that the reader is actually using that font. Sure, you can suggest Verdana, but if they don't have it on their system, or they prefer another font, the x-height you assume to be in use usually ends up being much smaller.
In this case, you want the CSS2 property called font-size-adjust, which reads the x-height of the user's font, and scales it up to the x-height that you want. Illustrated example available on the linked page.
Of course, this isn't a bulletproof solution, not least because Internet Explorer 6.0 doesn't support it...
It's not a technical thing. It's a licensing thing. The porting house needs to secure all the licenses for the game and the middleware. Then probably draw up more contracts still. Then secure the code and art assets. Most of the time, this doesn't happen until the PC version ships... some of the time, not for a few months after that. It's good ol' American corporate paranoia.
Porting probably isn't the type of activity that you can throw more programmers at... TFA says that they have 5 porters, and that's probably all they need. As with the saying, nine women can't have a baby in one month. Aspyr (the company mentioned in the article) already has a pretty good in-house DirectX-to-OpenGL conversion layer, probably better than any commercial offering. Not that it's perfect, but that part of the equation is arguably "solved".
And with the profits... you're looking at maybe 5% of the profits of the PC version. Let's say we do something amazing and double it! Now it's 10%. Your "suits" probably wouldn't care.
That's something I've been wondering for years. Not having the knowledge neccessary I still ask: What is the reason anyone and their mother can't set up a multicast audio/video stream?
I see a lot of complicated answers to this one. So let me try for a simple one.
The simple answer is, every router between you and your users has to be enabled for multicast. If a single one isn't, it doesn't work.
.. in this post they reported on a project supposedly aiming at breaking down single threads into multiple threads so as to better utilize core utilization beyond the fourth core.
In the Eiffel programming language, they've proposed a concurrency algorithm that doesn't use "traditional" threads.
The idea is, you sprinkle the "separate" keyword onto various objects that it makes sense for. The compiler or runtime then does a dependency analysis and breaks out your program into different threads or processes. Automatically. As many different threads as is optimal for your system.
That's it. No locking, no threading, no synchronisation. Just the one damn keyword.
OK, so the above is a simplification. But it's not a huge one. You can read up on it at the Eiffel site or in your local copy of OOSC.
The "problem" is, Eiffel is already a niche language, and this is even more niche. In fact, I don't think anyone's even implemented this concurrency scheme in production code. Also, from what I've read, it's formally proven to work, but this was some time ago so someone might have poked (theoretical or practical) holes in the scheme.
People will always find something to complain about.
1. Someone finds a way to boot a totally new environment on a Mac, allowing people to run applications they couldn't otherwise. Although this is an amazing technical achievement, people complain that you have to dual-boot.
2. Someone finds a way to avoid dual-booting by getting that totally new environment at the same time as the Mac (e.g. virtualisation). People complain that they have to keep switching between the two, and it would be better to integrate the two environments, for example, having the windows from both environments sharing the same desktop.
3. Someone finds a way to integrate the two environments. People complain that the totally new environment isn't "Mac-like" enough, although by definition it can't be. Short of porting things to Mac OS X (defeating the purpose of this), it's an intractable problem.
With Windows XP, we're up to stage 1 - dual booting.
With X11, we're up to stage 3. Stage 1 was dual booting into a Linux environment; stage 2 was XDarwin; stage 3 is Apple's current X11 and window manager. but instead of basking in the glow that is thousands of cool free software apps, people complain that things like OpenOffice.org or Evolution or GAIM, running in X11, is terrible and un-Mac-like. (That's a generalisation; I'm not saying that you're complaining.)
All those complaints about Apple not providing a virtualisation solution, are just complaining that we're not yet at stage 2. Once Apple provides that, those people may be satisfied; but a whole different group of people will start complaining that we're not at stage 3. And once we get there, yet another group of people will complain that we are at stage 3.
Of course, this is all worthwhile; I'm not saying otherwise. In fact, I'm hugely grateful just to get stage 1. But no matter what you do, people will always find something to complain about. (Hmm, that's nowhere as insightful as I thought it was.)
If you want a small phone, have a look at the Panasonic A100. Now that's a small phone - so small that you wonder how it's usable. You can probably get even smaller phones, but this one's been reasonably well-distributed, at least in my part of the world.
A lot of people have just read through a dozen screenfuls or more of Slashdot commentary to get to this comment. For most of us, it's not a problem, reading - or at least skimming - large amounts of text on a computer screen.
Nobody complains that you can't read Slashdot in the bath, or in bed, or on the beach. Nobody complains that the screen isn't natural or like paper, or it gives them headaches. Nobody complains that Slashdot-reading devices can't be put on a bookshelf, or dropped off a table.
Yet people make these complaints about e-books.
I think that, in some sense, comparing e-books with traditional books is unfair. Like comparing recorded music with live music. E-books don't have to replace traditional books. I read a lot of both. The trick is to play to their strengths.
For example, an e-book can be searched really quickly. Faster than skimming through a paper book. I come across some person or event that's been referenced before, but I can't remember quite where... the search button lets me know.
Something I'd never admit to doing: it's easier to read an e-book whilst slacking off at work. It looks like just another window on your screen. Much more discreet than reading a paperback. Nobody reading Slashdot from work will be able to identify with this...
As with online music, there's the instant gratification factor. No waiting around or having to drive to the store, you see something, a few clicks and it's ready to read. I like that. With DRM, I've found that for e-books, the norm is DRM that's much less restrictive than music. Generally, the "key" for your e-book is your credit card number, so you can copy your e-books to as many devices as you're willing to give out that key for. And there's a lot of e-book providers who go DRM-free.
And as with iPods, there's the hundreds-of-books-in-my-pocket factor.
Anyway, yeah. There are a lot of drawbacks to e-books (well-documented in this thread) which mean that paper books will never go away. But you have to say, they've got some strengths too. People are asking, why should I read e-books? My answer: because they fill a valuable niche. You've just got to take advantage of it.
But, neither matter anyway.. Apple does not expose an open API to use the video acceleration capabilities in GPU hardware. Only their DVD player can use it. So, all video decoding is done on the CPU -- which makes the new Mini a big improvement with a faster CPU & optional dual core.
It's worth mentioning: there is a project called Accellent, to reverse-engineer Apple's GPU acceleration APIs and make it available as open source. Some folks on the MythTV project are also working on integrating it into the frontend, I think.
Whether it'll work with the Intel graphics chipset is an open question.
Make the same device to both functions, and guess what your biggest problem is going to be.
That people will listen to MP3s and run the battery down to zero, rather than stop listening to MP3s when they notice that the battery is low, so they can continue to receive calls.
In other words, the problem is that people are stupid.
Say I can come up with a 2048 bit encryption, that is just increase the key size from 256 to 2048, I can to that in a second. It is going to take _a lot more time_
Obligatory quote from Bruce Schneier, referenced from this Slashdot post, which referenced this web site, which referenced Schneier's Applied Cryptography:
in regards to the strength of 256-bit encryption:
now, the annual energy output of our sun is about 121 * 10^41 ergs. this is enough to power about 2.7 * 10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. if we build a dyson sphere around the sun and captured all of its energy output for 32 years, without any loss, we should power a computer to count up to 2 ^ 192. of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
but that's just one star, and a measly one at that. a typical supernova releases something like 10^51 ergs. (about a hundred times as much energy would be released in the form of neutrinos, but i let them go for now.) if all this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
these numbers have nothing to do with the technology of the devices; they are the maximum that thermodynamics will allow. and they strongly imply that brute-force attracks against 256-bit keys will be infeasable until computers are built from something other than matter and occupy something other than space.
bruce schneier, applied cryptography, p 158
(Note that he's talking about symmetric ciphers, like DES - not public key ciphers, like RSA. But you get the idea.)
Um, why? Are you saying there is some massive unmet demand for penguins in our universe? People have cash burning a hole in their pocket, wanting to be spent on penguins, but, alas, no supplier exists? 'Cause that's the only way Linus in the alternative universe would drain off lots of cash that remains in consumers' hands in this universe.
I am not saying anything about our universe.
I am presenting a hypothetical parallel universe. Just like you did. It's another what-if scenario. It doesn't have any reason. It doesn't need to. It's hypothetical. People in that universe have a massive unmet demand for penguins. If we accept that, then what consequences does it cause?
Anyway, I don't really follow your line of reasoning. Not sure what it is you're trying to say.
I'm saying this: Your original post postulated a hypothesis which I thought had bias in a certain direction. So I postulated an opposing hypothesis to contrast it, to expose this bias. (I am not saying that the bias is bad, or even that it had bias. Only that I thought it did.)
The intention was not to make an economic argument, rather a logical one.
Slashdot Mirror
(This in contrast to the fast talking "green" showman whose mansion burned 20x the national average.)
http://www.snopes.com/politics/business/gorehome.asp
Yeah. Actually what I was getting at is, this new version of JavaScript is preferable. I have nothing against Java. However, Microsoft wants 1) total domination of IE, 2) total domination of .NET, and this is a reasonable (and arguably straightforward) way of achieving this. And the scary thing is, from a technology point of view, it makes great sense.
I can't believe that nobody's pointed this out.
.NET and the CLR.
.NET runtime in the browser. Probably a sandboxed one that can only access the DOM and browser. But you still get all the .NET benefits, like multithreading and bytecode compilation. And all the .NET drawbacks, like you can't implement it outside of IE because it's patented from here to hell and back.
Microsoft wants a new language for client-side scripts. Just-so-coincidentally, Microsoft has this new "language" ready to go for us. It's called
C#, VB.NET, J#. Whatever. Microsoft wants a
See Silverlight? That's the tip of the iceberg.
Open your eyes, people. This is Microsoft.
Here's an obligatory post that we can point and laugh at, 5 years later!
No phone. Less capability than a sub-notebook. Lame.
+1 to that.
Zodiac is probably the best Neal Stephenson novel for translation into film. It's got everything Hollywood needs - helicopters, guns, explosions, sex, biological terrorism, an asshole protagonist, and sweeping views of Boston Harbor. Plus it's around the right scope (read: it's short and simple enough) for a 90-minute film.
As a yardstick as to how much effort you need to maintain the code part of a port: Blizzard has four (4) Mac developers on staff, and they're split amongst World of Warcraft and Other Secret Blizzard Stuff. (Of course, they're probably the four greatest Mac developers out there. And it's not counting QA, support, etc.) Source
I wasn't referring originally to externally clocked S/PDIF or any other magical digital transports; just plain coaxial versus optical and the differing characteristics thereof. I thought I covered my ass sufficiently with talk of reclocking but people will just pick on any minor details I missed.
It wouldn't just result in a false signal; the energy from it has to come from somewhere. In this case, I suspect it'd come from right in the audio band. (Ain't DSP grand.)
Well, let's remember what the context is. We're talking 2 pieces of audio equipment (sender and receiver), separated by a single fibre-optic line, with all its drawbacks - reflections, the speed of light, cheap LEDs, etc. Everything's gotta happen on that line. It's not like a single-chip (or single-whatever) solution where you can just move things around or draw more electrical connections to sync the clocks, or whatever.
The solutions we have are good - this is no less a solved problem than in a computer hardware perspective. The only "problem" is that, from an audiophile perspective, it ain't perfect.
Oh yes, no doubt about this one.
But let's remember the context here. The original poster made a point that "old audio nuts" could hear a difference between two digital transports, without considering that the real-world implementation could account for that difference. That's what I was addressing.
Digital ain't digital.
There are two main transports for S/PDIF digital data: optical (pulses of light) and coaxial (electric signals). The internal circuitry of your audio player is electric signals, so when your transport is optical, you've got to translate between electrons and light, then back again at the other end.
Ah, but it's all digital, right? The problem is timing: although you think that your light is instantly either on or off, in reality it takes time to switch on and off. So the receiver has to "guess" when the transition to 1 or 0 is complete. These guesses mean that you get jitter: your data doesn't come at a perfectly constant rate, there's a few % difference in each "beat".
But we can assume that it's coming at 44,100Hz, and eliminate the jitter that way, right? Well, not really. Unless both sender and receiver use the same clock (which I don't think S/PDIF allows for), you're going to have two different clocks. The thing about clocks is, they're not all the same. Your source and receiver both claim that they run at 44,100Hz. But one could be running at 44,102Hz and the other at 43,999Hz. This means you can't "reclock" your incoming data in an easy way. (There are more elaborate solutions.)
So. We get jitter. Certainly it can be detected by metering equipment. But can anyone actually hear it? That's the big question...
It's called artistic licence, people. You know, the type of thing that gets ordinary people to gape in wonder at the beauty of the solar system, etc. etc. They could call it the "Peak of Eternal Light Except During Lunar Eclipses Where It Only Gets Refracted Sunlight, Also It's Not Really Eternal as the Sun Will Go Nova in 5 Billion Years". Or the "Peak That's a Good Place For Solar Collectors". And nobody would care.
NASA and ESA are trying to get people interested in this, not recruit engineers. (Unless they're artistic engineers.)
Want to cut gas consumption in half? Put two people in your car instead of one. That will clear up traffic queues, which as above, will probably cut gas consumption in half again...
And yes, many readers already do this, good stuff. But next time you're stuck in traffic, look at all the cars around you, and imagine if all the cars with one person were carrying two instead, and those with two were carrying three.
If your 12-14 year old kids are watching live Internet streaming at 4:30 a.m. (which, for everyone else, is the time that this was streamed), you have worse things to worry about.
Of course, this isn't a bulletproof solution, not least because Internet Explorer 6.0 doesn't support it...
But the CSS folks have considered this problem.
It's not a technical thing. It's a licensing thing. The porting house needs to secure all the licenses for the game and the middleware. Then probably draw up more contracts still. Then secure the code and art assets. Most of the time, this doesn't happen until the PC version ships... some of the time, not for a few months after that. It's good ol' American corporate paranoia.
Porting probably isn't the type of activity that you can throw more programmers at... TFA says that they have 5 porters, and that's probably all they need. As with the saying, nine women can't have a baby in one month. Aspyr (the company mentioned in the article) already has a pretty good in-house DirectX-to-OpenGL conversion layer, probably better than any commercial offering. Not that it's perfect, but that part of the equation is arguably "solved".
And with the profits... you're looking at maybe 5% of the profits of the PC version. Let's say we do something amazing and double it! Now it's 10%. Your "suits" probably wouldn't care.
That's something I've been wondering for years. Not having the knowledge neccessary I still ask: What is the reason anyone and their mother can't set up a multicast audio/video stream?
I see a lot of complicated answers to this one. So let me try for a simple one.
The simple answer is, every router between you and your users has to be enabled for multicast. If a single one isn't, it doesn't work.
.. in this post they reported on a project supposedly aiming at breaking down single threads into multiple threads so as to better utilize core utilization beyond the fourth core.
In the Eiffel programming language, they've proposed a concurrency algorithm that doesn't use "traditional" threads.
The idea is, you sprinkle the "separate" keyword onto various objects that it makes sense for. The compiler or runtime then does a dependency analysis and breaks out your program into different threads or processes. Automatically. As many different threads as is optimal for your system.
That's it. No locking, no threading, no synchronisation. Just the one damn keyword.
OK, so the above is a simplification. But it's not a huge one. You can read up on it at the Eiffel site or in your local copy of OOSC.
The "problem" is, Eiffel is already a niche language, and this is even more niche. In fact, I don't think anyone's even implemented this concurrency scheme in production code. Also, from what I've read, it's formally proven to work, but this was some time ago so someone might have poked (theoretical or practical) holes in the scheme.
People will always find something to complain about.
1. Someone finds a way to boot a totally new environment on a Mac, allowing people to run applications they couldn't otherwise. Although this is an amazing technical achievement, people complain that you have to dual-boot.
2. Someone finds a way to avoid dual-booting by getting that totally new environment at the same time as the Mac (e.g. virtualisation). People complain that they have to keep switching between the two, and it would be better to integrate the two environments, for example, having the windows from both environments sharing the same desktop.
3. Someone finds a way to integrate the two environments. People complain that the totally new environment isn't "Mac-like" enough, although by definition it can't be. Short of porting things to Mac OS X (defeating the purpose of this), it's an intractable problem.
With Windows XP, we're up to stage 1 - dual booting.
With X11, we're up to stage 3. Stage 1 was dual booting into a Linux environment; stage 2 was XDarwin; stage 3 is Apple's current X11 and window manager. but instead of basking in the glow that is thousands of cool free software apps, people complain that things like OpenOffice.org or Evolution or GAIM, running in X11, is terrible and un-Mac-like. (That's a generalisation; I'm not saying that you're complaining.)
All those complaints about Apple not providing a virtualisation solution, are just complaining that we're not yet at stage 2. Once Apple provides that, those people may be satisfied; but a whole different group of people will start complaining that we're not at stage 3. And once we get there, yet another group of people will complain that we are at stage 3.
Of course, this is all worthwhile; I'm not saying otherwise. In fact, I'm hugely grateful just to get stage 1. But no matter what you do, people will always find something to complain about. (Hmm, that's nowhere as insightful as I thought it was.)
If you want a small phone, have a look at the Panasonic A100. Now that's a small phone - so small that you wonder how it's usable. You can probably get even smaller phones, but this one's been reasonably well-distributed, at least in my part of the world.
(Yeah, that's an inflammatory title.)
A lot of people have just read through a dozen screenfuls or more of Slashdot commentary to get to this comment. For most of us, it's not a problem, reading - or at least skimming - large amounts of text on a computer screen.
Nobody complains that you can't read Slashdot in the bath, or in bed, or on the beach. Nobody complains that the screen isn't natural or like paper, or it gives them headaches. Nobody complains that Slashdot-reading devices can't be put on a bookshelf, or dropped off a table.
Yet people make these complaints about e-books.
I think that, in some sense, comparing e-books with traditional books is unfair. Like comparing recorded music with live music. E-books don't have to replace traditional books. I read a lot of both. The trick is to play to their strengths.
For example, an e-book can be searched really quickly. Faster than skimming through a paper book. I come across some person or event that's been referenced before, but I can't remember quite where... the search button lets me know.
Something I'd never admit to doing: it's easier to read an e-book whilst slacking off at work. It looks like just another window on your screen. Much more discreet than reading a paperback. Nobody reading Slashdot from work will be able to identify with this...
As with online music, there's the instant gratification factor. No waiting around or having to drive to the store, you see something, a few clicks and it's ready to read. I like that. With DRM, I've found that for e-books, the norm is DRM that's much less restrictive than music. Generally, the "key" for your e-book is your credit card number, so you can copy your e-books to as many devices as you're willing to give out that key for. And there's a lot of e-book providers who go DRM-free.
And as with iPods, there's the hundreds-of-books-in-my-pocket factor.
Anyway, yeah. There are a lot of drawbacks to e-books (well-documented in this thread) which mean that paper books will never go away. But you have to say, they've got some strengths too. People are asking, why should I read e-books? My answer: because they fill a valuable niche. You've just got to take advantage of it.
But, neither matter anyway.. Apple does not expose an open API to use the video acceleration capabilities in GPU hardware. Only their DVD player can use it. So, all video decoding is done on the CPU -- which makes the new Mini a big improvement with a faster CPU & optional dual core.
It's worth mentioning: there is a project called Accellent, to reverse-engineer Apple's GPU acceleration APIs and make it available as open source. Some folks on the MythTV project are also working on integrating it into the frontend, I think.
Whether it'll work with the Intel graphics chipset is an open question.
Congratulations! You have found out that converged devices are a trade-off.
Make the same device to both functions, and guess what your biggest problem is going to be.
That people will listen to MP3s and run the battery down to zero, rather than stop listening to MP3s when they notice that the battery is low, so they can continue to receive calls.
In other words, the problem is that people are stupid.
Obligatory quote from Bruce Schneier, referenced from this Slashdot post, which referenced this web site, which referenced Schneier's Applied Cryptography:
(Note that he's talking about symmetric ciphers, like DES - not public key ciphers, like RSA. But you get the idea.)
Um, why? Are you saying there is some massive unmet demand for penguins in our universe? People have cash burning a hole in their pocket, wanting to be spent on penguins, but, alas, no supplier exists? 'Cause that's the only way Linus in the alternative universe would drain off lots of cash that remains in consumers' hands in this universe.
I am not saying anything about our universe.
I am presenting a hypothetical parallel universe. Just like you did. It's another what-if scenario. It doesn't have any reason. It doesn't need to. It's hypothetical. People in that universe have a massive unmet demand for penguins. If we accept that, then what consequences does it cause?
Anyway, I don't really follow your line of reasoning. Not sure what it is you're trying to say.
I'm saying this: Your original post postulated a hypothesis which I thought had bias in a certain direction. So I postulated an opposing hypothesis to contrast it, to expose this bias. (I am not saying that the bias is bad, or even that it had bias. Only that I thought it did.)
The intention was not to make an economic argument, rather a logical one.