Linked by Scot Hacker on Mon 17th Dec 2001 17:34 UTC
The story of how a BeOS refugee (and not just everyone, but the author of the 'BeOS Bible' book) lost faith in the future of computing, resigned himself to Windows but found himself bored silly, tore out half his hair at the helm of a Linux box, then rediscovered the joy of computing in MacOSX. Scot Hacker will describe his personal adventures with today's operating systems after he was set out to find an alternative to his beloved (but with no apparent future) BeOS. Update: Make sure you read the second part of the article, a rebutal, found here.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Just some minor corrections.
* HFS+ supports large files, like BFS. It also has support in the volume format for arbitrary attributes, though I don't know if the API is actually wired up in Mac OS X; it wasn't in Mac OS 9. (A file's data and resource forks are just attributes.) HFS+ will also always be case-insensitive but case-preserving; the volume format is fixed, and can't be changed like that in a backwards-compatible way. But filesystem plug-ins can be written for Mac OS X, so if someone wanted to create a case-sensitive HFS+ (with a different volume type) it shouldn't be too tough.
* Getting long filename support in Carbon applications isn't necessarily difficult, but it is a little tedious because it can mean revising a significant amount of your code for dealing with files.
* BMessages were conceptually based on a technology Apple introduced with System 7 called AppleEvents. The AppleEvent Object Model is a set of conventions used to specify objects and actions within scriptable applications. AppleScript is built around the AEOM, but it's not the only language that can work with it; you can use any language as long as it can call the Apple Event Manager. (Some languages might force you to do this directly, like C, while others might do things like use terminology dictionaries to map between higher-level constructs and AppleEvents that particular applications respond to.)
* Apple has some of the infrastructure for filesystem and network notifications in the Darwin kernel right now. Plus they employ Jordan Hubbard, one of the movers behind FreeBSD, which does have such technology (under the name "kernel queues and events"). I bet this is on their to-do list, though it isn't available now. In the meantime, there are calls in the File Manager and in Cocoa that let you tell the Finder that you've changed an item so it can update. I haven't used them though so I don't know how well they work.
* You say several times that Mac OS X uses Display PostScript or uses PostScript for its imaging. NeXT did just this in NEXTSTEP and OPENSTEP. However, Core Graphics in Mac OS X is based on the PostScript imaging model -- the mathematical model PostScript uses to describe pages -- but it doesn't actually use PostScript internally. It's also not "Display PDF" as some people erroneously describe it; applications don't construct PDF documents and then send them to Core Graphics for display. Since the imaging model is the same it uses PDF as its metafile format, but that's not quite the same thing...
-- Chris