I have seen the pendulum swing back and forth several times over the last 20 years between dumb terminals and complete PC's with their own set of apps each.  Philosophically, the tension is between control and anarchy; cost is just brought in to justify your position.  If you love control, then dumb terminals are what you want.  Since this means things are centralized, it requires important hardware and backup systems to make sure it never goes down.  I think of this as the "nuclear aircraft carrier mentality" - sinking a nuclear carrier would be such a catastrophe (to both sides) that you need umpteen other ships to protect it from ever happening. 

I am more of an anarchist: I have faith in people's innate ability to muddle through okay for themselves. It doesn't bother me so much that people make mistakes and do dumb things; I try to set things up to blunt that, but other people's mistakes really not my responsibility.  I try to set things up more on the side of "boppo the clown" - the weighted blow-up figure that you can keep hitting forever and still have it come back without effort.  So I love being able to snapshot VMs before doing anything new; no longer are you risking rebuilding the whole machine every time you update/install something new.  VMs let me give people the leeway to shoot themselves in the foot without hurting others.  This is a great confidence-builder for people; they will come up with new ways of doing things far more often when the penalties for mistakes are not so severe.

The second thing I love about vms is that you can delete them. This is because you can afford to use them for just one or two things.  In the old days (pre-2006) when everything was on bare metal, you bought a big machine (aircraft carrier) and put all the business processes on it until there were too many to ever have the server go down.  In practical terms, security was non-existent, because no one could ever keep up with which task needed to do what after a while, and no one wanted to screw up some important process that everyone had forgotten needed rights to some files somewhere obscure.  So the longer a server lasted, the more extra rights were left over from previous business processes that no one even quite remembered any more.  But a VM you can delete when the main business process on it stops.  You will have had some security creep unless you really named your groups well, but that all goes away when you kill the VM.

I brought up the security aspect because it is an argument which can actually appeal to those worried about loss of control and proliferating VMs.  (I realize I probably have had a sheltered life, but I have only once been in a place that had more groups than people, with the groups controlling file access named so everyone knew what the main business process was and what the sub-task was.)  

--Ian Richmond

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Genny Engel
Sent: Monday, July 11, 2011 2:51 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Trends with virtualization

I *had* the entire computer lab go down when the network failed once.  That's when I switched it all to local desktops.  The security was way easier to manage with a hosted desktop (I basically didn't have to manage it at all) but we weren't set up to offer any alternative when the network server hiccupped.   It took me a lot of time to learn how to set up adequate security on an individual desktop, but once I got a good profile set up, I copied the image to all the other PCs and we were set.  There weren't any equipment cost differences either way, as I recall.

On moving things to the cloud, I'm still leery, especially after that Amazon thing a few months ago.
http://www.dailymail.co.uk/sciencetech/article-1379474/Web-chaos-Amazon-cloud-failure-crashes-major-websites-Playstation-Network-goes-AGAIN.html



Genny Engel
Internet Librarian
Sonoma County Library
[log in to unmask]
www.sonomalibrary.org
707 545-0831 x581

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Madrigal, Juan A
Sent: Monday, July 11, 2011 8:21 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Trends with virtualization

Its true what they say, history does repeat itself! I don't see how
virtualization is much different from
a dummy terminal connected to a mainframe. I'd hate to see an entire
computer lab go down should the network fail.

The only real promise is for making web development and server management
easier.

Vmware is looking to make thing easier with CloudFoundry
http://cloudfoundry.org/ along
with Activestate and Stackato http://www.activestate.com/cloud

I definitely want to take those two out for a test run. Deployment looks
dead simple.

Juan Madrigal


Web Developer
Web and Emerging Technologies
University of Miami
Richter Library





On 7/11/11 10:38 AM, "Nate Vack" <[log in to unmask]> wrote:

>On Sun, Jul 10, 2011 at 9:46 AM, Karen Schneider <[log in to unmask]>
>wrote:
>
>> My down-home-country-librarian observation that I always tack on (with
>> plenty of disclaimers) is "If virtualization were the answer, we'd see
>>more
>> of it by now."
>
>This.
>
>Various vendors have been pushing the "run all your desktops in the
>server room and export your I/O over ethernet" solution for a long
>time. Heck, X11 does exactly this, and it's as old as the original
>Macintosh.
>
>I suspect the problems partly come down to the end-user experience
>(performance, customizability, etc) and partly the fact that making an
>environment truly truly homogeneous is not completely realistic in
>most environments. Once you've gone the "everything will be
>virtualized" route, making one desktop setup just a little different
>(adding custom hardware, etc) is nearly impossible.
>
>So it winds up making more sense to find a solution that lets you
>cost-effectively manage lots of desktops, because that solves your
>actual business needs, not what IT wishes your business needs were.
>
>That, and the fact that the parts of desktop hardware that usually
>fail tend to be the things people spend time touching with their dirty
>fingers and pouring their coffee on. Disks and motherboards do fail,
>but if you've done your homework right, you should be able to swap
>another one in within minutes -- and thin clients can fail, too. So
>virtualizing doesn't get you out of the business of heading out to
>replace gear.
>
>And desktop PCs are dead cheap and you can buy them from anyone.
>Custom virtual solutions usually want you to source from one vendor.
>
>That said: we do love virtualization for delivering Windows apps to
>Macs and Linux clients. Sometimes, there's just no substitute for SPSS
>on Windows.
>
>-n