However, you said "just by visiting", I said "you have to click" and you said "click"...
I think the difference is clicking on a search result in google, vs clicking on something like a viagra ad or fake antivirus ad on the page that result took you to. You would expect the search result to be benign -- you have no way of differentiating one thumbnail in your search results from another with respect to malicousness -- this is the SEO poisoning part of the exploit.
The advantage of Safari's approach is that they don't define "safe". This allows Apple to adjust the safety heuristics from update to update without changing the default security setting.
That's the part I can't find mentioned anywhere -- what exactly constitutes a "safe" file? Is that the 'exploit' here? That somebody has figured out how to pose as a "safe" file?
Well, of all the million times large corporations try to gather information on people (search data, location data, address information, email addresses, credit card information, boxers or briefs.....) this seems like one of the few situations where the reason is completely legit.. We're always told (by whatever company) that they will be able to offer us better services once they have X data.
In this case, the benifit isn't some cloudy non-tangible thing in the distant future and of questionable value. It's immediate and pertinant information. You just tried connecting to a network, and now you know if you have internet connectivity or not.
That reminds me, Miguel already has a dual personality with his proclaimed love of open source yet his constant admiration for everything made by Microsoft.
Weak. The guy that gave the world Gnome has already benifited you more in your life than you can ever hope to repay him.
After banging my head against the Hyper-V headache for two days
I use hyper-v for testing my apps on multiple OS versions. It takes me less than 1 minute to configure a VM. This excludes any time spent copying VHDs across the network, if any. You took 2 days and you still haven't figured it out?
Do you ever accuse Microsoft of FUDing? Will you excuse me for pointing out the irony?
There's more.. if you're doing mobile development and you're trying to debug something, you have your IDE window (and it's 10+ docks) on one monitor, your mobile emulator, documentation, memory windows, etc. etc. on the other two screens. Regular development is easier on 2 screens. Mobile development is best done with 3. 2 is workable for mobile. 1 is just painful.
AFAIK, in Win7 UAC uses both whitelists, and blacklists, and is also configurable in terms of what it will prompt you for (haven't looked up level of granularity.. couldn't really be bothered)..
Why on gods green earth do you run Visual Studio elevated? IIRC there was a bug that requried that some time ago, but has been fixed since a very very long time.
I could believe them.. you think it's less than that? I know Win7 is pretty rock solid, but users will still find ways to defeat security measures, y'know..
Not sure if you're joking or serious. You know it's both right? 3 thousadths of win7 PCs used to be infected, now 4 thousdandths are infected. That's a difference of 1 thousandths, or 33%, depending on how you choose to represent it.
Lastly -- that's only for 32-bit win7. 64-bit win7 is more resiliant according to the article, but not enough data to work out exactly what that means (before and after numbers from x64 win7 not provided, relative installed base of 32 and 64 bit win7 not provided).
Or they could do what Google's security researchers do when they find an issue in an MS product -- release the details to the world within 48 hours (those 48 hours being Saturday and Sunday).
You are just babbling, and....... looking for an argument
I replied as AC to put a stop to the nonsense, and you came back with a santimonious lecture about etiquette. Further -- when you say something I agree with, I freely admit it (see the disk encryption scenario you mentioned). To each their own I guess.
You are not so much interested in looking for uses for cores
Correct. A sane design approach is to understand use profiles and requirements, and then solve them. Proposing 64 core CPUs without first having a need for it is a backwards approach. The use case you pointed out a thread above (mesh networking + encryption + video redirection + language conversion, simultaneously mind you) would cover what -- 0.09% of smartphone users? Never mind the point that 64 general purpose cores is still an inefficient approach for addressing it. And you persistently ignore issues related to finite battery life, and limited heat dissipation capabilities in a smartphone form factor.
I'd rather let you think you won
I feel like I've won when I've had a rational discussion, and one or both parties come away with a bit of insight. I fear I might have polarized you into a particular line of thinking that I am very certain is limited. I hate it when that happens.
showing you how much advantage a bit of imagination could be.
Imagination is a wonderful thing. A little bit of real-world engineering does have a habit of raining on the imagination parade from time to time.
Encrypting stuff on the fly is a great example. Let's say you benefit from having a core for that, in addition to your existing core. So you're at 2 cores now, with 62 left to go. I do understand that several ciphers will benefit from extra cores, but you have a device with finite storage, and finite battery power, so it begs the question as to how much stuff you're encrypting that you need to dedicate more than 1 core to it.
Video redirection is very unclear -- I don't see it as a moblie workload -- but perhaps I don't get your scenario yet. In any case, that seems like a completely data-bound process.
Mesh networking (any networking), given a standard protocol is not something the CPU should be taxed with. It should be 99% I/O bound
Language conversion (I don't know your exact scenario -- is this text, speech, what is it?) is not something you can do even today, even with 64 (or more) cores -- so it'll be a while before you have an application that attempts to do that on the phone. Language conversion apps require some serious data backing and number crunching -- it's best implemented as a cloud service that you stream the audio to, and it returns back the results -- very similar to how voice search apps on phones currently work (or say, similar to something like Shazam).
You have it backwards. The correct question is if I have 64 cores I didn't have at my disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the ancestral architecture.
Very well then, if you have 64 cores that you didn't have at your disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the current (ancestral assumes shared lineage) architecture?
I especially like the way he switched to posting as AC so he can keep spouting his nonsense while effectively putting his fingers in his ears and shouting NA NA NA NA. It doesn't leave much wonder why he is so clueless.
And we've entered a fact-free zone and reduced to childish bickering.
Let's take this down a notch. It does nobody any good to be disrespectful. Let's be specific -- what *problem* with current SOC implementations do you think a 64 core CPU will solve? For arguments sake, and for sanity, lets assume 4 of them are integer cores, and 60 (odd number, but what can you do) of them are FPU cores. What problem is it solving, or how is it better?
Also, what is to say we won't be pulling all these DSP units into the processor again?
They are already there. Every single function we've takled about has dedicated silicon for it, *inside one single chip*, which also includes the CPU. Aaargghh!
Pentium brought in some of the graphics processing, so on and so forth
Same point. Already done. Read up SOC architechture before replying. Look up a block diagram of what lives on a single chip for say a tegra or a snapdragon.
The newest CPUs from Intel and AMD both brought the "video card" into the processor, but there are still many chips outside of the CPU; audio, southbridge, bluetooth, wifi, etc.
Same point. Already done. Smartphone processors integrate all the functions into one single chip. Please, please, please do a little reading before replying again.
Not really -- on an old 486 or pentium (single core obviously) did you never have say outlook running in the background, while playing need for speed? At the most, you might need 2 cores to ensure jitter-free gaming during an event such as receiving a new email (etc). Beyond that, the game developers care a hell of a lot more about your SOC a good GPU.
Don't get me wrong -- i'm all for crazy fast processors -- it's just that the importance of processor speed (and cores in this case) is often completely misunderstood. Even in modern desktops, you're often in a situation where your quad-core i7 with dual hyperthreading (so 8 cores, depending on how you count) has at least 4 cores sitting in a state of utter and complete data-starvation. To solve data starvation issues, you need either more paralell (or parallelizable) workloads, and greater I/O bandwidth (more cache at each level, faster cache at each level, more RAM, faster RAM, wider RAM buses, more data per clock (ddr/qdr), faster hdd/ssd, lower latency hdd/ssd, faster and wider i/o bus, faster network, lower latency network, etc.). Just adding cores doesn't make something faster -- you need work for those cores to do, otherwise they're just sitting there consuming your battery. Worse -- if you have 64 super tiny ultra minimal cores each of them is guaranteed to be a very inferior integer pipeline compared to what you get in a full-blow ARM Cortext (for example). So when you are single tasking on a non-parallizeable workload (say checking email), you're only going to be able to use a tiny handful of your 64 cores, and that application will be slow as molasses. And consume more power while doing so. And when you do use all your cores by doing something like video decoding you'll still barely achieve the results that dedicated DSPs (that are already present in current-day SOCs) already achieve, and you'll take way more power doing so.
Disclaimer: There are some overgeneralizations in what I said, but the gist of it holds true. Bottom line: in the quest for awesome speed, people are salivating over something that will turn smartphones into slugs. It's like people drooling over the old Pentium 4 (netburst) gigahertz all over again, only to realize that the so-called fastest PC processor is actually a dog, an expensive one at that, and it generates insane amounts of heat. Sometimes you have to examine the details properly.
Why is there so much ignorance about mobile processors (SOCs) on slashdot?? (I really don't mean to be rude.. my apologies)..
The functions you pointed out are handled by specifc DSP units on the SOC. A snapdragon or tegra or omap CPU used in smartphones *today*, *already has* dedicated DSPs for these tasks. They are not handled by the CPU to begin with. If you want a (any number of cores) CPU, and software to handle this, be prepared for a costly phone (CPUs are ill-suited to these functions so it will take a CPU with considerable horsepower), a huge phone (all that horsepower results in a large die size and more heat to be dissipated), and poor battery life (all that heat dissipated indicates that your processor eats amperes for breakfast).
These functions are possible, or close to possible, *today* -- the limiting factors being battery life, I/O bandwidth, network bandwidth, and on-device storage. 4 cores or 64 cores won't solve those problems (and they'll make the battery life considerably worse). Jeez!
I actually beg to differ. On smartphones or low powered devices breaking it down to smaller physical processors is likely the most elegant and efficient route.
But this is not a new challenge (of how to handle multiple processes/threads) -- whether on single-core or multi-core CPUs, or even if you have a machine with multiple CPUs, each of which has multiple cores. All modern OSes can already deal with mutiples threads/processes in each of these scenarios, and the app developer never needs to even think of the underlying implementation. The only design choice remaining relates to workloads. Are they inherently serial or parallel? If inherently serial, then many cores are not needed (or even usable). If inherently parallel or parallelizable, then they are. It so happens that smartphone workloads are inherently serial.
Each aspect of the smartphone OS is compartmentalized. Email is scheduled to run at a specific interval, web browser is refreshing at a different interval all serial on their own in many cases but when it comes to sharing with other processes not very friendly.
This is true, but its not the same as serial/parallel workloads. For example, even if you have 6 different email accounts all setup to sync automatically on your smartphone, that's actually a serial workload. There's a single listener on an event, that wakes up when you receive an email, does the needful, and goes back to a blocked state, leaving the CPU to do other things. You might have a weather app that updates once per hour -- still a serial task that should a miniscule time-slice every hour. Most of the work it's doing is network I/O.
Then you have 3rd party apps that are all over the board.
This is true. Doesn't make them inherently parallel, but the day you have virus scanners, search indexers, bit torrent clients (i.e. active processes) all running simultaneously while you're checking email/browsing/making phone calls, yes, you absolutely will benefit from having multiple cores.
I think being able to assign specific tasks to dedicated units would help as far as context switching as well as data protection and sandboxing. From the users prospective each app can run smoothly and if the odd one craps out then the OS can just knock out the CPU and dump a report.
This is just not true. As I mentioned earlier -- modern OS kernels have had these functions nailed for some time now -- and that holds true for single core / muti core and multi processor environments. Sandboxing and data protection aren't necessarily related to processor cores. Killing an errant process and creating a dump is also not related to how many cores you have.
I doubt the processors they are talking about have much to them as to consider them CPU's
This is very true (and TFA says as much). They are likely thinking more along the lines of the cell processor in the PS3. Instead of having the various dedicated units that go into an SOC, the idea is to have many general purpose FPUs (most likely) that can be programmed to each of those tasks. Color me skeptical. SOCs are excellent solutions for smartphones because their functions are well understood, so you know exactly what to build into them.
but as we see with the trend of multiple low power cores even scaling to 4 or 8 would likely handle a decent work load equivalent to a few atom procs (enough for a presentation and a web browser) in your pocket at decent resolutions of 1080p minimum.
This trend is prevalent on desktops and laptops where paralell or paralellizable workloads are common. Mobile phones with dual-core processors have yet to prove that they do anything better than their single-core bretheren. And SOC solutions for mobile phones are already capable of putting out 1080p video -- that is not related to your CPU cores unless your solution is completely software based, in which case you will need a ton of cores, not to mention a really big battery and well cooled underpants.
Receiving notifications for email, and receiving SMS messages don't require active threads -- there shouldn't be cores dedicated to those tasks even if you do have a 64-core CPU. The batch files, if I understand correctly, are running on your server at work. The Pandora stream's audio decode should be handled by a dedicated auio decode unit. So all you have going is data transfer over the network. I think old single core 486s could handle that -- as can today's single core or dual core snapdragons / tegras / OMAPs / whatever.
Slashdot Mirror
Are all dmg's really considered safe by Safari?
Click on Google Image Search result
However, you said "just by visiting", I said "you have to click" and you said "click"...
I think the difference is clicking on a search result in google, vs clicking on something like a viagra ad or fake antivirus ad on the page that result took you to. You would expect the search result to be benign -- you have no way of differentiating one thumbnail in your search results from another with respect to malicousness -- this is the SEO poisoning part of the exploit.
The advantage of Safari's approach is that they don't define "safe". This allows Apple to adjust the safety heuristics from update to update without changing the default security setting.
That's the part I can't find mentioned anywhere -- what exactly constitutes a "safe" file? Is that the 'exploit' here? That somebody has figured out how to pose as a "safe" file?
Well, of all the million times large corporations try to gather information on people (search data, location data, address information, email addresses, credit card information, boxers or briefs.....) this seems like one of the few situations where the reason is completely legit.. We're always told (by whatever company) that they will be able to offer us better services once they have X data.
In this case, the benifit isn't some cloudy non-tangible thing in the distant future and of questionable value. It's immediate and pertinant information. You just tried connecting to a network, and now you know if you have internet connectivity or not.
That reminds me, Miguel already has a dual personality with his proclaimed love of open source yet his constant admiration for everything made by Microsoft.
Weak. The guy that gave the world Gnome has already benifited you more in your life than you can ever hope to repay him.
Ooooo, you test apps with it. Super impressive. I'm trying to figure how to make enough room in my office to bow down to your technical prowess.
If you don't like being called out, don't FUD.
After banging my head against the Hyper-V headache for two days
I use hyper-v for testing my apps on multiple OS versions. It takes me less than 1 minute to configure a VM. This excludes any time spent copying VHDs across the network, if any. You took 2 days and you still haven't figured it out?
Do you ever accuse Microsoft of FUDing? Will you excuse me for pointing out the irony?
Every time the Redmondroids...
This isn't about "us" vs. "them". You're sounding like an antiredmondroid.
Fact-free bullshit.
I too would post as AC if I were peddling nonsense like that
There's more.. if you're doing mobile development and you're trying to debug something, you have your IDE window (and it's 10+ docks) on one monitor, your mobile emulator, documentation, memory windows, etc. etc. on the other two screens. Regular development is easier on 2 screens. Mobile development is best done with 3. 2 is workable for mobile. 1 is just painful.
AFAIK, in Win7 UAC uses both whitelists, and blacklists, and is also configurable in terms of what it will prompt you for (haven't looked up level of granularity.. couldn't really be bothered)..
Why on gods green earth do you run Visual Studio elevated? IIRC there was a bug that requried that some time ago, but has been fixed since a very very long time.
I could believe them.. you think it's less than that? I know Win7 is pretty rock solid, but users will still find ways to defeat security measures, y'know..
Not sure if you're joking or serious. You know it's both right? 3 thousadths of win7 PCs used to be infected, now 4 thousdandths are infected. That's a difference of 1 thousandths, or 33%, depending on how you choose to represent it.
Lastly -- that's only for 32-bit win7. 64-bit win7 is more resiliant according to the article, but not enough data to work out exactly what that means (before and after numbers from x64 win7 not provided, relative installed base of 32 and 64 bit win7 not provided).
Or they could do what Google's security researchers do when they find an issue in an MS product -- release the details to the world within 48 hours (those 48 hours being Saturday and Sunday).
You are just babbling, and ....... looking for an argument
I replied as AC to put a stop to the nonsense, and you came back with a santimonious lecture about etiquette. Further -- when you say something I agree with, I freely admit it (see the disk encryption scenario you mentioned). To each their own I guess.
You are not so much interested in looking for uses for cores
Correct. A sane design approach is to understand use profiles and requirements, and then solve them. Proposing 64 core CPUs without first having a need for it is a backwards approach. The use case you pointed out a thread above (mesh networking + encryption + video redirection + language conversion, simultaneously mind you) would cover what -- 0.09% of smartphone users? Never mind the point that 64 general purpose cores is still an inefficient approach for addressing it. And you persistently ignore issues related to finite battery life, and limited heat dissipation capabilities in a smartphone form factor.
I'd rather let you think you won
I feel like I've won when I've had a rational discussion, and one or both parties come away with a bit of insight. I fear I might have polarized you into a particular line of thinking that I am very certain is limited. I hate it when that happens.
showing you how much advantage a bit of imagination could be.
Imagination is a wonderful thing. A little bit of real-world engineering does have a habit of raining on the imagination parade from time to time.
Encrypting stuff on the fly is a great example. Let's say you benefit from having a core for that, in addition to your existing core. So you're at 2 cores now, with 62 left to go. I do understand that several ciphers will benefit from extra cores, but you have a device with finite storage, and finite battery power, so it begs the question as to how much stuff you're encrypting that you need to dedicate more than 1 core to it.
Video redirection is very unclear -- I don't see it as a moblie workload -- but perhaps I don't get your scenario yet. In any case, that seems like a completely data-bound process.
Mesh networking (any networking), given a standard protocol is not something the CPU should be taxed with. It should be 99% I/O bound
Language conversion (I don't know your exact scenario -- is this text, speech, what is it?) is not something you can do even today, even with 64 (or more) cores -- so it'll be a while before you have an application that attempts to do that on the phone. Language conversion apps require some serious data backing and number crunching -- it's best implemented as a cloud service that you stream the audio to, and it returns back the results -- very similar to how voice search apps on phones currently work (or say, similar to something like Shazam).
You have it backwards. The correct question is if I have 64 cores I didn't have at my disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the ancestral architecture.
Very well then, if you have 64 cores that you didn't have at your disposal before, what value is added in terms of doing things on the new device that were either difficult or impossible to do with the current (ancestral assumes shared lineage) architecture?
Certainly. Page 1 of what?
I especially like the way he switched to posting as AC so he can keep spouting his nonsense while effectively putting his fingers in his ears and shouting NA NA NA NA. It doesn't leave much wonder why he is so clueless.
And we've entered a fact-free zone and reduced to childish bickering.
Let's take this down a notch. It does nobody any good to be disrespectful. Let's be specific -- what *problem* with current SOC implementations do you think a 64 core CPU will solve? For arguments sake, and for sanity, lets assume 4 of them are integer cores, and 60 (odd number, but what can you do) of them are FPU cores. What problem is it solving, or how is it better?
Also, what is to say we won't be pulling all these DSP units into the processor again?
They are already there. Every single function we've takled about has dedicated silicon for it, *inside one single chip*, which also includes the CPU. Aaargghh!
Pentium brought in some of the graphics processing, so on and so forth
Same point. Already done. Read up SOC architechture before replying. Look up a block diagram of what lives on a single chip for say a tegra or a snapdragon.
The newest CPUs from Intel and AMD both brought the "video card" into the processor, but there are still many chips outside of the CPU; audio, southbridge, bluetooth, wifi, etc.
Same point. Already done. Smartphone processors integrate all the functions into one single chip. Please, please, please do a little reading before replying again.
Beyond that, the game developers care a hell of a lot more about your SOC a good GPU
doh! care a hell of a lot more about your SOC *having* a good GPU
Not really -- on an old 486 or pentium (single core obviously) did you never have say outlook running in the background, while playing need for speed? At the most, you might need 2 cores to ensure jitter-free gaming during an event such as receiving a new email (etc). Beyond that, the game developers care a hell of a lot more about your SOC a good GPU.
Don't get me wrong -- i'm all for crazy fast processors -- it's just that the importance of processor speed (and cores in this case) is often completely misunderstood. Even in modern desktops, you're often in a situation where your quad-core i7 with dual hyperthreading (so 8 cores, depending on how you count) has at least 4 cores sitting in a state of utter and complete data-starvation. To solve data starvation issues, you need either more paralell (or parallelizable) workloads, and greater I/O bandwidth (more cache at each level, faster cache at each level, more RAM, faster RAM, wider RAM buses, more data per clock (ddr/qdr), faster hdd/ssd, lower latency hdd/ssd, faster and wider i/o bus, faster network, lower latency network, etc.). Just adding cores doesn't make something faster -- you need work for those cores to do, otherwise they're just sitting there consuming your battery. Worse -- if you have 64 super tiny ultra minimal cores each of them is guaranteed to be a very inferior integer pipeline compared to what you get in a full-blow ARM Cortext (for example). So when you are single tasking on a non-parallizeable workload (say checking email), you're only going to be able to use a tiny handful of your 64 cores, and that application will be slow as molasses. And consume more power while doing so. And when you do use all your cores by doing something like video decoding you'll still barely achieve the results that dedicated DSPs (that are already present in current-day SOCs) already achieve, and you'll take way more power doing so.
Disclaimer: There are some overgeneralizations in what I said, but the gist of it holds true. Bottom line: in the quest for awesome speed, people are salivating over something that will turn smartphones into slugs. It's like people drooling over the old Pentium 4 (netburst) gigahertz all over again, only to realize that the so-called fastest PC processor is actually a dog, an expensive one at that, and it generates insane amounts of heat. Sometimes you have to examine the details properly.
Why is there so much ignorance about mobile processors (SOCs) on slashdot?? (I really don't mean to be rude.. my apologies)..
The functions you pointed out are handled by specifc DSP units on the SOC. A snapdragon or tegra or omap CPU used in smartphones *today*, *already has* dedicated DSPs for these tasks. They are not handled by the CPU to begin with. If you want a (any number of cores) CPU, and software to handle this, be prepared for a costly phone (CPUs are ill-suited to these functions so it will take a CPU with considerable horsepower), a huge phone (all that horsepower results in a large die size and more heat to be dissipated), and poor battery life (all that heat dissipated indicates that your processor eats amperes for breakfast).
These functions are possible, or close to possible, *today* -- the limiting factors being battery life, I/O bandwidth, network bandwidth, and on-device storage. 4 cores or 64 cores won't solve those problems (and they'll make the battery life considerably worse). Jeez!
I actually beg to differ. On smartphones or low powered devices breaking it down to smaller physical processors is likely the most elegant and efficient route.
But this is not a new challenge (of how to handle multiple processes/threads) -- whether on single-core or multi-core CPUs, or even if you have a machine with multiple CPUs, each of which has multiple cores. All modern OSes can already deal with mutiples threads/processes in each of these scenarios, and the app developer never needs to even think of the underlying implementation. The only design choice remaining relates to workloads. Are they inherently serial or parallel? If inherently serial, then many cores are not needed (or even usable). If inherently parallel or parallelizable, then they are. It so happens that smartphone workloads are inherently serial.
Each aspect of the smartphone OS is compartmentalized. Email is scheduled to run at a specific interval, web browser is refreshing at a different interval all serial on their own in many cases but when it comes to sharing with other processes not very friendly.
This is true, but its not the same as serial/parallel workloads. For example, even if you have 6 different email accounts all setup to sync automatically on your smartphone, that's actually a serial workload. There's a single listener on an event, that wakes up when you receive an email, does the needful, and goes back to a blocked state, leaving the CPU to do other things. You might have a weather app that updates once per hour -- still a serial task that should a miniscule time-slice every hour. Most of the work it's doing is network I/O.
Then you have 3rd party apps that are all over the board.
This is true. Doesn't make them inherently parallel, but the day you have virus scanners, search indexers, bit torrent clients (i.e. active processes) all running simultaneously while you're checking email/browsing/making phone calls, yes, you absolutely will benefit from having multiple cores.
I think being able to assign specific tasks to dedicated units would help as far as context switching as well as data protection and sandboxing. From the users prospective each app can run smoothly and if the odd one craps out then the OS can just knock out the CPU and dump a report.
This is just not true. As I mentioned earlier -- modern OS kernels have had these functions nailed for some time now -- and that holds true for single core / muti core and multi processor environments. Sandboxing and data protection aren't necessarily related to processor cores. Killing an errant process and creating a dump is also not related to how many cores you have.
I doubt the processors they are talking about have much to them as to consider them CPU's
This is very true (and TFA says as much). They are likely thinking more along the lines of the cell processor in the PS3. Instead of having the various dedicated units that go into an SOC, the idea is to have many general purpose FPUs (most likely) that can be programmed to each of those tasks. Color me skeptical. SOCs are excellent solutions for smartphones because their functions are well understood, so you know exactly what to build into them.
but as we see with the trend of multiple low power cores even scaling to 4 or 8 would likely handle a decent work load equivalent to a few atom procs (enough for a presentation and a web browser) in your pocket at decent resolutions of 1080p minimum.
This trend is prevalent on desktops and laptops where paralell or paralellizable workloads are common. Mobile phones with dual-core processors have yet to prove that they do anything better than their single-core bretheren. And SOC solutions for mobile phones are already capable of putting out 1080p video -- that is not related to your CPU cores unless your solution is completely software based, in which case you will need a ton of cores, not to mention a really big battery and well cooled underpants.
Receiving notifications for email, and receiving SMS messages don't require active threads -- there shouldn't be cores dedicated to those tasks even if you do have a 64-core CPU. The batch files, if I understand correctly, are running on your server at work. The Pandora stream's audio decode should be handled by a dedicated auio decode unit. So all you have going is data transfer over the network. I think old single core 486s could handle that -- as can today's single core or dual core snapdragons / tegras / OMAPs / whatever.