The ONLY thing they can do is either drastically reduce the number of digital and HD channels they offer their subscribers, or bite the bullet and start massively upgrading their network.
They could also cut back the number of analog channels they're supporting. Each one frees up a digital QAM channel, which can house two 19 Mbit MPEG-2 HD channels, which matches OTA quality. Unfortunately, the all-digital mandate for 2009 only applies to OTA, and not to cable systems, most of whom will continue to support analog for a long time.
The real irony here is the most expertise I've seen out of the Microsoft side of things is the guys that can understand Redmond's insane licensing system.
That's intentional. A good deal of MCSE training/testing has to do with licensing. MCSE's aren't intended to be technical geniuses. They're meant to be clones, indoctrinated to look at things the way Microsoft wants you to look at them. That's why the key to any Microsoft test, if you get stuck on a question that seems to have more than one correct answer, is to look at it from the perspective of what would make Microsoft the most money. That will almost always be the "right" one.
Not to say all MS training is bad. If you get a decent instructor who has experience with other vendors and solutions, who can cut through all the crap and extract the meat of what you actually need to know to succeed in the field, you can actually learn something useful. There's not many instructors like that, though.
I was actually going to post the exact same thing, though in my mind it's MUCH harder to get teams to work well together in a VoIP implementation, just because of the completely different worlds the teams come from. A lot of traditional telecom engineers are having a real tough time adapting right now, as their industry is getting thrust into world that they know very little about. People from the Data world are having challenges with VoIP, too. However, the telecom world is moving in their direction, whereas it's moving away from the PBX guys.
Virtualization planning is just an extension of the work that's been going on for years between network, storage and server engineers. It's just a little more detailed, and requires more forethought.
Items that need to be redundant, should not be virtualized on shared hardware. I've heard people want to virtualize redundant instances of directory services, databases, proxy servers...etc. I call this the "putting all your eggs in one,central-point-of-failure, hardware basket".
If you're doing something stupid like putting clusters or redundant servers on the same virtualization host, then I would agree. High availability loses it's meaning if all your nodes have a single point of failure.
However, there's absolutely no reason you can't make your virtualization implementation highly available itself. Right now, I have clusters running in VMware VI3, that are running on separate hosts. Even with DRS, which balances all your VMs across an entire pool of servers, I can ensure that redundant servers and clusters don't end up running on the same piece of physical hardware. And when you add HA into the mix, you also provide a level of high availability to systems that you might not otherwise have been able to justify the expense on.
VMware has multiple ways to balance and protect resources. You can set hard limits on VM resource utilization, ensuring that one machine can never take over a certain percentage of CPU, memory and even network bandwidth. VMs can also be given "shares", which determine priority over resources. In a contention for resources, the VM with the highest number shares is given immediate access to what it needs, with the lower share VMs splitting what's left over. This is the recommended way to handle it, as it gives you the best overall hardware utilization across your entire implementation.
Starting in VI3, VMware also introduced the ability for VMs to migrate automatically across an entire farm of hosts, based on server load. In my experience, with very little tweaking, VMware does a very good job of fairly balancing resources.
At least, I know it does for me. There are plenty of times now I wish we had never gotten these stupid Blackberries. Once your management knows that they can get a hold of you via email any time, any place, they suddenly expect that to be the norm. With plain old cell phones, it requires a personal interaction that feels much more intrusive. When you shoot off an email, it doesn't feel the same. You don't feel bad about it, like you do when you call someone and interrupt their dinner. Which makes people much more likely to do it.
This happens when you're cutting corners to speed your testing. Apparently this bug doesn't affect all versions of the client, just a specific one. Testing your patch with all possible types of installed clients takes a lot of time. Which means either QA management is lazy, an employee tasked with the test was lazy, or upper management rushed them to get it out the door. I'd put my money on the last option.
I believe that the FCC requires cable companies to - at the least - provide local affiliates in unencrypted QAM, so if you get a QAM tuner you might still be able to watch the digital feeds.
OTA broadcasts are not likely to go to MPEG4 any time soon. It isn't part of the ATSC spec. Most, if not all, digital tuners can currently only decode MPEG-2. I've heard of some rumblings to try and get it added into ATSC (19 Mbit MPEG-2 is just barely enough to provide good quality 1080i, and many stations are bit-starving their HD feeds in favor of subchannels for extra income), but all the people who have already bought digital tuners would still be out of luck, which kind of defeats the whole purpose of the ramp-up to ATSC.
MPEG4 is starting to be used in satellite and digital cable delivery, but for most local broadcasts they're taking the station's MPEG-2 stream and re-compressing it as MPEG4, which doesn't do much for overall quality, but does free up some bandwidth for more channels. In scenarios where the cable or satellite provider can receive a completely uncompressed feed, MPEG4 can offer superior picture quality, but unfortunately most of what you're seeing right now in MPEG4 is still being re-compressed.
Those episodes were from last year. I'm sure either Blink or Family of Blood will make it next time.
And they aren't canceling it. From what I understand, they're doing the 4th series, then taking a break and producing a handful of extended length specials, and then doing the 5th series.
VDI is an overall [i]concept[/i] that VMware has been building with various third-party application vendors (including Citrix - though I'd imagine that's going to change now). VMware sells a VDI edition of VI3 licensing, but it's not required to actually do VDI. At the core, all you need is a virtualization platform, and a remote client to interact with the desktops. You can even do it with VMware server for free if you want.
What do you mean by "graphics"? Are you talking about 3D games, or full motion video? If so, Citrix is not any better at this than VDI. If you're just talking about GUI applications, then you really don't know what you're talking about here. In typical VDI installs, you're virtualizing Windows XP workstations and interacting with them through RDP (which was originally licensed from Citrix, ironically). In Citrix, you're accessing a Windows server over their own ICA protocol. Since RDP 5.1, there's not a whole lot of difference between ICA and RDP. I believe ICA still holds a bit of an edge in bandwidth utilization and efficiency, but not much anymore. Over a LAN, it's not even noticeable. Visual performance-wise, there's not really a difference between VDI and Citrix.
VMware offers little in the realm of... desktop virtualization
Actually, no, not really. VMware has been doing quite a lot with VDI for a couple of years now. Really, they've pioneered it. It's Citrix that was trying to adapt and catch up in this field, as it threatened their traditional market. The purchase of XenSource goes a long way to help them compete in a market that VMware has been dominating.
In fact, I would go as far as saying that this purchase is primarily about Citrix keeping up with VMware in VDI.
the "directly on hardware" is marketing talk saying that you dont need and shouldnt even bother with the host OS, vmware takes care of it (installation, support, updates, etc)
No, actually, it doesn't mean that at all. You have no actual concept of how ESX works, you just SSH'd into a box, ran uname and considered yourself clever. What you are looking at is the Service Console. The SC runs a modified RHEL 3, and functions on bootup as a bootloader for the vmkernel. Once the vmkernel is loaded, the vmkernel handles all hardware access and virtualization functions, and is a completely separate OS from the service console. The Service Console continues running as a pseudo-VM with API hooks into the vmkernel to preform management functions. It bridges the vmkernel with the outside world. The vmkernel itself, the underlying OS running everything and managing hardware access, is proprietary, and is not Linux.
Might I suggest you take some VMware classes to gain a better understanding of how this stuff works.
That's not surprising at all. You're interacting with the service console, which runs Linux. It's more interesting to me that your Nagios box thinks the SC is running 2.6.8. And Debian, at that. The Service Console for ESX 3 actually runs a heavily modified RHEL 3 - 2.4.21 as of 3.0.1. ESX 2.5 ran Red Hat 9, I believe.
Then you had a poor-quality instructor. Every VMware instructor I've had has been crystal clear that the Service Console runs a heavily modified version Red Hat, but that the vmkernel - the OS that's bootloaded by the SC, which handles virtualization and hardware access, or in other words the underlying platform - is a completely proprietary OS.
From what I understand, the Linux 2.4 kernel (Service Console) does the initial boot, but only addresses a limited amount of RAM (usually between 256M and 384M, depending on how many VMs you plan on running). It then loads the vmkernel, which takes the rest of the RAM and takes over scheduling functions from the Service Console, and directly addresses the hardware. With the exception of the initial RAM, everything else the Service Console does is through the vmkernel. The way it was explained to me was that the SC essentially becomes a pseudo-VM itself, relying on the vmkernel for hardware access.
In turn, the Service Console has some hooks into the vmkernel to perform management functions, monitoring, etc. The SC functions as a bridge between the vmkernel and the outside world. That's the way I understand it, anyway. Could be totally wrong. I have heard rumors in the past, though, that VMware is planning to ditch the Linux SC in future versions in favor of their own service console OS. Which would render the whole argument moot.
The service console runs a heavily modified version of Red Hat (in ESX 2.5 I believe it was Red Hat 9. In 3.0 it's RHEL 3). In 3.0 patches are still done through RPMs.
I'm primarily a VMware VI3 user, but I've been starting to do more with Xen lately. I have to say, Xen is very impressive in what it accomplishes. It's very stable, and has the capability to do some really advanced stuff. That being said, it can be a real pain to get some of those advanced features working. For example, running Xen in CentOS 5, I had a server with two NICs, and I wanted to setup a second bridged interface for the second NIC. It took way more effort than it should have to get that working correctly. In ANY VMware product, that's a task that takes, literally, seconds. Another thing I'm working on is getting VMs to auto-boot in a particular order, and wait on another VM to finish booting before the next one starts. Again, a task that's second nature in VMware, but appears to be difficult to implement in Xen.
In the end, it all boils down to management tools. There are no decent centralized tools to manage a farm of Xen servers right now, let alone manage just one host. Virt-manager is very helpful, but extremely limited. And I've looked into some web-based management applications, but none of them are anywhere close to mature enough to deploy in a data center. Xen is still my choice for free Linux virtualization, but they've got a long way to go to even approach VMware.
The second part of the article, he wonders why Comcast doesn't offer HDNet or HDNet movies. It's because Marc Cuban and Comcast are currently engaged in a corporate game of chicken. Cuban wants a couple of bucks per subscriber (which, frankly, I would be more than willing to pay just for HDNet Movies alone) and Comcast claims they don't want to tier-ize their HD programming. I've heard rumor that Comcast has started to cave in Houston, offering both channels for a few dollars, as a test.
My experience with Comcast taking over from Time Warner here was almost identical to this gentleman's. I lost about 20% of the channels I paid for starting the day they took over. They went to "Not Authorized", just like his. Stayed that way for 2 weeks. No one at Comcast was able to send the authorization codes to my DVR because their system was "broken". What I actually found out later, was that Comcast came in like a bull in a china shop on the week of the actual cutover, and made our local office to adopt their cable box management software immediately. It didn't work. At all. For two weeks.
Right now, they're fighting like crazy to keep UVerse out of our state. Constant commercials demonizing AT&T, trying to explain why their having a monopoly on your land-line television service is actually good for you, and their bi-annual rate raises are actually what you want. If UVerse or FiOS ever finally comes here, Comcast is out the door of my house as soon as I can get an installer on site.
Is it because there are no alternatives that have the features they need?
Pretty much. Photoshop is light years ahead of the closest competition when it comes to professional graphic design work. Amateurs and hobbyists a lot of times only deal with the filters, as those - for the occasional user - are the most whiz-bang parts of Photoshop, and the easiest to use to impress fellow forum-goers with your l33t Photoshop skills. And GIMP has pretty good filters, too. But move into the professional printing world, and the real meat of Photoshop is in a lot of the less-glamorous stuff: How it handles CMYK, spot colors, color profiles, levels, color curves, alpha channels, etc. There really is nothing comparable in the field, and it's been that way for more than a decade. I think GIMP suffers from the fact that most of the people working on it only used Photoshop for web-display work. So, those are the only features they're really making much of an effort to copy well.
GIMP is great for overlaying "O RLY" on pictures of owls, and rendering lens flares on anything you can find. I'd even put it above Paint Shop Pro. I use it a lot for quick-and-dirty RGB jobs, if I don't have Photoshop readily available already. It's really a great product for being free. But it still doesn't come close to Photoshop.
True... in a small company where you're doing everything, it can be almost impossible to telecommute. It really depends on your job, though. I'm a sysadmin/engineer, and I can count on one hand the number of times I've had to go into the data center to fix something over the past 6 months. Remote systems management capabilities like HP's iLO, moving to a SAN instead of individual hard disks... about the only thing I have to go into the data center for anymore is to rack a new server. Once it's physically in place, there isn't anything I can't do from just about anywhere in the world.
Slashdot Mirror
The ONLY thing they can do is either drastically reduce the number of digital and HD channels they offer their subscribers, or bite the bullet and start massively upgrading their network.
They could also cut back the number of analog channels they're supporting. Each one frees up a digital QAM channel, which can house two 19 Mbit MPEG-2 HD channels, which matches OTA quality. Unfortunately, the all-digital mandate for 2009 only applies to OTA, and not to cable systems, most of whom will continue to support analog for a long time.
The real irony here is the most expertise I've seen out of the Microsoft side of things is the guys that can understand Redmond's insane licensing system.
That's intentional. A good deal of MCSE training/testing has to do with licensing. MCSE's aren't intended to be technical geniuses. They're meant to be clones, indoctrinated to look at things the way Microsoft wants you to look at them. That's why the key to any Microsoft test, if you get stuck on a question that seems to have more than one correct answer, is to look at it from the perspective of what would make Microsoft the most money. That will almost always be the "right" one.
Not to say all MS training is bad. If you get a decent instructor who has experience with other vendors and solutions, who can cut through all the crap and extract the meat of what you actually need to know to succeed in the field, you can actually learn something useful. There's not many instructors like that, though.
I was actually going to post the exact same thing, though in my mind it's MUCH harder to get teams to work well together in a VoIP implementation, just because of the completely different worlds the teams come from. A lot of traditional telecom engineers are having a real tough time adapting right now, as their industry is getting thrust into world that they know very little about. People from the Data world are having challenges with VoIP, too. However, the telecom world is moving in their direction, whereas it's moving away from the PBX guys.
Virtualization planning is just an extension of the work that's been going on for years between network, storage and server engineers. It's just a little more detailed, and requires more forethought.
Items that need to be redundant, should not be virtualized on shared hardware. I've heard people want to virtualize redundant instances of directory services, databases, proxy servers...etc. I call this the "putting all your eggs in one,central-point-of-failure, hardware basket".
If you're doing something stupid like putting clusters or redundant servers on the same virtualization host, then I would agree. High availability loses it's meaning if all your nodes have a single point of failure.
However, there's absolutely no reason you can't make your virtualization implementation highly available itself. Right now, I have clusters running in VMware VI3, that are running on separate hosts. Even with DRS, which balances all your VMs across an entire pool of servers, I can ensure that redundant servers and clusters don't end up running on the same piece of physical hardware. And when you add HA into the mix, you also provide a level of high availability to systems that you might not otherwise have been able to justify the expense on.
VMware has multiple ways to balance and protect resources. You can set hard limits on VM resource utilization, ensuring that one machine can never take over a certain percentage of CPU, memory and even network bandwidth. VMs can also be given "shares", which determine priority over resources. In a contention for resources, the VM with the highest number shares is given immediate access to what it needs, with the lower share VMs splitting what's left over. This is the recommended way to handle it, as it gives you the best overall hardware utilization across your entire implementation.
Starting in VI3, VMware also introduced the ability for VMs to migrate automatically across an entire farm of hosts, based on server load. In my experience, with very little tweaking, VMware does a very good job of fairly balancing resources.
On the VMware side, there's several options. VMware's Consolidated Backup does exactly this. Also you can look at ESX Ranger.
That's not an office. That's a "stick the IT guy in the closet so we don't have to spend money on him" room.
At least, I know it does for me. There are plenty of times now I wish we had never gotten these stupid Blackberries. Once your management knows that they can get a hold of you via email any time, any place, they suddenly expect that to be the norm. With plain old cell phones, it requires a personal interaction that feels much more intrusive. When you shoot off an email, it doesn't feel the same. You don't feel bad about it, like you do when you call someone and interrupt their dinner. Which makes people much more likely to do it.
This happens when you're cutting corners to speed your testing. Apparently this bug doesn't affect all versions of the client, just a specific one. Testing your patch with all possible types of installed clients takes a lot of time. Which means either QA management is lazy, an employee tasked with the test was lazy, or upper management rushed them to get it out the door. I'd put my money on the last option.
I believe that the FCC requires cable companies to - at the least - provide local affiliates in unencrypted QAM, so if you get a QAM tuner you might still be able to watch the digital feeds.
OTA broadcasts are not likely to go to MPEG4 any time soon. It isn't part of the ATSC spec. Most, if not all, digital tuners can currently only decode MPEG-2. I've heard of some rumblings to try and get it added into ATSC (19 Mbit MPEG-2 is just barely enough to provide good quality 1080i, and many stations are bit-starving their HD feeds in favor of subchannels for extra income), but all the people who have already bought digital tuners would still be out of luck, which kind of defeats the whole purpose of the ramp-up to ATSC.
MPEG4 is starting to be used in satellite and digital cable delivery, but for most local broadcasts they're taking the station's MPEG-2 stream and re-compressing it as MPEG4, which doesn't do much for overall quality, but does free up some bandwidth for more channels. In scenarios where the cable or satellite provider can receive a completely uncompressed feed, MPEG4 can offer superior picture quality, but unfortunately most of what you're seeing right now in MPEG4 is still being re-compressed.
I would have to agree. I see all these kids pumping quarters into these machines and pretending to dance. Seems like a complete waste of money to me.
Those episodes were from last year. I'm sure either Blink or Family of Blood will make it next time.
And they aren't canceling it. From what I understand, they're doing the 4th series, then taking a break and producing a handful of extended length specials, and then doing the 5th series.
VDI is an overall [i]concept[/i] that VMware has been building with various third-party application vendors (including Citrix - though I'd imagine that's going to change now). VMware sells a VDI edition of VI3 licensing, but it's not required to actually do VDI. At the core, all you need is a virtualization platform, and a remote client to interact with the desktops. You can even do it with VMware server for free if you want.
What do you mean by "graphics"? Are you talking about 3D games, or full motion video? If so, Citrix is not any better at this than VDI. If you're just talking about GUI applications, then you really don't know what you're talking about here. In typical VDI installs, you're virtualizing Windows XP workstations and interacting with them through RDP (which was originally licensed from Citrix, ironically). In Citrix, you're accessing a Windows server over their own ICA protocol. Since RDP 5.1, there's not a whole lot of difference between ICA and RDP. I believe ICA still holds a bit of an edge in bandwidth utilization and efficiency, but not much anymore. Over a LAN, it's not even noticeable. Visual performance-wise, there's not really a difference between VDI and Citrix.
VMware offers little in the realm of... desktop virtualization
Actually, no, not really. VMware has been doing quite a lot with VDI for a couple of years now. Really, they've pioneered it. It's Citrix that was trying to adapt and catch up in this field, as it threatened their traditional market. The purchase of XenSource goes a long way to help them compete in a market that VMware has been dominating.
In fact, I would go as far as saying that this purchase is primarily about Citrix keeping up with VMware in VDI.
the "directly on hardware" is marketing talk saying that you dont need and shouldnt even bother with the host OS, vmware takes care of it (installation, support, updates, etc)
No, actually, it doesn't mean that at all. You have no actual concept of how ESX works, you just SSH'd into a box, ran uname and considered yourself clever. What you are looking at is the Service Console. The SC runs a modified RHEL 3, and functions on bootup as a bootloader for the vmkernel. Once the vmkernel is loaded, the vmkernel handles all hardware access and virtualization functions, and is a completely separate OS from the service console. The Service Console continues running as a pseudo-VM with API hooks into the vmkernel to preform management functions. It bridges the vmkernel with the outside world. The vmkernel itself, the underlying OS running everything and managing hardware access, is proprietary, and is not Linux.
Might I suggest you take some VMware classes to gain a better understanding of how this stuff works.
That's not surprising at all. You're interacting with the service console, which runs Linux. It's more interesting to me that your Nagios box thinks the SC is running 2.6.8. And Debian, at that. The Service Console for ESX 3 actually runs a heavily modified RHEL 3 - 2.4.21 as of 3.0.1. ESX 2.5 ran Red Hat 9, I believe.
Then you had a poor-quality instructor. Every VMware instructor I've had has been crystal clear that the Service Console runs a heavily modified version Red Hat, but that the vmkernel - the OS that's bootloaded by the SC, which handles virtualization and hardware access, or in other words the underlying platform - is a completely proprietary OS.
From what I understand, the Linux 2.4 kernel (Service Console) does the initial boot, but only addresses a limited amount of RAM (usually between 256M and 384M, depending on how many VMs you plan on running). It then loads the vmkernel, which takes the rest of the RAM and takes over scheduling functions from the Service Console, and directly addresses the hardware. With the exception of the initial RAM, everything else the Service Console does is through the vmkernel. The way it was explained to me was that the SC essentially becomes a pseudo-VM itself, relying on the vmkernel for hardware access.
In turn, the Service Console has some hooks into the vmkernel to perform management functions, monitoring, etc. The SC functions as a bridge between the vmkernel and the outside world. That's the way I understand it, anyway. Could be totally wrong. I have heard rumors in the past, though, that VMware is planning to ditch the Linux SC in future versions in favor of their own service console OS. Which would render the whole argument moot.
VMware Server actually runs on Windows or Linux.
The service console runs a heavily modified version of Red Hat (in ESX 2.5 I believe it was Red Hat 9. In 3.0 it's RHEL 3). In 3.0 patches are still done through RPMs.
I'm primarily a VMware VI3 user, but I've been starting to do more with Xen lately. I have to say, Xen is very impressive in what it accomplishes. It's very stable, and has the capability to do some really advanced stuff. That being said, it can be a real pain to get some of those advanced features working. For example, running Xen in CentOS 5, I had a server with two NICs, and I wanted to setup a second bridged interface for the second NIC. It took way more effort than it should have to get that working correctly. In ANY VMware product, that's a task that takes, literally, seconds. Another thing I'm working on is getting VMs to auto-boot in a particular order, and wait on another VM to finish booting before the next one starts. Again, a task that's second nature in VMware, but appears to be difficult to implement in Xen.
In the end, it all boils down to management tools. There are no decent centralized tools to manage a farm of Xen servers right now, let alone manage just one host. Virt-manager is very helpful, but extremely limited. And I've looked into some web-based management applications, but none of them are anywhere close to mature enough to deploy in a data center. Xen is still my choice for free Linux virtualization, but they've got a long way to go to even approach VMware.
The second part of the article, he wonders why Comcast doesn't offer HDNet or HDNet movies. It's because Marc Cuban and Comcast are currently engaged in a corporate game of chicken. Cuban wants a couple of bucks per subscriber (which, frankly, I would be more than willing to pay just for HDNet Movies alone) and Comcast claims they don't want to tier-ize their HD programming. I've heard rumor that Comcast has started to cave in Houston, offering both channels for a few dollars, as a test.
My experience with Comcast taking over from Time Warner here was almost identical to this gentleman's. I lost about 20% of the channels I paid for starting the day they took over. They went to "Not Authorized", just like his. Stayed that way for 2 weeks. No one at Comcast was able to send the authorization codes to my DVR because their system was "broken". What I actually found out later, was that Comcast came in like a bull in a china shop on the week of the actual cutover, and made our local office to adopt their cable box management software immediately. It didn't work. At all. For two weeks.
Right now, they're fighting like crazy to keep UVerse out of our state. Constant commercials demonizing AT&T, trying to explain why their having a monopoly on your land-line television service is actually good for you, and their bi-annual rate raises are actually what you want. If UVerse or FiOS ever finally comes here, Comcast is out the door of my house as soon as I can get an installer on site.
Is it because there are no alternatives that have the features they need?
Pretty much. Photoshop is light years ahead of the closest competition when it comes to professional graphic design work. Amateurs and hobbyists a lot of times only deal with the filters, as those - for the occasional user - are the most whiz-bang parts of Photoshop, and the easiest to use to impress fellow forum-goers with your l33t Photoshop skills. And GIMP has pretty good filters, too. But move into the professional printing world, and the real meat of Photoshop is in a lot of the less-glamorous stuff: How it handles CMYK, spot colors, color profiles, levels, color curves, alpha channels, etc. There really is nothing comparable in the field, and it's been that way for more than a decade. I think GIMP suffers from the fact that most of the people working on it only used Photoshop for web-display work. So, those are the only features they're really making much of an effort to copy well.
GIMP is great for overlaying "O RLY" on pictures of owls, and rendering lens flares on anything you can find. I'd even put it above Paint Shop Pro. I use it a lot for quick-and-dirty RGB jobs, if I don't have Photoshop readily available already. It's really a great product for being free. But it still doesn't come close to Photoshop.
I've got 3 words:
No More Phone.
True... in a small company where you're doing everything, it can be almost impossible to telecommute. It really depends on your job, though. I'm a sysadmin/engineer, and I can count on one hand the number of times I've had to go into the data center to fix something over the past 6 months. Remote systems management capabilities like HP's iLO, moving to a SAN instead of individual hard disks... about the only thing I have to go into the data center for anymore is to rack a new server. Once it's physically in place, there isn't anything I can't do from just about anywhere in the world.