It didn't appear to me that bschulman thought you had pulled your punches: it appeared to me that he simply thought you were wrong. So do I. To suggest that flash drives offer a cost advantage for any save those rare applications which require high IOPS but relatively little total storage space is ludicrous given their price per GB. To ignore the fact that conventional servers can use the very same power-efficient processors, and 2.5" drives, and flash drives (when they're sensible), and at least very similarly efficient power supplies - even after the first of these was explicitly pointed out to you - seems to verge upon incompetence, as does suggesting (as your footwear example appears to) that people pay an up-front premium that locks them into a specific platform for a decade or so, considering the rate at which technology advances. And to tout the packaging density innovation that blades offer while studiously ignoring packaging density innovation in conventional enclosures makes one wonder about your objectivity. Blades do offer some compelling advantages in ease of physical management, and in some situations this may actually sufficiently offset their higher up-front cost and long-term lock-in to reduce TCO. As for the rest, it still seems pretty much like hype. - bill »

Oh, dear - I see that we've got one of those victims of the unjustified hype that I was referring to right here - but he doesn't seem to have understood my own post (though he seems to have been responding to it). In particular, not only did I note ZFS's marginally superior detection of otherwise undetectable errors (which are orders of magnitude less common than detectable but uncorrectable errors - in the absence of scrubbing the primary cause of data loss in high-density arrays when a rebuild is required), but I also mentioned that WAFL had comparable integrity-checking mechanisms (and, incidentally, it had them before ZFS did). Leaving aside the fact that IBM's i-series (previously AS/400, nee System 38) systems have included supplementary data-integrity checksums for decades (as have high-end block-storage devices like EMC's Symmetrix): these are also comparably capable of catching uncorrected and even undetected bit-rot on a disk, though less capable of detecting wild or lost writes. Thus the ZFS developers reveal only their own ignorance when stating that no external storage systems provide comparable data integrity - and in general the acm article cited reads more like Sun marketing literature than like a serious journal submission (not to mention having been conducted by a Sun moderator...). - bill »

Whether many of ZFS's features qualify as 'revolutionary' (or even 'advanced') is subject to debate: 1. Pooled storage while a good idea is hardly a new one, nor is ZFS's implementation nearly as automated as it might be (e.g., RAID groups still have to be defined manually, disk by disk - just as with a conventional LVM). 2. RAID-Z might more reasonably be described as 'brain-damaged', given that it has dramatically *more* overhead than conventional RAID-5: every small write operation hits every disk in the stripe (rather than writes to just two of the disks after reading them - with at least one of the reads often satisfied in cache), and (even worse) every small *read* operation hits all but one of the disks in the stripe. 3. 'Always consistent disk space' has been available in many file systems - e.g., VxFS, XFS, JFS, NTFS, WAFL - since the early '90s, the last of which is a copy-on-write implementation (the others use a transaction log to protect internal integrity, which has advantages in minimizing fragmentation in files which are updated at fine grain but may be read in bulk - especially since last I knew ZFS had no defragmenter). 4. Disk scrubbing has been available in Linux for years - and it's analogous to RAM scrubbing, not to ECC (it only detects errors, allowing some other mechanism to correct them if sufficient redundancy exists to do so). ZFS's additional internal checksums can (like similar checksums in NetApp's WAFL) catch some errors that conventional scrubbing can't - perhaps improving the 99.99% of otherwise undetected errors that conventional scrubbing would catch to 99.999% (yes, some people actually need this last decimal place of reassurance, but probably not very many). 5. Snapshots are relatively old hat by now (thanks to NetApp's leading the way 15 years ago). Clones are more interesting, but arguably far less important. 6. Built-in compression has been part of NTFS since one of the early NT releases, and standard (though layered) compression on commodity platforms dates back to Microsoft DOS in the '80s. Given storage prices these days, far fewer people bother using it than used to (not that it isn't nice to have for special needs). I really applaud Sun's initiative in what has otherwise been a sadly-neglected area of corporate system development, but am less happy about the degree of hype ("ZFS - The Last Word In File Systems" being particularly notable) in which ZFS has been wrapped for public consumption. So I tend to comment upon the latter when it happens to cross my path. »

You don't seem to have been paying very close attention either, so I'll give this one more shot: 1. "A mini form factor that ran cool with no moving parts was a great move" - but could equally well have supported a fat client if the workload were nearly as light as the ones previously being discussed here (which it sounds like it was; if not, then you were tolerating increased overall system cost - due to the need for a very hefty server to handle the application load - to satisfy the client desire for a minimal desktop footprint). 2. "We also reduced the need for some licenses" - which is precisely what the final comment in the post to which you were responding observed: unlike the cases previously under discussion, when you throw commercial licensing into the mix anything can happen (but that has nothing to do with underlying resource optimization: it's a commercial rather than a technical effect). 3. "Maintenance was non-existence" (sic) - just as it would have been using diskless fat clients. 4. "group policies locked the user’s desktop" - now we're getting into Windows-specific areas (which were not part of the preceding discussion about Linux-based servers, but are still interesting when discussing the merits of the two approaches). As I already observed, Windows is not as readily suited to distributing fat clients as Linux is, so while it's possible to configure Windows diskless fat clients locked down by policies established at their (suitably protected) server-resident system data it 1) is more difficult and 2) requires individual client Windows licenses. So in the case where Windows applications must be run on a Windows server (unlike the cases previously under discussion) there's considerably more reason to consider thin clients (which is exactly what I observed at the end of my first post here). - bill »

I'm curious about exactly why you believe that using a fat client in your library kiosk would have required any more management than your thin client did (rather than just requiring the same occasional reboot). Some of what you've said suggests that you just haven't been listening: when individual client loads are small, you can use a fat client that has *essentially the same hardware* (a comparable CPU, negligible additional RAM, no disk, etc.) that the thin client you describe does - and save the server resources that would otherwise be devoted to running the application at the server rather than at the client. In the example that you provide the additional CPU load and RAM impact of running the Web browser locally is negligible compared to the requirements of running the local operating system supporting the thin client. I.e., whether at client is 'fat' or 'thin' is not (as least in the examples you have offered) a matter of *what* local hardware it requires, but of *how* it uses that hardware: if it uses it just for display management and communication, it's 'thin'; if it also uses it to run applications, it's 'fat'. Or, to look at it another way, the incremental resources at the client required to run applications there cost very little (because they still fall well within the range of commodity products), whereas incremental resources at the server - and the application server itself, when compared with a simple file server - cost relatively a lot, don't scale as well, and couple client loads together in a sometimes annoying manner. Or to put it a third way, anywhere you're *still* tempted to use a thin client for reasons of extreme economy you should instead be considering a dumb terminal - which requires even fewer server resources (green-screen form management loads are very low), costs less, and uses less power than a thin client does. "Thin clients" aren't exactly a new idea, you know: they were called "intelligent terminals" last time around, back in the '70s. And they actually had some reason for existence back then, because they helped very expensive (and by today's standards woefully under-powered) central computers scale up by off-loading a lot of their display management (which otherwise could bring the central computer to its knees when enough terminals were connected). But PCs allowed both vastly more sophisticated display management and enough *local* computing power to handle most common applications as well (at least after 32-bit processors and operating systems arrived: earlier, PCs were used more as commodity-priced cost-effective replacements for the 'intelligent terminals' that had preceded them - or in cases where a user needed both a personal computer and a dumb terminal on the desk). And after that PCs were increasingly used as intelligent terminals only to support legacy configurations that required such or when centralizing some processing activity actually made enough sense to be worth the effort (e.g., with a central, shared database server) - because it otherwise made sense to leverage that local processing power to distribute the processing load and decouple users from each other's resource consumption. Unfortunately, all this local autonomy created headaches for IT administrators, and their initial reaction was understandably to press for a return to centralized computing - a suggestion which the newly-liberated users resisted with equally understandable vigor. This struggle has see-sawed back and forth ever since, with the admins advocating thinly-veiled returns to yesteryear like thin clients and the creation of entire industries dedicated to the development of (complex) mechanisms by which admins can manage distributed autonomous PCs. As I've been suggesting, all that's really required to reconcile the situation is central (and centrally-manageable) storage. The network bandwidth is available: I helped design a diskless fat client network 25 years ago that used multi-drop 10 Mbit Ethernet fairly effectively, and Fast Ethernet's point-to-point 100 Mbit/sec is more than adequate for any client activity short of streaming very-high-bandwidth data in bulk or heavily-parallel random access to many-disk arrays. But local storage is so in-grained in the PC mind-set (and in the Windows operating system) that such an otherwise obvious solution has yet to become the norm. It's nice that you've had good experiences using thin clients - just don't kid yourselves that they also represented the most cost-effective use of hardware and management effort (license costs for proprietary software are of course a different story: a vendor can set prices fairly arbitrarily for different configurations to maximize profit, since proprietary software tends to behave a lot less like a commodity in this regard). - bill »