Comment slow charging not great (Score 1) 85
Read the datasheets and whitepapers from the battery manufacturers. Charging them too slowly isn't good for them...plus it makes it harder to figure out when they're fully charged.
Read the datasheets and whitepapers from the battery manufacturers. Charging them too slowly isn't good for them...plus it makes it harder to figure out when they're fully charged.
It should be noted that most programmers will never write or directly use a lockless multithreaded algorithm. The number of things on a phone or tablet that need (or even would benefit significantly from) such an algorithm is relatively small.
Most of the time I suspect that the various cores on a mobile device are doing independent things. The percentage of time that the average phone/tablet is going to be doing massively parallel cpu-bound work is tiny.
The solution for this is checksums and parity on the disk contents at the filesystem level. Read a block off the disk and check the stored checksum against what you read...if it doesn't match then use the parity information to correct the data and store it somewhere else.
They have N parity disks, and then roughly N(N-1)/2 data disks and roughly the same number of spares.
In larger arrays the overall overhead of the parity and spare disks is slightly under 50%, or roughly equivalent to RAID-1, but more reliable since the spares can be reassigned as needed.
I'm writing this on a Dell Latitude with 16GB of RAM. I'd like twice as much. I do OpenStack development and regularly run a couple of controller nodes and a couple of compute nodes. That uses pretty much all of my RAM.
I'd like to be able to simulate a couple of storage nodes as well, and I'd like to be able to have multiple NUMA nodes per compute node to test out the code for simulating NUMA in the OpenStack guest instances.
Generally speaking each project has a coding style that most code in the project adheres to, for the simple reason that it's easier to maintain when the code all looks more-or-less similar.
If one area uses lowercase with underscores, and the other area uses CamelCase, and one area typedefs the heck out of everything while the other is explicit, then for someone coming in and trying to understand the code it makes it harder than necessary to figure out what's going on.
So if you look at the linux kernel, or glibc, or firefox, or Chrome, or any other similarly large project, there will be some sort of coding style that applies. This is not to say that the style applies blindly. For example there are areas in the kernel where they basically imported a driver that is written in a different coding style. Since that driver is maintained out of the linux kernel tree and is largely self-contained, that was deemed to be acceptable. And even in that case, the driver used an internally-consistent coding style for all the files involved.
I bought a Moto G on sale, and I have a cheap cell plan with no data. Works fine 99% of the time.
Bluetooth headset/handset and voice recognition would let you keep the tablet in a bag/rucksack/etc. and interact with it remotely.
With most high-end phones having glued-in batteries now, after a couple years the battery is starting to go.
Most people don't use their tablets as much, so the battery lasts longer.
The most powerful IED that could be transported by a recreational drone would be one carrying a model rocket engine. These contain PETN solid fuel, which is a high explosive. With clever design, this solid fuel engine could be used to make a small explosion. The problem? This would be at most enough to damage a few windows, and maybe maim somebody at point blank range.
What's "recreational" in this context?
The M18A1Claymore mine weighs under 4lbs and fires roughly seven hundred steel pellets like a shotgun. The proposed Amazon Prime Air drones could carry a bit over 5 lbs, so could easily mount a Claymore.
Apparently there is a company doing booming business selling drone detection systems to movie stars and other famous people. Gives them enough warning to cover up or go inside.
So anyone with money can get drone detection already. Drone destruction might be another story...though I wouldn't be surprised if that comes eventually too.
Nowhere did I call for banning drones, I just pointed out that they're a real issue, not some invented thing.
Personally I think the solution for drones would be a sensor net combined with some kind of EM weapon (laser/maser/EMP/etc.) to shoot down the drone before it gets to the intended target.
What does make sense is a radar/acoustic/lidar "fence", with some sort of point-defence laser/maser/EMP/etc system to disable drones that enter restricted airspace around sensitive areas.
On of the issues will be minimizing collateral damage--debris raining down on people, backscatter from the radiation pulse, missed shots hitting innocent people/equipment, etc.
Uber's pricing varies with demand, cabs don't. So if it's a busy time then you'll either pay more for immediate service with Uber, or else wait longer for a normal cab. It's up to the consumer.
Hypothetically speaking, if I'm desperate to get somewhere, and I'm willing to pay *whatever it takes*, why is it a good idea to limit the surge pricing?
If raising the price from 1.0 to 1.5 raises the number of drivers considerably, what about raising it from 3.0 to 4.5? In both cases the price increases by the same multiplier.
Or what about having an auction system where each person that wants a ride indicates how much they're willing to pay for it? Would you want to cap that as well?
You must realize that the computer has it in for you. The irrefutable proof of this is that the computer always does what you tell it to do.