I messed-up the particular organization that decides on the narrow set of anti-circumvention exemptions. Since 2000 I believe we have only gained one new exemption (unlock cell phones) and lost about ten.
I think that a work around was already discovered. It entailed to first use setacl to modify the permissions on some registry entries and then to modify those and other registry entries.
I had a '81 19" Trinitron from the time I was a kid until just two years ago. The thing was indestructible. One time I was carrying it with a friend and it slipped from his hands and he tried to get it back up by kicking it up. It went way up and then down onto asphalt, and worked for years after that just the same as always. I think my parents paid $800 for it. I loved the individual fine tune pots for each channel.
I actually ran into the broadcast flag on a few occasions with using a DTV converter box and VCR. The issues that happened were of two flavors. One was that a broadcaster did use the flag (happened with two broadcasters to me) and the other case was a commercial would have the flag and then only a later commercial that happened to not have the flag would remove it. In the case of my using a DTV box and VCR what would happen is that the DTV box then would use the macrovision cp scheme, so the image on the TV was fine but what was recorded would fade in and out of dark b&w and nothing. At one point I already had WMC and two tuners and I can see when a program is tagged with the broadcast flag it says restricted or some such in the info of the program. I was able to record and watch the program in WMC. The way that I understand it is that broadcasters are allowed to still use the broadcast flag but that the FCC no longer requires equipment to respect it. I was unlucky and got some of the 2nd gen DTV tuner boxes that were made before the FCC ruled and so they did what was expected. Maybe there are DTV boxes now that never use macrovision or there might be ones that never did honor the broadcast flag at all.
I now live 50 to 60 miles out from the two cities I get TV (both digital and analog) from with no problems what so ever. I used to live 100+ miles from the two nearest cities and some repeaters about 50 miles away. I had no problems, though we did have a motorized antenna that made flipping through channels not something you did. You need to know what you are doing. I have a large good roof top antenna oriented properly, with good thick shielded coax, and two high quality amps, all fed to 3 TVs in the house. It works great but most people do not have the motivation or know how to get it right.
This is sort of a funny thing related to the story itself, but FSC came about due to the patents that RCA/NBC had at the time. In fact RCA did a lot of convoluted things in its actual implementation over the years to sidestep others' patents in the area and the situation only got reasonable in the '70s.
Low VHF is susceptible to interference, particualrly impulse noise, but guess what DVB-T at those frequencies is too. 8VSB is much better about dealing with it than any option under DVB. The other issue is that there have been RF modulator boxes that commonly used channels 2, 3, or 4 many stations broadcasting on 2, 3, 4, or 5 do it at lower power (well those do get to propagate better at low power) so the noise is more of a problem. That said I was and am able to get channel 2 NTSC and channel 3 ATSC from 50+ miles out and distribute it to 3 TVs and two recorders with very good results using a good rooftop antenna, thick shielded coax, and two amps. I have read the same complaints you have and I think that most people don't know what they are doing.
The other thing is that you mentioned DVB-T2. That really is a lost cause except for possible Norway and other countries that have been slow in the DTV roll-out. It would be such a PITA to have people upgrade yet again that it simply will not gain universal traction for OTA.
I am 50-60 miles away from the cities that I get OTA TV from. I never had much trouble with getting good TV signal and distributing it to three TVs in the house. I do have a large antenna pointed at the most troublesome VHF tower and good thick shielded coax and two amps. Every station but one will be UHF for me in a few days. I have now DTV tuners at all of the TVs. I only occasionally have trouble under heavy rain or wind of the current low power VHF station dropping out occasionally. It will move to UHF soon.
The other thing you did in your list is that the vast majority of the countries that you have listed have population only in certain dense regions. Then there are the tiny ones. In the US a large number of people do actually live in those low density areas served by repeaters from smaller cities. The signals do need to travel that far and people have 20-40 ft towers or whips to get TV.
Almost any modern system, to the CPU, a 32-bit aligned access is atomic. If they were just reading the global array, there is no need to use a lock, in fact this is a placebo lock, that adds unnecessary burden on the memory or reservation system. It is common for realtime that the global data is only modified at certain times when readers are not running.
Sometimes your 15 year senior programmers have earned their salt, in fact they usually have. I would like to see your fancy C++ with templates stuff compile onto some of the proprietary toolkits I have seen for small ARM and gate array systems. Writing code that uses a number of fixed sized simple data structures all written in C makes it very easy to port it to embedded systems. The moment you use something that seems as innocuous as C++ exceptions, you're in a world of hurt the moment you step out of GCC, VC++, SUNWpro, or XLC.
Here is one story. There is a fellow that likes to run C++ stuff he has written on our systems. The smallest config we run with that stuff has 16MB RAM and a 200MHz processor and we use GCC, so it's okay. One day he wanted to run on a new bigger system, so I enabled the C++ run time libs, this added 17s to the boot and used dozens of MB of RAM, but whatever this was in a system with 128 MB RAM and 1GHZ cpu. Then we got newer boards like those but with 256 MB RAM and 1.3GHz cpu and gigabit. Occasionally the boards would reset. It turned-out that due to all the extra resources and the dynamic sizing his code used, every now and then the HW watchdog timer was not getting twiddled (0.5s on a system with realtime requirements of various things in some cases of 4ms) and the board was being reset.
Sure RAM is cheap, plentiful, and fast, but it is a shared resource which then gets paged to slow magnetic storage once your system crosses a magic line. Once you use a lot of VADDR you start needing to do more TLB lookups. And there are the other more limited shared resources to contend with, TLB caches and memory caches which are hard to upgrade. In multiprocessors you are also using memory bandwidth when cache lines are dirtied.
I think there are a lot of copy constructors called when using STL that a lot of people do not expect. The algorithms themselves tend to be well implemented though. None of that really has much to do about OO though, templates with structs with no member functions and lots of casting of void * could have been used instead.
I have realized that I will have been working as a dev for ten years now in four days. I've worked at a few places and I think that the reason for this is pretty straight forward, poor benchmarks used poorly.
We have all heard the mantra about optimizing early is evil but there are two issues to contend with. You get to a crunch time towards the end and then there is no time to address performance issues in every project. By that time so much code is written that you cannot address the performance issues in the most effective way, thinking about what algorithm to use in the dataset that ends-up being the common case. So instead some profiling work gets done and the code goes out the door.
So for success you need to have some performance measurements even early on. The problem is that in that case you end-up with some benchmarks that don't measure the right thing (that is what you discover near the end) or you have worthless benchmarks that suffer too much from not being reproducible, taking too long to run, or not giving the dev any idea of where the performance problem really is.
So what ends-up happening is that only after the code base has been around for a while and you get to rev n + 1 is there any real handle on any of this performance stuff. But often what ends-up happening is that project management values feature additions so as long as no single benchmark decreases by more than 2-5% and the overall performance does not decrease by more than 15% compared to the pre feature build, it gets the okay. Then a milestone arrives and there is no time again for systematic performance work and it ships as is.
The right approach would be at that stage to not allow a new feature unless the overall benchmark does not improve by 2% and to also benchmark your competitors as well but that just does not happen except in the very rare good groups sadly.
To be fair that money we loaned to the banks, GM, Chrysler, and AIG is money that we borrowed from China or will need to print later. I hope those we paid to repay their obligations, and I hope we repay our obligations, maybe we will even come out ahead, but it's not a sure thing by far.
As an aside I had to code for an embedded system with 4MB DRAM and 1MB FLASH where about half of the FLASH was already consumed by the loader, test, and config code from the vendor. I actually tried to put a portion of the code on the FLASH but there was a penalty of 4us per word on each access since it was on an IO bus and the FLASH was really slow. In the end I used 2MB of off board SRAM (battery backed and cksum verified on boot) and that had a penalty of only 1us per access. I get very annoyed when people from on high decide that now we need new functionality in the system and certainly anything will have the resources to support something so trivial to add. Eventually you die the death of a hundred cuts. Those boards are retired now, instead the smallest ones I support are 16MB DRAM, 4MB Flash, and 4MB SRAM, again as new 'requirements' got added over the years.
I am actually impressed that you got your solitaire in 650K or so since it does so much. My version was on a Casio graphing calculator.
I get annoyed when people do not consider: what does my software do, what is reasonable in time and space
Many people decide as long as it is always below some arbitrary number, that is good enough.
They fail to realize that DRAM is not the only resource nor that they share it with all other processes. In particular a much more limited shared resource is the L1 cache. When software gets bloated by an order of magnitude or two it effects the responsiveness of the system as a whole and the narrow view that some people take bothers me.
Yes 50-60% is pretty much the norm. The French do something clever in a number of plants though. They use excess to pump water into a reservoir and then later when they need extra they release the water to turn turbines to generate more. They essentially use the reservoir as a huge battery. It is not too terribly efficient but it lets you get above about 60% or so for nuclear power in your grid. Pretty much everywhere else coal plants are used to fill out the grid.
But this is solitaire. When I was a kid I wrote a version of solitaire in less than 300 lines. This should not be a 2+ MB program, and see he did it around 650K of object code.
I use a nearly 7 year old eMac running 10.5.7 as my primary computer at home. My wife does as well. We and my kids have two newer PCs as well but one is used mainly for RCT3 and WMC, while the other for web browsing (since flash is so horrible at this point on the eMac). What has kept the eMac so well used is iDVD, iMovie, and iPhoto (also macports for me). I have FreeBSD on the WMC machine but it is inconvenient since the tuners are almost always going to or are recording something. The BIOS in the web browsing one does crazy stuff when I use USB keyboard and mouse (I have to since the PS/2 ports are borken) where inb to the controller ports reflects what would have been seen if there was a PS/2 keyboard and mouse. I have no way to disable that in the BIOS and then FreeBSD thinks I have two mice and keyboards. So I do not compile the PS/2 stuff into the kernel and then the USB keyboard and mouse do not work half of the time until I unplug and plug them in again, and then the USB mouse keeps disconnecting and reconnecting periodically, and then I gave-up. So because of all that the workhorse computer at home is nearly 7 years old. It also has a DVD drive old enough that it lets us read Polish and US DVDs.
Slashdot Mirror
You're right it's not the FCC but rather the LOC:
http://www.copyright.gov/1201/
I messed-up the particular organization that decides on the narrow set of anti-circumvention exemptions. Since 2000 I believe we have only gained one new exemption (unlock cell phones) and lost about ten.
http://en.wikipedia.org/wiki/DMCA#Anti-circumvention_exemptions
I guess it makes sense if you want exceptionally fast javascript, but still disappointing.
Specific listed exceptions that the FCC adds or removes to every so often. This is not one of them, stupid DMCA.
I think that a work around was already discovered. It entailed to first use setacl to modify the permissions on some registry entries and then to modify those and other registry entries.
ffmpeg-mt does a good enough job if you have a machine with few decent cores. CoreAVC is can be run on even lesser hardware though.
Does anyone have any info yet about what is going to be done about buying UMD games and movies in stores and getting them onto the PSP Go?
Also there was nothing on the firmed-up rumors of an upcoming PS3 slim, does anyone have anything more concrete as well?
I had a '81 19" Trinitron from the time I was a kid until just two years ago. The thing was indestructible. One time I was carrying it with a friend and it slipped from his hands and he tried to get it back up by kicking it up. It went way up and then down onto asphalt, and worked for years after that just the same as always. I think my parents paid $800 for it. I loved the individual fine tune pots for each channel.
I actually ran into the broadcast flag on a few occasions with using a DTV converter box and VCR. The issues that happened were of two flavors. One was that a broadcaster did use the flag (happened with two broadcasters to me) and the other case was a commercial would have the flag and then only a later commercial that happened to not have the flag would remove it. In the case of my using a DTV box and VCR what would happen is that the DTV box then would use the macrovision cp scheme, so the image on the TV was fine but what was recorded would fade in and out of dark b&w and nothing. At one point I already had WMC and two tuners and I can see when a program is tagged with the broadcast flag it says restricted or some such in the info of the program. I was able to record and watch the program in WMC. The way that I understand it is that broadcasters are allowed to still use the broadcast flag but that the FCC no longer requires equipment to respect it. I was unlucky and got some of the 2nd gen DTV tuner boxes that were made before the FCC ruled and so they did what was expected. Maybe there are DTV boxes now that never use macrovision or there might be ones that never did honor the broadcast flag at all.
I now live 50 to 60 miles out from the two cities I get TV (both digital and analog) from with no problems what so ever. I used to live 100+ miles from the two nearest cities and some repeaters about 50 miles away. I had no problems, though we did have a motorized antenna that made flipping through channels not something you did. You need to know what you are doing. I have a large good roof top antenna oriented properly, with good thick shielded coax, and two high quality amps, all fed to 3 TVs in the house. It works great but most people do not have the motivation or know how to get it right.
This is sort of a funny thing related to the story itself, but FSC came about due to the patents that RCA/NBC had at the time. In fact RCA did a lot of convoluted things in its actual implementation over the years to sidestep others' patents in the area and the situation only got reasonable in the '70s.
Low VHF is susceptible to interference, particualrly impulse noise, but guess what DVB-T at those frequencies is too. 8VSB is much better about dealing with it than any option under DVB. The other issue is that there have been RF modulator boxes that commonly used channels 2, 3, or 4 many stations broadcasting on 2, 3, 4, or 5 do it at lower power (well those do get to propagate better at low power) so the noise is more of a problem. That said I was and am able to get channel 2 NTSC and channel 3 ATSC from 50+ miles out and distribute it to 3 TVs and two recorders with very good results using a good rooftop antenna, thick shielded coax, and two amps. I have read the same complaints you have and I think that most people don't know what they are doing.
The other thing is that you mentioned DVB-T2. That really is a lost cause except for possible Norway and other countries that have been slow in the DTV roll-out. It would be such a PITA to have people upgrade yet again that it simply will not gain universal traction for OTA.
I am 50-60 miles away from the cities that I get OTA TV from. I never had much trouble with getting good TV signal and distributing it to three TVs in the house. I do have a large antenna pointed at the most troublesome VHF tower and good thick shielded coax and two amps. Every station but one will be UHF for me in a few days. I have now DTV tuners at all of the TVs. I only occasionally have trouble under heavy rain or wind of the current low power VHF station dropping out occasionally. It will move to UHF soon.
The other thing you did in your list is that the vast majority of the countries that you have listed have population only in certain dense regions. Then there are the tiny ones. In the US a large number of people do actually live in those low density areas served by repeaters from smaller cities. The signals do need to travel that far and people have 20-40 ft towers or whips to get TV.
Almost any modern system, to the CPU, a 32-bit aligned access is atomic. If they were just reading the global array, there is no need to use a lock, in fact this is a placebo lock, that adds unnecessary burden on the memory or reservation system. It is common for realtime that the global data is only modified at certain times when readers are not running.
Sometimes your 15 year senior programmers have earned their salt, in fact they usually have. I would like to see your fancy C++ with templates stuff compile onto some of the proprietary toolkits I have seen for small ARM and gate array systems. Writing code that uses a number of fixed sized simple data structures all written in C makes it very easy to port it to embedded systems. The moment you use something that seems as innocuous as C++ exceptions, you're in a world of hurt the moment you step out of GCC, VC++, SUNWpro, or XLC.
Here is one story. There is a fellow that likes to run C++ stuff he has written on our systems. The smallest config we run with that stuff has 16MB RAM and a 200MHz processor and we use GCC, so it's okay. One day he wanted to run on a new bigger system, so I enabled the C++ run time libs, this added 17s to the boot and used dozens of MB of RAM, but whatever this was in a system with 128 MB RAM and 1GHZ cpu. Then we got newer boards like those but with 256 MB RAM and 1.3GHz cpu and gigabit. Occasionally the boards would reset. It turned-out that due to all the extra resources and the dynamic sizing his code used, every now and then the HW watchdog timer was not getting twiddled (0.5s on a system with realtime requirements of various things in some cases of 4ms) and the board was being reset.
I wish I worked at more places like that.
Sure RAM is cheap, plentiful, and fast, but it is a shared resource which then gets paged to slow magnetic storage once your system crosses a magic line. Once you use a lot of VADDR you start needing to do more TLB lookups. And there are the other more limited shared resources to contend with, TLB caches and memory caches which are hard to upgrade. In multiprocessors you are also using memory bandwidth when cache lines are dirtied.
I think there are a lot of copy constructors called when using STL that a lot of people do not expect. The algorithms themselves tend to be well implemented though. None of that really has much to do about OO though, templates with structs with no member functions and lots of casting of void * could have been used instead.
I have realized that I will have been working as a dev for ten years now in four days. I've worked at a few places and I think that the reason for this is pretty straight forward, poor benchmarks used poorly.
We have all heard the mantra about optimizing early is evil but there are two issues to contend with. You get to a crunch time towards the end and then there is no time to address performance issues in every project. By that time so much code is written that you cannot address the performance issues in the most effective way, thinking about what algorithm to use in the dataset that ends-up being the common case. So instead some profiling work gets done and the code goes out the door.
So for success you need to have some performance measurements even early on. The problem is that in that case you end-up with some benchmarks that don't measure the right thing (that is what you discover near the end) or you have worthless benchmarks that suffer too much from not being reproducible, taking too long to run, or not giving the dev any idea of where the performance problem really is.
So what ends-up happening is that only after the code base has been around for a while and you get to rev n + 1 is there any real handle on any of this performance stuff. But often what ends-up happening is that project management values feature additions so as long as no single benchmark decreases by more than 2-5% and the overall performance does not decrease by more than 15% compared to the pre feature build, it gets the okay. Then a milestone arrives and there is no time again for systematic performance work and it ships as is.
The right approach would be at that stage to not allow a new feature unless the overall benchmark does not improve by 2% and to also benchmark your competitors as well but that just does not happen except in the very rare good groups sadly.
To be fair that money we loaned to the banks, GM, Chrysler, and AIG is money that we borrowed from China or will need to print later. I hope those we paid to repay their obligations, and I hope we repay our obligations, maybe we will even come out ahead, but it's not a sure thing by far.
As an aside I had to code for an embedded system with 4MB DRAM and 1MB FLASH where about half of the FLASH was already consumed by the loader, test, and config code from the vendor. I actually tried to put a portion of the code on the FLASH but there was a penalty of 4us per word on each access since it was on an IO bus and the FLASH was really slow. In the end I used 2MB of off board SRAM (battery backed and cksum verified on boot) and that had a penalty of only 1us per access. I get very annoyed when people from on high decide that now we need new functionality in the system and certainly anything will have the resources to support something so trivial to add. Eventually you die the death of a hundred cuts. Those boards are retired now, instead the smallest ones I support are 16MB DRAM, 4MB Flash, and 4MB SRAM, again as new 'requirements' got added over the years.
I am actually impressed that you got your solitaire in 650K or so since it does so much. My version was on a Casio graphing calculator.
I get annoyed when people do not consider: what does my software do, what is reasonable in time and space
Many people decide as long as it is always below some arbitrary number, that is good enough.
They fail to realize that DRAM is not the only resource nor that they share it with all other processes. In particular a much more limited shared resource is the L1 cache. When software gets bloated by an order of magnitude or two it effects the responsiveness of the system as a whole and the narrow view that some people take bothers me.
Kudos to you for not falling into that trap.
Yes 50-60% is pretty much the norm. The French do something clever in a number of plants though. They use excess to pump water into a reservoir and then later when they need extra they release the water to turn turbines to generate more. They essentially use the reservoir as a huge battery. It is not too terribly efficient but it lets you get above about 60% or so for nuclear power in your grid. Pretty much everywhere else coal plants are used to fill out the grid.
But this is solitaire. When I was a kid I wrote a version of solitaire in less than 300 lines. This should not be a 2+ MB program, and see he did it around 650K of object code.
Huh? I must have replied to the wrong thread.
I use a nearly 7 year old eMac running 10.5.7 as my primary computer at home. My wife does as well. We and my kids have two newer PCs as well but one is used mainly for RCT3 and WMC, while the other for web browsing (since flash is so horrible at this point on the eMac). What has kept the eMac so well used is iDVD, iMovie, and iPhoto (also macports for me). I have FreeBSD on the WMC machine but it is inconvenient since the tuners are almost always going to or are recording something. The BIOS in the web browsing one does crazy stuff when I use USB keyboard and mouse (I have to since the PS/2 ports are borken) where inb to the controller ports reflects what would have been seen if there was a PS/2 keyboard and mouse. I have no way to disable that in the BIOS and then FreeBSD thinks I have two mice and keyboards. So I do not compile the PS/2 stuff into the kernel and then the USB keyboard and mouse do not work half of the time until I unplug and plug them in again, and then the USB mouse keeps disconnecting and reconnecting periodically, and then I gave-up. So because of all that the workhorse computer at home is nearly 7 years old. It also has a DVD drive old enough that it lets us read Polish and US DVDs.