You move around full blocks. It's not a particularly fast endeavor, but most computers sit around idle for 99% of the time anyways, so it doesn't hurt them in real world performance.
Yes, 32 x 600MHz x 1MIP/MHz @ 0.5W == 19.2 GIPS@16W.
Meanwhile...
32 x ???MHz (Unknown, but likely to be 900+ to be competitive with current designs) x 3+MIPS/MHZ + 32 x 512-bit SIMD units = OMGWTFHAX @ 300W.
Seriously. The "Pentium" base of this design is damned near irrelevant. At this point, all it's doing there is scheduling execution on the SIMD units. If you've seen any modern GPU designs, they're basically hugely parallel cores attached to a few "director" cores which puts everything where it needs to go. The original Pentium is probably the most powerful CPU with the least complicated design on the process, with the least amount of legacy MMX cruft.
Meanwhile, Chumby is 100% open source hardware, including both the board and the default daughtercard, under a BSD-like license, along with 90% of its software (I only say 90% because the widget platform runs Adobe Flash, which is the only closed-source component on the entire device).
Costs about the same as Gumstix, plus you get an LCD, speakers and a microphone.
"They make a dual-core 2GHz power chip with 2MB of cache, and integrated DDR2 controller with DMA controller... burning just 5-13W. AFAIK, no one else is making anything similar. Atom seems similar on the x86 side, but is larger and does not have the same features."
Atom is smaller, Centrino Atom is a bit larger, but also has all of those other pesky features you need to build a platform (PCI-Express, USB, etc. etc). Atom burns 3W max, with under 0.2W being the average load. Centrino Atom is competitive with ~10W max.
PA Semi doesn't compete with Intel at all in this market. PA Semi's chips are more comparable to the back-plane models of Intel's Pentium-M chips, where it wins hands down. Of course, nobody's saying you can't build a desktop or server machine around them, but they really aren't designed for that kind of work, nor were they designed to be competitive with deeply embedded processors like ARM and the Atom.
You're right. If only there was a new, faster USB standard that would be able to take advantage of these new data rates. They could call it "USB 3.0", or "USB SuperSpeed" or something.
Oh Wait...
A) These drives were basically designed for datacenters, so you can look at paying out the teeth for them.
B) Latency. Nowhere did they mention the "wake-up" time from the Low RPM mode, but you can guarantee it's horrendous. "Average Latency" as the specs say, only tell you what happened during test conditions, conditions very unlikely to put it into Low RPM mode.
C) Density. Cutting edge drives are more dense.
If I were Google, these might sound like attractive trade offs.
His customers are forcing him to renew, no way he's going to leave iTunes and it's three-billion-songs-sold. He hopes by whining to the press everyone will throw daggers at Apple for being "too restrictive", when in reality their music still costs about 4 times what it's actually worth and the artists are still only getting about 0.5% of what they should be.
Luckily, looking at the Apple-NBC ordeal, we know Apple doesn't play those games.
We actually don't know if it's a SHA-1 hash or a Whirlpool hash or a weird 20/40-byte CRC signature, or what the hell it is really. We assume it's a SHA-1 because it's the most common hash that dumps 20-byte values. They have no way of knowing it hashes anything with a serial number or anything really, we just know the database has two new 20-byte entries.
I'd assume on Monday we'll have some kind of answer from Apple themselves on what the hell this actually is. And well, if we don't, then we'll have the answer anyways (their silence alone will be the answer).
So the worst case is just doing it the way the UNIX designers intended it to be done in the first place. So why not just do it the way the UNIX designers designed it to be done in the first place? Adding system calls for every little thing just means more things you need to port from system to system, having a file with a well-defined interface is more than enough.
If the user that posted his tirade against Linux's UNIX-style design had coded his application correctly to begin with, it'd be a non-issue, all of the code would be hidden away inside of a (rather clean) module and wouldn't have affected his application at all. In fact, there are already existing modules/libraries/pieces of code to do exactly what he wanted to do, so he wasn't "lazy enough" when coding and instead had his "Do it Myself" hat on, completely ignoring the groundwork that people had placed for him to use.
PlugSched would have let us do this in a big way, letting us change at boot or even while the system is running what cpu scheduler is working. But, most distributions pull most of their code from the Mainline and Linus' blessed code, so it's unlikely any distribution will ever see Kolivas' scheduler in action to know whether or not it could do better than Ingo's bastard-clone.
Now we get even more people questioning Ingo's code, and instead of examining the code, we get people starting to question Roman's merits too. The personal attacks over this need to stop, and we need to look at the actual problem instead of looking at the developers who are questioning the choices. I personally hope Kolivas will come back to the kernel and hasn't moved on for good, just needing some time away from the hot-heads and their corporate Linux eccentricity. Desktop Linux needs to start at the Kernel and end at the user, no component between left behind.
You shouldn't say "someone did", it was Kolivas himself that first offered the pluggable scheduler patch so that his patch could be used along side any new future schedulers and offer a concrete way to benchmark the changes caused by scheduling. And this was done years ago, circa 2004: http://ck.kolivas.org/patches/plugsched/
Of course, Linus and Ingo rejected those patches as well.
Kolivas apparently publicly announced his decision to stop working on the kernel, which would include the current scheduler. That means finding another maintainer for his code, should any problems surface. If you've got 2 pieces of code that test the same in speed (as they do according to some), and 1 has a dev that's willing to keep working on it, and the other doesn't... Which would you pick?
Wow, not even a full year has past and we're already getting revisionist historians trying to change the situation.
Kolivas quit because of the scheduler debacle, because nobody would listen to Kolivas but were apt to follow Linus and his cronie Ingo around when they drum up more-or-less the exact same thing. Instead of critically listening to Kolivas' points, Linus and Ingo attacked Kolivas' merits. Under that kind of personal attack, I couldn't say I wouldn't have quit just to shut them up. Not all of us are stubborn mules and jackasses.
Well, your own link says they discounted the "Betray Us" ad, so maybe they'd discount us. Let's put a fair price at $120k-$150k. There have got to be more than 12,000 people in America that believe Verizon is wrong, if they all gave $10...
Then again, the "Distributed Cash-Mob" model hasn't worked for very much in the past; using the very same models we could have financed legal playback for our favorite free software media players and the like.
"The 22MHz C block also comes with requirements: 40 percent coverage within four years, 75 percent coverage within 10. The FCC will automatically reclaimed "unserved portions of the license area" from companies that do not meet the build-out requirements."
What they didn't say is This spectrum should be available to the public under fair and decent pricing or anything of the like; they only added the two "Google Caveats". The phone companies could build up the entire infrastructure on top of existing infrastructure, even use it internally to shuffle data around, and only offer public access at any exorbitant price they choose to offer. These companies have made it an art form of prying spectrum away from the government, there's absolutely no reason to think things will change unless we impose changes on them.
If you read the development rules, they are required to do several billion dollars worth of Public Safety and emergency band build out over the next 10 years.
If you would have read those very same rules a bit more closely, you would realize that the Public Safety bands and the Commercial bands are two different bands being auctioned off independently. The "C" block auction is the one that has these two rules attached that Verizon is trying to get thrown out.
http://arstechnica.com/news.ars/post/20070815-700mhz-auction-whats-really-up-for-grabs-and-why-it-wont-be-monopolized.html for more info.
"Still, I'm interested how comes Opera's Javascript is so fast compared to the other browsers."
Well, they didn't test it against WebKit/Safari/Konq, which blazes through Javascript tests. Firefox's Javascript engine (SpiderMonkey) leaves a lot to be desired, and well, Internet Exploder is just plain terrible at everything. Things will get better for Firefox once Mozilla figures out a way to integrate Tamarin, but this is still a while off.
Slashdot Mirror
Toumani Diabate's "Symmetrical Orchestra" sounds rather recent to me. But I could be wrong, feel free to find out.
Google hasn't paid for half of the Judiciary's law schooling yet, unlike Microsoft who's been churning out lawyers like it's going out of style.
Microsoft hasn't been a software company for years, they're a law firm.
Atlas, the Titan who held the weight of the world on his shoulders.
I didn't know Greg Kroah-Hartman trolled Slashdot. But I get it, those sour grapes can be pretty hard to swallow.
You move around full blocks. It's not a particularly fast endeavor, but most computers sit around idle for 99% of the time anyways, so it doesn't hurt them in real world performance.
Yes, 32 x 600MHz x 1MIP/MHz @ 0.5W == 19.2 GIPS@16W.
Meanwhile...
32 x ???MHz (Unknown, but likely to be 900+ to be competitive with current designs) x 3+MIPS/MHZ + 32 x 512-bit SIMD units = OMGWTFHAX @ 300W.
Seriously. The "Pentium" base of this design is damned near irrelevant. At this point, all it's doing there is scheduling execution on the SIMD units. If you've seen any modern GPU designs, they're basically hugely parallel cores attached to a few "director" cores which puts everything where it needs to go. The original Pentium is probably the most powerful CPU with the least complicated design on the process, with the least amount of legacy MMX cruft.
Meanwhile, Chumby is 100% open source hardware, including both the board and the default daughtercard, under a BSD-like license, along with 90% of its software (I only say 90% because the widget platform runs Adobe Flash, which is the only closed-source component on the entire device).
Costs about the same as Gumstix, plus you get an LCD, speakers and a microphone.
"They make a dual-core 2GHz power chip with 2MB of cache, and integrated DDR2 controller with DMA controller... burning just 5-13W. AFAIK, no one else is making anything similar. Atom seems similar on the x86 side, but is larger and does not have the same features."
Atom is smaller, Centrino Atom is a bit larger, but also has all of those other pesky features you need to build a platform (PCI-Express, USB, etc. etc). Atom burns 3W max, with under 0.2W being the average load. Centrino Atom is competitive with ~10W max.
PA Semi doesn't compete with Intel at all in this market. PA Semi's chips are more comparable to the back-plane models of Intel's Pentium-M chips, where it wins hands down. Of course, nobody's saying you can't build a desktop or server machine around them, but they really aren't designed for that kind of work, nor were they designed to be competitive with deeply embedded processors like ARM and the Atom.
n/t.
You're right. If only there was a new, faster USB standard that would be able to take advantage of these new data rates. They could call it "USB 3.0", or "USB SuperSpeed" or something. Oh Wait...
Negative a few years...
Not that you'd really want to use it.
A) These drives were basically designed for datacenters, so you can look at paying out the teeth for them.
B) Latency. Nowhere did they mention the "wake-up" time from the Low RPM mode, but you can guarantee it's horrendous. "Average Latency" as the specs say, only tell you what happened during test conditions, conditions very unlikely to put it into Low RPM mode.
C) Density. Cutting edge drives are more dense.
If I were Google, these might sound like attractive trade offs.
I *knew* there was a reason I was afraid of heights.
Now please shut up grammar nazis.
His customers are forcing him to renew, no way he's going to leave iTunes and it's three-billion-songs-sold. He hopes by whining to the press everyone will throw daggers at Apple for being "too restrictive", when in reality their music still costs about 4 times what it's actually worth and the artists are still only getting about 0.5% of what they should be.
Luckily, looking at the Apple-NBC ordeal, we know Apple doesn't play those games.
..A whole penny? Why should I have to spend a whole penny if it's not even worth one billionth of that?
We actually don't know if it's a SHA-1 hash or a Whirlpool hash or a weird 20/40-byte CRC signature, or what the hell it is really. We assume it's a SHA-1 because it's the most common hash that dumps 20-byte values. They have no way of knowing it hashes anything with a serial number or anything really, we just know the database has two new 20-byte entries.
I'd assume on Monday we'll have some kind of answer from Apple themselves on what the hell this actually is. And well, if we don't, then we'll have the answer anyways (their silence alone will be the answer).
So the worst case is just doing it the way the UNIX designers intended it to be done in the first place. So why not just do it the way the UNIX designers designed it to be done in the first place? Adding system calls for every little thing just means more things you need to port from system to system, having a file with a well-defined interface is more than enough.
If the user that posted his tirade against Linux's UNIX-style design had coded his application correctly to begin with, it'd be a non-issue, all of the code would be hidden away inside of a (rather clean) module and wouldn't have affected his application at all. In fact, there are already existing modules/libraries/pieces of code to do exactly what he wanted to do, so he wasn't "lazy enough" when coding and instead had his "Do it Myself" hat on, completely ignoring the groundwork that people had placed for him to use.
PlugSched would have let us do this in a big way, letting us change at boot or even while the system is running what cpu scheduler is working. But, most distributions pull most of their code from the Mainline and Linus' blessed code, so it's unlikely any distribution will ever see Kolivas' scheduler in action to know whether or not it could do better than Ingo's bastard-clone.
Now we get even more people questioning Ingo's code, and instead of examining the code, we get people starting to question Roman's merits too. The personal attacks over this need to stop, and we need to look at the actual problem instead of looking at the developers who are questioning the choices. I personally hope Kolivas will come back to the kernel and hasn't moved on for good, just needing some time away from the hot-heads and their corporate Linux eccentricity. Desktop Linux needs to start at the Kernel and end at the user, no component between left behind.
You shouldn't say "someone did", it was Kolivas himself that first offered the pluggable scheduler patch so that his patch could be used along side any new future schedulers and offer a concrete way to benchmark the changes caused by scheduling. And this was done years ago, circa 2004: http://ck.kolivas.org/patches/plugsched/
Of course, Linus and Ingo rejected those patches as well.
Kolivas apparently publicly announced his decision to stop working on the kernel, which would include the current scheduler. That means finding another maintainer for his code, should any problems surface. If you've got 2 pieces of code that test the same in speed (as they do according to some), and 1 has a dev that's willing to keep working on it, and the other doesn't... Which would you pick?
Wow, not even a full year has past and we're already getting revisionist historians trying to change the situation.
Kolivas quit because of the scheduler debacle, because nobody would listen to Kolivas but were apt to follow Linus and his cronie Ingo around when they drum up more-or-less the exact same thing. Instead of critically listening to Kolivas' points, Linus and Ingo attacked Kolivas' merits. Under that kind of personal attack, I couldn't say I wouldn't have quit just to shut them up. Not all of us are stubborn mules and jackasses.
Well, your own link says they discounted the "Betray Us" ad, so maybe they'd discount us. Let's put a fair price at $120k-$150k. There have got to be more than 12,000 people in America that believe Verizon is wrong, if they all gave $10...
Then again, the "Distributed Cash-Mob" model hasn't worked for very much in the past; using the very same models we could have financed legal playback for our favorite free software media players and the like.
"The 22MHz C block also comes with requirements: 40 percent coverage within four years, 75 percent coverage within 10. The FCC will automatically reclaimed "unserved portions of the license area" from companies that do not meet the build-out requirements."
What they didn't say is This spectrum should be available to the public under fair and decent pricing or anything of the like; they only added the two "Google Caveats". The phone companies could build up the entire infrastructure on top of existing infrastructure, even use it internally to shuffle data around, and only offer public access at any exorbitant price they choose to offer. These companies have made it an art form of prying spectrum away from the government, there's absolutely no reason to think things will change unless we impose changes on them.
If you read the development rules, they are required to do several billion dollars worth of Public Safety and emergency band build out over the next 10 years.
If you would have read those very same rules a bit more closely, you would realize that the Public Safety bands and the Commercial bands are two different bands being auctioned off independently. The "C" block auction is the one that has these two rules attached that Verizon is trying to get thrown out.
http://arstechnica.com/news.ars/post/20070815-700mhz-auction-whats-really-up-for-grabs-and-why-it-wont-be-monopolized.html for more info.
"Still, I'm interested how comes Opera's Javascript is so fast compared to the other browsers."
Well, they didn't test it against WebKit/Safari/Konq, which blazes through Javascript tests. Firefox's Javascript engine (SpiderMonkey) leaves a lot to be desired, and well, Internet Exploder is just plain terrible at everything. Things will get better for Firefox once Mozilla figures out a way to integrate Tamarin, but this is still a while off.