• Taste Of Dirt Mac Os X

File Name Extensions.section

Dirt is a new utility in Leopard that can be used to test Directory Services. You can use dirt to test authentication for LDAP or Active Directory. The -u flag uses the username from the node you are testing against, in the above example it is the Active Directory username. Dirt tests whether an account exists Continue reading Mac OS X: dirt. Improve Tab Completion in Mac OS X Terminal Aug 2, 2012 - 5 Comments Tab completion is a wonderful feature of shells that make power users lives easier, letting you automatically complete commands, paths, file names, and a variety of other things entered into the command line.

This is the first taste of VR on macOS By Darren Allan February 14, 2017 Experience a virtual desktop using the Oculus Rift headset Virtual reality has come to Apple’s computers, in a fashion, with. Now the Online Version of Dirt 3 Is daily playing. World Of Mac Best Site to Download Mac Games and Software. DiRT 3 Complete Edition is now free for PC and Mac – MyGaming. Working Games 100% Dirt 3 Bug Free and All the Errors Have Fix By World Of Mac. Repack Dirt 3 Mac Games Now Download Online Only On World Of Mac.

In an earlier article, I spent a considerable amount of time discussing the history of metadata, and its role in Mac OS X. I did that partially because it's such a large topic that I didn't want it to overwhelm this Mac OS X 10.1 review. But in the time since the metadata article was written, there has been a very significant public policy clarification from Apple—one that confirms some of my worst fears about the future of metadata in Mac OS X.

In the metadata article, I wrote that Apple's Mac OS X metadata policies up to that point 'seem[ed] to be based on the assumption that file type metadata will always be encoded in the file name.' Sadly, I turned out to be right.

The bombshell was first dropped on an Apple mailing list, and was later formalized in the Mac OS X 10.1 release notes. You should read one of those links if you haven't already, because the exact behavior of the metadata management system in Mac OS X 10.1 is very complex, and I don't think it can be fully explained more concisely than it is already in those documents. But if it had to be condensed down to a single point, it would be this:

File name extensions are mandatory in Mac OS X 10.1

To comply with the new 10.1 metadata guidelines, all files created by Mac OS X applications must include a file name extension.

The aforementioned complexity is caused by an elaborate system of per-user, per-file, context-based file name extension hiding, conflict and confusion prevention, and a long list of guidelines for applications that create files or display file names. But the bottom line is that every new file created by a Mac OS X application must be created with an appropriate file name extension.

The reasoning behind this policy is simple. If every file created on Mac OS X has its file type information encoded in its file name, no additional action is required (on the part of the user or the OS) when a file is shared with an operating system that expects file type information to be encoded in this way (e.g. Windows).

The file name extension hiding and file name editing policies are geared towards preventing the Mac OS X 10.1 user from knowing which extensions actually exist in a file name at any given time, and preventing users from removing or changing this information. The guiding principle is described by Apple as 'what you see is what you typed', meaning that the exact file name entered by the user in a save dialog box or while editing a file name in the Finder should be what is shown in the GUI. (Again, consult the official guidelines for a more thorough explanation.)

Furthermore, traditional, distinctly stored file type and creator metadata (in the form of HFS/HFS+ type and creator codes) is optional under the new policy. Application developers 'may' set this information 'if they wish.' The only benefit Apple lists for this action is 'increased interoperability with Mac OS 9 applications.'

Mac OS X 10.1 Metadata in Action.subsection

The table below provides a brief taste of Mac OS X 10.1's metadata policies in action. It shows a sequence of user actions, the resulting file name (both actual and displayed in the Finder), type and creator codes, icon, application binding, and any other warnings or interactions.

For those keeping score, that's:

• four different displayed file names
• five different actual file names
• three situations where the actual file name differed from the displayed file name
• four different icons (one of which gave no indication of which application would open the file)
• three different applications that launched and attempted to open the file when it was double-clicked
• four warning dialog boxes in the Finder
• one error dialog in Preview
• two instances of garbage displayed in TextEdit

(At no time were any HFS/HFS+ type or creator codes set.)

The user actions that caused all this consisted of a 'Save' from within an application and a series of rename operations in the Finder.

For comparison, a similar sequence of steps in classic Mac OS would result in:

• a single icon displayed in the Finder
• a single application launched when the file is double clicked
• a displayed file name that always matched the actual file name

Again, this was all a result of a simple save and a series of rename operations in 10.1. Yes, there were many warning dialogs, but the point is that renaming a file should not be so fraught with danger, warnings or no warnings.

Furthermore, the warning dialogs displayed in the Finder mentioned only that the rename operations may cause the document to 'open in a different application.' There was no mention of an inability to view the document or a loss of cross-platform portability, despite the fact that, during four of the six states in this sequence, the file would not have opened successfully on a Windows system.

Big Problems.subsection

Needless to say, there has been strong and vocal opposition to Mac OS X 10.1's metadata policy from a large portion of the Mac community. And, not surprisingly, I've been part of that opposition. I don't think anyone debates the improved interoperability that strict adherence to this policy provides. It's the prioritization of interoperability above all else that is so objectionable. The natural extension of this value system is to simply use Windows.

Apple appears to want to have it all: perfect cross-platform interoperability married to a rich, Mac-like 'local' user experience. But given the current state of those 'foreign' platforms that Apple wants Mac OS X to interoperate with, sacrifices on one (or both) ends of that equation are required. The 10.1 metadata policy sacrifices simplicity and control (for both application developers and users) in the local user experience in an effort to improve cross-platform interoperability. This is an unwise sacrifice for many reasons.

While interoperability may be improved, it is still not perfect. Million of files created in classic Mac OS still exist on Mac OS X customers' hard drives—files either without file name extensions or, worse, with file names that may appear to have extensions. And don't forget about files that have resource forks, which will require encoding for safe passage to and from other platforms, with or without file name extensions.

The ability to choose file names that are meaningful to the user rather than the OS, and to have complete control over those file names (not just the illusion of control), has been a hallmark of the Mac user experience since 1984. It's also been one of its biggest advantages. If Mac users truly valued interoperability above the local user experience, they would not be using Macs in the first place.

If this sacrifice of a significant historic advantage of the Mac platform is meant to attract more users from other platforms, it is doomed to failure. First, the change alienates a substantial portion of the current Mac user base, so many of them will have to be replaced with platform converts to merely break even.

Second, in the grand scheme of things, mandatory file name extensions are a drop in the platform-convert bucket. Converts to the Mac platform would still need to purchase all new hardware, all new software, learn a new operating system, convert, transfer, or lose thousands of existing files, and then deal with all the remaining disadvantages of their new platform: fewer hardware choices, a smaller software selection, more expensive hardware, etc.

Furthermore, the 'payoff' for this conversion consists of all of the historic advantages of the Mac platform that had failed to attract this user in the past, minus one of the biggest advantages that was just sacrificed in an effort to cause the conversion!

If the new policy is meant to improve the user experience for the current Mac user base, feedback on this issue to date clearly demonstrates that it fails to do so for many Mac users.

Ironically, the new policy hurts interoperability with the platform most likely to be encountered by Mac OS X users: classic Mac OS. Files created without type/creator codes by Mac OS X applications may not be usable in classic Mac OS, or in Mac OS X's own classic environment.

Worse, the 10.1 metadata policy also effectively closes the door on many possibly future metadata policies by not requiring that all possible metadata be written to every file created on Mac OS X. Less metadata means fewer possible interpretations, and therefore fewer possible policies for application binding, icon display, and so on, in the future.

Solutions

The obvious solution is for Apple to come up with a new metadata system for Mac OS X that improves interoperability while also retaining all of the advantages of the Mac Way. This new system should be backwards-compatible with type/creator codes, but should be an entirely new implementation that goes beyond the limitations of its predecessors. Hypothetical feature of this new system might include the use of BeFS-style extensible file system metadata, MIME types, Java-style (e.g. 'com.adobe.Photoshop') application identifiers, etc. The interoperability of this new system, while important, should never come at the cost of the local user experience.

That's a tall order, of course, and no one expects such a system to spring, fully formed, form the forehead of Apple (especially when they're apparently still struggling with retaining window and icon positions in the Finder. Sorry, low blow ;-) But there is a simpler interim solution that requires much less work.

Start with the Mac OS X 10.1 metadata policy, but make the following changes:

• All Mac OS X applications must write HFS/HFS+ type and creator codes when creating a file.
• Make the application binding policy user-configurable. Include preset configurations that correspond to the traditional Mac OS and Windows policies, and allow custom policies to be created by the user that reference (or ignore) metadata of the user's choosing when determining which application a file will open in, and which icon will be displayed for that file in the Finder.
• Add 'metadata services' APIs to the OS for converting to and from various metadata representations: appending the appropriate file name extensions (based on other file type metadata, or even the file contents), or removing file name extensions (setting other file type metadata as appropriate). These APIs would reference a per-user, user-configurable metadata representation mapping table.
• Change the standard open/save dialog boxes to leverage the new metadata services APIs, and provide both system-wide and per-application preferences for each user to control which applications append file name extensions by default, and which don't. All open/save dialog boxes should have a checkbox to allow the defaults to be overridden on a per-file basis.
• Add menu commands and context menus to the Finder that use the new metadata services APIs to allow the user to convert selected files (or folders full of files, or entire volumes full of files) to and from different metadata representations.
• Change any applications or system services that currently depend on the presence of file name extensions to also understand file type metadata stored in locations other than the file name.
• Make the entire file name, including any extension, visible and editable at all times.

To improve interoperability, a future version Mac OS X that includes the changes listed above could ship with default settings that correspond closely to the current 10.1 behavior: the system-wide option to append file name extensions could be on by default, and the customizable binding policy could be set to match the 10.1 behavior.

Such a system would have nearly all of the interoperability benefits of the 10.1 policy, while also providing experienced Mac users who are both willing and able to manage interoperability on their own with the ability to do so—while retaining complete, simple, direct control over all file names. The new metadata services APIs and their use in the Finder and standard open/save dialog boxes would provide even more power to experienced users, freeing them from some of the more tedious manual conversion tasks.

Metadata Conclusion.subsection

The metadata policy in Mac OS X 10.1 is complex in its implementation (sometimes to the point of being mysterious), misguided in its apparent motivations, and does not live up to the quality of the traditional Mac user experience that it intends to replace. Furthermore, it will make future improvements more difficult as files created with 'partial metadata' by Mac OS X applications that adhere to this policy proliferate.

I'd like to paraphrase something I wrote in the metadata article because the sentiment seems even more apt in light of the current situation:

There is a feeling in some parts of the Mac community that the advantages of using a Mac are being eroded slowly by Mac OS X. Given Apple's tiny market share, compromises are often necessary to maintain acceptable levels of interoperability. But in cases where alternate solutions provide similar interoperability improvements without sacrificing favorable aspects of the Mac user experience, Apple should do everything in its power to implement them as such. Any part of the Mac OS user experience that duplicates the experience on another platform ceases to be a compelling reason to buy a Mac.

Coming soon: Windows games that will run on Intel Macs thanks to TransGaming’s new Cider software. There’s no rebooting involved and no separate Windows partition to be installed. It all happens transparently.

TransGaming, which several years ago dipped its toes in the Mac game market with conversions from leading Mac game publishers, is taking another step into the Mac market, this time adopting their Cedega technology for Linux to run on Intel-based Macs. The result is a forthcoming series of games from PC game publishers that TransGaming’s CEO Vikas Gupta calls a “transparent” experience for Mac gamers.

“Cider games will run as if they were made for Mac OS X,” Gupta told Macworld in a recent interview.

With Cider, Mac users’ long wait for Mac OS X-native games is a thing of the past—Mac users will be able to run Cider-enhanced Windows games simultaneously or nearly simultaneously with their PC counterparts, said Gupta.

Cider that’s distilled from WINE

One thing that makes Cider different is that the game is effectively “wrapped” with TransGaming’s technology. Users pop in a disc, install the game, and run it just as they would a standard Mac OS X application. But instead of Mac OS X, the game remains a Windows application. Cider, meanwhile, translates on the fly the Application Programming Interfaces (APIs) that the game needs to call in order to work.

This is significantly different than Apple’s Boot Camp software, which requires Intel Mac users to restart their systems in order to work with Windows XP applications. It’s also very different from Parallels Desktop, which uses virtual machine technology built into the Intel chips Apple uses in its new Macs to enable users to run Windows and Windows applications inside of a window on their Mac OS X desktop—that doesn’t provide graphics acceleration and other things needed to run Windows games on the Mac.

Instead, Cider is conceptually similar to CrossOver, CodeWeavers’ recently announced software that will enable Macs to run Windows applications on Mac OS X.

In fact, CrossOver, Cider and Cedega all have their roots in WINE. An acronym for WINE Is Not an Emulator, the software is an open source effort to make Linux-based computers run Windows application, not through emulation but through a translation layer that handles Windows-specific application code dynamically.

“Cider is quite considerably removed from WINE,” said Gupta. “They branched about three and a half years ago.”

Gupta said that while WINE remains a general-purpose translation environment and CrossOver is more aimed at business application users than gamers, TransGaming’s Cider is specifically focused on getting Windows games to run well on Intel-based Macs. Also, because Cider “wraps” the Windows games, there isn’t a separate Cider software environment that needs to be maintained—it’s built right into the games themselves.

Gupta said that Cider doesn’t increase the risk of being infected by Windows viruses or malware, either. “It’s a closed environment, thoroughly protected on our end as well,” he said. “We’re giving Mac users the experience they’ve always had. We understand Mac users and the Apple look and feel.”

The Cider press

TransGaming is already working with several PC game publishers to bring forth Cider-vetted games—Gupta said a half-dozen new titles are already in the works. The company takes the game, optimizes Cider to work with it and then returns the enhanced game to the publisher for further quality assurance (QA).

“We do our own Quality Assurance and testing,” Gupta said. “The publisher will do their own QA to give the game their stamp of approval.”

“One thing that makes this remarkable is that we’re not asking for any money up front,” said Gupta. “We’re using a revenue sharing model.”

Gupta said that PC games running using Cider on an Intel-based Mac provide near-native performance. “The average user won’t be able to discern any difference,” he said.

Though in some cases, Gupta indicated users are bound to see 10 to 15 percent lower frame rates than they would in a truly native game.

Apple is infamous among game developers for significantly changing OpenGL and other APIs needed for games during maintenance upgrades to operating systems. In many cases, this has broken compatibility with popular games, forcing developers to release point updates for their games to restore their ability to work on the Mac.

“The process [for Cider] is no different than it is today,” said Gupta. “Apple knows what we’ve been doing, we’ve had a good relationship with them for a long time. We’re confident we’ll be apprised of major changes when they happen. But with or without Apple’s help, we can make changes quickly and get updates out to our users.”

Fresh Cider in October

Gupta estimates that Mac users will begin seeing Cider-enhanced games appear on store shelves in October, in time for the holidays. Initially, Cider-enhanced games for the Mac will appear on store shelves in their own boxes, separate from their PC counterparts.

Taste Of Dirt Mac Os X

But Gupta said that TransGaming is hoping to see simultaneous releases for Mac and PC, perhaps even in the same box, if Mac gamers and PC game publishers both like the taste of Cider.