I may be confused, but... are you questioning the whole idea of hypervisors on servers at all?

There are a lot of reasons for that. One of the simple reasons is that it's cheaper. When you're working in IT, you often have a bare minimum of hardware you have to buy with each server in order to be safe, e.g. dual hot-plug power supplies, hot-plug RAID enclosures and drives, lights-out management, etc. Because of that, each server you buy is going to end up being about $4k minimum, and the price goes up from there. If you have to buy 5 servers, you might be spending $25k even if they aren't powerful servers. However, you may be able to run all of those servers on a single server that costs $10k. In addition to the initial purchase being less, it will also use less power, take up less space, and put out less heat. All of that means it'll be cheaper of the long term. It will also require less administration. For example, if an important firmware update comes out that requires a certain amount of work to schedule and perform, you're doing that update on 1/5 of the servers you would be doing it on. Oh, and warranty renewals and other support will probably be cheaper.

So more directly addressing the question, which I think was, "Why not just buy one big server and install everything on it?" There are lots of reasons. I think the most important reason is to isolate the servers. I'm a big believer in the idea of "1 server does 1 thing", except when there are certain tasks that group well together. For example, I might have one server run the web and database services for multiple web apps, and another run DNS/DHCP/AD, but I don't really want one server to do both of those things.

And there are a few reasons for that. Security is a big one. There are services that need to be exposed the the internet, and then there are services where I don't want the server running them to be internet-accessible. Putting all of those services on the same physical server creates a security problem, unless I virtualize and split the roles into different virtual machines. Or it may be that I need to provide administrative access to the server to different groups of people, but each can't have administrative access to each other's data. Hosting providers are a good example of this: You and I could both be hosting our web application on the same physical machine at the same hosting provider, and we both might need administrative access to the server. However, I don't want you having access to my files and you don't want me having access to yours.

Another big reason you'll want to isolate your servers is to meet software requirements. I might have one application that runs on Windows, but is only supported up to 2008R2. I might have another application or role that needs to run on Linux. I might have a third role where I really want to use Windows 2012R2 to take advantage of a feature that's unavailable in earlier versions of Windows. How would I put those things on the same server without using virtual machines?

Isolating your servers is also good because it tends to improve stability. Many applications are poorly written can cause crashes or security problems, and keeping them on their own VM server prevent those applications from interfering with other applications running on the same physical hardware. I can even decide how to allocate the RAM and CPU across the virtual machines, preventing any one application from slowing down the rest by being a resource hog.

Aside from all that, there are a bunch of other peripheral benefits. For example, with virtual machines, you have more options for snapshotting, backing and replication, restoring to dissimilar hardware, etc. With traditional installs, I need special software to do bare-metal restores in case something goes wrong, and the techniques used in that software often doesn't work quite right. If virtualized machines, I just need the VM's files copied to a compatible hypervisor, and I can start it up wherever I need to. With the right software, I can even move the whole VM live, without shutting it down, to another physical server.

There are probably a few other benefits that I'm just not thinking of off the top of my head.

I would generally disagree. I could see having some weird old piece of hardware that is completely isolated from the internet running an old OS for a good long time simply because there's no reason to upgrade, but then again, 10 years is already a good long time.

Among most users, the problem is usually just poor planning and bad budgeting. Someone spent a bunch of money buying a solution that they then don't have the money to maintain properly. That's how you end with with businesses running internal custom apps that only run on IE6. That's how you end up with businesses relying on some junky old piece of hardware that constantly breaks down and nobody can fix. That's how you end up needing to rebuild your system from scratch because there's no upgrade path-- the upgrade path from v3 to v7 requires you upgrade through v4, v5, and v6, but v4 is completely unavailable now.

If you're spending 50k in hardware this year, you should have an estimated lifetime for that hardware, a maintenance plan for the lifetime of the hardware, and you should be budgeting for the replacement of the hardware once the lifetime expires. I don't have much sympathy for businesses that bought hardware 10 years ago with no maintenance plan or budget for replacements. If you're running your business and you can't afford to maintain and eventually replace business-critical systems as needed, then your business model isn't sustainable.

I'm not a programmer, but it seems to me that different programming strategies are required for different situations. In the case of someone writing a kernel or other low-level code, you may want to optimize the hell out of the code even if it makes things hard to read. The idea here is that whoever is working on the code should have a pretty good idea of what they're doing and could read the difficult code, but performance is among the top priorities. In that case, there is a certain elegance in creating code that's super-efficient even if it's apparently complex.

However, for most other programs I would agree with you-- one of the major priorities should be to keep the code simple and easy to read, keeping in mind that you want it to be as easy as possible for another programmer to come in after you and make updates without breaking anything. In that case, I'd think of "elegant code" as something that does powerful things while being almost transparent to a neophyte.

Even so, it still means that the NSA doesn't just have it sitting on their servers where they can look up the data they promised they wouldn't. They need the approval of the rubber-stamp court, but at least this way they actually need that approval rather than just casually logging into their own servers. I'm not claiming it's sufficient reform, but it would be a meaningful reform. What has been disturbing about the Snowden revelations is not only that they're spying on us without oversight, but that it's apparently also easy for an individual employee of the NSA or even an outside contractor to pull whatever data they want without even the rubber-stamp court approval.

Notice the second clause to that sentence that you quoted? "...so long as they are able to get a warrant that is in keeping with the 4th amendment." What I'm saying is I don't have a problem with the FBI or local police department tapping phones or gathering phone records, so long as they are following traditional 4th amendment rules. That includes that they need to have a specific target and that they're investigating for a specific crime.

Yet they're already providing the records, so it can't be as hard as you're making it sound. Part of the reason I put in that condition is that I don't think the same rules translate very well to email, where tracking and storing email might create an undue burden for some providers. However, there are many circumstances where the government already requires organizations to keep email and chat logs for some retention periods.

If the NSA has to go through two other entities (a court and a private business) in order to get the information, then it greatly increases the difficulty of abuse. It may not make a difference for when the NSA is operating within the rules, but it makes it harder to break the rules, which is largely what we want.

No, I think that depending on the implementation, it's a huge difference. I honestly don't have a problem with law enforcement collecting phone records, so long as they are able to get a warrant that is in keeping with the 4th amendment. I also don't have a problem with them saying to phone providers, "You must keep the phone records we might solicit for a period of X months, in case we do solicit them, and you must have the infrastructure to provide that information in a timely manner." Assuming it's easy, reasonable, and effective for phone carriers to do that, I don't really have a problem with the idea.

And I do think there's a huge difference between that and the NSA collecting the data themselves. The problem I have with the NSA spying is specifically that they collect and store this information on their own servers. The metaphor I've used to describe my problem with the NSA wiretapping is that the physical equivalent would be as though they regularly rifled through your belongings and recorded potential evidence, and then say, "But that's not a 4th amendment violation because we promise not to look at or think about this evidence unless we think you've done something wrong!" To that I say, no, you need to get the warrant first, and then you can collect evidence. You can't collect evidence first and then later get a warrant to use that evidence, since that system is too easy to abuse.

Of course, they should still have to get a real warrant, and not through some secret court where the charges and proceedings are all hidden from the public.

It *raises* the question. "Begging the question" is different.

Sorry. Otherwise you make an excellent point.

Or more to the point: You can't just charge Walmart trucks because you own Target, and you want to use your ownership of the road as leverage against your competitors.

That's the real issue.

I'm not sure you're criticism is valid. He said, "Science is the willingness to relegate that evidence to be less significant than what some people want it to be."

I don't think he was saying that valid evidence would be dismissed because it didn't fit the theory, but that it would be admitted to be less significant if it's found to insufficient to support the theory.

Yes, I do understand. Both of those arguments are very stupid, though. What you're saying then is, "It won't help our business at all, and it won't give us better options when things fail. I'm just personally preparing an excuse for myself and my own decisions." You're trying to cover your own personal ass, and not really covering your business's ass.

I like LibreOffice, but there are some advantages to Google Apps. First, it's integrated with "cloud storage" so that you can easily share the files or access them anywhere. Their "office suite" is also a web app, meaning you can use it on basically any internet-connected computer with a web browser, without installing or downloading anything. Third, Google Apps has the nice collaboration feature that multiple people can be editing the same document at the same time.

I wouldn't suggest that it's absolutely better than LibreOffice. Having your documents "in the cloud" could be considered a disadvantage, depending on your use case. However, there are certainly situations where I'd rather use Google Apps than LibreOffice.

Working in IT, I hear a lot of argument 1 and argument 2. But then I have to ask those people, "When's the last time you sued Microsoft when things went bad? When's the last time you got official support for a Microsoft product?"

Theoretically there's someone to sue, but if you aren't in the practice of suing software vendors whenever things go wrong, it's not much of an advantage.

Apple actually does have tools to provision and manage their devices. They make tools to do that, and 3rd parties make tools for it. Many schools in fact do mass deployments of the sort you're talking about. It's not without its headaches, but hey... what is?

And though they're not a medical conspiracies, quite a few 'conspiracy theories' have turned out to be true in the past few decades. We've found out in recent years that our government *does* have secret prisons where they torture people. The NSA *does* read your email and tap your phone. People within the finance industry *do* apparently help to torpedo the economy so that they can make money from the collapse. Private prisons *do* raise money for candidates who support excessive prison terms and mandatory sentencing. The Republican party *does* have meetings where rich funders talk to the presidential nominee about how poor people are parasites and rich people deserve more money. Wasn't there something about the CIA selling crack?

All of these conspiracy theories have turned out to be more or less real. It doesn't seem to crazy to think that the pharmaceutical industry has engaged in some kinds of similarly insane shenanigans.

Yeah, I've seen enough Java software that no only requires 1.4 or 1.5 of the plugin, but might require a specific version (e.g. 1.4.2_23) or else it simply won't work. Earlier or later, it won't work. Now maybe the developers who made that app are completely retarded, but I've seen enough of them that I think there must be some fault in the approach Sun took in the first place.

It's definitely not the case that if you install the latest Java plugin, it will support all code written for prior versions.