2013-04-29
My practical problem with preconfigured virtual machine templates
In comments on my entry on some VM mistakes I made, people suggested setting up template VM images that I would clone or copy to create live images. With that, every time I wanted a new VM I'd at least have a chance to think about its settings and if cloning was easy enough I'd avoid the temptation to reuse an existing VM for some theoretically quick (and not very important) test.
As it happens I've sort of started to toy with this idea but I think there's a practical roadblock in our environment: OS package updates. Most of the actual machines that I deal with (and thus most of the test images I build) are not frozen at a point in time but instead are continuously kept up to date with Ubuntu's package updates. If I have base starter images I need to either keep those base starter images up to date or immediately apply all of the pending updates after I clone the base image to make a new working VM. Neither of those options seem entirely attractive, although I should probably give it a real try just to see.
(There is also the subtle issue that cloning a preconfigured base image and then updating the packages is not quite the same thing as a from-scratch rebuild. If I want to be absolutely sure that a machine can be rebuilt from scratch, I'm not sure I trust anything short of a from-scratch build. But I could probably save a bunch of time by doing the preliminary build testing with cloned images and only doing a from-scratch reinstall in the final test run.)
PS: every so often we make a meaningful change to the base install scripts and system; such changes would force me to rebuild all of the preconfigured images (well, strongly push me towards doing so). But I suppose those are relatively rare changes so I'm kind of making excuses to not try this.
(Which argues that I should try it, if only to understand what I really don't like about the idea instead of what I tell myself my concerns are. Yes, I'm sort of using my blog to talk out loud to myself.)
Sidebar: if you're working on VMs, give yourself more disk space
One of the smartest things I did recently for encouraging this sort of playing around with VMs is that I threw a third drive into my office workstation (to go along with the main mirrored system disks). Honestly, I should have done this ages ago; having to worry about how much disk space I had to spare for VMs is for the birds when 500 GB SATA drives are basically popcorn.
(The drive is unmirrored and un-backed-up, but if it dies I'll just lose expendable VM images and related bits and pieces. I keep the important VMs on my mirrored drives.)
My view of ARM versus other RISCs
Way back in my second entry on x86 winning against RISC a commentator asked:
And now you need to write
whohow ARM up-ending this orderly structure of the universe.
Writing about this is hampered by my lack of knowledge of the details of ARM history, but after some reading I have my theory: ARM has been successful where other RISCs weren't because from the first it was targeted differently.
(This is not a matter of architecture, as I initially thought before I started reading. The original ARM ISA was a bit odd but no more so than other RISCs.)
The simple version is that all other RISCs saw themselves as competing for the performance crown (against each other and then x86); they quite carefully and quite consciously engineered for performance and then tried to sell their CPUs on that basis. This was a sensible decision because performance was where the money was (and also because there clearly was a lot of room to improve CPU performance). It just happened that Intel was able to spend enough money to scale x86 up enough to crush everyone else with good enough performance for not too much money (and with the other advantages x86 gave them).
Acorn (where ARM started) doesn't seem to have seen itself as building a high-performance CPU. Instead it wanted to build a CPU that met its needs as far as features went, performed well enough, and was simple enough that a small company could design it (after all, early RISCs were designed by a class of graduate students). This gave ARM different design priorities and, just as importantly, meant that Acorn (and later ARM Ltd) didn't spend huge amounts of money on R&D efforts to crank performance up to compete with other CPUs (a race that they would have been doomed to lose). Free from chasing performance at all costs, ARM was both able and willing to adopt its design for people who were interested in other needs.
(I have no particular insight about why ARM won out over similar higher end low-power CPU efforts of the early 1990s. However two things seem worth noting there. First, all of the really big designs seem to have been RISC, which makes sense; if you're building a new embedded CPU, you want something simple. Second, both the Intel i960 and the AMD 29k were made by companies that were also chasing the CPU performance crown; among other things this probably drained their design teams of top talent.)
It's worth noting that part of this difference is a difference in business priorities. One reason that ARM is so widely used is that it is dirt cheap and one fundamental reason that it's dirt cheap is that ARM Ltd licenses designs instead of selling chips. This means that ARM Ltd has made a fraction of the profit that, say, Intel has made from their CPUs. Licensing widely and cheaply is an excellent way to spread your CPUs around but a terrible way to make a lot of money.
(Of course losing the CPU performance race was an even worse way of making money for all of the other RISC companies. But if the RISC revolution had actually worked out, one or more of those companies could have been an Intel or a mini-Intel.)