How is passing the letters on to the students an invasion of privacy?
If the university were to pass on the name of the student they believe was the one using the network at a specific IP address at a specific time, then perhaps that would be just such an invasion of privacy. But I don't see how telling the student that they suspect was using that IP address then about the letter, or passing a copy of the letter to them (surely the university would keep a copy for their "files") invades the student's privacy. If that was the only action done, the student could choose to contact the RIAA, or choose to ignore it. Something else must be implied by "passing the letter on"... such as passing names or even SSN to the RIAA?
ATI does produce drivers. The problem is, they don't release the source code so we can fix them and make them work without exposing ourselves to certain draconian laws.
I very much doubt publishing the interface specs is going to help ATI and Intel.
Actually, it can. It would reveal the specialized types of operations the video card can do. My alternative idea is not about exposing these specialized operations. Instead, it is about encapsulating them in messages that can utlize high speed direct memory access (what their interface is probably already in part doing, anyway) in a way where the OS and video card driver simply has no need to be concerned with the video operations (at least for "fully authorized" programs like the game being played, or the X server when doing "real work" if on Linux).
I agree with you (not with FireFury03) that opening up the interface they use now would be giving up at least some of their trade secret. I don't suggest that. Instead, I suggest using the message transport model. Within that they can still use their proprietary special operations, but do it in an interface where the layer of the system doing the access controls doesn't need to care about interpreting or understanding those messages. It would just know that the game is authorized for raw message access (e.g. the OS won't restrict some things like making sure an app is not reloading the firmware RAM) so anything the game sends goes to the video card. It would all be bulk direct memory transfers and would go faster over the bus than the tricky register juggling that happens now. A proprietary message may actually be a set of register IDs and values to load behind the scenes. But the OS won't need to care about that... it's just between the game program and the video card.
And this will eliminate one of the hurdles to game makers making games for Linux/BSD (the game still closed source, but can run on the open source OS). In fact it may well work under Windows emulation, anyway.
Do you honestly expect nVidia to give up trade secrets...
No, I do not. Your suggestion of that indicates that either you don't grok what I'm talking about, or I'm just bad at explaining it (or both). I'll try another way.
Let them keep all the proprietary stuff inside the card. A standardized interface could be message based (request/response). The kernel/OS driver would be little more than a tool to shuffle messages to and fro. The graphical libraries would form the messages from application API calls.
Then for gaming boosts, a set of specialized graphical operations that better coincide with what games need would be defined. The game developers could get this info under NDA from the video card maker. The game program would likely bypass libraries and supply whatever code it needs for itself. It would send one message to the video card and request the manufacturer and model ID and use that to select or activate the appropriate code to handle that card best. Most of the functions would be standardized, but specialized ones that games need can still be created by the card/chipset manufacturer and games could use those. This would still be requests sent in messages, utilizing direct unbuffered message queueing (e.g. the OS doesn't copy the message, but rather, schedules direct memory access I/O for the message right where it is in the game memory location). The OS won't care if the messages are the standard ones or the proprietary ones. It will just pass them along. Then the video card will do what it needs to do.
This gets the best of both worlds. Games can still have the specialized high performance graphical ops they want (if the video card in use has them... they find out and use what is there, if they have that info from the manufacturers). The OS stands back and lets it happen, doing very little to just schedule the physical I/O accesses. Then when it's time to quit playing games and get real work done, one can boot into a safe OS and have a video card that still does very well with the standardized set of graphics card requests usable on any OS (because again, the OS just passes messages and the real work is done by the video card and the applications). The one exception would be some limited knowledge of the messages in the OS so the OS can display things itself, especially when booting up. That, plus a standard VGA compatibility so legacy OSes can also be used.
You are ignoring the fact that some of us are more interested in open 3D drivers than performance.
Actually, by moving the graphical work to an on-the-card specialized graphics processor (or two), and limiting the bus bandwidth usage to just the informational aspect of what the application is requesting be done in graphics, then you can get both a big boost in graphics performance and an open interface at the same time (if that new interface is designed by someone without proprietary vested interests).
Consider the case of watching a movie. Why not have the graphics card itself decompressing the MPEG contents? Or would you rather your general purpose CPU be doing that and try to bottleneck your bus bandwidth pushing raw uncompressed video out? Of course passing the MPEG over the bus and letting the graphics card to the crunching work makes sense, if you have a video card that is capable (and quite many are).
Keep in mind how much of a modern graphics card's abilities are now located in software.
Yes. But does that mean software that runs on a CPU on the graphics card, or software that runs on the system CPU, stealing cycles from it? The latter is what some manufacturers are doing, and should not be doing. For software that runs on the graphics card CPU, it doesn't need to run either in kernel space or user space... that's another space we can call "hardware space". It has no access to kernel APIs or user APIs, nor should it have that.
Imagine for a moment if X Windows were the universal graphical system on (nearly) call computers. It isn't due to the likes of Microsoft, but just imagine it were. What we could have is a graphics card with a CPU on the card that implements an X Windows server. Then all you need is a way to shuffle all the messages that go between applications and X across the bus between system CPU and graphics card.
Now X might not be the best interface design, and certainly would not be for gaming, a better design certainly can be made. But even X would be faster than it is now with the server on the card (quite doable today). And still, the window manager would run in user space.
I wouldn't be surprised in the least if the interface between CPU and graphics card was a tightly guarded secret - main bus bandwidth, and bandwidth in general, is one of the major bottlenecks on graphics systems right now.
That interface should be nothing more than the information of what the system and applications expect the graphics card to display, an encapsulation protocol to organize it into messages and responses, and a basic way to stream it across the bus (like PCI-Express x16, for an example with high performance). Those messages may possibly be a reflection of the graphical API calls done by the applications.
... those restrictions would either have to be moved into hardware (expensive) or disabled (causes horrific problems with the FCC.)
We're well past the point where hardware interfaces can be described in half a dozen pages. We're well past the point where "hardware devices" even exist entirely in hardware. Most interesting hardware devices have complex interfaces that depend on functioning backend software.
That is certainly something that is happening. But it most certainly is not something that is necessary. What we have these days in designs are the result of companies trying to cut their costs with the consumers be damned. These are bad designs, not so much because they steal CPU power from the consumer's computer, but more so because they create these massively complex interfaces that keep changing all the time, and driver code that is so buggy it is frequently the source of systemwide crashes or data corruption. At least if that buggy code is moved into a process, it can do its thing without taking down the whole system.
But we shouldn't have to be doing that. The hardware specific code should be inside the hardware, running on the CPU that comes as part of that hardware. Upgrades can be provided by the system CPU as a checksummed and, if necessary, cryptographically signed, blob (via a unified firmware image upload interface design that all devices should share that includes device match checks to be sure the correct image is loaded). Then maybe we'll start getting some real value add out of things like video cards, instead of getting cards that result in a net loss of CPU power when added in.
Nicely put. I particularly enjoyed ". . . and they consistently appear to have mistaken their windowless cubicles for Olympus/Valhalla." I hope it's okay if I use that:).
You better be careful. Read the notice on all Slashdot pages:
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster.
So don't you think you ought to get permission first, especially if you are residing in University of Kansas dorms?:-)
This is a state funded school. Residents of the state should have equal and fair access. That should include due process when there is an accusation of wrong doing that would justify reduction or denial of access.
Will an innocent person who was not doing any infringement of copyright, but got caught up in the school's lack of due process, and was unable to investigate the failure of the school's insecure network to construct proof that they were innocent in the face of mere accusation of guilt (because someone else managed to crack the system and fake their MAC address), in just 5 business days... get equivalent state financial funding to attend another school that doesn't have the kinds of draconian processes that would make Adolf Hitler and Saddam Hussein proud?
I could understand your counter-argument in many contexts. But for a notice issued during the academic term, students would generally not be taking vacation. Maybe if the notice was issued between semesters when the target of the notice was away. Possibly even during finals week. But there are plenty of good arguments against their process; this one just doesn't fly in this situation.
There are a few things fundamentally wrong with what you are pointing out.
First of all, by calling this an appeal, it already presumes "guilt by accusation" (by a third party which already has a well known reputation of making meritless claims). Where's the due process in this?
Only 5 days to prepare an appeal... or even an initial defense? That is just utterly stupid. That would be stupid even as a limit for merely filing a notice of intent to defend.
It's one thing for the University to knee-jerk and just assume you are guilty upon receiving a notice that merely has a reference to an IP address and time that their records indicate you were using, and cut off your access until such time as you make a claim that something is wrong and proceed with steps to defend. But to completely cut off all avenues of defense and appeal in such a short time frame? That's what's really wrong here.
I do believe that the majority of students who will be facing this probably are guilty. But as we have seen, there are times when things go wrong. The RIAA is well known to have simply not checked their evidence at all, and crank out these pre-litigation letters like a spammer cranks out sex pill offers.
And universities are a place where absolute security of who is using which IP address when has not been considered that important of an issue. These methods are not cryptographically secure, and are easy to crack. MAC addresses can be faked (works especially well when the computer that really has that MAC address is off). So what method does U of K use to ensure there is absolutely no way possible for someone who is stealing unauthorized copyrighted content to fake someone else's MAC address? This is not a high-tech leader school here.
I take it you have not been to a college/university computer lab lately. If you can even get the junk computers to work right, and run the OS you need, is it even convenient at all (e.g. open 24 hours a day, and always has enough seats for all the needs).
While a bit draconian, at least Ohio University and Stanford have solutions that treat the "innocent until proven guilty" fairly. The University of Kansas would make Adolf Hitler proud.
This still requires discovery. The university expects students who did not actually do any infringement to figure it out, in 5 business days, without being able to investigate the real source of error? That's not an appeal. That's just stupidity.
It depends on your definition of HD. If you speak of what can go over the air (720p60 or 1080i30), you probably need about what is used over the air, 18 to 20 mbps (after figuring in protocol overheads and such). If you want really good HD (1080p60) that cable and satellite could choose to offer if they wanted to use the extra bandwidth, then double that to 36-40. But if you minimize the definition of HD, as the broadband providers are likely to ask for, at say 720p24, then we're talking about a measly 7.2 to 8 mbps, or possibly less if they demonstrate hypercompressed (and ugly) video. That's all with MPEG-2 (what over the air digital will be using in ATSC). But broadband could use MPEG-4 which does better (better quality in less bandwidth) if you believe the proponents.
IMHO a specific number needs to be established. I'd go with "basic broadband" at 18 mbps down and 3 mbps up, "premium broadband" at 48 mbps down and 8 mbps up, and "ultimate broadband" at 120 mbps down and 20 mbps up. Note that copper pair may not be able to handle this. Fiber is the way to go.
Comcast's technician told him he knew "nothing about *&@#$ing Macs,"eventually disappearing into his truck.
He doesn't need to know anything about a Mac. He needs to know how to fix or replace the *&#$ing modem. Then if he wants to test it to be sure it works, just whip out his *&#$ing laptop that has the *&#$ing Comcrap software on it.
It's also wrong for the RIAA to... "prosecute" is the wrong word, here... sue people who actually do have the means to commit copyright infringement but choose not to do so... when the RIAA has no evidence to suggest that they have done so. And it's wrong for the RIAA to do some of the other shenanigans they've been doing. I'm glad to see at least some judges understand the importance of their role.
But within like 3 weeks of them becoming AT&T they've turned into AT&T. Bad service, bad policies, bad politics. It's like the AT&T trademark requires a company to be assholes and give out terrible service.
You got that right. That's why we call them Assholes Through & Through.
I tried to download the paper. WTF kind of URL is that? There is a huge ID string in there. I can't believe they need that many bits to distinctly identify each downloader. I wonder what kind of private info they have discovered about me and are encoding in that thing? Why can't they just have a normal hyperlink if they aren't tracking people?
There plenty of compelling reason to ditch NTSC. There has been for decades. It's only in the past several years that a substantially better approach is available. ATSC (as well as DVB where that is used) allows the spectrum to be more efficiently used. If you look at a spectrum analyzer plot of an NTSC signal in a 6 MHz channel, it's totally dominated by the carrier that is 1.25 MHz above the lower edge of the channel. Video information looks like some grass growing along the bottom edge (especially if you use one with a green colored scope). There's a small blip and fuzzy area around the color subcarrier 4.829545 MHz above the lower edge. And finally, you can see a bit of the audio subcarrier poking its head above ground at 5.75 MHz above the lower edge. Most of the power in transmitting is wasted in the carriers that really carry nothing. Real information is in the sidebands, which are spread out but don't have any redundancy. Contrast that with ATSC which looks like the grass has grown to a forest (that's all information) and widened to nearly fill out the entire 6 MHz channel. Look closely where the forest slopes down to the lower edge and you can see a small blip down near the ground level for the pilot carrier (which is weaker than all the information signals). That's really the 8-VSB modulation taking place. DVB's COFDM is not much different (the forest of frequencies is a little flatter but the total waveform is a little more bumpy). It's an efficient way to carrier information over a fixed RF channel. That combined with MPEG compression, gives you high definition, extra program subchannels, and extended range for the same power level (in the USA, digital power levels will be lower so stations end up with about the same coverage as they had in analog).
But most places like that are rural areas where FIOS isn't being installed anyway.
I used to live in a dense urban area of a major city. I now live in a rural area. The power went out more often in the city (including spectacular high voltage line faults a few dozen times on exactly the same pole). Where I live now, the power goes out maybe twice a year, and both of the last two times were not even during bad weather.
My cable does go out an average of about twice a month.
Sure, the chances of it getting through do seem to be daunting. But I think we need to try, and try again, and keep trying, through Congress, until we can get this or something like it moving forward. As I understand it, the original breakup was some 20+ years in the making, on again and off again, in Congress and in the courts. Too bad it actually happened when it did. If it had been put off another decade or so, the correct way to do the breakup might have been clear.
Slashdot Mirror
How is passing the letters on to the students an invasion of privacy?
If the university were to pass on the name of the student they believe was the one using the network at a specific IP address at a specific time, then perhaps that would be just such an invasion of privacy. But I don't see how telling the student that they suspect was using that IP address then about the letter, or passing a copy of the letter to them (surely the university would keep a copy for their "files") invades the student's privacy. If that was the only action done, the student could choose to contact the RIAA, or choose to ignore it. Something else must be implied by "passing the letter on" ... such as passing names or even SSN to the RIAA?
ATI does produce drivers. The problem is, they don't release the source code so we can fix them and make them work without exposing ourselves to certain draconian laws.
Actually, it can. It would reveal the specialized types of operations the video card can do. My alternative idea is not about exposing these specialized operations. Instead, it is about encapsulating them in messages that can utlize high speed direct memory access (what their interface is probably already in part doing, anyway) in a way where the OS and video card driver simply has no need to be concerned with the video operations (at least for "fully authorized" programs like the game being played, or the X server when doing "real work" if on Linux).
I agree with you (not with FireFury03) that opening up the interface they use now would be giving up at least some of their trade secret. I don't suggest that. Instead, I suggest using the message transport model. Within that they can still use their proprietary special operations, but do it in an interface where the layer of the system doing the access controls doesn't need to care about interpreting or understanding those messages. It would just know that the game is authorized for raw message access (e.g. the OS won't restrict some things like making sure an app is not reloading the firmware RAM) so anything the game sends goes to the video card. It would all be bulk direct memory transfers and would go faster over the bus than the tricky register juggling that happens now. A proprietary message may actually be a set of register IDs and values to load behind the scenes. But the OS won't need to care about that ... it's just between the game program and the video card.
And this will eliminate one of the hurdles to game makers making games for Linux/BSD (the game still closed source, but can run on the open source OS). In fact it may well work under Windows emulation, anyway.
No, I do not. Your suggestion of that indicates that either you don't grok what I'm talking about, or I'm just bad at explaining it (or both). I'll try another way.
Let them keep all the proprietary stuff inside the card. A standardized interface could be message based (request/response). The kernel/OS driver would be little more than a tool to shuffle messages to and fro. The graphical libraries would form the messages from application API calls.
Then for gaming boosts, a set of specialized graphical operations that better coincide with what games need would be defined. The game developers could get this info under NDA from the video card maker. The game program would likely bypass libraries and supply whatever code it needs for itself. It would send one message to the video card and request the manufacturer and model ID and use that to select or activate the appropriate code to handle that card best. Most of the functions would be standardized, but specialized ones that games need can still be created by the card/chipset manufacturer and games could use those. This would still be requests sent in messages, utilizing direct unbuffered message queueing (e.g. the OS doesn't copy the message, but rather, schedules direct memory access I/O for the message right where it is in the game memory location). The OS won't care if the messages are the standard ones or the proprietary ones. It will just pass them along. Then the video card will do what it needs to do.
This gets the best of both worlds. Games can still have the specialized high performance graphical ops they want (if the video card in use has them ... they find out and use what is there, if they have that info from the manufacturers). The OS stands back and lets it happen, doing very little to just schedule the physical I/O accesses. Then when it's time to quit playing games and get real work done, one can boot into a safe OS and have a video card that still does very well with the standardized set of graphics card requests usable on any OS (because again, the OS just passes messages and the real work is done by the video card and the applications). The one exception would be some limited knowledge of the messages in the OS so the OS can display things itself, especially when booting up. That, plus a standard VGA compatibility so legacy OSes can also be used.
Actually, by moving the graphical work to an on-the-card specialized graphics processor (or two), and limiting the bus bandwidth usage to just the informational aspect of what the application is requesting be done in graphics, then you can get both a big boost in graphics performance and an open interface at the same time (if that new interface is designed by someone without proprietary vested interests).
Consider the case of watching a movie. Why not have the graphics card itself decompressing the MPEG contents? Or would you rather your general purpose CPU be doing that and try to bottleneck your bus bandwidth pushing raw uncompressed video out? Of course passing the MPEG over the bus and letting the graphics card to the crunching work makes sense, if you have a video card that is capable (and quite many are).
You are right. But that doesn't make it right.
Yes. But does that mean software that runs on a CPU on the graphics card, or software that runs on the system CPU, stealing cycles from it? The latter is what some manufacturers are doing, and should not be doing. For software that runs on the graphics card CPU, it doesn't need to run either in kernel space or user space ... that's another space we can call "hardware space". It has no access to kernel APIs or user APIs, nor should it have that.
Imagine for a moment if X Windows were the universal graphical system on (nearly) call computers. It isn't due to the likes of Microsoft, but just imagine it were. What we could have is a graphics card with a CPU on the card that implements an X Windows server. Then all you need is a way to shuffle all the messages that go between applications and X across the bus between system CPU and graphics card.
Now X might not be the best interface design, and certainly would not be for gaming, a better design certainly can be made. But even X would be faster than it is now with the server on the card (quite doable today). And still, the window manager would run in user space.
That interface should be nothing more than the information of what the system and applications expect the graphics card to display, an encapsulation protocol to organize it into messages and responses, and a basic way to stream it across the bus (like PCI-Express x16, for an example with high performance). Those messages may possibly be a reflection of the graphical API calls done by the applications.
What do you think is happening now with quite a number of wireless routers being booted (or boosted) with Linux or BSD on them?
That is certainly something that is happening. But it most certainly is not something that is necessary. What we have these days in designs are the result of companies trying to cut their costs with the consumers be damned. These are bad designs, not so much because they steal CPU power from the consumer's computer, but more so because they create these massively complex interfaces that keep changing all the time, and driver code that is so buggy it is frequently the source of systemwide crashes or data corruption. At least if that buggy code is moved into a process, it can do its thing without taking down the whole system.
But we shouldn't have to be doing that. The hardware specific code should be inside the hardware, running on the CPU that comes as part of that hardware. Upgrades can be provided by the system CPU as a checksummed and, if necessary, cryptographically signed, blob (via a unified firmware image upload interface design that all devices should share that includes device match checks to be sure the correct image is loaded). Then maybe we'll start getting some real value add out of things like video cards, instead of getting cards that result in a net loss of CPU power when added in.
You better be careful. Read the notice on all Slashdot pages:
So don't you think you ought to get permission first, especially if you are residing in University of Kansas dorms? :-)
This is a state funded school. Residents of the state should have equal and fair access. That should include due process when there is an accusation of wrong doing that would justify reduction or denial of access.
Will an innocent person who was not doing any infringement of copyright, but got caught up in the school's lack of due process, and was unable to investigate the failure of the school's insecure network to construct proof that they were innocent in the face of mere accusation of guilt (because someone else managed to crack the system and fake their MAC address), in just 5 business days ... get equivalent state financial funding to attend another school that doesn't have the kinds of draconian processes that would make Adolf Hitler and Saddam Hussein proud?
I could understand your counter-argument in many contexts. But for a notice issued during the academic term, students would generally not be taking vacation. Maybe if the notice was issued between semesters when the target of the notice was away. Possibly even during finals week. But there are plenty of good arguments against their process; this one just doesn't fly in this situation.
There are a few things fundamentally wrong with what you are pointing out.
First of all, by calling this an appeal, it already presumes "guilt by accusation" (by a third party which already has a well known reputation of making meritless claims). Where's the due process in this?
Only 5 days to prepare an appeal ... or even an initial defense? That is just utterly stupid. That would be stupid even as a limit for merely filing a notice of intent to defend.
It's one thing for the University to knee-jerk and just assume you are guilty upon receiving a notice that merely has a reference to an IP address and time that their records indicate you were using, and cut off your access until such time as you make a claim that something is wrong and proceed with steps to defend. But to completely cut off all avenues of defense and appeal in such a short time frame? That's what's really wrong here.
I do believe that the majority of students who will be facing this probably are guilty. But as we have seen, there are times when things go wrong. The RIAA is well known to have simply not checked their evidence at all, and crank out these pre-litigation letters like a spammer cranks out sex pill offers.
And universities are a place where absolute security of who is using which IP address when has not been considered that important of an issue. These methods are not cryptographically secure, and are easy to crack. MAC addresses can be faked (works especially well when the computer that really has that MAC address is off). So what method does U of K use to ensure there is absolutely no way possible for someone who is stealing unauthorized copyrighted content to fake someone else's MAC address? This is not a high-tech leader school here.
I take it you have not been to a college/university computer lab lately. If you can even get the junk computers to work right, and run the OS you need, is it even convenient at all (e.g. open 24 hours a day, and always has enough seats for all the needs).
While a bit draconian, at least Ohio University and Stanford have solutions that treat the "innocent until proven guilty" fairly. The University of Kansas would make Adolf Hitler proud.
This still requires discovery. The university expects students who did not actually do any infringement to figure it out, in 5 business days, without being able to investigate the real source of error? That's not an appeal. That's just stupidity.
It depends on your definition of HD. If you speak of what can go over the air (720p60 or 1080i30), you probably need about what is used over the air, 18 to 20 mbps (after figuring in protocol overheads and such). If you want really good HD (1080p60) that cable and satellite could choose to offer if they wanted to use the extra bandwidth, then double that to 36-40. But if you minimize the definition of HD, as the broadband providers are likely to ask for, at say 720p24, then we're talking about a measly 7.2 to 8 mbps, or possibly less if they demonstrate hypercompressed (and ugly) video. That's all with MPEG-2 (what over the air digital will be using in ATSC). But broadband could use MPEG-4 which does better (better quality in less bandwidth) if you believe the proponents.
IMHO a specific number needs to be established. I'd go with "basic broadband" at 18 mbps down and 3 mbps up, "premium broadband" at 48 mbps down and 8 mbps up, and "ultimate broadband" at 120 mbps down and 20 mbps up. Note that copper pair may not be able to handle this. Fiber is the way to go.
... as the mother of all distributions: Skapareware 0.0.1
... then it would have XP instead. That would have made it an even better deal.
From TFA:
He doesn't need to know anything about a Mac. He needs to know how to fix or replace the *&#$ing modem. Then if he wants to test it to be sure it works, just whip out his *&#$ing laptop that has the *&#$ing Comcrap software on it.
It's also wrong for the RIAA to ... "prosecute" is the wrong word, here ... sue people who actually do have the means to commit copyright infringement but choose not to do so ... when the RIAA has no evidence to suggest that they have done so. And it's wrong for the RIAA to do some of the other shenanigans they've been doing. I'm glad to see at least some judges understand the importance of their role.
You got that right. That's why we call them Assholes Through & Through.
... iPhone?
I tried to download the paper. WTF kind of URL is that? There is a huge ID string in there. I can't believe they need that many bits to distinctly identify each downloader. I wonder what kind of private info they have discovered about me and are encoding in that thing? Why can't they just have a normal hyperlink if they aren't tracking people?
There plenty of compelling reason to ditch NTSC. There has been for decades. It's only in the past several years that a substantially better approach is available. ATSC (as well as DVB where that is used) allows the spectrum to be more efficiently used. If you look at a spectrum analyzer plot of an NTSC signal in a 6 MHz channel, it's totally dominated by the carrier that is 1.25 MHz above the lower edge of the channel. Video information looks like some grass growing along the bottom edge (especially if you use one with a green colored scope). There's a small blip and fuzzy area around the color subcarrier 4.829545 MHz above the lower edge. And finally, you can see a bit of the audio subcarrier poking its head above ground at 5.75 MHz above the lower edge. Most of the power in transmitting is wasted in the carriers that really carry nothing. Real information is in the sidebands, which are spread out but don't have any redundancy. Contrast that with ATSC which looks like the grass has grown to a forest (that's all information) and widened to nearly fill out the entire 6 MHz channel. Look closely where the forest slopes down to the lower edge and you can see a small blip down near the ground level for the pilot carrier (which is weaker than all the information signals). That's really the 8-VSB modulation taking place. DVB's COFDM is not much different (the forest of frequencies is a little flatter but the total waveform is a little more bumpy). It's an efficient way to carrier information over a fixed RF channel. That combined with MPEG compression, gives you high definition, extra program subchannels, and extended range for the same power level (in the USA, digital power levels will be lower so stations end up with about the same coverage as they had in analog).
I used to live in a dense urban area of a major city. I now live in a rural area. The power went out more often in the city (including spectacular high voltage line faults a few dozen times on exactly the same pole). Where I live now, the power goes out maybe twice a year, and both of the last two times were not even during bad weather.
My cable does go out an average of about twice a month.
Sure, the chances of it getting through do seem to be daunting. But I think we need to try, and try again, and keep trying, through Congress, until we can get this or something like it moving forward. As I understand it, the original breakup was some 20+ years in the making, on again and off again, in Congress and in the courts. Too bad it actually happened when it did. If it had been put off another decade or so, the correct way to do the breakup might have been clear.