AT&T already has an IMEI blacklist. I believe they are exchanging data internationally already too. (The GSMA has an international shared blacklist - http://www.gsma.com/technicalp... )
Yup. The carriers already HAVE an effective killswitch: A database of IMEIs reported as stolen which the network can (and DOES) blacklist. (I know for a fact that AT&T does blacklisting as Samsung devices change to a "default" test IMEI if their EFS partition is corrupted - this IMEI is blacklisted by AT&T.)
If users want something more than that they have plenty of options available to them at their own risk.
"“Once a year they pick cities like Denver or London and rescan them and they get it into their database – how often Google buys those images and updates its maps, is up to them.” I'm surprised that Google is still buying DigitalGlobe imagery for the continental USA, ESPECIALLY for major metropolitan areas.
Most states have state-level orthoimagery collection programs, and as a result, there is high-quality aerial imagery significantly exceeding these satellites in quality over most of the USA, especially in metropolitan areas.
For example, New York State has 2 foot (24 inch) resolution across the entire state (only slightly worse than DigitalGlobe's best quality available), and over much of the state has 1 foot (12 inch) and even 0.5 foot (6 inch) resolution, the latter of which is better than what DG offers government customers. This data is under similar extremely permissive licensing to most other government GIS data such as TIGER. (Anyone can download NYGIS orthoimagery, and this same imagery is what Google uses for Maps/Earth for "satellite" which is really "aerial")
Pennsylvania has similar quality statewide imagery. Same for New Jersey (1 foot in the case of NJ).
OK, to clarify: You can't without violating the EULA.
The risks involved in getting caught RMTing (ban plus all assets in question get eliminated from the game) mean that: 1) The exchange rate is going to be far poorer than the PLEX exchange rate 2) The ability to scale the operation is going to be severely limited
The PLEX approach CCP implemented was a pretty ingenious way to combat real money trading. What CCP did was satisfy a market demand that existed (new players want to "get ahead" financially by spending some extra real money) while combatting "undesirable" methods for satisfying that demand (classic farming sweatshops). The sweatshops have to provide far more ISK per dollar than the PLEX exchange rate for them to make any money, while also being limited in how they make ingame money. (nullsec players have zero tolerance for RMT farmers and can easily take care of them, while they're also filthy rich ingame and love being able to play the game for free by putting a small portion of their income into PLEX.)
Note: Yes, I'm quite familiar with the PLEX affiliate kickback fees loophole, but that doesn't scale either... Even the largest such operation in the game is only netting around $75k/year so would take years to convert this much ISK into RL money, and there is basically no room in the game for another e-casino.
"Largest-Yet EVE Online Battle Destroys $200,000 in game time Worth of Starships"
You can't purchase real life money for ISK. You can only purchase game time cards for ISK (or other ingame items).
When someone buys PLEX for real life money and sells it for ISK ingame, they forget that intermediary step where CCP got the money, not the person who gave you the ISK.
That is indeed what I meant by "transfer well". If it requires 4x the cost of a general purpose CPU to get an FPGA to match the performance for a given algorithm - then the FPGA wins.
As an interesting reference point - in many cases, "custom hardware" for some algorithms is now winding up something more along the lines of a tweaked CPU with a modified instruction set than dedicated hardware (such as the video encoding/decoding blocks of most ARM CPUs, such as TI's Ducati engine and Qualcomm's vidc, both of which are running firmware that is loaded by the applications processor on ??? architectures - vidc might be Hexagon just like most of Qualcomm's basebands are) Determining the proper tradeoff of hardware vs. software requires a lot of work and whether it is worth it depends on a lot of things (cost per unit, number of units shipped, etc.)
While there are some compilers that ATTEMPT to convert C/C++ into a hardware representation - These will usually fail unless you understand the target hardware.
One thing is: Even if you can successfully compile from C to Verilog or VHDL, there is no guarantee that the Verilog or VHDL will successfully synthesize on your target hardware.
Even if it successfully synthesizes, there is no guarantee that it will be in any way an optimal implementation.
Some C algorithms may never transfer well into a hardware implementation.
Don't forget that a MAC address is 48 bits. The vendor ID portion is 24 bits - leaving 24 bits (approx. 16 million addresses) as the smallest range of addresses you can obtain if you obtain a single VID.
While I'm unhappy with many aspects of CM - They have never forcefully EOLed a device that was technically capable of running newer versions of Android.
Yes, prior to "inc" everything was volunteer based, and sometimes a volunteer would drop a device. Other devices (such as the original GalaxyS family) are going on forever.
There are only two cases I know of where CM "aggressively" EOLed anything: 1) The announcement that Snapdragon S1 series devices (such as the MSM7227 - NOT the 7227A) would be dropped. This was due to the fact that it was not possible for these devices to run 4.0 and later while still passing Google CTS. One of the rules for CM was "don't break apps" - Now, some CTS violations were just stupid (like anything related to root, or allowing apps to write to external SD) and CM used to let these slide. But if a device had a GPU that had no chance of rendering apps correctly on ICS and beyond - that would get EOLed. 2) EOLing of Nvidia Tegra2 sometime around Android 4.2 or 4.3 - This was because gapps for 4.2 or 4.3 *required* NEON instructions, which Tegra2 lacks
In your case - the problem lies with the fact that you have a shitty carrier that is an MVNO of one of the worst offenders in the business (Verizon) with respect to blocking alternate firmwares of any sort, not with CM. Seriously, if you want a decent Android device, your chances are slim to none on Verizon or any of their MVNOs.
In this specific case - the CM team tried to use the project's Contributor Licensing Agreement (CLA) as an intimidation tactic. (Effectively, saying it allowed them to relicense Focal when, in reality, it didn't.)
In the end, Focal was never relicensed BECAUSE Guillaume chose a license that protected him - BUT there is the fact that they tried to convince him that their CLA would allow them to relicense his code whether he liked it or not.
(Note: Some CLAs, such as Canonical's Harmony CLA, explicitly grant the recipient of a contribution rights to do this. The AOSP CLA, which CM's is a nearly identical copy of, does NOT grant such rights.)
One of the new company's first actions as a corporate entity was to try and use the CyanogenMod Contributor License Agreement to relicense a major GPLv3 contribution (a total rewrite of the camera app) AFTER work was completed (even though work was started well after they had formed as a company).
So they are promising that "everything you see now will remain open source" - but actions speak louder than words, and one of their first actions was to seek rights to create a closed-source version of the camera app.
Fortunately, their CLA didn't give them the power they thought it did. They claim the whole thing was just a "misunderstanding" - but if they were unaware that Guillaume wanted to keep the GPL, why were they bringing up the CLA, a document which serves solely to mediate licensing *disputes*?
Google never released an app. They accidentally left code enabled deep in the frameworks for which user-facing control was never exposed except via third-party modifications.
FYI, this is EXACTLY why the first iteration of privacy controls in CyanogenMod (that which was present in CM7) was removed - too many apps crashed.
The newer PG implementation in CM10.1 was such that permissions would not be denied, but an empty dataset would be returned.
Now the claim made in TFS - "The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people's data is being sucked through."
Every single permission granted to an app is listed in that app's summary, and ALSO is explicitly listed in such a way that the user must accept the list when installing.
Yup. As much as you might claim to not mind the weather, unless there is something on your resume that you actually HAVE long-term experience with similar weather, you're in for a rough time.
I know in the past, managers at the location I live in (Southern Tier of New York State) have a strong preference to see that the applicant has spent at least 2-3 winters in the area or an area with similar weather. (e.g. grew up in the area, worked for an extended period of time in the area, or went to a school in upstate New York such as Cornell, Binghamton, RIT, Clarkson, etc.)
Yup. In fact, this accident could be blamed on them.
At least one of the Fukushima reactors was originally scheduled for decommissioning prior to the accident. However, because it's so damn difficult to get new modernized plants with improved safety features built, and the population still needs electricity - the end result is that old clunkers like Fukushima (which consisted of some of the oldest operating reactors on the planet) get service life extensions.
Yup. The reactor sustained no damage from the earthquake itself.
It was the following tsunami they didn't properly plan for.
Also - more modern plants would have weathered this tsunami without problems. Newer plant designs have significantly improved passive safety, rendering the diesel generators (which are safety-critical in older plants) non-safety-critical.
Slashdot Mirror
AT&T already has an IMEI blacklist. I believe they are exchanging data internationally already too. (The GSMA has an international shared blacklist - http://www.gsma.com/technicalp... )
Yup. The carriers already HAVE an effective killswitch: A database of IMEIs reported as stolen which the network can (and DOES) blacklist. (I know for a fact that AT&T does blacklisting as Samsung devices change to a "default" test IMEI if their EFS partition is corrupted - this IMEI is blacklisted by AT&T.)
If users want something more than that they have plenty of options available to them at their own risk.
So what if someone puts a URL for a cheat site in a forum comment somewhere, disguised as something else?
Was the driver a smoker?
The same people who buy crap from Micromax.
"“Once a year they pick cities like Denver or London and rescan them and they get it into their database – how often Google buys those images and updates its maps, is up to them.”
I'm surprised that Google is still buying DigitalGlobe imagery for the continental USA, ESPECIALLY for major metropolitan areas.
Most states have state-level orthoimagery collection programs, and as a result, there is high-quality aerial imagery significantly exceeding these satellites in quality over most of the USA, especially in metropolitan areas.
For example, New York State has 2 foot (24 inch) resolution across the entire state (only slightly worse than DigitalGlobe's best quality available), and over much of the state has 1 foot (12 inch) and even 0.5 foot (6 inch) resolution, the latter of which is better than what DG offers government customers. This data is under similar extremely permissive licensing to most other government GIS data such as TIGER. (Anyone can download NYGIS orthoimagery, and this same imagery is what Google uses for Maps/Earth for "satellite" which is really "aerial")
Pennsylvania has similar quality statewide imagery. Same for New Jersey (1 foot in the case of NJ).
Hopefully those improvements can be "backported" to the S and X, reducing their price.
OK, to clarify: You can't without violating the EULA.
The risks involved in getting caught RMTing (ban plus all assets in question get eliminated from the game) mean that:
1) The exchange rate is going to be far poorer than the PLEX exchange rate
2) The ability to scale the operation is going to be severely limited
The PLEX approach CCP implemented was a pretty ingenious way to combat real money trading. What CCP did was satisfy a market demand that existed (new players want to "get ahead" financially by spending some extra real money) while combatting "undesirable" methods for satisfying that demand (classic farming sweatshops). The sweatshops have to provide far more ISK per dollar than the PLEX exchange rate for them to make any money, while also being limited in how they make ingame money. (nullsec players have zero tolerance for RMT farmers and can easily take care of them, while they're also filthy rich ingame and love being able to play the game for free by putting a small portion of their income into PLEX.)
Note: Yes, I'm quite familiar with the PLEX affiliate kickback fees loophole, but that doesn't scale either... Even the largest such operation in the game is only netting around $75k/year so would take years to convert this much ISK into RL money, and there is basically no room in the game for another e-casino.
"Largest-Yet EVE Online Battle Destroys $200,000 in game time Worth of Starships"
You can't purchase real life money for ISK. You can only purchase game time cards for ISK (or other ingame items).
When someone buys PLEX for real life money and sells it for ISK ingame, they forget that intermediary step where CCP got the money, not the person who gave you the ISK.
Thing is, a number of people have indicated that they have used third-party cables and those have solved the issue.
That is indeed what I meant by "transfer well". If it requires 4x the cost of a general purpose CPU to get an FPGA to match the performance for a given algorithm - then the FPGA wins.
As an interesting reference point - in many cases, "custom hardware" for some algorithms is now winding up something more along the lines of a tweaked CPU with a modified instruction set than dedicated hardware (such as the video encoding/decoding blocks of most ARM CPUs, such as TI's Ducati engine and Qualcomm's vidc, both of which are running firmware that is loaded by the applications processor on ??? architectures - vidc might be Hexagon just like most of Qualcomm's basebands are) Determining the proper tradeoff of hardware vs. software requires a lot of work and whether it is worth it depends on a lot of things (cost per unit, number of units shipped, etc.)
While there are some compilers that ATTEMPT to convert C/C++ into a hardware representation - These will usually fail unless you understand the target hardware.
http://www.drdobbs.com/embedded-systems/c-for-fpgas/230800194
One thing is: Even if you can successfully compile from C to Verilog or VHDL, there is no guarantee that the Verilog or VHDL will successfully synthesize on your target hardware.
Even if it successfully synthesizes, there is no guarantee that it will be in any way an optimal implementation.
Some C algorithms may never transfer well into a hardware implementation.
Another way of looking at it: This is the smallest possible address range you can obtain, since OUIs are 3 bytes.
Also, to my knowledge there is no provision for subdividing within an OUI - a 24 bit address range is the smallest you can get.
Don't forget that a MAC address is 48 bits. The vendor ID portion is 24 bits - leaving 24 bits (approx. 16 million addresses) as the smallest range of addresses you can obtain if you obtain a single VID.
While I'm unhappy with many aspects of CM - They have never forcefully EOLed a device that was technically capable of running newer versions of Android.
Yes, prior to "inc" everything was volunteer based, and sometimes a volunteer would drop a device. Other devices (such as the original GalaxyS family) are going on forever.
There are only two cases I know of where CM "aggressively" EOLed anything:
1) The announcement that Snapdragon S1 series devices (such as the MSM7227 - NOT the 7227A) would be dropped. This was due to the fact that it was not possible for these devices to run 4.0 and later while still passing Google CTS. One of the rules for CM was "don't break apps" - Now, some CTS violations were just stupid (like anything related to root, or allowing apps to write to external SD) and CM used to let these slide. But if a device had a GPU that had no chance of rendering apps correctly on ICS and beyond - that would get EOLed.
2) EOLing of Nvidia Tegra2 sometime around Android 4.2 or 4.3 - This was because gapps for 4.2 or 4.3 *required* NEON instructions, which Tegra2 lacks
In your case - the problem lies with the fact that you have a shitty carrier that is an MVNO of one of the worst offenders in the business (Verizon) with respect to blocking alternate firmwares of any sort, not with CM. Seriously, if you want a decent Android device, your chances are slim to none on Verizon or any of their MVNOs.
In this specific case - the CM team tried to use the project's Contributor Licensing Agreement (CLA) as an intimidation tactic. (Effectively, saying it allowed them to relicense Focal when, in reality, it didn't.)
In the end, Focal was never relicensed BECAUSE Guillaume chose a license that protected him - BUT there is the fact that they tried to convince him that their CLA would allow them to relicense his code whether he liked it or not.
(Note: Some CLAs, such as Canonical's Harmony CLA, explicitly grant the recipient of a contribution rights to do this. The AOSP CLA, which CM's is a nearly identical copy of, does NOT grant such rights.)
They potentially get shafted - https://plus.google.com/+GuillaumeLesniak/posts/L8FJkrcahPs
One of the new company's first actions as a corporate entity was to try and use the CyanogenMod Contributor License Agreement to relicense a major GPLv3 contribution (a total rewrite of the camera app) AFTER work was completed (even though work was started well after they had formed as a company).
So they are promising that "everything you see now will remain open source" - but actions speak louder than words, and one of their first actions was to seek rights to create a closed-source version of the camera app.
Fortunately, their CLA didn't give them the power they thought it did. They claim the whole thing was just a "misunderstanding" - but if they were unaware that Guillaume wanted to keep the GPL, why were they bringing up the CLA, a document which serves solely to mediate licensing *disputes*?
What surprises me is - this same IMEI blacklist is already in use in the USA. At the very least, AT&T uses it.
Google never released an app. They accidentally left code enabled deep in the frameworks for which user-facing control was never exposed except via third-party modifications.
FYI, this is EXACTLY why the first iteration of privacy controls in CyanogenMod (that which was present in CM7) was removed - too many apps crashed.
The newer PG implementation in CM10.1 was such that permissions would not be denied, but an empty dataset would be returned.
Now the claim made in TFS - "The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people's data is being sucked through."
Every single permission granted to an app is listed in that app's summary, and ALSO is explicitly listed in such a way that the user must accept the list when installing.
Don't like a permission? Don't install the app.
Yup. As much as you might claim to not mind the weather, unless there is something on your resume that you actually HAVE long-term experience with similar weather, you're in for a rough time.
I know in the past, managers at the location I live in (Southern Tier of New York State) have a strong preference to see that the applicant has spent at least 2-3 winters in the area or an area with similar weather. (e.g. grew up in the area, worked for an extended period of time in the area, or went to a school in upstate New York such as Cornell, Binghamton, RIT, Clarkson, etc.)
Yup. In fact, this accident could be blamed on them.
At least one of the Fukushima reactors was originally scheduled for decommissioning prior to the accident. However, because it's so damn difficult to get new modernized plants with improved safety features built, and the population still needs electricity - the end result is that old clunkers like Fukushima (which consisted of some of the oldest operating reactors on the planet) get service life extensions.
Yup. The reactor sustained no damage from the earthquake itself.
It was the following tsunami they didn't properly plan for.
Also - more modern plants would have weathered this tsunami without problems. Newer plant designs have significantly improved passive safety, rendering the diesel generators (which are safety-critical in older plants) non-safety-critical.
Yeah... This product existed before Glass was even announced I'm fairly certain.
It's also stuck running Froyo...
I've seen this device in person (someone had one at the Big Android BBQ last year) and also now own Glass - it doesn't even remotely compare to Glass.