Now, they likely do have some valid complaints here.

But bitching about a slow transition away from magnetic stripe cards when *you are one of the last retailers to install NFC payment terminals* and more importantly *knowingly skipped the start of migration during your last payment terminal upgrade cycle* is bullshit.

Now, I can understand if maybe Walmart were just at the wrong point in the upgrade cycle and hadn't upgraded their terminals in years, but I know for a fact that nearly every Walmart I've been to in the last year has upgraded their terminals in that time period and, despite many of their competitors having NFC payment terminals for a few years, Walmart did *not* upgrade to terminals that were capable of anything but magswipe.

Target appears to have deployed terminals that look NFC-ish but aren't, and did so before the NFC rollout started and hasn't done another deployment since then, so they do have an excuse.

One question: Is Waze v2 a derivative work under the GPL, or an original work that they happened to release under the GPL?

If the latter, then as the original copyright holder they are allowed to also release the code under an alternate license (assuming that all external contributions were either removed, had copyright assigned to Waze via a CLA, or had additional rights granted to the contribution via a CLA similar to Canonical's Harmony CLA...)

Also, as you've indicated, the only person with an actual legitimate claim in such a lawsuit is a copyright holder. For example, if you or I don't have any code in the Linux kernel that we retain copyright to, we can't sue someone for GPL infringement of the Linux kernel. (This is why kernel GPL violations rarely reach a lawsuit, most companies solve the issue well before a lawsuit or are located in China outside of the reach of most jurisdictions that someone could sue in, plus most kernel copyright holders would rather keep coding than spend time on a suit. The busybox team, on the other hand, frequently goes after busybox GPL violators.)

Yup. I suspect Canonical is going to continue down a path towards irrelevancy. They've got a solid userbase and a pretty good lead for now, which means it's not going to happen soon, but I can't see anything but a decline in the future for them.

I'm seeing a lot of parallels with Cyanogen Inc, the company that was formed by some of the CyanogenMod leads. They're delusionally self-important and consistently speaking things in direct conflict with their actions ("Everything you see now will remain open-source" at the same time they're trying to force a contributor to dual-license a major GPL work so they could have commercial rights to it. Fortunately their CLA wasn't as powerful as Canonical's). I suspect they're going to wind up going down the same road as Canonical.

Cyngn is doing EVERYTHING in nearly the exact same way Canonical has - and seems oblivious to the fact that Canonical has been doing a good job of alienating all of their potential partners and many of their contributors. Canonical should serve as a shining example of how NOT to monetize open source software in a sustainable fashion (especially by coopting existing projects), yet certain people feel that Canonical's example is the best one to follow.

You have obviously never worked closely with software written by Samsung before.

You know, the company that shipped millions of chips that would be damaged permanently if you send them a secure erase command. (Remember http://www.anandtech.com/show/... - What they don't tell you in that article is that Samsung shipped eMMC chips with the SAME EXACT BUG in every single international Galaxy S2 and Galaxy Note sold for many months.)

This is also the company that had a device file that was chmodded 666 or 777 that allowed you read/write access to the entirety of system memory. (Google exynos-abuse)

Yeah. Most importantly, no one ever proved that shipped (released builds as opposed to leaks or test builds) basebands ever used those functions. In fact, no one even found a leaked/test baseband firmware image that ever used those functions.

It wasn't really a "backdoor", it was Samsung being their typical careless selves and leaving debug code compiled in to a release build. That "backdoor" has nothing on exynos-abuse for example...

Keep in mind that Qualcomm has almost total dominance of the LTE modem market and they want to keep it that way.

Even massive pressure from Google won't work here... Maintaining their lead in baseband chipsets (which is heavily dependent on their modem firmware being as difficult to RE as possible) is EXTREMELY important to Qualcomm. Losing dominance of the LTE market will hurt their cash flow there, and also their ability to keep using it to sell complete SoCs. (It's only recently with Krait that Qualcomm's SoCs were able to stand on their own and obtain design wins without pairing to a Qualcomm modem. The old Scorpion cores in the Snapdragon S3 family kind of sucked.)

I grew up in central New Jersey.

Deer are a MAJOR pest there:
1) No natural predators. The closest thing to a "natural predator" they have any more are cars.
2) No firearms hunting. The area is so built up that I believe even bow hunting needed exceptions from the normal rules (regarding proximity to residences) be made. Doesn't help that residences are where most of the food supply (landscaping) is, so it's hard to find deer that aren't too close to a house to shoot.
3) People dropping rocks out of windows probably wouldn't be effective enough for population control. (Although the deer are so docile and adjusted to human presence that this, in theory, would be a possible method for hunting deer.)

Yeah. There are third-party lens covers like GlassKap, but there are two problems:
1) They don't match Glass in color. So it keeps the tinfoilhatters (an honestly small but vocal and whiny part of the crowd) happier but to everyone else you look really silly. (Yes, there are some that will say you'll always look silly with Glass - but it looks far sillier with a GlassKap on due to the color mismatch.)
2) Google put the light sensor for the device in the camera hole. So with GlassKap, Glass thinks you're always in a dark room and dims the display. :( (I wish I could get a version of http://www.shapeways.com/model... that didn't have the display shield component - I'd put a translucent cover over the camera hole.)

Another article on this, I agree with Dan's assessment - http://arstechnica.com/securit...

"Never attribute to malice that which can be attributed to stupidity."

My guess, after years of working with Samsung's poor-quality platform software and multiple runins with their utterly piss-poor configuration management processes (as in, the Korean divisions at Samsung Mobile don't seem to have any, as evidenced by numerous situations during the Superbrick fiasco):

Samsung probably put this into the RIL library to facilitate modem debugging. e.g. the modem can read/write to /efs/root/ in order to make it easier for a developer to track state changes of the modem or whatever. (Why do this instead of using whatever debugging functions are built into the modem such as maybe JTAG? This is probably for late-stage development where they wanted to test finishing touches on the modem using final hardware and the modem's debugging functions weren't physically available.)

Keep in mind that, based on the reverse engineering effort, Samsung *intended* this feature to only access files within /efs/root/ - the EFS partition is specifically reserved for device-specific state and calibration data (most notably the phone's IMEI is stored in the EFS partition, and with the exception of some miscellaneous other config data such as MAC addresses for wifi and BT, it's almost entirely for modem-related items. I may be wrong about the MAC data, I'm a bit rusty and haven't poked around at my EFS partitions in a long time.) It's only due to a screwup (lack of sanitization of escape sequences such as ../../ ) that someone can in theory access files outside of /efs/root

So at some point, Samsung probably removed the corresponding components on the baseband firmware side (no one has yet to confirm anything on the modem side that sends these commands, nor has anyone caught any of these commands being issued - the behavior of the library was verified by injecting extra commands with a kernel patch in the driver between the modem and the library), but someone forgot to remove them from the RIL library on the applications processor side. Forgetting to remove dead code and/or leaving epic security holes in place (remember that in late 2012, someone realized that Samsung left a world readable/writable device node that effectively mapped all system memory to that device file - allowing anyone to read or write any part of memory. For more, do a Google search for "exynos-abuse" ) is pretty typical for Samsung.

As to my experience here - I was one of the Cyanogenmod maintainers for the Exynos 4210 (I9100, I777, N7000) handset family, and also did some work on 4412 devices (primarily the Note 10.1 - GT-N8013) throughout 2012 and the first half of 2013. I'm 90% retired from working with Haxxinos these days and was (along with the majority of the rest of the Exynos maintainers) one of the people who left the project to start Omni after the Focal relicensing attempt fiasco.

An interesting question is - what architecture is the XMM626x's baseband processor? Is it custom or an ARM variant making it easier to analyze the baseband firmware itself? More than two years of working with that family of devices and I never personally looked in detail at what was running on the baseband side.

In a particular case like this, it may be possible for much of the transport work to be done by volunteers from the local ham community.

W2CXM's Force12 antenna was entirely put up by volunteers. This isn't exactly a small antenna - http://www.qsl.net/w2cxm/pics....

Yup. Here it's perfectly legal if you're informed. Any time I log into a machine at work I get a banner that my employer reserves the right to monitor anything I do with their network.

Because it's a shitty law that has too many dangerous drawbacks, and they already have a better solution (IMEI/ESN blacklisting) in place.

Yup. There are plenty of "opt-in" solutions to mobile device management right now.

Thing is, I know of none that can completely brick a device after a wipe, and I have grave concerns over such a capability because of the damage it does if it accidentally goes off. If it can't completely brick a device, at best it can protect your data but not the smartphone itself.

The thing is, there are already solutions for smartphone theft. A smartphone, to be fully useful, needs service from a wireless carrier. To get service, a device must report its IMEI or ESN. IMEI/ESN blacklists already exist and are in use today.

"Hacking was encouraged—users and developers were told they could root the console without voiding its warranty."

Problem was that it came out early that this wasn't a particularly "hackable" console due to some design flaws.
1) If you're doing platform-level hacking, Tegra3 is not a pleasant chipset to work with
2) It had some issues as I understand it with fastboot mode (I don't recall the exact details, but it either was extremely difficult to enter or simply didn't exist) - as a result it was very easy to brick the Ouya. The news of this drove away quite a lot of the potential enthusiast/power users.