3 ms·

> are so badly designed Why are they badly designed? There are a huge amount of bright OS hackers in the world, and a huge amount of mindshare on the problem.

> are so badly designed Why are they badly designed? There are a huge amount of bright OS hackers in the world, and a huge amount of mindshare on the problem. When the culmination of all this effort continues to be hilarious[1], I can only conclude that the problem is less tractable than we expected. And in fact, that is what the people who work on the problem say[2]: that it is not tractable. [1] http://en.wikipedia.org/wiki/Bush_hid_the_facts http://en.wikipedia.org/wiki/Bush_hid_the_facts [2] http://blogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspx http://blogs.msdn.com/b/oldnewthing/archive/2007/04/17/21583...

jfb 13y ago
I'm not denying that fixing the problem requires a rethink. I guess I'm still just feeling beat up by the removal of the admittedly imperfect first class metadata from HFS in favor of file extensions. Roll that progress back, folks. Make NFS happy. EDIT: I don't believe that the problem is tractable in a world where you need to maintain backwards compatibility; the solution then to me is ditch backwards compatibility. I almost always prefer elegant solutions to practical ones.
- drewcrawford 13y ago
  > the solution then to me is ditch backwards compatibility. Backwards compatibility is a visible problem, but it isn't the True Problem with creatorcodes/metadata. The true problem is that a world with metadata is an unstable equilibrium, because what if just this once we get it wrong. * Consider the case that the file's author got it wrong * Consider the case of Python and RPython (or .js and .json, or .txt and .md) where a file can belong to multiple classes. Further consider the case where a system has a Python interpreter but not an RPython interpreter installed (or a JavaScript interpreter but not a JSON parser, or a text editor but not a MarkDown editor, or...) * Consider the case where a document was saved with Excel 2013, but just happens to only use Excel 2010 features, because who really cares about whatever the heck they add in each new Office release * Consider the case of a container format, like mkv or mp4, that does not alone completely describe the format of the data it contains * Consider the case of sometimes-interchangable formats like m4a and m4b, mp4 and m4v, etc. * Consider the difference between a storage format (.sqlite3) and the data that it contains (.localstorage, Firefox/Profiles/places.sqlite, ~/Library/Mail/V2/MailData/Envelope Index) * Consider the case that that one day somebody just wants to make a "monkey-fighting file without filling out this monday-to-friday questionnaire" and either the "no really, it's a file" creator code is accepted by the International Body of Creator Codes, or it isn't and so there are five incompatible implementations. As soon as you tolerate any of these (and probably the list is a lot longer than this), we are right back where we are now: trying to guess what kind of file it is by poking at it with a stick. Backwards compatibility is a red herring.

jfb 13y ago

I'm not denying that fixing the problem requires a rethink. I guess I'm still just feeling beat up by the removal of the admittedly imperfect first class metadata from HFS in favor of file extensions. Roll that progress back, folks. Make NFS happy. EDIT: I don't believe that the problem is tractable in a world where you need to maintain backwards compatibility; the solution then to me is ditch backwards compatibility. I almost always prefer elegant solutions to practical ones.

drewcrawford 13y ago
> the solution then to me is ditch backwards compatibility. Backwards compatibility is a visible problem, but it isn't the True Problem with creatorcodes/metadata. The true problem is that a world with metadata is an unstable equilibrium, because what if just this once we get it wrong. * Consider the case that the file's author got it wrong * Consider the case of Python and RPython (or .js and .json, or .txt and .md) where a file can belong to multiple classes. Further consider the case where a system has a Python interpreter but not an RPython interpreter installed (or a JavaScript interpreter but not a JSON parser, or a text editor but not a MarkDown editor, or...) * Consider the case where a document was saved with Excel 2013, but just happens to only use Excel 2010 features, because who really cares about whatever the heck they add in each new Office release * Consider the case of a container format, like mkv or mp4, that does not alone completely describe the format of the data it contains * Consider the case of sometimes-interchangable formats like m4a and m4b, mp4 and m4v, etc. * Consider the difference between a storage format (.sqlite3) and the data that it contains (.localstorage, Firefox/Profiles/places.sqlite, ~/Library/Mail/V2/MailData/Envelope Index) * Consider the case that that one day somebody just wants to make a "monkey-fighting file without filling out this monday-to-friday questionnaire" and either the "no really, it's a file" creator code is accepted by the International Body of Creator Codes, or it isn't and so there are five incompatible implementations. As soon as you tolerate any of these (and probably the list is a lot longer than this), we are right back where we are now: trying to guess what kind of file it is by poking at it with a stick. Backwards compatibility is a red herring.