Efforts like this are dangerous for the same reason that OS/2's Windows compatibility layer killed OS/2: it removes any incentive for vendors to support you natively. They'll just develop for Windows alone and assume you come along for the ride. (but judging from the quality of MS's kernel APIs and most third-party Windows drivers, we don't WANT them...)
You are right, Maya 5 is available for Linux (I own it), but not the "learning" edition.
I assume Alias is afraid of the immense technical support burden. Installing and setting up Maya on Linux is not as simple as on Windows or OSX. They do offer installation support for the "learning" edition, and I bet they don't want their Linux support people tied up helping newbies all day.
Actually I prefer 5400RPM drives... They tend to run quieter and cooler, so they don't need aggressive cooling. The speed difference vs. 7200RPM drives isn't that big of a deal, and it's easier to RAID 5400RPM drives due to the aforementioned heat and cooling issues:)
I would definitely love the ability to define a new non-virtual member function anywhere...
I would also like virtual data members. e.g. class Foo { virtual int a = 1; }; class Bar : public Foo { virtual int a = 3; }. This should be easy to implement - just put them into the vtable along with the function pointers. And it would eliminate the need for zillions of tiny functions like virtual int Foo::get_a() { return 1; }
From my own experience with raster and vector GUIs I'd estimate the cutoff point is quite high; about 1280x1024. That is, below 1280x1024 you really need to carefully line things up pixel-by-pixel for maximum clarity (I'm talking about typical GUI interface graphics). Only at higher resolutions can you take a hands-off approach and just let the OS rasterize an abstract vector description.
This means that for really small displays like cell phones, a lot of manual tweaking will still be required for vector-based stuff to work. (e.g. a "" element from 1280x1024 would lose its shaded border, rounded edges, etc and become a plain box at 320x200).
If you want an example of this, look at the taskbars and menu bars of KDE or Gnome. A lot of the text and boxes/lines are 1 or 2 pixels out of place, which results in a much less "professional" look than a polished pixel-by-pixel design like the Windows or Mac OS menu bars. (I have yet to see a menu bar from KDE or Gnome that looks as good as the default Windows or OSX menu bars; AA text helps, but polishing pixels sells the result)
Just to be specific, looking at the first screenshot on the SVG page, the URL bar is too "tight" (too many lines close together), the underline under the "o" in "Location:" is too wide, the toolbar icons are too close, the digital clock in the lower-right needs a border, etc. I'm only talking about 1 or 2 pixels here and there, but that's the difference between "OK" and "insanely great".
Ironically I don't think even Mac OSX uses vectors for its UI elements (scroll bars, etc). They're just carefully-tweaked bitmaps. Hopefully they will make this jump before 3840x2400 displays become commonplace:)
I know I've read about just such an IR image-spoiling system that is in testing, if not daily use, in theaters.
But this still leaves the problem of a projectionist turning off the IR to make a good copy. A unique watermark that is traceable to individual cinemas could be more effective. (the cinema owner would have to keep track of which employees handled each print, but that's a lot easier than tracking down P2P pirates:)
I wonder if they might put a different watermark on each print, so they can track which ones get pirated...
Maybe they'll fine a cinema if a pirated version of their print surfaces. That would give an incentive to control access to the prints and stop people from bringing cameras into the theater.
Another technique might be to briefly mask different parts of the frame, or vary the frame rate slightly, to confound video cameras (like a CRT monitor refresh - you can adjust a video camera for a particular constant rate, but it would be hard if the rate varied a lot).
And I agree that any measure that perceptibly alters the experience for normal audiences is reprehensible.
I own the WMV9 T2 DVD. The visual quality is quite impressive. It was very, very hard to spot any kind of compression artifact. NTSC MPEG-2 usually jumps out at me anywhere under 7 Mbit/sec.
The image was actually not a whole lot *sharper* than an NTSC DVD. The resolution of the WMV9 stream is only around 1200x700 (I forgot the exact number but it's definitely less than 1440 pixels across). Nonetheless the absence of noticeable compression artifacts more than makes up for this. The overall visual impression is that of a really good NTSC DVD, but without any MPEG-2 artifacts. (and keep in mind the dirty little secret of HDTV - *very* few pieces of equipment outside the movie studios actually record 1920x1080 useful pixels - the effective *information-carrying* resolution of most consumer-level HD equipment is probably no more than 1024x576, even in "1080i" mode - as Joe Kane found out:).
The T2 HD DVD has two *SERIOUS* problems though. First is setting up their player software - it requires WMV9 plus a bunch of updates, and had compatibility issues with some of my video cards (requiring several driver updates). Only a really tech-savvy Windows user would be able to get it to play at all. (this problem will hopefully go away if WMV9 decoding is implemented in set-top players:). The second problem is the incredibly onerous DRM system. Your computer must "phone home" to the studio to get a license to view the movie - and the license only lasts 7 days. So if your net connection is down, or (god forbit) the company goes bankrupt, your DVD becomes a $29.95 coffee-table coaster. (again, a set-top player would mitigat this...)
One really neat application for DiVX might be a fast end-run around the HD DVD standardization process. A movie studio and player manufacturers could get together and squeeze HD movies down using DiVX so that they fit on a standard DVD. Then they could legitimately sell HD DVDs either as an add-on to NTSC/PAL DVDs, or as a separate unit, without having to wait for the "real" HD DVD standard to be worked out.
Or, cable/satellite broadcasters could use DiVX to send channels at lower bandwidths than they do currently with MPEG-2, and thus offer more channels. (god knows they've been lowering the bitrate on MPEG-2 channels to barely-tolerable levels...).
I definitely agree with the others that DiVX should not call itself "MPEG-4 compatible" unless you can really take a DiVX-encoded file and play it on most MPEG-4 players (e.g. Quicktime 6). Standards exist for a reason; if it doesn't interoperate with anything, then at most it's "MPEG-4 like", not "MPEG-4 compatible".
(just as Linux is "Unix-like", not really 100% "Unix-compatible")
It is amusing to watch Schneier walk a political tight-rope in many chapters, carefully pointing out that some issues come down to personal value judgments. He tries his best not to take sides but I feel the work is somewhat politically biased. e.g. I object to his assertion that airline pilots shouldn't be trusted with guns, simply because that is not their primary area of expertise. And I don't agree with his model of US military intervention - basically that intervention leads to anti-Americanism which leads to more terrorism - this leaves out the potential for positive social and economic intervention to weaken extremist positions.
Not to detract from the book as a whole; I found it an eye-opening read, and am very happy it was written and published.
I humbly note that your "good" HTML example is 50% larger than your "bad" example:)
You could certainly *write* your website in the "good" form, then process it into the "bad" (but more compact) form with an automated filter. Then you get the best of both worlds - a highly-structured authoring environment, and a compact on-the-wire representation.
Again, I'm emphasizing "on-the-wire". Many digital media use a different representation at the "authoring" stage than the "publishing" stage. e.g. you might write something in TeX and then publish it as a PDF file (or write C code and "publish" it as an executable). It makes sense for the "authoring" format to be as flexible as possible, but the "publishing" format should emphasize compactness. In HTML "authoring" and "publishing" are mostly seen as one and the same, but there's no reason that has to be so.
Atomic file transactions would be great. I think this is in the plan for Reiserfs v4. It would eliminate SO many little race conditions here and there... (one of which being the program-crashes-while-writing problem, where you end up with a non-zero but otherwise corrupted file)
AFAIK the only things you can count on being atomic right now on Unix are rename() (within the same mount) and small write()s. (theoretically open(O_EXCL) and link() too, but they break on NFS I think). Actually, a Unix-compatible network filesystem that supports atomicity guarantees would be awesome (we've gotten so used to the horrors of NFS it's hard to imagine life without it now...)
I would prefer more browsers to use gzip for retrieving web pages. Also, web servers could optimize HTML by stripping out all unnecessary whitespace and redundant tags before transmission.
In my experience, standards-compliant HTML is *less* space-efficient than ad-hoc HTML. Compare font size="+1" vs. font size=+1 or the extra trailing slash on atomic tags, or/p tags (which you can pretty much omit entirely without confusing any browsers).
I predict that at some point in the future it will become a crime, or at least very strongly looked-down upon, to send compressible (redundant) data over public networks in uncompressed form.
Capping uploads lowers their costs, and most users won't even notice. Most of those who DO notice will be the ones doing illegal stuff anyway, and so won't complain for fear of being caught:)
I think broadband ISPs rarely imposed upload caps in the past because nobody really had an application that took much upstream bandwidth on a consistent basis. Along comes Napster/Kazaa/et al, and now practically *everyone* is trying to max out their upload rate *all the time*. I don't blame ISPs for reacting with severe caps. (although I wish they had an option to raise your cap if you pay extra - I'd take it in a second...)
How about the shocking asymmetry of download vs. upload speeds? Time Warner Road Runner just lowered our upload cap to 10KB/sec. This more than 20x slower than our max download rate (~225KB/sec).
Here are two legitimate reasons a hardware company might withhold driver code:
1) They differentiate high-end and low-end versions of the same product in software only. I think Nvidia and some storage vendors do this - they sell the same card for $200 and $400, but the driver disables certain features on the $200 part. If they released the source someone could easily find a way to re-enable the "high-end" features on cheap hardware, thus erasing the product differentiation. (which would force the company to sell only the more expensive part, and everyone loses)
2) Software-based copy prevention, a la DVD CSS, or software-based restrictions, like Macrovision. (I know at least one video card company won't release driver source because it would be obvious how to stop Macrovision from being enabled when a video player requires it)
I'd say 2) is slightly less legitimate, but I have no problem with reason 1). I'd rather be able to buy cheap but limited hardware than not have the option at all.
More important I would say is an NTSC/PAL video output that does NOT consist of a scan converter hooked up to the regular VGA video card. NTSC/PAL and HDTV have vastly different signal requirements than VGA (interlacing, YCbCr vs RGB, etc). A scan converter will produce some sort of approximation of a real NTSC/PAL signal, but if you compare e.g. a DVD playing through a VGA scan converter against the component or S-video out from a set-top DVD player, the VGA out looks like a poor imitation.
I would love to see a commodity video card with a dedicated NTSC/PAL out driven by a hardware MPEG-2 decoder. (NOT simply a software decoder that scales video to the frame buffer and then scan converts it)
I think the studios' position is that they can't stop you from taking music you bought out of the country - but they definitely don't want to create a secondary market by making it easy to export music for sale (not only would this violate their contracts, it would also reduce the profits from geographic price discrimination).
If the mechanism to prevent export sales also makes purchased music become unplayable out of the country, so much the better for the studios - you'll have to buy everything all over again.
It's like DVD region coding or NTSC vs. PAL videos. I'm sure all future consumer media formats will be geographically restricted in addition to encrypted. (wasn't there a story recently about consumer electronics equipped with a GPS-triggered self-destruct mechanism to prevent export sales?)
It's stupid, I know, but more profitable than the alternative of letting anyone buy anything anywhere... Why not buy some stock in media companies?:)
The reason for this is that music studios have signed contracts going back to the 80s, 70s, 60s, and before, which only cover the right to sell music in the US. Many artists sign with different labels overseas (this seemed the best way to go before the internet appeared, since each local label knew the most about marketing for its own territory). Anyway, many US labels don't even have the right to sell their music stock outside the country. Apple is just passing along this restriction.
It would take a MAJOR re-negotiation of almost every artists' contract to change this. That may eventually happen but it won't be soon.
The same thing happens with movies, btw. Expect on-line pay movie services to restrict viewing to the US.
I think part of the reason some devices are banned during takeoff and landing is that they are distracting, and could slow your reaction to an emergency situation. If the plane goes down on takeoff or landing they don't want you zoned out listening to Metallica when they're explaining what to do (because everybody reads those safety instruction cards, right...)
As someone who has used Premiere to edit large projects for years, and recently switched to Final Cut, I have to say: who cares? Final Cut Pro is better than Premiere in almost every respect. Anyone who mourns the loss of Premiere on the Mac must be insane (or at least a masochist).
The on-board audio out from my Dell Precision 350 is quite acceptable (though with more noise than most sound cards, and you can hear CPU/bus traffic). But the audio input is something else... Even with a good microphone it produces the most disgusting waveforms you've ever seen - TONS of noise (more than an analog casette tape) and a wacky DC offset of something like 10dB. The same mic plugged into a Mac works just fine.
I hear the best approach is to move the AD/DA conversions outside the computer - this week I'm supposed to receive a sound card with digital I/O and a dedicated AD/DA hardware box.
The one consumer-level application where a better bus is vital is HDTV. Current buses are just barely able to handle uncompressed SDTV (20-30MB/sec). (in theory PCI gives you 133MB/sec and AGP more, but as they say, in theory there is no difference between theory and practice:).
PCI-X will finally bring HDTV (~200MB/sec) within reach. What this means is that you'll be able to have a software-only HDTV decoder - which will make it trivial to receive HDTV broadcasts on a PC, and make HD-DVD players possible.
At the pro level, this is just about the last thing that a $50K SGI system has over a cheap Linux PC - playback and maniupulation of uncompressed HDTV video. It's about time PCs finally caught up to "workstations" in the bus department...
I will add to this and point out that ALL previous missions to the outer planets have generated power using radioactivity. There is simply NO way current solar power technology can provide enough power for a decent-size spacecraft far beyond the orbit of Mars.
(Jupiter is about 5AU from the sun, and solar power drops off as 1/r^2, so you'd need 25 times the solar panel area as a spacecraft near Earth - and solar panels ALREADY dominate most spacecraft designs!).
Cassini was the last outer-planets launch, and its use of a radioactive power generator stirred up tremendous controversy. (mostly among uninformed people who recoiled at the mention of "nuclear" anything). The actual hazard was very very small. A launch accident would probably not have resulted in the release of any radioactive material. The dangerous part of the mission was when Cassini flew by Earth again (for a gravitational slingshot) after traveling the inner solar system for a while. At this time it was traveling so fast that if it went off course and entered the atmosphere, the radioactive generator would have vaporized and dispersed its payload over a large area. The estimated net effect on cancer rates due to this was the equivalent of having each person in the affected area smoke one cigarette - very small, but not zero.
The good news is that situtations like this can be avoided in the future if outer-solar-system craft do not use Earth for slingshot trajectories. This will probably require more fuel and reduce their usable payloads, but it is not an insurmountable problem.
Slashdot Mirror
Efforts like this are dangerous for the same reason that OS/2's Windows compatibility layer killed OS/2: it removes any incentive for vendors to support you natively. They'll just develop for Windows alone and assume you come along for the ride. (but judging from the quality of MS's kernel APIs and most third-party Windows drivers, we don't WANT them...)
You are right, Maya 5 is available for Linux (I own it), but not the "learning" edition.
I assume Alias is afraid of the immense technical support burden. Installing and setting up Maya on Linux is not as simple as on Windows or OSX. They do offer installation support for the "learning" edition, and I bet they don't want their Linux support people tied up helping newbies all day.
Actually I prefer 5400RPM drives... They tend to run quieter and cooler, so they don't need aggressive cooling. The speed difference vs. 7200RPM drives isn't that big of a deal, and it's easier to RAID 5400RPM drives due to the aforementioned heat and cooling issues :)
I would definitely love the ability to define a new non-virtual member function anywhere...
I would also like virtual data members. e.g. class Foo { virtual int a = 1; }; class Bar : public Foo { virtual int a = 3; }. This should be easy to implement - just put them into the vtable along with the function pointers. And it would eliminate the need for zillions of tiny functions like virtual int Foo::get_a() { return 1; }
From my own experience with raster and vector GUIs I'd estimate the cutoff point is quite high; about 1280x1024. That is, below 1280x1024 you really need to carefully line things up pixel-by-pixel for maximum clarity (I'm talking about typical GUI interface graphics). Only at higher resolutions can you take a hands-off approach and just let the OS rasterize an abstract vector description.
:)
This means that for really small displays like cell phones, a lot of manual tweaking will still be required for vector-based stuff to work. (e.g. a "" element from 1280x1024 would lose its shaded border, rounded edges, etc and become a plain box at 320x200).
If you want an example of this, look at the taskbars and menu bars of KDE or Gnome. A lot of the text and boxes/lines are 1 or 2 pixels out of place, which results in a much less "professional" look than a polished pixel-by-pixel design like the Windows or Mac OS menu bars. (I have yet to see a menu bar from KDE or Gnome that looks as good as the default Windows or OSX menu bars; AA text helps, but polishing pixels sells the result)
Just to be specific, looking at the first screenshot on the SVG page, the URL bar is too "tight" (too many lines close together), the underline under the "o" in "Location:" is too wide, the toolbar icons are too close, the digital clock in the lower-right needs a border, etc. I'm only talking about 1 or 2 pixels here and there, but that's the difference between "OK" and "insanely great".
Ironically I don't think even Mac OSX uses vectors for its UI elements (scroll bars, etc). They're just carefully-tweaked bitmaps. Hopefully they will make this jump before 3840x2400 displays become commonplace
I know I've read about just such an IR image-spoiling system that is in testing, if not daily use, in theaters.
:)
But this still leaves the problem of a projectionist turning off the IR to make a good copy. A unique watermark that is traceable to individual cinemas could be more effective. (the cinema owner would have to keep track of which employees handled each print, but that's a lot easier than tracking down P2P pirates
I wonder if they might put a different watermark on each print, so they can track which ones get pirated...
Maybe they'll fine a cinema if a pirated version of their print surfaces. That would give an incentive to control access to the prints and stop people from bringing cameras into the theater.
Another technique might be to briefly mask different parts of the frame, or vary the frame rate slightly, to confound video cameras (like a CRT monitor refresh - you can adjust a video camera for a particular constant rate, but it would be hard if the rate varied a lot).
And I agree that any measure that perceptibly alters the experience for normal audiences is reprehensible.
I own the WMV9 T2 DVD. The visual quality is quite impressive. It was very, very hard to spot any kind of compression artifact. NTSC MPEG-2 usually jumps out at me anywhere under 7 Mbit/sec.
:).
:). The second problem is the incredibly onerous DRM system. Your computer must "phone home" to the studio to get a license to view the movie - and the license only lasts 7 days. So if your net connection is down, or (god forbit) the company goes bankrupt, your DVD becomes a $29.95 coffee-table coaster. (again, a set-top player would mitigat this...)
The image was actually not a whole lot *sharper* than an NTSC DVD. The resolution of the WMV9 stream is only around 1200x700 (I forgot the exact number but it's definitely less than 1440 pixels across). Nonetheless the absence of noticeable compression artifacts more than makes up for this. The overall visual impression is that of a really good NTSC DVD, but without any MPEG-2 artifacts. (and keep in mind the dirty little secret of HDTV - *very* few pieces of equipment outside the movie studios actually record 1920x1080 useful pixels - the effective *information-carrying* resolution of most consumer-level HD equipment is probably no more than 1024x576, even in "1080i" mode - as Joe Kane found out
The T2 HD DVD has two *SERIOUS* problems though. First is setting up their player software - it requires WMV9 plus a bunch of updates, and had compatibility issues with some of my video cards (requiring several driver updates). Only a really tech-savvy Windows user would be able to get it to play at all. (this problem will hopefully go away if WMV9 decoding is implemented in set-top players
One really neat application for DiVX might be a fast end-run around the HD DVD standardization process. A movie studio and player manufacturers could get together and squeeze HD movies down using DiVX so that they fit on a standard DVD. Then they could legitimately sell HD DVDs either as an add-on to NTSC/PAL DVDs, or as a separate unit, without having to wait for the "real" HD DVD standard to be worked out.
Or, cable/satellite broadcasters could use DiVX to send channels at lower bandwidths than they do currently with MPEG-2, and thus offer more channels. (god knows they've been lowering the bitrate on MPEG-2 channels to barely-tolerable levels...).
I definitely agree with the others that DiVX should not call itself "MPEG-4 compatible" unless you can really take a DiVX-encoded file and play it on most MPEG-4 players (e.g. Quicktime 6). Standards exist for a reason; if it doesn't interoperate with anything, then at most it's "MPEG-4 like", not "MPEG-4 compatible".
(just as Linux is "Unix-like", not really 100% "Unix-compatible")
It is amusing to watch Schneier walk a political tight-rope in many chapters, carefully pointing out that some issues come down to personal value judgments. He tries his best not to take sides but I feel the work is somewhat politically biased. e.g. I object to his assertion that airline pilots shouldn't be trusted with guns, simply because that is not their primary area of expertise. And I don't agree with his model of US military intervention - basically that intervention leads to anti-Americanism which leads to more terrorism - this leaves out the potential for positive social and economic intervention to weaken extremist positions.
Not to detract from the book as a whole; I found it an eye-opening read, and am very happy it was written and published.
I humbly note that your "good" HTML example is 50% larger than your "bad" example :)
You could certainly *write* your website in the "good" form, then process it into the "bad" (but more compact) form with an automated filter. Then you get the best of both worlds - a highly-structured authoring environment, and a compact on-the-wire representation.
Again, I'm emphasizing "on-the-wire". Many digital media use a different representation at the "authoring" stage than the "publishing" stage. e.g. you might write something in TeX and then publish it as a PDF file (or write C code and "publish" it as an executable). It makes sense for the "authoring" format to be as flexible as possible, but the "publishing" format should emphasize compactness. In HTML "authoring" and "publishing" are mostly seen as one and the same, but there's no reason that has to be so.
Atomic file transactions would be great. I think this is in the plan for Reiserfs v4. It would eliminate SO many little race conditions here and there... (one of which being the program-crashes-while-writing problem, where you end up with a non-zero but otherwise corrupted file)
AFAIK the only things you can count on being atomic right now on Unix are rename() (within the same mount) and small write()s. (theoretically open(O_EXCL) and link() too, but they break on NFS I think). Actually, a Unix-compatible network filesystem that supports atomicity guarantees would be awesome (we've gotten so used to the horrors of NFS it's hard to imagine life without it now...)
I would prefer more browsers to use gzip for retrieving web pages. Also, web servers could optimize HTML by stripping out all unnecessary whitespace and redundant tags before transmission.
/p tags (which you can pretty much omit entirely without confusing any browsers).
In my experience, standards-compliant HTML is *less* space-efficient than ad-hoc HTML. Compare
font size="+1"
vs.
font size=+1
or the extra trailing slash on atomic tags, or
I predict that at some point in the future it will become a crime, or at least very strongly looked-down upon, to send compressible (redundant) data over public networks in uncompressed form.
Capping uploads lowers their costs, and most users won't even notice. Most of those who DO notice will be the ones doing illegal stuff anyway, and so won't complain for fear of being caught :)
I think broadband ISPs rarely imposed upload caps in the past because nobody really had an application that took much upstream bandwidth on a consistent basis. Along comes Napster/Kazaa/et al, and now practically *everyone* is trying to max out their upload rate *all the time*. I don't blame ISPs for reacting with severe caps. (although I wish they had an option to raise your cap if you pay extra - I'd take it in a second...)
How about the shocking asymmetry of download vs. upload speeds? Time Warner Road Runner just lowered our upload cap to 10KB/sec. This more than 20x slower than our max download rate (~225KB/sec).
Here are two legitimate reasons a hardware company might withhold driver code:
1) They differentiate high-end and low-end versions of the same product in software only. I think Nvidia and some storage vendors do this - they sell the same card for $200 and $400, but the driver disables certain features on the $200 part. If they released the source someone could easily find a way to re-enable the "high-end" features on cheap hardware, thus erasing the product differentiation. (which would force the company to sell only the more expensive part, and everyone loses)
2) Software-based copy prevention, a la DVD CSS, or software-based restrictions, like Macrovision. (I know at least one video card company won't release driver source because it would be obvious how to stop Macrovision from being enabled when a video player requires it)
I'd say 2) is slightly less legitimate, but I have no problem with reason 1). I'd rather be able to buy cheap but limited hardware than not have the option at all.
More important I would say is an NTSC/PAL video output that does NOT consist of a scan converter hooked up to the regular VGA video card. NTSC/PAL and HDTV have vastly different signal requirements than VGA (interlacing, YCbCr vs RGB, etc). A scan converter will produce some sort of approximation of a real NTSC/PAL signal, but if you compare e.g. a DVD playing through a VGA scan converter against the component or S-video out from a set-top DVD player, the VGA out looks like a poor imitation.
I would love to see a commodity video card with a dedicated NTSC/PAL out driven by a hardware MPEG-2 decoder. (NOT simply a software decoder that scales video to the frame buffer and then scan converts it)
I think the studios' position is that they can't stop you from taking music you bought out of the country - but they definitely don't want to create a secondary market by making it easy to export music for sale (not only would this violate their contracts, it would also reduce the profits from geographic price discrimination).
:)
If the mechanism to prevent export sales also makes purchased music become unplayable out of the country, so much the better for the studios - you'll have to buy everything all over again.
It's like DVD region coding or NTSC vs. PAL videos. I'm sure all future consumer media formats will be geographically restricted in addition to encrypted. (wasn't there a story recently about consumer electronics equipped with a GPS-triggered self-destruct mechanism to prevent export sales?)
It's stupid, I know, but more profitable than the alternative of letting anyone buy anything anywhere... Why not buy some stock in media companies?
The reason for this is that music studios have signed contracts going back to the 80s, 70s, 60s, and before, which only cover the right to sell music in the US. Many artists sign with different labels overseas (this seemed the best way to go before the internet appeared, since each local label knew the most about marketing for its own territory). Anyway, many US labels don't even have the right to sell their music stock outside the country. Apple is just passing along this restriction.
It would take a MAJOR re-negotiation of almost every artists' contract to change this. That may eventually happen but it won't be soon.
The same thing happens with movies, btw. Expect on-line pay movie services to restrict viewing to the US.
I think part of the reason some devices are banned during takeoff and landing is that they are distracting, and could slow your reaction to an emergency situation. If the plane goes down on takeoff or landing they don't want you zoned out listening to Metallica when they're explaining what to do (because everybody reads those safety instruction cards, right...)
http://www.maasdigital.com/gallery.html
As someone who has used Premiere to edit large projects for years, and recently switched to Final Cut, I have to say: who cares? Final Cut Pro is better than Premiere in almost every respect. Anyone who mourns the loss of Premiere on the Mac must be insane (or at least a masochist).
The on-board audio out from my Dell Precision 350 is quite acceptable (though with more noise than most sound cards, and you can hear CPU/bus traffic). But the audio input is something else... Even with a good microphone it produces the most disgusting waveforms you've ever seen - TONS of noise (more than an analog casette tape) and a wacky DC offset of something like 10dB. The same mic plugged into a Mac works just fine.
I hear the best approach is to move the AD/DA conversions outside the computer - this week I'm supposed to receive a sound card with digital I/O and a dedicated AD/DA hardware box.
The one consumer-level application where a better bus is vital is HDTV. Current buses are just barely able to handle uncompressed SDTV (20-30MB/sec). (in theory PCI gives you 133MB/sec and AGP more, but as they say, in theory there is no difference between theory and practice :).
PCI-X will finally bring HDTV (~200MB/sec) within reach. What this means is that you'll be able to have a software-only HDTV decoder - which will make it trivial to receive HDTV broadcasts on a PC, and make HD-DVD players possible.
At the pro level, this is just about the last thing that a $50K SGI system has over a cheap Linux PC - playback and maniupulation of uncompressed HDTV video. It's about time PCs finally caught up to "workstations" in the bus department...
I will add to this and point out that ALL previous missions to the outer planets have generated power using radioactivity. There is simply NO way current solar power technology can provide enough power for a decent-size spacecraft far beyond the orbit of Mars.
(Jupiter is about 5AU from the sun, and solar power drops off as 1/r^2, so you'd need 25 times the solar panel area as a spacecraft near Earth - and solar panels ALREADY dominate most spacecraft designs!).
Cassini was the last outer-planets launch, and its use of a radioactive power generator stirred up tremendous controversy. (mostly among uninformed people who recoiled at the mention of "nuclear" anything). The actual hazard was very very small. A launch accident would probably not have resulted in the release of any radioactive material. The dangerous part of the mission was when Cassini flew by Earth again (for a gravitational slingshot) after traveling the inner solar system for a while. At this time it was traveling so fast that if it went off course and entered the atmosphere, the radioactive generator would have vaporized and dispersed its payload over a large area. The estimated net effect on cancer rates due to this was the equivalent of having each person in the affected area smoke one cigarette - very small, but not zero.
The good news is that situtations like this can be avoided in the future if outer-solar-system craft do not use Earth for slingshot trajectories. This will probably require more fuel and reduce their usable payloads, but it is not an insurmountable problem.