Apple won't be the "only", in fact they won't even be one at all. This is because this slashdot article is blatantly wrong; Apple's new x86 macs DO use DRM. They have the TPM chips on the motherboard. They have TPM-related kernel calls. THE OS WILL NOT PROPERLY RUN WITHOUT THE TPM CHIP.
Here is OSx86's official rebuttle saying why this "no DRM in macs" is a load of crap:
Adding another frequency doesn't give you full duplex communication, it just doubles effective network bandwidth.
You can call it full duplex I suppose, but even then it's shared full duplex. So long as there are only two devices, they can transmit to eachother on seperate channels. But what happens when a third device pops onto the network? It needs to send on one of those two channels, and devices need to send to it on one of those two channels. You still end up having only two channels, but three devices.
Personally I thought that mimo involved sending the exact same signal out through multiple antennas and then using the multiple identical signals for greater signal strength, such as using bouncing signals to their advantage.
Either way, it isn't full duplex wireless. The only potential full duplex wireless technology is UWB, because there is the potential for so many differeng timing patterns that every device could have their own, so non-shared full duplex (Until you ran out of timing patterns, in which case you can increase the resolution).
SeaMonkey is "SeaMonkey". Firefox is "Firefox". Neither product uses "Mozilla" in the title. It looks more like a change in naming convention than a matter of being allowed to use it or not. They're on equal ground.
There is a difference, of course, in the focus. SeaMonkey is a "Project" and Firefox is a "Product". They're both on the Mozilla site, and since Mozilla's focus is Firefox, SeaMonkey is rightfully less important (Ignoring the reasons for why it is or isn't).
Personally I am happy that Mozilla moved over to Firefox. The Mozilla Suite was a bloated mess in that it did so much that people often didn't want. Do I really need an IRC client built in, and a HTML editor, newsgroup browser, and the kitchen sink? Jack of all trades, master of none. Except I don't USE most of the trades.
That was the problem with the suite. Everyone wanted something it did, but also everybody didn't want something it did. With the new system I can grab the parts I want (Firefox, Thunderbird) without the extra bloat that I couldn't care less against.
Complaining that Mozilla shifted focus away from browser suites is like complaining that Microsoft shifted focus away from Windows 3.1. Progress marches on and we do away with antiquated stuff that isn't suited to the current environment.
First off, 802.11n doesn't exist. It won't exist for years (OK, maybe one) until the standard is done. You are probably referring to something like Belkin's "pre-n" products, which have NOTHING to do with 802.11n.
Second, wireless networks are by definition half duplex, just because the wired connection to an access point is full duplex doesn't mean the wireless connection is too. Think about it, only one transmission can happen on a wireless network at a time. That is, only one packet can be moving at any given time. You have only one frequency you broadcast and receive on. If you are receiving a packet that means somebody else is sending a packet. If you were to try to send a packet while receiving, you'd have two people broadcasting at the same time. That doesn't work.
And don't forget there is a world of difference between advertised speed and actual speed.
If the pattern holds true to the same as 802.11g, we will see 200mbit at close range, and 100mbit at normal range.
In other words they will claim 540mbit but we'll get 100mbit wired performance.
The problem is that even 540mbit is not enough because a wireless network is like a hub, not a switch. All bandwidth is shared, and it is half duplex; only one person can send at a time on the entire wireless network. 540mbit sounds amazing, but even at the 200mbit you get at close range, if you have ten people on the network, each can only get 20mbit if they all transfer at the same time. I imagine collisions would further reduce that. And cut some more off for upstream usage.
Please, any probe of they were this kind of information?
Huh? Make sense man.
I have one prove of this site doesn't exists and were not exists: go to www.mojihedun.com or search in google and/or yahoo the word "mojihedun".
You didn't look very hard. Your google search should have pointed you to "mojahedin", which produces many results. There are various very similar names for the group. It's a militant Iranian group.
You will only found the same note as you publish in the (Surprise!) www.timesonline.co.uk publication.
Umm, I'm not the author of the article. I didn't publish anything. See my previous note on this. It's not my fault the author of the article can't spell.
And what sites thinks the UK Governments are "moderates"?
I don't know, why don't you ask them. I'm not a UK citizen, let alone the UK government.
One global jihad site terminated recently was an inflammatory Pakistani site, www.mojihedun.com, in which a section entitled How to Strike a European City gave full technical instructions. Tens of similar sites, some offering detailed information on how to build and use biological weapons, have also been shut down. However, Islamic sites believed to be "moderate", remain.
That probably isn't enough since we have to assume we might be going through a proxy. At the very least we have to tell the proxy not to cache anything.
And what port is that C daemon going to listen on? Port 80? What if that is proxied? The only thing that is certain to get through is HTTP traffic.
I'd go for a much simpler approach. It depends on how accurate this needs to be, but find a web server with accurate time (Perhaps a friend has webspace or a dedicated server, or even a home DSL/Cable connection), and put a one-line PHP, Perl, anything, script on it that simply sends the timestamp. Perhaps try to speed things up marginally by removing all but the crucial headers.
Then, on the client side, a short script that is called by cron every so often. The script simply downloads the output of the PHP script, times the download, and sets the system time to the downloaded time plus half the time taken for the download. Is it perfectly accurate? No. Is it good enough for almost any use? Yes.
Using the half-the-download time is sort of cheating, but it gets you close enough to the actual time, and it's dead simple. The original poster doesn't specify how accurate he needs this to be, but as a rough guess I'd say that the method I've outlined will probably sync the time on the two servers to closer than a quarter second.
This is because my fear is that the technology will become popular enough to impact my choice of LCDs without this feature. Not buying it isn't going to solve any problems.
On the other hand, complaining about it on Slashdot isn't going to help at all either, so it's a moot point.
I really think this is a step backwards in that it doesn't solve the problem, it just masks it. The response times are still the same.
I question if you've ever used a modern high end LCD. Ghosting has been more or less eliminated since the response times have dropped so low. These aren't the 35 or 50ms LCDs of the past ( I remember using an LCD with a response time of 150ms, what a nightmare).
Current LCD response times have dropped to 8ms where the problem is pretty much gone.
Personally I find the flickering of CRTs causes quite a bit eyestrain, even at so-called flicker-free refresh rates. And in order to get a CRT that supports higher refresh rates you're going to pay as much or more than an LCD.
Desk space means nothing to me, I care about two things with LCD. One is that they are much sharper. The other is that they don't flicker.
That said I'm eagerly awaiting OLED displays. All the benefits of LCDs, but with contrast ratios and response times like a CRT. All while being thinner and using less power than an LCD. There's nothing not to like, other than possibly their shorter lifespan.
But it is, since it may or may not be noticeable, and it actually does improve response times.
Flickering, however, verges on headache inducing, and doesn't actually improve response times. It just hides the pixels while they are changing.
One can only hope that the market rejects these new LCDs... Luckily when OLEDs take over this won't be a problem since they have CRT-like response times to begin with.
I hope these new displays fail horribly. This is the LAST thing we need...
Modern LCDs have response times so low that the problem is nearly eliminated. Further developments such as overdrive (Increasing response times by going past the desired setting and then back again) have further improved it.
So, WHY are they going to go and introduce flickering LCDs?
This is like hitting someone on the head with a hammer in order to kill a fly. The "solution" is way worse than the problem.
That's essentially what I meant, though you've got it a bit wrong. Both Microsoft and Sony are using the PowerPC architechture (Cell is PowerPC based). It's just that Microsoft's solution, while still custom, is less fancy. As in closer to existing technology. They also opted to offload a lot of the work to ATI, it seems; the XBox 360 sports 512MB of memory that is used for both system and GPU, and I imagine ATI probably played a hand in the development of the memory management system.
This unified memory system seems to be simpler than the odd hybrid solution that Sony has going for the PS3. But I don't know much about the details of their respective memory systems.
You may be wrong about the CPUs being overkill, though. The Cell has one main core and a bunch of small cores that are almost like DSPs. They have no branch predictor, so they are nearly useless for any code that needs any control flow (Like an IF statement). The only time they can really be used for branching is when the branching was random (Physics engines). Most stuff, however, will be limited to the PS3's one primary core (PPE).
The XBox features three cores that are essentially the same as the Cell's PPE. However the difficulty here also means that many games will only use one of the three cores. Some engines and tools will certainly take advantage of the multiple cores, but many won't. Microsoft is going to offset this by offloading a lot of the 360's core software (The interface and media aspects) to the third core.
It should also be noted that the cores themselves in both the PS3 and 360 are very ill suited for gaming. It is estimated that each core in the 360 are about twice as fast for gaming-related code as the P3 in the original XBox. That puts it at the speed roughly of a 1.5ghz P3. Not exactly a screaming fast CPU.
You can argue that the 360 has three such cores, but obviously three cores doesn't lead to anywhere near three times the available power for game engines.
As I understand it the 360's cores are ideal for rendering. This means that the 360 and PS3 are going to have incredible graphics, especially paired with their insanely powerful GPUs. But other areas such as AI are going to suffer as a result.
Keep in mind Microsoft (And Sony) sell their consoles at a huge loss, initially (They cost Microsoft more to make than they sell them for). Price is entirely dependant on how much of a loss the manufacturer is willing to make (They hope to make it back on game licencing/sales).
Unfortunately, Microsoft doesn't really have a choice about introducing their next-gen console (360) now. I don't think at all that they're treating the console world like the PC world, they're only realizing that Sony's next system is coming out, and they need something better than the XBox to compete against it. It's not a matter of treating it like the PC market, it's a matter of competition, staying alive in the marketplace.
The fact that the 360 is coming out 6 to 12 months earlier than the PS3 is simply due to the fact that Sony was more ambitious with the PS3, so it is taking longer to finish. Microsoft went for a simpler approach, and so they're ready earlier. And they see an advantage in being the first to market.
Sony might expect the PS3 to last 10 years, but will the market let it last that long?
Would anybody have purchased the playstation if the N64 had cost $99 and the PS1 had cost $599? Well, yes, I'm sure people would, but a heck of a lot less than would have otherwise.
Microsoft intends to price to 360 at about $249 to $299 US, from what I've heard. That is certainly pricey, but still within the realm of affordability. How many people are going to buy both the 360 and PS3 if the 360 is selling for $249 and the PS3 is selling for $499?
The two systems are ballpark equivalent in power. Yes, I know, the PS3 has more raw CPU power (But can it be used?), and the 360 has more raw GPU power. The PS3 has BD-ROM support, the 360 has DVD. But they're not that far off eachother.
So, being ballpark equivalent, if Sony sells the PS3 for a significantly higher price than Microsoft, AND Sony starts selling it 6 to 12 months later than Microsoft, I don't think they will get the sort of marketshare that people predict they will. There might be a lot of people that will pay $499 for a console, but there are a lot less people who will pay $499 for the PS3 and buy the 360 for $249 at the same time.
Of course, I'm only guessing that the PS3 is going to cost $499. Sony said it won't be cheap, and people consider the 360 pricing to be reasonable, so I assume that means the PS3 is more than the 360. I'm just guessing, really.
Even with the higher latency on the i-RAM, I'm betting that applications are throughput limited, not latency limited. So it would be the 100MB/s performance (I think that was sustained, not peak, it doesn't make sense for the i-RAM to have a peak) that would be the limiting factor.
Now, say we're reading in data. The latencies are low enough that we're keeping the bus more or less saturated at 100MB/s. What are the caches supposed to do? If we're talking about a cache of data we've already read incase we need it again, that's one thing, but I'm talking about a read-ahead cache.
A read-ahead cache, as I understand it, normally tries to anticipate what an application might want, and reads it ahead of time. This isn't a sure thing, and it often gets it right, and sometimes gets it wrong, reading in data that is never requestsed.
But the thing is, if we're throughput limited, spending bandwidth filling a read-ahea cache would be wasted bandwidth. If the drive is transferring at full tilt any time spent filling a cache rather than reading from disk would be wasted time. That's why I think caches might not be useful.
But, as I said, a cache of already read data, that would help, sure.
But the interface DOES matter. The RAM is capable of 1.6GB/s, so it should certainly be able to saturate a 300MB/s SATA2 link. Most (many?) new motherboards already support SATA2. The current i-RAM only sports a realworld transfer rate twice that of a Raptor, assuming sequential reads.
They're already doing everything with an FPGA, so it should be very easy to add SATA2 support; the worst case would be that they need to toss in a faster FPGA (or one with more gates) which might drive the cost up. But without research I can't say for certain how much.
My primary qualm, however, is that the article didn't even MENTION SATA2, not even as a future possibility. Not even as a "This device would be much faster with SATA2 support".
That's the thing, it might not support SATA2, but they didn't even MENTION it in the article. I would have expected at least a mention of "While the i-RAM doesn't support SATA2, we can't wait to see what it can do with SATA2 support in a future revision."
Databases are not a very good use of it. For example, MySQL can create HEAP tables that exist entirely in RAM. System RAM isn't limited by SATA, so if you have 4GB of RAM to put towards a database, chances are you'd be better off running it out of real RAM.
That and putting more RAM towards database cacheing is probably better than putting it towards the i-RAM.
As the other reply mentioned, it's an SATA drive so limited to 150MB/s (100MB/s in practice). The latency is very low, yes, but that's not the only factor. There is only so much you can do with double the bandwidth, no matter how low the latency is.
I also wonder if the benchmarks were done with drive caches on or off. I would imagine that this drive would be faster with caches off. With what might as well be zero latency on disk accesses, the benefit of a cache is lost; reading ahead probably will only waste bandwidth reading stuff we may not need.
I'm very disappointed that the article didn't mention SATA2 (300MB/s), which is already available in most new motherboards. With double the bandwidth it would have made a big difference. It's very likely the device doesn't support SATA2. However the Anandtech article makes NO MENTION at all of SATA2, not even to the point of saying "We'd like to see this drive with SATA2 support."
I got an idea, how about stepping up to the plate and declining to take any job that is going to treat you unfairly?
Because most employers have such clauses, getting a job without one is extremely difficult. With the current job prospects in the industry, people often don't have a choice.
Given a choice between two equal jobs, one with a non-compete agreement and one without, obviously people will choose the one without. But when the one without isn't available, what are we supposed to do? Collect unemployment insurance and live off carrots until we find a job?
I'm currently a co-op at a software development company. I signed a non-compete agreement as part of my co-op. Luckily, I objected that the 2-year period was unreasonable since it would prevent me from completing future work terms. The management agreed fully and shortened the term to the point where it won't conflict (I think it was 4 months) with future terms. I found this acceptable.
I think that the fact that EA is the publisher is mostly irrelevant. Valve is (was) in a very unique position; they are an independant developer with a huge franchise looking for a publisher. Any publisher would kill to publish the game, under extremely tight restrictions. If a publisher doesn't like the restrictions, Valve can say, fine, publishers are knocking down the door to get this deal.
I suspect that the contract that Valve has with EA gives EA absolutely no control over the games themselves. EA normally only has control of games because they either made a game themselves, own the company that made the game, or put forth cash to make the game. Valve has plenty of cash, so they don't have any reason to give EA any control over their games at all.
I am guessing that the deal that Valve has with EA is pretty much "We supply the games, you publish them, end of story." I don't think we'll see EA delaying future releases via Steam because they're not on shelves yet; Valve didn't like it when Vivendi did that.
In short, I think that EA is simply a vehicle to get products on shelves and will have no control over anything. For those of us who hate EA and would rather our money didn't go to them, this is exactly what Valve's excellent STEAM platform is designed to do.
I purchased HL2 via STEAM. Vivendi didn't get a penny, though Vivendi did set a minimum price that Valve could charge. And now that EA is Valve's new publisher, EA won't get any of my cash; it's going all to Valve.
It fixed the memory leaks from 2.3.x.x, yes. It still takes a lot of memory though (Your definition of a lot may vary), though it makes up for it in power/flexibility.
Slashdot Mirror
Really, and who is? Microsoft? Google Maps and associated images are hosted by Google.
Apple won't be the "only", in fact they won't even be one at all. This is because this slashdot article is blatantly wrong; Apple's new x86 macs DO use DRM. They have the TPM chips on the motherboard. They have TPM-related kernel calls. THE OS WILL NOT PROPERLY RUN WITHOUT THE TPM CHIP.
e buttal
Here is OSx86's official rebuttle saying why this "no DRM in macs" is a load of crap:
http://www.osx86.classicbeta.com/wiki/index.php/R
Adding another frequency doesn't give you full duplex communication, it just doubles effective network bandwidth.
You can call it full duplex I suppose, but even then it's shared full duplex. So long as there are only two devices, they can transmit to eachother on seperate channels. But what happens when a third device pops onto the network? It needs to send on one of those two channels, and devices need to send to it on one of those two channels. You still end up having only two channels, but three devices.
Personally I thought that mimo involved sending the exact same signal out through multiple antennas and then using the multiple identical signals for greater signal strength, such as using bouncing signals to their advantage.
Either way, it isn't full duplex wireless. The only potential full duplex wireless technology is UWB, because there is the potential for so many differeng timing patterns that every device could have their own, so non-shared full duplex (Until you ran out of timing patterns, in which case you can increase the resolution).
SeaMonkey is "SeaMonkey". Firefox is "Firefox". Neither product uses "Mozilla" in the title. It looks more like a change in naming convention than a matter of being allowed to use it or not. They're on equal ground.
There is a difference, of course, in the focus. SeaMonkey is a "Project" and Firefox is a "Product". They're both on the Mozilla site, and since Mozilla's focus is Firefox, SeaMonkey is rightfully less important (Ignoring the reasons for why it is or isn't).
Personally I am happy that Mozilla moved over to Firefox. The Mozilla Suite was a bloated mess in that it did so much that people often didn't want. Do I really need an IRC client built in, and a HTML editor, newsgroup browser, and the kitchen sink? Jack of all trades, master of none. Except I don't USE most of the trades.
That was the problem with the suite. Everyone wanted something it did, but also everybody didn't want something it did. With the new system I can grab the parts I want (Firefox, Thunderbird) without the extra bloat that I couldn't care less against.
Complaining that Mozilla shifted focus away from browser suites is like complaining that Microsoft shifted focus away from Windows 3.1. Progress marches on and we do away with antiquated stuff that isn't suited to the current environment.
First off, 802.11n doesn't exist. It won't exist for years (OK, maybe one) until the standard is done. You are probably referring to something like Belkin's "pre-n" products, which have NOTHING to do with 802.11n.
Second, wireless networks are by definition half duplex, just because the wired connection to an access point is full duplex doesn't mean the wireless connection is too. Think about it, only one transmission can happen on a wireless network at a time. That is, only one packet can be moving at any given time. You have only one frequency you broadcast and receive on. If you are receiving a packet that means somebody else is sending a packet. If you were to try to send a packet while receiving, you'd have two people broadcasting at the same time. That doesn't work.
And don't forget there is a world of difference between advertised speed and actual speed.
If the pattern holds true to the same as 802.11g, we will see 200mbit at close range, and 100mbit at normal range.
In other words they will claim 540mbit but we'll get 100mbit wired performance.
The problem is that even 540mbit is not enough because a wireless network is like a hub, not a switch. All bandwidth is shared, and it is half duplex; only one person can send at a time on the entire wireless network. 540mbit sounds amazing, but even at the 200mbit you get at close range, if you have ten people on the network, each can only get 20mbit if they all transfer at the same time. I imagine collisions would further reduce that. And cut some more off for upstream usage.
Please, any probe of they were this kind of information?
Huh? Make sense man.
I have one prove of this site doesn't exists and were not exists: go to www.mojihedun.com or search in google and/or yahoo the word "mojihedun".
You didn't look very hard. Your google search should have pointed you to "mojahedin", which produces many results. There are various very similar names for the group. It's a militant Iranian group.
You will only found the same note as you publish in the (Surprise!) www.timesonline.co.uk publication.
Umm, I'm not the author of the article. I didn't publish anything. See my previous note on this. It's not my fault the author of the article can't spell.
And what sites thinks the UK Governments are "moderates"?
I don't know, why don't you ask them. I'm not a UK citizen, let alone the UK government.
You should RTFA. A quote from TFA:
One global jihad site terminated recently was an inflammatory Pakistani site, www.mojihedun.com, in which a section entitled How to Strike a European City gave full technical instructions. Tens of similar sites, some offering detailed information on how to build and use biological weapons, have also been shut down. However, Islamic sites believed to be "moderate", remain.
That probably isn't enough since we have to assume we might be going through a proxy. At the very least we have to tell the proxy not to cache anything.
And what port is that C daemon going to listen on? Port 80? What if that is proxied? The only thing that is certain to get through is HTTP traffic.
I'd go for a much simpler approach. It depends on how accurate this needs to be, but find a web server with accurate time (Perhaps a friend has webspace or a dedicated server, or even a home DSL/Cable connection), and put a one-line PHP, Perl, anything, script on it that simply sends the timestamp. Perhaps try to speed things up marginally by removing all but the crucial headers.
Then, on the client side, a short script that is called by cron every so often. The script simply downloads the output of the PHP script, times the download, and sets the system time to the downloaded time plus half the time taken for the download. Is it perfectly accurate? No. Is it good enough for almost any use? Yes.
Using the half-the-download time is sort of cheating, but it gets you close enough to the actual time, and it's dead simple. The original poster doesn't specify how accurate he needs this to be, but as a rough guess I'd say that the method I've outlined will probably sync the time on the two servers to closer than a quarter second.
This is because my fear is that the technology will become popular enough to impact my choice of LCDs without this feature. Not buying it isn't going to solve any problems.
On the other hand, complaining about it on Slashdot isn't going to help at all either, so it's a moot point.
I really think this is a step backwards in that it doesn't solve the problem, it just masks it. The response times are still the same.
I question if you've ever used a modern high end LCD. Ghosting has been more or less eliminated since the response times have dropped so low. These aren't the 35 or 50ms LCDs of the past ( I remember using an LCD with a response time of 150ms, what a nightmare).
Current LCD response times have dropped to 8ms where the problem is pretty much gone.
Personally I find the flickering of CRTs causes quite a bit eyestrain, even at so-called flicker-free refresh rates. And in order to get a CRT that supports higher refresh rates you're going to pay as much or more than an LCD.
Desk space means nothing to me, I care about two things with LCD. One is that they are much sharper. The other is that they don't flicker.
That said I'm eagerly awaiting OLED displays. All the benefits of LCDs, but with contrast ratios and response times like a CRT. All while being thinner and using less power than an LCD. There's nothing not to like, other than possibly their shorter lifespan.
But it is, since it may or may not be noticeable, and it actually does improve response times.
Flickering, however, verges on headache inducing, and doesn't actually improve response times. It just hides the pixels while they are changing.
One can only hope that the market rejects these new LCDs... Luckily when OLEDs take over this won't be a problem since they have CRT-like response times to begin with.
I hope these new displays fail horribly. This is the LAST thing we need...
Modern LCDs have response times so low that the problem is nearly eliminated. Further developments such as overdrive (Increasing response times by going past the desired setting and then back again) have further improved it.
So, WHY are they going to go and introduce flickering LCDs?
This is like hitting someone on the head with a hammer in order to kill a fly. The "solution" is way worse than the problem.
That's essentially what I meant, though you've got it a bit wrong. Both Microsoft and Sony are using the PowerPC architechture (Cell is PowerPC based). It's just that Microsoft's solution, while still custom, is less fancy. As in closer to existing technology. They also opted to offload a lot of the work to ATI, it seems; the XBox 360 sports 512MB of memory that is used for both system and GPU, and I imagine ATI probably played a hand in the development of the memory management system.
This unified memory system seems to be simpler than the odd hybrid solution that Sony has going for the PS3. But I don't know much about the details of their respective memory systems.
You may be wrong about the CPUs being overkill, though. The Cell has one main core and a bunch of small cores that are almost like DSPs. They have no branch predictor, so they are nearly useless for any code that needs any control flow (Like an IF statement). The only time they can really be used for branching is when the branching was random (Physics engines). Most stuff, however, will be limited to the PS3's one primary core (PPE).
The XBox features three cores that are essentially the same as the Cell's PPE. However the difficulty here also means that many games will only use one of the three cores. Some engines and tools will certainly take advantage of the multiple cores, but many won't. Microsoft is going to offset this by offloading a lot of the 360's core software (The interface and media aspects) to the third core.
It should also be noted that the cores themselves in both the PS3 and 360 are very ill suited for gaming. It is estimated that each core in the 360 are about twice as fast for gaming-related code as the P3 in the original XBox. That puts it at the speed roughly of a 1.5ghz P3. Not exactly a screaming fast CPU.
You can argue that the 360 has three such cores, but obviously three cores doesn't lead to anywhere near three times the available power for game engines.
As I understand it the 360's cores are ideal for rendering. This means that the 360 and PS3 are going to have incredible graphics, especially paired with their insanely powerful GPUs. But other areas such as AI are going to suffer as a result.
Keep in mind Microsoft (And Sony) sell their consoles at a huge loss, initially (They cost Microsoft more to make than they sell them for). Price is entirely dependant on how much of a loss the manufacturer is willing to make (They hope to make it back on game licencing/sales).
Unfortunately, Microsoft doesn't really have a choice about introducing their next-gen console (360) now. I don't think at all that they're treating the console world like the PC world, they're only realizing that Sony's next system is coming out, and they need something better than the XBox to compete against it. It's not a matter of treating it like the PC market, it's a matter of competition, staying alive in the marketplace.
The fact that the 360 is coming out 6 to 12 months earlier than the PS3 is simply due to the fact that Sony was more ambitious with the PS3, so it is taking longer to finish. Microsoft went for a simpler approach, and so they're ready earlier. And they see an advantage in being the first to market.
Sony might expect the PS3 to last 10 years, but will the market let it last that long?
Would anybody have purchased the playstation if the N64 had cost $99 and the PS1 had cost $599? Well, yes, I'm sure people would, but a heck of a lot less than would have otherwise.
Microsoft intends to price to 360 at about $249 to $299 US, from what I've heard. That is certainly pricey, but still within the realm of affordability. How many people are going to buy both the 360 and PS3 if the 360 is selling for $249 and the PS3 is selling for $499?
The two systems are ballpark equivalent in power. Yes, I know, the PS3 has more raw CPU power (But can it be used?), and the 360 has more raw GPU power. The PS3 has BD-ROM support, the 360 has DVD. But they're not that far off eachother.
So, being ballpark equivalent, if Sony sells the PS3 for a significantly higher price than Microsoft, AND Sony starts selling it 6 to 12 months later than Microsoft, I don't think they will get the sort of marketshare that people predict they will. There might be a lot of people that will pay $499 for a console, but there are a lot less people who will pay $499 for the PS3 and buy the 360 for $249 at the same time.
Of course, I'm only guessing that the PS3 is going to cost $499. Sony said it won't be cheap, and people consider the 360 pricing to be reasonable, so I assume that means the PS3 is more than the 360. I'm just guessing, really.
But the question is how data gets into the cache.
Even with the higher latency on the i-RAM, I'm betting that applications are throughput limited, not latency limited. So it would be the 100MB/s performance (I think that was sustained, not peak, it doesn't make sense for the i-RAM to have a peak) that would be the limiting factor.
Now, say we're reading in data. The latencies are low enough that we're keeping the bus more or less saturated at 100MB/s. What are the caches supposed to do? If we're talking about a cache of data we've already read incase we need it again, that's one thing, but I'm talking about a read-ahead cache.
A read-ahead cache, as I understand it, normally tries to anticipate what an application might want, and reads it ahead of time. This isn't a sure thing, and it often gets it right, and sometimes gets it wrong, reading in data that is never requestsed.
But the thing is, if we're throughput limited, spending bandwidth filling a read-ahea cache would be wasted bandwidth. If the drive is transferring at full tilt any time spent filling a cache rather than reading from disk would be wasted time. That's why I think caches might not be useful.
But, as I said, a cache of already read data, that would help, sure.
But the interface DOES matter. The RAM is capable of 1.6GB/s, so it should certainly be able to saturate a 300MB/s SATA2 link. Most (many?) new motherboards already support SATA2. The current i-RAM only sports a realworld transfer rate twice that of a Raptor, assuming sequential reads.
They're already doing everything with an FPGA, so it should be very easy to add SATA2 support; the worst case would be that they need to toss in a faster FPGA (or one with more gates) which might drive the cost up. But without research I can't say for certain how much.
My primary qualm, however, is that the article didn't even MENTION SATA2, not even as a future possibility. Not even as a "This device would be much faster with SATA2 support".
That's the thing, it might not support SATA2, but they didn't even MENTION it in the article. I would have expected at least a mention of "While the i-RAM doesn't support SATA2, we can't wait to see what it can do with SATA2 support in a future revision."
Databases are not a very good use of it. For example, MySQL can create HEAP tables that exist entirely in RAM. System RAM isn't limited by SATA, so if you have 4GB of RAM to put towards a database, chances are you'd be better off running it out of real RAM.
That and putting more RAM towards database cacheing is probably better than putting it towards the i-RAM.
As the other reply mentioned, it's an SATA drive so limited to 150MB/s (100MB/s in practice). The latency is very low, yes, but that's not the only factor. There is only so much you can do with double the bandwidth, no matter how low the latency is.
I also wonder if the benchmarks were done with drive caches on or off. I would imagine that this drive would be faster with caches off. With what might as well be zero latency on disk accesses, the benefit of a cache is lost; reading ahead probably will only waste bandwidth reading stuff we may not need.
I'm very disappointed that the article didn't mention SATA2 (300MB/s), which is already available in most new motherboards. With double the bandwidth it would have made a big difference. It's very likely the device doesn't support SATA2. However the Anandtech article makes NO MENTION at all of SATA2, not even to the point of saying "We'd like to see this drive with SATA2 support."
I got an idea, how about stepping up to the plate and declining to take any job that is going to treat you unfairly?
Because most employers have such clauses, getting a job without one is extremely difficult. With the current job prospects in the industry, people often don't have a choice.
Given a choice between two equal jobs, one with a non-compete agreement and one without, obviously people will choose the one without. But when the one without isn't available, what are we supposed to do? Collect unemployment insurance and live off carrots until we find a job?
I'm currently a co-op at a software development company. I signed a non-compete agreement as part of my co-op. Luckily, I objected that the 2-year period was unreasonable since it would prevent me from completing future work terms. The management agreed fully and shortened the term to the point where it won't conflict (I think it was 4 months) with future terms. I found this acceptable.
I think that the fact that EA is the publisher is mostly irrelevant. Valve is (was) in a very unique position; they are an independant developer with a huge franchise looking for a publisher. Any publisher would kill to publish the game, under extremely tight restrictions. If a publisher doesn't like the restrictions, Valve can say, fine, publishers are knocking down the door to get this deal.
I suspect that the contract that Valve has with EA gives EA absolutely no control over the games themselves. EA normally only has control of games because they either made a game themselves, own the company that made the game, or put forth cash to make the game. Valve has plenty of cash, so they don't have any reason to give EA any control over their games at all.
I am guessing that the deal that Valve has with EA is pretty much "We supply the games, you publish them, end of story." I don't think we'll see EA delaying future releases via Steam because they're not on shelves yet; Valve didn't like it when Vivendi did that.
In short, I think that EA is simply a vehicle to get products on shelves and will have no control over anything. For those of us who hate EA and would rather our money didn't go to them, this is exactly what Valve's excellent STEAM platform is designed to do.
I purchased HL2 via STEAM. Vivendi didn't get a penny, though Vivendi did set a minimum price that Valve could charge. And now that EA is Valve's new publisher, EA won't get any of my cash; it's going all to Valve.
It fixed the memory leaks from 2.3.x.x, yes. It still takes a lot of memory though (Your definition of a lot may vary), though it makes up for it in power/flexibility.
Insert mandatory NetForce reference here.
Of course, this is Homeland Security, and NetForce is supposed to be FBI and later DoD.