OT: Re: why not OS X?

[Timothy A. Seufert]

[Warning: Offtopic digression follows, delete now if you're not 
interested in knowing some OS X esoterica.]

At 12:35 AM -0400 6/5/02, Bill Fink wrote:
>On Tue Jun 4 2002, Timothy A. Seufert wrote:
>
>>  See http://software.bombich.com/ccc.html .  Free tool.  It's nothing
>>  more than an AppleScript which copies files around using command line
>>  tools included with the system, but it makes creating images or
>>  cloning drives quite easy.
>
>This sounded really interesting until I checked it out and discovered
>that it didn't seem to support cloning to a network volume.  MacOS 9
>is easy to clone across the network by just dragging all the top level
>folders to the target system, remembering to copy a copy of the system
>folder, and then tweaking a few network configuration parameters on the
>new system, at which point you have a nice standard installation on the
>new system.  But you can't do the same thing with MacOS X because they
>decided to make all the unix underpinnings be invisible files, arggggg.

Only some of the unix information is stored in the invisible files 
you're thinking of: mainly stuff like hard/soft link emulation. 
Other things like the unix permission bits live in the same 
structures that store traditional Mac metadata  (the designers of 
HFS+ knew it might be required to host other operating systems and 
left some space for expansion)

I think the issue is that the AFP protocol simply doesn't support the 
extra HFS+ file attributes OS X needs -- not even filenames longer 
than 31 characters.  (I've seen filenames truncated to 31 when 
copying via AFP.)

There is a simple workaround: create a HFS+ disk image on the remote 
FS, mount the image, and clone to it.  That's the method suggested by 
Mike Bombich for using CCC to perform clones over the network.

>The other main problem I see is that AFAIK there is no package manager
>for MacOS X, i.e. it's basically one monolithic system (please correct
>me if I'm mistaken).  This would make it a nightmare to manage, as opposed
>to rpm which lets you do such things as check what packages specific files
>belong to, easily remove or update packages, or be able to verify the
>integrity of installed packages (in case of disk corruption or suspicion
>of possibly being hacked).  I'm not aware of such capabilities with
>MacOS X, but since I'm not that conversant with it at the moment, it's
>possibly just my ignorance.

There is a packaging system, inherited from NeXT, and it does track 
dependencies/requirements to some extent.  For example I just tried 
installing the 10.1.3 update package on a 10.1.4 system, and 
Installer.app knew it shouldn't even let me try to install that 
package.

Look at /Library/Receipts -- that's where records for installed 
packages are kept.  The records consist of most of the actual package 
bundle except for the meat (the pax archive containing the actual 
files to be installed).  Package contents and file checksums and 
other information is recorded in PackageName.bom.   You can list a 
*.bom file with the lsbom command.

It is not a proper database like RPM.  And I don't think it was 
designed to do everything RPM does (of course, it is much older than 
RPM; I don't think anybody was doing RPM-like things when NeXT 
invented its package system).  For example, I don't think there is 
really any provision for uninstall, and Apple certainly doesn't 
encourage use of it that way because their own packages are very very 
coarse rather than fine grained like RPMs.  (Meaning that when you 
install a 10.1.x update, it may have a new version of iTunes, a 
replacement kernel, and sendmail updates all in one gigantic package. 
That's why your impression is of a monolithic system; the Apple 
supplied packages effectively make it one.)

Without a true package database and fine grained packages, I don't 
think you can do all of what Konstantin wanted with regards to 
automatically distributing updates.  You probably could do some of 
it, especially if you were willing to create your own packages and 
dependencies and write some scripts to automate the process of 
checking for and installing packages.  (Installer.app doesn't do the 
real work of unpacking and copying files; it's just a shell around 
some command line tools such as pax and ditto.  So you can probably 
replace it with shell scripts.)

There has been discussion on the desirability of a better packaging 
system for MacOS X / Darwin on some of the darwin mailing lists, and 
it was clear that people at Apple do realize the need for one 
(especially Jordan Hubbard).  Unfortunately I don't think much action 
has happened yet.
-- 
Tim Seufert