Peeve Farm

g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets

  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.

On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »

Book Plug:

Buy it and I get
money. I think.
BSD Mall

10/6/2003 -  10/8/2003
9/29/2003 -  10/5/2003
9/22/2003 -  9/28/2003
9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
8/25/2003 -  8/31/2003
8/18/2003 -  8/24/2003
8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
7/28/2003 -   8/3/2003
7/21/2003 -  7/27/2003
7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
6/30/2003 -   7/6/2003
6/23/2003 -  6/29/2003
6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
5/26/2003 -   6/1/2003
5/19/2003 -  5/25/2003
5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
4/28/2003 -   5/4/2003
4/21/2003 -  4/27/2003
4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
3/31/2003 -   4/6/2003
3/24/2003 -  3/30/2003
3/17/2003 -  3/23/2003
3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
2/24/2003 -   3/2/2003
2/17/2003 -  2/23/2003
2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
1/27/2003 -   2/2/2003
1/20/2003 -  1/26/2003
1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
12/9/2002 - 12/15/2002
12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
10/7/2002 - 10/13/2002
9/30/2002 -  10/6/2002
9/23/2002 -  9/29/2002
9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
8/26/2002 -   9/1/2002
8/19/2002 -  8/25/2002
8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
7/29/2002 -   8/4/2002
7/22/2002 -  7/28/2002
7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
6/24/2002 -  6/30/2002
6/17/2002 -  6/23/2002
6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
5/27/2002 -   6/2/2002
5/20/2002 -  5/26/2002
5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
4/29/2002 -   5/5/2002
4/22/2002 -  4/28/2002
4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
3/25/2002 -  3/31/2002
3/18/2002 -  3/24/2002
3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
2/25/2002 -   3/3/2002
2/18/2002 -  2/24/2002
2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
1/28/2002 -   2/3/2002
1/21/2002 -  1/27/2002
1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001

Tuesday, October 15, 2002
01:33 - So much for UFS, then... http://www.eweek.com/article2/0,3959,634711,00.asp	(top)
This eWeek article, pointed out by CapLion, describes a fascinating new development: journaling support for HFS. That's right... even though OS X could initially be installed on Unix-style UFS filesystems (minus Classic functionality), and even though the BSD heritage of Darwin would seem to make it more at home on UFS than on Apple's traditional HFS+, it looks as though Apple has taken the high road when it comes to server-class filesystem design. The Mac requires lots of meta-data in its filesystems. It can do without multi-forked files, as is in evidence with OS X's new "bundle" architecture rather than resource forks to handle text-string repositories, embedded graphics, and the like. And it can get by even without Type and Creator codes, a fact which has caused no small amount of consternation among traditionalist Mac users who refuse to give up our ability to associate different files of the same type independently with different applications, and all applications to be independently known to the system and to each know which file types it's capable of opening, without resorting to the ugly and error-prone hack that is the Registry, as Microsoft was forced to do through poor planning (or malice). The first version of OS X could be installed on UFS instead of HFS+, if you so chose. The benefits? Better server-class performance, less tendency toward fragmentation-- the usual UFS benefits. The drawbacks? No Type/Creator codes. There was some talk about "Extended UFS Attributes" being checked into the FreeBSD 4.x codebase about a year ago, but it's unknown exactly what their purpose was, or whether they might have been intended for use with the Mac. (I e-mailed Jordan Hubbard at the time, and even he didn't know.) The upshot, after all was said and done, was that OS X ran most richly on HFS+, and UFS gave it server-class fault-tolerance, but only as the result of some really ugly and regrettable hacking and slashing of features from the OS. Many of us pleaded with Apple not to follow the path that it seemed they were aiming for: a migration away from HFS+ and onto UFS. It looked as though they were trying to wean us off of the need for type/creator codes, resource forks, custom icons, content indexes, files that operated just fine without god damn bloody blasted filename extensions, and all the other little goodies we'd all gotten used to-- for the sake of being able to run on UFS, so Apple could sell servers. For a long time, it looked as though that was a reasonable fear. OS X 10.1 implemented the new extension-hiding thing, and it looked at first like a poorly-disguised attempt to force us into the world of filename extensions so Apple could dispense with Type/Creator codes once and for all. (It's since become clear that this move, while painful to think about too hard, actually results in vastly improved seamlessness across platforms with negligible diminishment of user experience-- while simultaneously moving us from the model of "immutable file type and creator application" to the far more useful "immutable file type and mutable opener application"; I've made my peace with the per-file extension-hiding feature, and I think it was a stroke of genius-- exactly the strategic move Apple needed in a crucial spot.) But we'd also noticed that along the way, Apple had hired quite a few notables. Jordan Hubbard, head guru of the FreeBSD project, was now Apple's chief UNIX development guy. And with the demise of Be, Apple snapped up two of the company's most central filesystem-development architects, one of whom was Dominic Giampaolo, as noted in the eWeek article. In what would that result? we wondered. Who went seeking who? Did Apple need Be's filesystem expertise, or did the ex-Be guys just need a job that kept them away from Windows? Well, it seems we now have an answer. And we no longer need to fear that Apple will take away our beloved HFS+, abandoning it in favor of the more primitive but more sturdy UFS. That's not going to happen. Whereas they could have forced us onto UFS and then implemented FreeBSD's "Soft Updates" mechanism (similar to journaling, or at least accomplishing the same goal in a rather different way), Apple has leveraged Giampaolo's know-how into a fresh new journaling layer for HFS+, ready within weeks to be deployed onto XServes just in time to be coupled with the XServe RAID system (which is scheduled to ship before year's end). Apple heard the masses speak, and they responded. What I think we can conclude from this is that a) Apple doesn't hire big-name minds indiscriminately, without a plan for what to do with those valuable neurons; and b) when the user base speaks up with a No, no, no, NO! ... Apple listens, and does what it takes to change it to a chorus of Yes, yes, YES! ...Moon... Pie! ... What a time to be alive.