On May 29, 2012, at 19:03 , Shawn Bakhtiar wrote: > Again, the technical answer (solution) is NOT to use it. If everyone on > this list really understood the damage it does by turning people away from > Apple (and the art of programing) many people, and acted accordingly, we can, > and will change things. But simply saying it is what it is, is NOT an > answer. Putting yourself in a prison (or you application in a prison) > because there are a lot of bad people (applications) out there is not living > (or in an > application sense, executing).
Nonsense. > I really mean it, this is MCP. The Master Control Program from Tron. Please > understand when you have a hardware vendor, riding an open source tool set, > and creating control that as of yet no one has a good argument for, it should > give everyone the creeps. Utter nonsense. The essence of this thread isn't about the philosophy of sandboxing. It's about the difficulty of *adding* sandboxing to an existing application with an established feature set. Mac applications often survive in niches, and invalidating functionality can have the side effect of ejecting applications from their niches. This is a valid and even vital concern to developers such as Graham. A number of commentators have jumped into the thread to declare, in effect, that the sandboxing could *never* work. Such a point of view seems inexplicably to ignore the fact that there is a platform out there already (iOS) for which sandboxing is demonstrably viable -- technically, economically, and functionally. My response to such commentators is, of course: WTF? _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
