There are a number of pale imitations of dtrace available for Linux but none of them gets close to DTrace functionality, safety or performance. Part of the problem is that Dtrace uses a fully instrumented kernel which is one and the same as the production Solaris kernel. Almost all the other DTrace imitators on Linux rely on special Linux kernels and none of them have the safety of DTrace which you can turn on on a production kernel without worrying about performance or kernel panics.
One reason why Linux cannot deliver the same functionality as DTrace/Solaris is the resistance put up by Trovalds to instumenting the Linux kernel, his view is that dbugging is for wimps, code should be perfect and therefore DTrace type funtionality isn't necessary.
ZFS isn't available either though it would be simpler to impliment on Linux than DTrace.
Zones and Container type functionality does exist for Linux/BSD Zones are like BSD Jails.
Sun are unlikely to drop Solaris, it is and for the most part always has been their crown jewels.
It would be difficult to find a OS that on a capability by capability approaches Solaris as a server platform. dtrace, SMF, zones, fireengine, great scalability, good enough HCL.
However I can understand a Linux advocate wanting Sun to drop Solaris, it is the closest and best competitor to Linux.
A large number of big commercial companies that were early adopters of Linux are now looking long and hard at Solaris x86. Its fast, cheaper than Linux, OpenSource if they want to tick that box and it runs on pretty much all the hardware that they deployed Linux on.
Add NetBeans, the slab memory allocator and a whole of boring but rather critical Linux plumbing.
Ever wondered why Linux is rather Solaris like ????
Highly amusing. Last time anyone counted Sun had contributed more code to the RedHat distribution than any other entity except FSF.
I rather like the idea of people who don't think that Sun's OpenSource contributions matter being made to remove all Sun's donated code from their Linux distribitions because Linux would cease to exist at least for them.
T1 isn't OOO. It 8 cores essentially cut and pasted across a die. You could build a much smaller processor based on the T1 design using say 2 cores. However as far as I know you could not use something like Microblaze softcore because it is 32bit only.
Apart from OpenOffice, NetBeans, NFS, OpenSolaris big chunks of most Linux distributions (last time anyone counted RedHat contained more source attributed to by Sun than any other entity except FSF), cubic spline, etc etc etc etc.
However since Sun ownes the rights to the core Solaris source code and to the methods and concepts they are perfectly within their rights to release under CDDL.
Umm actually your argument is rather dubious at best. If Sun paid SCO to allow them to release chunks of SCO IP under OpenSource (I think it was x86 device driver code) then you could argue that Sun would obviously think that IBM did something wrong. Sun paid to release and SCO asserts that IBM did not.
Perhaps IBM have included Sun in the case because they want an example of how it should be done in case they lose.
There is nothing in the design of Opteron which makes it impossible to build greater than 8 way SMP boxes as Sun are soon going to demonstrate. In fact you could argue that saddling Itanium with Frontside Bus was rather more of a hinderence than the Opteron Hypertransport architecture. SGI themselves have complained about the difficulties of building a very large MP system using FrontSide as the basic building block.
SGI were one of the first vendors to produce Itanium based systems, switching from MIPS earlier would only have meant that they had no CPU to put in their Itanium servers.
Then there was the problem that the first iteration of Itanium was horribly uncompetitive for both Integer and FP with Itanium only establishing its niche FP status at the second attempt.
The writing on the wall for MIPS probably goes back to Digital dropping it in favour of Alpha, while SGI's bargain basement sale of Cray Business Systems Division (Aka Sun E10K) and the earlier aquisition of Cray set the seeds to SGI's long downward spiral. At the same time propelling Sun from a Workstation vendor who happend to do servers to the position of being the largest UNIX server vendor with huge dominance of the high end UNIX market. The E10K arrived at a time when the largest Digital box topped out at 6-10 CPU's depending on if you wanted memory and I/O, HP topped out at 12 and IBM 8.
Apple switching to Intel probably wasn't the brightest move, they should have switched to AMD who have a clear lead over Intel in both power and performance.
IBM's announcements are interesting but in my option IBM have made a big mistake. Clocking CPU's faster may seem attractive but the reality is that all this does is build a bigger and bigger memory pressure problem which results in poor performance except for the minority of workloads which are cache friendly. This is because RAM performance is not increasing at anything like the same rate as CPU clock.
So all IBM is doing is building a processor where missing the L1/L2/L3 cache has a greater relative penalty in terms of stalls than the current Power 5+. Because of this real world performance will not be anything like the 2-3x clock hike between Power 5+ and the new CPU's.
And the 2-3x real world throughput per CPU package is not going to allow IBM to remain remotely competitive. The Sun T1 CPU clocked at a relatively modest 1.2 GHz and built in a 90nm process currently delivers 2-4x the throughput of a 1.9 Ghz dual core Power 5+ CPU.
All of these results are with 1.2 Ghz T1 and 1.9 Ghz Power 5+ except the NotesBench test where the IBM used 1.5 Ghz Power 5+. The net net is that for server workloads 2-3x performance improvment delivered with the next generation Power is not remotely going to cut it. Sun will be releasing the follow on to the T1 in 2007 and Rock the high end follow on in 2008. IBM sould be consuming their transistor advantage with agressively multi-threaded CPU's which are inherantly more memory fiendly and deliver much better throughput.
You are right, spending $50 billion getting the population of the US out of their SUV's and into public transport would be a better bet in the short term.
But this would be an after the event solution to a massive slowdown or total stopage of the Gulf Stream which may happen if we fail to alter the behaviour of the worlds largest C02 emitting nations.
Climate models run by the Met Office in the UK would tend to suggest that stopping the Gulf Stream would cause rather more than $50 billion worth of damage to the economies of western europe and the US.
And $50 billion is peanuts compared with the US defence budget which is currently running at 400+ billion.
I am fairly sure that UNIX is more secure than Windows for a number of reasons.
1. While there is a great deal more Windows around than UNIX, UNIX is where the money is. If you want to extract large sums of money or steal swathes of identities then UNIX servers tend to be the systems hosting these backend services. So UNIX should be the target of hackers wanting to make serious money while much of the Windows activity is concentrated on hacks designed to produce the maximum public impact most of which cost because they down systems rather than extract cash from systems. The fact that almost all the money making hacks concentrate on Windows is testiment to the factthat it is difficult todo on UNIX.
2. Much of UNIX is OpenSource or available as source code, despite this there have been very few examples of ethical hacks or demos of vunerability that have been viable generated by security research companies or ethical hacking groups.
3. Stack overflow holes account for a huge chunk of the Windows vunerabilities mainly because Windows and x86 lack generic protection against these specific overflows. This is not true of UNIX particularly if it isn't running on Intel. Solaris for example has specific controls which limit the options for stack overflows as does the SPARC processor. These controls make it more difficult for hackers to generate exploits that remain viable.
4. There have been vanishingly tiny numbers of viable reported UNIX virii, none in the case of Solaris.
Solaris hasn't been slow relative to Linux since Solaris 10 came out and before that Solaris outperformed Linux for most SMP workloads but lost out on single CPU systems.
One of the design goals for Solaris 10 was for it to be not more than 5% slower than Linux for a range of single processor workloads where typically in the past Linux had been faster (on the same hardware). To that end Sun developed a benchmark called LibMicro which modeled the workloads which Solaris underperformed at and gave this to the Solaris 10 kernel developers as a way of measuring how far they were from their goal.
Most of the benchmarks that have been published show that they have done a pretty good job with Solaris delivering very similar performance to Linux on the same hardware for single CPU workloads and generally outperfoming Linux on SMP workloads.
There are some areas where Solaris anhilates Linux, give Solaris 10 a TCP heavy workload and it will easily outperform Linux. This may also no apply to UDP as well.
To give you an example of how close Solaris is to Linux on single CPU tests the SPECjbb results for a AMD based x2100 are 15434 for SLES 9 64bit and 16070 for Solaris 10 64bit
This is changing, we are seing more and more interest in Solaris x86.
The general feedback is that it is as fast or faster as Linux on the same hardware, you can get it for free and use it without having to go something like the Fedora route and if you do want support it is cheaper than Linux.
Sun is already distributing the code to Solaris (OpenSolaris) under their CDDL license.
I somewhat doubt that SCO would consider suing Sun to be a good idea, Sun holds a rather large chunk of patents relating to UNIX networking, kernels etc and I have no doubt that any case brought by SCO would result in a rather in depth analysis by Sun of SCO's position with respect to Sun's patent portfolio.
Sure the EE has a smaller die size 169 vs 199 so in theory using a similar sized wafer Intel should get a higher yield because they have more dies per wafer. However that assumes a parity in terms of failure rate between the AMD 90nm process and the Intel 65nm process.
Manufacturers guard their effective yield rate stats very closely so its impossible to say if Intel or AMD has the advantage here. However the 65nm process is a very new one and it is likely that as in Intels move to 90nm their effective yield will initially start low and then increase, while AMD with the a more mature process have a higher yield.
Since both CPU's cost about the same it would appear that at least for the moment neither vendor has a yield advantage.
It is also obvious that Intels strategy of being as early into a new process is driven largely by necessity because the facts plainly illustrate how far behind the FX-60 the EE is on all other metrics except price despite its apparent process advantage. AMD on the other hand have the luxury of being able to wait until the new process matures a bit before delivering product using it.
Compare the Pentium EE 955 and the Athlon 64 FX-60 currently the top end of the Intel and AMD dual core workstation/gaming CPU range.
The Pentium EE is fabbed in a 65nm process while the Athlon is fabbed in a 90nm process.
The Pentium EE has a 169mm/sq die size, the AMD 199mm/sq.
Under load the Pentium EE consumes 286 watts, while the AMD consumes 225 watts. At idle the Pentium EE consumes 189 watts, while the AMD consumes 149 watts
They both cost around $1000
The vast majority of benchmarks show the FX-60 easily outperforming the Pentium EE. More damagingly the slower Athlon X2 4800+ also outperforms the EE on the vast majority of tests and costs less.
As you can see from this being built in a better Fab does not necessarely impart any competitive advantage on the Intel processor and so it remains to be seen if being first into 45nm will help Intel get ahead of AMD
The problem with heating your house with waste heat from your gadgets is that it is a very inefficient use of resources.
Most fossil fuel electricity generation and transmission is less than 50% efficient, true you could be talking about renewables or nuclear but on balance you probably arn't. The only way to improve this is to participate in a CHP scheme where waste heat from the generation process is used for domestic heating and transmission losses are minimised.
On the other hand domestic heating using Oil or Gas is much more efficient up to 90% and in the case of Gas has an almost 0% transmission loss.
So what you should be doing is ditching electical heating unless your can source your electricity from renewables or nuclear, turning off anything when possible and checking the power consumption of devices that have to be turned on all the time or which are on for reasonable periods. Its interesting just how much variation there is between say one 8port Gigabit switch and another. Install energy efficient lighting because using conventional lightning as a heat source is very inefficient
One of the worst environmental crimes has been the dash to generate electricity using natural Gas and in the process running down the reserves of a low transmission loss high efficiency domestic energy source.
Xen and Vserver don't really compete except at a 30,000 foot level.
Xen allows you to host a number of different kernels and if you want different OS's on the same platform, it does this by providing a hypervisor that allows multiple OS's to run on the same platform at the same time. In theory at least the OS instances hosted by Xen do not need to be Xen aware.
Vserver impliments something akin to BSD Jails or Solaris Zones hosted on a single kernel.
They both have their advantages and uses.
Xen supports multiple copies of the same OS at different patch levels and versions as well as hosting entirely different OS's on the same platform at the same time. This can be an advantage and a disadvantage. From a development perspective being able to support a number of different revisions of the same OS on the same platform at the same time can be attractive, from a production perspective this can be less so.
From an efficiency perspective Vserver should win over Xen every time as would Solaris Zones and BSD Jails.
From an availability perspective Xen should provide higher levels of availability than Vserver because a kernel crash in one partition should not cause a crash in another and at the same time Xen should allow a hardware failure for example a CPU failure to be isolated to the partition(s) being hosted by that CPU. Of course you could argue that you are simply swapping a single point of failure at the Linux kernel level hosting Vserver for a single point of failure in the Xen hypervisor.
It should also be pointed out that comparing Xen hosting Linux with Solaris Zones from an availability perspective is less advantageous from to Xen because Solaris can survive the failure of a CPU provided it isn't running the kernel.
I would be interest to know which UNIX or Linux kernel you think is faster than Solaris. Most of the benchmarks testing Solaris 10, Linux etc have concluded that Solaris 10 is within a gnats whisker of the best Linux kernel for single CPU workloads with Solaris having better scalability than Linux.
In addition the Solaris 10 TCP/IP stack is much faster than any of the competitive IP stacks.
SPEC CPU which you refer to is very dependant on Compiler and Compiler options, that said the indevidual tests that make up Int and Fp are real world code and so any compiler tweeks generally also help real applications as well. I assume you are refering to the Fp optimisations that Sun added to their compilers in the UltraSPARC III 900 Mhz timeframe, in fact at the time the vast majority of people who reviewed what Sun had done concluded that their tuning was fair and also also usefull to other non SPEC codes which is the acid test of any compiler tweak.
I would also assume that Opteron will be faster than Intel particularly with Dual Core Opteron vs Dual Core Xeon, you can see how badly the Dell Scales with 2 dual core CPU's vs the IBM xSeries box with 2 Single Core CPU's.
That said I would expect that a 4 CPU Opteron Box would be about the same speed as the IBM P550 if it is using Dual Core Opterons and about 15% faster if it is using 4 x Single Core Opterons.
In neither case is the Opteron likely to overhaul the T2000 on web serving, single threaded apps on the otherhand would be a very different story and anything with a significant FP element will also perform badly on the T2000.
I used the StarDivision product and I now use OpenOffice and StarOffice and on that basis I can assure you that most of the development was not done when it was a commercial product. Apart from anything else the current StarOffice file formats for Calc, Writer, Impress are totally different to the old StarDivision products and that in itself represents a huge chunk of development.
Slashdot Mirror
There are a number of pale imitations of dtrace available for Linux but none of them gets close to DTrace functionality, safety or performance. Part of the problem is that Dtrace uses a fully instrumented kernel which is one and the same as the production Solaris kernel. Almost all the other DTrace imitators on Linux rely on special Linux kernels and none of them have the safety of DTrace which you can turn on on a production kernel without worrying about performance or kernel panics.
One reason why Linux cannot deliver the same functionality as DTrace/Solaris is the resistance put up by Trovalds to instumenting the Linux kernel, his view is that dbugging is for wimps, code should be perfect and therefore DTrace type funtionality isn't necessary.
ZFS isn't available either though it would be simpler to impliment on Linux than DTrace. Zones and Container type functionality does exist for Linux/BSD Zones are like BSD Jails.
Sun are unlikely to drop Solaris, it is and for the most part always has been their crown jewels.
It would be difficult to find a OS that on a capability by capability approaches Solaris as a server platform. dtrace, SMF, zones, fireengine, great scalability, good enough HCL.
However I can understand a Linux advocate wanting Sun to drop Solaris, it is the closest and best competitor to Linux.
A large number of big commercial companies that were early adopters of Linux are now looking long and hard at Solaris x86. Its fast, cheaper than Linux, OpenSource if they want to tick that box and it runs on pretty much all the hardware that they deployed Linux on.
Some have jumped allready.
Add NetBeans, the slab memory allocator and a whole of boring but rather critical Linux plumbing.
Ever wondered why Linux is rather Solaris like ????
Highly amusing. Last time anyone counted Sun had contributed more code to the RedHat distribution than any other entity except FSF.
I rather like the idea of people who don't think that Sun's OpenSource contributions matter being made to remove all Sun's donated code from their Linux distribitions because Linux would cease to exist at least for them.
T1 isn't OOO. It 8 cores essentially cut and pasted across a die. You could build a much smaller processor based on the T1 design using say 2 cores. However as far as I know you could not use something like Microblaze softcore because it is 32bit only.
Apart from OpenOffice, NetBeans, NFS, OpenSolaris big chunks of most Linux distributions (last time anyone counted RedHat contained more source attributed to by Sun than any other entity except FSF), cubic spline, etc etc etc etc.
However since Sun ownes the rights to the core Solaris source code and to the methods and concepts they are perfectly within their rights to release under CDDL.
Umm actually your argument is rather dubious at best. If Sun paid SCO to allow them to release chunks of SCO IP under OpenSource (I think it was x86 device driver code) then you could argue that Sun would obviously think that IBM did something wrong. Sun paid to release and SCO asserts that IBM did not.
Perhaps IBM have included Sun in the case because they want an example of how it should be done in case they lose.
Just kidding.
Quite, my understanding was that Sun bought a whole load of device driver code from SCO, mainly for use on Solaris x86.
There is nothing in the design of Opteron which makes it impossible to build greater than 8 way SMP boxes as Sun are soon going to demonstrate. In fact you could argue that saddling Itanium with Frontside Bus was rather more of a hinderence than the Opteron Hypertransport architecture. SGI themselves have complained about the difficulties of building a very large MP system using FrontSide as the basic building block.
SGI were one of the first vendors to produce Itanium based systems, switching from MIPS earlier would only have meant that they had no CPU to put in their Itanium servers.
Then there was the problem that the first iteration of Itanium was horribly uncompetitive for both Integer and FP with Itanium only establishing its niche FP status at the second attempt.
The writing on the wall for MIPS probably goes back to Digital dropping it in favour of Alpha, while SGI's bargain basement sale of Cray Business Systems Division (Aka Sun E10K) and the earlier aquisition of Cray set the seeds to SGI's long downward spiral. At the same time propelling Sun from a Workstation vendor who happend to do servers to the position of being the largest UNIX server vendor with huge dominance of the high end UNIX market. The E10K arrived at a time when the largest Digital box topped out at 6-10 CPU's depending on if you wanted memory and I/O, HP topped out at 12 and IBM 8.
Apple switching to Intel probably wasn't the brightest move, they should have switched to AMD who have a clear lead over Intel in both power and performance.
IBM's announcements are interesting but in my option IBM have made a big mistake. Clocking CPU's faster may seem attractive but the reality is that all this does is build a bigger and bigger memory pressure problem which results in poor performance except for the minority of workloads which are cache friendly. This is because RAM performance is not increasing at anything like the same rate as CPU clock.
So all IBM is doing is building a processor where missing the L1/L2/L3 cache has a greater relative penalty in terms of stalls than the current Power 5+. Because of this real world performance will not be anything like the 2-3x clock hike between Power 5+ and the new CPU's.
And the 2-3x real world throughput per CPU package is not going to allow IBM to remain remotely competitive. The Sun T1 CPU clocked at a relatively modest 1.2 GHz and built in a 90nm process currently delivers 2-4x the throughput of a 1.9 Ghz dual core Power 5+ CPU.
SPECJappserver 3x throughput/module
SPECweb2005 3.5x throughput/module
SPECjbb2004 2.1x throughput/module
SAP-SD 2 tier 3.8x throughput/module
NotesBench 4.4x throughput/module
All of these results are with 1.2 Ghz T1 and 1.9 Ghz Power 5+ except the NotesBench test where the IBM used 1.5 Ghz Power 5+. The net net is that for server workloads 2-3x performance improvment delivered with the next generation Power is not remotely going to cut it. Sun will be releasing the follow on to the T1 in 2007 and Rock the high end follow on in 2008. IBM sould be consuming their transistor advantage with agressively multi-threaded CPU's which are inherantly more memory fiendly and deliver much better throughput.
You are right, spending $50 billion getting the population of the US out of their SUV's and into public transport would be a better bet in the short term.
But this would be an after the event solution to a massive slowdown or total stopage of the Gulf Stream which may happen if we fail to alter the behaviour of the worlds largest C02 emitting nations.
Climate models run by the Met Office in the UK would tend to suggest that stopping the Gulf Stream would cause rather more than $50 billion worth of damage to the economies of western europe and the US.
And $50 billion is peanuts compared with the US defence budget which is currently running at 400+ billion.
I am fairly sure that UNIX is more secure than Windows for a number of reasons.
1. While there is a great deal more Windows around than UNIX, UNIX is where the money is. If you want to extract large sums of money or steal swathes of identities then UNIX servers tend to be the systems hosting these backend services. So UNIX should be the target of hackers wanting to make serious money while much of the Windows activity is concentrated on hacks designed to produce the maximum public impact most of which cost because they down systems rather than extract cash from systems. The fact that almost all the money making hacks concentrate on Windows is testiment to the factthat it is difficult todo on UNIX.
2. Much of UNIX is OpenSource or available as source code, despite this there have been very few examples of ethical hacks or demos of vunerability that have been viable generated by security research companies or ethical hacking groups.
3. Stack overflow holes account for a huge chunk of the Windows vunerabilities mainly because Windows and x86 lack generic protection against these specific overflows. This is not true of UNIX particularly if it isn't running on Intel. Solaris for example has specific controls which limit the options for stack overflows as does the SPARC processor. These controls make it more difficult for hackers to generate exploits that remain viable.
4. There have been vanishingly tiny numbers of viable reported UNIX virii, none in the case of Solaris.
Solaris hasn't been slow relative to Linux since Solaris 10 came out and before that Solaris outperformed Linux for most SMP workloads but lost out on single CPU systems.
One of the design goals for Solaris 10 was for it to be not more than 5% slower than Linux for a range of single processor workloads where typically in the past Linux had been faster (on the same hardware). To that end Sun developed a benchmark called LibMicro which modeled the workloads which Solaris underperformed at and gave this to the Solaris 10 kernel developers as a way of measuring how far they were from their goal.
Most of the benchmarks that have been published show that they have done a pretty good job with Solaris delivering very similar performance to Linux on the same hardware for single CPU workloads and generally outperfoming Linux on SMP workloads.
There are some areas where Solaris anhilates Linux, give Solaris 10 a TCP heavy workload and it will easily outperform Linux. This may also no apply to UDP as well.
To give you an example of how close Solaris is to Linux on single CPU tests the SPECjbb results for a AMD based x2100 are 15434 for SLES 9 64bit and 16070 for Solaris 10 64bit
This is changing, we are seing more and more interest in Solaris x86.
The general feedback is that it is as fast or faster as Linux on the same hardware, you can get it for free and use it without having to go something like the Fedora route and if you do want support it is cheaper than Linux.
Sun is already distributing the code to Solaris (OpenSolaris) under their CDDL license.
I somewhat doubt that SCO would consider suing Sun to be a good idea, Sun holds a rather large chunk of patents relating to UNIX networking, kernels etc and I have no doubt that any case brought by SCO would result in a rather in depth analysis by Sun of SCO's position with respect to Sun's patent portfolio.
Sure the EE has a smaller die size 169 vs 199 so in theory using a similar sized wafer Intel should get a higher yield because they have more dies per wafer. However that assumes a parity in terms of failure rate between the AMD 90nm process and the Intel 65nm process.
Manufacturers guard their effective yield rate stats very closely so its impossible to say if Intel or AMD has the advantage here. However the 65nm process is a very new one and it is likely that as in Intels move to 90nm their effective yield will initially start low and then increase, while AMD with the a more mature process have a higher yield.
Since both CPU's cost about the same it would appear that at least for the moment neither vendor has a yield advantage.
It is also obvious that Intels strategy of being as early into a new process is driven largely by necessity because the facts plainly illustrate how far behind the FX-60 the EE is on all other metrics except price despite its apparent process advantage. AMD on the other hand have the luxury of being able to wait until the new process matures a bit before delivering product using it.
Fabs arn't everything.
Compare the Pentium EE 955 and the Athlon 64 FX-60 currently the top end of the Intel and AMD dual core workstation/gaming CPU range.
The Pentium EE is fabbed in a 65nm process while the Athlon is fabbed in a 90nm process.
The Pentium EE has a 169mm/sq die size, the AMD 199mm/sq.
Under load the Pentium EE consumes 286 watts, while the AMD consumes 225 watts.
At idle the Pentium EE consumes 189 watts, while the AMD consumes 149 watts
They both cost around $1000
The vast majority of benchmarks show the FX-60 easily outperforming the Pentium EE. More damagingly the slower Athlon X2 4800+ also outperforms the EE on the vast majority of tests and costs less.
As you can see from this being built in a better Fab does not necessarely impart any competitive advantage on the Intel processor and so it remains to be seen if being first into 45nm will help Intel get ahead of AMD
The problem with heating your house with waste heat from your gadgets is that it is a very inefficient use of resources.
Most fossil fuel electricity generation and transmission is less than 50% efficient, true you could be talking about renewables or nuclear but on balance you probably arn't. The only way to improve this is to participate in a CHP scheme where waste heat from the generation process is used for domestic heating and transmission losses are minimised.
On the other hand domestic heating using Oil or Gas is much more efficient up to 90% and in the case of Gas has an almost 0% transmission loss.
So what you should be doing is ditching electical heating unless your can source your electricity from renewables or nuclear, turning off anything when possible and checking the power consumption of devices that have to be turned on all the time or which are on for reasonable periods. Its interesting just how much variation there is between say one 8port Gigabit switch and another. Install energy efficient lighting because using conventional lightning as a heat source is very inefficient
One of the worst environmental crimes has been the dash to generate electricity using natural Gas and in the process running down the reserves of a low transmission loss high efficiency domestic energy source.
Xen and Vserver don't really compete except at a 30,000 foot level.
Xen allows you to host a number of different kernels and if you want different OS's on the same platform, it does this by providing a hypervisor that allows multiple OS's to run on the same platform at the same time. In theory at least the OS instances hosted by Xen do not need to be Xen aware.
Vserver impliments something akin to BSD Jails or Solaris Zones hosted on a single kernel.
They both have their advantages and uses.
Xen supports multiple copies of the same OS at different patch levels and versions as well as hosting entirely different OS's on the same platform at the same time. This can be an advantage and a disadvantage. From a development perspective being able to support a number of different revisions of the same OS on the same platform at the same time can be attractive, from a production perspective this can be less so.
From an efficiency perspective Vserver should win over Xen every time as would Solaris Zones and BSD Jails.
From an availability perspective Xen should provide higher levels of availability than Vserver because a kernel crash in one partition should not cause a crash in another and at the same time Xen should allow a hardware failure for example a CPU failure to be isolated to the partition(s) being hosted by that CPU. Of course you could argue that you are simply swapping a single point of failure at the Linux kernel level hosting Vserver for a single point of failure in the Xen hypervisor.
It should also be pointed out that comparing Xen hosting Linux with Solaris Zones from an availability perspective is less advantageous from to Xen because Solaris can survive the failure of a CPU provided it isn't running the kernel.
I would be interest to know which UNIX or Linux kernel you think is faster than Solaris. Most of the benchmarks testing Solaris 10, Linux etc have concluded that Solaris 10 is within a gnats whisker of the best Linux kernel for single CPU workloads with Solaris having better scalability than Linux.
In addition the Solaris 10 TCP/IP stack is much faster than any of the competitive IP stacks.
SPEC CPU which you refer to is very dependant on Compiler and Compiler options, that said the indevidual tests that make up Int and Fp are real world code and so any compiler tweeks generally also help real applications as well. I assume you are refering to the Fp optimisations that Sun added to their compilers in the UltraSPARC III 900 Mhz timeframe, in fact at the time the vast majority of people who reviewed what Sun had done concluded that their tuning was fair and also also usefull to other non SPEC codes which is the acid test of any compiler tweak.
I would also assume that Opteron will be faster than Intel particularly with Dual Core Opteron vs Dual Core Xeon, you can see how badly the Dell Scales with 2 dual core CPU's vs the IBM xSeries box with 2 Single Core CPU's.
That said I would expect that a 4 CPU Opteron Box would be about the same speed as the IBM P550 if it is using Dual Core Opterons and about 15% faster if it is using 4 x Single Core Opterons.
In neither case is the Opteron likely to overhaul the T2000 on web serving, single threaded apps on the otherhand would be a very different story and anything with a significant FP element will also perform badly on the T2000.
Interestiong, there are plenty of people who have argued with Linus over kernel design.
It is odd, the T2000 uses the same chassis as the X4200 but the T1000 does not chassis share with the X2100 or X4100.
Shame.
I understand that the upcoming Opteron Blade chassis from Sun will support the Niagra processors.
I used the StarDivision product and I now use OpenOffice and StarOffice and on that basis I can assure you that most of the development was not done when it was a commercial product. Apart from anything else the current StarOffice file formats for Calc, Writer, Impress are totally different to the old StarDivision products and that in itself represents a huge chunk of development.