Myth is all about tactics. There's no resource building at all. Each player starts with access to the same resources: a certain number of "points" that can be used to "purchase" troops at the start of a match. The number and types of troops available to purchase are set by the map designer. (There's also an optional, customizable time limit on making these purchase decisions, just to make it even more fun:-) Once the match starts, that's it: no more troops for you.
This is the best system for a tactics-oriented RTS game I've ever seen, and I was surprised when every other similar game didn't immediately copy it (and the real 3D terrain:-) It makes every single troop--every single annoying little arrow stuck into every troop!--very important. (Yes, you will wail in pain when you lose your one dwarf:-) And the terrain actually makes a huge difference in the game, unlike in many other RTS-ish games where it's either it's just a passable yes/no issue.
Myth maps can be unbalanced, of course, heavily favoring one particular strategy, but the game itself does not force this at all, which is the big difference. Great maps in Myth are sublime, making even people who have played them thousands of times think hard during every game.
Myth ruined me for the click-fest, isometric, resource building, bum-rush RTS games. It's not a super-complex "realistic" war game, nor is it artificially limiting. It's the perfect balance, IMO.
The problem is, when you let third parties modify the menu bar, they always do it, whether the user wants them to or not. I remember back in Mac OS 9 and before, every software developer wanted their application to be right up front, so it seems everybody was sticking inits in the Extension folder so they could have their own menu bar icon. Microsoft would add one for some sort of shortcut. Palm adds one to access Palm Desktop. Power On Software would stick one on there for their contact manager. I personally found it annoying that these apps would unnecessarily clutter the menu bar, forcing me to dig through through the System Folder to get rid of whatever they stuck in there. It was even more annoying that under Mac OS 9 you have to reboot after removing an init.
Yeah, but now imagine that you could simply drag those annoying menus off the menu bar and they'd disappear in a puff of smoke. Welcome to the 10.1 "Menu Extras" API. It should be open to everyone, not just Apple. The usefulness far outweighs the potential for annoyance.
Man, it never fails...I always have moderator access to stories involving me. Anyway, now that I've forfeitted it, but while I still have a chance of being scored up, I'd like to pimp the Apple topic icons I emailed to Malda (where procmail no-doubt sent them to/dev/null:-P) The current one is just plain ugly, IMO. How about this instead? (Two versions of the same thing)
http://siracusa.home.mindspring.com/images/topic ap ple-1.gif
http://siracusa.home.mindspring.com/images/topic ap ple-2.gif
Did you notice that cunning $a == $b != NaN test in operator:EQ? This lovely Perl 6 idiom solves the problem of numerical comparisons between non-numeric strings.
which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.
I'm wasn't trying to say that unix tools and apps depend on file types, but on filename extensions. Apple wants to use software like GCC which treats.c and.h and.cpp differently. Apple wants to use Apache which uses extensions to set outgoing MIME types. That sort of thing. I tend to think that Apple's decision to support filename extensions is a natural decision to make given OS X's Unix base.
Supporting file name extensions (i.e. parsing and understanding them) is desirable. Forcing them to be used even when they are not necessary (e.g. with more typical Mac user apps like Word or Photoshop) is not. Apple's policy does not even address Unix tools, which, of course, will continue to function as they always have. And even Apple's own developer tools and IDE will, of course, keep dealing with foo.h and blah.c. But "user-land" apps like word processors and such are also *required* to append file name extensions. That's the big issue, not what goes on in the Unix side of things or in the realm of application development.
What the author of the article is missing is that what he calls "File Type" is actually representing two (or more) things.
1. The type of data represented by the file. This can be used to help an application know how to load the data, or more importantly, to help the USER know what is contained in that file.
2. The application which the user prefers to view/edit this file with. This depends on the user, on the machine, on what apps are installed, etc.
IMHO, he is too tied to the one-type-one-app view of the world.
Er, which article are you reading? I specifically make the distinction between the existence of type metadata and the application binding policy--several times!:-)
Ars said the file names were limited to 32 characters, and I corrected them by saying 31.
Where does the article say that? You're right about the length, and I'd like to correct it if I made that mistake. But I can't find any mention of 32-character file name limits in the article.
There is still a problem with considering the file type as immutable. Some data can be interpreted as a text file, a C source file, a perl script, etc. There are times when the VERY SAME DATA can be interpreted in different ways, and it's not just a matter of accuracy.
As I posted earlier, I think it is. What you really want to say is that a file is simultaneously several types. This is simply a matter of accuracy, just as indicating that a file is both "text" and "HTML" is an increase in accuracy over just calling it "text." That fact that "text" and "HTML" have parent-->child relationship instead of a sibling relationship (as may be the case in some file that is both valid "Spreadsheet data" and "Address book data", for example) does not change the fact that it is merely an increase in the accuracy/resolution of the file type data.
Sorry, but from my perspective, the association of a file type that is unable to be changed without changing the data is wrong for the simple reason that a file may have more than one type!
Yes, index.html is an HTML formatted file - yet it's also a TEXT file
Both hierarchical types and file type accuracy/resolution (which is what you're getting at) were addressed in the article.
It's true the older MacOS file type methodology worked well when the Mac was used as a much more limited system. The fact that MacOS X includes Apache is an example of how much more versatile the Mac is today. In order to be more versatile, you have to reduce some things to the LCD. To do otherwise limits the usage of the system and that's exactly why the Mac has remained the cherished possession of so few. To expand market share, Apple needs to expand the uses of the Mac - that means more flexability, and less stringent ties to those technologies (however useful in old-school aspects) that limit that flexability.
To quote the article, "any part of the Mac OS user experience that exactly duplicates the experience on another platform ceases to be a compelling reason to buy a Mac." Furthermore, regressing to more primitive metadata just as the rest of the industry progresses to more sophisticated metadata (e.g. MS's Blackcomb/SQL file system rumblings) would be a very bad move.
Aren't you confusing metadata storage issues with app policies that may be based on them, when you bring up.txt.vbs files as an argument?
No, I'm directly addressing a particular OS policy at that point. Storing file type metadata is good. Storing it encoded in the file name is not so good. Optionally hiding that part of the file name is a dangerous OS policy.
If the file type is a short string that happens to be stored by the OS as part of the name, but the user never sees the type because it is hidden, then how exactly is that worse than the data being stored in a seperate filesystem structure? The only user-visible difference I can see is that the max filename length would be shortened by a few characters.
Here are a few problems off the top of my head. There's the "5 files named 'foo'" problem in dirs with foo.c, foo.h, foo.gif, foo.txt, and foo.html. Then there's the fact that other views of the file system (say, FTP or web) will see different names than the local user does. Totally restricting access to part of the file name is too limiting, so the possibility of mucking up the file type during the seemingly unrelated task of editing the name also exists. And, of course, there's the virus-spreading problem mentioned earlier.
MacOS X has a Unix base, and one of the goals was obviously compatibility with Unix software. Wouldn't this explain Apple's move towards file extensions better than the reasons you give in your paper?
No, because Unix doesn't make any file type distinctionsat the OS level (beyond character/block/special, etc.), so nothing Apple chooses to do on the "Mac" side of things is likely to impact Unix tools and apps, which will continue to work the way they always have.
Immutable or data-dependent, they're both inaccurate when discussing file types. Unless you can have a definitive and assuredly correct description of what exactly is in that file, you're bound to be wrong on occasion.
You can be wrong about a person's gender too. Does that make gender as mutable as a person's name?
As well, I'm not entirely convinced that it's important to have a definitive description of a file's contents; frequently a user will open a file in an app that isn't designed to handle it, intentionally.
Nothing about storing file type metadata prevents this. You're confusing metadata storage with OS policies that may be based on it.
You yourself state in the article that "metadata [...] is distinct from the data itself" and "metadata [...] is often difficult (or impossible) to add once it is lost" (suggesting that metadata isn't even derivable from the file's data).
Where did I say that metadata isn't derivable from the data? I said that some metadata, like size and type, is actually directly tied to the data. And I said that "metadata [...] is often difficult (or impossible) to add once it is lost", not "always."
a file's size is part of the file's data
Tell me where in a file's data I can read the file size. It is intrinsic (just as type is), but it is still metadata.
file size is always preserved when files transit through systems, even when those systems don't support any type of metadata.
They support essential metadata: metadata that is needed to access the file like name, location, and size.
Since implementation is irrelevant in the Fundamentals section, it makes no sense to pick a particular implementation as an argument to tie modification time to file contents and so come up with an "immutable" categorization of metadata.
I had to pick semantics for all the example metadata in the fundamentals section. It just so happens that modification date semantics vary more than the others in the real world, which is what's leading you into implementation thoughts.
In general, I stand by my claim that there's no purpose in cobbling together special categories of metadata.
I think there are clear categories, regardless of what you choose call them.
John argues that the OS can handle flattening files and creating file extensions when they are written to transports & filesystems that don't support the MacOS metadata properly.
Actually, one of my points was that "flattening" is no longer necessary in OS X (in the future, anyway) since resource forks are now deprecated.
This relies on the MacOS always having appropriate mappings between filetype/creator codes and those annoying DOS extensions - not something that is always possible.
Yes, the same way it is possible that a particular Windows machine will not know what a ".qyz" file is. No matter what the file type metadata system, there will always be "unrecognized" file types even when the file type metadata is present.
Furthermore in an increasingly networked future it's not always assured that files will pass directly in & out through the OS but rather will likely just as often come & go through alternate transports, all of which would have to all be rewritten to support this.
...or users who want to use such protocols can simply choose to have their apps append file name extensions. Again, my objection is to making them mandatory in OS X.
And yes, long term, all network protocols should support extensible metadata:-)
Personally I would always prefer any extension-addition be made and clearly communicated when I explicitly create a file and not later when it passes in and out of MacOS-metadata-supporting networks and filesystems. Just as John is appalled at the proposal for hiding these extensions from the user's view I'd be appalled at their being automagically added to my file's names at some later date when they may get moved around or viewed from another OS.
See above. Configuration is desirable. Forcing extensions everywhere is the big problem, just as forcing the lack of extensions would be, were some OS to do so.
Finally John views the possibility of Apple moving from it's MacOS X HFS+ native filesystem to some other with alarm; I see this as evolution.
The alarm is based on the speculated move away from file type metadata stored separately from the file name. I have no particular attachment to HFS/HFS+. Any file system with (preferably extensible) metadata support will do:-)
"There are three people in this room with me. Their names are: John, Sarah, and Matt"
Just by telling you their names, you also know something about their types:
John is male
Sarah is female
Matt is male
Or so you choose to assume! And what about Pat or Toby or Morgan?
A name is supposed to describe the object it represents.
If Matt changes his (or her;-) name to Morgan, does his/her sex change as well?
From the article:
Any part of the Mac OS user experience that exactly duplicates the experience on another platform ceases to be a compelling reason to buy a Mac.
I totally disagree. I had absolutely no interest in Macs until OS X, and the reason I switched was because it acts just like a *nix.
The fact that you can run Unix apps may have removed a reason for you to avoid Mac OS, but it is not a compelling reason to switch in and of itself. If Mac OS X acts "just like Unix", why would you switch to it from Unix? Obviously there was some other compelling reason to switch--something that differentiates it from other OSes that are also Unix or Unix-like. Those differences are what make people switch. Features that are the same merely remove those features form the decision making process.
P.S.-If you read any of the reader mail from my OS X reviews, you'd know that I'm really a PC bigot;-)
Barring anything academic, experimental, or "fancy," it's pretty clear he's never tried to think about UNIX linked-list style filesystems
I assure you, that's not the case:)
within the framework of his discussion, I would assert that a file's name is not part of its essential metadata in a UNIX-style FS. Why? All of the file information is contained in the file's inode and data blocks (the immediate decomposition into metadata and data being obvious). [...] unless one is willing to assert that inode + data blocks don't constitute a file, and that each instance of a reference to a particular inode is to be considered a file.
But you can't get at the inode without the file's name and location. Inodes are not suitable as file identifiers since they are not guaranteed to be unique across the multiple disks that make up a given file system. The combination of the file name and location is unique in a given file system. "inode + data blocks" do constitute a file, but the file is inaccessible unless the file name and location are known. Therefore the file name is still essential metadata on a Unix-style file system.
Furthermore, the examples of "immutable" metadata (ill-considered vocabulary in the first place, I think)...
I considered "data-dependent", but stuck with immutable, for better or for worse.
...are poorly considered. File size can be altered without altering the underlying data on BSD-style unices that provide truncation and extension system calls.
Truncation is a modification of the data.
Modification time often gets changed on many systems without any change to the underlying data
See my previous post on the topic. Yes, the semantics of modification date vary wildly. But there's no reason that the semantics I chose in the example in the fundamentals section (which tries to ignore existing implementations) couldn't exist.
"File type" is essentially a nonsense notion on most UNIX filesystems
I agree, which is one of the reasons I didn't address the Unix philosophy of reducing everything to a sequence of bytes or blocks at the OS level.
the notion of file type is at least partially bogus. There's nothing to stop me from interpreting data many differnt ways: an XPM is something I can edit with an ordinary text editor, and hence a file of type "text," but it can also define pixmaps, so depending on what I want to do with it, it might be of at least two file types.
What you want is a type hierarchy that indicates that XPM is of general type "text" and, more specifically, it is an X pixmap. There's nothing "bogus" about the notion of file type. I think you're unnecessarily constraining yourself to very simple metadata values.
Similarly, I can try to view a raw audio file as a compiled pixmap, or, to recapitulate the famous joke, 'cat/boot/vmlinuz >/dev/audio'. The results of such voluntary file polymorphism aren't always useful, but they sometimes are.
Storing file type metadata does not necessarily dictate any OS policies (if any) based on that metadata--something the article tries to point out many times.
It seems abundantly clear to me that the author is a thoughtful and well-educated person whose primary computing experience has been with Macs and post-DOS MS machines: and while he may have used UNIX-like operating systems, he doesn't know much about data representation of filesystems on them
I'm not so sure about "well educated.";-) My primary computing experience is on the Mac and in Unix. I just chose not to address the Unix angle, for various reasons.
and clearly hasn't considered more modern developments like filesystems with journaling or ACLs instead of permission bits.
I've certainly "considered" them, and I did mention ACLs (although spelled out instead of by acronym: page 4) in the article. That's all just more, richer metadata.
I disagree with his statement that the type of a file is immutable data. It is not. I have, many times, created a text file, written some html, and renamed it ".html" to load it in a web browser.
You merely increased the accuracy of the file type metadata (HTML is a specific case of text), which was covered in the article.
Using a Mac has always been infuriating to me because I cannot easily change the application it is loaded with. It's changeable, sure, but not as easily as you can change to a simple, easily remembered mnemonic.
You're conflating the existence of file metadata with the application binding policy based on it--something warned against (multiple times) in the article.
How hard is it to change a bash script to a different shell? Change the first line. On a Mac, this would require you to change an embedded 32 bit identifier.
On the Mac, the file would likely be of the more general type "TEXT" in both cases. Speaking conceptually, of course you can change a file's type by changing its contents.
slashdot.pl and slashdot.txt should NOT collide on my desktop
In traditional file systems that use file name and location as the file identifier, I agree.
the type IS part of the name.
In the examples above, yes, it appears that the file type is encoded in the file names. But that doesn't have to be the case (nor should it be, IMO).
To those of us who use computers not as an information appliance but as information builders, the ability to easily manipulate file type data is a way of life.
There's nothing about file type metadata stored outside the file name that necessarily makes it any more difficult to change. Your thinking is constrained by existing implementations.
That said, file type metadata should still never be changed unless it is to increase/decrease accuracy, or the file contents change (in which case the application changing the contents should set the new type metadata when saving the file). Actually changing (as opposed to improving or degrading the accuracy of) file type metadata without modifying the data itself is not useful.
Problem with his analysis. E-mail isn't the only way to share files in OS X. Currently OS X offers FTP, HTTP, Appletalk, NFS, SSH and X.1 will add CIFS. Appletalk handles Meta information transparently, going from Mac to Mac, no need for extensions. FTP, HTTP, SSH and NFS (NFS will almost always go to a flat filesystem) offer no way to store/send OS X style meta information.
As I posted to the Ars discussion:
Yes, there are issues with other users connecting to a Mac via NFS or Samba and pulling off extension-less files. But there's no reason that a user in that situation couldn't opt to twiddle the system preference that tells every app to always append extensions (or use the per-app settings, if only some apps should do so, etc.) My main objection is to being forced to use them across the board, with no option not to.
1) A file's size is not metadata: A file can best be defined as an ordered set of bytes (or bits, or words, or whatever atomic unit your system uses), and the size of that set is intrinsic to it, not external.
Yes, it is "intrinsic", but it's also metadata. Think of a person's gender. It is intrinsic, but it is also information about that person.
2) A file's modification time is conceptually unrelated to its contents.
It depends on the implementation, as you point out.
Generally, systems use the modification time to note the time of an action that the user would see as causing a file to be modified, which is not always the same thing as noting the time that a file's content are actually changed. I know of no system that records the later time.
The existence of implementations that behave in the way described is irrelevant in the fundamentals section. There's no reasons that the modification date semantics described couldn't exist.
3) A file's type can change at will, not just to increase or decrease the "accuracy" of the typing. It's rare that a file would be useful when viewed as data of two or more independant data types, but there's nothing intrinsic in the concepts of files, their types, or metadata, to prevent this. Thus, for example, hacker can get some perverse enjoyment from writing source code that works simultaneously in multiple programming languages.
Such a change is a case of trying to increase accuracy while being constrained by an implementation that assumes files can have only one type at a time. What you want to do is say that file X is of type A, B, and C. But since you can only say it's of type A, you may "change" it to be of type B. But what you're really, conceptually, doing is trying to increase the accuracy of file type information by indicating that the file is of both types.
As you noted, such situations are rare, but handling them does not negate any of the fundamentals, IMO.
In general, the author's categorization of metadata into "immutable" and "mutable" is nonsensical. File metadata, by definition, is independent of file data, and is therefore mutable independantly of it.
Your definition of metadata obviously differs from mine.
The big problem with LCDs and games is if the pixel speed on the display is too low, thus not allowing the LCD to keep up with the frames that the game is displaying because it can't change pixel colors fast enough. I doubt any of Apple's displays would suffer from this problem, since they are intended to be used for things like video editing.
Don't doubt it. They're not magical, and they do suffer from mild ghosting. I found Quake 3 to be much less playable on the 22-inch Apple LCD, although it doesn't bother everyone.
The thing that bugs me about Ars (I liked their review) is their continued use of white text on black, as if it's still 1996. I found myself selecting the text to read it more easily.
User interface experts, indeed!
I just write 'em, I don't choose the site design...
Re:Mac people don't know how to use top
on
OS X
·
· Score: 1
I read the review on Ars Technica, and they think it's a problem that top shows that the system is using 253mb of ram on a system with 256mb ram in total. It's not
...which is exactly what I was trying to show by launching a dozen more apps and noting that top still reads about the same. I didn't think it was necessary to get into the gory details of demand-paged virtual memory. I just wanted to illustrate the different set of "rules" in OS X vs. classic Mac OS, where "3MB left" means "3MB left"!:-)
Slashdot Mirror
I'll expand a bit... :-)
:-) Once the match starts, that's it: no more troops for you.
:-) It makes every single troop--every single annoying little arrow stuck into every troop!--very important. (Yes, you will wail in pain when you lose your one dwarf :-) And the terrain actually makes a huge difference in the game, unlike in many other RTS-ish games where it's either it's just a passable yes/no issue.
Myth is all about tactics. There's no resource building at all. Each player starts with access to the same resources: a certain number of "points" that can be used to "purchase" troops at the start of a match. The number and types of troops available to purchase are set by the map designer. (There's also an optional, customizable time limit on making these purchase decisions, just to make it even more fun
This is the best system for a tactics-oriented RTS game I've ever seen, and I was surprised when every other similar game didn't immediately copy it (and the real 3D terrain
Myth maps can be unbalanced, of course, heavily favoring one particular strategy, but the game itself does not force this at all, which is the big difference. Great maps in Myth are sublime, making even people who have played them thousands of times think hard during every game.
Myth ruined me for the click-fest, isometric, resource building, bum-rush RTS games. It's not a super-complex "realistic" war game, nor is it artificially limiting. It's the perfect balance, IMO.
It's called Myth
(TFL, obviously :-)
Yeah, but now imagine that you could simply drag those annoying menus off the menu bar and they'd disappear in a puff of smoke. Welcome to the 10.1 "Menu Extras" API. It should be open to everyone, not just Apple. The usefulness far outweighs the potential for annoyance.
Man, it never fails...I always have moderator access to stories involving me. Anyway, now that I've forfeitted it, but while I still have a chance of being scored up, I'd like to pimp the Apple topic icons I emailed to Malda (where procmail no-doubt sent them to /dev/null :-P) The current one is just plain ugly, IMO. How about this instead? (Two versions of the same thing)
c ap ple-1.gif
c ap ple-2.gif
http://siracusa.home.mindspring.com/images/topi
http://siracusa.home.mindspring.com/images/topi
(Without the space...grrr)
Actually, it does, as Damian pointed out to me when I asked about it earlier today.
Supporting file name extensions (i.e. parsing and understanding them) is desirable. Forcing them to be used even when they are not necessary (e.g. with more typical Mac user apps like Word or Photoshop) is not. Apple's policy does not even address Unix tools, which, of course, will continue to function as they always have. And even Apple's own developer tools and IDE will, of course, keep dealing with foo.h and blah.c. But "user-land" apps like word processors and such are also *required* to append file name extensions. That's the big issue, not what goes on in the Unix side of things or in the realm of application development.
Er, which article are you reading? I specifically make the distinction between the existence of type metadata and the application binding policy--several times! :-)
Where does the article say that? You're right about the length, and I'd like to correct it if I made that mistake. But I can't find any mention of 32-character file name limits in the article.
As I posted earlier, I think it is. What you really want to say is that a file is simultaneously several types. This is simply a matter of accuracy, just as indicating that a file is both "text" and "HTML" is an increase in accuracy over just calling it "text." That fact that "text" and "HTML" have parent-->child relationship instead of a sibling relationship (as may be the case in some file that is both valid "Spreadsheet data" and "Address book data", for example) does not change the fact that it is merely an increase in the accuracy/resolution of the file type data.
Both hierarchical types and file type accuracy/resolution (which is what you're getting at) were addressed in the article.
To quote the article, "any part of the Mac OS user experience that exactly duplicates the experience on another platform ceases to be a compelling reason to buy a Mac." Furthermore, regressing to more primitive metadata just as the rest of the industry progresses to more sophisticated metadata (e.g. MS's Blackcomb/SQL file system rumblings) would be a very bad move.
No, I'm directly addressing a particular OS policy at that point. Storing file type metadata is good. Storing it encoded in the file name is not so good. Optionally hiding that part of the file name is a dangerous OS policy.
Here are a few problems off the top of my head. There's the "5 files named 'foo'" problem in dirs with foo.c, foo.h, foo.gif, foo.txt, and foo.html. Then there's the fact that other views of the file system (say, FTP or web) will see different names than the local user does. Totally restricting access to part of the file name is too limiting, so the possibility of mucking up the file type during the seemingly unrelated task of editing the name also exists. And, of course, there's the virus-spreading problem mentioned earlier.
No, because Unix doesn't make any file type distinctionsat the OS level (beyond character/block/special, etc.), so nothing Apple chooses to do on the "Mac" side of things is likely to impact Unix tools and apps, which will continue to work the way they always have.
You can be wrong about a person's gender too. Does that make gender as mutable as a person's name?
Nothing about storing file type metadata prevents this. You're confusing metadata storage with OS policies that may be based on it.
...and what was your login name, Mr. Anonymous?
Where did I say that metadata isn't derivable from the data? I said that some metadata, like size and type, is actually directly tied to the data. And I said that "metadata [...] is often difficult (or impossible) to add once it is lost", not "always."
Tell me where in a file's data I can read the file size. It is intrinsic (just as type is), but it is still metadata.
They support essential metadata: metadata that is needed to access the file like name, location, and size.
I had to pick semantics for all the example metadata in the fundamentals section. It just so happens that modification date semantics vary more than the others in the real world, which is what's leading you into implementation thoughts.
I think there are clear categories, regardless of what you choose call them.
Actually, one of my points was that "flattening" is no longer necessary in OS X (in the future, anyway) since resource forks are now deprecated.
Yes, the same way it is possible that a particular Windows machine will not know what a ".qyz" file is. No matter what the file type metadata system, there will always be "unrecognized" file types even when the file type metadata is present.
...or users who want to use such protocols can simply choose to have their apps append file name extensions. Again, my objection is to making them mandatory in OS X.
And yes, long term, all network protocols should support extensible metadata :-)
See above. Configuration is desirable. Forcing extensions everywhere is the big problem, just as forcing the lack of extensions would be, were some OS to do so.
The alarm is based on the speculated move away from file type metadata stored separately from the file name. I have no particular attachment to HFS/HFS+. Any file system with (preferably extensible) metadata support will do :-)
Or so you choose to assume! And what about Pat or Toby or Morgan?
If Matt changes his (or her ;-) name to Morgan, does his/her sex change as well?
The fact that you can run Unix apps may have removed a reason for you to avoid Mac OS, but it is not a compelling reason to switch in and of itself. If Mac OS X acts "just like Unix", why would you switch to it from Unix? Obviously there was some other compelling reason to switch--something that differentiates it from other OSes that are also Unix or Unix-like. Those differences are what make people switch. Features that are the same merely remove those features form the decision making process.
P.S.-If you read any of the reader mail from my OS X reviews, you'd know that I'm really a PC bigot ;-)
I assure you, that's not the case :)
But you can't get at the inode without the file's name and location. Inodes are not suitable as file identifiers since they are not guaranteed to be unique across the multiple disks that make up a given file system. The combination of the file name and location is unique in a given file system. "inode + data blocks" do constitute a file, but the file is inaccessible unless the file name and location are known. Therefore the file name is still essential metadata on a Unix-style file system.
I considered "data-dependent", but stuck with immutable, for better or for worse.
Truncation is a modification of the data.
See my previous post on the topic. Yes, the semantics of modification date vary wildly. But there's no reason that the semantics I chose in the example in the fundamentals section (which tries to ignore existing implementations) couldn't exist.
I agree, which is one of the reasons I didn't address the Unix philosophy of reducing everything to a sequence of bytes or blocks at the OS level.
What you want is a type hierarchy that indicates that XPM is of general type "text" and, more specifically, it is an X pixmap. There's nothing "bogus" about the notion of file type. I think you're unnecessarily constraining yourself to very simple metadata values.
Storing file type metadata does not necessarily dictate any OS policies (if any) based on that metadata--something the article tries to point out many times.
I'm not so sure about "well educated." ;-) My primary computing experience is on the Mac and in Unix. I just chose not to address the Unix angle, for various reasons.
I've certainly "considered" them, and I did mention ACLs (although spelled out instead of by acronym: page 4) in the article. That's all just more, richer metadata.
You merely increased the accuracy of the file type metadata (HTML is a specific case of text), which was covered in the article.
You're conflating the existence of file metadata with the application binding policy based on it--something warned against (multiple times) in the article.
On the Mac, the file would likely be of the more general type "TEXT" in both cases. Speaking conceptually, of course you can change a file's type by changing its contents.
In traditional file systems that use file name and location as the file identifier, I agree.
In the examples above, yes, it appears that the file type is encoded in the file names. But that doesn't have to be the case (nor should it be, IMO).
There's nothing about file type metadata stored outside the file name that necessarily makes it any more difficult to change. Your thinking is constrained by existing implementations.
That said, file type metadata should still never be changed unless it is to increase/decrease accuracy, or the file contents change (in which case the application changing the contents should set the new type metadata when saving the file). Actually changing (as opposed to improving or degrading the accuracy of) file type metadata without modifying the data itself is not useful.
As I posted to the Ars discussion:
Yes, there are issues with other users connecting to a Mac via NFS or Samba and pulling off extension-less files. But there's no reason that a user in that situation couldn't opt to twiddle the system preference that tells every app to always append extensions (or use the per-app settings, if only some apps should do so, etc.) My main objection is to being forced to use them across the board, with no option not to.
Yes, it is "intrinsic", but it's also metadata. Think of a person's gender. It is intrinsic, but it is also information about that person.
It depends on the implementation, as you point out.
The existence of implementations that behave in the way described is irrelevant in the fundamentals section. There's no reasons that the modification date semantics described couldn't exist.
Such a change is a case of trying to increase accuracy while being constrained by an implementation that assumes files can have only one type at a time. What you want to do is say that file X is of type A, B, and C. But since you can only say it's of type A, you may "change" it to be of type B. But what you're really, conceptually, doing is trying to increase the accuracy of file type information by indicating that the file is of both types.
As you noted, such situations are rare, but handling them does not negate any of the fundamentals, IMO.
Your definition of metadata obviously differs from mine.
So...at what version will Slashdot start using HTML (instead of whatever custom angle-bracketed language I see when I view source right now)
Don't doubt it. They're not magical, and they do suffer from mild ghosting. I found Quake 3 to be much less playable on the 22-inch Apple LCD, although it doesn't bother everyone.
I just write 'em, I don't choose the site design...
...which is exactly what I was trying to show by launching a dozen more apps and noting that top still reads about the same. I didn't think it was necessary to get into the gory details of demand-paged virtual memory. I just wanted to illustrate the different set of "rules" in OS X vs. classic Mac OS, where "3MB left" means "3MB left"! :-)