I'm not really sure that I'm comfortable linking to this on our page. The problem that you are trying to solve actually introduces a few other issues. If there are no other 32 bit applications running, then you'll end up paying ~15% in speed for the increased memory savings. If you already have a 32 bit app running that's not the case since the 32 bit dyld shared code is running.
My main concern however is the other problem. You'll be running applications into less tested paths for what amounts to a small improvement overall in memory and an increase in cpu usage. It shouldn't actually hurt anything, but there are big concerns at least how I see it. I ran this by someone who knows a lot more about it than I do, and he didn't think it was such a hot idea except in the already running circumstance outlined above.
We have a rule about applications making it onto the applications page, mostly due to the fact that once on there we only remove the app if the link goes away, or change it if it changes. We don't post:
- Alphas or betas, just final releases.
- I also don't allow for anything that would be considered misleading
- Anything that is not signed.
- Anything that might be harmful.
- Anything that I don't understand the benefit of (if I can't understand it, then later if I have to explain it there's a problem)
In general I can slightly understand the benefit of the app in certain situations, but I don't think it's outlined well on the web page and it probably could be explained better. That said, I would have posted this with that problem there.
I'm not going to post this because it's not signed.
codesign -v SixtyFour.app/
SixtyFour.app/: code object is not signed at all
In architecture: x86_64
That issue needs to be addressed. I realize we may have some applications we link to that are not signed, but I'm working to prune the list. Any new applications need to be signed properly before we add them to the list.
On Sunday, March 3, 2013 at 8:34 AM, sup...@1951fdg.com wrote: