For current Intel core2, to get the Rpeak, take the number of cores total * clockspeed * 4. A single quad core 2.0 GHz gets you to 32 gflops already. You can readily build a rig with a single quad-core 2.0 ghz for less than 2,500. This is incredibly a non-event. It serves as a handy demonstration of how supercomputers are roughly architected today to people not in the industry, but the price/flop is noting special at all.
I still run Ubuntu (hasn't done anything to date to make me want to leave, and is doing a good job of bringing new technology to me in a stable form than others with their release cycle.
I will say, hawever, the 'easier to manage' part is largely people who were disenchanted with the RedHat situation a long time ago. Since finally adapting yum, the RedHat/CentOS world has something that is roughly equivalent to apt (IMO, the key thing that RH didn't officially have that made the difference). Yum has behaviors I don't like (i.e. yum search is much harder to parse through than aptitude search), but the fact remains, I admin a CentOS server and it's trivial to manage, not that different from Ubuntu anymore.
I tried Fedora back in the day, but they were, at the time, too aggressive and things broke frequently and behaved poorly (this was the Fedora Core 1/2 days), but I have no idea how they are now. I will say Ubuntu gets things done in a good balance, but I don't claim that the others haven't adopted strategies/policies that bring it up to par.
I couldn't begin to keep track of how many times I've heard that one in the industry. 'X is broken'. 'Well, our new architecture can't theoretically acheive X anymore, so it's a design limitation, not a bug'.
On the/etc/passwd thing, first off, I don't see what they could get from that in 99% of systems. As has been noted *many* times before, no password or hash of a password is stored there most times. You mention 'real' names, which *possibly* in there, but the *vast* majority of desktop linux installs I see don't have anything accurate for the users full name. Any attempt to correlate that data, for whatever bizarre reason, wouldn't get them very far. Almost certainly all the worrisome/etc calls are made by auxilarly libraries in the course of trying to fulfill run-of-the-mill calls. The browser profile walking seems bizarre and probably the place where skype should answer, and the potential place where things like AppArmor and SELniux really come into play, where a single user wannts to segregate application data all run by the same user. I can't see why anyone would worry about/proc/interrupts, and can easily see how opening that is relevant to an application using an audio device/has realtime characteristics. If some counter in interrupts is increasing, that info may be helpful to know if someone files a report and says the audio is skipping, an interrupt going nuts would explain that readily.
I'd have cancelled my cable TV long ago if it weren't for my PVR. Offtopic, but I don't have cable and use MythTV+Airstar HD500 (cheaper alternatives exist nowadays) to DVR the broadcast networks. AFAIK, it's the only way to do something DVR-ish without a cable or satellite service. Though admittedly, zap2it has left me in a bit of an pinch with respect to a PVR without any recurring fee...
You are correct in that it isn't a pure GPS situation in most all phones, but it doesn't mean it isn't interacting with GPS satellite signals, see http://en.wikipedia.org/wiki/Assisted_GPS. GPS takes more time and is more picky about quality signal from satellites. aGPS still has some degree of satellite signal being received at the phone, but either sends that data to the tower which uses it's more optimal GPS situation to provide a lock, or receives the extra data from the tower. In other words, it isn't necessarily any less precise, just potentially dependent on communication with a tower and less time needed from the point of being turned on to being able to pinpoint the location.
1) Has J&J properly defended their trademark before? If the trademark is seen as having a universal meaning (like Kleenex or Xerox), then they can lose their right to it. I just want to mention that Kleenex and Xerox are *not* yet legally genericized. (http://en.wikipedia.org/wiki/List_of_generic_and_ genericized_trademarks). Note they appear under the 'at risk' category, but still not in public domain. Escalator is an example of a truly generecized trademark.
As to other things, I can see how it comes about that ARC is being sued as they have started to go to J&J competitors to allow use of the red cross for products, and the previous understanding is therefore being violated. It seems like early on some sort of agreement was reached that both ARC and J&J could use the symbol, but for different applications. In this case, medical supplies and charity medical aid seem *really* close and hard to distinguish, so it gets a bit strange. It might be the case that if J&J started a for-profit blood-blank with big red crosses on their trucks, that ARC could sue them. Kinda like how Apple computers and music *were* trademarked in their separate industries, and neither was legally allowed to infringe on the other (of course, that all changed).r
Sony had a significant headstart in the market to Xbox and Gamecube. The only competition for them their first Christmas season was Dreamcast, and many people recognize Sega only ever had any measure of success with the Genesis. They had the momentum of PS1 success behind them (even if they couldn't have played PS1 games, which was a huge boon in and of itself, giving it technically the largest launch library to date, they had business relationships with the third party vendors to logically continue series on the PS2 platform). Microsoft was starting from scratch (loser relationships with PC game publishers count for something, but not with the control strategy and tight relationships of the console world), and Nintendo to an extent repeated one of the N64 blunders (small game media), and did nothing to tap into previous console libraries and, of course, had lost so many third parties to Sony. Add to the fact that Sony embraced DVD in terms of video playback out of the box, and you see the PS2 to be one of the most intelligently planned product launches of its time. It's no wonder that PS2 was far and away the 'winner', and from what I see, was a well-earned win. Totally the opposite of the rather bumbled PS3 launch situation, the wrong time to make mistakes when Nintendo has done something so smart.
If your active distribution *can* run 64-bit, all the drivers are 64-bit. The kernel must be 64-bit (and by extension all drivers, where we define drivers as loadable kernel modules). It's simply not that big a deal as the lion's share of the drivers of interest were open source and the change to a new architecture for many was little more than a recompile, however, there were many exceptions, and early adopters of x86_64 linux distros are probably painfully aware of them. Source code explicitly calling out uint32 data types as memory addresses, some funky things with PCI addressing and memory holes, etc etc. I think the open source world benefits somewhat from 'code nazis' with nothing better to do than nitpick such peculiarities as they find them, even before they would have functional impact, while commercial development has project managers with whips to meet schedules, leaving no time for being pedantic. Additionally, many of the most popular drivers frequently were somehow applicable to an existing 64-bit platform (i.e. sparc and ppc64), therefore the code had largely already evolved to be more platform agnostic, or at least trained a large number of OSS developers in how to do it so porting of those drivers was not bizarre. Applications are another matter, i.e. because of Sun's Java plugin and flash, my 64-bit systems still run 32-bit firefox, and provided all the libraries are there, the 64-bit kernel doesn't mind hosting 32-bit applications at all.
Now Windows 64-bit is a different set of circumstances. Most drivers have source guarded by the hardware vendor, and most of these hardware vendors ever really cared about support Windows and the only platform where Windows dominated was x86. Thus the situation is pretty grim for those companies, many of which still don't care about 64-bit, and the ones that care being ill-equipped for knowing the sorts of things that break in a platform change of this sort. The fact that the driver API is so close to what they've been using, it means the logical schedule move for them is to try to port their existing code. Of course, as Vista has shown, the commercial vendors have even more of a hard time getting it right porting from XP driver model to Vista (even without an arch change) than 32 bit to 64 bit within the same driver model.
-Re-releasing their old, popular titles over and over and over again for big bucks with very little effort. (the reason they avoid Wii's virtual console like the plague is because people are *still* willing to pay ~50 bucks for the same game they already bought for ~50 bucks at least twice already, crazy fandom... The games were good, but not good enough to sign up for being repeatedly reamed).
-When they do release a 'new' game, it's been increasingly more style over substance. The shinier and more polygon count, the better. The more cinematic-like cutscenes, etc. PS3 has the Blue-Ray format, allowing for significant amounts of storage, and the graphics subsystem to do their 'ooh shiny' bits. Wii does not have the graphics/processor capability to do that to the same extent. Wii is a lot of things, but rendering real-time graphics it is significantly less adept at. DVD has a lot of storage, but give Square the license to use up to a BD-ROM's capacity, and they'll probably eat it up.
To me, Square jumped the shark a bit ago. From Square's perspective they probably think (and perhaps accurately so) that it doesn't matter *what* platform they release for. If only 2 million PS3s exist in households, and they release for PS3, they probably think people will buy the PS3 *just* to play their game if nothing else (evidently, this may be the case here as well). Square and Sony have a certain hubris in common about how infallible their new product will be in the marketplace. Sony crammed a number of agendas into the PS3 and priced it high, because they thought they just couldn't lose. Maybe Sony is starting to/would soon see the light, but Square hasn't had such a humbling experience yet.
Even 10Gbps PCIe NICs for computers only push about 6-7Gbps... Not to take away from your point, but 10GE PCI-E NICs do exist that can push things at about line rate. They use 8 PCI-E 1.0 lanes to ensure sufficient bandwidth to do so, so a hypothetical system teaming four such NICs would use up 32 lanes of PCI-e (16 if you go to PCI-e 2.0). Even at 16, you'll have a hard time finding a chipset that can accommodate that and disk storage and graphics.
Oh, and to further strengthen your argument, current storage technology has a theoretical throughput of 3.0 Gbps per disk. Assuming you could acheive 40 Gbps to a functional PC, you'd need a 14 drive non-redundant array to even theoretically have the numbers to download to disk, of course, that would require an equal number of pci-e lanes to get to a hypothetical controller that could handle the throughput. If trying to use a ram-backed storage strategy, you'd use up all memory of, say, 8GB in less than two seconds. Unless 4 GB of data can be discarded per second, that won't work either.
So, absolutely for any realistic home use, the throughput in the article is useless, since no media has currently ludicrous requirements where 4 GB of data per second can be consumed and discarded per second, and storage becomes the bottleneck for downloading. There exist applications that can benefit from transferring that much data over a network, crunching on it and being done with 4 GB datasets in a second, but they are few and far between and none really applicable for a home computer.
Don't think the DVD feature was *that* key in terms of movie at least.
PS1 came in with optical media with the incredible storage space relative to the Nintendo 64 offering, and the only other possible contender was Saturn of the era, which lacked the 3D capability to keep up with the other two consoles in a genre where 3D was what made them new and different from previous games. As a result, PS1 gained an incredible library of games.
The next round, Sega was first to market with Dreamcast, which had either CD or a goofy GD-ROM format which wasn't much better, so storage per game was not significantly better than PS1. The graphics were truly great, to its credit. The controllers were awkward and it had to stand completely on its own in terms of available game library. Sega marketing failed to overcome Sony teasing its customerbase over the PS2, and failed to attract many good games nor produce first-party titles that were compelling. Sega's only real success was the Genesis, and that's largely only because they had a two year head start in the market before SNES came along. When PS2 released to a market that still hadn't embraced Dreamcast, at a price-point not much higher than Dreamcasts, with a media that was significantly larger (attracting publishers looking to reduce disk-swaps), and the ability to play the PS1 games, they instantly had a formidable game library to draw own. Xbox and Gamecube came significantly later, neither with an existing library to tap into.
Now this round, everyone came out at the same time. Sony seems to be trying to use PS3 to push BlueRay (not the other way around). Seems like they perceived how well they did with PS1 and PS2 and assumed PS3 would be a success, so they better put something they really want to win on it, so they both would be winners. In doing so, more aggressively than with DVD, they pushed the price unreasonably high. That, and very few titles spanned more than one DVD, so the capacity leap for games didn't seem pressing. Both MS and Sony largely stuck with what had been working, same thing they did last time but with faster bits for prettier games. Nintendo, not having a big success since SNES days, stayed budget conscious and had an innovative controller strategy. They had the sense finally to support their previous systems games, but took it a step farther by setting up an infrastructure to easily acquire and run games all the way back to the NES, as well as some former competitors' systems. Nintendo executed the best to-date utilization of legacy titles as well as offering something truly new and different without compromising budget too much. It's a well-earned success. My concern here is that Nintendo gets to be the asshats they were back in the 80s with respect to third parties.
Considering the extent of half-assed guessing in terms of capability, I would take the numbers with a grain of salt (think either side can make numbers work as they wish). However, to play devil's advocate and assume that an AS/400 is approximately 60 x86 servers, let's take your points one by one:
1) Rackspace. Higher density (i.e. 84 per rack) configurations exist in the form of blade servers and some less sophisticated rackmount systems.
2) Power. Again Blades come in. At least the blades I work with will have two power supplies per half a chassis (for redundancy). Significantly reducing the inefficiencies.
3) Cooling. Similar deal, cooling is acheived more efficiently through use of fewer blowers. However, you'd have to compare the components in each in terms of TDP to get a feel for how much heat you have to move (not all racks are equally coolable, as you seem to suggest). Additionally, the common power supply further mitigates the problem you suggest.
4) Ok, add the cost of that much switching equipment. As long as we are at it, admit blades in the initial purchase price are more expensive and take it down a few servers I suppose.. The difficulty of managing that many IP addresses is trivial if you know what you are doing.
5) Storage You skipped minimal ramroot or cheap low-capacity flash storage. It's obvious the network will be utilized to some extent depending on your application, si it is really rough to determine what is or is not appropriate. There are sem situations in which a valid metric is aggregate disk write/read performance among nodes, in which case 60 distinct disks would be the only way to get some sustained throughput numbers (any individual hard drive is only so fast after all). So if you don't need 60 disks in the AS400, you can probably get away with a similar amount of disks somehow in the x86 server case.
6) Who cares about video console? Serial console (through serial console servers or SOL on modern BMCs) gives everything I ever need. Though, admittedly, 60 consoles could be more to manage, but the goal of managing systems at scale is to avoid touching any one of them except through some automated scripting or catastrophic hardware failure.
7) Sys admins. I'm regularly in charge of hundreds of systems at a given time, with a current maximum of 2,000 systems with me being solely responsible. If you can live on an AS/400 and are reproducing that sort of situation in x86 world, the environment can be so homogeneous amongst the servers as to make it scale up in number pretty well from the administrative standpoint.
8) Fault tolerance. Well that was in part the point of so many servers. If uber-paranoid, high-risk components (fans, drives, power-supplies) on moderate x86 architecture servers are generally hot-swappable, with the low-risk components (solid state stuff) generally able to detect failures and correct or bail out as appropriate for service). In the case of those huge failures or cheaping out on system-level redundancy, the higher layer of your app would provide redundancy between servers.
9) Service contract. That's a function of your vendor, nothing to do with the architecture. And most vendors afaik recognize that a support contract for a huge set of servers should scale up less steeply than linearly. (It's not 60 times harder than 1 server, it's somewhere less than that).
The picture obviously isn't simple, and even IBM is rather multiple-personality on the issue (they offer z,i,p,x lines of systems, obviously indicating a perceived benefit for each, or just confusion). Ultimately, if you are going to dump that much money into a large solution, in depth investigation of the options would be much better than anything we will post in slashdot comments.
In the broader sense of an 'architecture' in my mind, AMDs has a more advanced one than Intel (the integrated and hypertransport IO/multi-processor strategy).
Intel does, however, have a faster processor design than AMD's released product. If Barcelona levels the field in terms of instructions per clock, then the ball is back to Intel's court to at least meet AMDs memory/SMP/IO architecture or offset that deficiency with another leap in the processor technology. I hear Intel's roadmap eventually brings in a more AMD-like architecture in 2008, so that will probably be the time where the two vendors have the most easily comparable technology.
I've seen arguments used where people say 'we don't need to worry about aspect X that TCP takes care of' and ultimately get bitten. IPMI to me is a good example. They have the notion of retries (more of an afterthought), and have sequence numbers above and beyond what UDP offers. The problem is that retries for most packets increment that sequence number, so a retry is indistinuishable from a reissuance of the same command. For some contents, this can be very undesirable.
When something with as much high-profile support as IPMI ends up with such shortcomings, it goes to show that people easily fail to understand why this aspect or that of TCP is not applicable to their use.
As to TCP over UDP, that's an example of a very bad sounding ideas. Redundant features of TCP and UDP. It's not as bad as TCP over IP over PPP over SSH which is over TCP (multiple reliable protocols on top of each other), but still, if you wanted to be a better TCP than TCP, the place to implement would be at the same layer, on top of IP protocol, not on top of UDP.
Are doomed to reinvent it, poorly, to paraphrase a well known saying. I have to roll my eyes everytime I see someone recommend the use of UDP in a circumstance where the application will not tolerate data loss. In gaming and media streaming, UDP can make sense, where the receiver can gloss over the details and do something reasonable, to an extent possible interpolating the missing data or simply showing a corrupted block or having someone skip a little in an online game. The only places where I see UDP implemented in a context where packet loss without retry is tolerated is in traditionally embedded applications (i.e. service processors with IPMI, and TFTP in ethernet boot roms). Both of these protocols can start behaving very badly if packets are lost or if over a high-latency link.
TCP is the most researched most tweaked and most examined reliable transport protocol, and trying to reinvent your own over an unreliable protocol is asking for trouble.
AMD is using SOI, which as I understand, produces some benefit over Intels process at a given process size. If the benefit offsets 65 v 45, or comes close, I don't know.
I do know that AMD sales have persisted in high-performance applications, simply because AMD's memory and IO architecture remain *much* metter than Intel's. Intel with Core 2 finally seriously had a competitor in terms of performance (i.e. very good floating point), but it will be interesting if Barcelona essentially matches the performance in terms of floating point and such, but maintains (or widens) the memory performance, it could be an interesting time for AMD once more.
My Verizon phone does aGPS for E911, and Verizon actually does let you access it... if you bend over for them just more, which I don't, though I did do the free trial and let it expire, so I know it can work.
But guesses about what he might have done to be in a position as described. Did not compare it to anything. I didn't take it out of the exact circumstance described.
"if the performance is by audio means only, the performance is communicated by means of a total of not more than 6 loudspeakers, of which not more than 4 loudspeakers are located in any 1 room or adjoining outdoor space"
So if you set up a sound system that can scale to a larger venue, you can be considered to be intentionally broadcasting it. Putting data in an explicitly shared would be considered analogous to that.
These 'gray lines' people like to jump on in terms of real-world analogies have been recognized and answered in law already. You can probably reasonably tell whether the person's share was intentional or incidental (most modern OSes and large-scale networks make it hard to accidentally share data such that people can get it without circumventing or bypassing a mechanism meant to prevent it). If his directory was by default world readable, there is a fair argument he was using it for his own purposes never realizing the world could get at it. If he put it in something like public_html, it's hard to argue that he didn't mean it. In which case, public_html would be like putting a few hundred speakers throughout a town and playing the music, and then claiming you didn't mean for anyone but you to hear it.
A better analogy would be to say he has some music files, and he puts it on a shared folder somewhere.... oh wait...
But seriously *WTF* is with all the analogies. The original concept is not that hard to completely understand. If he put it in his home directory, and the default permissions were open (i.e. umask being set stupidly), then I would say he has an argument. However, if he had to explicitly change permissions on it, or put it in something analagous to a 'public_html', intent to distribute can be argued. If you put a big sign on your drive saying 'I put music on here, feel free to copy it', it's obvious you are inviting the activity.
I think we can debate on whether or not that is debatable, I'm sure there are reasons it would be debatable and maybe reasons it wouldn't be debatable.
Slashdot Mirror
For current Intel core2, to get the Rpeak, take the number of cores total * clockspeed * 4. A single quad core 2.0 GHz gets you to 32 gflops already. You can readily build a rig with a single quad-core 2.0 ghz for less than 2,500. This is incredibly a non-event. It serves as a handy demonstration of how supercomputers are roughly architected today to people not in the industry, but the price/flop is noting special at all.
I still run Ubuntu (hasn't done anything to date to make me want to leave, and is doing a good job of bringing new technology to me in a stable form than others with their release cycle.
I will say, hawever, the 'easier to manage' part is largely people who were disenchanted with the RedHat situation a long time ago. Since finally adapting yum, the RedHat/CentOS world has something that is roughly equivalent to apt (IMO, the key thing that RH didn't officially have that made the difference). Yum has behaviors I don't like (i.e. yum search is much harder to parse through than aptitude search), but the fact remains, I admin a CentOS server and it's trivial to manage, not that different from Ubuntu anymore.
I tried Fedora back in the day, but they were, at the time, too aggressive and things broke frequently and behaved poorly (this was the Fedora Core 1/2 days), but I have no idea how they are now. I will say Ubuntu gets things done in a good balance, but I don't claim that the others haven't adopted strategies/policies that bring it up to par.
I couldn't begin to keep track of how many times I've heard that one in the industry. 'X is broken'. 'Well, our new architecture can't theoretically acheive X anymore, so it's a design limitation, not a bug'.
On the /etc/passwd thing, first off, I don't see what they could get from that in 99% of systems. As has been noted *many* times before, no password or hash of a password is stored there most times. You mention 'real' names, which *possibly* in there, but the *vast* majority of desktop linux installs I see don't have anything accurate for the users full name. Any attempt to correlate that data, for whatever bizarre reason, wouldn't get them very far. Almost certainly all the worrisome /etc calls are made by auxilarly libraries in the course of trying to fulfill run-of-the-mill calls. The browser profile walking seems bizarre and probably the place where skype should answer, and the potential place where things like AppArmor and SELniux really come into play, where a single user wannts to segregate application data all run by the same user. I can't see why anyone would worry about /proc/interrupts, and can easily see how opening that is relevant to an application using an audio device/has realtime characteristics. If some counter in interrupts is increasing, that info may be helpful to know if someone files a report and says the audio is skipping, an interrupt going nuts would explain that readily.
You are correct in that it isn't a pure GPS situation in most all phones, but it doesn't mean it isn't interacting with GPS satellite signals, see http://en.wikipedia.org/wiki/Assisted_GPS. GPS takes more time and is more picky about quality signal from satellites. aGPS still has some degree of satellite signal being received at the phone, but either sends that data to the tower which uses it's more optimal GPS situation to provide a lock, or receives the extra data from the tower. In other words, it isn't necessarily any less precise, just potentially dependent on communication with a tower and less time needed from the point of being turned on to being able to pinpoint the location.
As to other things, I can see how it comes about that ARC is being sued as they have started to go to J&J competitors to allow use of the red cross for products, and the previous understanding is therefore being violated. It seems like early on some sort of agreement was reached that both ARC and J&J could use the symbol, but for different applications. In this case, medical supplies and charity medical aid seem *really* close and hard to distinguish, so it gets a bit strange. It might be the case that if J&J started a for-profit blood-blank with big red crosses on their trucks, that ARC could sue them. Kinda like how Apple computers and music *were* trademarked in their separate industries, and neither was legally allowed to infringe on the other (of course, that all changed).r
Sony had a significant headstart in the market to Xbox and Gamecube. The only competition for them their first Christmas season was Dreamcast, and many people recognize Sega only ever had any measure of success with the Genesis. They had the momentum of PS1 success behind them (even if they couldn't have played PS1 games, which was a huge boon in and of itself, giving it technically the largest launch library to date, they had business relationships with the third party vendors to logically continue series on the PS2 platform). Microsoft was starting from scratch (loser relationships with PC game publishers count for something, but not with the control strategy and tight relationships of the console world), and Nintendo to an extent repeated one of the N64 blunders (small game media), and did nothing to tap into previous console libraries and, of course, had lost so many third parties to Sony. Add to the fact that Sony embraced DVD in terms of video playback out of the box, and you see the PS2 to be one of the most intelligently planned product launches of its time. It's no wonder that PS2 was far and away the 'winner', and from what I see, was a well-earned win. Totally the opposite of the rather bumbled PS3 launch situation, the wrong time to make mistakes when Nintendo has done something so smart.
If your active distribution *can* run 64-bit, all the drivers are 64-bit. The kernel must be 64-bit (and by extension all drivers, where we define drivers as loadable kernel modules). It's simply not that big a deal as the lion's share of the drivers of interest were open source and the change to a new architecture for many was little more than a recompile, however, there were many exceptions, and early adopters of x86_64 linux distros are probably painfully aware of them. Source code explicitly calling out uint32 data types as memory addresses, some funky things with PCI addressing and memory holes, etc etc. I think the open source world benefits somewhat from 'code nazis' with nothing better to do than nitpick such peculiarities as they find them, even before they would have functional impact, while commercial development has project managers with whips to meet schedules, leaving no time for being pedantic. Additionally, many of the most popular drivers frequently were somehow applicable to an existing 64-bit platform (i.e. sparc and ppc64), therefore the code had largely already evolved to be more platform agnostic, or at least trained a large number of OSS developers in how to do it so porting of those drivers was not bizarre. Applications are another matter, i.e. because of Sun's Java plugin and flash, my 64-bit systems still run 32-bit firefox, and provided all the libraries are there, the 64-bit kernel doesn't mind hosting 32-bit applications at all.
Now Windows 64-bit is a different set of circumstances. Most drivers have source guarded by the hardware vendor, and most of these hardware vendors ever really cared about support Windows and the only platform where Windows dominated was x86. Thus the situation is pretty grim for those companies, many of which still don't care about 64-bit, and the ones that care being ill-equipped for knowing the sorts of things that break in a platform change of this sort. The fact that the driver API is so close to what they've been using, it means the logical schedule move for them is to try to port their existing code. Of course, as Vista has shown, the commercial vendors have even more of a hard time getting it right porting from XP driver model to Vista (even without an arch change) than 32 bit to 64 bit within the same driver model.
Square is all about 2 things nowadays:
-Re-releasing their old, popular titles over and over and over again for big bucks with very little effort. (the reason they avoid Wii's virtual console like the plague is because people are *still* willing to pay ~50 bucks for the same game they already bought for ~50 bucks at least twice already, crazy fandom... The games were good, but not good enough to sign up for being repeatedly reamed).
-When they do release a 'new' game, it's been increasingly more style over substance. The shinier and more polygon count, the better. The more cinematic-like cutscenes, etc. PS3 has the Blue-Ray format, allowing for significant amounts of storage, and the graphics subsystem to do their 'ooh shiny' bits. Wii does not have the graphics/processor capability to do that to the same extent. Wii is a lot of things, but rendering real-time graphics it is significantly less adept at. DVD has a lot of storage, but give Square the license to use up to a BD-ROM's capacity, and they'll probably eat it up.
To me, Square jumped the shark a bit ago. From Square's perspective they probably think (and perhaps accurately so) that it doesn't matter *what* platform they release for. If only 2 million PS3s exist in households, and they release for PS3, they probably think people will buy the PS3 *just* to play their game if nothing else (evidently, this may be the case here as well). Square and Sony have a certain hubris in common about how infallible their new product will be in the marketplace. Sony crammed a number of agendas into the PS3 and priced it high, because they thought they just couldn't lose. Maybe Sony is starting to/would soon see the light, but Square hasn't had such a humbling experience yet.
Custer's Revenge.
Oh, and to further strengthen your argument, current storage technology has a theoretical throughput of 3.0 Gbps per disk. Assuming you could acheive 40 Gbps to a functional PC, you'd need a 14 drive non-redundant array to even theoretically have the numbers to download to disk, of course, that would require an equal number of pci-e lanes to get to a hypothetical controller that could handle the throughput. If trying to use a ram-backed storage strategy, you'd use up all memory of, say, 8GB in less than two seconds. Unless 4 GB of data can be discarded per second, that won't work either.
So, absolutely for any realistic home use, the throughput in the article is useless, since no media has currently ludicrous requirements where 4 GB of data per second can be consumed and discarded per second, and storage becomes the bottleneck for downloading. There exist applications that can benefit from transferring that much data over a network, crunching on it and being done with 4 GB datasets in a second, but they are few and far between and none really applicable for a home computer.
Don't think the DVD feature was *that* key in terms of movie at least.
PS1 came in with optical media with the incredible storage space relative to the Nintendo 64 offering, and the only other possible contender was Saturn of the era, which lacked the 3D capability to keep up with the other two consoles in a genre where 3D was what made them new and different from previous games. As a result, PS1 gained an incredible library of games.
The next round, Sega was first to market with Dreamcast, which had either CD or a goofy GD-ROM format which wasn't much better, so storage per game was not significantly better than PS1. The graphics were truly great, to its credit. The controllers were awkward and it had to stand completely on its own in terms of available game library. Sega marketing failed to overcome Sony teasing its customerbase over the PS2, and failed to attract many good games nor produce first-party titles that were compelling. Sega's only real success was the Genesis, and that's largely only because they had a two year head start in the market before SNES came along. When PS2 released to a market that still hadn't embraced Dreamcast, at a price-point not much higher than Dreamcasts, with a media that was significantly larger (attracting publishers looking to reduce disk-swaps), and the ability to play the PS1 games, they instantly had a formidable game library to draw own. Xbox and Gamecube came significantly later, neither with an existing library to tap into.
Now this round, everyone came out at the same time. Sony seems to be trying to use PS3 to push BlueRay (not the other way around). Seems like they perceived how well they did with PS1 and PS2 and assumed PS3 would be a success, so they better put something they really want to win on it, so they both would be winners. In doing so, more aggressively than with DVD, they pushed the price unreasonably high. That, and very few titles spanned more than one DVD, so the capacity leap for games didn't seem pressing. Both MS and Sony largely stuck with what had been working, same thing they did last time but with faster bits for prettier games. Nintendo, not having a big success since SNES days, stayed budget conscious and had an innovative controller strategy. They had the sense finally to support their previous systems games, but took it a step farther by setting up an infrastructure to easily acquire and run games all the way back to the NES, as well as some former competitors' systems. Nintendo executed the best to-date utilization of legacy titles as well as offering something truly new and different without compromising budget too much. It's a well-earned success. My concern here is that Nintendo gets to be the asshats they were back in the 80s with respect to third parties.
Considering the extent of half-assed guessing in terms of capability, I would take the numbers with a grain of salt (think either side can make numbers work as they wish). However, to play devil's advocate and assume that an AS/400 is approximately 60 x86 servers, let's take your points one by one:
1) Rackspace. Higher density (i.e. 84 per rack) configurations exist in the form of blade servers and some less sophisticated rackmount systems.
2) Power. Again Blades come in. At least the blades I work with will have two power supplies per half a chassis (for redundancy). Significantly reducing the inefficiencies.
3) Cooling. Similar deal, cooling is acheived more efficiently through use of fewer blowers. However, you'd have to compare the components in each in terms of TDP to get a feel for how much heat you have to move (not all racks are equally coolable, as you seem to suggest). Additionally, the common power supply further mitigates the problem you suggest.
4) Ok, add the cost of that much switching equipment. As long as we are at it, admit blades in the initial purchase price are more expensive and take it down a few servers I suppose.. The difficulty of managing that many IP addresses is trivial if you know what you are doing.
5) Storage You skipped minimal ramroot or cheap low-capacity flash storage. It's obvious the network will be utilized to some extent depending on your application, si it is really rough to determine what is or is not appropriate. There are sem situations in which a valid metric is aggregate disk write/read performance among nodes, in which case 60 distinct disks would be the only way to get some sustained throughput numbers (any individual hard drive is only so fast after all). So if you don't need 60 disks in the AS400, you can probably get away with a similar amount of disks somehow in the x86 server case.
6) Who cares about video console? Serial console (through serial console servers or SOL on modern BMCs) gives everything I ever need. Though, admittedly, 60 consoles could be more to manage, but the goal of managing systems at scale is to avoid touching any one of them except through some automated scripting or catastrophic hardware failure.
7) Sys admins. I'm regularly in charge of hundreds of systems at a given time, with a current maximum of 2,000 systems with me being solely responsible. If you can live on an AS/400 and are reproducing that sort of situation in x86 world, the environment can be so homogeneous amongst the servers as to make it scale up in number pretty well from the administrative standpoint.
8) Fault tolerance. Well that was in part the point of so many servers. If uber-paranoid, high-risk components (fans, drives, power-supplies) on moderate x86 architecture servers are generally hot-swappable, with the low-risk components (solid state stuff) generally able to detect failures and correct or bail out as appropriate for service). In the case of those huge failures or cheaping out on system-level redundancy, the higher layer of your app would provide redundancy between servers.
9) Service contract. That's a function of your vendor, nothing to do with the architecture. And most vendors afaik recognize that a support contract for a huge set of servers should scale up less steeply than linearly. (It's not 60 times harder than 1 server, it's somewhere less than that).
The picture obviously isn't simple, and even IBM is rather multiple-personality on the issue (they offer z,i,p,x lines of systems, obviously indicating a perceived benefit for each, or just confusion). Ultimately, if you are going to dump that much money into a large solution, in depth investigation of the options would be much better than anything we will post in slashdot comments.
In the broader sense of an 'architecture' in my mind, AMDs has a more advanced one than Intel (the integrated and hypertransport IO/multi-processor strategy).
Intel does, however, have a faster processor design than AMD's released product. If Barcelona levels the field in terms of instructions per clock, then the ball is back to Intel's court to at least meet AMDs memory/SMP/IO architecture or offset that deficiency with another leap in the processor technology. I hear Intel's roadmap eventually brings in a more AMD-like architecture in 2008, so that will probably be the time where the two vendors have the most easily comparable technology.
I've seen arguments used where people say 'we don't need to worry about aspect X that TCP takes care of' and ultimately get bitten. IPMI to me is a good example. They have the notion of retries (more of an afterthought), and have sequence numbers above and beyond what UDP offers. The problem is that retries for most packets increment that sequence number, so a retry is indistinuishable from a reissuance of the same command. For some contents, this can be very undesirable.
When something with as much high-profile support as IPMI ends up with such shortcomings, it goes to show that people easily fail to understand why this aspect or that of TCP is not applicable to their use.
As to TCP over UDP, that's an example of a very bad sounding ideas. Redundant features of TCP and UDP. It's not as bad as TCP over IP over PPP over SSH which is over TCP (multiple reliable protocols on top of each other), but still, if you wanted to be a better TCP than TCP, the place to implement would be at the same layer, on top of IP protocol, not on top of UDP.
Are doomed to reinvent it, poorly, to paraphrase a well known saying. I have to roll my eyes everytime I see someone recommend the use of UDP in a circumstance where the application will not tolerate data loss. In gaming and media streaming, UDP can make sense, where the receiver can gloss over the details and do something reasonable, to an extent possible interpolating the missing data or simply showing a corrupted block or having someone skip a little in an online game. The only places where I see UDP implemented in a context where packet loss without retry is tolerated is in traditionally embedded applications (i.e. service processors with IPMI, and TFTP in ethernet boot roms). Both of these protocols can start behaving very badly if packets are lost or if over a high-latency link.
TCP is the most researched most tweaked and most examined reliable transport protocol, and trying to reinvent your own over an unreliable protocol is asking for trouble.
AMD is using SOI, which as I understand, produces some benefit over Intels process at a given process size. If the benefit offsets 65 v 45, or comes close, I don't know.
I do know that AMD sales have persisted in high-performance applications, simply because AMD's memory and IO architecture remain *much* metter than Intel's. Intel with Core 2 finally seriously had a competitor in terms of performance (i.e. very good floating point), but it will be interesting if Barcelona essentially matches the performance in terms of floating point and such, but maintains (or widens) the memory performance, it could be an interesting time for AMD once more.
My Verizon phone does aGPS for E911, and Verizon actually does let you access it... if you bend over for them just more, which I don't, though I did do the free trial and let it expire, so I know it can work.
Oh well, guess it's hard to resist trying to extend an analogy when you disagree...
But guesses about what he might have done to be in a position as described. Did not compare it to anything. I didn't take it out of the exact circumstance described.
If your car is bigger than 2,000 square feet. If you are smaller than 2,000 square feet, that subrule doesn't apply. Isn't copyright law sensible?
http://www.copyright.gov/title17/92chap1.html
"if the performance is by audio means only, the performance is communicated by means of a total of not more than 6 loudspeakers, of which not more than 4 loudspeakers are located in any 1 room or adjoining outdoor space"
So if you set up a sound system that can scale to a larger venue, you can be considered to be intentionally broadcasting it. Putting data in an explicitly shared would be considered analogous to that.
These 'gray lines' people like to jump on in terms of real-world analogies have been recognized and answered in law already. You can probably reasonably tell whether the person's share was intentional or incidental (most modern OSes and large-scale networks make it hard to accidentally share data such that people can get it without circumventing or bypassing a mechanism meant to prevent it). If his directory was by default world readable, there is a fair argument he was using it for his own purposes never realizing the world could get at it. If he put it in something like public_html, it's hard to argue that he didn't mean it. In which case, public_html would be like putting a few hundred speakers throughout a town and playing the music, and then claiming you didn't mean for anyone but you to hear it.
A better analogy would be to say he has some music files, and he puts it on a shared folder somewhere.... oh wait...
But seriously *WTF* is with all the analogies. The original concept is not that hard to completely understand. If he put it in his home directory, and the default permissions were open (i.e. umask being set stupidly), then I would say he has an argument. However, if he had to explicitly change permissions on it, or put it in something analagous to a 'public_html', intent to distribute can be argued. If you put a big sign on your drive saying 'I put music on here, feel free to copy it', it's obvious you are inviting the activity.
I think we can debate on whether or not that is debatable, I'm sure there are reasons it would be debatable and maybe reasons it wouldn't be debatable.