Perhaps, but if there were that many battery-swap capable Tesla EVs on the road, they'd probably be in the financial position to do something like that. I think the basic point is that the concern about getting a worn out battery from a swap isn't going to be a concern, either with the current system (where you get your existing battery back) or with a hypothetical battery subscription service.
For most people, though, battery swaps will be rare. You might need to drive far enough to justify one occasionally, but most people don't do so very often.
Umm, a soldier in the field is issued MREs. Short of eating the dirt and rocks around them, I don't think "thinking harder" will magically produce food.
Your alternatives would be either the existing MRE varieties, or starving to death. If you'd rather starve to death than eat shelf-stable pizza, you've got issues.
RTFA: this is for military rations. Have you ever made your "farm-fresh" pizza while hiding behind a rock on the other side of the world while people shoot at you? Didn't think so.
Canadian civilian here. US military MREs are better than most of the frozen stuff I usually eat. I probably haven't eaten as many as you, but I've eaten 36 of the things (including every flavour of the US military ones and every flavour of the MealKitSupply ones), and they were mostly pretty good.
It's more like 4 minutes versus 30 minutes, but the point is still fair. Luckily, Tesla's battery swap option should take about 90 seconds (beating refuelling), assuming they ever actually deploy them. So far, Tesla's battery swapping has been a paper launch.
Tesla's announced battery swap option requires you to pick up your original battery on your return trip; if you don't, they'll bill you the price difference taking depreciation into account.
Re:Why do you need an external camera to track hea
on
The Road To VR
·
· Score: 3, Informative
Relying entirely on accelerometers and gyroscopes works for a very brief amount of time, before suffering from massive drift.
What Oculus is doing is relying on the onboard tracker for low-latency real-time data, and using the external camera to correct for drift.
I'm particularly referring to VP8, which Google likes to claim is equivalent to h.264, but in reality it produces dramatically inferior results. The last benchmarks I had looked at showed VP8 requiring about twice the bitrate to achieve comparable quality, although that was a few years ago, so it's possible that the situation has improved. The only real advantage it had was being royalty-free, but that only came about because Google paid for the patent licenses after getting sued for patent infringement.
As for your claims that "no one has produced a finished h.265 or VP9 codec", I don't know what you're talking about. There are implementations of both available.
What makes you think the terribly performing FLOSS codec of the day will be more likely to be supported in the future than today? You'll probably find the FLOSS codecs are just as poorly supported in the future as they are now.
There are a few exceptions, where the FLOSS codecs are really quite good; Xiph has done some great things with speech codecs, for example. But Theora and VP8 are terrible, and VP9 doesn't even match h.264, let alone h.265...
Also synchronizing reading progress between different devices, and as Ozoner pointed out, getting firmware updates and transferring your own files. I buy my books from Baen (DRM free, not that I really care), and just tell Baen to e-mail them to my kindle directly. It's simpler than plugging it into a computer and copying them over.
There's a bunch of electrical stuff in the extreme front of the car. The 12V battery jumper terminals are right behind the plastic nose on the very front, not to mention the headlights on either side. There's also a bunch of electrical cabling around there. The 12V battery itself is located beside the frunk near the rear, not dissimilar to where you'd find a 12v battery in a normal car (still "under the hood" as it were).
Luxury car? As far as I can tell, the cheapest Cessna (the 172) costs $275,000 USD... that's as much as a house. And yet, the price of the aircraft when it was introduced, adjusted for inflation, is only about $72,000.
So the cost of the aircraft has increased nearly 4x faster than inflation. That can't help!
And therein lies the problem. PureData probably works great for a few specific use cases, but ultimately... PureData is written in C.
Don't get me wrong, that's not a problem. As I said, PureData isn't intended to be general purpose like that. But the fact that visual programming languages are never self-hosting (as far as I know, anyway) illustrates the reason why they're not a replacement for text-based languages.
Allow me to stress the importance of a multi-tiered backup strategy. The loss of any individual tier should not result in the loss of any data...
We're not exactly fanatical about our backups, but we still go for a three tiered strategy for our live systems: on-system (like nightly SQL dumps), off-system (nightly disk images stored in the datacentre), and off-site (nightly incremental rsync-based backups). The failure of any one of those backup tiers wouldn't be an issue...
I don't see why archival storage should be much different. You should have at least two copies of everything in different locations, on-site and off-site. Basically, if you're shoving archival data in a third-party facility like this, you have no backups of your archives...
France uses their nuclear plants for load-following: they can ramp up/down their nuclear plants at about 5% per minute. That means that you only need to back your wind/solar with a few minutes worth of battery capacity to work in tandem with the nuclear plants.
Errm, but Doom was a pseudo-3D engine that used raycasting... it used binary space partitioning instead of the simple grid that Wolf3D did, but it's still the same underlying technique.
Perhaps, but if there were that many battery-swap capable Tesla EVs on the road, they'd probably be in the financial position to do something like that. I think the basic point is that the concern about getting a worn out battery from a swap isn't going to be a concern, either with the current system (where you get your existing battery back) or with a hypothetical battery subscription service.
For most people, though, battery swaps will be rare. You might need to drive far enough to justify one occasionally, but most people don't do so very often.
Umm, a soldier in the field is issued MREs. Short of eating the dirt and rocks around them, I don't think "thinking harder" will magically produce food.
Your alternatives would be either the existing MRE varieties, or starving to death. If you'd rather starve to death than eat shelf-stable pizza, you've got issues.
RTFA: this is for military rations. Have you ever made your "farm-fresh" pizza while hiding behind a rock on the other side of the world while people shoot at you? Didn't think so.
Canadian civilian here. US military MREs are better than most of the frozen stuff I usually eat. I probably haven't eaten as many as you, but I've eaten 36 of the things (including every flavour of the US military ones and every flavour of the MealKitSupply ones), and they were mostly pretty good.
I love MREs. I've tried all the US military flavours and all of MealKitSupply's Canadain flavours. I may just be odd, though.
So the 250-300 mile range on electric cars don't exist? Sure, they're not cheap, but that's just a matter of time.
It's more like 4 minutes versus 30 minutes, but the point is still fair. Luckily, Tesla's battery swap option should take about 90 seconds (beating refuelling), assuming they ever actually deploy them. So far, Tesla's battery swapping has been a paper launch.
Fuel economy is measured in miles per gallon, the metric equivalent of which is kilometres per litre
I can't get my head around an inverse measure..
Living in a metric country (Canada), I refute your statement. The metric equivalent is litres per 100 kilometres.
Tesla's announced battery swap option requires you to pick up your original battery on your return trip; if you don't, they'll bill you the price difference taking depreciation into account.
Relying entirely on accelerometers and gyroscopes works for a very brief amount of time, before suffering from massive drift.
What Oculus is doing is relying on the onboard tracker for low-latency real-time data, and using the external camera to correct for drift.
VP8 turned out to be patent encumbered, what is to say VP9 won't also be?
Or perhaps they're hedging their bets; they also support MPEG-2 in hardware, that doesn't mean MPEG-2 is a better solution.
I'm particularly referring to VP8, which Google likes to claim is equivalent to h.264, but in reality it produces dramatically inferior results. The last benchmarks I had looked at showed VP8 requiring about twice the bitrate to achieve comparable quality, although that was a few years ago, so it's possible that the situation has improved. The only real advantage it had was being royalty-free, but that only came about because Google paid for the patent licenses after getting sued for patent infringement.
As for your claims that "no one has produced a finished h.265 or VP9 codec", I don't know what you're talking about. There are implementations of both available.
There are plenty of opensource h.264 decoders. Your source-related arguments are irrelevant.
No, it'd be like a regular customer of the fish and chip shop complaining that they've decided to stop selling fish and chips.
Freedom is letting people use what codecs they want, not forcing them to use a handful of really terrible ones.
What makes you think the terribly performing FLOSS codec of the day will be more likely to be supported in the future than today? You'll probably find the FLOSS codecs are just as poorly supported in the future as they are now.
There are a few exceptions, where the FLOSS codecs are really quite good; Xiph has done some great things with speech codecs, for example. But Theora and VP8 are terrible, and VP9 doesn't even match h.264, let alone h.265...
Also synchronizing reading progress between different devices, and as Ozoner pointed out, getting firmware updates and transferring your own files. I buy my books from Baen (DRM free, not that I really care), and just tell Baen to e-mail them to my kindle directly. It's simpler than plugging it into a computer and copying them over.
There's a bunch of electrical stuff in the extreme front of the car. The 12V battery jumper terminals are right behind the plastic nose on the very front, not to mention the headlights on either side. There's also a bunch of electrical cabling around there. The 12V battery itself is located beside the frunk near the rear, not dissimilar to where you'd find a 12v battery in a normal car (still "under the hood" as it were).
Luxury car? As far as I can tell, the cheapest Cessna (the 172) costs $275,000 USD... that's as much as a house. And yet, the price of the aircraft when it was introduced, adjusted for inflation, is only about $72,000.
So the cost of the aircraft has increased nearly 4x faster than inflation. That can't help!
And therein lies the problem. PureData probably works great for a few specific use cases, but ultimately... PureData is written in C.
Don't get me wrong, that's not a problem. As I said, PureData isn't intended to be general purpose like that. But the fact that visual programming languages are never self-hosting (as far as I know, anyway) illustrates the reason why they're not a replacement for text-based languages.
Allow me to stress the importance of a multi-tiered backup strategy. The loss of any individual tier should not result in the loss of any data...
We're not exactly fanatical about our backups, but we still go for a three tiered strategy for our live systems: on-system (like nightly SQL dumps), off-system (nightly disk images stored in the datacentre), and off-site (nightly incremental rsync-based backups). The failure of any one of those backup tiers wouldn't be an issue...
I don't see why archival storage should be much different. You should have at least two copies of everything in different locations, on-site and off-site. Basically, if you're shoving archival data in a third-party facility like this, you have no backups of your archives...
France uses their nuclear plants for load-following: they can ramp up/down their nuclear plants at about 5% per minute. That means that you only need to back your wind/solar with a few minutes worth of battery capacity to work in tandem with the nuclear plants.
Errm, but Doom was a pseudo-3D engine that used raycasting... it used binary space partitioning instead of the simple grid that Wolf3D did, but it's still the same underlying technique.