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

ACL management on MacOS Snow Leopard

So I was going to follow the directions at this hint site to prevent Time Machine from doing a full backup again once I updated my MacBook Pro to a bigger drive. After all, I don't want to re-backup the stuff I just restored from my backup! But my attempt slammed to a halt after I type 'fsaclctl' and... uhm... WTF? It isn't in Snow Leopard! And by the time you get to userland the permission to override a "Deny All to All" ACL is dropped even if you su to root... you just can't get there from here unless you can somehow turn off ACL support for the whole filesystem!

Ah, but never fear, the Leopard version of fsaclctl works just fine on Snow Leopard. The question is, which of my half dozen backup drives up in the storage closet or offsite is old enough to have Leopard on it? I was about to get up and go grab one, when I glanced down and... there was the Mac OS Leopard 10.5.2 install DVD, right there, in the pile of disks I'd used to re-image the Mac.

So first thing to do was drill down and find the package. The packages live in '/Volumes/Mac OS X Install DVD/System/Installation/Packages' and the easiest thing to do is 'go to folder' from the Finder 'Go' menu to go there. Then by dragging dropping packages onto the /Developer/Applications/Utilities/PackageMaker utility, I discovered that fsaclctl lives in package "BSD.pkg" in directory /usr/sbin.

The next question is, how do we get the file out of the package? I couldn't drag it out of PackageMaker, PackageMaker simply refused to do so. So I grabbed a utility called 'Pacifist'. I won't claim it's the best utility for doing this because it's simply the first one that came up when I googled, but it allowed me to drop the BSD.pkg onto it, drill down to the file, then drag the file out to a folder on my desktop, from whence I could then put it into ~/bin and use it.

Now, this isn't about the Time Machine hack (BTW, it didn't work -- apparently Time Machine's implementation has changed since Leopard), but, rather, about security. Some folks wonder why MacOS is more secure than Windows. This experience gives you one clue why. There are things you cannot override even if you have full administrative access, once permissions are dropped during the boot process. I suspect that in future releases of Snow Leopard will remove the low-level ioctl that fsaclctl relies on, further securing the system. But it's clear that while Apple doesn't make splashy announcements about security and doesn't have some of the bells and whistles like address space randomization, they're doing some things quite right in the background to keep things secure.

-EG

Parallels 5 vs. VMware Fusion 3

So I have tried both of these virtualization solutions for MacOS Snow Leopard and the winner is... VMware by a landslide. Not because of performance. VMware's performance is acceptable for my purposes but I can definitely tell that I'm running in a virtualized environment. But, rather, because VMware WORKS, and Parallels doesn't. That's the bottom line. I can go into more detail, but I'm just too frustrated with Parallels right now and would use language not appropriate for polite conversation. Having Parallels crash my computer *TWICE*, and lock up three different times, simply does not make me happy.

I am saddened to say this, because I've owned Parallels since version 2.0, but this is it. This is the end. They are not getting any more money from me. Each new release of Parallels they promise that they got it right this time. Each time, they break things badly -- for example, in Parallels 4, one of my mapping programs ended up going BLAMMO unless I turned off mouse pointer acceleration in the Windows control panel, and then the Parallels device driver simply refused to display any mouse pointer at all. Meanwhile VMware Fusion 3 is a rock solid product. It might be slightly slower than Parallels on some benchmarks (hard to tell, I could never keep Parallels running long enough to run the benchmarks I was wanting to run), but it *works*, and the integration between Windows and MacOS Snow Leopard is quite good, no problems with cut-and-paste or sharing files between Windows and MacOS or anything like that. The competition between VMware and Parallels is over, and Parallels is done. Finished. Kaput. They had first mover advantage, and like Netscape with web browsers, simply failed to execute.

Which reminds me of the time that my manager was the guy who ran Netscape's development process into the dirt. Needless to say the common Linux fanboy notion that Microsoft ran Netscape out of business is utter nonsense -- Netscape's browser technology disintegrated without any help from Microsoft at all. Their technology simply disintegrated under the weight of too many idiotic false deadlines and hacks, and the manager who did that then did the same thing for my then-employer's development process. But that's another ugly tale that tends to evoke unwise language so I'll do something a bit more abstract about deadlines and why they're both useful and, in some cases, toxic.

-EG

Numbers from Windows Experience quickie benchmark:

• VMware 3:
  • Processor: 5.9
  • Memory: 3.9
  • Graphics: 2.9
  • Gaming graphics: 3.4
  • Primary hard disk: 6.3
• Parallels 5:
  • Processor: 4.5
  • Memory: 3.9
  • Graphics: 2.9
  • Gaming graphics: 4.1
  • Primary hard disk: 5.9

Parallels has somewhat better 3D performance, somewhat poorer performance on processor and hard drive tests, same as VMware elsewhere. Parallels is probably better if you want to play games, but that's why Boot Camp was invented...

The Windows 7 'reg' command

So I had a problem. I had a Topo 8 install on my old XP hard drive and wanted to transfer it to my new Windows 7 machine. No problem, just re-install, right? Well, that would be a problem alright, because my activation key for Delorme Netlink would not work in the new install -- Delorme links it to a single installation of Topo USA. Note that the licensing for Netlink allows me to run it on any computer that I own as long as it's just one computer at a time (i.e. I can't have it installed on more than two computers and can only use it on one computer at a time), but the actual implementation is similar to the lamentable Windows Activation in that it often disallows things that are allowed under your licensing agreement, requiring you to call in to a support center and have a database entry adjusted at the other end to allow activation.

So now let's talk about what actually happens on modern versions of Windows when you install a program. Things get placed into basically four areas:

1. Start Menu folder -- usually a folder is created here with a new Shortcut to the application plus utilities. The location of the Start Menu folder differs wildly between Windows XP and Windows 7, but it's easy to find.
2. Program Files -- usually a folder with the program and all its data is created here.
3. Windows -- Any driver bundles are plopped into the appropriate folders here, as is installer/uninstaller info.
4. Registry -- Configuration data and component registration.

Of these, the first three are easy to copy from one computer to another. But the registry entries... ah yes, now that is a problem!

The fundamental problem is that the registry is a database, and thus you can't simply use drag and drop to move entries from point A to point B, unlike with MacOS where you could just copy the appropriate directory from the old /System/Library/xxx to the new /System/Library/xxx and/or the old ~/Library/xxx to the new ~/Library/xxx to move the configuration data, or Linux where you could just copy the appropriate directory from the old /etc/xxx to the new /etc/xxx to move the configuration data. You have to use database tools, and the Windows database tools for accessing the registry are crude and primitive compared to the tools available for accessing file data. This is especially true for the 'regedit' GUI command which is utterly incapable of copying registry from place A in the registry tree to place B in the registry tree. But never fear: This is a capability that the command line 'reg' command has, and we're going to use it.

The first thing to do is to mount the old hard drive as your "D:" drive. Make sure you've added the 'Run' menu option to your Start Menu with the appropriate control panel entry (sorry, you've already seen my opinion of the Windows control panel, it's in there *somewhere* but you'll have to do like me and just dig until you find it!). Select 'Run' from your start menu, and go into 'Regedit'.

The next thing you'll need to do after that is import the HKLM hive into your registry. Click on the HKEY_LOCAL_MACHINE entry and select File->Load Hive. Browse over to D:\Windows\System32\config and select 'software' as the hive to import. Then give it a name, like OLD_SOFTWARE. Once you finish doing this, you'll find that OLD_SOFTWARE is now in your registry tree. You can now exit regedit, because regedit has no (zero) ability to copy subtrees from one place to another in your registry tree.

Now you'll need an administrative mode command prompt in order to operate. Now, I'm going to assume you have some basic Unix-compatible command line tools available using Cygwin or by copying files to MacOS or Linux via a network file share then executing Unix commands there, simply because there are no native Windows tools which will do the same command line parsing in as easy a manner, but it COULD be done with VBscript. It'd just be a lot more coding to make it work.

So: now that we have a command line,let's query out all the Delorme keys:

• reg query HKLM\OLD_SOFTWARE /s /f delorme >\Delorme_keys

Then copy Delorme_keys someplace where you can run Unix commands on it:

• grep "^HKEY" Delorme_keys >Delorme_keys2
• vi Delorme_keys2

Take a look at those keys, and at the original file too, to see which ones you want. In general you will not want to completely replace the contents of all keys that have some data item related to your application, you'll want the Classes and any software-specific key. So I edited Delorme_keys2 to have the keys I wanted to copy from the old install, then:

• awk ' { t=$0; sub("OLD_","",$0) ; printf("reg copy \"%s\" \"%s\" /s\n", t,$0); } ' Delorme_keys2 >DelormeRegCopy.bat

This gives me a file that has lines in it that look like this:

• reg copy "HKEY_LOCAL_MACHINE\OLD_SOFTWARE\Classes\CLSID\{20016EDD-4CB6-11D3-A3FA-0000C0506658}" "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{20016EDD-4CB6-11D3-A3FA-0000C0506658}" /s

The 'reg copy' command will copy both the key (and its data items) and any subkeys to the new location, assuming you provide the /s flag. Then I copy this .bat file back to the Windows 7 system, and from the Command prompt type "delormeregcopy.bat" and voila! Now my copy of the Delorme application works, Netlink works, and I can then re-install Topo 8 on top of this install to "repair" it (i.e., put the installer and driver bundles in the right place and verify that everything is registered properly) and the installation keys will still be there to keep my Netlink operational.

Note: As always, back up your registry before mucking around in it. And be *very* careful with any keys you copy in, I examined the contents of each key using regedit before I allowed it to stay in my final Delorme_keys2 file. The above is NOT the full directions for how to do this specific task, simply because I do not wish to enable software piracy, but, rather, an example of how to use the 'reg' command to copy critical registry entries from an old installation into a new installation. And the usual disclaimer "this might destroy your system!" applies.

Now: I could go off on a rant about how stupid the Windows registry is, how the tools to manipulate it are primitive and far inferior to the tools available to manipulate text files, blah blah blah, but we already all know about that. The "reg" command at least gives us some of the missing functionality that regedit doesn't have, even if it requires typing obscure commands at a command prompt. But then, "obscure" and "Windows Registry" do go together like "macaroni" and "cheese", eh?

-- EG

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

The smartphone maze

Much has been made of recent improvements in Google Android phone sales. Android phones are now available (or will be available by November 1) on all major U.S. carriers except AT&T, and many carriers will have multiple Android phones. There are some who say that this will doom the Palm Pre, which along with the iPhone has the slickest user interface of all the various smartphones out there. But my own analysis is that this isn't so: The smartphone OS that Android is supplanting is not RIM's or Palm's, but, rather, Windows Mobile.

It is little secret that the development of the next generation of Windows Mobile is a disaster. Windows Mobile 6.5 has been announced for the end of this year to collective yawns -- nobody thinks anybody is going to actually ship a phone based on it. Windows Mobile 7 has been announced for next year to barely concealed guffaws. Nobody who is serious expects a viable Windows Mobile 7 to come out anytime before the end of next year. What has happened, during this era of stagnation in Windows Mobile, is that WM vendors are now migrating to Android for their new smartphones. Android supports the new features of the new smartphone hardware, while Windows Mobile doesn't. And while Android is a user interface disaster, so is Windows Mobile -- both systems embody pre-iPhone paradigms of how to do things where each application has its own unique user interface, as vs. the new multi-touch common-user-interface paradigm where all user interface coding must go through a library that enforces a common look and feel. In short, where geeks used to go to WM because it was a (relatively) open platform with a lot of capabilities such as multi-tasking that the competition did not have, now they're going to Android instead because it has those same attributes but supports newer hardware.

So what seems to be falling out of all this is that Windows Mobile is going to go the way of old-school PalmOS shortly. The current vendors of WM phones such as HTC appear to be engaged in a mass migration to Android. But this does not mean that sales of the iPhone and Palm Pre will be hurt by Android. They are simply different markets -- Android, due to its fundamental design and development processes, will simply never be able to match Apple or Palm on ease of use or consistency of user interface between applications. Like Windows Mobile, Android is a geek product. Plenty of geeks will likely end up migrating to Android, but there is a huge market for smartphones as people max out the capabilities of standard candybar/flip phones between Twittering and everything else they want to do with phones, and most of these people are not geeks. Vendors like Apple and Palm are well positioned to go after that market... but Android simply doesn't play there, any more than RIM does with their crackberries.

-E

People are NOT fungible

One of the things that happened during the transformation from being "employees" to being "human resources" is that large corporations apparently decided that employees are fungible. That is, if you have two employees, employee A and employee B, and employee A is making a lot more money than employee B, it's fine to just drive off employee A and replace his position with employee B then hire a contractor for even less to fill employee B's position. Hey, an employee is an employee, right? Interchangeable, just like cogs, eh?

Much has been said about Microsoft's T-Mobile Sidekick disaster and what that says about the notion of "cloud computing" (hint: As I said earlier, cloud computing does not eliminate normal IT tasks other than actual hardware maintenance). But it says even more about the whole concept of "human resources". The infrastructure that Microsoft purchased with Danger included Oracle databases, Sun servers, and a set of non-Microsft NAS or SAN systems. None of these are things that Microsoft has experience with. The current hypothesis is that Microsoft contracted a contractor to do an Oracle database upgrade, and the contractor did exactly that, and Oracle -- as it often does -- ate its database during the upgrade. This was compounded by, apparently, the database backups being unreadable by the new version of the database. All of this is remediable if you have sufficient Oracle expertise on staff, but apparently neither Microsoft nor their contractor had such expertise -- they'd all left Danger after the acquisition after being shifted to positions dealing with other technologies that they didn't like or did not have the skills to do successfully.

Lesson for managers: Identify the critical skills that you need in order to continue to have a viable business, and retain those people. It's a lot easier to retain the people you need, than to find new people with those same skills to replace them once they do leave and you discover that suddenly you no longer have a viable enterprise because critical tasks are no longer being done for lack of expertise to do them. Employees are not fungible. You simply cannot replace an Oracle database expert with a contractor hired off the streets or with an expert in Microsoft databases, Oracle databases are black magic and the people who can successfully maintain them are worth every penny you pay them.

Of course, it's easy to throw stones at Microsoft here, but it's not a Microsoft problem. It's an industry-wide problem. Managers industry-wide are failing at the task of properly identifying the skills they need in order to perform the tasks needed to have a viable business, and when the people with critical skills leave are blind-sided. Thus you get disasters like Sprint's Nextel disaster, or this Sidekick disaster, where critical infrastructure people left and the infrastructure fell apart and rendered the enterprise non-viable. Employees are not fungible, and if you fail in your job of identifying the skills needed to keep your business operating and retaining the people with those skills, you may not get the press of the Sidekick disaster, but your business will operate slower, less efficiently, and have difficulty getting product out the door. And especially look at IT and operations people. That's not sexy stuff, but both Sprint/Nextel and Microsoft/Danger show that you simply cannot fire all the operations people you just acquired and replace them with your experienced employees who are experienced with a totally incompatible technology. It doesn't work. It just doesn't. And remedying the disaster that arises after you do this will be far, far more expensive than just retaining those critical infrastructure people in the first place.

-E

SSD in a low-end netbook

Netbooks tend to live a hard life. They're used in moving cars, they spend a lot of time banging around in backpacks, and so forth. Early netbooks like the Asus eee that practically defined the category used Linux and a small flash memory chip. This dealt quite well with the problem of durability -- flash memory chips don't care about vibration (at least, not about levels of vibration that wouldn't utterly disintegrate the whole computer) and The problem is that people want to use their netbooks to view multimedia content, and Linux is woefully inadequate in that area due to the fact that Linux users today are either utter geeks (parodied in this Xkcd comic) or are using it for servers where multimedia is not an issue (other than serving it via a web server). So netbooks have moved to using Windows XP rather than Linux.

The problem is that Windows XP does not run well off of the slow flash memory chips included with first-generation netbooks, thus netbooks have moved towards the cheapest hard drives available. Unfortunately this brings two problems: 1) those hard drives are still painfully slow compared to current state-of-the-art hard drives, and 2) those hard drives have the same vibration sensitivity and G sensitivity of all hard drives, making them a poor fit for netbooks.

The solution would be a high-speed SSD drive. They perform much better than low-end hard drives, and the only vibration or G forces that could destroy them would turn the entire netbook into a pile of shards. The problem is that SSD's were typically expensive. Until now: 64GB SSD for $150, in this case a Kingston SSDNow V-Series.

64GB doesn't sound like a lot of storage, but I examined the hard drive on my Acer Aspire One netbook and discovered that I was using a whole 20GB of hard drive space. I think my usage of the netbook is probably typical of most people's usage of a netbook -- Internet browsing and light word processing. These aren't computers that you buy to do video processing or music recording, they don't have the CPU horsepower for that, but they're perfectly acceptable for Internet browsing. When I'm bouncing around in my Jeep on field expeditions I don't want to haul around my expensive Macbook Pro, I want something small and durable for doing quick email checks whenever I get near civilization, and the Aspire One suffices for that. Except for the hard drive issue.

Thus I purchased the above SSD and installed it in my Aspire One. I had previously purchased the disk imaging CD/DVD set from Acer to allow re-imaging my netbook when the hard drive failed (note the "when", not "if" -- netbooks live hard lives), and it installed fine onto the SSD. The results have been gratifying. Performance is much better than with the low-end hard drive, and the durability is excellent. The second-generation SSD's have now conquered the stuttering problems that plagued the first-generation SSD's, at least for applications such as netbooks where large writes are rare -- I have never encountered stuttering problems.

What does this mean for the future? It means yet more low-power energy-efficient netbooks, perhaps higher in price than current netbooks but with better durability and performance. Netbooks will be relegated to the long-battery-life small-storage-capacity category rather than being marketed based on low performance and low price. You will start seeing some netbooks in the $700 range, around the same as a "real" notebook, assuming that sufficient performance can be obtained to justify that price. The question is whether Intel will deliberately cripple their Pineview follow-on to the current Atom processors the way they currently cripple it by forcing netbook makers to use the antiquated high-power-use 945 chipset, which has atrocious graphics performance (i.e., cannot even play HD videos from YouTube without stuttering, which is a major problem given that many people buy these things to browse Internet multimedia content). If they do, expect rival chips from AMD and VIA to gain popularity, albeit not with major vendors due to Intel's anti-competitive behavior of charging vendors more for chips if computer vendors use a rival's chips for more than 5% of their shipping computers. Given that there are major markets where Intel's chips are the only available chips, this clearly is going to limit how many jump ship to AMD and VIA. But if Intel can't deliver the performance that people want, somebody will jump ship to AMD or VIA, even if it isn't Dell or HP...

-E

In the Cloud

Cloud computing. Ah, how the buzzwords love to flock. This is no different from the 1970's when it appeared that the future was going to be large timesharing services. You could deploy your applications in that "cloud" and have redundancy, automatic backups, and so forth without the time and trouble of maintaining your own infrastructure. If you needed more storage an additional DASD in your VM virtual machine could be easily deployed from the "cloud" of storage devices available at the timesharing service, if you needed more CPU your application could be deployed on a VM given access to more of a CPU or even to a whole CPU, and so on and so forth. Large time sharing services with IBM 370's and follow-ons were doing cloud computing before the word existed. There is no (zero) functional difference between an IBM 370 running VM in 1973 and a Dell server running VMware ESXi today, other than the fact that the Dell is much faster and has much larger hard drives of course. But both do the exact same task, and arguably the IBM 370 did it better since the IBM 370 would even let you migrate all processes off of a CPU and take that CPU offline and remove it entirely for service, *with no disruption to running jobs*. Something which, I might add, its descendant IBM mainframes are still capable of doing, and which VMware wishes it could do.

So what happened, you ask? Why did large corporations move to networked microcomputers and their own insourced mainframes, and why did smaller businesses move to microcomputers and servers? Part of the reason was one of data security -- having your data reside with a third party entity that might go out of business at any time was a business risk that was not acceptable. But also, they ran into the same problem that cloud computing runs into when you try to deploy large enterprise databases into the cloud: a lack of I/O bandwidth. We are talking about an era where 300 baud acoustic couplers were high tech, remember, and where the backbones of the primitive data networks ran at 56kbit and operated in block mode. As a result, user interfaces were crude and based around block transfers of screen data, since real-time updates of screen contents based on immediate response to keystrokes was simply impossible. When microcomputers were invented with their megahertz-speed connections to their video displays and keyboards, that made possible entire classes of applications that were simply impossible on the prior timesharing systems, such as spreadsheets and real WSIWYG text editing and word processing.

Pipes to cloud computing facilities today are similarly constrained compared to local pipes. 10 gigabit network backbones are now not unusual at major corporations, yet most ISP connections are going to be DS3's that are operating at 45 megabits per second. It is clear that cloud computing runs into the same communications problem that prior time-sharing operations ran into, except in reverse -- where the problem with the time sharing systems was inadequate bandwidth to the user interface, the problem with cloud computing is inadequate bandwidth to the database. Most major corporations generate gigabytes of data every day. One major producer of graphics cards, for example, has so many NetApp appliances filled with simulation data for their cards that they had to expand their data center twice in the past five years. This is not a problem for a 10 gigabit backbone, but you are not going to move that data into the cloud, you're hard pressed to save it to local servers.

So what makes sense to deploy to the cloud? Well, primarily applications that are Internet-centric and operate upon a limited set of data. A web site for a book store that occasionally makes a query to a back end database server to get current inventory works fine for cloud computing. Presumably the cloud servers are colocated at critical points in the Internet infrastructure so that buyers from around the world can reach your book store and order at any given time, and the data requirements to the back end are modest and, because much of the content is static (War and Peace is always going to have the same ISBN and description for example), much of the data can be cached in those same data centers to reduce bandwidth to the central inventory system. I can imagine that this bookstore might even decide to sell access to their own internally developed system for managing this "cloud" of web application servers to third parties (hmm, I wonder who this bookstore could be? :-). Another possible application is for "bursting" -- where you need to serve a significant number of web pages for only a small part of the year. The Elections Results web site, for example, only gets hammered maybe six times per year, and gets *really* hammered only once every four years (when the Presidential race hits town). It serves a limited amount of data to the general public that is easy to push to data centers and serve from local caches there, and maintaining huge infrastructure that will be used only once every four years makes no sense from a financial point of view. Cloud computing makes a lot of sense there.

But one thing to remember about cloud computing: Even for those applications where it does make sense, it is no panacea. Yes, it removes the necessity to purchase actual hardware servers and find a location for them either in your own data center or in a colo, and provide plumbing for them. But you still have all the OS and software management problems that you have if the servers were local. You still need to deploy an OS and manage it, you still need to deploy software and manage it, you have simplified your life only in that you no longer need to worry about hardware.

At the recent Cloudworld trade show, one of the roundtables made the observation that "the next stage in cloud computing is going to be simplifying deployment of applications into the cloud." I.e., previously it had been about actually creating the cloud infrastructure. Now we have to figure out how to get applications out there and manage them. And past that point I cannot go :-).

-EG

The product cycle does not end at the doors of QA

Most engineers, I've found, have a very limited view of the product cycle. They get a spec from product marketing. They implement this spec. They hand the product off to QA. The product gets shipped to customers after bugs are fixed. They're done.

The problem is that this limited view of the product cycle utterly ignores the most important question of all for customers, the question that causes the most pain and headache for customers: How will this product be distributed and deployed in the enterprise?

Product marketing's spec doesn't answer this question, usually. For that matter, the customer often has no idea. The end result is that you end up with atrocities like the Windows install cycle, where deploying Windows and Windows applications across your enterprise requires massive manpower and huge amounts of time and trouble.

When you're working on your product's detailed functional specification and architecture, you must be also thinking about how to automate its deployment. You're the one who knows how the technology will work internally. So let's look at the evolution of deployment...

My first contract job after leaving teaching was a school discipline tracking program, necessary in order to meet new federal requirements for tracking disciplinary offenses. Once I had the actual program working, the next question I had was, "how will this be deployed?" I knew this company had over a dozen clients scattered all over the state, each of which had at least five schools. There was no way that we were going to deploy it by hand to all of these places. The program also required a new database table inserted into the database, so you couldn't just place the program into some location and have it work. And the program also required a modification of the main menu file to add the new program to the list of programs. So there was at least three files involved here. My solution, given we had to get this thing deployed rapidly, was to write a shell script (this was on Xenix back in the day), tar it all up, and then give short directions:

• Place distribution floppy in drive
• Go to Unix shell prompt by logging in as user 'secret' then selecting menu option 2/3/4 .
• Type:
  • cd /
  • tar xvf /dev/floppy
  • sh /tmp/install-program.sh
• Exit all logged-in screens, and re-login.

This worked, but still required us to swiftly ship floppy disks to the central office technology coordinators of all these school districts, and required them to physically go to each school and perform these operations. So the next thing I did was look at the technology available for modem communications on Unix, and decide, "you know, we could do all this with uux!" The modern equivalent would be 'ssh', but this was years before ssh existed.

By the time I left that company, several years later, I could sit at my desk and press one key and send a software update to every school district in our state, which the school technology coordinator could then review and trial at the central office, then, once it was approved, himself (or herself) push one key and send that software to every school in his district. This was all being done via modems and UUCP, since this predated Internet access for schools, but because this was also the era of green screen dumb terminals where 64K-byte programs were large programs, 2400 baud modems were plenty to do the job. We had arrived at a system of deployment that used the minimum manpower possible to deploy this software across a geographically dispersed enterprise. Because of the swiftly changing requirements of state and federal regulators (who would often require updates several times during the course of the year as they decided to collect new chunks of data), this system gave us a considerable cost advantage in the marketplace compared to our competitors, who still required technicians to physically go to each school and install software updates by hand.

Now, this was a specific environment with specific needs. But you should still go into any project aimed at the enterprise with a specific goal to make it as easy as possible to deploy into the enterprise. The customer should have to enter as little data as possible into the program to make it function. It should Just Work, for the most part. And lest you say, "but my program requires complex configurations in order to make it work!", you should investigate and make sure that's true. It was thought to be true about enterprise tape backup software, for example -- that setting up enterprise tape backup software required huge amounts of technical expertise in order to configure SCSI tape jukeboxes. It was the insight of my VP of Engineering at that time, however, that all the information we needed in order to configure the entire SCSI tape subsystem was already exported either by Linux or by the SCSI devices themselves. We told customers to place one tape into each jukebox, then press the ENTER key. They pressed the ENTER key and my scanning routine went out and did the work for them. What was a half-day affair with competitors became a single button press.

The point is that a) you must think about how to distribute software updates to multiple enterprises and across enterprises with the minimum necessory human intevention, and b) even the initial deployment of seemingly complex products can become easy to deploy once you look at what technology is involved and figure out ways to automate the configuration. But you need to be thinking about deployment -- how is this going to be deployed into the enterprise -- or it's not going to happen. Instead what happens is the typical product on the market today which is expensive to deploy across the enterprise and thus it doesn't happen, or happens only haphazardly. And being typical, in today's day and age, is hardly a way towards success...

-E