The primary reason why most laptop vendors don't offer a hard drive in place of the optical drive is power consumption. Optical drives use basically nothing when they're sitting there idle, and since most optical drives today are used about as much as floppy drives were used in the mid 1990's (i.e., virtually never, only to install software, and even that is going away with Internet delivery of software), that means that they can spec the rest of the laptop around a lower power draw, which allows them to claim a longer battery life and allows them to use a smaller fan to cool the laptop and a smaller brick to power the laptop and allows you to actually set the laptop on your lap without scorching your lap and requiring a trip to the surgery suit for skin grafts. The large desktop replacement laptops from Dell and HP (amongst others) actually do have space for multiple hard drives, but those are more portable desktops than laptops -- you aren't going to unplug one of those and walk across the lab with it to plug into a different network to sniff for a rogue machine that's brought your installation to a crawl, they sit on a desk and stay there, with short excursions to the car and home perhaps, because they are large, bulky, hot, will last maybe 20 minutes on battery power, and have power bricks the size of concrete blocks.

Given that, if you need a lot of space in a single 2.5" form factor package to fit into, say, a current Apple Macbook Pro (where Apple very highly optimizes the power consumption and the OS really doesn't deal well with you removing the optical drive and putting in a second hard drive using a third-party bracket, it won't go to sleep correctly much of the time), the hybrid approach makes a lot of sense. The primary issue with the prior generation of the Momentus XT in that application was a) it topped off at 500GB, and b) it consumed more power than a 750GB 7200 RPM Western Digital Black drive. The current generation solves the capacity problem, but I'll need to take a close look at power consumption, because power budgets in many modern slim (i.e., actually portable) laptops are quite tight.

The core problem with SSD's is write speed on workloads that have a large number of small updates. My testing on the older 500GB Momentus XT showed that in general it had better write speed doing, e.g., a Fedora install, than the 80GB Intel SSD that I benchmarked it against (same generations of product here, about a year ago), due to the large number of small updates that the non-SSD-aware EXT3/4 filesystems do during the course of installing oodles of RPM's. Because the Momentus only caches *read* requests in the SSD (write requests flow right through it, other than to invalidate anything in its internal cache that is getting written), writes went through at full 7200 rpm 2.5" hard drive speed. In general when I benchmarked writes on similar-generation 7200 rpm 2.5" hard drives and SSD's, the hard drives ended up faster for virtually all real-world workloads, so the end result of my benchmarking was that on real-world workloads the hybrid drive was faster at reads than a hard drive (primarily due to SSD-cached filesystem metadata) and faster at writes than an SSD.

Please not that I have *not* tested the current generation of SSD's and Momentus XT. Just that it's baffling that the Momentus XT never seemed to really get any traction in the marketplace, given the performance advantages of the approach for many real-world tasks.

Wow, great job reciting Fox News talking points. Too bad they have nothing to do with reality. I know what my local school districts' pay scale is. I know what I get paid as a top software engineer. I know what my benefits are, and I know what my local school districts' benefits are. Here's some facts:

* I get free health, dental, life, and disability insurance as a software engineer. Teachers in the local district pay 100% of the cost of their health insurance.
* The top pay scale for a teacher with 20 years experience and an advanced degree in my district is less than half of my salary as a software engineer.
* Tenure rights for public school teachers are based on Constitutional due process and as long as due process is followed, any teacher can be fired for any *valid* reason (i.e., not just because the principal doesn't like gays or Mormons). Any principal who says he has a problem getting rid of an incompetent teacher is either himself incompetent or is lying to you, there is due process to follow but in every state of the nation an incompetent teacher can be fired regardless of tenure.
* Tenure rights don't have anything to do with layoffs. 40% of teachers in some of our local districts got layoff notices this year. A large percentage of those teachers had tenure.
* I will receive more money from Social Security when I retire (due to maxing out the contribution limit each year) than the teachers in the top pay scale at my local district will receive from CALPERS. And because of the double-dipping penalty in the Social Security formula, they'll never make more combined pension and Social Security than I get from Social Security when I retire.

Really, with a disrespectful and ignorant attitude being the norm, why *would* I want to teach? So people like you could spit on me for doing a job that's ten times harder than software engineering? Been there, done that. No thanks.

I am wondering what in the world you are talking about. During the three years I was teaching, a) my highest salary was the munificent sum of $21,800 per year (roughly $40K/year in today's dollars), b) I paid 100% of my health insurance costs (NO district subsidy of the cost), and c) the retirement benefit was 40% of my ginormous salary if I managed to survive 30 years without stroking out, being knifed or shot by one of my students, or being thrown under the bus by a school administrator upset that I cared about whether my students learned or not (and note that I did NOT pay into Social Security and if I had managed to get Social Security via some other job, there's a "double dipper" penalty in the SS formula that would take most of that away from me). In the years since I switched to doing software engineering rather than teaching mathematics I've sometimes worked 60+-hour weeks and multiple all-nighters but never worked anywhere near as hard as I worked as a teacher and get paid more than three times as much money than a teacher. If you paid me the same six-figure salary I make as a senior-level engineer I still wouldn't go back, because the job is thankless, never-ending, and utterly exhausting both physically and intellectually if you're doing it right. My hats off to those teachers who stay on the job and do it well, year after year, because the fools who criticize such teachers have not a clue.

BTW, once you get above 35 students in a classroom, it becomes simply impossible to manage in a way conducive to learning. Above 35 students learning starts dropping off rapidly, past 40 it's just baby-sitting and make-work. Teachers know this the hard way. The fact that politicians and parents talk about 40+ student classrooms as if that were some reasonable solution to the cost of running public schools tells me that either a) they don't care about education, they just want free babysitting to keep kids off the streets, or b) they're clueless cretins who need to be drummed about the head with a clue stick. That is all.

Perhaps Media Molecule should think about hiring some of the 50%+ of UK Computer Science graduates who cannot find a job in the field? When I see statistics that say that 70% of Computer Science graduates are not working in the field five years later, I call balderdash on the notion of a shortage of software engineers in the UK. If Media Molecule truly believes that 50%+ of UK Computer Science graduates are unqualified to write software, it sounds to me as if their beef is with the universities that credential people not worthy of said credential, not with anything happening at the primary school level.

I saw my first computer at age 17. I've been making a living writing software or doing other related things for over 20 years now and while I'm no Linus Torvalds, I still don't have any problem finding a job when I need one and making significant contributions everywhere I go. What differentiates those who will be good at writing software from those who will never be has nothing to do with how young you are when you encounter computers, and everything to do with your ability to think in a logical and straightforward manner. I would much rather see our schools teach thinking skills than computer skills. Thinking skills are useful for other things (say, in figuring out which politicians are lying to you and thus you should vote for the one *not* lying to you, for example), while skill writing computer programs is useful only for a small set of problems. I don't write algorithms to go grocery shopping or change the cat box. Just sayin'.

One thing I'll note is that MIT MACLisp had a functional compiler that compiled all the way down to machine code before most of Slashdot's readers were born. The original MIT Multics Emacs was written in MACLisp, I looked at the resulting ALM (Assembly Language Multics) from the compilation process for a few functions just to see how well it compiled, and it was pretty close to the output I saw from the PL/1 compiler, which had an excellent optimizer for that era. There's nothing inherent about Lisp that makes it impossible to compile and optimize, Bernie Greenberg and David A. Moon certainly proved that.

That said, I'm of the opinion that the age of extension languages embedded into applications is over. The extension language paradigm explicitly limits the extension language to manipulating a single application, when what we have open on our modern desktop is dozens of applications and we'd like to create something new from all of them. What is needed, instead, is a universal interface exported by applications to use to script applications. Think Windows PowerShell rather than Emacs Lisp -- the shell lives outside the application and calls a defined application API to perform actions. SOAP/XML-RPC/REST are far more important to the future of scriptability than some archaic concept from the 1960s and 1970's, if I implement one of those interfaces to the core functionality of my application I can write my extensions in *anything* -- Perl, Java, Python, you name it. The problem of course is that SOAP/XML-RPC/REST are also horrendously inefficient, surely we can do better than marshalling and demarshalling everything to/from XML or JSON. Still, I present this as a conceptual thought -- though I might point out that the Amiga *almost* managed something similar with AREXX (theoretically it was possible to use the "AREXX port" to control Amiga applications from other scripting languages, though it was rarely done).

One thing I'll point out is that RDP (using the current Windows clients and servers) is extremely efficient compared to "network-transparent" X. When I use Wireshark to look at what's on the wire, opening a Firefox window on Windows and displaying it to my desktop uses roughly the same bandwidth as X's "network transparent" windowing, but happens much quicker due to latency -- the X client is issuing multiple requests to the X server then *waiting for the response* before continuing on. Furthermore, RDP is transferring ONLY THE CHANGED BYTES, *not* the whole screen, so the notion that RDP transfers the entire screen every time the screen updates on Windows is just plain nonsense. Meanwhile, X is not only transferring the changed bytes, but only doing so after a series of *synchronous* commands. The net result is that the 500ms total turnaround time between my house and my work ends up very painful with "X", while is virtually unnoticeable with RDP.

From a theoretical point of view, it all makes sense. There is a theoretical minimum number of bytes which must be sent to update a window from its old state to its new state. This occurs whether the detection of which bytes need sending is via screen scraping or via the application directly telling the graphics library "these are the bytes that have changed". Recent revisions of RDP have gotten *very* efficient at approaching this theoretical minimum. Standard "X" doesn't even try -- if an application draws a new graphic and tells "X" to display it, X sends the entire new graphic to the remote end, *even if only a few pixels have changed*. (And yes, I know there is such a thing as FreeNX etc., but that's add-ons that are not part of X proper, attempting to work around these performance limits of X).

I guess what I'm saying is that if Wayland chooses to use an RDP-like screen scraping protocol for remote display rather than doing "network-transparent" windows like X, there's no theoretical reason why it cannot be efficient. Pixels are pixels, in the end, and the minimum number of pixels needed to refresh a window are identical whether the pixels are being derived via screen scraping, via screen scraping with hints based on GUI library calls (what RDP does), or via the application telling the display protocol "these are the pixels that have changed". The only difference is that the last requires every application to be written to efficiently tell the display protocol "these are the pixels that have changed" -- and we already know that this isn't so for many major "X" applications, which are far from efficient in that regard.

Do note that my development platform is Fedora 15 / Gnome 3 running KVM VM's of the various target distributions for the product, so I'm clearly familiar enough to use it every day. But I suppose yes and no, because I stopped my investigations into replacing ESXi with KVM or Xen when I ran into a couple of show-stopper issues. The first one was with KVM stability, basically there is a feature we needed that KVM supposedly supports, but KVM regularly kernel panics if we try to use it. I tried at least three different distributions -- Fedora 15, RHEL6, and the latest Ubuntu -- and ran into the same problem with each of them. The second was with distribution Xen support. The only distribution that had a version of Xen new enough to support the functionality we needed was OpenSUSE 11.3, hardly what I would call a stable distribution, and then OpenSUSE 11.4 broke Xen. Any other distribution would have required that we create a new DOM0 kernel and update the Xen runtime utilities and QEMU in DOM0 (note that Xen uses QEMU for its HVM virtualization). *PLUS* write an entirely new virtualization management infrastructure, since libvirtd doesn't support the functionality of Xen that we needed.

Meanwhile ESXi 4.1 Just Works(tm). An attribute that I appreciate more and more as I get older (thus why this is being typed from a Macbook Pro, the only laptop that doesn't annoy me with a palm-surfing trackpad, clunky keyboard, or ridiculously short battery life). So, let's see, where do I want to put several man-months of my time -- into creating actual product that can be sold, or into futzing with Xen? In the end it's a no-brainer, putting the man-months into the product results in a more functional and faster product, whereas putting the man-months into Xen in order to get away from ESXi is just a cheaper product, not a better one -- and price isn't our selling point, functionality and performance is.

A new iscsi volume for each VM is certainly one approach, and actually that's sort of what we're doing with the ESXi VM's -- they have a boot disk on VMFS on an iSCSI volume, and the VM then mounts an iSCSI volume off the SAN for their actual data. And you are certainly correct that it is *technically* feasible to do it with KVM, I have in fact done it -- for a one-off prototype. The pain I endured doing that basically told me that there was no way in BLEEP that this was a supportable solution in the field deployed at customer sites that lack dedicated IT resources.

The ESX console, BTW, isn't necessary for a lot of things if you enable the ssh on your ESXi hosts. vim-cmd is your friend. With an appropriate oem.tgz you can even set up your keys so you can script it from outside. The only time I fire up the VSphere GUI in a VirtualBox Windows VM on my Macbook Pro is when I need to see the actual console (as vs. use rdesktop to a Windows VM or vnc to a Linux VM).