From: Nicholas Clark Date: 21:18 on 31 Oct 2005 Subject: Preview $ file ~/tmp/Printout /Users/nick/tmp/Printout: PostScript document text conforming at level 2.0 I don't care what its fucking name is. It's postscript. Damn well open it. Don't sit there with your pathetic dialogue box showing it greyed out because it doesn't conform to your numskull blinkered idea of how files should be named. I am the user and I am right dammit. Not Steve fucking Jobs. Nicholas Clark
From: Luke Kanies Date: 21:34 on 31 Oct 2005 Subject: Re: Preview On Mon, 31 Oct 2005, Nicholas Clark wrote: > $ file ~/tmp/Printout > /Users/nick/tmp/Printout: PostScript document text conforming at level 2.0 > > I don't care what its fucking name is. It's postscript. Damn well open it. > Don't sit there with your pathetic dialogue box showing it greyed out because > it doesn't conform to your numskull blinkered idea of how files should be > named. > > I am the user and I am right dammit. Not Steve fucking Jobs. I have been mucking around with address books, trying to have some semblance of unity between the 50 or so areas I store information about contacts. Apple's Address Book deserves quite a heap of hate right now, considering that it crashed about every third edit, and in case you missed my last hate about AddressBook, remember that if it crashes twice on you and you hit the 'try again' button, it will delete your preferences. Which preferences? More than you want, I guarantee that, and even though the dialog says "temporary", I think they mean, "they'll be gone until you recreate each of them manually". It at least deletes your AddressBook and your Appearance preferences. Yes, Appearance. But the thing I'm writing about, the thing that pissed me off the most, is that it would literally refuse to acknowledge a file full of VCards because that file did not have the right extension. Even dragging the stupid file onto the window got zero response. This is exactly the kind of absolute stupidity that I feared when Apple announced their retarded "we're going to store important metadata in the file name" policy. The worst part was that I had to actually export some existing entries to figure out what the right extension is. Rename the file, whammo, things work just fine. What a stupid, stupid idea.
From: Daniel Pittman
Date: 23:18 on 31 Oct 2005
Subject: Re: Preview
Luke Kanies <luke@xxxxxxx.xxx> writes:
> On Mon, 31 Oct 2005, Nicholas Clark wrote:
[...]
> But the thing I'm writing about, the thing that pissed me off the most, is
> that it would literally refuse to acknowledge a file full of VCards because
> that file did not have the right extension. Even dragging the stupid file
> onto the window got zero response.
>
> This is exactly the kind of absolute stupidity that I feared when Apple
> announced their retarded "we're going to store important metadata in the
> file name" policy. The worst part was that I had to actually export some
> existing entries to figure out what the right extension is. Rename the
> file, whammo, things work just fine.
Bah. This is exactly the same hate as it was when Apple used to store
important metadata in their special little eight bytes somewhere other
than the filename.
At least you can /change/ the filename without having to find and
install some sort of magic file blessing tool to alter those bytes into
making your application identify them.
Painful and stupid: not actually considering file content when you look
to opening, or not opening, a file.
Painful and stupid: the idea that there is one, and only one, thing that
is solely responsible for a file, and nothing should be able to change
that.
Not that any platform is substantially better at this.
Daniel
From: Luke Kanies Date: 23:23 on 31 Oct 2005 Subject: Re: Preview On Tue, 1 Nov 2005, Daniel Pittman wrote: > Bah. This is exactly the same hate as it was when Apple used to store > important metadata in their special little eight bytes somewhere other > than the filename. While I won't disagree with the technical truth of that, the previous system had a kind of bias towards doing what you wanted and expected (i.e., if it doesn't seem to work, try a few other things out). I know that systems relying on file extensions generally have a bias against helping the user out, and I was afraid that Apple would acquire that bias. Unfortunately, at least some of their apps seem to have. > At least you can /change/ the filename without having to find and > install some sort of magic file blessing tool to alter those bytes into > making your application identify them. > > Painful and stupid: not actually considering file content when you look > to opening, or not opening, a file. Yeah, this is the real problem. > Painful and stupid: the idea that there is one, and only one, thing that > is solely responsible for a file, and nothing should be able to change > that. The previous system was pretty good when it was developed, but it was retained far too long. > Not that any platform is substantially better at this. BeOS's system was pretty sweet, and I just don't understand why people haven't stolen it, or at least something like it. Dammit.
From: Peter da Silva Date: 01:30 on 01 Nov 2005 Subject: Re: Preview >> Not that any platform is substantially better at this. Traditional UNIX apps used to look for files with the right extensions but happily ignore them if you told them otherwise, with a few exceptions (eg, the old trick of linking "tty.c" to "/dev/tty" so you could type code in and avoid creating a file). > BeOS's system was pretty sweet, and I just don't understand why people > haven't stolen it, or at least something like it. Dammit. Because: 1. if your applications are smart enough to ignore the metadata when you know better, you don't need it. 2. if they're not, you're just as boned.
From: Luke Kanies Date: 00:58 on 02 Nov 2005 Subject: Re: Preview On Mon, 31 Oct 2005, Peter da Silva wrote: > >> Not that any platform is substantially better at this. > > Traditional UNIX apps used to look for files with the right extensions > but happily ignore them if you told them otherwise, with a few > exceptions (eg, the old trick of linking "tty.c" to "/dev/tty" so you > could type code in and avoid creating a file). Traditional Unix apps don't seem to do anything with extensions; they don't really seem to do any sort of filetype recognition at all, from what I can tell. I'm sure there are exceptions, but everything I've seen just uses extensions for the humans. > > BeOS's system was pretty sweet, and I just don't understand why people > > haven't stolen it, or at least something like it. Dammit. > > Because: > > 1. if your applications are smart enough to ignore the metadata when > you know better, you don't need it. > > 2. if they're not, you're just as boned. It's just silly to require that kind of intelligence in every application, though. Your operating system should support those kind of operations as a service, both retrieving the existing metadata and dealing with wanting to override it.
From: Abigail Date: 01:37 on 02 Nov 2005 Subject: Re: Preview On Tue, Nov 01, 2005 at 06:58:49PM -0600, Luke Kanies wrote: > On Mon, 31 Oct 2005, Peter da Silva wrote: > > > >> Not that any platform is substantially better at this. > > > > Traditional UNIX apps used to look for files with the right extensions > > but happily ignore them if you told them otherwise, with a few > > exceptions (eg, the old trick of linking "tty.c" to "/dev/tty" so you > > could type code in and avoid creating a file). > > Traditional Unix apps don't seem to do anything with extensions; they don't > really seem to do any sort of filetype recognition at all, from what I can > tell. I'm sure there are exceptions, but everything I've seen just uses > extensions for the humans. HTTP servers often use file extensions to determine which MIME type to sell the document for. Mail clients often do the same when you attach a file. Make is the classical example of a traditional Unix application that use extensions to "do something". I think that using file extensions without an governing body to decide what an extension means sucks. I think that using magic bytes without a governing body to determine what which byte mean sucks as well. Both suck because anyone can pick anything, and clashes are determined too late. But worse are OSses where some applications use magic bytes, and some applications use extensions. Abigail
From: Peter da Silva Date: 03:01 on 02 Nov 2005 Subject: Re: Preview On Nov 1, 2005, at 6:58 PM, Luke Kanies wrote: > Traditional Unix apps don't seem to do anything with extensions; they > don't > really seem to do any sort of filetype recognition at all, from what I > can > tell. I'm sure there are exceptions, but everything I've seen just > uses > extensions for the humans. The big traditional exception is "cc". But, yes, that's what I mean when I say UNIX does a better job with it. > It's just silly to require that kind of intelligence in every > application, > though. Your operating system should support those kind of operations > as a > service, both retrieving the existing metadata and dealing with > wanting to > override it. The only program that can be expected to create, refresh, or otherwise organize and manage any *important* metadata associated with a file (that is, stuff that needs to be there for the application to work) is the application itself. By definition, application-specific information is application-specific. BeOS metadata is useful for humans in organizing and managing information about files at a higher level, but it's no better a place to put stuff like hard file types than resource forks, finder info, or file extensions.
From: Luke Kanies Date: 03:09 on 02 Nov 2005 Subject: Re: Preview On Tue, 1 Nov 2005, Peter da Silva wrote: > BeOS metadata is useful for humans in organizing and managing > information about files at a higher level, but it's no better a place > to put stuff like hard file types than resource forks, finder info, or > file extensions. I don't really mean BeOS's mechanism for storing the types -- I really don't care and I really don't actually want to know. I mean its system for handling them in general, both the MIME heirarchy for specifying them, and the flexibility the system provided for applications to register an ability to handle types. There were essentially no data/application relationships that I wanted but could not model with BeOS, and it also helpfully provided, out of the box, a simple application for managing preferences, which is still stupidly lacking in OS X.
From: Peter da Silva Date: 01:26 on 01 Nov 2005 Subject: Re: Preview On Oct 31, 2005, at 3:34 PM, Luke Kanies wrote: > This is exactly the kind of absolute stupidity that I feared when Apple > announced their retarded "we're going to store important metadata in > the > file name" policy. It's less retarded than the "we're going to store important data (including the actual content of the file in some cases) in one hidden file AND store important metadata in another hidden file" policy they're moving (too slowly) away from. The retarded part, of course is to treat ANY metadata as more than hints. It should at the most be index and commentary, or a cache for information a program can AND DOES routinely extract from the file content and the user's actions.
Generated at 10:26 on 16 Apr 2008 by mariachi