Nope, it's not enough. An explanation helps the people who find the bug via search engine later. Not providing a reason aside from "this isn't supported anymore" is simply lazy; an additional sentence or two of why would go a long way towards keeping everyone on the same page.
Wireless charging is ineffective? Do you actually use it? I've used it for months and it charges my phone quite nicely and conveniently.
You could argue that some energy is lost to the ether, but that really doesn't affect me. Sure, It's not as fast as a quality cable charger, but it's still faster than the knock-off chargers that most people use. In any event it's fast enough to get me charged up for a while.
Plugging\unplugging cables doesn't sound like a terrible chore, but when you go wireless, you get very used to it. For example, I have wireless charging installed\hacked into my car. I get into my car and slap my phone onto my magnetic wireless charging mount (which is a Mountek magnetic mount with a Nexus Qi charger attached. The phone is Nexus 5). I don't have to adjust the mount to grab the phone (no grips, just magnets!) and I don't have to plug anything in. Within half a second, the phone is charging and mounted, and it charges at a fast enough rate that even with screen on and GPS active, the phone charge level is ticking upwards. When I leave my car, I just grab the phone. No fussing with cables or the mount. Awesome. Fast. Convenient. I'm living in the future.
I also have a Nexus Qi charger on my bedside table. With this, I never have to retrieve a cable that's fallen to the ground, and never have to drag a cable across the bed over a sleeping partner. It charges my phone all night, I wake up with a full charge, and it's easy, so I don't give a damn if some energy is lost. It's very effective for me.
Git is perfectly capable of having a repo that is considered the "single source of truth". All you have to do is tell everyone which repository to consider the "main" one.
The reason it's fine to use any random developer's git repository to restore is because the data's integrity is guaranteed by git's design. Let's say you had some disaster and lost your repository. Suppose you found a random developer (that you don't necessarily trust) who has a git repository that is a clone of your old, destroyed repository. You can safely and confidently restore from his copy so long as they have a commit id (hash) that matches exactly with a known hash from the original repository. If the hashes match then his copy at that commit is guaranteed to exactly match, bit for bit, your original repository. Compromising that integrity would be extraordinarily hard.
Of course you shouldn't rely on random developers having copies, just out of pure luck. Make your own backups and keep them safe.
Ever actually watch the closed captions? The data isn't as accurate or consistent as you may hope.
If such were the case, Google surely would have been sued to the brink by its shareholders by now.
This permission grouping is the exact opposite direction that Android permissions should be heading. There are a number of permissions, such as "Read Phone State and Identity" that should be broken up because they aren't even strongly related to each other.
You're not a real coder unless you write your own OS, processor microcode, support libraries, network architecture and programming language before you make your application. Otherwise, you're just letting other people do the hard work for you!
Do see what a bad place this line of thinking takes you? If you want to get anything done, you have to reinvent the world. Imagine if everybody did that... how slow development would be and how slightly incompatible everything would be.
Go ahead and proceed with your elitist worldview. If you need me, I'll be over here, being productive and shipping actual products.
doing things that break browsers that are somewhat out of the mainstream (while avoiding more portable solutions), it's not even a good, well-thought-out solution. If my browser doesn't work right on a given website, it's almost a certainty that the site uses JQuery.
So JQuery doesn't support your esoteric, out of mainstream, unnamed browser, but it works just fine for 99% of the world who do use mainstream browsers. Therefore JQuery is a bad solution? JQuery only has the developer mind\time resources to support only so much stuff. They just can't support everything, as that draws time\attention away from making the mainstream use cases work (read: use cases that are important to everyone else).
Faulting JQuery for not supporting your oddball browser is like faulting Adobe for not bringing Photoshop to FreeBSD; there are precisely 6 people who would use Photoshop on FreeBSD, so they choose to spend their time on other things.
Do you really want to sap the performance of your script by following the JQuery ethos of using expensive DOM-query navigators for every operation instead of simply gathering up an array of element references only once and then using that repeatedly?
Who says you have to query inefficeintly? Just query once and save the result somewhere. Just because it's possible to do something the wrong way doesn't mean JQuery is bad. There are ways to shoot yourself in the foot on every platform ever made.
You can always search with the word "near". "Pizza near Anytown, USA"
Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?
Consider the postage stamp: its usefulness consists in the ability to stick to one thing till it gets there. -- Josh Billings