Only problem is that article basically shows that the CPU isn't the bottle neck in what they were doing. It's like saying there isn't a performance improvement from an original K6 to an opteron and to prove it I'm going to time how long it takes to transfer a 100mb file over a modem with the different CPU's and prove to you how the performance difference is minimal.
On corruption, probably the reverse would be true, what is the cost of smart cards vs passive RFID? RFID is significantly less expensive than a smart card (pennies per passport).
And your point being??? That a very heavily used web/database/mail/etc server shouldn't be virtualized? That cities shouldn't have mass transit because riding a bus doesn't fit every single need. It's kind of a duh statement, but you've got to admit that there is significant excess capacity in datacenters, and that excess capacity while good for peak utilization only wastes money in paid for excess capacity or in resources required (power, cooling, etc). You've still got to be an admin, you still don't run physical hardware hosting virtual machines at 100%, you still make intelligent decisions about putting what onto where; but probably 75% of servers in most datacenters are reasonable candidates for virtualization because their task doesn't care about a difference between 1 millisecond and 1.25 millisecond response.
Exactly, every single server on the internet on average runs at 100% utilized not at the ~15% that industry groups say they do. The people who are able to average 4 virtual machines per cpu are truely lieing it's impossible to do that as we all know you can only get 1 virtual machine per cpu.
Actually it is a memory issue, with win32 you have to start doing tricks to address higher memory space (/3/4/pae each having their drawbacks and problems with citrix & terminal services). Citrix+32bit tends to top out and adding more cpu gives you hardly any benefits because you've run out of addressable kernel memory space. It's been used for this purpose for a number of years now.
It all depends, there are lots and lots of installations of Citrix inside VMware, it's a relatively common action. The main reason behind it is the memory address limitations of 32bit windows, you can create as many citrix instances as you want for no cost (each windows server is an additional cost, but in the grand scheme of citrix it's a minor cost). As for the 64bit windows + citrix I don't know how things play (I'm not really a windows guy but I know enough from being involved in their projects).
And if you decide to use vmware + citrix, you paid a bunch for citrix pay a little more and get ESX it's miles ahead of GSX which is still ahead of the Server Beta product.
If they've been running Win98 for this many years now, they will probably just continue running it until the hardware dies (and then buy the afforemention bundled hardware/MS os). If they've not had a reason the change yet, dropping support for Win98 is doubtful that it will have much of any affect in forcing them to change their OS. Coupled with the fact that Win98 users are probably not very technically competent that the only way Linux is proably going to get onto their system is via a friend or family member doing it for free. Without the technical skills they'd have to pay someone to install any OS onto their system, with hardware being cheaper they can either pay GeekSquad,etc $100 to install Linux that they have no understanding of onto their old hardware, or they can buy a new computer for $300-400 preinstalled.
1) If they are going to upgrade they are going to upgrade to a new system with Microsoft preinstalled (they've been using Microsoft products for possibly ~8years, that's what they know and that's what they'll use)
2) If they don't buy any new hardware using any of the new linux desktops that you suggest would be so sluggish that it would be basically unuseable and Win98 would look like a godsend in comparison
If they are non-redundant this is when the perverbial shit hits the fan, you'd be in a position like I've mentioned one would be with software mirroring with write cache, you'd have lost your transactions in flight and cannot even guarantee a fsck would recover the filesystem as you might have commited writes on some drives but not others.
Actualy it wouldn't be a problem, normally the batteries on the chip last significantly longer than any UPS (and then there are those that use NVRAM which never would be a problem). When the drives come back online the pending I/O's are destaged to disk. Let alone the real-life examples of full-on datacenters with UPS's going dark during the eastern US blackout.
Umm... no, just no. A journaled filesystem does not protect you from a write-cache situation where you've lost all uncommited I/O's. If an I/O is in cache and the box reboots, it will be guaranteed that you will not have the data on the disk. Furthmore, the problem is that some of the drives can have the change and others not, the drives have acked to the host of the i/o completion so it has gone on. Half of your raid5 drives have the committed data, the others don't is bad enough, but because it's been acked to the host you can have multiple commited i/o's to some disks while their parters still have them in cache.
To keep up the performance you use hardware raid that has battery-backed write cache to destage to disk, write caching gives significant performance increases (an order of magnitude 2x+) larger than algorithms. Linux may have the fastest algorithm in the world, but it can't get around the physical limitation of how fast the drive rotates, you use write caching to get that. I'll use exagerated numbers to more clearly explain this, the software raid5 algorithm in the world may run 50% faster than the hardware in the world, but using write caching is 500% faster than non. Hardware raid will than run 450% faster than software, while actualy having a slower algorithm.
The slowest part of any system is phsyical disks, mathematical algorithm comparison between hardware and software is negligible (and basically everybody does it the same) which is why with hardware raid you can do additional tricks to get around that limitation that software is unable to do without basically guaranteed corruption.
Performance gets increased significantly by decreasing the number of iop's to phsyical media or decreasing the ammount of time to ack to the host write complete. How do you do that? Well you allow the storage to delay a write, i.e. turn on write caching, ack a write complete without actually getting it to the media. If you do that with software you are going to get corruption, if you do it with any reasonable hardware you are not. Without write caching you are bound by the speed of the physical disks, which like I said is always the slowest part of a computer. That is why hardware raid is faster than software raid, you can't make a physical disk spin faster so how do you go faster you defer writes and front it with enough cache to support the write ingest rate (doesn't take much, even a small 16-32 MB will give noticeable difference).
Software is more reliable+performance, what are you smoking? To get the performance you've got to turn on write caching, system goes down with write caching you're very likely (almost guaranteed) to have a corrupt filesystem. To get the reliability you turn off write caching, and performance plumments. Any hardware raid worth more than 3 cents has battery backed cache that allows you to have write caching and maintain reliability, not even taking in account being able to do some Raid5 operations with only 1 disk iop.
Except for the guy using your bandwidth does and a month later police, etc after going through different ISP's tracks it back to your physical location. I prefer to avoid being in a situation where someone might come to me and say, "We have proof that this nasty stuff came from your physical location, and being it's a house not a business it's most likely you. We'd like to laugh at your stumbling explanation that it wasn't you it was a mysterious "OTHER GUY" using your equipment and why we shouldn't make you feel some uncomfortabl" police scrutiny at home/work/etc."
Actually it's fairly easy to write a *nix program in userspace that can bring a whole system down. You should see what our development staff have accidentaly been able to do as non-root users:)
So what you are saying is that if I have a Linux kernel module that I create, it adhere's to the API and it crashes the system it's Linux's fault? You obviously haven't done any programming and have no knowledge of what an API is.
I believe (I could be wrong) that the certification involves only certifies adherence to the published api, it doesn't certify quality of driver code. What a driver does or how it does it doesn't matter only how it gives the result of it's work back to the OS.
Actually I believe it's you submitting bug reports for hardware that microsoft doesn't controll, doesn't create drivers for and isn't distributed by them. What you paid microsoft for were the ones that come from microsoft, but you can't really claim that you are paying microsoft to be their beta tester when you download a new . So I'm not quite sure what your beef is... other than to possibly anti-m$ karma-whore a bit.
Actually what you don't seem to understand is support leggacy proucts and consolidation that's been one of the big selling point for VMware for longer than MS has had their product out. They even have been selling a product specifically for that process to make it dead simple (P2V) where you pop in a cd and it will take an old box and pull it into vmware. MS deffinetly doesn't win this market, they are later to this market than VMware is, their product is worse than VMware and VMware goes beyond just supporting legacy/consolidation to test, dev, DR, etc. and VMware still smokes MS virtual server on performance on *ALL* items (network, cpu, memory and disk).
Kernel rootkits have been around for many years, they aren't self replicating but all you've got to do is install a kernel module. That kernel module will then intercept syscalls to hide itself and any other rootkit programs (ps will now lie to you and not show you a hacked irc daemon is running, ls now won't show certain directories, lsmod won't even list the kernel module as running). Started to get notoriety ~5+ years ago, they tend to not be automated install (that could be debated, if you've got kernel source & compiler on the box it's pretty easy to "one-click" install it) but they are very effective on a compromised box.
I doubt you'd get any disagreement from VMware on your statement, but probably a lot in regards to ESX vs Xen. Xen is more like ESX as they both run on their own hypervisor kernel, vmware server has the same legacy difficulties as the host OS has control over the hardware and scheduling. You've got to go from your guest VM to the hypervisor to the host OS to the hardware, ESX removes the host OS as it's running bare metal. I think I've heard that vmware server has up to 85% of native speed while ESX has up to 98% native speed.
An interesting thing I've heard is that ESX 3 most likely has paravirtualization support built-in so that when the OS kernel change becomes standardized a simple patch to ESX will allow for support for it (they have philosophical differences against requiring users to change the OS)
I think the problem you are running into is reality, having worked in an ISP during the early days (95) customers had the same misconception of reality. A very small town can have (I'll use nice round numbers) 1,000 high-speed customers, (again a very *small* town). Let's say the town is serviced by comcast who has an advertised rate of 6mb download, now to support the stated 6mb connection you'd need somewhere between 2x OC48's and 1x OC192 (6 gigabit = 6mb * 1000 customers). There is no possible way that it feasible can be done, without having monthly individual costs into 4-5 digit numbers.
What this basically means is that EVERY ISP does oversubscription to home customers, there really is no other realistic way for it to happen. That's why you'll hardly ever see a guaranteed speed rate to home customers anymore, unlimited access has an asterisk by it now, and companies talk about *advertised* rates. You didn't pay for a certain quality at your end (unless you have a special contract, are a business paying for something specific), you paid for an advertised rate which may be faster or slower depending upon the day and I'm sure their legal team would be more than happy to point out the specific contract clause showing you where you are wrong on your assumption.
Slashdot Mirror
Only problem is that article basically shows that the CPU isn't the bottle neck in what they were doing. It's like saying there isn't a performance improvement from an original K6 to an opteron and to prove it I'm going to time how long it takes to transfer a 100mb file over a modem with the different CPU's and prove to you how the performance difference is minimal.
On corruption, probably the reverse would be true, what is the cost of smart cards vs passive RFID? RFID is significantly less expensive than a smart card (pennies per passport).
And your point being??? That a very heavily used web/database/mail/etc server shouldn't be virtualized? That cities shouldn't have mass transit because riding a bus doesn't fit every single need. It's kind of a duh statement, but you've got to admit that there is significant excess capacity in datacenters, and that excess capacity while good for peak utilization only wastes money in paid for excess capacity or in resources required (power, cooling, etc). You've still got to be an admin, you still don't run physical hardware hosting virtual machines at 100%, you still make intelligent decisions about putting what onto where; but probably 75% of servers in most datacenters are reasonable candidates for virtualization because their task doesn't care about a difference between 1 millisecond and 1.25 millisecond response.
Exactly, every single server on the internet on average runs at 100% utilized not at the ~15% that industry groups say they do. The people who are able to average 4 virtual machines per cpu are truely lieing it's impossible to do that as we all know you can only get 1 virtual machine per cpu.
Actually it is a memory issue, with win32 you have to start doing tricks to address higher memory space (/3 /4 /pae each having their drawbacks and problems with citrix & terminal services). Citrix+32bit tends to top out and adding more cpu gives you hardly any benefits because you've run out of addressable kernel memory space. It's been used for this purpose for a number of years now.
It all depends, there are lots and lots of installations of Citrix inside VMware, it's a relatively common action. The main reason behind it is the memory address limitations of 32bit windows, you can create as many citrix instances as you want for no cost (each windows server is an additional cost, but in the grand scheme of citrix it's a minor cost). As for the 64bit windows + citrix I don't know how things play (I'm not really a windows guy but I know enough from being involved in their projects).
And if you decide to use vmware + citrix, you paid a bunch for citrix pay a little more and get ESX it's miles ahead of GSX which is still ahead of the Server Beta product.
If they've been running Win98 for this many years now, they will probably just continue running it until the hardware dies (and then buy the afforemention bundled hardware/MS os). If they've not had a reason the change yet, dropping support for Win98 is doubtful that it will have much of any affect in forcing them to change their OS. Coupled with the fact that Win98 users are probably not very technically competent that the only way Linux is proably going to get onto their system is via a friend or family member doing it for free. Without the technical skills they'd have to pay someone to install any OS onto their system, with hardware being cheaper they can either pay GeekSquad,etc $100 to install Linux that they have no understanding of onto their old hardware, or they can buy a new computer for $300-400 preinstalled.
The problem with your argument is that:
1) If they are going to upgrade they are going to upgrade to a new system with Microsoft preinstalled (they've been using Microsoft products for possibly ~8years, that's what they know and that's what they'll use)
2) If they don't buy any new hardware using any of the new linux desktops that you suggest would be so sluggish that it would be basically unuseable and Win98 would look like a godsend in comparison
If they are non-redundant this is when the perverbial shit hits the fan, you'd be in a position like I've mentioned one would be with software mirroring with write cache, you'd have lost your transactions in flight and cannot even guarantee a fsck would recover the filesystem as you might have commited writes on some drives but not others.
Actualy it wouldn't be a problem, normally the batteries on the chip last significantly longer than any UPS (and then there are those that use NVRAM which never would be a problem). When the drives come back online the pending I/O's are destaged to disk. Let alone the real-life examples of full-on datacenters with UPS's going dark during the eastern US blackout.
Umm... no, just no. A journaled filesystem does not protect you from a write-cache situation where you've lost all uncommited I/O's. If an I/O is in cache and the box reboots, it will be guaranteed that you will not have the data on the disk. Furthmore, the problem is that some of the drives can have the change and others not, the drives have acked to the host of the i/o completion so it has gone on. Half of your raid5 drives have the committed data, the others don't is bad enough, but because it's been acked to the host you can have multiple commited i/o's to some disks while their parters still have them in cache.
t m
To keep up the performance you use hardware raid that has battery-backed write cache to destage to disk, write caching gives significant performance increases (an order of magnitude 2x+) larger than algorithms. Linux may have the fastest algorithm in the world, but it can't get around the physical limitation of how fast the drive rotates, you use write caching to get that. I'll use exagerated numbers to more clearly explain this, the software raid5 algorithm in the world may run 50% faster than the hardware in the world, but using write caching is 500% faster than non. Hardware raid will than run 450% faster than software, while actualy having a slower algorithm.
This page basically shows exactly this (corruption) in ext3 & reiserfs filesystems using software raid: http://sr5tech.com/write_back_cache_experiments.h
The slowest part of any system is phsyical disks, mathematical algorithm comparison between hardware and software is negligible (and basically everybody does it the same) which is why with hardware raid you can do additional tricks to get around that limitation that software is unable to do without basically guaranteed corruption.
Performance gets increased significantly by decreasing the number of iop's to phsyical media or decreasing the ammount of time to ack to the host write complete. How do you do that? Well you allow the storage to delay a write, i.e. turn on write caching, ack a write complete without actually getting it to the media. If you do that with software you are going to get corruption, if you do it with any reasonable hardware you are not. Without write caching you are bound by the speed of the physical disks, which like I said is always the slowest part of a computer. That is why hardware raid is faster than software raid, you can't make a physical disk spin faster so how do you go faster you defer writes and front it with enough cache to support the write ingest rate (doesn't take much, even a small 16-32 MB will give noticeable difference).
Software is more reliable+performance, what are you smoking? To get the performance you've got to turn on write caching, system goes down with write caching you're very likely (almost guaranteed) to have a corrupt filesystem. To get the reliability you turn off write caching, and performance plumments. Any hardware raid worth more than 3 cents has battery backed cache that allows you to have write caching and maintain reliability, not even taking in account being able to do some Raid5 operations with only 1 disk iop.
Except for the guy using your bandwidth does and a month later police, etc after going through different ISP's tracks it back to your physical location. I prefer to avoid being in a situation where someone might come to me and say, "We have proof that this nasty stuff came from your physical location, and being it's a house not a business it's most likely you. We'd like to laugh at your stumbling explanation that it wasn't you it was a mysterious "OTHER GUY" using your equipment and why we shouldn't make you feel some uncomfortabl" police scrutiny at home/work/etc."
ever try and work through the manual dependcies of building from tar files some larger linux projects?
Actually it's fairly easy to write a *nix program in userspace that can bring a whole system down. You should see what our development staff have accidentaly been able to do as non-root users :)
So what you are saying is that if I have a Linux kernel module that I create, it adhere's to the API and it crashes the system it's Linux's fault? You obviously haven't done any programming and have no knowledge of what an API is.
I believe (I could be wrong) that the certification involves only certifies adherence to the published api, it doesn't certify quality of driver code. What a driver does or how it does it doesn't matter only how it gives the result of it's work back to the OS.
Actually I believe it's you submitting bug reports for hardware that microsoft doesn't controll, doesn't create drivers for and isn't distributed by them. What you paid microsoft for were the ones that come from microsoft, but you can't really claim that you are paying microsoft to be their beta tester when you download a new . So I'm not quite sure what your beef is... other than to possibly anti-m$ karma-whore a bit.
Maybe his history of antics have worked against him and now is listed under the "cooks" category.
Actually what you don't seem to understand is support leggacy proucts and consolidation that's been one of the big selling point for VMware for longer than MS has had their product out. They even have been selling a product specifically for that process to make it dead simple (P2V) where you pop in a cd and it will take an old box and pull it into vmware. MS deffinetly doesn't win this market, they are later to this market than VMware is, their product is worse than VMware and VMware goes beyond just supporting legacy/consolidation to test, dev, DR, etc. and VMware still smokes MS virtual server on performance on *ALL* items (network, cpu, memory and disk).
But are you saying that Russia wouldn't give a shit about about US sites stealing from Russian artists/labels (amongst others)?
Kernel rootkits have been around for many years, they aren't self replicating but all you've got to do is install a kernel module. That kernel module will then intercept syscalls to hide itself and any other rootkit programs (ps will now lie to you and not show you a hacked irc daemon is running, ls now won't show certain directories, lsmod won't even list the kernel module as running). Started to get notoriety ~5+ years ago, they tend to not be automated install (that could be debated, if you've got kernel source & compiler on the box it's pretty easy to "one-click" install it) but they are very effective on a compromised box.
I doubt you'd get any disagreement from VMware on your statement, but probably a lot in regards to ESX vs Xen. Xen is more like ESX as they both run on their own hypervisor kernel, vmware server has the same legacy difficulties as the host OS has control over the hardware and scheduling. You've got to go from your guest VM to the hypervisor to the host OS to the hardware, ESX removes the host OS as it's running bare metal. I think I've heard that vmware server has up to 85% of native speed while ESX has up to 98% native speed.
An interesting thing I've heard is that ESX 3 most likely has paravirtualization support built-in so that when the OS kernel change becomes standardized a simple patch to ESX will allow for support for it (they have philosophical differences against requiring users to change the OS)
I think the problem you are running into is reality, having worked in an ISP during the early days (95) customers had the same misconception of reality. A very small town can have (I'll use nice round numbers) 1,000 high-speed customers, (again a very *small* town). Let's say the town is serviced by comcast who has an advertised rate of 6mb download, now to support the stated 6mb connection you'd need somewhere between 2x OC48's and 1x OC192 (6 gigabit = 6mb * 1000 customers). There is no possible way that it feasible can be done, without having monthly individual costs into 4-5 digit numbers.
What this basically means is that EVERY ISP does oversubscription to home customers, there really is no other realistic way for it to happen. That's why you'll hardly ever see a guaranteed speed rate to home customers anymore, unlimited access has an asterisk by it now, and companies talk about *advertised* rates. You didn't pay for a certain quality at your end (unless you have a special contract, are a business paying for something specific), you paid for an advertised rate which may be faster or slower depending upon the day and I'm sure their legal team would be more than happy to point out the specific contract clause showing you where you are wrong on your assumption.