This isn't really that much of a suprise. RedHat has some fairly deep ties into VMware. They are one of the only 'officially supported' Linux guest operating systems that VMware will run (of course it also runs everything else just fine). The VMware service console of ESX is based on RedHat, etc. They have a pretty good track record there, and I suppose that it is worth it from this standpoint to maintain the relationship. I also imagine that they get a kickback from VMware whenever ESX is sold since it basically includes RHEL3 -- either that or VMware is paying them a lot of money --
FWIW, I agree with them on Xen even though I hate RedHat. Xen is a great performer and a very capable platform, but management is difficult and it is still lacking a lot of important features that VMware implements. This is part of the reason for the performance hit of VMware ESX vs Xen. When Xen gets up to a very equivalent feature level I think that you'd see the performance gap is going to be a lot smaller. In a hosting application or something when your company can afford the overhead of maintaining Xen -- go for it. If you are actually worried about maintaing the VM's and can't take the extra headache of being a Xen admin as well, go for ESX.
You will never visit a site which requires a particular FireFox extension (running with the same privileges as the rest of your applications) in order to navigate.
This is an important point to consider. Just because it hasn't happened *yet* doesn't mean it couldn't. The security model of Firefox extensions is really not very good either.
Woah! Why exactly is front projection not an option? People often throw out front projection because they want to stand in front of the screen to present and rear projection is not a good option.
Don't give up on front projection until you at least learn a little bit about short throw options. There are front projection systems that can deliver 100" diagonal images in as little as 2' (NEC WT610). If you are projecting from the ceiling to a 60" screen, you could be standing riciculously close (e.g. closer than one usually stands next to a wall) and not even cast a shadow.
I did do some programming one time for Coca Cola's MDP (Multidrop protocol) used in their vending machines to interface the vending electronics with the money acceptors, etc. It had the largest bytes I have seen at 11 bits.
Well any type of 'authenticate then forward' type port control is vulnerable to this sort of thing, and so is simply defining the allowed mac address on a port. A shadow host attack as you have described is certainly possible against 802.1x but the usefulness of such a configuration would be somewhat limited without cooperation from the targeted computer or the ability to disable the target computer after access is granted. It's not as if the shadowed host has full network connectivity; in fact it has far from iif there is no cooperation from the computer targeted by the attack. In any case I believe 802.1x would be sufficient security for making sure that, say, a college dorm room doesnt turn into an ISP.
You can somewhat defend agains this type of attack without physical security as well. You can force the port to gigabit speed, greatly reducing the probability that someone has a hub-type device to perform the attack (you could still use a l2 bridge attack) or you can disable the port entirely if the physical link goes down.
If you require more security than this you should probably be running PPPoE or IPsec on the wire instead. There are a number of ethernet cards capable of IPSec offload and wireline speeds...
I came into this discussion fully expecting to see a nice breakdown of the various merits of 802.1x yet I only see your ONE SINGLE POST that even acknowledges that 802.1x even exists?!?! Not only is it widely supported, it's pretty much the only standard for port based security before you start getting into high level protocol stuff like PPoE or other tunneling protocols. Tying MAC addresses to ports is as ridiculous as it is insecure.
I thought that there were at least some people on slashdot that were actually IT pros...
Well I guess I'll know more tomorrow when I have a conference call set up with their engineers about what we would need in order to deploy that product here. I am pretty positive it doesnt use ICA or even ship with any special management tools. From what I know so far this VDI thing is not so much of a product but more of a concept that "Hey! Don't forget that XP has an RDP server in it!" Multi-monitor support is our biggest hang up; other than that it's just a very easy way to manage a bunch of desktops without the hassle of Citrix.
As for the multiple monitor support, at least it is possible to use rdesktop or MS RDP 6 client to export the desktop as one huge screen that spans monitors. (The RDP5 client lacks a large enough video buffer) Then you can run software helpers to manage windows so that things like maximize and window placement behave correctly. Apparently in Vista this will be less of an issue as RDP 6 addresses many of the concerns with multiple monitors.
Well I suppose you probably know this but for the others out there who may miss the subtlety ---
Ubuntu draws sources heavily from the unstable and/or testing branches of Debian in order to devote more time and energy to testing and the important fixed-length release cycle. They also are partially reliant on the Debian project for security updates. There would be little to no forward movement of Ubuntu currently without the Debian project. Indeed this may change as time goes on, but to me there are a lot of benefits to this model and I hope they stick with it. Previously most every debian-derived distribution has perished by trying to shed their ties and reliance on the core Debian project.
There is a pretty good size market for an ICA layer for regular desktop versions of Windows. If I could install XP desktops into VM's on a central server running VMware ESX and export them to users (on terminals or repurposed pc's) via ICA you could sell it to me in less than ONE SECOND -- particularly if you want to go ahead and support multiple monitors...
Wow I can't even get it to hang up for 1/2 second:) Probably whatever switches were between you and the ESX servers took longer to update their forwarding tables than mine did...
Since nobody seems to have answered the original question of "Why aren't we trying this with humans?" -- The answer is that "We are. And it doesn't work that well."
If you search for "NASA Hypergravity" on Google, you will find all kinds of data about the experiments, all kinds of crackpots talking about becoming super-strong or the like and this interesting Wired article written by one of the participants. If you don't want to dig too deep, check out the article. It's a pretty good summary from the inside out.
Well the reality is with MS at least they are opening up to some extent to virtualization. Their license revision to Windows Server 2003 Enterprise grants you explicit permission to run up to 5 (I think) copies of the software on the same machine -- and I believe this is independent of the virtualization layer. I don't use windows for much, but this is a step in the right direction. I don't see many other commercial OS vendors stepping up to do the same.
Let me guess; you are one of those people who have everything from DNS and DHCP to a database, web, mail, and file server all running on one big SMP box with RAID and all kinds of other redundant goodness, right? I've been there.
1) What do you do when you have to take it down or have a hardware problem? All that stuff stops all at once. With VM's (depending on your solution) you can move services to other machines either live (while they are still running) or at least schedule the move during normal downtime. In the event of complete failure, you don't have to reconfigure much of anything to recover on alternate hardware or in an alternate location.
2) What do you do when you need to upgrade the software running one of the other services? What if you have to upgrade the OS? It's far easier to maintain a couple of machines and handle your dependency problems per application than to try to sort out the web of mess that running everyting in one box gives you. Maybe you like doing that though; go for it.
3) You can prioritize your services more easily. Have a development webserver and production webserver on the same hardware? Sure you can configure it properly and securely, etc. But what happens when you screw up some code and the dev side eats the production side? Whoops.
4) You expose yourself to security problems far more when everything is on the same machine. If there is an exploit for, say, some app you are running on apache, you really don't want every service you run to be compromised all at once.
These aren't all problems that Virtualization necessarily solves though. You can get the same results by using multiple machines, something like jails in BSD, or simply keeping ahead of the game on security and updates and going ahead with everything in one box. VM's just make everything a whole lot easier...
By the time you spec individual machines with all the same redunancies you get when you just plug a blade into a chassis, it about balances out if you are doing more than 5-6 machines or so, at least from what I saw when I spec'd our new equipment.
You also have to recognize how easy they are to install and manage. All your network and storage switches are just modules in the chassis; no cable! Particularly with Fibre Channel this is a godsend and a huge time, money, and space saver -- whether or not you have the room for regular rackmount systems or not.
Are we having an argument about what the best feature of ESX is?
In my book it's one of two things:
1) Virtual networks (including the much improved vlan support in 3.0)
2) Memory page sharing. People argue that solutions like VMWare have X% performance penalty over something like Xen yet when you are building up a cluster for any type of redundancy -- are you going to double the amount of RAM in your hosts just so you can take on extra VM's in a failure?
How would you suggest that UML is a better idea than Xen? In an acedemic sense, maybe it's more interesting, but Xen provides strict resource allocation and control for the supervised OS's meaning that you get much better control over resources in each session. After all, one of the good reasons to segment applications or customers into their own virtual environment anyway is to prevent problems with that customer or application from affecting others. This type of protection is nearly impossible in UML.
A logical exension of UML; however, might be to incorporate something like Xen itself into the Linux kernel such that you could run a UML-like environment with Xen-like allocations. That would be a novel solution maybe, but still probably inappropriate for hosting companies...
I am not an expert with Server (GSX) -- I mainly stick to ESX. I do; however run some VMware Server machines in the lab and know what you are talking about -- this symptom sounds like a memory management issue. I'd bet dollars to donuts that your guest is getting partially swapped out either because you have given the guest more memory than it really needs (this is a very common problem), you have not configured the host to prevent swapping ("Fit all virtual machine memory into reserved host RAM" under "Host Settings" in the server console), you do not have enough ram in the machine to allocate enough to the guest (and the guest is swapping itself out), or you are running services on the host machine that are dragging down the guests. You have to remember that even though VMWare Server lets you oversubscribe your system RAM, it is up to you NOT to do it. Unlike ESX, VMware Server does not have the ability to share identical memory pages among VM's, thus oversubscribing memory in Server although possible is never a good idea. In ESX, however, memory subscritption is probably the biggest advantage VMware has over any other solution at this point.
If you are using VMWare Server, please keep in mind that best practices say that you should generally NOT RUN SERVICES ON THE HOST ! It is far better to minimize the footprint of the host and create another VM to handle the services instead. There are of course exceptions to this such as when an application needs physical access to hardware that VMware can not supply or emulate, but they are not common.
If this doesn't help you, please check the VMTN forums for help; they have a points system for questions/answers and are generally one of the better free support forums for any commercial product I have ever seen.
I've never heard it called FAKERAID maybe it should just be called FAID? I'll file that one back for use later...
Anyway, it's not entirely a hw/sw combo. These types of raid controllers are entirely software based. They consist basically of an ata or sata controller and an interrupt handler. When the disk is being accessed in legacy bios mode (ie during an os install, etc) the cpu pulls the interrupt to write to the disk and the BIOS calls the software stored on the card. This software is executed by the BIOS on the CPU and this code basically does whatever reading or writing to disk is necessary to keep the array consistent. Performance is improved after an OS's native driver is loaded since the software raid is done entirely in the driver.
It is arguable that software raid done at the OS level actually can have a performance advantage since it can know about file tasks at a much higher level than the driver itself, which basically only knows about block accesses. In the example presented in the article it seems that most of the tricks that software raid has been using do not perform well on the Core2 chips; I don't really see what the big deal is though; nobody has had a chance to write optimized routines for Core2. Probably their legacy BIOS handling ability is poor; so be it. There are a lot of alternatives out there from completely managing the array inside of software to full on ASIC-based hardware RAID.
It might be true if you are doing a sector by sector read, and then only if you have platters with high areal density (ie extremely recent drives). Windows file copy; however, does not optimize its disk access in any way and so you have lots of delays while moving from file to file. So, yeah, Firewire (400) might be a bottleneck if you are doing drive imaging or copying lots of very large files, but sustaining ~50MB/s during random access is still a pipe-dream on normal consumer drives at this point in time.
1) Your drive doesn't keep up with Firewire. Sorry, but it's true. Disks aren't as fast as you think -- particularly that cheap ATA thing you are using.
2) Windows file copy sucks ass. We are talking order of magnitude ass sucking. A local disk-to-disk rsync will convince you of this if you really don't want to believe me.
3) (As others have pointed out) Firewire is not so great on windows. Depending on how often you run Microsoft Update, you may be shooting yourself in the foot. Get the latest updates from MS on this one and be amazed that your connections suddenly actually operate at 400Mbps instead of 100Mbps!
I find it very hard to stomach these reviewers who are trying to compare the 'picture quality' of Blu-Ray to HD-DVD when the codecs used are exactly the same. Blu-Ray offers the edge on size and maximum bitrate, but it's doubtful that the early titles are going to be taking advantage of it. Any title that did take advantage of the extra space would very logically look better (if the compressionist is not an idiot, anyway). Whether or not anyone would really notice is another debate. You could make a comparison to the acutal players ability to decode and post process the footage as well, but this would require identical MPEG2 or H.264 content to be fed through both format players -- which has not been done either.
So anyway, I guess the gauntlet is down and the proverbial "masses" will decide. Unfortunately they will probably end up doing it based on title availability, brand loyalty, price, and "picture quality" instead of technical merit. All it really means to me is that I have to wait to buy a player until: a) one camp gives in, b) someone makes a dual format player or c) companies start releasing *everything* in both formats.
The same headers are sent as though you're doing an regular GET by typing a URL in the browser...
That all depends on how the application is written, doesn't it? I can hook into Apache and make it violate any part of HTTP that I want to with little effort. As hard as it might be to believe that programmers sometimes take shortcuts, when coding these thin AJAX responders, some authors do actually neglect to send proper headers or any headers at all! Shockingly, some even neglect to send XML entirely!
The XMLHttprequest is operating in a sandbox much like java applets.
By "is operating" I assume you really mean "supposed to be operating". In any case it is the browser's fault if there is a security problem, so it's not like a developer should run away just because of the possibility of an exploit; if people thought like that, who would even use computers?
I agree with that line 100%, but the use of AJAX as an enhancement to the shopping cart does not inherently bring up security issues.
I didn't say it does; but it imposes requirements of the browser that some administrators and some security software have chosen to lock down because of the mere possibilities of security problems; therefore an application's behavior should degrade gracefully when these features are not present. Bad practices with AJAX techniques really ought to create nothing more than a support problem and proper use should not create any problems at all.
Slashdot Mirror
This isn't really that much of a suprise. RedHat has some fairly deep ties into VMware. They are one of the only 'officially supported' Linux guest operating systems that VMware will run (of course it also runs everything else just fine). The VMware service console of ESX is based on RedHat, etc. They have a pretty good track record there, and I suppose that it is worth it from this standpoint to maintain the relationship. I also imagine that they get a kickback from VMware whenever ESX is sold since it basically includes RHEL3 -- either that or VMware is paying them a lot of money --
FWIW, I agree with them on Xen even though I hate RedHat. Xen is a great performer and a very capable platform, but management is difficult and it is still lacking a lot of important features that VMware implements. This is part of the reason for the performance hit of VMware ESX vs Xen. When Xen gets up to a very equivalent feature level I think that you'd see the performance gap is going to be a lot smaller. In a hosting application or something when your company can afford the overhead of maintaining Xen -- go for it. If you are actually worried about maintaing the VM's and can't take the extra headache of being a Xen admin as well, go for ESX.
This is an important point to consider. Just because it hasn't happened *yet* doesn't mean it couldn't. The security model of Firefox extensions is really not very good either.
Yeah I just calculated it; 60" diagonal from a NEC WT610 is a throw distance of 10.8" Resolution is XGA
With a moderately high gain screen this will give you plenty of brightness even with the lights on in a conference room.
Woah! Why exactly is front projection not an option? People often throw out front projection because they want to stand in front of the screen to present and rear projection is not a good option.
Don't give up on front projection until you at least learn a little bit about short throw options. There are front projection systems that can deliver 100" diagonal images in as little as 2' (NEC WT610). If you are projecting from the ceiling to a 60" screen, you could be standing riciculously close (e.g. closer than one usually stands next to a wall) and not even cast a shadow.
I did do some programming one time for Coca Cola's MDP (Multidrop protocol) used in their vending machines to interface the vending electronics with the money acceptors, etc. It had the largest bytes I have seen at 11 bits.
Thanks for the refresher there HP.
Well any type of 'authenticate then forward' type port control is vulnerable to this sort of thing, and so is simply defining the allowed mac address on a port. A shadow host attack as you have described is certainly possible against 802.1x but the usefulness of such a configuration would be somewhat limited without cooperation from the targeted computer or the ability to disable the target computer after access is granted. It's not as if the shadowed host has full network connectivity; in fact it has far from iif there is no cooperation from the computer targeted by the attack. In any case I believe 802.1x would be sufficient security for making sure that, say, a college dorm room doesnt turn into an ISP.
You can somewhat defend agains this type of attack without physical security as well. You can force the port to gigabit speed, greatly reducing the probability that someone has a hub-type device to perform the attack (you could still use a l2 bridge attack) or you can disable the port entirely if the physical link goes down.
If you require more security than this you should probably be running PPPoE or IPsec on the wire instead. There are a number of ethernet cards capable of IPSec offload and wireline speeds...
I came into this discussion fully expecting to see a nice breakdown of the various merits of 802.1x yet I only see your ONE SINGLE POST that even acknowledges that 802.1x even exists?!?! Not only is it widely supported, it's pretty much the only standard for port based security before you start getting into high level protocol stuff like PPoE or other tunneling protocols. Tying MAC addresses to ports is as ridiculous as it is insecure.
I thought that there were at least some people on slashdot that were actually IT pros...
I dunno; sounds like a typical ISP setup for cable or DSL customers to me --
Well I guess I'll know more tomorrow when I have a conference call set up with their engineers about what we would need in order to deploy that product here. I am pretty positive it doesnt use ICA or even ship with any special management tools. From what I know so far this VDI thing is not so much of a product but more of a concept that "Hey! Don't forget that XP has an RDP server in it!" Multi-monitor support is our biggest hang up; other than that it's just a very easy way to manage a bunch of desktops without the hassle of Citrix.
As for the multiple monitor support, at least it is possible to use rdesktop or MS RDP 6 client to export the desktop as one huge screen that spans monitors. (The RDP5 client lacks a large enough video buffer) Then you can run software helpers to manage windows so that things like maximize and window placement behave correctly. Apparently in Vista this will be less of an issue as RDP 6 addresses many of the concerns with multiple monitors.
Well I suppose you probably know this but for the others out there who may miss the subtlety ---
Ubuntu draws sources heavily from the unstable and/or testing branches of Debian in order to devote more time and energy to testing and the important fixed-length release cycle. They also are partially reliant on the Debian project for security updates. There would be little to no forward movement of Ubuntu currently without the Debian project. Indeed this may change as time goes on, but to me there are a lot of benefits to this model and I hope they stick with it. Previously most every debian-derived distribution has perished by trying to shed their ties and reliance on the core Debian project.
There is a pretty good size market for an ICA layer for regular desktop versions of Windows. If I could install XP desktops into VM's on a central server running VMware ESX and export them to users (on terminals or repurposed pc's) via ICA you could sell it to me in less than ONE SECOND -- particularly if you want to go ahead and support multiple monitors...
Wow I can't even get it to hang up for 1/2 second :) Probably whatever switches were between you and the ESX servers took longer to update their forwarding tables than mine did...
Since nobody seems to have answered the original question of "Why aren't we trying this with humans?" -- The answer is that "We are. And it doesn't work that well."
If you search for "NASA Hypergravity" on Google, you will find all kinds of data about the experiments, all kinds of crackpots talking about becoming super-strong or the like and this interesting Wired article written by one of the participants. If you don't want to dig too deep, check out the article. It's a pretty good summary from the inside out.
Well the reality is with MS at least they are opening up to some extent to virtualization. Their license revision to Windows Server 2003 Enterprise grants you explicit permission to run up to 5 (I think) copies of the software on the same machine -- and I believe this is independent of the virtualization layer. I don't use windows for much, but this is a step in the right direction. I don't see many other commercial OS vendors stepping up to do the same.
Let me guess; you are one of those people who have everything from DNS and DHCP to a database, web, mail, and file server all running on one big SMP box with RAID and all kinds of other redundant goodness, right? I've been there.
1) What do you do when you have to take it down or have a hardware problem? All that stuff stops all at once. With VM's (depending on your solution) you can move services to other machines either live (while they are still running) or at least schedule the move during normal downtime. In the event of complete failure, you don't have to reconfigure much of anything to recover on alternate hardware or in an alternate location.
2) What do you do when you need to upgrade the software running one of the other services? What if you have to upgrade the OS? It's far easier to maintain a couple of machines and handle your dependency problems per application than to try to sort out the web of mess that running everyting in one box gives you. Maybe you like doing that though; go for it.
3) You can prioritize your services more easily. Have a development webserver and production webserver on the same hardware? Sure you can configure it properly and securely, etc. But what happens when you screw up some code and the dev side eats the production side? Whoops.
4) You expose yourself to security problems far more when everything is on the same machine. If there is an exploit for, say, some app you are running on apache, you really don't want every service you run to be compromised all at once.
These aren't all problems that Virtualization necessarily solves though. You can get the same results by using multiple machines, something like jails in BSD, or simply keeping ahead of the game on security and updates and going ahead with everything in one box. VM's just make everything a whole lot easier...
It's not as bad as you think with the blades.
By the time you spec individual machines with all the same redunancies you get when you just plug a blade into a chassis, it about balances out if you are doing more than 5-6 machines or so, at least from what I saw when I spec'd our new equipment.
You also have to recognize how easy they are to install and manage. All your network and storage switches are just modules in the chassis; no cable! Particularly with Fibre Channel this is a godsend and a huge time, money, and space saver -- whether or not you have the room for regular rackmount systems or not.
Are we having an argument about what the best feature of ESX is?
In my book it's one of two things:
1) Virtual networks (including the much improved vlan support in 3.0)
2) Memory page sharing. People argue that solutions like VMWare have X% performance penalty over something like Xen yet when you are building up a cluster for any type of redundancy -- are you going to double the amount of RAM in your hosts just so you can take on extra VM's in a failure?
How would you suggest that UML is a better idea than Xen? In an acedemic sense, maybe it's more interesting, but Xen provides strict resource allocation and control for the supervised OS's meaning that you get much better control over resources in each session. After all, one of the good reasons to segment applications or customers into their own virtual environment anyway is to prevent problems with that customer or application from affecting others. This type of protection is nearly impossible in UML.
A logical exension of UML; however, might be to incorporate something like Xen itself into the Linux kernel such that you could run a UML-like environment with Xen-like allocations. That would be a novel solution maybe, but still probably inappropriate for hosting companies...
I am not an expert with Server (GSX) -- I mainly stick to ESX. I do; however run some VMware Server machines in the lab and know what you are talking about -- this symptom sounds like a memory management issue. I'd bet dollars to donuts that your guest is getting partially swapped out either because you have given the guest more memory than it really needs (this is a very common problem), you have not configured the host to prevent swapping ("Fit all virtual machine memory into reserved host RAM" under "Host Settings" in the server console), you do not have enough ram in the machine to allocate enough to the guest (and the guest is swapping itself out), or you are running services on the host machine that are dragging down the guests. You have to remember that even though VMWare Server lets you oversubscribe your system RAM, it is up to you NOT to do it. Unlike ESX, VMware Server does not have the ability to share identical memory pages among VM's, thus oversubscribing memory in Server although possible is never a good idea. In ESX, however, memory subscritption is probably the biggest advantage VMware has over any other solution at this point.
If you are using VMWare Server, please keep in mind that best practices say that you should generally NOT RUN SERVICES ON THE HOST ! It is far better to minimize the footprint of the host and create another VM to handle the services instead. There are of course exceptions to this such as when an application needs physical access to hardware that VMware can not supply or emulate, but they are not common.
If this doesn't help you, please check the VMTN forums for help; they have a points system for questions/answers and are generally one of the better free support forums for any commercial product I have ever seen.
I've never heard it called FAKERAID maybe it should just be called FAID? I'll file that one back for use later...
Anyway, it's not entirely a hw/sw combo. These types of raid controllers are entirely software based. They consist basically of an ata or sata controller and an interrupt handler. When the disk is being accessed in legacy bios mode (ie during an os install, etc) the cpu pulls the interrupt to write to the disk and the BIOS calls the software stored on the card. This software is executed by the BIOS on the CPU and this code basically does whatever reading or writing to disk is necessary to keep the array consistent. Performance is improved after an OS's native driver is loaded since the software raid is done entirely in the driver.
It is arguable that software raid done at the OS level actually can have a performance advantage since it can know about file tasks at a much higher level than the driver itself, which basically only knows about block accesses. In the example presented in the article it seems that most of the tricks that software raid has been using do not perform well on the Core2 chips; I don't really see what the big deal is though; nobody has had a chance to write optimized routines for Core2. Probably their legacy BIOS handling ability is poor; so be it. There are a lot of alternatives out there from completely managing the array inside of software to full on ASIC-based hardware RAID.
It might be true if you are doing a sector by sector read, and then only if you have platters with high areal density (ie extremely recent drives). Windows file copy; however, does not optimize its disk access in any way and so you have lots of delays while moving from file to file. So, yeah, Firewire (400) might be a bottleneck if you are doing drive imaging or copying lots of very large files, but sustaining ~50MB/s during random access is still a pipe-dream on normal consumer drives at this point in time.
1) Your drive doesn't keep up with Firewire. Sorry, but it's true. Disks aren't as fast as you think -- particularly that cheap ATA thing you are using.
2) Windows file copy sucks ass. We are talking order of magnitude ass sucking. A local disk-to-disk rsync will convince you of this if you really don't want to believe me.
3) (As others have pointed out) Firewire is not so great on windows. Depending on how often you run Microsoft Update, you may be shooting yourself in the foot. Get the latest updates from MS on this one and be amazed that your connections suddenly actually operate at 400Mbps instead of 100Mbps!
I find it very hard to stomach these reviewers who are trying to compare the 'picture quality' of Blu-Ray to HD-DVD when the codecs used are exactly the same. Blu-Ray offers the edge on size and maximum bitrate, but it's doubtful that the early titles are going to be taking advantage of it. Any title that did take advantage of the extra space would very logically look better (if the compressionist is not an idiot, anyway). Whether or not anyone would really notice is another debate. You could make a comparison to the acutal players ability to decode and post process the footage as well, but this would require identical MPEG2 or H.264 content to be fed through both format players -- which has not been done either.
So anyway, I guess the gauntlet is down and the proverbial "masses" will decide. Unfortunately they will probably end up doing it based on title availability, brand loyalty, price, and "picture quality" instead of technical merit. All it really means to me is that I have to wait to buy a player until: a) one camp gives in, b) someone makes a dual format player or c) companies start releasing *everything* in both formats.
The same headers are sent as though you're doing an regular GET by typing a URL in the browser...
That all depends on how the application is written, doesn't it? I can hook into Apache and make it violate any part of HTTP that I want to with little effort. As hard as it might be to believe that programmers sometimes take shortcuts, when coding these thin AJAX responders, some authors do actually neglect to send proper headers or any headers at all! Shockingly, some even neglect to send XML entirely!
The XMLHttprequest is operating in a sandbox much like java applets.
By "is operating" I assume you really mean "supposed to be operating". In any case it is the browser's fault if there is a security problem, so it's not like a developer should run away just because of the possibility of an exploit; if people thought like that, who would even use computers?
I agree with that line 100%, but the use of AJAX as an enhancement to the shopping cart does not inherently bring up security issues.
I didn't say it does; but it imposes requirements of the browser that some administrators and some security software have chosen to lock down because of the mere possibilities of security problems; therefore an application's behavior should degrade gracefully when these features are not present. Bad practices with AJAX techniques really ought to create nothing more than a support problem and proper use should not create any problems at all.