The network is not necessarily involved. The example given of a self-driving car talks about the amount of time taken to distinguish between a plastic bag blowing in the wind and a child running in front of the car. This is not "network" timekeeping, just regular real-time processing.
I note that the Porsche 918 uses two electric motors, one for each axle.
Putting an electric motor at each wheel would eliminate the transmission, allow the use of smaller motors, and allow for active torque control at all four wheels (instead of just being able to break you could accelerate each wheel too).
I suspect that to minimize unsprung weight you'd want to have a small driveshaft at each wheel.
If you're dead set on putting it in the crawlspace, then either:
1) Go cheap enough that it's essentially disposable and you can replace it when it dies. or 2) Go expensive with SSD storage and passive cooling in a totally sealed case. (To minimize environmental issues.)
I bought a Truly Ergonomic. For "normal" typing it's fine, but for coding it moved too many of the keys around (square brackets, backslash, tilde, etc.) and I found it really hard to get used to.
I work with OpenStack, and regularly want to simulate 3+ VMs on my laptop. I've got 16GB of RAM, and could use twice that, but almost no laptops support 4 DIMM slots. (You pretty much have to get the mobile workstation ones, and they cost a lot.)
I dislike Harper as much as most of us, but to be fair it has always been the case that charitable organizations were not supposed to engage in significant amounts of political activities.
Yes, many of them (of all political stripes) have been doing just that for quite a while, but the law has been on the books for a long time (just not enforced very strictly).
It seems to me that the only real bit of inventiveness is to have a way for the phone to automatically detect that it has been inserted into the holder (and presumably switch to a different operating mode).
I don't think Google Cardboard does this, but it's an obvious incremental step.
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.
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?
Slashdot Mirror
The network is not necessarily involved. The example given of a self-driving car talks about the amount of time taken to distinguish between a plastic bag blowing in the wind and a child running in front of the car. This is not "network" timekeeping, just regular real-time processing.
Dell U2412M, U2413, U2415 are all 24" monitors with 1920x1200 screens.
Or you can jump up to 27" 2560x1440, 30" 2560x1600 or even 34" 3440x1440
Or you can go to a 4K screen or even a 5K one.
I note that the Porsche 918 uses two electric motors, one for each axle.
Putting an electric motor at each wheel would eliminate the transmission, allow the use of smaller motors, and allow for active torque control at all four wheels (instead of just being able to break you could accelerate each wheel too).
I suspect that to minimize unsprung weight you'd want to have a small driveshaft at each wheel.
If you're dead set on putting it in the crawlspace, then either:
1) Go cheap enough that it's essentially disposable and you can replace it when it dies.
or
2) Go expensive with SSD storage and passive cooling in a totally sealed case. (To minimize environmental issues.)
I bought a Truly Ergonomic. For "normal" typing it's fine, but for coding it moved too many of the keys around (square brackets, backslash, tilde, etc.) and I found it really hard to get used to.
I work with OpenStack, and regularly want to simulate 3+ VMs on my laptop. I've got 16GB of RAM, and could use twice that, but almost no laptops support 4 DIMM slots. (You pretty much have to get the mobile workstation ones, and they cost a lot.)
Even integrated video can handle Sketchup reasonably well, which is about as much CAD work as the average person will ever do.
As for video encoding, most people are fine with letting it run overnight so the speed delta doesn't matter.
I dislike Harper as much as most of us, but to be fair it has always been the case that charitable organizations were not supposed to engage in significant amounts of political activities.
Yes, many of them (of all political stripes) have been doing just that for quite a while, but the law has been on the books for a long time (just not enforced very strictly).
It seems to me that the only real bit of inventiveness is to have a way for the phone to automatically detect that it has been inserted into the holder (and presumably switch to a different operating mode).
I don't think Google Cardboard does this, but it's an obvious incremental step.
Native apps all the way, since I don't actually have a dataplan enabled on my smartphone.
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?