Because it's relevant to the viability of the platform. The SGX540 is not particularly modern or competitive, so it holds back the rest of the platform. The fact that Intel is also licensing a third-party GPU (and talking about their future migration to the SGX543, also third-party) rather than using their own GPU is not particularly reassuring.
As a pure CPU, Medfield looks pretty decent. As an SoC, it's unimpressive. There's way more to an SoC than the CPU.
For the most part, they don't need to. Android has already been ported, and 75% of the apps for Android are written with the standard SDK, meaning they're cross-platform Java applets.
That leaves the 25% of remaining apps that are written with the NDK. Of those, most can be recompiled by the developer with minimal effort (the NDK supports building for x86 or ARM, and most apps wouldn't require any changes to recompile). Of those that can't, or aren't, Intel is going to be supplying binary translation software (read: emulation). That part won't run all that great, but it will run.
Basically, the point is that Android is particularly well-suited to switching between architectures because not much of it (or its apps) is architecture-dependent.
If you consider that mirrorless interchangeable lens cameras have much less distance between the lens and the sensor than DSLRs, regardless of sensor size, then yes, it is.
While it's true that micro fourthirds and fourthirds (used on their consumer DSLRs, since higher end ones would be full frame) use the same sized sensor, and Sony's e-mount cameras also use an APS-C sensor similar in size to their consumer DSLRs, the optics are different, so you're not going to get the same properties out of them in terms of depth of field, for example.
Cellphone sensors are smaller than anything on this chart, Point & Shoot cameras are the 1/2.5" to 1/1.6" sizes (typically closer to 1/2.5" these days), and the rest should be obvious. You only hit full frame on prosumer cameras, like the Canon 5D series or the Leica M9 (and others from Sony, Nikon, etc) nothing below that.
I understand the concepts behind compression, I was just pointing out the limitations of block-based deduplication... It only works optimally when your writes are block-aligned, and it only works decently when you're not inserting or removing data from the middle of a file. Archive-based compression rarely works in many of the places that you'd use deduplication.
I'm aware of all this, and I think that generally it can work out well, but it doesn't guarantee future compatibility if somebody wants to go and do their own thing and then that thing becomes popular. And the interoperability between ZFS and Solaris was my primary concern, although to be honest I'll probably never run "real" Solaris again since it's not free anymore, so I probably shouldn't care about that either.
It does sound like a decent tradeoff; ZFS deduplication, I can say from personal experience with my home file server that has a deduplicated filesystem used for incremental backups, is painfully slow when you don't have enough RAM. So the idea that you do a best-effort deduplication on write and a best-quality deduplication offline each night would be a big improvement.
What sort of timespans are involved in doing offline deduplications when multiple passes are required? Is it the kind of thing you can do every night on a large deduplicated data set?
Certainly, there are many scenarios where block-level deduplication does wonders. It just doesn't work well in all cases. For example, trying to use deduplication to store incremental database backups. Record sizes are not fixed in a sql dump, so you're likely to waste large amounts of space for small differences. I do use ZFS deduplication to store incremental backups from a variety of machines, and generally it works well, but the SQL dumps were one of the annoying bits.
HAMMER's online deduplication doesn't need an incredible amount of memory because it will only match duplicate block that it has the checksums of cached. If the checksum is not cached, HAMMER won't deduplicate the block even if a duplicate exists on disk, because it won't know the duplicate exists. That's my interpretation of the coder's explanation, anyhow ( http://leaf.dragonflybsd.org/mailarchive/users/2011-04/msg00044.html ).
HAMMER's offline deduplication doesn't have this limitation because it can re-iterate as many times as is required to compare each checksum, but that's not helpful if you want (or require) online deduplication.
With deduplication, RAM is more important than CPU speed. If you can fit the checksums for every block of data in RAM, then you're golden. If not, deduplication can get extremely slow, no matter how fast the processor.
So long as you never add or remove data from the middle of the file, sure. Otherwise a one byte change in either direction can require re-storing all the rest of the unchanged data because it might not line up on the same block boundaries.
ZFS deduplication works on a block level, so it's not only storing the differences. That would require byte-level deduplication.
For example, imagine I had a block size of two bytes, and had the following two files:
02468A 012468A
These two pieces of data are identical except for one inserted byte, but deduplication will be forced to store both files in their entirety. Why? Because even though only one byte changed, none of the blocks are identical:
02 46 8A 01 24 68 A-
This is a fairly common case in many kinds of modified files. Imagine trying to deduplicate ISOs where one file in the middle of the ISO changed, or a word processor document where I fixed a typo by adding an extra letter to a word...
Don't get me wrong, there is still a big savings to be had in the average case with block-level deduplication, but there are limitations.
It means, however, that ZFS is now forked. ZFS volumes from future Solaris releases may be incompatible with future versions of FreeBSD (or IllumOS or whatnot). And the new approach that they're taking to define which new features are supported is flexible, but opens the door to situations where you can't mount a filesystem because your OS is missing some individual feature that the devs chose not to implement (ZFS currently goes by backwards compatible versions of the filesystem, the new forked version works based on feature flags).
To be honest, I don't see the latter being much of a problem, but the former (lack of inter compatibility with "official" ZFS) is annoying. Perhaps the forked version should change the name to something other than ZFS to avoid confusion.
Slicehost doesn't exist anymore; Rackspace bought them, let the service languish without improvements (while competitors continued to improve), and then killed it off by forcing customers to migrate to Rackspace's way more expensive services.
My understanding is that many Slicehost customers migrated to Linode, since it was always the closest competitor anyhow.
I've been with maybe a half dozen hosts over the past decade or so, from the biggest in the world to one of the smallest. Not one of them managed to come anywhere close to Linode in terms of reliability and quality of service. Yes, they're a premium provider (not in the business of massive overselling to offer super low prices for super high amounts of bandwidth), but at $20 a month for their entry level offering, the barrier to entry is not high.
They've got six datacenters spread out over the world (leased space, obviously), run pretty high-performance boxes (dual quad-core xeons with low contention, 15K RPM SAS drives in RAID-10, etc), have a large degree of automation (so most requests happen instantly since no human has to intervene), support pvgrub for loading your own kernels if you want, have an active community on IRC (where most of their staff idle) and forums, offer more flexibility than even a dedicated server (management interface lets you do everything down to repartition your disk space and install random operating systems, if you want, although anything but Linux is unsupported, upgrading or resizing your VPS takes only the time to migrate it to another homogeneous host box), they use Xen (similar to KVM) for real virtualization, they provide out-of-band console access via a virtual serial port (ssh to the host box or use an ajax terminal), etc. I could keep listing features, but it's better to just visit their site and read up. I'll leave with another parting shot about their management interface (which has smartphone app versions too) being awesome.
It doesn't hurt the range because of the battery being cold, it hurts the range because of the battery warmer keeping the battery from getting cold, and the heating the car itself. You can probably still do something like 300KM in cold weather, although that's tight enough that you may require a second refueling stop. Then again, the Model S also supports battery swapping, so you can go from 0% to 100% charge in under a minute.
It should actually also be noted that the Model S supports battery switching, in which an automated station can just completely swap out your battery in about a minute, making refuelling faster than a gasoline car.
It's difficult to know how much this would reduce the range. The best guess I can say is you should still get about 300KM out of the larger capacity model under cold conditions (based on the Nissan Leaf's EPA testing data), which is still sufficient to get to the destination, but that's cutting it rather close. You may need two refuelling stops along the way instead, which would indeed lengthen your trip. The charge is fast enough to not be a huge issue, though. Just an inconvenience. Again, providing that the refuelling stations are available. Anyhow, it's hard to guess, because the data for the Leaf isn't an apples to apples comparison, and I've no idea how the insulation and heating system efficiency on the Model S would compare to a Leaf.
45 minutes gets you 80% of capacity. If I wanted to drive from Montreal to Toronto (545KM) with the high-capacity model S (480KM range), you're looking at one single 45 minute refueling stop halfway. So yeah, the trip that takes 6h13m in a gas car now takes 6h58m in the electric car, but that's not a huge difference. And, to be honest, most people stop halfway for lunch when driving to Toronto anyhow, so if you can charge midway while eating, you're potentially not using up any extra time at all.
All this presupposes that there's a recharging station halfway between Montreal and Toronto, although since they're the two largest cities in the country and it's one of the most heavily traveled routes in the country, it's not an unreasonable thing to expect we'll see some recharging stations along that route eventually.
It's $49.9k *after* the tax credits, so it's not actually $40k. Let's call it $50k to be safer.
The thing is, the Roadster cost $109k, so this is already a huge price drop compared to that. That's been Tesla's strategy all along. The new tech will initially be expensive, so sell it as a premium product and use the revenues from that to develop the tech farther, driving down the cost. They've said that this is a three-phase process, and the model S is the second phase. Even the difference between $109k and $50k is a big one, and it brings the pricing into the affordable range for a much larger number of people, particularly if leasing is considered.
Comparing it to other similar cars, it's not a bad deal either. The Nissan Leaf sells for ~$35k, with a 24 kWh battery. The basic model S sells for ~$50k, with a 40 kWh battery, and is a higher-end vehicle. The range is substantially improved, and there's the (very expensive) option for larger batteries that get it within shouting distance of the range of a gasoline vehicle.
Anyhow, the point was that the model S opens up a much larger market to Tesla, which will give them the revenue and scale to work on the third phase of their plan, an electric car that is cheap enough that it can be afforded by the average person. The Roadster was $109k, the Model S was $50k, and they're planning for their third phase, codenamed BlueStar, to sell for $30k. That's not going to compete with a Toyota Yaris/Vitz, but it could compete favourably with a Camry or Avalon, perhaps. They were originally talking about getting the BlueStar out in 2013-2014, but they're now talking about being able to do it in 2015-2016. I'd imagine that battery pricing/technology is the primary limiting factor at this point.
Well, a standard high-performance dual-core Cortex A9 (clockspeed of up to 2GHz) has a TDP of 1.9W, while the low-power version (clockspeed of 800MHz) has a TDP of 0.5W. In either case, that's way more than the 0.035 watts being given as the peak usage.
Not to mention that the Nook's processor uses a hell of a lot more than 35 milliwatts when doing work. It might survive on that when idle, but not active...
The vast majority of "these things", with "these things" being the key part there. Google is great at searching for stuff, but it doesn't search for information, it searches for pages.
If I google for "What is the population of Barnsley?", then unlike you I get only one result: 73,500, which is presented as a "best guess" without any identifying info (Wolfram Alpha reports that the population is 71,447, as of 2004, which at least lets me know when the estimate is from). Because remember, unless you're getting the result from Google itself directly, it's not really useful for many classes of application. Yes, the first SEARCH result on Google shows me the other info, but that's on some page that I'm going to have to go read to find the info. That doesn't work; what are you going to present as the Majel result, a wikipedia page? The user just wants that one piece of info, not the whole history of Barnsley.
That's the part that I'm comparing between Google and Wolfram Alpha; the ability to return direct information. And it's an area in which Wolfram Alpha is currently ahead in three ways.
Firstly, Wolfram Alpha handles more variation in language. This is probably an artifact of how Google is a general search engine that sometimes should be expected to return data directly, and Wolfram Alpha is expected to ALWAYS return some data, because that's the sole purpose. Google does a great job at currency conversion, I use it all the time. If I ask it for "104.55 cad in usd", it gives me a direct result (~102.02) But if I google for "104.55 cad", it returns no data. Wolfram Alpha, however, will give me data for "104.55 cad". It will tell me how much that is worth in a few common currencies. The same is true for "how much is 104.55 cad", which might be a more natural query to make. Google gives no data, Wolfram Alpha can interpret that properly and gives me info.
The second area is the breadth of the type of problem or data it can solve. Google only activates the calculator functionality for a pretty narrow set of problems. Mathematical calculations, where it usually (but not always) figures out you're trying to get a result, requests for population figures, currency and other unit conversions, etc. But ask Google "Who was Steve Jobs?", and it gives you nothing. Yes, it will search for that, and the first result is Wikipedia, and that's relevant, but it gives you no actual data. Wolfram Alpha, on the other hand, gives me direct information. Some basic facts like his full name, place and date of birth and death, some notable facts, a graph of his net worth, etc. This is just one example, I'm not trying to be exhaustive here. There are a lot of other classes of "problem" where Wolfram Alpha can give me direct and relevant results, while Google just does a generic web search.
The third area is kind of related to the second, and that's the breadth of data. Your example of changing a headlight is a fail in both cases, because Google can't tell you how to do that, it can only point you to a video to do so. But as I mentioned in the previous question, Google Calculator (or whatever they call their "give you direct data" stuff, since it's moved beyond just calculating these days) is pretty limited in scope, while Wolfram Alpha has obviously put more effort into feeding data into their system.
The headlight thing isn't actually a problem, because Siri or Majel should not be using Wolfram Alpha for every query. That's one of the hardest things about implementing something like that, I think. There's the speech recognition part, there's the natural language parsing part, and then there's the figuring out which source to use for which query part. If you ask Siri how to change a headlight, she should do a google video search and give you your how-to video. If you ask Siri what the population of Barnsley is, she should give you the direct data from Wolfram Alpha. Majel should do the same sort of thing.
I can understand if Google chooses not to license Wolfram Alpha. It's a very impressive system that i
Slashdot Mirror
Because it's relevant to the viability of the platform. The SGX540 is not particularly modern or competitive, so it holds back the rest of the platform. The fact that Intel is also licensing a third-party GPU (and talking about their future migration to the SGX543, also third-party) rather than using their own GPU is not particularly reassuring.
As a pure CPU, Medfield looks pretty decent. As an SoC, it's unimpressive. There's way more to an SoC than the CPU.
For the most part, they don't need to. Android has already been ported, and 75% of the apps for Android are written with the standard SDK, meaning they're cross-platform Java applets.
That leaves the 25% of remaining apps that are written with the NDK. Of those, most can be recompiled by the developer with minimal effort (the NDK supports building for x86 or ARM, and most apps wouldn't require any changes to recompile). Of those that can't, or aren't, Intel is going to be supplying binary translation software (read: emulation). That part won't run all that great, but it will run.
Basically, the point is that Android is particularly well-suited to switching between architectures because not much of it (or its apps) is architecture-dependent.
If you consider that mirrorless interchangeable lens cameras have much less distance between the lens and the sensor than DSLRs, regardless of sensor size, then yes, it is.
While it's true that micro fourthirds and fourthirds (used on their consumer DSLRs, since higher end ones would be full frame) use the same sized sensor, and Sony's e-mount cameras also use an APS-C sensor similar in size to their consumer DSLRs, the optics are different, so you're not going to get the same properties out of them in terms of depth of field, for example.
This is a pretty good illustration:
https://en.wikipedia.org/wiki/File:Sensor_sizes_overlaid_inside.svg
Cellphone sensors are smaller than anything on this chart, Point & Shoot cameras are the 1/2.5" to 1/1.6" sizes (typically closer to 1/2.5" these days), and the rest should be obvious. You only hit full frame on prosumer cameras, like the Canon 5D series or the Leica M9 (and others from Sony, Nikon, etc) nothing below that.
I understand the concepts behind compression, I was just pointing out the limitations of block-based deduplication... It only works optimally when your writes are block-aligned, and it only works decently when you're not inserting or removing data from the middle of a file. Archive-based compression rarely works in many of the places that you'd use deduplication.
I'm aware of all this, and I think that generally it can work out well, but it doesn't guarantee future compatibility if somebody wants to go and do their own thing and then that thing becomes popular. And the interoperability between ZFS and Solaris was my primary concern, although to be honest I'll probably never run "real" Solaris again since it's not free anymore, so I probably shouldn't care about that either.
It does sound like a decent tradeoff; ZFS deduplication, I can say from personal experience with my home file server that has a deduplicated filesystem used for incremental backups, is painfully slow when you don't have enough RAM. So the idea that you do a best-effort deduplication on write and a best-quality deduplication offline each night would be a big improvement.
What sort of timespans are involved in doing offline deduplications when multiple passes are required? Is it the kind of thing you can do every night on a large deduplicated data set?
Certainly, there are many scenarios where block-level deduplication does wonders. It just doesn't work well in all cases. For example, trying to use deduplication to store incremental database backups. Record sizes are not fixed in a sql dump, so you're likely to waste large amounts of space for small differences. I do use ZFS deduplication to store incremental backups from a variety of machines, and generally it works well, but the SQL dumps were one of the annoying bits.
HAMMER's online deduplication doesn't need an incredible amount of memory because it will only match duplicate block that it has the checksums of cached. If the checksum is not cached, HAMMER won't deduplicate the block even if a duplicate exists on disk, because it won't know the duplicate exists. That's my interpretation of the coder's explanation, anyhow ( http://leaf.dragonflybsd.org/mailarchive/users/2011-04/msg00044.html ).
HAMMER's offline deduplication doesn't have this limitation because it can re-iterate as many times as is required to compare each checksum, but that's not helpful if you want (or require) online deduplication.
With deduplication, RAM is more important than CPU speed. If you can fit the checksums for every block of data in RAM, then you're golden. If not, deduplication can get extremely slow, no matter how fast the processor.
So long as you never add or remove data from the middle of the file, sure. Otherwise a one byte change in either direction can require re-storing all the rest of the unchanged data because it might not line up on the same block boundaries.
ZFS deduplication works on a block level, so it's not only storing the differences. That would require byte-level deduplication.
For example, imagine I had a block size of two bytes, and had the following two files:
02468A
012468A
These two pieces of data are identical except for one inserted byte, but deduplication will be forced to store both files in their entirety. Why? Because even though only one byte changed, none of the blocks are identical:
02 46 8A
01 24 68 A-
This is a fairly common case in many kinds of modified files. Imagine trying to deduplicate ISOs where one file in the middle of the ISO changed, or a word processor document where I fixed a typo by adding an extra letter to a word...
Don't get me wrong, there is still a big savings to be had in the average case with block-level deduplication, but there are limitations.
It means, however, that ZFS is now forked. ZFS volumes from future Solaris releases may be incompatible with future versions of FreeBSD (or IllumOS or whatnot). And the new approach that they're taking to define which new features are supported is flexible, but opens the door to situations where you can't mount a filesystem because your OS is missing some individual feature that the devs chose not to implement (ZFS currently goes by backwards compatible versions of the filesystem, the new forked version works based on feature flags).
To be honest, I don't see the latter being much of a problem, but the former (lack of inter compatibility with "official" ZFS) is annoying. Perhaps the forked version should change the name to something other than ZFS to avoid confusion.
Those kind of specs mean they're horrendously overselling. Anybody who uses that sort of service is asking for it.
They didn't really have a clear idea what they were doing when hardware failed and because of that I don't feel comfortable recommending them.
Considering that Linode's staff don't do work in the datacenters (they rely on remote hands & eyes), I'm not sure how you could get that impression.
Slicehost doesn't exist anymore; Rackspace bought them, let the service languish without improvements (while competitors continued to improve), and then killed it off by forcing customers to migrate to Rackspace's way more expensive services.
My understanding is that many Slicehost customers migrated to Linode, since it was always the closest competitor anyhow.
I've been with maybe a half dozen hosts over the past decade or so, from the biggest in the world to one of the smallest. Not one of them managed to come anywhere close to Linode in terms of reliability and quality of service. Yes, they're a premium provider (not in the business of massive overselling to offer super low prices for super high amounts of bandwidth), but at $20 a month for their entry level offering, the barrier to entry is not high.
They've got six datacenters spread out over the world (leased space, obviously), run pretty high-performance boxes (dual quad-core xeons with low contention, 15K RPM SAS drives in RAID-10, etc), have a large degree of automation (so most requests happen instantly since no human has to intervene), support pvgrub for loading your own kernels if you want, have an active community on IRC (where most of their staff idle) and forums, offer more flexibility than even a dedicated server (management interface lets you do everything down to repartition your disk space and install random operating systems, if you want, although anything but Linux is unsupported, upgrading or resizing your VPS takes only the time to migrate it to another homogeneous host box), they use Xen (similar to KVM) for real virtualization, they provide out-of-band console access via a virtual serial port (ssh to the host box or use an ajax terminal), etc. I could keep listing features, but it's better to just visit their site and read up. I'll leave with another parting shot about their management interface (which has smartphone app versions too) being awesome.
It doesn't hurt the range because of the battery being cold, it hurts the range because of the battery warmer keeping the battery from getting cold, and the heating the car itself. You can probably still do something like 300KM in cold weather, although that's tight enough that you may require a second refueling stop. Then again, the Model S also supports battery swapping, so you can go from 0% to 100% charge in under a minute.
It should actually also be noted that the Model S supports battery switching, in which an automated station can just completely swap out your battery in about a minute, making refuelling faster than a gasoline car.
It's difficult to know how much this would reduce the range. The best guess I can say is you should still get about 300KM out of the larger capacity model under cold conditions (based on the Nissan Leaf's EPA testing data), which is still sufficient to get to the destination, but that's cutting it rather close. You may need two refuelling stops along the way instead, which would indeed lengthen your trip. The charge is fast enough to not be a huge issue, though. Just an inconvenience. Again, providing that the refuelling stations are available. Anyhow, it's hard to guess, because the data for the Leaf isn't an apples to apples comparison, and I've no idea how the insulation and heating system efficiency on the Model S would compare to a Leaf.
45 minutes gets you 80% of capacity. If I wanted to drive from Montreal to Toronto (545KM) with the high-capacity model S (480KM range), you're looking at one single 45 minute refueling stop halfway. So yeah, the trip that takes 6h13m in a gas car now takes 6h58m in the electric car, but that's not a huge difference. And, to be honest, most people stop halfway for lunch when driving to Toronto anyhow, so if you can charge midway while eating, you're potentially not using up any extra time at all.
All this presupposes that there's a recharging station halfway between Montreal and Toronto, although since they're the two largest cities in the country and it's one of the most heavily traveled routes in the country, it's not an unreasonable thing to expect we'll see some recharging stations along that route eventually.
It's $49.9k *after* the tax credits, so it's not actually $40k. Let's call it $50k to be safer.
The thing is, the Roadster cost $109k, so this is already a huge price drop compared to that. That's been Tesla's strategy all along. The new tech will initially be expensive, so sell it as a premium product and use the revenues from that to develop the tech farther, driving down the cost. They've said that this is a three-phase process, and the model S is the second phase. Even the difference between $109k and $50k is a big one, and it brings the pricing into the affordable range for a much larger number of people, particularly if leasing is considered.
Comparing it to other similar cars, it's not a bad deal either. The Nissan Leaf sells for ~$35k, with a 24 kWh battery. The basic model S sells for ~$50k, with a 40 kWh battery, and is a higher-end vehicle. The range is substantially improved, and there's the (very expensive) option for larger batteries that get it within shouting distance of the range of a gasoline vehicle.
Anyhow, the point was that the model S opens up a much larger market to Tesla, which will give them the revenue and scale to work on the third phase of their plan, an electric car that is cheap enough that it can be afforded by the average person. The Roadster was $109k, the Model S was $50k, and they're planning for their third phase, codenamed BlueStar, to sell for $30k. That's not going to compete with a Toyota Yaris/Vitz, but it could compete favourably with a Camry or Avalon, perhaps. They were originally talking about getting the BlueStar out in 2013-2014, but they're now talking about being able to do it in 2015-2016. I'd imagine that battery pricing/technology is the primary limiting factor at this point.
Well, a standard high-performance dual-core Cortex A9 (clockspeed of up to 2GHz) has a TDP of 1.9W, while the low-power version (clockspeed of 800MHz) has a TDP of 0.5W. In either case, that's way more than the 0.035 watts being given as the peak usage.
Not to mention that the Nook's processor uses a hell of a lot more than 35 milliwatts when doing work. It might survive on that when idle, but not active...
The vast majority of "these things", with "these things" being the key part there. Google is great at searching for stuff, but it doesn't search for information, it searches for pages.
If I google for "What is the population of Barnsley?", then unlike you I get only one result: 73,500, which is presented as a "best guess" without any identifying info (Wolfram Alpha reports that the population is 71,447, as of 2004, which at least lets me know when the estimate is from). Because remember, unless you're getting the result from Google itself directly, it's not really useful for many classes of application. Yes, the first SEARCH result on Google shows me the other info, but that's on some page that I'm going to have to go read to find the info. That doesn't work; what are you going to present as the Majel result, a wikipedia page? The user just wants that one piece of info, not the whole history of Barnsley.
That's the part that I'm comparing between Google and Wolfram Alpha; the ability to return direct information. And it's an area in which Wolfram Alpha is currently ahead in three ways.
Firstly, Wolfram Alpha handles more variation in language. This is probably an artifact of how Google is a general search engine that sometimes should be expected to return data directly, and Wolfram Alpha is expected to ALWAYS return some data, because that's the sole purpose. Google does a great job at currency conversion, I use it all the time. If I ask it for "104.55 cad in usd", it gives me a direct result (~102.02) But if I google for "104.55 cad", it returns no data. Wolfram Alpha, however, will give me data for "104.55 cad". It will tell me how much that is worth in a few common currencies. The same is true for "how much is 104.55 cad", which might be a more natural query to make. Google gives no data, Wolfram Alpha can interpret that properly and gives me info.
The second area is the breadth of the type of problem or data it can solve. Google only activates the calculator functionality for a pretty narrow set of problems. Mathematical calculations, where it usually (but not always) figures out you're trying to get a result, requests for population figures, currency and other unit conversions, etc. But ask Google "Who was Steve Jobs?", and it gives you nothing. Yes, it will search for that, and the first result is Wikipedia, and that's relevant, but it gives you no actual data. Wolfram Alpha, on the other hand, gives me direct information. Some basic facts like his full name, place and date of birth and death, some notable facts, a graph of his net worth, etc. This is just one example, I'm not trying to be exhaustive here. There are a lot of other classes of "problem" where Wolfram Alpha can give me direct and relevant results, while Google just does a generic web search.
The third area is kind of related to the second, and that's the breadth of data. Your example of changing a headlight is a fail in both cases, because Google can't tell you how to do that, it can only point you to a video to do so. But as I mentioned in the previous question, Google Calculator (or whatever they call their "give you direct data" stuff, since it's moved beyond just calculating these days) is pretty limited in scope, while Wolfram Alpha has obviously put more effort into feeding data into their system.
The headlight thing isn't actually a problem, because Siri or Majel should not be using Wolfram Alpha for every query. That's one of the hardest things about implementing something like that, I think. There's the speech recognition part, there's the natural language parsing part, and then there's the figuring out which source to use for which query part. If you ask Siri how to change a headlight, she should do a google video search and give you your how-to video. If you ask Siri what the population of Barnsley is, she should give you the direct data from Wolfram Alpha. Majel should do the same sort of thing.
I can understand if Google chooses not to license Wolfram Alpha. It's a very impressive system that i