The problem here is you are using oranges to compare with apple. Most of the EVs on the market are hybrids., Tesla excepted. Secondly everyone always wants to compare the weight of a EV with the dry weight of a gasoline powered car. The gasoline actually weighs something though and some people keep their tanks full. The weight of all that gasoline and the gas engine are significant. If you remove the gas and the gas engine from the Chevy Volt you could gill up that space with batteries and wind up with an EV with many times the original capacity and a comparable weight.
I never mentioned any hybrids, so I don't know why you think it's an "apples to oranges" thing. All I've mentioned is pure EVs and gasoline cars. I'm not sure where you're going with this. The Leaf's 24 kWh battery pack weighs 300kg, giving the car a dry weight of 1521kg. Compare this to the Yaris, a similar sized car, which is 1048kg. The Leaf is already a very heavy car for its size, there isn't terribly much headroom to cram more batteries in there. Tesla's approach in their upcoming cars is to use lithium ion cells that are a lot further ahead on the capacity curve.
The Tesla is an anomaly, it's a sports car. I'm betting the Toyota Yaris isn't a sports car. I doubt you'd bet much range from a Maserati.
No, it's not. The Tesla Model S is a full-sized four-door sedan. Should I be comparing a sedan to a compact? Maybe not, but since the Tesla Model S and the Nissan Leaf are the only two large-scale series production EVs between $30k and 60k expected to be on the market any time soon, to my knowledge, I think it's pretty relevant. The Model S is 1735kg with a 42 kWh battery capacity, which is pretty impressive considering it's not a compact.
I believe you're thinking of the Tesla Roadster, which is a completely different car.
While you may like driving 5 hours straight, and I've done more than twice that, most people stop every two to three hours for a break or whatever. Any fuel stop is likely to take several minutes. I know it takes me at least three minutes to fill my tank. I timed it once. Five minutes to charge an EV is not going to be noticeable to most people.
Sure. But the Nissan Leaf isn't going to be able to drive 2-3 hours at 100-120 KM/h. It'll probably do that for about one hour. The Tesla Model S should be able to do 2-3 hours at that speed, possibly with one of the optional higher capacity batteries, although the Model S does cost about $20k more than the Leaf. The Tesla car after the model S is expected to hit that sub-$30k pricepoint, and if it has the same capacity, it might be the first EV to cost $30k or less that can drive 200-300KM, but it won't be out for years. Which sort of goes to reinforce my primary point: EVs aren't ready to replace cars in every use-case.
I didn't say I have a 7kW furnace.
But my AC draws 3.5kWh, and my furnace draws at least twice that.
3.5 x 2 = 7
I have a 48,000 BTU furnace, roughly 14kW, connect to a 60A (I was wrong the twin breakers are 30A not 25A) 240V (14.4kW) service connection. I'd be surprised if my furnace ever pulled 14kWh, but it could conceivably.
A kilowatt and a kilowatt hour are two different things. You appear to be using them interchangeably. Regardless, your point that you can do more than 240*30 in a home environment is taken, although it doesn't necessarily change the problem of charging long-range EVs, which even at 240*60 would still require five or six hours to charge.
That's funny, I could have sworn my furnace was hooked up to a pair of 25 Amp service breakers. Here, let me check... Yep, sure 'nuff my furnace can draw up to 50 Amps right off my grid. I know some only using 40. It wouldn't take much to run 500 Amp service like that or more.
The trick is in how you set up your battery array in the vehicle, and the charging coupling. Instead of using one big 0000 cable, you run multiple 20, 30, 40, 50 amp cables. Those cables could connect to a single "connector", while still maintaining isolation. You then charge in parallel with each wire drawing no more than the amp rating, and the battery charging happens spread out over the array, in parallel. No big super hot cables or coupling devices.
This is not rocket science people. It just requires the right design on the part of the people making the cars. Drawing power from multiple smaller cables is the logical home choice.
The "multiple cables" thing is largely transparent to the user, because they'd all be in a single sheath anyhow. Nor would a charger require multiple cables in order to tap in to multiple circuits.
Instead of one big 80kWh battery, use twelve 7kWh batteries, or 24 3.4kWh batteries.
Nobody makes an 80kWh battery (or at least, if somebody does, they're rather rare). Battery packs are made up of many battery cells. The Nissan Leaf's 24 kWh battery pack is made up of 48 blocks of 4 cells, or 192 battery cells in total.
Sure even then you won't be able to hook up and charge in 5-10 minutes. But my AC draws 3.5kWh, and my furnace draws at least twice that. So with either of the two later scenarios of batteries, I could charge a car in an hour. The time it takes me to make and eat dinner.
Your math doesn't hold up here. If your furnace draws 7 kW (I assume you don't actually mean 7 kWh, since that doesn't make sense), and you charged a Nissan Leaf at that rate, it'd take you ~4 hours to charge it assuming unrealistically high efficiency. If you took the hypothetical 80 kWh car that seems to be under discussion here, it'd take you ~12 hours, again assuming unrealistic efficiency.
Lastly, on capacity, I rarely ever drive more than 2-3 hours without refueling. While stopping every hour would be an inconvenience, doubling that would have almost zero impact on most people's driving habits. So, being able to get 250-300 mile range on a charge is plenty of capacity. There was one commercial EV that had that capacity, until they pulled it from they market. So it's doable.
I don't know about you, but I value being able to drive from Montreal to Toronto in 5 hours without stopping. Sure, it's not a big deal to stop halfway there, but it's nice to have the option not to. The Nissan Leaf's 24 kWh battery back gets you roughly 100KM of capacity. Driving to Toronto, you'd have to stop five times (about once an hour) to refuel, with an estimated charge time of 30 minutes using a fast charger (which actually only gets you to 80%, but let's ignore that). Even if you could get that down to 5 minutes, that's still a waste.
EVs are really neat, and they can certainly replace cars for many driving needs, but I figure it'll be at least 10-20 years before battery technology is sufficiently advanced to replace them for all purposes. Look at the 2009 Toyota Yaris. The EPA rates it at 6.5L/100km, and it has a 42 litre tank. That means you can go 646KM on a single tank. So we're not quite there yet. The Tesla Model S claims future "larger battery packs" that will do 480KM, which is very nearly there, but the cost (of the model S and the extra large battery pack) and weight of that are not necessarily practical yet. So give it 10-20 years, and that sort of range in an EV should be affordable.
Fast charging is nice... It's not practical for home EV charging (the Leaf's 240v home charger requires a 30 amp circuit, and expecting more in a home is unreasonable), but it can be useful for fueling stations and consumer electronics (filling a 60Wh laptop battery in 3 minutes is doable on a standard 120V AC circuit).
A far more useful thing would be improved capacity, though. Charging your car's batteries in five minutes sounds nice, but if you're driving a long distance and have to stop every hour to charge the battery for five minutes, it's not very practical. Battery capacity is also the primary limiting factor in the performance of mobile devices such as laptops and smartphones.
Umm... maybe the article was written before the iPad 2 came out?
Fair enough. Then you'd also want to discount V8's crankshaft, and the advancements in desktop CPU performance since the previous slew of devices came out. The picture won't change much. Certainly not by an order of magnitude. And the general point is that you shouldn't expect the performance of a smartphone processor to come anywhere near a desktop processor that can draw a hundred times more power.
If HTML5 was pushed a replacement for Flash, and if it fails at the very basic tag to create Flash like content that's not possible in HTML5. See Jobs' rant against Flash about a year ago. http://www.apple.com/hotnews/thoughts-on-flash/
If Apple is unable to get HTML5 even close to Flash in a whole year, I don't know what that says. Maybe they don't want HTML5 apps which will perfrom equally well on Android and the upcoming IE9 mobile and want native apps instead so that the user is locked in and where developers are forced to give up 30% of both their revenue from selling it AND any subscription fees that the user pays?
Do you really think that this is the first time Jobs has sold the public exaggeration and hyperbole? Apple makes some impressive products, but he's made a career out of perfecting the reality distortion field.
Meh, Netflix Canada has never supported queues to begin with. While it would be nice to mark stuff that I'd like to watch to remember later, it's not that big a deal in the end.
HTML wasn’t created for dynamic/interactive content, it was created to present academic documents.
And the USPS wasn't created to ship you books from Amazon. And the telephone network wasn't created to use DSL modems. And the cable network wasn't created to deliver video on demand or internet service. And computers weren't created to connect to a global information network. What's the point? Because HTML 1.0 wasn't intended for this stuff, HTML 5 can't be? That's silly. HTML 5 and HTML 1 are two different things. HTML 4 and 5 *were* created for dynamic/interactive content.
JavaScript performance on iOS is 100x worse than desktop.
Some benchmarks would be nice. How about I provide some? How about we take SunSpider from Anandtech's review of the iPad 2 (http://www.anandtech.com/show/4215/apple-ipad-2-benchmarked-dualcore-cortex-a9-powervr-sgx-543mp2/2). 2041.4ms. Sounds about right, roughly twice the speed of the iPhone in this article, which is in-line with the hardware differences. OK, so if iOS JavaScript performance is 100x worse, we would expect a fast desktop browser to do this in 20.4ms, right? Let's see what Chrome gets with their latest-and-greatest, CrankShaft for V8 (http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump)... Hmm, 250ms. Not even 10x faster, let alone 100x faster. Maybe the speed difference is because we're comparing a processor that draws one or two watts, to a processor that draws a hundred watts? Maybe the difference has nothing to do with software, and everything to do with the fact that a smartphone is not a 20 pound desktop computer (or a 5 pound laptop)?
Canvas performance on iOS is so bad that it is barely usable.
Again, with the lack of any data or benchmarks... OK, I'll give you the fact that iOS canvas performance is slow. So is Android's: neither iOS or Android have fully hardware accelerated browsers. But barely usable? A bit of an exaggeration, I think. So let's put this one as "Sure, but that's about the same for most mobile browsers."
A lot of people don’t upgrade their software, iOS 3.2 is completely different than iOS 4.2 and you should support both.
Yes and no. Was Apple completely out of line to drop support entirely for products they sold 7 months before iOS 4.3 launched (the second generation iPod touch)? Definitely. Were they out of line for dropping support for the 3G? Sure. But if people don't upgrade their software, what exactly can be done to support them? If they don't want to upgrade, they're not going to get 3.2.x point releases either.
Officially, Google is actually worse here. The HTC Dream, the first Android phone, came out in October of 2008. The last supported version of Android was 1.6, which came out in September of 2009. Yikes, less than one year of software support from Google on their flagship device. And yes, you can root your Dream and put 2.3 on it, but you can jailbreak your iPhone and put Android 2.3 on it too, so that's not really a valid thing; we need to only consider official support. Both Apple and Google are dropping the ball on this.
The iOS simulator is different than the actual device.
Umm, sure, some googling seems to bear that out, but that's true of pretty much every emulator ever written. The goal of such simulators in the case of mobile app development isn't to perfectly emulate a given device, but to offer a generic development platform that's more convenient than loading builds onto actual hardware (something that's made very easy).
It is very important to note that every single Webkit browser works differently and that older versions of the iOS have many bugs and missing features (the new ones as well). Chrome and Safari have a bunch of rendering problems related with HTML5 video and CSS3 as well when you start overlaying content and adding CSS transitions. Android 2.0-2.2 also have many bugs related with HTML5 video.
1) Get a data-only SIM. Here in Canada, $35/mth gets you 5GB for a data-only SIM. In that case it's a Virgin Mobile (which is wholly owned by Bell) android tablet SIM, but there's no reason it couldn't go in an android phone instead. 2) Get an Android phone supporting 2.3 or later 3) Get an account and DID at voip.ms (no PBX required, their customer management portal can do most things Asterix can). I assume you're in the US, so that's $0.99 USD per month for the DID, $0.01 per minute incoming minutes (by 6 second increments), and $0.0105 per minute outgoing (by 6 second inc 4) Either use Android 2.3's built-in SIP support, a third-party SIP application, or some combination of the two.
Excepting that the latency on HSPA+ isn't great (130-150ms on a decent connection), it should feel pretty close to native. I regularly make Skype calls on 3G, and while it's not optimal, it works well enough.
However, if I were you, I would wait until I could get an LTE Android phone before trying this; some googling showed benchmarks of 20 to 50 milliseconds on LTE, which is a huge improvement, and more than sufficient for great VoIP quality.
you'd rather run your network on a hacked copy and risk getting screwed, like when CentOS nearly went tits up, than to actually spend a buck and help pay for your own OSes improvements
Where did I say that I run CentOS? I don't, nor do I run RHEL. I've got Windows on my desktop and laptop, Solaris on my file server, and Ubuntu on my VPS. I was simply pointing out that you were incorrect in saying that it's not relevant; your own post here only underscores the relevance, since you're arguing that CentOS has various ill effects on the ecosystem. Something doesn't have to be a positive benefit to be relevant.
Their most recent release (4.9) was two days ago (and the previous major release of 5.5 was 9 months before that), and it's used on 30% of all Linux webservers. I'd say that makes it pretty relevant. Sure, they're a bit late on the release of 6.0, but with more than a few other enterprise Linux distros working on two year release cycles, I don't think that a four month wait for the latest bleeding edge is really such a big deal; users of the 4.x and 5.x releases are still getting the latest releases on time.
I tried to convert to CFL. I bought one at the store, and tried to put it in my lamp at home. Guess what? It doesn't fit, because the neck of the CFL was far wider than an incandescent lightbulb. I had to return it.
Since then, I've kept my eye out whenever I'm at the pharmacy or other store that has CFLs; I have yet to see a single one that's actually shaped like an incandescent that will fit in my lamp (which, I should note, is a 6+ foot tell lamp from IKEA).
What am I supposed to do when Canada decides to do something similar? Buy a new lamp just because they aren't able or willing to produce CFLs in the same shape as the bulbs they aim to replace?
I'm not advocating for one over the other, only stating that sometimes you need to hit a target filesize or bitrate, and you've listed some of the reasons why you might. Fitting your video on an optical disc is one such reason. For example, the videos coming out of my camera are pretty high bitrate (almost twenty megabit). If I need to fit a video on a mini DVD, for example, that's going to need a target filesize.
No, they both do the same thing. The problem is that you have no control over filesize with quality-based encoding, so if you're trying to hit some specific target, or even if you just generally want to be in some certain range, then quality-based encoding may not be the best idea. Even getting within a certain range might take a few tries with quality-based settings, and at that point it would have been faster to do a two-pass encode.
There's a simple solution to that problem: backups.
Considering that it costs thousands of dollars to hire a recovery company for a single drive, and that tape backups (or other types of backup solutions) cost a tiny fraction of that, the solution is obvious.
You can't change the state of a flash cell without first erasing it, they already have that "self-destruct" write path. When you get an empty SSD, all the blocks are in the erased state, so each write is a simple write. If you want to rewrite anything, you must first erase it before you can write to it. That's why SSD performance slows down over time. A secure erase doesn't do any writing, it just erases all the blocks simultaneously withing having to care about which ones should be preserved.
I'm probably slightly exaggerating by saying that it happens instantly, but the last time I did a secure erase on an Intel SSD (due to getting it into a poor performance state), the process took mere seconds.
No, it wouldn't work, but only because SSDs are copy-on-write by nature, and have large amounts of spare space hidden from the OS. However, using an SSD's built-in secure erase functionality, which triggers an erase cycle on every single block of the SSD, would be sufficient; a flash cell with no electrons in the floating gate isn't going to reveal any secrets.
It should be noted that the multiple rewrites thing is only require for "old school" HDDs. Modern magnetic HDs only need a single pass (as referenced by the wikipedia article that you cite).
SandForce SSD controllers encrypt all data as it hits the SSD. That does nothing to protect against plugging the drive into a computer and using it (a secure delete would handle that), but it *does* protect against people accessing the NAND chips directly. That and the fact that SandForce drives use compression/deduplication/other tricks and properly support secure erase would make it exceedingly difficult to recover data.
They've had actual silicon for 12 days. They may have been too busy showing it off to the press to sit down and plug it into a killawatt.
Referencing the Anandtech article, nVidia claims that for the same workload, it is as efficient or more efficient than the Tegra 2, but if you increase the workload, it'll obviously use a bunch more power.
"MeeGo smartphones and tablet devices will offer overwhelmingly superior experiences and applications than iOS and Android based competitor products."
Clearly they have a firm grip on reality. I'm not saying that MeeGo won't be a decent platform, but claiming that it will ovfer an "overwhelmingly superior experience" to the other market leaders who have multi-year head starts is silly.
That'd be the distance, yes. I tried OnLive in Montreal (my ISP bounces me through Toronto), for a total path (by car) of ~1300KM. The recommended range of OnLive to their datacenters is ~1600KM. So, I'm not optimal, but I'm well within range.
My experience was that latency was acceptable (I was surprised, really, how low it was) and that people at shorter ranges might even see latencies below a typical console game (console games tend to have massive input latency compared to PC games).
However, the video quality was exceptionally poor. This is not a bandwidth thing, since onlive does not appear to adapt to the available bandwidth; if your connection slows down too much, it drops frames, and then disconnects you if it continues (also, I was testing with a 50Mbps cable line). This was purely a matter of their bitrate being too low (or their h.264-like encoder not being efficient enough). Slower-paced games might be OK, but vehicular combat in Unreal Tournament 3 was unplayable; as soon as the vehicle was moving at speed, the screen devolved into a blurry mess. I couldn't aim at enemies properly because I couldn't see them.
I think there's potential for the service, though. Latency, while not bad, could be improved with more regional datacenters (Toronto would shave off most of the latency for me), and image quality can be improved by cranking up the bitrate (I don't think they can make codec changes since they're producing hardware).
TFA is suggesting a pointless solution, though. TFA suggests that instead of an algorithm that allows an attacker to check 2300 million hashes per second, we use something that can limits current hardware to 10 thousand per second. That's all well and good, except that Moore's law will raise that back to 2300 million after 27 years... and that's assuming that the ability to generate these things doesn't increase faster than Moore's law. Certainly the introduction of GPGPU computing gave us a performance leap far in excess of Moore's law for this sort of stuff. A willingness to increase power consumption, for example, allows you to scale performance beyond Moore's law.
The author suggests that we use an algorithm where "Computational time required can be adjusted easily when processing power increases" but this doesn't completely solve the problem; keys generated before changing the algorithm will still be crackable with the old processing requirements.
In principle, many Canadians agree with you. In practice, Bell set the caps/charges at 25GB and $2 per gig overage.
If it was 250GB and $0.10 overage, we wouldn't be in this mess. But when I have to pay $50 in bandwidth to download a videogame from the playstation network, or pay $4 an hour to watch netflix, something is wrong.
Unlikely. Sony essentially took current smartphone tech and scaled it up. Smartphones are starting to ship with dual-core Cortex A9 processors, Sony threw in a quad-core. Smartphones are starting to ship with single-core PowerVR SGX540s, Sony through in four of 'em.
The reason you won't see this in 6 months from smartphone vendors is because Sony has a bigger power budget; the PSP doesn't have to be as small and light as a smartphone, so they can afford to burn a lot less power. The NGP probably draws three times more power than a typical smartphone, and 6 months isn't enough time to counterbalance that.
18 months, maybe, that's enough for Moore's law to take effect, but since dual-core Cortex A9 smartphones *just* hit the market, 6 months is silly.
I've never had that problem over nine years of using wireless mice (for gaming as well as other use). Wireless mice are presented to the OS just like wired mice, there is no reason why an antivirus scan should kill your mouse; something is wrong with your computer.
Slashdot Mirror
The problem here is you are using oranges to compare with apple. Most of the EVs on the market are hybrids., Tesla excepted. Secondly everyone always wants to compare the weight of a EV with the dry weight of a gasoline powered car. The gasoline actually weighs something though and some people keep their tanks full. The weight of all that gasoline and the gas engine are significant. If you remove the gas and the gas engine from the Chevy Volt you could gill up that space with batteries and wind up with an EV with many times the original capacity and a comparable weight.
I never mentioned any hybrids, so I don't know why you think it's an "apples to oranges" thing. All I've mentioned is pure EVs and gasoline cars. I'm not sure where you're going with this. The Leaf's 24 kWh battery pack weighs 300kg, giving the car a dry weight of 1521kg. Compare this to the Yaris, a similar sized car, which is 1048kg. The Leaf is already a very heavy car for its size, there isn't terribly much headroom to cram more batteries in there. Tesla's approach in their upcoming cars is to use lithium ion cells that are a lot further ahead on the capacity curve.
The Tesla is an anomaly, it's a sports car. I'm betting the Toyota Yaris isn't a sports car. I doubt you'd bet much range from a Maserati.
No, it's not. The Tesla Model S is a full-sized four-door sedan. Should I be comparing a sedan to a compact? Maybe not, but since the Tesla Model S and the Nissan Leaf are the only two large-scale series production EVs between $30k and 60k expected to be on the market any time soon, to my knowledge, I think it's pretty relevant. The Model S is 1735kg with a 42 kWh battery capacity, which is pretty impressive considering it's not a compact.
I believe you're thinking of the Tesla Roadster, which is a completely different car.
While you may like driving 5 hours straight, and I've done more than twice that, most people stop every two to three hours for a break or whatever. Any fuel stop is likely to take several minutes. I know it takes me at least three minutes to fill my tank. I timed it once. Five minutes to charge an EV is not going to be noticeable to most people.
Sure. But the Nissan Leaf isn't going to be able to drive 2-3 hours at 100-120 KM/h. It'll probably do that for about one hour. The Tesla Model S should be able to do 2-3 hours at that speed, possibly with one of the optional higher capacity batteries, although the Model S does cost about $20k more than the Leaf. The Tesla car after the model S is expected to hit that sub-$30k pricepoint, and if it has the same capacity, it might be the first EV to cost $30k or less that can drive 200-300KM, but it won't be out for years. Which sort of goes to reinforce my primary point: EVs aren't ready to replace cars in every use-case.
I didn't say I have a 7kW furnace.
But my AC draws 3.5kWh, and my furnace draws at least twice that.
3.5 x 2 = 7
I have a 48,000 BTU furnace, roughly 14kW, connect to a 60A (I was wrong the twin breakers are 30A not 25A) 240V (14.4kW) service connection. I'd be surprised if my furnace ever pulled 14kWh, but it could conceivably.
A kilowatt and a kilowatt hour are two different things. You appear to be using them interchangeably. Regardless, your point that you can do more than 240*30 in a home environment is taken, although it doesn't necessarily change the problem of charging long-range EVs, which even at 240*60 would still require five or six hours to charge.
That's funny, I could have sworn my furnace was hooked up to a pair of 25 Amp service breakers. Here, let me check ... Yep, sure 'nuff my furnace can draw up to 50 Amps right off my grid. I know some only using 40. It wouldn't take much to run 500 Amp service like that or more.
The trick is in how you set up your battery array in the vehicle, and the charging coupling. Instead of using one big 0000 cable, you run multiple 20, 30, 40, 50 amp cables. Those cables could connect to a single "connector", while still maintaining isolation. You then charge in parallel with each wire drawing no more than the amp rating, and the battery charging happens spread out over the array, in parallel. No big super hot cables or coupling devices.
This is not rocket science people. It just requires the right design on the part of the people making the cars. Drawing power from multiple smaller cables is the logical home choice.
The "multiple cables" thing is largely transparent to the user, because they'd all be in a single sheath anyhow. Nor would a charger require multiple cables in order to tap in to multiple circuits.
Instead of one big 80kWh battery, use twelve 7kWh batteries, or 24 3.4kWh batteries.
Nobody makes an 80kWh battery (or at least, if somebody does, they're rather rare). Battery packs are made up of many battery cells. The Nissan Leaf's 24 kWh battery pack is made up of 48 blocks of 4 cells, or 192 battery cells in total.
Sure even then you won't be able to hook up and charge in 5-10 minutes. But my AC draws 3.5kWh, and my furnace draws at least twice that. So with either of the two later scenarios of batteries, I could charge a car in an hour. The time it takes me to make and eat dinner.
Your math doesn't hold up here. If your furnace draws 7 kW (I assume you don't actually mean 7 kWh, since that doesn't make sense), and you charged a Nissan Leaf at that rate, it'd take you ~4 hours to charge it assuming unrealistically high efficiency. If you took the hypothetical 80 kWh car that seems to be under discussion here, it'd take you ~12 hours, again assuming unrealistic efficiency.
Lastly, on capacity, I rarely ever drive more than 2-3 hours without refueling. While stopping every hour would be an inconvenience, doubling that would have almost zero impact on most people's driving habits. So, being able to get 250-300 mile range on a charge is plenty of capacity. There was one commercial EV that had that capacity, until they pulled it from they market. So it's doable.
I don't know about you, but I value being able to drive from Montreal to Toronto in 5 hours without stopping. Sure, it's not a big deal to stop halfway there, but it's nice to have the option not to. The Nissan Leaf's 24 kWh battery back gets you roughly 100KM of capacity. Driving to Toronto, you'd have to stop five times (about once an hour) to refuel, with an estimated charge time of 30 minutes using a fast charger (which actually only gets you to 80%, but let's ignore that). Even if you could get that down to 5 minutes, that's still a waste.
EVs are really neat, and they can certainly replace cars for many driving needs, but I figure it'll be at least 10-20 years before battery technology is sufficiently advanced to replace them for all purposes. Look at the 2009 Toyota Yaris. The EPA rates it at 6.5L/100km, and it has a 42 litre tank. That means you can go 646KM on a single tank. So we're not quite there yet. The Tesla Model S claims future "larger battery packs" that will do 480KM, which is very nearly there, but the cost (of the model S and the extra large battery pack) and weight of that are not necessarily practical yet. So give it 10-20 years, and that sort of range in an EV should be affordable.
Fast charging is nice... It's not practical for home EV charging (the Leaf's 240v home charger requires a 30 amp circuit, and expecting more in a home is unreasonable), but it can be useful for fueling stations and consumer electronics (filling a 60Wh laptop battery in 3 minutes is doable on a standard 120V AC circuit).
A far more useful thing would be improved capacity, though. Charging your car's batteries in five minutes sounds nice, but if you're driving a long distance and have to stop every hour to charge the battery for five minutes, it's not very practical. Battery capacity is also the primary limiting factor in the performance of mobile devices such as laptops and smartphones.
Umm... maybe the article was written before the iPad 2 came out?
Fair enough. Then you'd also want to discount V8's crankshaft, and the advancements in desktop CPU performance since the previous slew of devices came out. The picture won't change much. Certainly not by an order of magnitude. And the general point is that you shouldn't expect the performance of a smartphone processor to come anywhere near a desktop processor that can draw a hundred times more power.
If HTML5 was pushed a replacement for Flash, and if it fails at the very basic tag to create Flash like content that's not possible in HTML5. See Jobs' rant against Flash about a year ago. http://www.apple.com/hotnews/thoughts-on-flash/
If Apple is unable to get HTML5 even close to Flash in a whole year, I don't know what that says. Maybe they don't want HTML5 apps which will perfrom equally well on Android and the upcoming IE9 mobile and want native apps instead so that the user is locked in and where developers are forced to give up 30% of both their revenue from selling it AND any subscription fees that the user pays?
Do you really think that this is the first time Jobs has sold the public exaggeration and hyperbole? Apple makes some impressive products, but he's made a career out of perfecting the reality distortion field.
Meh, Netflix Canada has never supported queues to begin with. While it would be nice to mark stuff that I'd like to watch to remember later, it's not that big a deal in the end.
Sure.
HTML wasn’t created for dynamic/interactive content, it was created to present academic documents.
And the USPS wasn't created to ship you books from Amazon. And the telephone network wasn't created to use DSL modems. And the cable network wasn't created to deliver video on demand or internet service. And computers weren't created to connect to a global information network. What's the point? Because HTML 1.0 wasn't intended for this stuff, HTML 5 can't be? That's silly. HTML 5 and HTML 1 are two different things. HTML 4 and 5 *were* created for dynamic/interactive content.
JavaScript performance on iOS is 100x worse than desktop.
Some benchmarks would be nice. How about I provide some? How about we take SunSpider from Anandtech's review of the iPad 2 (http://www.anandtech.com/show/4215/apple-ipad-2-benchmarked-dualcore-cortex-a9-powervr-sgx-543mp2/2). 2041.4ms. Sounds about right, roughly twice the speed of the iPhone in this article, which is in-line with the hardware differences. OK, so if iOS JavaScript performance is 100x worse, we would expect a fast desktop browser to do this in 20.4ms, right? Let's see what Chrome gets with their latest-and-greatest, CrankShaft for V8 (http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump)... Hmm, 250ms. Not even 10x faster, let alone 100x faster. Maybe the speed difference is because we're comparing a processor that draws one or two watts, to a processor that draws a hundred watts? Maybe the difference has nothing to do with software, and everything to do with the fact that a smartphone is not a 20 pound desktop computer (or a 5 pound laptop)?
Canvas performance on iOS is so bad that it is barely usable.
Again, with the lack of any data or benchmarks... OK, I'll give you the fact that iOS canvas performance is slow. So is Android's: neither iOS or Android have fully hardware accelerated browsers. But barely usable? A bit of an exaggeration, I think. So let's put this one as "Sure, but that's about the same for most mobile browsers."
A lot of people don’t upgrade their software, iOS 3.2 is completely different than iOS 4.2 and you should support both.
Yes and no. Was Apple completely out of line to drop support entirely for products they sold 7 months before iOS 4.3 launched (the second generation iPod touch)? Definitely. Were they out of line for dropping support for the 3G? Sure. But if people don't upgrade their software, what exactly can be done to support them? If they don't want to upgrade, they're not going to get 3.2.x point releases either.
Officially, Google is actually worse here. The HTC Dream, the first Android phone, came out in October of 2008. The last supported version of Android was 1.6, which came out in September of 2009. Yikes, less than one year of software support from Google on their flagship device. And yes, you can root your Dream and put 2.3 on it, but you can jailbreak your iPhone and put Android 2.3 on it too, so that's not really a valid thing; we need to only consider official support. Both Apple and Google are dropping the ball on this.
The iOS simulator is different than the actual device.
Umm, sure, some googling seems to bear that out, but that's true of pretty much every emulator ever written. The goal of such simulators in the case of mobile app development isn't to perfectly emulate a given device, but to offer a generic development platform that's more convenient than loading builds onto actual hardware (something that's made very easy).
It is very important to note that every single Webkit browser works differently and that older versions of the iOS have many bugs and missing features (the new ones as well).
Chrome and Safari have a bunch of rendering problems related with HTML5 video and CSS3 as well when you start overlaying content and adding CSS transitions.
Android 2.0-2.2 also have many bugs related with HTML5 video.
OK... and? This is true of every piece of soft
1) Get a data-only SIM. Here in Canada, $35/mth gets you 5GB for a data-only SIM. In that case it's a Virgin Mobile (which is wholly owned by Bell) android tablet SIM, but there's no reason it couldn't go in an android phone instead.
2) Get an Android phone supporting 2.3 or later
3) Get an account and DID at voip.ms (no PBX required, their customer management portal can do most things Asterix can). I assume you're in the US, so that's $0.99 USD per month for the DID, $0.01 per minute incoming minutes (by 6 second increments), and $0.0105 per minute outgoing (by 6 second inc
4) Either use Android 2.3's built-in SIP support, a third-party SIP application, or some combination of the two.
Excepting that the latency on HSPA+ isn't great (130-150ms on a decent connection), it should feel pretty close to native. I regularly make Skype calls on 3G, and while it's not optimal, it works well enough.
However, if I were you, I would wait until I could get an LTE Android phone before trying this; some googling showed benchmarks of 20 to 50 milliseconds on LTE, which is a huge improvement, and more than sufficient for great VoIP quality.
you'd rather run your network on a hacked copy and risk getting screwed, like when CentOS nearly went tits up, than to actually spend a buck and help pay for your own OSes improvements
Where did I say that I run CentOS? I don't, nor do I run RHEL. I've got Windows on my desktop and laptop, Solaris on my file server, and Ubuntu on my VPS. I was simply pointing out that you were incorrect in saying that it's not relevant; your own post here only underscores the relevance, since you're arguing that CentOS has various ill effects on the ecosystem. Something doesn't have to be a positive benefit to be relevant.
Their most recent release (4.9) was two days ago (and the previous major release of 5.5 was 9 months before that), and it's used on 30% of all Linux webservers. I'd say that makes it pretty relevant. Sure, they're a bit late on the release of 6.0, but with more than a few other enterprise Linux distros working on two year release cycles, I don't think that a four month wait for the latest bleeding edge is really such a big deal; users of the 4.x and 5.x releases are still getting the latest releases on time.
I tried to convert to CFL. I bought one at the store, and tried to put it in my lamp at home. Guess what? It doesn't fit, because the neck of the CFL was far wider than an incandescent lightbulb. I had to return it.
Since then, I've kept my eye out whenever I'm at the pharmacy or other store that has CFLs; I have yet to see a single one that's actually shaped like an incandescent that will fit in my lamp (which, I should note, is a 6+ foot tell lamp from IKEA).
What am I supposed to do when Canada decides to do something similar? Buy a new lamp just because they aren't able or willing to produce CFLs in the same shape as the bulbs they aim to replace?
I'm not advocating for one over the other, only stating that sometimes you need to hit a target filesize or bitrate, and you've listed some of the reasons why you might. Fitting your video on an optical disc is one such reason. For example, the videos coming out of my camera are pretty high bitrate (almost twenty megabit). If I need to fit a video on a mini DVD, for example, that's going to need a target filesize.
No, they both do the same thing. The problem is that you have no control over filesize with quality-based encoding, so if you're trying to hit some specific target, or even if you just generally want to be in some certain range, then quality-based encoding may not be the best idea. Even getting within a certain range might take a few tries with quality-based settings, and at that point it would have been faster to do a two-pass encode.
There's a simple solution to that problem: backups.
Considering that it costs thousands of dollars to hire a recovery company for a single drive, and that tape backups (or other types of backup solutions) cost a tiny fraction of that, the solution is obvious.
You can't change the state of a flash cell without first erasing it, they already have that "self-destruct" write path. When you get an empty SSD, all the blocks are in the erased state, so each write is a simple write. If you want to rewrite anything, you must first erase it before you can write to it. That's why SSD performance slows down over time. A secure erase doesn't do any writing, it just erases all the blocks simultaneously withing having to care about which ones should be preserved.
I'm probably slightly exaggerating by saying that it happens instantly, but the last time I did a secure erase on an Intel SSD (due to getting it into a poor performance state), the process took mere seconds.
SSD secure erases are almost instant. The SSD might not be able to write to every cell simultaneously, but it *can* erase them all at the same time.
No, it wouldn't work, but only because SSDs are copy-on-write by nature, and have large amounts of spare space hidden from the OS. However, using an SSD's built-in secure erase functionality, which triggers an erase cycle on every single block of the SSD, would be sufficient; a flash cell with no electrons in the floating gate isn't going to reveal any secrets.
It should be noted that the multiple rewrites thing is only require for "old school" HDDs. Modern magnetic HDs only need a single pass (as referenced by the wikipedia article that you cite).
SandForce SSD controllers encrypt all data as it hits the SSD. That does nothing to protect against plugging the drive into a computer and using it (a secure delete would handle that), but it *does* protect against people accessing the NAND chips directly. That and the fact that SandForce drives use compression/deduplication/other tricks and properly support secure erase would make it exceedingly difficult to recover data.
They've had actual silicon for 12 days. They may have been too busy showing it off to the press to sit down and plug it into a killawatt.
Referencing the Anandtech article, nVidia claims that for the same workload, it is as efficient or more efficient than the Tegra 2, but if you increase the workload, it'll obviously use a bunch more power.
The Motorola Atrix also has a dock that does exactly that. The dock has a few USB ports for keyboards/mice, and HDMI out to plug in a desktop monitor.
"MeeGo smartphones and tablet devices will offer overwhelmingly superior experiences and applications than iOS and Android based competitor products."
Clearly they have a firm grip on reality. I'm not saying that MeeGo won't be a decent platform, but claiming that it will ovfer an "overwhelmingly superior experience" to the other market leaders who have multi-year head starts is silly.
That'd be the distance, yes. I tried OnLive in Montreal (my ISP bounces me through Toronto), for a total path (by car) of ~1300KM. The recommended range of OnLive to their datacenters is ~1600KM. So, I'm not optimal, but I'm well within range.
My experience was that latency was acceptable (I was surprised, really, how low it was) and that people at shorter ranges might even see latencies below a typical console game (console games tend to have massive input latency compared to PC games).
However, the video quality was exceptionally poor. This is not a bandwidth thing, since onlive does not appear to adapt to the available bandwidth; if your connection slows down too much, it drops frames, and then disconnects you if it continues (also, I was testing with a 50Mbps cable line). This was purely a matter of their bitrate being too low (or their h.264-like encoder not being efficient enough). Slower-paced games might be OK, but vehicular combat in Unreal Tournament 3 was unplayable; as soon as the vehicle was moving at speed, the screen devolved into a blurry mess. I couldn't aim at enemies properly because I couldn't see them.
I think there's potential for the service, though. Latency, while not bad, could be improved with more regional datacenters (Toronto would shave off most of the latency for me), and image quality can be improved by cranking up the bitrate (I don't think they can make codec changes since they're producing hardware).
TFA is suggesting a pointless solution, though. TFA suggests that instead of an algorithm that allows an attacker to check 2300 million hashes per second, we use something that can limits current hardware to 10 thousand per second. That's all well and good, except that Moore's law will raise that back to 2300 million after 27 years... and that's assuming that the ability to generate these things doesn't increase faster than Moore's law. Certainly the introduction of GPGPU computing gave us a performance leap far in excess of Moore's law for this sort of stuff. A willingness to increase power consumption, for example, allows you to scale performance beyond Moore's law.
The author suggests that we use an algorithm where "Computational time required can be adjusted easily when processing power increases" but this doesn't completely solve the problem; keys generated before changing the algorithm will still be crackable with the old processing requirements.
In principle, many Canadians agree with you. In practice, Bell set the caps/charges at 25GB and $2 per gig overage.
If it was 250GB and $0.10 overage, we wouldn't be in this mess. But when I have to pay $50 in bandwidth to download a videogame from the playstation network, or pay $4 an hour to watch netflix, something is wrong.
Unlikely. Sony essentially took current smartphone tech and scaled it up. Smartphones are starting to ship with dual-core Cortex A9 processors, Sony threw in a quad-core. Smartphones are starting to ship with single-core PowerVR SGX540s, Sony through in four of 'em.
The reason you won't see this in 6 months from smartphone vendors is because Sony has a bigger power budget; the PSP doesn't have to be as small and light as a smartphone, so they can afford to burn a lot less power. The NGP probably draws three times more power than a typical smartphone, and 6 months isn't enough time to counterbalance that.
18 months, maybe, that's enough for Moore's law to take effect, but since dual-core Cortex A9 smartphones *just* hit the market, 6 months is silly.
I've never had that problem over nine years of using wireless mice (for gaming as well as other use). Wireless mice are presented to the OS just like wired mice, there is no reason why an antivirus scan should kill your mouse; something is wrong with your computer.