Re: Bochs - Free PC emulator
Re: Bochs - Free PC emulator
- Subject: Re: Bochs - Free PC emulator
- From: Charles Srstka <email@hidden>
- Date: Sat, 5 Oct 2002 10:51:17 -0500
On Saturday, October 5, 2002, at 06:57 AM, Wade Tregaskis wrote:
Tar, gzip, bz2, etc. trash MacOS metadata and resource forks and thus
should not be used to distribute Mac files.
Should not be used for files which use these obsolete things. For
those that do, sit of course has support for these legacy items.
Hey, resource forks may be deprecated, but the last time I checked,
file system metadata was certainly not. Things like creation dates and
custom icons are certainly still used, and should be preserved.
Also, what seems to be missed here is the fact that 90% of files
downloaded by your average user don't contain executable items.
Images, text files, icon libraries, etc. I don't want some bloated
disc image just for a few icons.
Well, two of those items (images and text files) usually don't need to
be compressed anyway, so that doesn't really matter. At any rate, I was
specifically talking about distributing *software* in this thread.
StuffIt is a proprietary format and can trash UNIX metadata such as
file permissions. In addition, it has a nasty habit of truncating
long filenames. The new version of StuffIt corrects these problems,
but has other bugs, still is proprietary, still costs money, and to
boot there's no guarantee that your users will have the latest
StuffIt Expander.
StuffIt Expander ships with OS X. Even if for some reason you've
deleted it, it's a free download. It doesn't hassle you to register
or anything similar, and can be easily configured to operate
transparently in the background. It's ability to decompress files
into a specific directory is most useful.
The latest version of Expander, which is necessary to extract the
latest version of the StuffIt format, does not ship with OS X, since it
came out later than OS X. There is no way to guarantee that users will
have it. It does not operate in the background - it jumps to the front
every time it is used. Its ability to decompress files is only useful
to those who know about holding down the 'option' key while it is
launched. To all other users, the ability to simply drag and drop a
file wherever they want is much more intuitive and useful.
If permissions and the like are an issue, you should probably use a
custom installer - there's no guarantee anything will be preserved
even with disc images.
Even better, make your app not rely on any specific permissions -
who's to say they won't be changed at any time anyway? If it must
have certain permissions, it should deal with them itself.
And by the same reasoning, one should never name a file longer than the
old 32 character limit?
Disk images are easy to use, are guaranteed preserve *any* metadata
that the file system can support, and are supported by all versions
of Mac OS X, out of the box. In addition, disk images have some nifty
little features like the ability to mount remotely over the network
using the "hdiutil" command-line tool, allowing you to just get one
file out of an archive without having to download the whole thing,
and download without leaving a garbage file behind on the desktop.
Disk images take forever to mount, are buggy to eject and manipulate,
as mentioned, and are a general pain. Ever tried to mount a thousand
or so at once? If you start now you might be able to before your
computer rusts.
Buggy to eject and manipulate in what way? Does it do buggy things
like, say, mutilate file names as Expander does? Does it screw up
.tar.gz files like Expander does? Does it hose UNIX metadata like
Expander does? Does it randomly fail to open archives like Expander
does? Does it delete the archive afterwards, even after a failed
extraction, like Expander does?!
I've never had any problems with disk images being buggy. Expander,
though, is buggy enough to be legendary.
BTW, how many users are going to want to open 1000 disk images at a
time?
If disc images could be browsed like folders, could be mounted
somewhere away from the real volumes (maybe into a specific
user-determined folder), and/or could have their contents extracted to
a user-determined location by default, then they'd actually be usable.
Oh, and if they worked a heck of a lot faster than they do now.
1. You most certainly can browse disk images like folders. Just
double-click the mounted disk image's icon. This is part of the beauty
of disk images. You can even browse them without downloading their
contents, via hdiutil (really handy when you just want to read the read
me or get one app from a 20 MB application suite package without
downloading the whole thing!).
2. You can easily mount them somewhere other than /Volumes via the
command line. You could even probably whip up a really quick Cocoa app
to automate this.
3. Drag-and-drop is an essential part of the Mac OS X metaphor which is
not going to go away (nor should it!). This is the way of the future,
and it is how you install files. If it bothers you, I guess you could
write a quick Cocoa app to copy the entire contents of a disk image to
some pre-determined location.
Oh, and Apple recommends it too.
Apple does a lot of things, and some of them aren't very intelligent.
File extensions come to mind. And metadata & resource forks. But
then again you don't seem to have a problem breaking the rules
there... selective hearing, maybe?
Hey, cut the ad hominem attacks. We're all friends here, regardless
whether we disagree on things.
Only thing I'll comment on that is that if file extensions and metadata
are *both* bad, then how on earth is the machine supposed to know what
type a file is?!
Charles
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.