Regarding my last post, it turns out I was wrong. It was actually Mac OS X translating the extended attributes, not the NFS server.
Mac OS X turned the xattrs into resource forks, and promptly AppleDoubled them.
Gee, thanks, Apple.
I want a couple of things:
Can I do this with NFS, or will I get AppleDouble cruft all over the place?
The answer, apparently, is “no”.
Exporting a ZFS filesystem from an OpenSolaris host to Mac OS X (10.6.2, since you ask) via NFS works swimmingly.
I can set and read xattrs from within Mac OS X.
I haven’t quite figured out how read them in Solaris: I’m not sure if either Mac OS X or the NFS server are doing some kind of translation. I’m guessing the latter is.
Meanwhile, setting a custom icon on a folder still litters the folder with AppleDouble cruft.
I can live without being able to read xattrs from within OpenSolaris, but is there some voodoo global setting that I can apply in order to use xattrs in preference to AppleDouble? Pretty please?
A long time ago, I wrote a post on using a local nameserver on Mac OS X. That was fine for 10.4, but 10.5 and 10.6 do things slightly differently.
First of all, although both client and server versions of Mac OS X ship with BIND, you shouldn’t use /etc/hostconfig to enable it any more. Have a look at /System/Library/LaunchDaemons/org.isc.bind.plist: by default the Disabled entry in the dictionary is set to <true/>.
By default, /etc/named.conf on Mac OS X doesn’t include a key for ‘rndc’. Have a look at ‘rndc-confgen’ and run ‘rndc-confgen -a’ if necessary (or run it without the -a and manually add the lines to your rndc.conf and named.conf).
You may wish to add a statement to the options stanza in /etc/named.conf: specifically, add listen-on port 53 { 127.0.0.1; };
This means that your private copy of BIND is visible to and can be queried by only you.
As this is a parallel nameserver, you don’t need to use the root hints or anything like that. Assuming you want to allow lookups for anything.localhost to resolve to 127.0.0.1, just remove all of the zone blocks except the one for file "localhost.zone"; to read file "localhost-wildcard.zone";
Next, make a copy of /var/named/localhost.zone, calling it localhost-wildcard.zone in the same directory. Add the following two lines to the end:
* 1D IN A 127.0.0.1
* 1D IN AAAA ::1
You can then launch the nameserver via launchctl, or if you already have it running, reload the configuration and zones with rndc reload.
Now, assuming you’ve got your nameserver up and running and listening on port 53 of localhost, you should be able to verify that it works with the host utility: host test.localhost 127.0.0.1. If this times out or otherwise doesn’t return 127.0.0.1, go back and check that named is running and that it hasn’t reported errors via Console.app.
This guide to achieving the same thing as we’re trying to accomplish here may help you, but ignore the parts about modifying your resolv.conf or network configuration.
Next, create the directory /etc/resolver if it doesn’t exist and create a file in it named localhost. Add the following lines:
domain localhost
nameserver 127.0.0.1.53
search_order 1
Finally, run dscacheutil - flushcache and try to ping test.localhost. If all is well, you should find your Mac pinging itself.
Here is my response (PDF).
One of, if not the biggest criticism of iPhone OS which holds weight is that of Apple’s tight control over the App Store. Without submitting to the App Store approval process, qualifying as (and paying to be) a registered developer, or jailbreaking your device, you can’t install applications of your own devising.
For the majority of people using iPhone OS, this doesn’t present a practical problem (although their options are being artificially limited). For hobbyists and developers, it’s at the very least a wrinkle, and at worst completely off-putting.
There are several reasons why Apple doesn’t allow users to grab applications from anywhere on the web and install them, each with varying levels of legitimacy.
First is piracy: if the device will execute unsigned applications, then you can install any old .ipa that somebody’s downloaded from the App Store and stripped the signature from. Some developers claim that jailbreaking solely exists to facilitate piracy; many of those who jailbreak insist they’ve never downloaded an illicit copy of an app in their lives. What is true, though, is that many people do jailbreak their devices in order to install App Store applications without paying for them. Even if they’re a minority of users, they’re still a headache.
Second is support—, security— and user-experience-related: how do you allow app installation without significantly risking the security of the device and without compromising the fairly straightforward app installation process. I certainly struggle to see how app installation can be performed on-device from arbitrary sources without there being a huge risk of iPhone OS trojans. It’s clear that Apple is keen on leaving this aspect of mainstream computing far behind if it possibly can.
Third is revenue: Apple’s magical 30% cut on App Store sales, which goes to pay for maintaining the SDK and documentation, as well as the App Store itself, plus the various ancillary related services, such as Geniuses helping people who have some sort of app-related problem. As I’ve argued previously, I can’t see that the $99/year developer programme fee can possibly pay for all of this stuff on its own (which means that those who develop free applications actually make Apple a loss).
So, what to do about it?
First is to implement a standard block of code which performs Fairplay verification. App Store developers could then implement this in those applications they know will only be sold via the App Store. A couple of implementations of this exist already (and some developers have used them to track launches of legitimate versus illegitimate versions). A version of this with Apple’s stamp of official approval could boost its adoption.
Next is to tweak the iPhone Configuration Utility and iPhone OS itself to allow the installation of unsigned applications on any device. The net effect is that whether installed manually onto a jailbroken device, or via the ICU, an application which is only supposed to be sold on the App Store would only launch if it was properly signed and authenticated (or otherwise behave differently according to the developer’s preferences).
This isn’t an endgame, of course. The ideal would be the applications could come from anywhere, any time, and have both the flexibility to share data with one another, access external devices, the network, and so on and also do all of this without compromising the security of the user’s data or the device itself. And do all of this with a slick user experience irrespective of the source of the application.
That’s not going to happen in the immediate future. Nobody’s quite figured out how it’s possible in a way which isn’t horrendous for normal people to use.
Moreover, it needs to happen without destroying the most successful commercial application distribution system built to date and the profit margins of the company responsible: and for that reason, it can—for the time being—only be complementary, rather than a complete rethink. Because of this, a way to get non-App Store applications onto the device wouldn’t be as nice or as slick as the App Store itself, and would by no means be aimed at iPhone OS users in general, but it would let you, or I, or anybody else download the SDK, build something and throw it onto their device and share the .ipa for others to try out if they’re so inclined.
The nice side-effect of this is that it would also make life much easier for App Store developers. All of the problems of ad-hoc distribution vanish if you don’t care for the use of “technological measures” in order to constrain who gets a copy of your application.
Applications may include a UIless daemon. This would be subject to specific approval from Apple, and be categorised by what it does (for example, plays audio, receives time-sensitive notifications [e.g., VoIP incoming call alerts], transfers files).
There would be explicit user authorisation for keeping a daemon running once an app terminates: similar to the “Do you want to allow Fred’s App to access your current location?” prompts now, with an equally similar Settings menu listing the applications you’ve allowed to do background stuff and the ability to stop them.
There would be strict rules about what a background daemon could do, and there would be significant caveats, especially with respect to the OS’s ability to unceremoniously kill a daemon for any reason it likes, such as low-memory conditions or the launching of certain applications (such as games).
However, some possibilities open up: Apple could permit [music-playing] daemons to hook the pop-up iPod controls, allowing play-pause/track controls to function with Spotify, for example.
The approval process for all of this would be horrible for developers, I suspect, in part to actively discourage the use of background daemons so that they’re only employed if absolutely necessary. There are situations where the only way to accomplish something is through a background process, but for the other 90%, there’s the notifications framework. Neither is perfect, but Apple really wants to avoid having the kind of system where an application like “Advanced Task Killer” is remotely necessary.
Two words: Get. Fucked.
(From The Guardian, hat tip to Charlotte Gore)
I imagine it would be like in the movie “The Magnificent Seven”. I’d be Yul Brenner, and my first job would be to find my Steve McQueen. Then we’d recruit a handful of other gunslingers, strap on our gun belts, and kick some fucking ass.
Of course, most of the guys in The Magnificent Seven were killed. But Brenner and McQueen survived.
” John Gruber describes how he would, if elected to manage the project, assemble the team of area leads for Lettters.app.I have an Xserve that’s still on 10.4. It runs a web app with a typical MySQL database backend. Both on metal.
This morning the DB got so slow that the app server started returning “timed out” error pages.
Ungood.
So I dumped the database, created a new Debian VMware instance and loaded up the data. I ssh port-forwarded metal’s
3306to the new VM and restarted the apps.Yesterday it took around seven seconds to vend a page. Now it’s back under half a second.
I wonder what I’m doing wrong that MySQL on OSX metal is an order of magnitude slower than MySQL on virtualized Linux.*
Could it be the default settings on Mac OS X Server 10.4 are that much worse than the defaults on Debian 5 Lenny?
Mac OS X’s file system is a lot slower than Linux’s, but I don’t think it could explain this much of a difference.
*You may assume I did the obvious things before migrating the DB from metal to VMware: restart the server, dump+reload the DB, etc.
It’s very likely a combination of the above. Apple doesn’t really care much about giving you a sensible default configuration for MySQL, whereas Debian’s MySQL package maintainers will. Filesystem performance may or may not make much difference depending upon your table type (I would rather hope that, being virtualised, Debian would be marginally slower). What were the respective MySQL versions?
Mac Dev Center: File System Overview: Where to Put Application Files:
It is important to remember that the user domain (/Users) is intended for files created by the user. With the exception of the ~/Library directory, your application should never install files into the user’s home directory. In particular, you should never install files into a user’s Documents directory or into the /Users/Shared directory. These directories should only be modified by the user.
(My emphasis).
