I don't think these "copy flag bits" are going to work. All broadcasters will simply hard-code the flags to "no copy" all the time. And then we are back to square one...
In order for this to work, Congress must pass a law that enshrines "fair use" as a guaranteed right that must be allowed by any copy-prevention system.
Also, any stream that contains "copy flag bits" must be required to include the expiration date of the copyright. Copy-prevention systems must be required to freely decrypt material that has entered the public domain.
A "copy flag bit" that doesn't also include an expiration date clearly violates the "limited Times" clause of the US Constitution.
Does anyone know if CSS-scrambled DVDs or WMA-scrambled audio streams include a copyright expiration date? I don't think so...
The reverse of this would be even more useful to me - a mapping from DNS to phone number.
That way I could give out my stable, unchanging domain name, instead of my phone number - which changes depending on where I am and who I'm buying phone service from.
Maybe you could store a phone number in a special type of DNS record. Then you'd pay a small fee to a company that provides a toll-free number. People who want to get in touch with me call the toll-free number, type in the domain name, and the call connects. Computer-based phones or future stand-alone phones could let you type the DNS name instead of the phone number.
My best advice for those developing 3D animation software: do 3D animation. Then write the tools you need to do it better.
It may not be that difficult to reverse-engineer an existing program (in the sense of reverse-engineering its general architecture, not necessarily duplicating it bit for bit). I find that the public documentation on Maya and Lightwave is detailed enough to get a very good idea of how their internals are structured.
Yes "dynamic range" is just the range of dark to bright across which the sensor gives you meaningful information.
Photographic negative film has something like 9-10 stops (powers of 2) dynamic range. That means you can record a bright highlight that is ~1000 times brighter than a dark shadow in the same image, and still retain full detail in both.
CCDs are improving quickly, but the ones in most digital cameras today don't have nearly the same dynamic range as film (something like 100:1, but there is a great deal of variation). You can certainly take good photos with these, but you'll have trouble capturing good detail in both bright highlights and dark shadows in a single exposure. You tend to get washed-out uniform highlights and shadows.
Another issue is that amateur digital cameras only give you 8 bits of brightness information per pixel, whereas negative film has something like 12 bits of information. Most pro cameras do give you access to 12 or 16 bits of brightness, but you'll have a hard time handling those images without special software.
When all is said and done, I don't think the reduced dynamic range of CCDs versus film is going to be a major problem for anyone except professional photographers. The shortcomings of low dynamic range only become apparent if you are doing extensive image processing. (such as brightening or darkening the image before printing it)
One last area where CCDs don't do so well is with sharp edges at high resolution. The digital images on the review linked from this article have what I call a "shitty edge" effect - there are dark contours around all of the sharp edges. Granted this could be an artifact of the JPEG compression, but I've seen it in almost all CCD photos and videos. Edges and color transitions should be smooth, like in the film images.
I think the problem is that CCDs do odd things at the individual pixel level - the red/green/blue sensors are not exactly coincident, so the camera needs to do a bit of image processing or filtering to produce a final RGB image; whereas in film the dye layers are exactly on top of each other. You can mitigate this by downsampling the digital image, but then you sacrifice resolution.
I stand corrected - you are right about 1.x vs 2.x. I just got the distinct impression that 2.x was to stay until a long-off "flag day" when enough incompatible changes have been waiting to be worth breaking user-space.
BTW by "ABI version" I specifically mean the kernel-user ABI - i.e. the syscall numbers, their arguments, and expected behavior. Not the kernel-driver ABI, which, as you point out, changes with virtually every release.
The kernel-user ABI has the distinction of being practically the only ABI that has *not* seen incompatible changes in my 3+ years of Linux usage =).
Re:About the "new driver model"
on
Linux Kernel 3.0?
·
· Score: 3, Informative
No, as long as Linus is in charge there will never be binary compatibility of modules between minor kernel versions (or even different configurations of a single version, e.g. UP or SMP). Linus considers it too much trouble to be worth the effort.
AFAIK the new driver model basically puts all drivers in a uniform structure, primarily for the purposes of handling power management (sleep states) uniformly, and of moving towards a simple, standardized layout for/proc interfaces. There has been some talk about revising the module loading/unloading process (since the current methods still have some problems), but no action has been taken yet.
I meant linear in the sense that the single-player game is simply a linear path through all the maps. Also the game has been tweaked out for action/fun rather than realism. (e.g. no M1 Garand)
1942 claims replayability because of the "smart" AI, but in my experience the AI is basically dumb as dirt:[.
Multiplayer is where it shines, of course - but the net code is pretty awful. I'm not sure the average buyer of 1942 would be persistent enough to actually enjoy on-line play...
I would say that 1942 is a lot more polished than, say, Operation Flashpoint or America's Army. The audio is great, the in-game server browser actually works (a first! although they get serious negative points for pushing you to install Gamespy Arcade - ugh). I'm hoping they will fix the net code in future patches, we'll see... (IMHO they would have been much better off licensing a good engine like Q3A or Torque than baking their own - MOHAA had awesome net play, thanks to the Q3 engine...)
Agreed... The shooter games that EA publishes have been among the simplest and most linear I've played. (thinking of Medal of Honor and Battlefield 1942 here).
On the other hand, they do seem a bit more "polished" than a lot of second-tier shooter releases. (by that I mean the audio is good, and there aren't enough bugs in the first release to make the game seriously unplayable =)
Argh! The first digit in the kernel version number was always meant to indicate the ABI version! They should NOT change it from 2. to 3. unless they intend to make major (backwards-incompatible) changes to the kernel ABI. If they do this then we will lose the second-to-last piece of information in kernel version numbers. (the last piece being the even/odd stable/development thing)
I guess Linus is falling into the same trap as most other free software developers. Already in most software packages, version numbers provide nothing more than an ordered sequence of releases. There is no way to tell just by looking at a version number what ABI/API version is exported, whether it is a stable or development release, etc. Pathetic.
If this law passes, it would be open season for hacking. Just put up a an original two-line poem on your web server. Claim copyright on it. According to the DMCA, when anyone's web browser downloads it, they have made an actionable copy and therefore infringed your copyright. So now you have the right to go and hack them to kingdom come, with no penalty whatsoever!
It would be even better if someone created a central repository of logged copyright infringements, indexed by the source. Want to hack Microsoft or IBM? Just look for a company IP address in the repository.
I should probably defer to the experts on this question; I'm not a NASA engineer =).
My guess- in order to increase the bandwidth, the spacecraft needs to carry a larger, more powerful transmitter. This adds weight and power consumption, two resources that are extremely scarce in spacecraft design.
If you are in low earth orbit, however, it's not impossible to get real-time, high-bandwidth video. One of my clients is a company that specializes in this kind of thing: Ecliptic Enterprises.
The difficult part about taking hi-res images is getting them back to earth. Using the best radio communication technology we have, we can receive only a handful of KB/sec from a remote probe in the inner solar system. In the outer solar system we are limited to more like a couple hundred bytes a second. And then there are overheads, like control commands and non-image science data. If the probe is on a planet then we can only receive when Earth is abobe its horizon. (unless we use a relay satellite...)
I believe modern missions use light compression on the images before transmitting them back, but scientists are naturally reluctant to use any fancy compression algorithms for fear of skewing the data.
Our best hope for the future is optical-wavelength communication, which could theoretically push data rates into megabytes per second.
BTW you want eye candy? Check out my Mars Rover video =).
I believe VirtualDub can read MPEG-1 now, but I don't think it can write them.
MPEG is sort of outside VirtualDub's scope; it is first and foremost an *AVI* editing program (not a general video editing program).
To my knowledge there is no single software package that can handle AVI, Quicktime, and MPEG equally well. (Premiere claims to handle all three, but its Quicktime and MPEG support have serious problems; Apple's Quicktime also claims to handle all three, but its AVI support is severely lacking).
Plus, I don't think it is possible to distribute a free MPEG-2 codec since there are active patents on it... (Apple distributes Quicktime 6 without MPEG-2 support, and makes you pay $20 or $30 extra for it)
Virtual Dub rules. If you do any work with video on Windows, it is essential.
Virtual Dub is much more stable and its interface is much more streamlined than most other free software. Plus it has probably the most robust AVI read/write code ever offered. Out-of-spec files that crash other video programs, Virtual Dub chews 'em up and spits 'em out.
1) The GeForce2 hardware is identical to Quadro2 hardware, except for a single resistor. (which you can solder to "morph" your card into the other type - there are instructions for this on several websites)
2) The Quadro2 performs an order of magnitude faster than the GeForce2 on certain specific benchmarks, such as antialiased line drawing. These specific features are used in many CAD applications but not in any games.
Therefore, the driver must be crippling certain features when it thinks it's running on a GeForce 2. So NVIDIA can charge CAD users $600 for essentially the same hardware that a gamer buys for $200... (these prices were when the GeForce2 was first released, of course)
I don't think SGI's old IP is the reason NVIDIA won't release source code. The real reason is that the drivers deliberately cripple certain advanced features on NVIDIA's low-end cards, to force "professional" users to buy their high-end cards.
Remember how the $600 Quadro2 hardware was exactly the same as a $200 GeForce2, except for a tiny little resistor? I'm sure there are a few places in the NVIDIA driver like: if(user_paid_for_quadro()) {
make_antialiasing_fast();
enable_overlay_planes(); } else {
make_antialiasing_slow();
disable_overlay_planes(); }
So naturally a few days after they release the driver souce, somebody would provide a "magic" version of the driver that makes all of NVIDIA's low-end cards perform just like their high-end cards. Then they wouldn't be able to charge $600 for "pro" video cards anymore...
This would be really easy to implement also, at least on a PC/software DVD player - you could give the player the ability to read in a text file containing the edits. Then all you need to do is download a tiny EDL file. You'd have to own the original DVD to make any use of it, and I'm pretty sure you could argue that the EDL file is not covered under the DVD's copyright as a derivative work.
Then Clean Flicks et al could open up a website, kind of like CDDB, where you just stick the DVD in, and it automatically downloads the appropriate "clean" edit. (they could charge for each EDL download, or a monthly fee for access to the website).
Of course "Episode I: The Phanom Edit" type stuff would be easy to find also =).
Sophisticated players could look for audio fade-in/fade-out commands in the EDL to hide jumps in the soundtrack where a scene was deleted.
It would be tougher to do this with all-in-one hardware DVD players; maybe you could fit a USB port on one and download the playlist from a PC (yuck), or maybe the player could accept a "smart card" with the EDL on it.
But realistically, I'd expect that the movie studios themselves will eventually realize that they can charge extra if each DVD already comes equipped with a "clean" option. (they already edit for airlines and offer multiple language soundtracks; clean edits can't be THAT much of a stretch).
Yes, it will still be possible to do a digital->analog->digital rip. But I doubt you will see equipment capable of ripping a digital HD signal while preserving any more detail than a regular old SD signal...
Another issue is that, thanks to the DMCA, making or distributing a tool to do this will be a felony. Region-free DVD players are sort of in a grey area, as are Macrovision removers. But DeCSS and "De5C" are unquestionably illegal. You may be able to get them from a website here or there (before MPAA orders them shut down), but you definitely WON'T see any actual companies making these kinds of tools. Which means they will be inaccessible to 99.9% of the population. (remember, you need to rip/crack the HD content to exercise ANY of your fair use rights, like time shifting, making a backup copy, subtitling for foreign language speakers or the hearing-impaired, playing the video on a portable unit, etc... These are things everybody should be able to do, not just hard-core video geeks).
And finally, who is going to be in charge of the encryption keys? If things keep going the way they look like they're going, the US government will mandate 5C copy-prevention for all digital broadcasts. So it will be impossible to get your own content broadcasted, since only the big studios will have the keys.
(here's a thought - if they mandate an encryption system, they should also have to mandate that the public encryption keys be made available to anyone who asks...)
Although I disagree that threaded programs are inherently easier to write than state machine programs, I can understand your point of view. It's probably a matter of personal preference and experience. (yes, Win32 and BeOS both strongly encourage a multithreaded style of programming, but I don't think that decision was made purely on technical merit. Multithreading was the "cool" thing to do back when these APIs were invented...)
If you need an example of AIO in a GUI application - consider Netscape 4 or Mozilla on Mac OS 9. These programs are multithreaded on most operating systems, but since Mac OS 9 has weak support for threads, the Netscape runtime simulates multiple threads using coroutines and AIO. (this is done transparently to code running on top of the runtime, so it still appears to be written in the multithreaded model...)
I use Mozilla and I do notice that it sometimes becomes unresponsive to input while loading a page. But when I boot into Windows, Internet Explorer has no problem loading the same pages without noticeable delays. (not only are other IE windows not blocked, but the one that's loading isn't blocked for long either - so it can't be IE doing all the work in a background thread). I blame inefficient code in Gecko... Pushing the work into a background thread is only a band-aid; it's like pushing a bubble sort algorithm into a background thread when you could just use quicksort and get the same work done much faster.
Existing SD TV sets will not need to be thrown out. All current and proposed HD receivers will provide SD analog outputs, so your existing SD sets will work fine.
The problem is existing HD TV sets that lack a DVI input with 5C copy prevention hardware. The new HD guidelines that Hollywood is working on mandate that NO HD analog outputs are allowed - only SD analog and HD digital (with 5C copy prevention - like CSS for television). So you won't be able to use an older HD TV set with one of these new receivers, since most older HD TV sets only accept analog or unencrypted digital signals.
Hollywood is so intent on getting this standard adopted that they are willing to obsolete most existing HD TV sets. A Disney official has been quoted as saying, "[we care so much about the new HD standard] that we're willing to visit each current home with a HD TV set and replace it with a new [copy-prevented] one..."
The new HD guidelines put forth by Hollywood's "Broadcast Protection" working group are truly disgusting. They mandate precisely what outputs a HD receiver is allowed to provide - SD analog is OK, HD digital (encrypted) is OK, HD analog is NOT OK. Which means the only way to record or manipulate (e.g. subtitle) a digital HD broadcast will be using Hollywood-approved hardware, and conditional on the "copy-prevention" flag in the data stream being turned off. And I'm sure that before long, all HD broadcasters will simply leave all of the "prevention" flags on all the time... (goodbye fair use, goodbye time-shifting, etc...)
I hate those UNIX grognards that come from that school of thought, then try to code GUI applications with only one thread and end up with apps that can't update the GUI while doing I/O
Then they are stupid. I/O can be done asynchronously in a single-threaded program; you just need to use non-blocking I/O (sockets) or AIO (disk).
As for Galeon - the rendering code needs optimization. Rendering in a background thread is NOT going to help. (think: the socket connection to the X server is inherently serialized; if rendering is the bottleneck then the rendering code itself is the problem)
I agree... We recently switched to digital cable here in central NY state (Time Warner). I actually find the MPEG-2 compression artifacts MORE objectionable than regular old analog noise. (especially for the higher numbered channels, which I assume use a lower bitrate than the major networks). Another minus of the digital system is that it takes FOREVER to change channels (1-2 seconds, versus almost instantaneous for analog).
Normally I am of the "use only as many threads as CPUs" school of thought, but I can think of a reason to use 100,000 threads - imagine a large FTP server, or a multi-homed HTTP server, where you need to provide each connected user with his own set of access privileges or filesystem context. A one-thread-per-connection server may be the easiest way to build security into the system.
I think we, the Internet technical community, have to face up to the fact that we fucked up. We committed ourselves to an email system (SMTP) that is extremely vulnerable to abuse and exploitation.
Of course we didn't intend to do this. Microsoft probably didn't intend the scripting "features" of Outlook to be exploited by virii either.
This is a technical problem in need of a technical solution. Laws will have no effect (spammers just move out of the jurisdiction). Smarter spam filters are a good band-aid, but they only mask the problem.
There are plenty of possibilities for building a spam-proof email infrastructure - charging money to receive an email from an unknown sender, forcing senders to perform some expensive action for each recipient, etc. Some of these ideas probably won't work, but some will.
The biggest problem will be encouraging wide-spread adoption of the best solution. It can't just be geeks in the open-source community; we really need the likes of Microsoft, Apple, and co. to push this technology to the masses. (cf the failed adoption of email encryption)
Slashdot Mirror
I don't think these "copy flag bits" are going to work. All broadcasters will simply hard-code the flags to "no copy" all the time. And then we are back to square one...
In order for this to work, Congress must pass a law that enshrines "fair use" as a guaranteed right that must be allowed by any copy-prevention system.
Also, any stream that contains "copy flag bits" must be required to include the expiration date of the copyright. Copy-prevention systems must be required to freely decrypt material that has entered the public domain.
A "copy flag bit" that doesn't also include an expiration date clearly violates the "limited Times" clause of the US Constitution.
Does anyone know if CSS-scrambled DVDs or WMA-scrambled audio streams include a copyright expiration date? I don't think so...
The reverse of this would be even more useful to me - a mapping from DNS to phone number.
That way I could give out my stable, unchanging domain name, instead of my phone number - which changes depending on where I am and who I'm buying phone service from.
Maybe you could store a phone number in a special type of DNS record. Then you'd pay a small fee to a company that provides a toll-free number. People who want to get in touch with me call the toll-free number, type in the domain name, and the call connects. Computer-based phones or future stand-alone phones could let you type the DNS name instead of the phone number.
My best advice for those developing 3D animation software: do 3D animation. Then write the tools you need to do it better.
It may not be that difficult to reverse-engineer an existing program (in the sense of reverse-engineering its general architecture, not necessarily duplicating it bit for bit). I find that the public documentation on Maya and Lightwave is detailed enough to get a very good idea of how their internals are structured.
Yes "dynamic range" is just the range of dark to bright across which the sensor gives you meaningful information.
Photographic negative film has something like 9-10 stops (powers of 2) dynamic range. That means you can record a bright highlight that is ~1000 times brighter than a dark shadow in the same image, and still retain full detail in both.
CCDs are improving quickly, but the ones in most digital cameras today don't have nearly the same dynamic range as film (something like 100:1, but there is a great deal of variation). You can certainly take good photos with these, but you'll have trouble capturing good detail in both bright highlights and dark shadows in a single exposure. You tend to get washed-out uniform highlights and shadows.
Another issue is that amateur digital cameras only give you 8 bits of brightness information per pixel, whereas negative film has something like 12 bits of information. Most pro cameras do give you access to 12 or 16 bits of brightness, but you'll have a hard time handling those images without special software.
When all is said and done, I don't think the reduced dynamic range of CCDs versus film is going to be a major problem for anyone except professional photographers. The shortcomings of low dynamic range only become apparent if you are doing extensive image processing. (such as brightening or darkening the image before printing it)
One last area where CCDs don't do so well is with sharp edges at high resolution. The digital images on the review linked from this article have what I call a "shitty edge" effect - there are dark contours around all of the sharp edges. Granted this could be an artifact of the JPEG compression, but I've seen it in almost all CCD photos and videos. Edges and color transitions should be smooth, like in the film images.
I think the problem is that CCDs do odd things at the individual pixel level - the red/green/blue sensors are not exactly coincident, so the camera needs to do a bit of image processing or filtering to produce a final RGB image; whereas in film the dye layers are exactly on top of each other. You can mitigate this by downsampling the digital image, but then you sacrifice resolution.
I stand corrected - you are right about 1.x vs 2.x. I just got the distinct impression that 2.x was to stay until a long-off "flag day" when enough incompatible changes have been waiting to be worth breaking user-space.
BTW by "ABI version" I specifically mean the kernel-user ABI - i.e. the syscall numbers, their arguments, and expected behavior. Not the kernel-driver ABI, which, as you point out, changes with virtually every release.
The kernel-user ABI has the distinction of being practically the only ABI that has *not* seen incompatible changes in my 3+ years of Linux usage =).
No, as long as Linus is in charge there will never be binary compatibility of modules between minor kernel versions (or even different configurations of a single version, e.g. UP or SMP). Linus considers it too much trouble to be worth the effort.
/proc interfaces. There has been some talk about revising the module loading/unloading process (since the current methods still have some problems), but no action has been taken yet.
AFAIK the new driver model basically puts all drivers in a uniform structure, primarily for the purposes of handling power management (sleep states) uniformly, and of moving towards a simple, standardized layout for
I meant linear in the sense that the single-player game is simply a linear path through all the maps. Also the game has been tweaked out for action/fun rather than realism. (e.g. no M1 Garand)
:[.
1942 claims replayability because of the "smart" AI, but in my experience the AI is basically dumb as dirt
Multiplayer is where it shines, of course - but the net code is pretty awful. I'm not sure the average buyer of 1942 would be persistent enough to actually enjoy on-line play...
I would say that 1942 is a lot more polished than, say, Operation Flashpoint or America's Army. The audio is great, the in-game server browser actually works (a first! although they get serious negative points for pushing you to install Gamespy Arcade - ugh). I'm hoping they will fix the net code in future patches, we'll see... (IMHO they would have been much better off licensing a good engine like Q3A or Torque than baking their own - MOHAA had awesome net play, thanks to the Q3 engine...)
Agreed... The shooter games that EA publishes have been among the simplest and most linear I've played. (thinking of Medal of Honor and Battlefield 1942 here).
On the other hand, they do seem a bit more "polished" than a lot of second-tier shooter releases. (by that I mean the audio is good, and there aren't enough bugs in the first release to make the game seriously unplayable =)
Argh! The first digit in the kernel version number was always meant to indicate the ABI version! They should NOT change it from 2. to 3. unless they intend to make major (backwards-incompatible) changes to the kernel ABI. If they do this then we will lose the second-to-last piece of information in kernel version numbers. (the last piece being the even/odd stable/development thing)
I guess Linus is falling into the same trap as most other free software developers. Already in most software packages, version numbers provide nothing more than an ordered sequence of releases. There is no way to tell just by looking at a version number what ABI/API version is exported, whether it is a stable or development release, etc. Pathetic.
If this law passes, it would be open season for hacking. Just put up a an original two-line poem on your web server. Claim copyright on it. According to the DMCA, when anyone's web browser downloads it, they have made an actionable copy and therefore infringed your copyright. So now you have the right to go and hack them to kingdom come, with no penalty whatsoever!
It would be even better if someone created a central repository of logged copyright infringements, indexed by the source. Want to hack Microsoft or IBM? Just look for a company IP address in the repository.
I should probably defer to the experts on this question; I'm not a NASA engineer =).
My guess- in order to increase the bandwidth, the spacecraft needs to carry a larger, more powerful transmitter. This adds weight and power consumption, two resources that are extremely scarce in spacecraft design.
If you are in low earth orbit, however, it's not impossible to get real-time, high-bandwidth video. One of my clients is a company that specializes in this kind of thing: Ecliptic Enterprises.
The difficult part about taking hi-res images is getting them back to earth. Using the best radio communication technology we have, we can receive only a handful of KB/sec from a remote probe in the inner solar system. In the outer solar system we are limited to more like a couple hundred bytes a second. And then there are overheads, like control commands and non-image science data. If the probe is on a planet then we can only receive when Earth is abobe its horizon. (unless we use a relay satellite...)
I believe modern missions use light compression on the images before transmitting them back, but scientists are naturally reluctant to use any fancy compression algorithms for fear of skewing the data.
Our best hope for the future is optical-wavelength communication, which could theoretically push data rates into megabytes per second.
BTW you want eye candy? Check out my Mars Rover video =).
I believe VirtualDub can read MPEG-1 now, but I don't think it can write them.
MPEG is sort of outside VirtualDub's scope; it is first and foremost an *AVI* editing program (not a general video editing program).
To my knowledge there is no single software package that can handle AVI, Quicktime, and MPEG equally well. (Premiere claims to handle all three, but its Quicktime and MPEG support have serious problems; Apple's Quicktime also claims to handle all three, but its AVI support is severely lacking).
Plus, I don't think it is possible to distribute a free MPEG-2 codec since there are active patents on it... (Apple distributes Quicktime 6 without MPEG-2 support, and makes you pay $20 or $30 extra for it)
Virtual Dub rules. If you do any work with video on Windows, it is essential.
Virtual Dub is much more stable and its interface is much more streamlined than most other free software. Plus it has probably the most robust AVI read/write code ever offered. Out-of-spec files that crash other video programs, Virtual Dub chews 'em up and spits 'em out.
I base my theory on two facts:
1) The GeForce2 hardware is identical to Quadro2 hardware, except for a single resistor. (which you can solder to "morph" your card into the other type - there are instructions for this on several websites)
2) The Quadro2 performs an order of magnitude faster than the GeForce2 on certain specific benchmarks, such as antialiased line drawing. These specific features are used in many CAD applications but not in any games.
Therefore, the driver must be crippling certain features when it thinks it's running on a GeForce 2. So NVIDIA can charge CAD users $600 for essentially the same hardware that a gamer buys for $200... (these prices were when the GeForce2 was first released, of course)
I don't think SGI's old IP is the reason NVIDIA won't release source code. The real reason is that the drivers deliberately cripple certain advanced features on NVIDIA's low-end cards, to force "professional" users to buy their high-end cards.
Remember how the $600 Quadro2 hardware was exactly the same as a $200 GeForce2, except for a tiny little resistor? I'm sure there are a few places in the NVIDIA driver like:
if(user_paid_for_quadro()) {
make_antialiasing_fast();
enable_overlay_planes();
} else {
make_antialiasing_slow();
disable_overlay_planes();
}
So naturally a few days after they release the driver souce, somebody would provide a "magic" version of the driver that makes all of NVIDIA's low-end cards perform just like their high-end cards. Then they wouldn't be able to charge $600 for "pro" video cards anymore...
I'm pretty sure cars are covered by design patents. (which are distinct from "regular" utility patents and copyrights)
This would be really easy to implement also, at least on a PC/software DVD player - you could give the player the ability to read in a text file containing the edits. Then all you need to do is download a tiny EDL file. You'd have to own the original DVD to make any use of it, and I'm pretty sure you could argue that the EDL file is not covered under the DVD's copyright as a derivative work.
Then Clean Flicks et al could open up a website, kind of like CDDB, where you just stick the DVD in, and it automatically downloads the appropriate "clean" edit. (they could charge for each EDL download, or a monthly fee for access to the website).
Of course "Episode I: The Phanom Edit" type stuff would be easy to find also =).
Sophisticated players could look for audio fade-in/fade-out commands in the EDL to hide jumps in the soundtrack where a scene was deleted.
It would be tougher to do this with all-in-one hardware DVD players; maybe you could fit a USB port on one and download the playlist from a PC (yuck), or maybe the player could accept a "smart card" with the EDL on it.
But realistically, I'd expect that the movie studios themselves will eventually realize that they can charge extra if each DVD already comes equipped with a "clean" option. (they already edit for airlines and offer multiple language soundtracks; clean edits can't be THAT much of a stretch).
Yes, it will still be possible to do a digital->analog->digital rip. But I doubt you will see equipment capable of ripping a digital HD signal while preserving any more detail than a regular old SD signal...
Another issue is that, thanks to the DMCA, making or distributing a tool to do this will be a felony. Region-free DVD players are sort of in a grey area, as are Macrovision removers. But DeCSS and "De5C" are unquestionably illegal. You may be able to get them from a website here or there (before MPAA orders them shut down), but you definitely WON'T see any actual companies making these kinds of tools. Which means they will be inaccessible to 99.9% of the population. (remember, you need to rip/crack the HD content to exercise ANY of your fair use rights, like time shifting, making a backup copy, subtitling for foreign language speakers or the hearing-impaired, playing the video on a portable unit, etc... These are things everybody should be able to do, not just hard-core video geeks).
And finally, who is going to be in charge of the encryption keys? If things keep going the way they look like they're going, the US government will mandate 5C copy-prevention for all digital broadcasts. So it will be impossible to get your own content broadcasted, since only the big studios will have the keys.
(here's a thought - if they mandate an encryption system, they should also have to mandate that the public encryption keys be made available to anyone who asks...)
Although I disagree that threaded programs are inherently easier to write than state machine programs, I can understand your point of view. It's probably a matter of personal preference and experience. (yes, Win32 and BeOS both strongly encourage a multithreaded style of programming, but I don't think that decision was made purely on technical merit. Multithreading was the "cool" thing to do back when these APIs were invented...)
If you need an example of AIO in a GUI application - consider Netscape 4 or Mozilla on Mac OS 9. These programs are multithreaded on most operating systems, but since Mac OS 9 has weak support for threads, the Netscape runtime simulates multiple threads using coroutines and AIO. (this is done transparently to code running on top of the runtime, so it still appears to be written in the multithreaded model...)
I use Mozilla and I do notice that it sometimes becomes unresponsive to input while loading a page. But when I boot into Windows, Internet Explorer has no problem loading the same pages without noticeable delays. (not only are other IE windows not blocked, but the one that's loading isn't blocked for long either - so it can't be IE doing all the work in a background thread). I blame inefficient code in Gecko... Pushing the work into a background thread is only a band-aid; it's like pushing a bubble sort algorithm into a background thread when you could just use quicksort and get the same work done much faster.
Existing SD TV sets will not need to be thrown out. All current and proposed HD receivers will provide SD analog outputs, so your existing SD sets will work fine.
The problem is existing HD TV sets that lack a DVI input with 5C copy prevention hardware. The new HD guidelines that Hollywood is working on mandate that NO HD analog outputs are allowed - only SD analog and HD digital (with 5C copy prevention - like CSS for television). So you won't be able to use an older HD TV set with one of these new receivers, since most older HD TV sets only accept analog or unencrypted digital signals.
Hollywood is so intent on getting this standard adopted that they are willing to obsolete most existing HD TV sets. A Disney official has been quoted as saying, "[we care so much about the new HD standard] that we're willing to visit each current home with a HD TV set and replace it with a new [copy-prevented] one..."
The new HD guidelines put forth by Hollywood's "Broadcast Protection" working group are truly disgusting. They mandate precisely what outputs a HD receiver is allowed to provide - SD analog is OK, HD digital (encrypted) is OK, HD analog is NOT OK. Which means the only way to record or manipulate (e.g. subtitle) a digital HD broadcast will be using Hollywood-approved hardware, and conditional on the "copy-prevention" flag in the data stream being turned off. And I'm sure that before long, all HD broadcasters will simply leave all of the "prevention" flags on all the time... (goodbye fair use, goodbye time-shifting, etc...)
I hate those UNIX grognards that come from that school of thought, then try to code GUI applications with only one thread and end up with apps that can't update the GUI while doing I/O
Then they are stupid. I/O can be done asynchronously in a single-threaded program; you just need to use non-blocking I/O (sockets) or AIO (disk).
As for Galeon - the rendering code needs optimization. Rendering in a background thread is NOT going to help. (think: the socket connection to the X server is inherently serialized; if rendering is the bottleneck then the rendering code itself is the problem)
I agree... We recently switched to digital cable here in central NY state (Time Warner). I actually find the MPEG-2 compression artifacts MORE objectionable than regular old analog noise. (especially for the higher numbered channels, which I assume use a lower bitrate than the major networks). Another minus of the digital system is that it takes FOREVER to change channels (1-2 seconds, versus almost instantaneous for analog).
Normally I am of the "use only as many threads as CPUs" school of thought, but I can think of a reason to use 100,000 threads - imagine a large FTP server, or a multi-homed HTTP server, where you need to provide each connected user with his own set of access privileges or filesystem context. A one-thread-per-connection server may be the easiest way to build security into the system.
I think we, the Internet technical community, have to face up to the fact that we fucked up. We committed ourselves to an email system (SMTP) that is extremely vulnerable to abuse and exploitation.
Of course we didn't intend to do this. Microsoft probably didn't intend the scripting "features" of Outlook to be exploited by virii either.
This is a technical problem in need of a technical solution. Laws will have no effect (spammers just move out of the jurisdiction). Smarter spam filters are a good band-aid, but they only mask the problem.
There are plenty of possibilities for building a spam-proof email infrastructure - charging money to receive an email from an unknown sender, forcing senders to perform some expensive action for each recipient, etc. Some of these ideas probably won't work, but some will.
The biggest problem will be encouraging wide-spread adoption of the best solution. It can't just be geeks in the open-source community; we really need the likes of Microsoft, Apple, and co. to push this technology to the masses. (cf the failed adoption of email encryption)