Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the Mac App Sandbox makes me sad

lacquer.fi

Post reply on HN
Print view View original

141–150 of 200 posts

Re: Why the Mac App Sandbox makes me sad

#141

Post by CJefferson »

eddieplan9 wrote: post #114
recoiledsnake wrote: post #87

Earlier quoted context omitted.

>This article mostly seems to ignore the fact that you can still distribute apps outside of the App Store. Sure, but when Apple starts claiming and advertising that all Mac Store apps are secure(indirectly implying that external apps are not or may not be), external apps will have a much harder time appealing to the casual crowd, and for some apps living on thin margins, might be a death knell as more and more Macs g…

I cannot see how this is bad for competition. Within the App Store, the apps are subject to the same restrictions and it is fair competition. Outside of the App Store, you are not subject to the restrictions, and hopefully you can - and you should - build something that is impossible to achieve under the App Store restrictions, and you get your competitive advantages. If you just hate the App Store idea, and you don'…

Except of course, the App Store gets dropped into the dock of every Mac bought.

I wonder (and just thinking out loud here) if there might end up being an 'app store' anti-trust suite, with Apple and Microsoft being forced to give things like Steam prominence?

Re: Why the Mac App Sandbox makes me sad

#142

Post by LaGrange »

Daishiman wrote: post #120
LaGrange wrote: post #89

Earlier quoted context omitted.

I wouldn't expect Apple to care about any single specific professional niche (maybe except application developers), so keeping any sort of professional software in-house might be even a distraction. But Apple still depends on professionals-as-a-whole — once you add up graphic designers, architects, movie professionals and all others you get quite a lot of people who probably have enough money to buy fancy computers,…

Except that the very top of the professional high end is not really that populated by macs. Most pro 3D designers use 3DStudio MAX (Windows) or Maya (multiplatform with no advantage for Macs). Most architects use AutoCAD (Windows only). Most professional studios use a mix of all three, with a predominance of Linux and Windows at the highest end. Even with audio there isn't much of an advantage to using a Mac unless y…

Actually, AutoCAD has a Mac version, though that doesn't change that much. But the point still stands — it makes sense for Apple to want professional applications, it doesn't really make sense to try and write own Maya, and distribution dynamics are for large packages are different enough to make using Mac App Store for them less attractive.

Re: Why the Mac App Sandbox makes me sad

#143

Post by fennecfoxen »

dextorious wrote: post #137
lallysingh wrote: post #117

I just bought a new laptop. The last 3 were powerbooks/macbook pros. I saw the app store on os x and decided on a lenovo this time, running linux (xmonad helped tip that scale). I'm really glad I went that way. I'm sure that this is a good thing (tm) for most users, and will help avoid all sorts of problems. But the Mac's becoming more of an appliance, and while it's safer, easier, and more convenient for most users,…

"""But the Mac's becoming more of an appliance, and while it's safer, easier, and more convenient for most users, it makes it a substantially less desirable machine for me to hack on.""" You do understand that in Lion, say, nothing, absolutely nothing has been taken away from you that you could do back in 10.1 or even NeXT. So, this "the Mac's becoming more of an appliance" is just bullshit, just blindly following th…

Dude. We know how the iPhone works. It's easy to see Apple starting to bring the same sort of model to the MacBook. We're not blind. We can see where this is going, even if it's not there yet, and make reasonably informed guesses about what it's going to be like.

Re: Why the Mac App Sandbox makes me sad

#144

Post by c1sc0 »

gcv wrote: post #82
guard-of-terra wrote: post #57

Don't they distribute xcode via appstore? it obviously dould not fit in the sandbox. If they make it an exception, can't they be hammered for monopolizing the development tools in the app store for themself?

Apple distributes the Xcode installer through the App Store. Normal App Store restrictions don't apply.

Cool! Does this mean I will be allowed to distribute App Install scripts through the AppStore? The best of both worlds: free distribution & full control!

Re: Why the Mac App Sandbox makes me sad

#145

Post by ryannielsen »

Some points of clarification to eliminate some FUD, especially around plugins:

- Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space.

- Plugins do not need to exist within the app's bundle. Plugins don't even necessarily need to exist within a sandboxed app's container, if that app requests an exception to read its plugin directory (e.g. ~/L/Application Support/MyApp/Plug-ins).

- Plugins can be signed and distributed independently from their host app.

- Calling out restricted Thunderbolt access is a misnomer. AFAIK, there is no public Thunderbolt API now and as Thunderbolt is largely PCI Express + DisplayPort, any kind of access would have required kexts anyway. As kernel extensions already aren't allowed on the App Store, this isn't (just) a sandbox restriction.

- Bluetooth devices can likely be accessed via AppleBluetoothUSBHCIController, which provides a USB HCI interface to any compatible BT devices.

- You can read/write files in a known location on a network disk (or any disk) if you simply ask for permission once per launch. In fact, if you opt-in to auto termination, that user-granted entitlement will persist across most app relaunches, as long as the app's serialized state is preserved[1]. (And if you filed a radar requesting such a feature, it's very possible Apple would find a way to persist that user-granted entitlement across all app relaunches.)

Regarding other points, it is true that Firewire access is restricted, as is general filesystem access and frame buffer access. Likewise, a sandboxed app is prevented from sending Apple Events to arbitrary applications, breaking a good bit of IPC. It's fair to complain about these restrictions (some of them affect my apps, and working around them will not be simple and may require removing popular features), but please don't cloud the issue with misinformation.

[1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...

Re: Why the Mac App Sandbox makes me sad

#146

Post by fennecfoxen »

guywithabike wrote: post #124
super_mario wrote: post #44

Earlier quoted context omitted.

Give it a release or two and app store will be the only way to get software on your locked down appliance owned by Apple.

You're basing this information off what? Just your wild preconceived notions?

I don't think the notion that the iPhone/iPad model represents the future of Apple is a particularly wild one.

Re: Why the Mac App Sandbox makes me sad

#147

Post by ryannielsen »

pavlov wrote: post #13
nknight wrote: post #7

I can think of only two GUI apps I semi-regularly use that can't fit within those restrictions: VMware Fusion, and Steam. Plugins are a red herring. Some poorly-designed plugin infrastructures will not be workable, boo-hoo. Valid use cases can be accommodated with proper message passing. Maybe we'll finally get applications that don't crash horribly because of buggy plug-ins?

What kind of plugin architecture do you propose that doesn't use dynamic loading or standard IPC mechanisms? Your "message passing" is much too vague. Remember, this needs to be fast enough to accomodate FCP video processing plugins - hundreds of megabytes of data may need to be passed between the host and plugin each second.

Signed and sandboxed applications have no code loading restrictions. They're free to map anything into their memory space, though that code will of course be bound by the same entitlement restrictions as the loading process.

Re: Why the Mac App Sandbox makes me sad

#148

Post by marquis »

Daishiman wrote: post #120
LaGrange wrote: post #89

Earlier quoted context omitted.

I wouldn't expect Apple to care about any single specific professional niche (maybe except application developers), so keeping any sort of professional software in-house might be even a distraction. But Apple still depends on professionals-as-a-whole — once you add up graphic designers, architects, movie professionals and all others you get quite a lot of people who probably have enough money to buy fancy computers,…

Except that the very top of the professional high end is not really that populated by macs. Most pro 3D designers use 3DStudio MAX (Windows) or Maya (multiplatform with no advantage for Macs). Most architects use AutoCAD (Windows only). Most professional studios use a mix of all three, with a predominance of Linux and Windows at the highest end. Even with audio there isn't much of an advantage to using a Mac unless y…

While a lot of people moved to Windows due to Avid Media Composer issues with Macs in the mid-2000s they've been moving back since hardware support renewed. In the audio post industry it's at least 80% Mac-based in the US.

Re: Why the Mac App Sandbox makes me sad

#149

Post by ryannielsen »

natesm wrote: post #16
pavlov wrote: post #13

Earlier quoted context omitted.

What kind of plugin architecture do you propose that doesn't use dynamic loading or standard IPC mechanisms? Your "message passing" is much too vague. Remember, this needs to be fast enough to accomodate FCP video processing plugins - hundreds of megabytes of data may need to be passed between the host and plugin each second.

Is it possible to install the plugins to `~/Library/Containers/...` instead of the usual location? Not that loading code is allowed on the App Store anyways, unless you're Apple, of course.

Plugins can exist anywhere. They can be placed into the app's bundle without necessarily breaking its signing seal, they can exist within the app's container if the app has a way of copying them in (e.g. it advertises a file type, like Aperture's ".ApertureExport" bundle, so the user can double click to load the plugin, or it provides an "Install Plugin" feature somewhere), and they can exist anywhere in the user's home dir or system volume (if the app requests an exception to read files from those known locations).

No code loading restrictions are placed on signed and sandboxed apps. Any signed and sandboxed process is free to map in any code, though that code is bound by the parent process's sandbox restrictions.

Re: Why the Mac App Sandbox makes me sad

#150

Post by ryannielsen »

pavlov wrote: post #30
nknight wrote: post #24

Earlier quoted context omitted.

The IPC mechanism is XPC, and my memcpys run at a few thousand megabytes per second, why don't yours?

XPC services must be located within the host app's bundle [1]. They must be appropriately code-signed. How do you propose to use this mechanism for 3rd party plugins? [1] http://developer.apple.com/library/mac/#documentation/MacOSX...

As I've pointed out elsewhere in these comments, XPC isn't required for supporting plugins in a sandboxed application, and it's possible for plugins to exist within a signed and sandboxed app's bundle:

http://news.ycombinator.com/item?id=3193354

http://news.ycombinator.com/item?id=3193379

http://news.ycombinator.com/item?id=3193404

Post reply on HN