Slashdot Mirror
The Challenges Of Integrating Unix And Mac OS
Schemer writes: "Wilfredo Sánchez, the lead developer on Darwin has posted his usenix paper, 'The Challenges of Integrating the Unix and Mac OS Environments' on the Web. In it he describes the difficulties and solutions to the problems encountered while trying to adapt BSD Unix for use with MacOS X. It's a very good read, even if you aren't a fan of the Macintosh." The OS X team have been dealing with the serious complications of mixing one established, beloved interface with another -- this is a thoughtful look from the inside at how they've dealt with it, and a good explanation of some underlying assumptions and conventions of each OS.
Apple might consider spending a little effort on keeping some of its biggest supporters -- developers -- happy.
I use Macs for work, Linux for education, and Windows for cardplaying.
From starting with 'case preserving' but 'case insensitive' filenames ... ??? WTF???
Excuse me for being overly indoctrinated with Li/*nix -- but something seems wrong with this.
I think you may have slightly misunderstood the thrust of the original article. The point was Apple has no choice in this. Everyone realises that its a less-than-perfect situation, but the new Mac OS X has to be able to work with the filesystems from Mac OS 9. This is an absolutely essential feature. Because HFS and HFS+ (the Mac OS 9 filesystems) are indeed both 'case preserving' and 'case insensitive', Mac OS X has to be able to handle this sort of filesystem. As Wilfredo says, in practice its not nearly as large a problem as it would appear at first glance. Which isn't to say its never a problem, of course...
If your foundation is not stable, then anything you build will also be unstable. I feel this to be the case with this filesystem.
This seems like a pretty large leap. The use of HFS+ as a Mac OS X filesystem is not at all "unstable". I have three machines running Mac OS X with pure HFS+ filesystems throughout. This really isn't an issue at all. The filesystem is about the most stable part of the entire OS :-)
Sailing over the event horizon
My greatest impression from reading the paper was one of a schizophrenic system. The differences between the two systems that form the basis for OSX seemed not to have been resolved, instead they were patched over with an additional layer of complexity, and a great deal of hope applied that the two different OS's at the core wouldn't misbehave and contradict each other.
Usually, this is the sort of thing that makes software developers run screaming down to the pub.
Charles Miler
--
The more I learn about the Internet, the more amazed I am that it works at all.
The interesting question is: should the day come that Linux implements metadata, could/would the Apple team merge the same Unix API into the BSD layer of OS-X?
www.eFax.com are spammers
A facetious statement at best. Application programmers have to rely on large bodies of code over which they have little or no control, e.g. MFC and other class libraries/frameworks.
And to say that a poor OS encourages good application engineering is silly, to say the least. An OS with memory protection, such as Windows NT, Unix or Mac OS X, makes it much more practical and efficient to debug applictions suffering from stray pointers, etc.
--
"Where, where is the town? Now, it's nothing but flowers!"
Mac OS is built like a tank in the areas that really count in the area of average user computing. A program can be installed at any time and that won't kill other, existing programs. Similarly, a program that is already installed will never preclude another program from being installed (like RPM does). And if you delete all the mac OS configuration files, programs can still run. How many times has someone installed one windows program and this has totally killed another working program? Or the registry got corrupted in one particular area and dragged other areas down with it? Or how many times has someone has tried installing a linux application, only to find out they have to screw around with environment variables to even get the program to start up. Mac OS doesn't have these problems, and in the Reality That Is The Average Joe Consumer Desktop(tm), crashing is far less of a concern than something not running at all or something screwing up the computer. A crash in this area of computing is an annoyance, something failing to work at all is completely unacceptable.
/etc, on windows delete the registry, and on MacOS, trash the preferences folder. Reboot and see which computer has the most functionality that an average computer user requires. Guarentee you it won't be the first two. Which is unfortunate since it would be great if linux and windows had the system/application integrity that consumer level usage requires. True, anyone geek enough could fix the first two computers, but keep in mind that most average joe computer users are not like us geeks.
Let's do a test. On a unix system, do rm -rf
Meta data is a seriously nifty concept if implemented correctly. BeOS has a similar (though much superior, read up on it) system called attributes. Not only does it allow for info such as icon to be stored within an attribute attached to the file, but it allows things like bookmarks to be implmented entirely as attributes. The cool thing about that is that since attributes are indexed by the file system, they are searchable database style! The contacts database is a set of files with attributes, and just by moving a file into a directory you get an instantly searchable database of contacts. Of course, it necessitates some additional stuff. open() can't read attributes (and it probably won't be able to read meta data, an alternate OS call would have to be implemented). Also, you'd have to switch to something like the .zip format because gzip and tar don't preserve attributes or metadata. If it can be done within the Linux architecture, I think it should. ReiserFS is getting database functionality eventually, and if you could connect the two, you could do some nifty tricks. (And isn't that what Linux is all about? :)
A deep unwavering belief is a sure sign you're missing something...
Transparent and flawless? I guess you've never talked to anybody who went through the 68K/PPC conversion kicking and screaming, eh?
... guess you've never talked to any Mac OS developer with a CLUE, eh?
Actually, I made a lot of money cleaning up after those idiots.
Programs I wrote in 1984 compile perfectly today. Anyone who followed Apple's rules for compatibility, which are 95% unchanged since the days when Inside Macintosh came in three-ring binders (I'm pretty much as old-school as a Mac developer gets) didn't have any significant problems then, and hasn't upgrading to Carbon today.
Now, before people jump all over me about API limitations, yes I realize that there's a lot of places where jobs have to be done in a non-compatible fashion. That's holding me up Carbonizing right now because all four projects I'm responsible for at my day job do CD ripping and there's no OS X equivalent of DV 22 yet. But if you were smart enough to ISOLATE those portions of the code which you knew would eventually be a problem, replacing them was straightforward then and is straightforward now. Well, will be once I get the new APIs anyway, I imagine.
So, to turn your question back