File types [was: Re: wide characters and i18n]

[Giles Lean <giles.lean%pobox.com@localhost>]

[ I changed the subject title; drifting, but in an interesting
  (to me, anyway) direction. --giles ]

markucz%gmail.com@localhost wrote:

> Using $FOO.app directories has always struck me as odd but I guess it has
> some advantages, like shipping all needed libraries and not depending on
> a particular version being installed systemwide.

It's a practical solution to shared library versioning hell,
of which Unix still has some (e.g. an application that depends
on a bug in a particular version of a library).

Of course, any library thus shipped with the application then
loses the benefit of being "shared", so one wonders why _that_
library shouldn't be linked statically, removing one
justification for the whole idea.

On the plus side, keeping all the image files, help files,
libexec type binaries etc with the primary executable helps
with installation and uinstallation.  (Except when you have
several applications which all use the same helper, and that
helper needs fixing ... been there, done that too, but I'd
put up with that case.)

On the gripping hand, every darn application seems to want to
maintain a cache and some state, and while there are
"standard" places to store those too, most ("most" by my
personal observation, not any scientific measurement) OS X
applications fail to include an uninstall script/program so
these are easily "left behind" when the application's .app
directory is deleted.

I still do OS upgrades via "Backup, check the backup, clean
install, reinstall applications" process. :-) :-(

> Having used MacOS only occasionally, I remain blissfully
> ignorant about its quirks and resource forks are still a
> mystery to me.

They're "alternate" data streams. Originally for program icons
and such I believe.  Officially they're deprecated.
Unofficially OS X applications and programmers can't quite
give them up, seemingly.

Windows (starting with NT?) has something similar, but that
I'm not familiar with.

For the record (and IMHO blah blah) resource forks are an
outright bad idea: directories are _designed_ for keeping
related data together.

Extended attributes (or tags of some sort) make a lot more
sense (or would, IMHO, yada yada) if they provided some
sort of MIME type file metadata about the file, and were
flexible enough to handle additional concepts like *BSD
flags (refer chflags(2), chflags(1)) etc.

ACLs (IMHO -- this whole post is IMHO :-) should not be
an add-on to traditional Unix groups: pick one or the
other, and stick to it.

In practice I have never had a situation where Unix group
membership (if necessary, with a setgid and/or setuid
accessor program) did not suffice.  About twice ACLs would
truly have been more convenient, but the lack (at least at
the time, but probably still now) of consistent semantics
(nevermind user unfamiliarity) was a showstopper.

> Sure, it would be great if there was something like magic numbers for text
> files. I guess BOM was meant to serve as such but there're too many
> UTF-16/-32 files without it.

Plus, every program has to know to expect a BOM, and as a form
of in-band signalling it has all the problems such schemes
always have.

A magic number in a binary file is different: only programs
already familiar with the file format care about the magic
number, and so can be taught to check for it at the same time
as they're taught the entire file format.

> Piping poorly generated UTF-16 text to iconv on x86 without
> explicitly specifying byte order is a great way to learn
> Chinese.

I'll take your word for it.  I once had to teach a week long
class (in English) where the only PC that could drive the
projector was cofigured for (I think) simplified Chinese. I
needed help from my students to manage things like opening
files. :-(

> Ever since I first saw BeOS I'm in love with extended
> attributes (I'm not quite sure if BeOS used xattr's or
> something else), especially because you can Just Tag Your
> Filesâ and thus avoid having to use ugly looking filenames,
> lots of symlinks, strangely organized directories or any
> combination of the above.

But it's close to all or nothing: open(), read(), write(),
close() isn't enough to replicate the file anymore.  (I
suppose, to be fair, it isn't on Unix either: you need stat(),
chown(), chmod(), etc ... but still, _every_ application that
copies files has to know about any new functionality.)

Trouble is here with NetBSD, we don't have a clean slate. We
have years of history and lots of valuable code: any
enhancements along these lines are going to be tradeoffs
between maintaining compatibility with the past (and thus
existing code) and providing new capabilities.

Change isn't impossible: we have 64bit off_t and the
commercial vendors even managed to work together for that
migration.  (Their solution wasn't ideal, perhaps, but it
_was_ usable across all the vendors' platforms who used it,
and didn't require the "flag day" that 4.4BSD had the luxury
of opting for.)

Giles