You get this sort of notions out of the hardware guys (anyone remember the Intel 432?).
There is a long history of announcements from hardware organizations that leave software folks puzzled.
Just because someone has a good grasp of how to design a CPU chip does not mean they have any clue about software.
Putting multiple CPUs on the same die is not a bad idea, but all the hardware (including the CPUs)
will be controlled by one manager. The manager could be Linux, could be Windows, could be a virtualization
layer like Xen.
If you are going to run multiple operating systems on the same machine, the software is going to
require the same sort of virtualization as on an ordinary single-CPU system.
About the only (minor) advantage is when more than one operating system is trying to be active concurrently.
With multiple CPUs you can keep latency short without playing troublesome scheduling games in the virtualization layer.
When one of the guest operating systems goes CPU-bound, you have a simpler time keeping response times
with the other guest operating systems predictable.
Note that this works out the same either the CPUs are on the chip or separate chips.
Looks like a good start. I think we will have to wait a couple years to see if this gathers enough interest from both music producers and consumers. Hope this works out as I am disinclined to ever buy anything from a RIAA member.
The funny (or brilliant?) thing about this model is that it really is a pretty close match to reality. How have most of us folks bought music before? Most likely we heard something interesting on the radio or TV, or from a friend. In nearly every case we "try" music before we buy it.
The key will be a good set of accumulated user reviews - much like Amazon. (There is a thought, could they hook into - or sell through - the Amazon review system?). Hints from other customers with similar taste would be a big help sorting out interesting music.
You might also want to look at thttpd for serving your graphics. Unless you have an amazingly fat pipe (or slow CPU) this should be good enough to deliver all your network connection can handle.
I too have wondered if there were any exploits for consumer NAT/firewall boxes.
Judging from posts so far, it would seem that at least there are none known:).
I started using the Linksys cable/routers when they first came out.
I have insisted that all my neighbors, friends, and family with fast connections use a Linksys box (or similar).
There are a few points to bear in mind:
Most crack attempts are from brain-dead script kiddies.
Hardware firewalls fail-safe, where software firewalls fail-unsafe.
You don't want your average folk running only a software firewall.
Observation (1) comes from running with both a Linux and Windows box exposed directly to the Internet.
Both boxes had all unnecessary ports closed, were up-to-date on all patches, and carefully monitored.
Neither machine was ever compromised.
Periodic review of the logs showed a remarkable lack of intelligence on the part of the attacker.
Practically all the activity was from a small number of popular crack-of-the-month scripts.
Tracing the attacks back to their source - and getting the script kiddie kicked off their account - was seldom difficult.
So practically speaking, we don't have to worry about ultra-sophisticated attacks.
The vast majority of script kiddies lack the needed intelligence.
Keep (2) in mind when you weigh the risk of failure.
If a software firewall fails to run (for whatever reason) most likely your machine will be completely exposed.
If the hardware NAT/firewall fails you will be safe (if without internet access).
The software on your PC probably changes regularly.
If any of those changes disables your firewall, the you might first notice when your machine is already subverted.
The software in your NAT/firewall box never changes (discounting upgrades) so the chance of failure is less.
Keep (3) in mind when evaluating effectiveness.
Most folks with fast connections are not techies.
A solution that works well and reliably for the bulk of the population is in the end far more effective.
If the majority of your present customers are on Windows, and you hope port to Linux later, this is an interesting development.
If your developers are all Windows developers comfortable with C# and not Java, this might end up being a big deal.
If you're considering compiling a higher level language to byte codes, on Windows compiling to MSIL makes a lot of sense. If this also works elsewhere, again this could turn out to be a big deal.
Slashdot Mirror
Putting multiple CPUs on the same die is not a bad idea, but all the hardware (including the CPUs) will be controlled by one manager. The manager could be Linux, could be Windows, could be a virtualization layer like Xen. If you are going to run multiple operating systems on the same machine, the software is going to require the same sort of virtualization as on an ordinary single-CPU system.
About the only (minor) advantage is when more than one operating system is trying to be active concurrently. With multiple CPUs you can keep latency short without playing troublesome scheduling games in the virtualization layer. When one of the guest operating systems goes CPU-bound, you have a simpler time keeping response times with the other guest operating systems predictable.
Note that this works out the same either the CPUs are on the chip or separate chips.
The funny (or brilliant?) thing about this model is that it really is a pretty close match to reality. How have most of us folks bought music before? Most likely we heard something interesting on the radio or TV, or from a friend. In nearly every case we "try" music before we buy it.
The key will be a good set of accumulated user reviews - much like Amazon. (There is a thought, could they hook into - or sell through - the Amazon review system?). Hints from other customers with similar taste would be a big help sorting out interesting music.
You might also want to look at thttpd for serving your graphics. Unless you have an amazingly fat pipe (or slow CPU) this should be good enough to deliver all your network connection can handle.
I too have wondered if there were any exploits for consumer NAT/firewall boxes. Judging from posts so far, it would seem that at least there are none known :).
I started using the Linksys cable/routers when they first came out. I have insisted that all my neighbors, friends, and family with fast connections use a Linksys box (or similar).
There are a few points to bear in mind:
Observation (1) comes from running with both a Linux and Windows box exposed directly to the Internet. Both boxes had all unnecessary ports closed, were up-to-date on all patches, and carefully monitored. Neither machine was ever compromised. Periodic review of the logs showed a remarkable lack of intelligence on the part of the attacker. Practically all the activity was from a small number of popular crack-of-the-month scripts. Tracing the attacks back to their source - and getting the script kiddie kicked off their account - was seldom difficult.
So practically speaking, we don't have to worry about ultra-sophisticated attacks. The vast majority of script kiddies lack the needed intelligence.
Keep (2) in mind when you weigh the risk of failure. If a software firewall fails to run (for whatever reason) most likely your machine will be completely exposed. If the hardware NAT/firewall fails you will be safe (if without internet access). The software on your PC probably changes regularly. If any of those changes disables your firewall, the you might first notice when your machine is already subverted. The software in your NAT/firewall box never changes (discounting upgrades) so the chance of failure is less.Keep (3) in mind when evaluating effectiveness. Most folks with fast connections are not techies. A solution that works well and reliably for the bulk of the population is in the end far more effective.
If the majority of your present customers are on Windows, and you hope port to Linux later, this is an interesting development.
If your developers are all Windows developers comfortable with C# and not Java, this might end up being a big deal.
If you're considering compiling a higher level language to byte codes, on Windows compiling to MSIL makes a lot of sense. If this also works elsewhere, again this could turn out to be a big deal.
So yes, this *is* interesting...