ORM

I'm going to speak heresy here: Object-Relational Mappers such as Hibernate are evil. I say that as someone who wrote an object-relational mapper back in 2000 -- the BRU Server server is written as a master class that maps objects to a record in a MySQL database, which is then inherited by child classes that implement the specific record types in the MySQL database. The master class takes care of adding the table to the database if it doesn't exist, as well as populating the Python objects on queries. The child classes take care of business logic and generating queries that don't map well to the ORM, but pass the query results to generators to produce proper object sets out of SQL data sets.

So why did this approach work so well for BRU Server, allowing us to concentrate on the business logic rather than the database logic and allowing its current owners to maintain the software for ten years now, while it fails so harshly for atrocities like Hibernate? One word: complexity. Hibernate attempts to handle all possible cases, and thus ends up producing terrible SQL queries while making things that should be easy difficult, but that's because it's a general purpose mapper. The BRU Server team -- all four of us -- understood that if we were going to create a complete Unix network backup solution within the six months allotted to us, complexity was the enemy. We understood the compromises needed between the object model and the relational model, and the fact that Python was capable of expressing sets of objects as easily as it was capable of expressing individual objects meant that the "object=record" paradigm was fairly easy to handle. We wrote as much ORM as we needed -- and no more. In some cases we had to go to raw relational database programming, but because our ORM was so simple we had no problems with that. There were no exceptions being thrown because of an ORM caching data that no longer existed in the database, and the actual objects for things like users and servers could do their thing without worrying about how to actually read and write the database.

In the meantime, I have not run into any Spring/Hibernate project that actually managed to produce usable code performing acceptably well in any reasonable time frame with a team of a reasonable size. I was at one company that decided to use the PHP-based code that three of us had written in four weeks' time as the prototype for the "real" software, which of course was going to be Java and Spring and Hibernate and Restful and all the right buzzwords, because real software isn't written in PHP of course (though our code solved the problem and didn't require advanced degrees to understand). Six months later and a cast of almost a dozen and no closer to release than at the beginning of the project, the entire project was canned and the project team fired (not me, I was on another project, but I had a friend on that project and she was not a happy camper). I don't know how much money was wasted on that project, but undoubtedly it hurried the demise of that company.

But maybe I'm just not well informed. It wouldn't be the first time, after all. So can anybody point me to a Spring/Hibernate project that is, say, around 80,000 lines of code written in under five months' time by a team of four people, that not only does database access but also does some hard-core hardware-level work slinging massive amounts of data around in a three-box client-server-agent architecture with multiple user interfaces (CLI and GUI/Web minimum)? That can handle writing hundreds of thousands of records per hour then doing complex queries on those records with MySQL without falling over? We did this with BRU Server, thanks to Python and choosing just enough ORM for what we needed (not to mention re-using around 120,000 lines of "C" code for the actual backup engine components), and no more (and no less). The ORM took me a whole five (5) days to write. Five. Days. That's it. Granted, half of that is because of Python and the introspection it allows as part of the very definition of the language. But. Five days. That's how much you save by using Spring/Hibernate over using a language such as Ruby or Python that has proper introspection and doing your own object-relational mapping. Five days. And I submit that the costs of Spring/Hibernate are far, far worse, especially for the 20% of projects that don't map well onto the Spring/Hibernate model, such as virtually everything that I do (since I'm all about system level operations).

-ELG

On spinning rust and SSD's.

I got my Crucial M4 512GB SSD back for my laptop. It failed about three weeks ago, when I turned on my laptop it simply wasn't there. Complete binary failure mode -- it worked, then it didn't work. So I took it out of the laptop, verified in an external USB enclosure that it didn't "spin up" there either, installed a 750Gb WD Black 7200 rpm rust-spinner that was in my junk box for some project or another, and re-installed Windows and restored my backups. Annoying, but not fatal by any means. I've had to get used to the slow speed of spinning rust again versus the blazingly fast SSD, but at least I'm up and running. So this weekend I get to make another full backup, then swap out the rust for the SSD again.

At work I've had to replace several of the WD 2TB Enterprise drives in the new Linux-based infrastructure when smartd started whining about uncorrectable read errors. When StorStac got notification of that sort of thing it re-wrote the sector from the RAID checksums and that usually resolved it. The Linux 3.8 kernel's md RAID6 layer apparently doesn't do that, requiring me to kick the drive out of the md, slide in a replacement, fire off a rebuild, and then haul the drive over to my desktop and slide it in there and run a blank-out (write zeroes to the entire drive). Sometimes that resolves the issue, sometimes the drive really *is* toast, but at least it was an analog error (just one or two bad places on the drive), not a complete binary error (the entire drive just going blammo).

SSD's are the future. The new COW filesystems such as ZFS and BTRFS really don't do too well on spinning rust, because by their very nature they fragment badly over time. That doesn't matter on SSD's, it does matter with rust-spinners, for obvious reasons. With ZFS you can still get decent performance on rust if you use a second-level SSD cache, that's how I do my backup system here at home (which is an external USB3 hard drive and an internal SSD in my server), BTRFS has no such mechanism at present but to a certain extent compensates by having a (manual) de-fragmentation process that can be run from time to time during "off" hours. Still, both filesystems clearly prefer SSD to rotational storage. It's just the nature of the beast. And those filesystems have sufficient advantages in terms of functionality and reliability (except in virtualized environments as virtual machine filesystems -- but more on that later) that if your application can afford SSD's, that alone may be the tipping point that makes you go to SSD-based storage rather than rotational storage.

Still, it's clear to me that, at this time, SSD is still an immature technology subject to catastrophic failure with no warning. Rotational storage usually gives you warning, you start getting SMART notifications about sectors that cannot be read, about sectors being relocated, and so forth. So when designing an architecture for reliability, it is unwise to have an SSD be a single point of failure, as is often done for ESXi servers that lack hardware RAID cards supported by ESXi. It might *seem* that SSD is more reliable than rotational storage. And on paper, that may even be true. But the reality is that because the nature of the failures is different, in *reality* rotational storage gives you a much better chance of detecting and recovering from a failing drive than SSD's do. That may, or may not be important for your application -- in RAID it clearly isn't a big deal, since you'll be replacing the drive and rebuilding a new drive anyhow -- but for things like an ESXi boot drive it's something you should consider.

-ELG

Setting up bridging and vlans in Fedora 13

In the previous half of this, I talked about how Fedora's NetworkManager interfered with complex configurations, and discussed how to disable it. Now I'll show you how to define a network that consists of:

• Two Ethernet ports, bridged:
  • eth0 - to public network
  • eth1 - to internal network transparently bridged to public network
• VLAN 4000 on internal network, *NOT* bridged to public network
• Bridge to VLAN 4000 for my KVM virtual machines to connect to, *NOT* bridged to public network.

Now, to do all of this we take advantage of an interesting feature of the Linux networking stack -- bridges aren't "really" bridges. If a packet arrives at the physical eth1 hardware, it gets dispatched to either eth1.4000 or eth1 based upon the VLAN tag. Only those packets that are dispatched to eth1 actually make it onto the bridge to go to eth0. In other words, the Linux bridging code is a *logical* bridge, not a *physical* bridge -- it is not the physical ports that are connected, it is the logical Ethernet devices inside the Linux networking stack that are connected, and eth1.4000 and eth1 just happen to be connected to the same physical port but otherwise are logically distinct with the dispatching to the logical Ethernet device happening based upon the VLAN header (or lack thereof).

So, here we go:

/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
BRIDGE=br0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE=eth1
BRIDGE=br0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth1.4000:
VLAN=yes
DEVICE=eth1.4000
BRIDGE=br1
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-br0:
DEVICE=br0
TYPE=Bridge
USERCTL=yes
ONBOOT=yes
BOOTPROTO=dhcp

/etc/sysconfig/network-scripts/ifcfg-br1:
DEVICE=br1
TYPE=Bridge
USERCTL=yes
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.22.2
NETMASK=255.255.255.0

And there you are. Two bridges, one of which has a single port (eth1.4000) for virtual machines to attach to, one of which bridges eth0 and eth1 so that the machine plugged to eth1 on this cluster can also make it out to the outside world (via that bridge) as well as having the VM's on both systems communicate with each other (via the bridge attached to eth1.4000 on the 192.168.22.x network). Internal VM cluster communications stay internal, either within br1 or on VLAN 4000 that never gets routed to the outside world (we'd need an eth0.4000 to bridge it to the outside world -- but we're not going to do that). This does introduce a single point of failure for the cluster -- the cluster controller -- but it's one that's managable, if we need to talk to the outside world after the cluster controller dies we can simply plug in the red interconnect cable to a smart switch that blocks VLAN 4000 rather than into the cluster controller if the cluster controller goes down.

Now, there's other things that can be done here. Perhaps br1 could be given an IP alias that migrates to another cluster controller if the current cluster controller goes down. Perhaps we have multiple gigabit Ethernet ports that we want to bond together into a high speed bond device. There's all sorts of possibilities allowed by Red Hat's "old school" /etc/sysconfig/network-scripts system, and it won't stop you. The same, alas, cannot be said of the new "better" NetManager system, which would simply throw up its hands in disgust if you asked it to do anything more complicated than a single network port attached to a single network.

-ELG

And the winner is...

The iPhone 4.

The Droid X is an awesome piece of hardware. But my experiments with the various Android-based phones said to me that Android is still a work in progress. Each of them had odd bits of user interface that seemed unfinished or clunky or just plain badly thought out. After my brief experience with the Google hiring process it's pretty clear why that's true -- Google's hiring process, other than for a few superstars, has a built-in bias towards young mathematical types who recently took an algorithms course in college and also has a built-in filter to get rid of those of us who've been around long enough to know what we like to do and are good at doing. Youth has its advantages, but also its disadvantages -- young arrogant mathematical types rarely give much thought to user experience.

Which reminds me of an incident at a prior job. Me and my office-mate combined had maybe 15 years experience in the industry at the time, had actually used our product in production environments before joining the company that made it, and were now working on taking it to the next level with a new GUI and a new management infrastructure around our core data engine to make it easier to use in modern network environments. Our boss had about 20 years experience in the industry. So my boss assigns one of these young arrogant math PhD types to mock up a user interface for our project, we gave him the basic architecture and workflow and told him "make it easy to use." So he produces this mock up and calls me in to take a look at it and I scratch my head because I can't make heads or tails of what he's done, it isn't oriented around the workflow of any site admin that I've ever encountered. I call in my office-mate. He can't make heads or tails of it either. We ask this young brilliant mathematical type just out of college questions about how to do various site-admin-ish kinds of things, and he takes us on this long complicated set of procedures through a number of incomprehensible dialogs. My office-mate and I say "This doesn't seem like an easy to use interface for site admins." He goes, "but it's obvious! It's simple!"

So we look at each other, think, "hmm, he seems really sure about this, maybe it's just us," and call in our boss, just telling him "You have to look at this" but not why we want him to look at it. By this time we have 35 years of experience in the room, people who've actually used the technology in question in production environments. He runs through the same thing as we did, and comes to the same conclusion. By this time the arrogant young mathematical type is in pure snit mode. How *dare* we question his impeccable user interface! I explain to him that there's 35 years of experience in this room who've actually used the technology in production environments, so if we can't make heads or tails of it our customers will be utterly lost. "Then your customers are idiots!" he shouts.

Indeed. Indeed. But they are *paying* idiots. Which is what Apple understands. The customer may not always be right, but the customer is what keeps you in business, and customers want something that doesn't require a math PhD to understand or use. And in that regard, the iPhone despite its occasional glitches is still the one to beat, and Android still has a lot of growing up to do. As for that math PhD guy? Eventually after another design disagreement months later (on internals, not GUI -- we knew not to put him anywhere near the GUI by then) he stomped off and turned in his resignation because we didn't properly respect his brilliance, and my manager's manager talked him into working in another area of the company on another product rather than resigning outright, and eventually he turned in his resignation from *that* position after his tastes in user interface proved to be equally daunting for them for the same basic reason. Oddly enough, after a few years of seasoning elsewhere in the industry to brush the edges off his arrogance to turn it into less-obnoxious self confidence, he turned out to be a decent engineer... just don't put him anywhere near a user interface, for cryin' out loud. Which Google would have done immediately, if the Android user interface is any indicator.

-ELG

Droid or iPhone?

On the left side, weighing in at 4.3 inches, the Motorola Droid X. This massive hunka hunka burnin' cell phone love is running a 1ghz TI OLED processor and has 8gb of built-in memory for programs and 16gb of Microsd memory for data, as well as an 8 megapixel camera.

On the right side, weighing in at 3.8 inches, the Apple iPhone 4. This sleek little beauty is running an 800mhz Samsung A4 with a 5 megapixel camera whose sensor is the same size as the Droid's (i.e., fewer, but more sensitive, pixels).

So who is the winner? The iPhone 4's camera, despite fewer pixels, is definitely better than the Droid X camera. As in, ridiculously good. On the other hand, the iPhone 4 is more tightly-walled than any previous iPhone. As in, jailbreaking it to run "unauthorized" software is ridiculously difficult. Given the way AT&T and Apple cripple the thing, that's a major problem. The iPhone's screen is too teensy for my not-as-young-as-they-used-to-be eyes. On the other hand, it also has the iPod ecosphere with it, and tight integration with my Macbook Pro, and all my current software will continue working with it.

The Droid X, on the other hand, is easily "rooted". Motorola has created their own ecosphere of sorts, with a car dock and charger, home docks, etc. so that you can do pretty much the same things as with the Apple ecosphere. It doesn't by default have any integration with my Macbook Pro, but a third-party program called The Missing Sync will do most of that. The big screen is nice for older eyes. But Android itself is ugly and clunky, though serviceable.

So who's the winner? Call it a draw -- for now. Which presents a problem, because my aging iPhone 3G really is not liking iOS 4.0, everything runs really slow and clunky. Maybe I ought to flip a coin... or maybe if I wait a few more months, the horse will sing. Hmm...

-ELG

The new alternative to VMware: KVM

Both the latest Ubuntu and the latest Red Hat are shipping with a new alternative to VMware Server called QEMU-KVM. I've been playing with it, and it is much faster and lighter weight than VMware Server, as well as being more flexible and easier to use.

To get started with QEMU-KVM on Ubuntu 10.04, first install kvm and qemu-kvm from aptitude. Then install virt-manager. After that, System Tools->Virtual Machine Manager will bring up your virtual machine management console.

You'll see two entries when you do this:

• localhost (QEMU Usermode) - Not Connected
• localhost (QEMU)

Double-click on localhost (QEMU) and it'll connect to the local root virtual machine manager. You could also connect to other machine's managers, if you're wanting to, say, manage the virtual machines on a host in your data center, by using File->Add Connection. Now you'll probably want to set up a data pool for use by your new virtual machines. Most of us put the virtual machines on their own partition, not on the root partition, but the default data pool is in /var/lib/libvirt/images -- which is on the root partition. Ick. Never fear, right-click on the localhost(QEMU) and select 'Details', then click on the 'Storage' tab when you get the details. Click "+" to add your new storage pool, once you define its location click the green 'play' button to make it active, then hit the red delete button to get rid of the 'default' pool. You now have a new default storage pool at the location you desire.

Okay, so you have your data pool, now what about creating a virtual machine? Easiest way to do that is to use an ISO image of your favorite distribution. Just right-click on the localhost(QEMU) entry again, and select 'New'. The resulting wizard is ridiculously easy to navigate as long as you remember that it's going to create it in whatever your enabled data pool is when you tell it to 'create a disk image on the computer's hard drive'.

So, after this you should be able to run the virtual machine and install your ISO on it. Remember that ctrl-alt gets you out of the QEMU console back into the regular Linux desktop environment, and you'll be fine. To open a console, just right-click and select 'open'. Or once you have a VM set up and installed, you can shut it

Okay, so what's the limits of QEMU/KVM right now? First of all, don't expect to run graphical environments via the normal console with any kind of responsiveness. It emulates a very slow/old display card which is then screen-scraped by a vnc server. KVM is mostly useful for running non-GUI setups, such as Asterisk servers or hosted virtual web servers. Secondly, some operating systems might not install at all into KVM due to driver support issues. Finally, there is no equivalent of "VMware tools" to integrate with your host environment so you can move your mouse freely between the virtual machine terminal and the host OS. Your best bet there, if you want a graphical console inside a virtual machine, is to install VNC in the virtual machine and then use VNC to view your graphical console.

But aside from those limitations, KVM appears to be working quite well. It is definitely better on Linux than VMware Server, and if you need to create a vmdk to import into VMware on some other non-Linux host, it's easy enough to just 'qemu-img convert -O vmdk VbAst32.img VbAst32.vmdk' and voila, the new virtual machine will import cleanly into VMware. And of course VPEP runs inside a KVM virtual machine just fine... :).

-ELG

iPad insanity

I suppose that, like every other geek on the planet, I have to talk about the iPad. Okay. I'm underwhelmed. Good enough?

The iPad has two problems: 1) It's too big, I can't fit it into the side pouch of my laptop case or of my carry-on bag. 2) The 10" LCD uses too much power. My little Sony PRS-300 uses e-Ink, which uses power only when you're flipping from one page to the next and allows a 2-week nominal battery life (1 week in actual heavy use). The iPad nominally has a 10 hour battery life, but my experience with my Macbook Pro, which nominally has a 7 hour battery life, says that the iPad will actually have a 7 hour battery life in real-life use -- the nominal battery life is if you have the backlighting turned down to pretty much unreadable levels, and I'm not as young as I was 14 years ago when I was releasing my first Linux product, I can't read things that are so dim anymore.

So the iPad, to me, is like the Apple TV -- a so-so product that might at some point in the future become useful, but right now is a "so what?". I normally carry my Macbook Pro and my iPhone with me when I travel, and maybe the Sony Reader tucked in the side pocket of my laptop case if it's going to be a long trip just so that I don't run out of books to read (hauling that many paper books can get problematic). I just can't see the point of the iPad, at least for me. Maybe if it were an iTampon, a smaller handier more convenient device similar in size to the Kindle, I could "get it", but for now? Too big, too power hungry, too inconvenient.

--ELG

The problem with eBooks

I've been looking at ebook readers lately -- the Sony Reader, Amazon Kindle, and Barnes & Noble Nook being the three that I looked at. All three do a good job from a hardware perspective. E-paper is quite acceptable for reading text novels and you can store enough novels on one of these things for a whole year, saving a whole lot of dead trees in the process. And the one-to-two-week battery life on these things is adequate for all purposes short of hiking the Appalachian Trail, and even there it would work as long as you brought along a USB solar charger. These e-paper devices with their relatively large high-contrast screens put reading eBooks on the small screen of an iPhone to shame, and even the lowest-power-use laptops won't get much further than five hours before they go dark, much less one to two weeks. Most of this can be attributed to the e-paper screen, whose large size, high contrast, and lack of power usage (the only time they use power is when you flip the page, static displays use no power) allows a much more pleasant experience than any prior electronic reading device.

Yet... yet. E-book uptake is ridiculously small. Even the Kindle has probably not sold more than 400,000 copies despite the fact that every time you go to the Amazon.com site the thing is hyped to you. So what, exactly, is the problem?

Well, the problem is simple: A lack of books, compounded by a) DRM, and b) the outrageous costs for the ebooks, costs that in many cases are higher than the costs for equivalent paperback books from your local bookstore. For example, Sony's ebook chief claims it's impossible to make money selling ebooks for $9.99. WTF? Bookstores can sell paperbacks for $7.99, despite the huge overhead of having a physical plant and employees and shipping charges to get the books there and etc., yet E-vendors can't make money at $9.99?!

The big publishers, to me, seem to have their heads stuck up their a$$'es in much the same way that the big music studios had their heads stuck up their a$$'es about digital music until Steve Jobs finally brow-beat them into submission to get them to sell songs for 99 cents without DRM. The various ebook vendors all have incompatible ebook formats, sell only a small smattering of publishers' catalogs in e-format, and sell them for prices higher than the paper version of the publication. And, they have them DRM-protected. Meaning that five years from now, they're worthless, because the device you installed them on will have broken and you won't be able to read them anymore.

I have files on my computer that are 20 years old. That's because I never used proprietary formats (or at least used proprietary formats that were so common that they were easily translated into non-proprietary formats), and transferred the files from older computer to newer computer every time I upgraded using open protocols such as xModem over RS-232 in the early days, and FTP and SCP over TCP/IP networks nowadays. Similarly, I have paper books in my storage room that are 30 years old that I can read just fine today. I did not buy any songs from the iTunes store until they became DRM-free because having songs in a proprietary protocol tied to a specific computer simply was incompatible with my experience in technology, which said that the songs would become unlistenable within five years if I did that. It's like having a 9 track tape from 1982. How are you going to read the data off of it? Where are you going to find the device? If it's in some proprietary format, how are you going to convert it into some modern format? Digging through my storage I came across a couple of 9-track tapes from the mid 1980's, I think they had early copies of GNU Emacs on them to be read into our VAX minicomputer at college. At least they're (probably) in tar or cpio format, but how in the world could I possibly read them when the hardware to read them is long gone and obsolete?

Yet that is what the eBook vendors want to lock us into -- having to re-buy our entire library every three to five years when proprietary eBook formats become obsoleted and the devices they were installed upon die the normal death of consumer electronic devices (i.e., 3 to 5 years, then bam, one day they just don't wake up again, maybe a battery wore out and you can't get a replacement battery because the vendor doesn't make them anymore or because the battery is more expensive than a new device, maybe a capacitor in a critical path reached its end-of-life, but it's dead, Jim). It is laughable, and it's no wonder that only a few early adopters are buying these things right now despite the great hardware that's come out recently, even though the DRM put on these early e-books is itself laughable (all -- ALL -- major e-book DRM formats have been cracked, even the Kindle one, copy protection works no better today than it worked in 1985 when we were cracking the protection on Commodore 64 games, all it does is annoy people while not impairing the pirates at all). Because, as with computers, hardware is only half the equation. If you don't have content -- if you can't get books for it for an affordable price, and more importantly, can't get books that will last longer than the device they are installed upon, what's the point?

-E

The Windows 7 hoopla

So is Windows 7 a Mac killer? Or is Windows 7 lipstick on a pig? The answer is "No."

Let's look at the first one first. Windows 95 in many ways introduced "the" Windows user experience. It was a clean, reasonably logical user interface that was surprisingly good from a user interface perspective considering the limitations of the underlying platform, limitations which were necessitated by the limitations of the underlying hardware and the need for DOS compatibility until Windows-specific software arrived. It was Windows 95 that I evaluated, then went to my boss and said, "This is going to be big. We need to figure out some way to make money with it." That was a few months before a customer brought Linux to our attention (and my reaction to that later -- it was not favorable, initially), but certainly I wasn't wrong when I said that to my boss.

It's been all downhill since from a user interface standpoint, with each new release of Windows having yet more useless folderol to waste resources and confuse customers but no fundamental change in the UI. Windows 7 continues that tradition, adding lipstick to the pig that has become Microsoft's overly complex user interface by re-naming some things, changing text to icons on the menu bar, and somehow managing to make the Control Panel even more complex than it already was. People who claim Windows 7 could somehow be a "Mac Killer" are being ridiculous. Changing the text on the menu bar to icons does not make it a dock, and Windows 7 is even more confusing to set up and configure than its predecessors were if you're trying to integrate it into an already-existing network. I clicked away in the control panel for quite some time before finally typing "change workgroup" into the search bar. That took me to a place where I could change the workgroup (so it matched my home and office workgroup name so my systems would appear in the network browser), but where is that located in the morass that is the Windows 7 control panel? I have absolutely no idea, I clicked into the logical place and it changed my workgroup to "WORKGROUP", which isn't what I wanted at all.

Meantime, click on the open-apple icon and select 'System Preferences'. There's two possible places where you could set the workgroup -- 'Sharing', or 'Network'. I clicked on 'Sharing' and didn't find it, so I clicked on 'Network', there's a button 'Advanced', I clicked on 'Advanced', saw the word 'WINS', and yep, there's my NetBIOS name and workgroup name. Three clicks once I got the Mac "control panel" up - Network, Advanced, WINS -- to get me where I needed to be.

So from a user interface perspective, Windows 7 definitely is lipstick on a pig. It's just a bunch of lipstick on top of the original Windows 95 user interface, and like a toddler messing with mommy's lipsticks, the results are not all that great from a usability perspective. Frankly, I prefer the original, which was fast, clean, useful. However, that's not the important changes that have been made to Windows 7. The important changes are under the hood. Windows 7, in my test, used approximately 3GB more disk space than Windows XP -- i.e., around 8GB rather than 5GB. Its memory usage for snappy performance is approximately 256MB more than Windows XP (around 756M vs. 512M) if you disable Aero by switching to a 'Basic' theme, and since Aero is just lipstick, that's no big deal. In exchange you get a more secure operating system that has built-in functionality that Windows XP lacks, such as the ability to record a DVD. I have not tested Windows 7 on a netbook yet, but I'm not seeing any reason why it wouldn't work -- even with Microsoft Office installed and various third-party Internet software (Firefox, Safari, Flash, etc.) I'm using only 14GB of disk space for my Windows 7 system, and even low-end netbooks come with 32GB SSD drives and 1GB of memory today.

So from that perspective, Windows 7 accomplishes what Microsoft wanted it to do -- it allows them to discontinue support for Windows XP because it will run pretty much everywhere that XP is currently required due to the resource usage of Vista. It also accomplishes what most IT people want -- a more secure operating system that won't require them to spend half their time cleaning up after virus outbreaks, and which allows them to standardize on *one* operating system, rather than having a mismash of various versions of Windows. On the other hand, it's pretty clear that Microsoft needs more than lipstick on a pig to clean up their user interface. They need a few iFools to lead the charge against useless UI complexity, including at least one iFool who has the status in the corporation to push back against the marketing droids and geeks who always want one...more...feature... to never be used by actual customers, but look good on a marketing flyer or looks, like, really rad, dude. I wish them luck, because after fifteen years of putting lipstick on a pig, there's almost more lipstick than pig insofar as the Windows UI is concerned.

-- EG

A new gadget

This is an HP OfficeJet Pro 8500. It is a fax machine, copy machine, scanner, photo printer, and just plain printer. It uses a water-resistant pigment-based ink so while it's not a laser printer, it fills the same basic need. It's fast, and the inks are priced reasonably on a per-page basis. So far, so good.

It replaces a laser printer, an inkjet printer, a scanner, and a fax machine, and frees up a huge amount of space in my home office even if it does sort of overlap the sides of my filing cabinet. And because it's network-connected to my Airport Extreme (via a network cable, not via WiFi), I can print wirelessly from my MacBook Pro while I'm at the dining room table or in the bedroom.

It just showed up in my Bonjour window when I went into Printer Preferences to add it as a printer. The scanner just showed up there too. Both work, and the document feeder works too for both copying and scanning, albeit I wish it had a duplexer. But for under $200, it's hard to be disappointed that the document feeder "only" gets one side of pages you feed it...

-Eric

Is the end of rotational storage near?

Okay, so this one's been predicted for over 20 years now. I remember reading Jerry Pournelle in Byte Magazine in the early 80's making this prediction. But I just went over to NewEgg.com and found a decent 64GB SSD for $150. While that's not going to replace the 2 terabyte RAID array in my Linux server, for the average consumer that's more than enough storage for anything they're ever going to do with a computer, and the 128GB SSD's are going to be just as cheap within six months, which is more storage than the average consumer will ever use.

Okay, now I hear you laughing. "64 gigabytes? Heck, my collection of unboxing videos is bigger than that!" But you're not the average person. The average person looks supiciously like me when I'm using my Acer Aspire One netbook on my Jeep expeditions rather than my top-of-the-line Macbook for development. My Aspire One gets used pretty much the same way the typical person uses their computer -- it does Internet browsing and email, I suck photos out of my camera into the Acer and resize them and post them on the Internet, and it handles a single major application -- in my case, loading detailed topographical maps and imagery into my DeLorme PN-40 GPS. It came with a 120gb hard drive. I'm using about 35GB of that hard drive right now, because I copy all my photos off onto an external drive when I get home (because I don't trust the integrity of a hard drive that's been bouncing around in a Jeep on an expedition into the Mojave Desert). Why wouldn't I put a 64GB "hard drive" into the thing that won't ever fail (at least, not because I bounce it around in a Jeep, anyhow)? After all, if I need more space, I can always plug in an external drive and copy stuff off. Frankly, 64GB is plenty of space for everything that the average person ever does with a personal computer, and 128GB is going to be $150 by the end of this year and most decidedly is enough space for the average consumer.

So maybe the end of rotational storage isn't here. But unless some new consumer application comes up that requires huge amounts of storage, it may be that we're seeing the last gasp of rotational storage in consumer hardware. After all, who needs a 500gb hard drive that might crash and fail, if a 128gb SSD costs the same amount of money and is plenty big for everything the average person wants to do with a computer?

-E