Between a rock and a hard place – our decision to abandon the Mac App Store(blogs.atlassian.com)
blogs.atlassian.com
Between a rock and a hard place – our decision to abandon the Mac App Store
http://blogs.atlassian.com/2012/02/between-a-rock-and-a-hard-place-our-decision-to-abandon-the-mac-app-store/
19 comments
There's another kind of applications, besides dev tools, that's going to be affected by this.
I'm a user of one of Apple's "pro" applications, Logic Pro 9, a top music recording software (or DAW). I started using it long before it was put in the appstore, and was surprised when they moved it there, as it was a 5 DVD install.
Anyways ... the tool interacts with plugins written in a Logic Pro independent standard, VST. It burns CDs. It manipulates midi through wifi, usb, and firewire. It reads third party provided sound samples and loops. It manipulates analog instrument interfaces through firewire ...
Is Apple going to cripple Logic Studio? Or will they also have to take their "pro" software out of the appstore?
I'm a user of one of Apple's "pro" applications, Logic Pro 9, a top music recording software (or DAW). I started using it long before it was put in the appstore, and was surprised when they moved it there, as it was a 5 DVD install.
Anyways ... the tool interacts with plugins written in a Logic Pro independent standard, VST. It burns CDs. It manipulates midi through wifi, usb, and firewire. It reads third party provided sound samples and loops. It manipulates analog instrument interfaces through firewire ...
Is Apple going to cripple Logic Studio? Or will they also have to take their "pro" software out of the appstore?
Mainstage is in the Mac App Store as well, nothing about Rewire support is consistent with MAS guidelines.
Unfortunately, it appears this may be a "do as I say, not as I do" situation.
Unfortunately, it appears this may be a "do as I say, not as I do" situation.
Unfortunately, how?
The whole point of sandboxing is to reduce the damage a badly written or mal-intended application can do to a system.
Surely Apple TRUSTS their own apps.
The whole point of sandboxing is to reduce the damage a badly written or mal-intended application can do to a system.
Surely Apple TRUSTS their own apps.
Are you dense?
It's unfortunate for users, rational beings who, having spent several hundred/thousand dollars on pro applications, can generally expect not to be served malware. I don't really need Apple's assistance to ensure that Ableton doesn't sell me a trojan. If they do, I have my lawyer's number in my phone, we know who to sue, we've got it covered. It's unfortunate that the way the rules are currently written, no pro media application will be able to take advantage of iCloud functionality…except of course the ones that Apple sells.
I don't care who Apple trusts. And if the answer to "Who does Apple trust?" is "No one but Apple," that says more negative things about Apple than it does about the tens of thousands of software developers, large and small, who aren't Apple.
It's unfortunate for users, rational beings who, having spent several hundred/thousand dollars on pro applications, can generally expect not to be served malware. I don't really need Apple's assistance to ensure that Ableton doesn't sell me a trojan. If they do, I have my lawyer's number in my phone, we know who to sue, we've got it covered. It's unfortunate that the way the rules are currently written, no pro media application will be able to take advantage of iCloud functionality…except of course the ones that Apple sells.
I don't care who Apple trusts. And if the answer to "Who does Apple trust?" is "No one but Apple," that says more negative things about Apple than it does about the tens of thousands of software developers, large and small, who aren't Apple.
Are you dense? It's unfortunate for users, rational beings who, having spent several hundred/thousand dollars on pro applications, can generally expect not to be served malware. I don't really need Apple's assistance to ensure that Ableton doesn't sell me a trojan.
You might be dense. Who said it's only for trojans? I wrote "to reduce the damage a badly written or mal-intended application can do to a system".
Sandboxing is not only about malware. If, for example, Live has a bug that eats your home directory, it won't have its day under sandboxing.
And who said anything different will happen to Live or anything? It's not in the App Store, and you will STILL be able to run it. The change is for App Store applications.
You might be dense. Who said it's only for trojans? I wrote "to reduce the damage a badly written or mal-intended application can do to a system".
Sandboxing is not only about malware. If, for example, Live has a bug that eats your home directory, it won't have its day under sandboxing.
And who said anything different will happen to Live or anything? It's not in the App Store, and you will STILL be able to run it. The change is for App Store applications.
In contrast to Google, whose malware auto-detection algorithms will still flag Google-owned domains.
>Is Apple going to cripple Logic Studio? Or will they also have to take their "pro" software out of the appstore?
The answer is simple, Apple's apps will have special access that will make them better than 3rd party apps which have to jump through all these hoops.
The answer is simple, Apple's apps will have special access that will make them better than 3rd party apps which have to jump through all these hoops.
The current version of Xcode, released yesterday (two weeks prior to the sandboxing deadline), contains no code signing entitlements and hence is not sandboxed.
Except that you just made this up. Do you really think Apple doesn't know people are on the lookout for just such behavior?
What can anyone do about it really? They hide behind the 'is not a monopoly' excuse and there's nothing anyone can do.
If true, didn't Microsoft do that a long time ago... with Internet Exporer?
Anyways ... the tool interacts with plugins written in a Logic Pro independent standard, VST.
Actually, Logic Pro does not interact with VST plugins at all. It interacts with AU (Audio Unit) plugins. Plugins like Native Instrument's etc that come as VST plugins also come in AU versions.
Is Apple going to cripple Logic Studio?
No, Apple is not going to cripple Logic Studio. They even said so, a few months ago.
Or will they also have to take their "pro" software out of the appstore?
They can also do whatever they want with THEIR apps in the appstore, like have them there despite not implementing sanboxing, or giving them arbitrary sanboxing rights (after all, Apple TRUSTS their own apps not to be malware).
Actually, Logic Pro does not interact with VST plugins at all. It interacts with AU (Audio Unit) plugins. Plugins like Native Instrument's etc that come as VST plugins also come in AU versions.
Is Apple going to cripple Logic Studio?
No, Apple is not going to cripple Logic Studio. They even said so, a few months ago.
Or will they also have to take their "pro" software out of the appstore?
They can also do whatever they want with THEIR apps in the appstore, like have them there despite not implementing sanboxing, or giving them arbitrary sanboxing rights (after all, Apple TRUSTS their own apps not to be malware).
Good point. Every interpreter - and program that loads anything - will have to be foolproof. There was a case some time ago where an Xbox (or was it ps3?) game did not correctly check the saved games before loading them. IIRC people where able to exploit this and get the game to run code on their behalf.
In theory, all the games and apps have to sign/encrypt/check everything they load. But I can't believe they will all implement this correctly or that Apple will find all the subtle bugs when reviewing.
In theory, all the games and apps have to sign/encrypt/check everything they load. But I can't believe they will all implement this correctly or that Apple will find all the subtle bugs when reviewing.
The sandbox lessens the risk of said overflows. Instead of exploiting a flaw in an interpreter or file handling function and getting control of the entire machine, you'd only get control of the sandbox's context.
The only way to parlay that into control of the system would be to break the sandbox. And then, because OS X default security is fairly sane, the only way to do real lasting damage is to use a further exploit to escalate your permissions.
The only way to parlay that into control of the system would be to break the sandbox. And then, because OS X default security is fairly sane, the only way to do real lasting damage is to use a further exploit to escalate your permissions.
True, but that would be true without signed apps as well.
Also, I guess it depends on what the app does and what you mean by "real lasting damage".
Also, I guess it depends on what the app does and what you mean by "real lasting damage".
That was the first way Wii owners got homebrew software running: the Wii version of Zelda: Twilight Princess didn't do a bounds check when reading the name of the player's horse from a save file.
http://wiibrew.org/wiki/Twilight_Hack#Explanation
http://wiibrew.org/wiki/Twilight_Hack#Explanation
the real way we got homebrew in the wii in the first place was because of a awful RSA implementation done by outsourced devs in the USA.
http://events.ccc.de/congress/2008/Fahrplan/events/2799.en.h...
http://events.ccc.de/congress/2008/Fahrplan/events/2799.en.h...
http://en.wikipedia.org/wiki/Softmod#Softmods_for_Microsoft_...
Splinter Cell and MechAssault where famous for this. The bug is actually in the XBox Dashboard code itself, so the Host system was buggy.
Splinter Cell and MechAssault where famous for this. The bug is actually in the XBox Dashboard code itself, so the Host system was buggy.
xbox, ps3, wii, psp, gamecube.. this has been a consistent successful attack vector against signed application environments on consoles.
That was my first thought too. MAS is mainly for the general public. While it's a nice long blog with lots of details, it's not a universally correct criticism of MAS.
Wouldn't security-scoped bookmarks solve some of the problems he describes? From the sandbox design guide:
--------------------------------
Starting in Mac OS X v10.6, the NSURL class and the CFURLRef opaque type each provide a facility for creating and using bookmark objects. A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current location. A bookmark’s association with a file-system resource (typically a file or folder) usually continues to work if the user moves or renames the resource, or if the user relaunches your app or restarts the system.
In an app that adopts App Sandbox, you must use a security-scoped bookmark to gain persistent access to a file-system resource.
Security-scoped bookmarks, available starting in Mac OS X v10.7.3, support two use cases:
• An app-scoped bookmark provides a specific sandboxed app with persistent access to a user-specified file or folder.
For example, if your app employs a download or processing folder, present an NSOpenPanel dialog to obtain the user’s intent to use a specific folder. Then, by creating a security-scoped bookmark for that folder and storing it as part of the app’s configuration (perhaps in a property list file or using the NSUserDefaults class), your app acquires a means to obtain future access to the folder.
• A document-scoped bookmark provides a specific document with persistent access to a file.
For example, a code editor typically supports the notion of a project document that refers to other files and needs persistent access to those files. Other examples are an image browser or editor that maintains an image library, in which the library file needs persistent access to the images it owns; or a word processor that supports embedded images, multimedia, or font files in its document format. In these cases, you configure the document format (of the project file, library file, word processing document, and so on) to store security-scoped bookmarks to the files a document refers to. (A document-scoped bookmark can point only to a file, not a folder.)
A document-scoped bookmark can be resolved by any app that has access to the bookmark data itself and to the document that owns the bookmark. The document can be a flat file, or a document distributed as a bundle.
--------------------------------
--------------------------------
Starting in Mac OS X v10.6, the NSURL class and the CFURLRef opaque type each provide a facility for creating and using bookmark objects. A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current location. A bookmark’s association with a file-system resource (typically a file or folder) usually continues to work if the user moves or renames the resource, or if the user relaunches your app or restarts the system.
In an app that adopts App Sandbox, you must use a security-scoped bookmark to gain persistent access to a file-system resource.
Security-scoped bookmarks, available starting in Mac OS X v10.7.3, support two use cases:
• An app-scoped bookmark provides a specific sandboxed app with persistent access to a user-specified file or folder.
For example, if your app employs a download or processing folder, present an NSOpenPanel dialog to obtain the user’s intent to use a specific folder. Then, by creating a security-scoped bookmark for that folder and storing it as part of the app’s configuration (perhaps in a property list file or using the NSUserDefaults class), your app acquires a means to obtain future access to the folder.
• A document-scoped bookmark provides a specific document with persistent access to a file.
For example, a code editor typically supports the notion of a project document that refers to other files and needs persistent access to those files. Other examples are an image browser or editor that maintains an image library, in which the library file needs persistent access to the images it owns; or a word processor that supports embedded images, multimedia, or font files in its document format. In these cases, you configure the document format (of the project file, library file, word processing document, and so on) to store security-scoped bookmarks to the files a document refers to. (A document-scoped bookmark can point only to a file, not a folder.)
A document-scoped bookmark can be resolved by any app that has access to the bookmark data itself and to the document that owns the bookmark. The document can be a flat file, or a document distributed as a bundle.
--------------------------------
Wow thanks; I had not realized there were 10.7.3 related updates to the Sandboxing Guide.
Thanks for the suggestion, this is very helpful. Do you know if this also bypasses issues of file ownership, or is this only relevant to the sandbox? (Editing of non-owned files using an admin password is a gorram nightmare on modern OS X.)
I'm pretty sure it should stay that way... no?
It should be non-trivial for both user and developer, but it shouldn't require interprocess communication and reading fifty-ish pages of docs. It's a little insane, and I gave up on trying. (It was a simple GUI for editing a particular system file, similar to what Cocktail does; like sudo vi, but more convenient.)
Bookmarks are a working solution, the problem is getting the user to locate those urls in the first place. I'm having many of the same problems that the OP mentions and explaining to the user how to locate folders and files correctly is a usability nightmare.
"Click the button below, locate file xyz and 'Open' it to proceed"
I would be perfectly ok with a system "Grant permission to xyz" dialog, but the open file dialog is a terrible way of requiring access to a file or folder.
"Click the button below, locate file xyz and 'Open' it to proceed"
I would be perfectly ok with a system "Grant permission to xyz" dialog, but the open file dialog is a terrible way of requiring access to a file or folder.
> "Click the button below, locate file xyz and 'Open' it to proceed"
Rather than presenting it as some pointless mechanical chore in which you direct a user to a specific file in a known place, wouldn't "Choose where you would like Foo.app to save your XYZ (project/file/whatever)" make a lot more sense?
Rather than presenting it as some pointless mechanical chore in which you direct a user to a specific file in a known place, wouldn't "Choose where you would like Foo.app to save your XYZ (project/file/whatever)" make a lot more sense?
It's not about saving though, it's about reading files that already exist in certain locations.
Imagine for instance an application that helps you clean up your downloads folder, but wouldn't be appropriate to use on other folders on your system. It's not the best example, but it illustrates how much of a usability mess it is to ask the user to locate the folder for you through an open file dialog, and then have to reject it if they select the wrong thing.
Imagine for instance an application that helps you clean up your downloads folder, but wouldn't be appropriate to use on other folders on your system. It's not the best example, but it illustrates how much of a usability mess it is to ask the user to locate the folder for you through an open file dialog, and then have to reject it if they select the wrong thing.
That's a fairly niche case, though. Personally I'm comfortable sacrificing it in favor of not giving apps full read-write access to everything on my system by default.
I can see how there are very specific cases in which it would be too cumbersome, but it probably works in > 80% of cases, and it's pretty clear that those 80% apps are who the App Store is aimed at.
Edit: Thinking about this some more: not to pick on your example, but the Downloads folder actually does need to be located by the user, because it's not actually in a fixed location (it defaults to $HOME/Downloads, but that's not where mine is located, for instance).
There really aren't many cases that I can dream up in which you can absolutely be certain of a file or folder's location, such that an Open Dialog is totally superfluous.
I can see how there are very specific cases in which it would be too cumbersome, but it probably works in > 80% of cases, and it's pretty clear that those 80% apps are who the App Store is aimed at.
Edit: Thinking about this some more: not to pick on your example, but the Downloads folder actually does need to be located by the user, because it's not actually in a fixed location (it defaults to $HOME/Downloads, but that's not where mine is located, for instance).
There really aren't many cases that I can dream up in which you can absolutely be certain of a file or folder's location, such that an Open Dialog is totally superfluous.
It's not really niche though, the entire Utilities and Dev Tools section of the app store are full of these kinds of apps that provide users with convenient management of data in predetermined locations, my own included http://itunes.apple.com/us/app/space-gremlin/id414515628?mt=...
Imagine if there were "just pass a path" APIs. Apps could then just pass a path, users wouldn't care where the path points to even if it's shown to them. "Yeah whatever." Clearly defies the idea of the sandbox.
Apple needs to do better than this.
For the duration of the company's existence, one of their biggest customer segments has been the creative industry. I can't think of a single pro audio/video/graphic/etc app that doesn't make extensive use of plug-ins, another Mac App Store disqualifier.
Do the developers of these apps necessarily have a "right" to iCloud APIs, delta updates, and other benefits of playing in Apple's sandbox? Of course not.
But is Apple harming themselves and their customers by excluding the creators of these apps from the party and potentially causing them to focus their development efforts elsewhere? I think they may be.
For the duration of the company's existence, one of their biggest customer segments has been the creative industry. I can't think of a single pro audio/video/graphic/etc app that doesn't make extensive use of plug-ins, another Mac App Store disqualifier.
Do the developers of these apps necessarily have a "right" to iCloud APIs, delta updates, and other benefits of playing in Apple's sandbox? Of course not.
But is Apple harming themselves and their customers by excluding the creators of these apps from the party and potentially causing them to focus their development efforts elsewhere? I think they may be.
> For the duration of the company's existence, one of their biggest customer segments has been the creative industry
I would have thought the Final Cut Pro X debacle (http://pogue.blogs.nytimes.com/2011/06/23/professional-video...) would have served adequate notice to those folks that Apple doesn't consider them an important market segment anymore...
I would have thought the Final Cut Pro X debacle (http://pogue.blogs.nytimes.com/2011/06/23/professional-video...) would have served adequate notice to those folks that Apple doesn't consider them an important market segment anymore...
Maybe. I hope not. All the filmmakers/editors I know still use a previous version of Final Cut, many of them really like some of the features of Final Cut X (syncing is apparently dead easy, nearly automagic), and remain hopeful that Apple will pull it together and address their needs in future updates.
I don't know if you have used/use Final Cut 6/7, but it is a phenomenally ugly, often poor performing, generally unintuitive piece of software. I can see where the motivation for a full reboot would stem from.
Now, a reboot that involves consolidating formerly modular panes into a single window when the target market typically works on two, three or more displays is just dumb. A reboot that was, as a practical matter, 0% backwards-compatible may have been necessary, but if it could have been avoided, it should have been. But buried under all the mistakes, I think there was some genuine good intent (yes, I know I'm grasping at straws).
I primarily work with music, and you don't need to be as involved as I am or attend as many shows as I do to know that for any artist/band that uses a laptop on stage, the MacBook Pro is the de facto standard. The same applies to Mac Pros in studios (although those boxes may be going the way of the Dodo as well).
None of this necessarily makes a difference to Apple; the new features in Mountain Lion which focus on Chinese web portals and social networks serve as a reminder that the emerging Chinese middle class is likely as important a segment to Apple as any, and the number of potential customers in that group already dwarfs the ranks of every DJ, producer, sound engineer, and electronic musician on earth.
Still, it would be a great disappointment to me and many others if Apple were to abandon such a loyal group of customers who helped them reach this point.
I don't know if you have used/use Final Cut 6/7, but it is a phenomenally ugly, often poor performing, generally unintuitive piece of software. I can see where the motivation for a full reboot would stem from.
Now, a reboot that involves consolidating formerly modular panes into a single window when the target market typically works on two, three or more displays is just dumb. A reboot that was, as a practical matter, 0% backwards-compatible may have been necessary, but if it could have been avoided, it should have been. But buried under all the mistakes, I think there was some genuine good intent (yes, I know I'm grasping at straws).
I primarily work with music, and you don't need to be as involved as I am or attend as many shows as I do to know that for any artist/band that uses a laptop on stage, the MacBook Pro is the de facto standard. The same applies to Mac Pros in studios (although those boxes may be going the way of the Dodo as well).
None of this necessarily makes a difference to Apple; the new features in Mountain Lion which focus on Chinese web portals and social networks serve as a reminder that the emerging Chinese middle class is likely as important a segment to Apple as any, and the number of potential customers in that group already dwarfs the ranks of every DJ, producer, sound engineer, and electronic musician on earth.
Still, it would be a great disappointment to me and many others if Apple were to abandon such a loyal group of customers who helped them reach this point.
FYI, the latest update to Final Cut Pro X was a major update, adding impressive multicam support which uses "audio waveforms from the different cameras to sync them together. The audio doesn't have to be the final production track and can be used for syncing purposes only,"[1] chroma keying, media relinking, import of photoshop layered graphics, support for XML 1.1, and beta broadcast support. This new update has an average review score of 4.5 stars Mac App Store.[2] While Final Cut Pro X started out weak, it looks like it's becoming very solid.
[1] http://www.tuaw.com/2012/01/31/apple-updates-final-cut-pro-x... [2] http://itunes.apple.com/us/app/final-cut-pro/id424389933?mt=...
[1] http://www.tuaw.com/2012/01/31/apple-updates-final-cut-pro-x... [2] http://itunes.apple.com/us/app/final-cut-pro/id424389933?mt=...
It's the opposite. Taking the time AND money to rewrite the old Final Cut Pro codebase from scratch is an indication that Apple is pretty much dedicated to their Pro apps.
Unlike, say, Adobe, that merely piles incremental bloat upon incremental bloat, and calls it a "new version of the suite".
The complains are from people that:
1) see a black interface as some kind of iMovie-fication (iMovie is black, so they have dumded down FCP).
2) Think professional software means convoluted GUI (they made things simpler, so they have dumbed it down)
3) Expect a rewrite of a 10+ year old codebase to have feature parity with the old version from day one.
4) Expect a rewrite of a 10+ year old codebase, with the intention to support modern movie making practices, to also cater for obsolete practices that the old version covered (like tape editing).
Unlike, say, Adobe, that merely piles incremental bloat upon incremental bloat, and calls it a "new version of the suite".
The complains are from people that:
1) see a black interface as some kind of iMovie-fication (iMovie is black, so they have dumded down FCP).
2) Think professional software means convoluted GUI (they made things simpler, so they have dumbed it down)
3) Expect a rewrite of a 10+ year old codebase to have feature parity with the old version from day one.
4) Expect a rewrite of a 10+ year old codebase, with the intention to support modern movie making practices, to also cater for obsolete practices that the old version covered (like tape editing).
As I indicated above, I think the reboot of Final Cut was well intended.
Having said that, I've had far too many conversations with far too many professional filmmakers and editors (I'm talking "multiple all-nighters every week editing multicam RED; invitations to Cannes; contracts to produce music videos for multi-platinum selling artists and promos for Fortune 100 companies" professional) about the weaknesses of Final Cut X to have much regard for the opinion you've shared here.
Ultimately, if the intended users are dissatisfied, then Apple missed the mark, any rationalizations from armchair analysts notwithstanding.
By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.
Having said that, I've had far too many conversations with far too many professional filmmakers and editors (I'm talking "multiple all-nighters every week editing multicam RED; invitations to Cannes; contracts to produce music videos for multi-platinum selling artists and promos for Fortune 100 companies" professional) about the weaknesses of Final Cut X to have much regard for the opinion you've shared here.
Ultimately, if the intended users are dissatisfied, then Apple missed the mark, any rationalizations from armchair analysts notwithstanding.
By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.
Ultimately, if the intended users are dissatisfied, then Apple missed the mark
Not really. System 9 Users also complained about OS X 10. How it wasn't like OS 9, how it missed some features, how it was unstable etc. But putting a nice foundation down is better than giving instant gratification to your users in the long run.
By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.
Or just use the old version for your old projects, and only move to the new one for new stuff?
What kind of Pro jumps to a new version of a core tool anyway as soon as it it released? Most actuals Pros keep their setups steady for many years. Which is why I think most of the noise is from low production tinkerers, that already use both FC and Premiere etc.
Not really. System 9 Users also complained about OS X 10. How it wasn't like OS 9, how it missed some features, how it was unstable etc. But putting a nice foundation down is better than giving instant gratification to your users in the long run.
By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.
Or just use the old version for your old projects, and only move to the new one for new stuff?
What kind of Pro jumps to a new version of a core tool anyway as soon as it it released? Most actuals Pros keep their setups steady for many years. Which is why I think most of the noise is from low production tinkerers, that already use both FC and Premiere etc.
Actually, the sandbox seems like a requirement for safely distributing apps that allow plug-ins.
Can you explain how this works? My understanding is that plugins — defined for clarity's sake as "loadable code that interacts with the original application but was not included in it" — are not allowed in the sandbox. Has this been fixed? Or did you mean something else?
I mean that plugins are very unsafe if there's no sandbox. I don't mean they got actually allowed.
Are you suggesting that every pro media application released before March 1, 2012 was not safely distributed?
I guess I should step back a bit and make my argument more clear. I'm not opposed to the concept of sandboxing, I recognize the benefits of these policies as Apple's user base grows and malware becomes a greater concern.
My contention is that the imposition this places on users and developers alike will most likely dissuade pro media software developers from participating in the Mac App Store to begin with, thereby depriving Apple of potential income, depriving developers access to useful features like iCloud file sharing/mirroring, and exposing users to the very risks this policy is intended to shield them from.
I guess I should step back a bit and make my argument more clear. I'm not opposed to the concept of sandboxing, I recognize the benefits of these policies as Apple's user base grows and malware becomes a greater concern.
My contention is that the imposition this places on users and developers alike will most likely dissuade pro media software developers from participating in the Mac App Store to begin with, thereby depriving Apple of potential income, depriving developers access to useful features like iCloud file sharing/mirroring, and exposing users to the very risks this policy is intended to shield them from.
I'm suggesting that every single application prior sandboxing was not safely distributed. It's not like anyone had a choice, there was an age before airbags.
I also disagree that extensibility is in conflict with sandboxing. As for pro media software developers, I'm pretty sure it's just a matter of time and polishing of the platform. AutoCad LT is already in.
I also disagree that extensibility is in conflict with sandboxing. As for pro media software developers, I'm pretty sure it's just a matter of time and polishing of the platform. AutoCad LT is already in.
I'm not sure why the Mac App Store represents the high water mark for safety (as opposed to a secure server maintained by the people who actually developed the software or MacPorts/Fink/Homebrew) but whatever.
Many popular audio plugins are themselves plugin hosts (just off the top of my head, Native Instruments' Reaktor, Maschine, and Guitar Rig and Five12 Numerology match that description). In this context, wouldn't that require nested sandboxes? You're sure you don't see any potential conflicts there?
Many popular audio plugins are themselves plugin hosts (just off the top of my head, Native Instruments' Reaktor, Maschine, and Guitar Rig and Five12 Numerology match that description). In this context, wouldn't that require nested sandboxes? You're sure you don't see any potential conflicts there?
Not really. They still can't access files outside of what has already been granted to the main application.
Are you suggesting that every pro media application released before March 1, 2012 was not safely distributed?
Yes. Is that hard to grasp? Sanboxing is safer than the old distribution practice. You won't find any security expert to disagree with this.
Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.
Yes. Is that hard to grasp? Sanboxing is safer than the old distribution practice. You won't find any security expert to disagree with this.
Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.
My intent isn't to bash Apple, I love their products and intend to use them for the rest of my life, provided they don't fuck it up.
I don't want to see them fuck it up.
Now:
>Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.
First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed. The only reason we're discussing both issues here is that Apple has elected to conflate the two with their MAS policies.
I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.
My contention is not that sandboxing, generally speaking, is bad for users. It isn't.
My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.
Furthermore, if developers choose to eschew the MAS, users of their applications will be deprived access to useful new tools like iCloud file sharing for reasons that seem arbitrary at best.
Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.
I don't want to see them fuck it up.
Now:
>Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.
First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed. The only reason we're discussing both issues here is that Apple has elected to conflate the two with their MAS policies.
I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.
My contention is not that sandboxing, generally speaking, is bad for users. It isn't.
My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.
Furthermore, if developers choose to eschew the MAS, users of their applications will be deprived access to useful new tools like iCloud file sharing for reasons that seem arbitrary at best.
Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.
First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed.
Well, it's a pedantic distinction if sanboxing occurs before or after. Since, sure, sanboxing rules are applied at runtime, but sanboxing is also built into the app before distribution (the developers adds the certs, the "ask for permission" bits, etc).
I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.
Well, in Windows lots of apps have wrecked havoc with my system. Malware, spyware, what have you. I've hand around 10 instances of my machine being infected in around 8 years of using a Windows machine. In OS X, on the other hand, nothing yet. And sandboxing is a way to ensure it won't be so in the future.
But there's is also another issue for which I think sandboxing is nice, besides malware. It keeps apps from spiting stuff all over the system. Like, how MS Office installs its shit everywhere it can, or how Abode Creative suite does. Same things for lots of small apps. If sandboxing can keep the confided in their own space, that will also be a win.
My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.
Well, I think those rules can change. They already extended the period before sandboxing is applied. I'm sure as limitations are found we will see other changes too.
For some apps, on the other hand, like developer tools, rsync, git etc, they will always have to run without sandboxing.
Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.
I'm not sure about the "anticompetitively" thing. It's their store, their rules. If sandboxing is about not trusting apps, then why would Apple require it for their own apps? One would think they trust them already.
Well, it's a pedantic distinction if sanboxing occurs before or after. Since, sure, sanboxing rules are applied at runtime, but sanboxing is also built into the app before distribution (the developers adds the certs, the "ask for permission" bits, etc).
I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.
Well, in Windows lots of apps have wrecked havoc with my system. Malware, spyware, what have you. I've hand around 10 instances of my machine being infected in around 8 years of using a Windows machine. In OS X, on the other hand, nothing yet. And sandboxing is a way to ensure it won't be so in the future.
But there's is also another issue for which I think sandboxing is nice, besides malware. It keeps apps from spiting stuff all over the system. Like, how MS Office installs its shit everywhere it can, or how Abode Creative suite does. Same things for lots of small apps. If sandboxing can keep the confided in their own space, that will also be a win.
My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.
Well, I think those rules can change. They already extended the period before sandboxing is applied. I'm sure as limitations are found we will see other changes too.
For some apps, on the other hand, like developer tools, rsync, git etc, they will always have to run without sandboxing.
Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.
I'm not sure about the "anticompetitively" thing. It's their store, their rules. If sandboxing is about not trusting apps, then why would Apple require it for their own apps? One would think they trust them already.
MAS applications are not disallowed from supporting plugins.
You're technically correct.
They're just disallowed from supporting plugins in the manner that they have been on every platform for 20 or 30 years.
They're just disallowed from supporting plugins in the manner that they have been on every platform for 20 or 30 years.
Providing deep platform-specific support in a cross-platform codebase is a pain; believe me I get that. But platforms evolve, and frankly the ways they've been evolving recently is likely much tougher to keep up with than "loading plugins from a new location, or with a new security context", especially for a time-based media application.
Wholesale changes in OS or environment runtime? Changes in underlying processor architecture? Forced update to full 64-bit support? Customers wanting to operate on files that are an order of magnitude larger?
If these apps have any claim to being worth hundreds or thousands of dollars per seat, and charging hundreds of dollars for basic compatibility updates, their developers should Pro-up and deal with this change like they've dealt with others.
And given the motivation for the change, I think they should skip the complaining step and lean into the work.
Wholesale changes in OS or environment runtime? Changes in underlying processor architecture? Forced update to full 64-bit support? Customers wanting to operate on files that are an order of magnitude larger?
If these apps have any claim to being worth hundreds or thousands of dollars per seat, and charging hundreds of dollars for basic compatibility updates, their developers should Pro-up and deal with this change like they've dealt with others.
And given the motivation for the change, I think they should skip the complaining step and lean into the work.
I mostly agree, with one exception:
"SSH keys and agent configuration are automatically picked up, so access to remotes over SSH ‘just works’"
Um, no. If there's one thing that's more private than my address book, it's my ssh keys. The fact that they aren't available to your application by default is a feature. If you need a key, ask me for it. If I want to give you the access, I'll do that.
Um, no. If there's one thing that's more private than my address book, it's my ssh keys. The fact that they aren't available to your application by default is a feature. If you need a key, ask me for it. If I want to give you the access, I'll do that.
Under OS X, the Mac Keychain framework hooks into ssh-agent, so you don't have to retype your private key passphrase over and over, just once per session.
There are other tools that do similar in other OS's, for example the "keychain" script in Debian. This isn't something weird IMO.
There are other tools that do similar in other OS's, for example the "keychain" script in Debian. This isn't something weird IMO.
That would actually be (GUI, it doesn't work like this actually, I think, but what I want would look the same) ideal: you don't get my ssh key. You get an ssh session arranged for by the keychain. Too bad it's probably too much work for something not enough people use (and those who use it are generally security-conscious enough to avoid malware on their own).
If you call `ssh` on the command line it will use Keychain to unlock your private SSH key.
That part is done. The application shouldn't be asking for SSH keys, it is completed already. Just use `ssh` as you would before.
That part is done. The application shouldn't be asking for SSH keys, it is completed already. Just use `ssh` as you would before.
And if you type 'ssh-add' you'll only have to enter your passphrase once. I think this all got sorted out beginning with Leopard; before that, it may not have worked as expected (compared to other *NIX environments).
ssh-agent has shipped from the very beginning (that's part of the ssh distribution). The only thing that was different was that it wasn't bridged to the system keychain until recently. Or more accurately, the system keychain now runs its own version of ssh-agent automatically.
Yeah, I just checked up on the man page, and the agent actually works the way I'd want it to. So it's just a question if a sandboxed app has access to the agent.
The real question regarding the Mac App Store, IMHO, is whether or not it forbids a broad enough class of still-popular applications that it fails to achieve the goal of becoming the default distribution method for applications on the Mac and instead is relegated to games and simple utilities that fit nicely inside this model.
Very very popular apps like:
The Mac App Store loses a bit of its allure when you get your new MacBook Air [even as a non developer] and can't find basics like Chrome or Dropbox or Microsoft Office in there.
Very very popular apps like:
Chrome
Photoshop/Adobe CS
Fusion/Parallels
Microsoft Office
Text Editors
FTP Clients
Dropbox
The Mac App Store loses a bit of its allure when you get your new MacBook Air [even as a non developer] and can't find basics like Chrome or Dropbox or Microsoft Office in there.
The Mac App Store loses a bit of its allure when you get your new MacBook Air [even as a non developer] and can't find basics like Chrome or Dropbox or Microsoft Office in there.
I can testify about that. I just bought MBA recently and opened up App Store out of curiosity, however almost all of software I needed I bought at writer's store (apparently there is final draft now in app store, but I bought directly from Final Draft). Same goes for Office, Chrome, Dropbox, etc...
I can testify about that. I just bought MBA recently and opened up App Store out of curiosity, however almost all of software I needed I bought at writer's store (apparently there is final draft now in app store, but I bought directly from Final Draft). Same goes for Office, Chrome, Dropbox, etc...
Pretend I'm Apple answering these questions for a moment...
> Chrome
"Safari."
> Photoshop/Adobe CS
"Creatives? Did you see what we did to Final Cut? Have you noticed how little we talk about the Mac Pro anymore?"
> Fusion/Parallels
> Text Editors
> FTP Clients
"We're in the consumer products business, not the 'tools for nerds' business. Ask an XServe customer if you want more information."
> Microsoft Office
"We could care less if we sell boring-ass business software into enterprises."
> Dropbox
"iCloud."
> Chrome
"Safari."
> Photoshop/Adobe CS
"Creatives? Did you see what we did to Final Cut? Have you noticed how little we talk about the Mac Pro anymore?"
> Fusion/Parallels
> Text Editors
> FTP Clients
"We're in the consumer products business, not the 'tools for nerds' business. Ask an XServe customer if you want more information."
> Microsoft Office
"We could care less if we sell boring-ass business software into enterprises."
> Dropbox
"iCloud."
Or, far more accurately, "You can get these all apps from the developers directly. We don't support them on the Mac App Store at this time, and we don't discuss future product directions".
Two and half, three years ago, people predicted this move for OS X after the locked down nature of the iPhone really took hold. There are people that swore up and down that signed applications would never come to OS X and that there would never be a walled ecosystem on a non-iOS Mac product. Now we know this to be blatantly false. Apple's biggest money comes from devices that have an exclusively walled ecosystem. It seems pretty clear that they want users using what they provide to them. I don't think it's incredibly inaccurate to say that they don't care that they're not supporting major competing applications.
Wait, what? Who claimed that signed applications won't come to OS X? Windows has had them for years. People said that OS X would never be limited to App Store purchases only and that's still the case. In fact, lots of people expected the default to be "App Store curated only, with an off switch. Instead, we got the comparatively surprising "Signed only with no checks on what's signed, with easy to use off switch" (i.e. app by app exemptions even for full lockdown mode).
Apple's money comes from selling a cohesive experience. That, on iOS, that's been helped by a "walled garden" approach does not indicate that the same approach will make OS X better. Some people have been crying wolf since iOS 1.0 about the demise of the open Mac platform. They were wrong about Snow Leopard, they were wrong about Lion, and they're wrong about Mountain Lion. It's beginning to sound like a certain boy and a certain wolf.
Apple's money comes from selling a cohesive experience. That, on iOS, that's been helped by a "walled garden" approach does not indicate that the same approach will make OS X better. Some people have been crying wolf since iOS 1.0 about the demise of the open Mac platform. They were wrong about Snow Leopard, they were wrong about Lion, and they're wrong about Mountain Lion. It's beginning to sound like a certain boy and a certain wolf.
How can you say they're completely wrong? Every iteration brings in more iOS features, often with no way to opt-out or the option is buried away or hidden in a plist setting. Mission Control versus the old Expose? App persisting (both in memory and) state. Not showing hidden files in Finder. More iCloud integration at seemingly every turn in Mountain Lion.
It's clear that Apple is making OS X more and more and more like iOS. I think you're right the loud-mouth "DOOM" scare posts are a bit silly and I hope I'm not coming across that way. I just think that people are accepting this when they wouldn't have imagined OS X looking like it will soon with Mountain Lion a year or two.
Sigh, if you're going to downvote, please have the courtesy of telling me what was so inflammatory about my post. Especially if you're going to drive by downvote all of mine in a particular portion of the thread. I mean, good god, this post is simply a listing of observations and then an agreement with the parent that many people draw absurd conclusions.
It's clear that Apple is making OS X more and more and more like iOS. I think you're right the loud-mouth "DOOM" scare posts are a bit silly and I hope I'm not coming across that way. I just think that people are accepting this when they wouldn't have imagined OS X looking like it will soon with Mountain Lion a year or two.
Sigh, if you're going to downvote, please have the courtesy of telling me what was so inflammatory about my post. Especially if you're going to drive by downvote all of mine in a particular portion of the thread. I mean, good god, this post is simply a listing of observations and then an agreement with the parent that many people draw absurd conclusions.
Mission Control versus the old Expose?
Yeah, isn't it much better?
App persisting (both in memory and) state.
Yay, a modern operating system practice finally in OS X. The OS should take advantage of what it can do, to balance apps loading faster and using less resources. For all I care, the ideal would be all apps to be always INSTANT ON.
Not showing hidden files in Finder.
Hidden files shouldn't be an end user's concern.
More iCloud integration at seemingly every turn in Mountain Lion.
Yeah, finally. We don't live with ONE computer anymore, we have several, plus several devices. We want them synced. We want them to backup online. We want a modern Cloud service from Apple.
Yeah, isn't it much better?
App persisting (both in memory and) state.
Yay, a modern operating system practice finally in OS X. The OS should take advantage of what it can do, to balance apps loading faster and using less resources. For all I care, the ideal would be all apps to be always INSTANT ON.
Not showing hidden files in Finder.
Hidden files shouldn't be an end user's concern.
More iCloud integration at seemingly every turn in Mountain Lion.
Yeah, finally. We don't live with ONE computer anymore, we have several, plus several devices. We want them synced. We want them to backup online. We want a modern Cloud service from Apple.
>We want a modern Cloud service from Apple.
I feel like you're completely and intentionally ignoring the point I'm trying to make.
I feel like you're completely and intentionally ignoring the point I'm trying to make.
Just wanting to say that what one sees as "problems", other people are perfectly happy with, and even happier than with the old status quo.
I don't even see them as "problems"; at least not in some altruistic form for the platform necessarily. I just think that a curated, managed platform is something that Apple has been very, very, very successful with (and obviously because people are down with it), and it seems obvious to me that OS X is moving in that direction.
Like I said, I don't think it's fair to imply that they will shut out non-AppStore apps or what not, but it's clear that OS X is becoming part of the LARGER Apple ecosystem in a way that I really don't feel like it was in Leopard or Snow Leopard.
I mean, they're ALL doing it as the app/branding craze comes full circle. Ubuntu is pushing the USC, Windows is pushing Live for login/user management, Apple is integrating iCloud at a very core level in OS X. I guess part of my surprise is from how quickly Apple has thrown iCloud together and integrated it compared to how long Windows has been scrambling with Live and Windows.
Like I said, I don't think it's fair to imply that they will shut out non-AppStore apps or what not, but it's clear that OS X is becoming part of the LARGER Apple ecosystem in a way that I really don't feel like it was in Leopard or Snow Leopard.
I mean, they're ALL doing it as the app/branding craze comes full circle. Ubuntu is pushing the USC, Windows is pushing Live for login/user management, Apple is integrating iCloud at a very core level in OS X. I guess part of my surprise is from how quickly Apple has thrown iCloud together and integrated it compared to how long Windows has been scrambling with Live and Windows.
Two and half, three years ago, people predicted this move for OS X after the locked down nature of the iPhone really took hold. There are people that swore up and down that signed applications would never come to OS X and that there would never be a walled ecosystem on a non-iOS Mac product.
Actually, nothing of the kind ever happened. Maybe some idiots did, but security experts have been nagging Apple to add signed apps all the time (Windows had them for ages), and people were also interested in a Mac App Store (not to mention developers, who saw it as another gold rush after the successful iPhone App Store).
Besides, from the very first OS X, say, 10.0.1 to 10.8, nothing has been taken away from user freedom. What exactly can't you do in 10.8 that you could in 10.0.1? They only ADDED stuff, i.e not you can also get stuff from the App Store, and in 10.8 you can also run secure, signed, apps.
Plus, why wouldn't OS X have a "walled garden"? Linux distros had one for ages, we call 'em "package repositories". Yeah, you can install stuff in other ways too in a Linux distro, but then again, so you can on OS X 10.8.
Actually, nothing of the kind ever happened. Maybe some idiots did, but security experts have been nagging Apple to add signed apps all the time (Windows had them for ages), and people were also interested in a Mac App Store (not to mention developers, who saw it as another gold rush after the successful iPhone App Store).
Besides, from the very first OS X, say, 10.0.1 to 10.8, nothing has been taken away from user freedom. What exactly can't you do in 10.8 that you could in 10.0.1? They only ADDED stuff, i.e not you can also get stuff from the App Store, and in 10.8 you can also run secure, signed, apps.
Plus, why wouldn't OS X have a "walled garden"? Linux distros had one for ages, we call 'em "package repositories". Yeah, you can install stuff in other ways too in a Linux distro, but then again, so you can on OS X 10.8.
Not sure why you're getting down-voted. For regulators, this will be the key question: is Apple disadvantaging third parties who produce software that competes with their own?
As someone who has lived through a protracted antitrust review (Google acquiring ITA Software, a company I co-founded), I can tell you that there are dozens of hard-working people at the DOJ and FTC ready to make their careers on taking Apple down should Apple give them the tools to do so. A "some animals are more equal than others" app store policy -- whether intended or unintended -- is definitely fodder for a juicy DOJ/FTC lawsuit.
As someone who has lived through a protracted antitrust review (Google acquiring ITA Software, a company I co-founded), I can tell you that there are dozens of hard-working people at the DOJ and FTC ready to make their careers on taking Apple down should Apple give them the tools to do so. A "some animals are more equal than others" app store policy -- whether intended or unintended -- is definitely fodder for a juicy DOJ/FTC lawsuit.
Really, the average consumer's needs are met by iLife + iWork.
That gives a photo editor, a movie editor, spreadsheet, and word processor.
That gives a photo editor, a movie editor, spreadsheet, and word processor.
The problem with iWork is interoperability with MS Office. I recently got my parents set up with a new iMac and had them buy iWork instead of MS Office. They quickly switched back to MS Office after getting frustrated at having to export their Pages docs as Word docs every time instead of saving, and dealing with formatting loss when importing from Doc into Pages.
iWork is a much better and more user-friendly set of software than MS Office (unless you're an Excel power-user, in which case the OS X version of Excel probably isn't cutting it for you either), but it's tough to recommend it for non-technical people who need to work with Windows folk.
iWork is a much better and more user-friendly set of software than MS Office (unless you're an Excel power-user, in which case the OS X version of Excel probably isn't cutting it for you either), but it's tough to recommend it for non-technical people who need to work with Windows folk.
Photoshop/Adobe CS "Creatives? Did you see what we did to Final Cut?
What DID they do to Final Cut? They spend tons of money and engineering time to rewrite the app from scratch with a modern codebase and added new innovative features. The got it to 64bit, they added the magnetic timeline (HUGE timesaver), the improved tons of workflow stuff, they made it take advantage of multiple cores, and they made it work with files in whatever format they are in to begin with.
In the process, as with any version 1.0 app, FPCX lost a few of the features that the old, bloated, version of FCP had. Some because you just cannot just scratch from scratch and replicate absolutely everything at once, and others because they don't make much sense moving forward. Some of those features, like multicam editing, they delivered in subsequent minor versions (of which there have been 3 already).
That is much more than what Adobe does, which is incrementally adding a few features, without ever rethinking their apps, and keeps adding bloat upon bloat (Flash based custom panels, anyone?) to the same 10 or 20 year old codebase. Apple betted on the future, Adobe plays it safe.
So, I beg to differ in respect to FCP X.
Have you noticed how little we talk about the Mac Pro anymore?"
And why should they? A quad core iMac is just as capable for the needs of 90% of creatives, and in fact, if you looked at any design studio in the past 2-3 years you were more likely to find one of those than a Mac Pro or a G5.
They also know that they sell a very small amount of those Pro machines, and it's not like Intel is making new chips for them all the time.
Besides, Thunderbird, the Apple/Intel interconnect perfectly suited for professionals and creatives that no other PC vendor took the time and effort to create, solves most of the connectivity issues that an iMac (or even a MacBook Pro laptop) had related to a Mac Pro.
What DID they do to Final Cut? They spend tons of money and engineering time to rewrite the app from scratch with a modern codebase and added new innovative features. The got it to 64bit, they added the magnetic timeline (HUGE timesaver), the improved tons of workflow stuff, they made it take advantage of multiple cores, and they made it work with files in whatever format they are in to begin with.
In the process, as with any version 1.0 app, FPCX lost a few of the features that the old, bloated, version of FCP had. Some because you just cannot just scratch from scratch and replicate absolutely everything at once, and others because they don't make much sense moving forward. Some of those features, like multicam editing, they delivered in subsequent minor versions (of which there have been 3 already).
That is much more than what Adobe does, which is incrementally adding a few features, without ever rethinking their apps, and keeps adding bloat upon bloat (Flash based custom panels, anyone?) to the same 10 or 20 year old codebase. Apple betted on the future, Adobe plays it safe.
So, I beg to differ in respect to FCP X.
Have you noticed how little we talk about the Mac Pro anymore?"
And why should they? A quad core iMac is just as capable for the needs of 90% of creatives, and in fact, if you looked at any design studio in the past 2-3 years you were more likely to find one of those than a Mac Pro or a G5.
They also know that they sell a very small amount of those Pro machines, and it's not like Intel is making new chips for them all the time.
Besides, Thunderbird, the Apple/Intel interconnect perfectly suited for professionals and creatives that no other PC vendor took the time and effort to create, solves most of the connectivity issues that an iMac (or even a MacBook Pro laptop) had related to a Mac Pro.
I've been wondering/worried what Gatekeeper, sandboxing, and the rise of the Mac App store in general are going to mean for third party plugin type apps, say for instance Native Instruments virtual synth plugins, or photoshop plugins. iOS can't really handle them, but will they be able to continue to exist on future macs, or will they only work on the non-app store model?
1. By the letter of the law, Mac App Store apps are to be sandboxed, which means no /Library access, which means no plug-ins. In practice, Logic, Mainstage, Final Cut, and others are currently available in the Mac App Store. To me, the only thing that would make these harsh restrictions worse would be uneven enforcement of the rules. We'll see what happens.
2. As of iOS 5, the platform has native Audio Unit support. I haven't seen much use of it, more commonly devs have been porting their work to JUCE (as in the case of the Auria iPad DAW, which features some popular third party plug-ins as in-app purchases).
2. As of iOS 5, the platform has native Audio Unit support. I haven't seen much use of it, more commonly devs have been porting their work to JUCE (as in the case of the Auria iPad DAW, which features some popular third party plug-ins as in-app purchases).
> By the letter of the law, Mac App Store apps are to be sandboxed, which means no /Library access, which means no plug-ins.
I don't understand: What prevents an app from having an "Add Plugin..." dialog that uses the sandboxed file browser to locate a plugin library in whatever sensible format?
I don't understand: What prevents an app from having an "Add Plugin..." dialog that uses the sandboxed file browser to locate a plugin library in whatever sensible format?
No technical limitation that I can think of prevents the scenario you've described.
As a practical matter, it would require anything up to and including a full rewrite of every pro media creation app on the market. The standard to date has been that there is a specified folder for plug-ins, and the host scans the folder for installed plug-ins on startup.
One benefit of this arrangement is that the user must install the plug-in only once to have access to it in any application that supports its plug-in format. Let's use pro audio apps as an example. I use Ableton Live and Native Instruments Maschine as my primary compositional tools, but I prefer to mix/master in Reaper. Given your alternative method, when I purchased Madrona Labs' Aalto, one of my favorite virtual instruments released in recent memory, I would have needed to endure three separate installation processes to have access to the plug-in in each app where I might want to use it.
Additionally, Maschine happens to have the ability to run both as a standalone application and as a VST plug-in. Let's say I sketched out a beat in Maschine standalone, using Aalto to produce some cool Buchla bongo sounds. Later, in Live, I insert an instance of the Maschine VST and open my project file for further processing. Do I now have nested sandboxes? Will it work at all?
Things get even more complicated when one considers the plug-in developers who require iLoks (license verification USB dongles). These seem even less likely to be compatible with Apple's new processes. Don't get me wrong, I hate and refuse to use iLoks, and by extension any software which requires them. But many Pro Tools/Waves/Soundtoys/etc users are just used to the inconvenience of a hardware dongle at this point, and the companies I mentioned have many satisfied customers.
It seems to me more likely that rather than rewriting their apps or fundamentally adjusting their license verification practices, many of these developers will simply avoid the App Store altogether. As a consequence, users suffer.
As a practical matter, it would require anything up to and including a full rewrite of every pro media creation app on the market. The standard to date has been that there is a specified folder for plug-ins, and the host scans the folder for installed plug-ins on startup.
One benefit of this arrangement is that the user must install the plug-in only once to have access to it in any application that supports its plug-in format. Let's use pro audio apps as an example. I use Ableton Live and Native Instruments Maschine as my primary compositional tools, but I prefer to mix/master in Reaper. Given your alternative method, when I purchased Madrona Labs' Aalto, one of my favorite virtual instruments released in recent memory, I would have needed to endure three separate installation processes to have access to the plug-in in each app where I might want to use it.
Additionally, Maschine happens to have the ability to run both as a standalone application and as a VST plug-in. Let's say I sketched out a beat in Maschine standalone, using Aalto to produce some cool Buchla bongo sounds. Later, in Live, I insert an instance of the Maschine VST and open my project file for further processing. Do I now have nested sandboxes? Will it work at all?
Things get even more complicated when one considers the plug-in developers who require iLoks (license verification USB dongles). These seem even less likely to be compatible with Apple's new processes. Don't get me wrong, I hate and refuse to use iLoks, and by extension any software which requires them. But many Pro Tools/Waves/Soundtoys/etc users are just used to the inconvenience of a hardware dongle at this point, and the companies I mentioned have many satisfied customers.
It seems to me more likely that rather than rewriting their apps or fundamentally adjusting their license verification practices, many of these developers will simply avoid the App Store altogether. As a consequence, users suffer.
Nothing, and IIRC this is what I've seen recommended on Dev Forum. Browse to plugin, copy plugin to app sandbox (or with 10.7.3 maybe get new security managed context handle to FS object), load. I don't have an app that does this so I can't comment on any possible issues around code signatures.
Sorry I can't point to individual forum threads at the moment.
Sorry I can't point to individual forum threads at the moment.
How could Apple handle sandboxing in Xcode? It doesn't seem possible. Right now they just distribute the installer via the app store, but I thought they were planning to put the whole app in there.
I wonder if Apple might give some companies of just distributing the installer via the app store as well.
I wonder if Apple might give some companies of just distributing the installer via the app store as well.
Apple fairly routinely lets themselves be exceptions to rules for their own platform. Lion is distributed via the Mac App Store, and I'd put money on them not allowing Ubuntu or Windows to be distributed via the Mac App Store in a similar fashion[1].
1: future anti-trust cases or congressional testimonies nonwithstanding
1: future anti-trust cases or congressional testimonies nonwithstanding
Hypothetical rule: "Operating Systems may be distributed through the Mac App Store only if they are capable of running the Mac App Store"
They just updated xcode today. In the new update they're slightly more in compliance as it is no longer an installer that is downloaded, it's an app package. You can tell they spent some time reworking stuff to get it working correctly within those app store rules.
Xcode was not distributed through the App Store, an Installer for Xcode was distributed through the App Store.
When I think of all the articles that have passed through the HN front page about mobile developers' terrible experience with the app store, I can't imagine why a desktop software developer would voluntarily subject themselves to it.
Sure, iDevice developers have no choice. But for desktop software there's this handy thing called the Internet. Why kick up revenue to apple, subject myself to submission rules and arbitrary rejection, absurd technical limitations and switcheroos like the one described in this article, and all the rest?
Sure, iDevice developers have no choice. But for desktop software there's this handy thing called the Internet. Why kick up revenue to apple, subject myself to submission rules and arbitrary rejection, absurd technical limitations and switcheroos like the one described in this article, and all the rest?
"When I think of all the articles that have passed through the HN front page about mobile developers' terrible experience with the app store"
Right, there are no success stories.
"Why kick up revenue to apple"
People keep saying this like Apple doesn't deliver buying customers and revenue. The app store making a profit on sales is exactly how every other store in the world works. Why does Apple 'kick up revenue' to Amazon when they could just sell all their iPads online through Apple.com? The answer is because lots of people shop at Amazon and Apple will sell way more iPads with Amazon then without them.
Right, there are no success stories.
"Why kick up revenue to apple"
People keep saying this like Apple doesn't deliver buying customers and revenue. The app store making a profit on sales is exactly how every other store in the world works. Why does Apple 'kick up revenue' to Amazon when they could just sell all their iPads online through Apple.com? The answer is because lots of people shop at Amazon and Apple will sell way more iPads with Amazon then without them.
If the app store can truly compete with an open marketplace, why won't apple let me install arbitrary software on my iDevice?
It's common courtesy to announce when one's surrendering an argument and starting a new one.
"If the app store can truly compete with an open marketplace"
As it turns out there is an open market for iOS apps and an open alternative to iOS and Apple's walled garden is competitive with both.
"why won't apple let me install arbitrary software on my iDevice?"
Aren't the reasons obvious? Simplicity, profit, security?
You might as well be asking why your Macy's card doesn't work at Sears or why you can't make a copy of your building key at Sears or why.. hey just what does Sears have against freedom anyway?
"If the app store can truly compete with an open marketplace"
As it turns out there is an open market for iOS apps and an open alternative to iOS and Apple's walled garden is competitive with both.
"why won't apple let me install arbitrary software on my iDevice?"
Aren't the reasons obvious? Simplicity, profit, security?
You might as well be asking why your Macy's card doesn't work at Sears or why you can't make a copy of your building key at Sears or why.. hey just what does Sears have against freedom anyway?
Since you've asked, Steko, I'll continue as if you're actually interested in exploring this topic with me. I promise I was trying to contribute to my argument and not change the subject. Please calm your fury.
First, what is this open market for iOS apps you mentioned? I haven't heard of it.
Of course Apple locks down the app store on their iDevices for profit. I think we're in agreement on that. If they didn't limit software delivery in that way, their app store would have to compete with other software delivery channels including the open web.
What I'm trying to express is my surprise that developers in the desktop world would opt in to a market like this. I had assumed that iDevice developers only used the app store because they had no choice.
First, what is this open market for iOS apps you mentioned? I haven't heard of it.
Of course Apple locks down the app store on their iDevices for profit. I think we're in agreement on that. If they didn't limit software delivery in that way, their app store would have to compete with other software delivery channels including the open web.
What I'm trying to express is my surprise that developers in the desktop world would opt in to a market like this. I had assumed that iDevice developers only used the app store because they had no choice.
"Of course Apple locks down the app store on their iDevices for profit."
I doubt that Apple is solely concerned with profit and even if they were I guess I don't see that as the end of the world.
If Apple is solely concerned with profiting from apps why do they subsidize free ones and credit card fees? {If dev share is actually calculated post cc fees I'll plead ignorance and move on to the other part of the argument.}
99 cent app less 69 cents to developer less 40-70 cents to credit card company less bandwidth fees = loss.
(I've given a range on cc fees because they are shared if you purchase multiple apps within a few days, that mitigates the loss but ultimately someone motivated only by profit would be taking easily avoided losses all over the place in either scenario.)
Isn't it well known that Apple's direct profit on the App Store is a rounding error compared to their other business?
Isn't it then more likely then that their motivation is not primarily to directly profit from it?
While I do think Apple is interested in profit here, I very deliberately listed it as secondary to simplicity which is really at the heart of everything Apple does well. There's a book coming out soon about just this:
http://kensegall.com/blog/2012/02/and-now-a-different-kind-o...
The premise I'm building on is that Apple really profits by making great products that just work and make people happy. Having a super simple way to get apps is part of that.
For 98%+ of users 1 app store >> 2 app stores >> 10 app stores. One App Store just works. It also stops most malware without any action by the user. That's simplicity again.
"What I'm trying to express is my surprise that developers in the desktop world would opt in to a market like this"
I guess again I'll fall back on my Sears comparison. I don't know if Sears still sells software but they did for decades -- Wal-Mart still does for sure though and there's no way Wal-Mart is any more dev friendly then Apple. Way harder to get your product on the shelves at, harder to keep your product there, takes at least as large a cut, etc.
What Wal-Mart does have is tens of millions of customers though. Apple too. So of course devs are going to opt into those markets.
I doubt that Apple is solely concerned with profit and even if they were I guess I don't see that as the end of the world.
If Apple is solely concerned with profiting from apps why do they subsidize free ones and credit card fees? {If dev share is actually calculated post cc fees I'll plead ignorance and move on to the other part of the argument.}
99 cent app less 69 cents to developer less 40-70 cents to credit card company less bandwidth fees = loss.
(I've given a range on cc fees because they are shared if you purchase multiple apps within a few days, that mitigates the loss but ultimately someone motivated only by profit would be taking easily avoided losses all over the place in either scenario.)
Isn't it well known that Apple's direct profit on the App Store is a rounding error compared to their other business?
Isn't it then more likely then that their motivation is not primarily to directly profit from it?
While I do think Apple is interested in profit here, I very deliberately listed it as secondary to simplicity which is really at the heart of everything Apple does well. There's a book coming out soon about just this:
http://kensegall.com/blog/2012/02/and-now-a-different-kind-o...
The premise I'm building on is that Apple really profits by making great products that just work and make people happy. Having a super simple way to get apps is part of that.
For 98%+ of users 1 app store >> 2 app stores >> 10 app stores. One App Store just works. It also stops most malware without any action by the user. That's simplicity again.
"What I'm trying to express is my surprise that developers in the desktop world would opt in to a market like this"
I guess again I'll fall back on my Sears comparison. I don't know if Sears still sells software but they did for decades -- Wal-Mart still does for sure though and there's no way Wal-Mart is any more dev friendly then Apple. Way harder to get your product on the shelves at, harder to keep your product there, takes at least as large a cut, etc.
What Wal-Mart does have is tens of millions of customers though. Apple too. So of course devs are going to opt into those markets.
Very true. I didn't try to imply in any previous post that being motivated by profit is a bad thing. The app store definitely provides the ultra-simple software ecosystem you mentioned, and I agree that's awesome for most users. It also happens to guarantee that apple will be in the pipeline for all sales, so it's really win-win.
Despite my surprise that anybody would use it, there are over a thousand apps on the mac app store, so apple must be adding value by getting the product in front of eyeballs and streamlining the payment process. Still, I don't think they'll be able to get away with the draconian rule that they enjoy in the iDevice world. After all, if they make the experience too unpleasant, developers can still sell software through a competing app store, their website, or by mailing you a CD-ROM if all else fails. I think this is a good thing - the "escape hatch" means they'll actually have to put effort into pleasing the vendors who use their channel.
You'll never see a "why we decided to abandon the iPhone app store" - the only choice in that world is to abandon the platform altogether.
Despite my surprise that anybody would use it, there are over a thousand apps on the mac app store, so apple must be adding value by getting the product in front of eyeballs and streamlining the payment process. Still, I don't think they'll be able to get away with the draconian rule that they enjoy in the iDevice world. After all, if they make the experience too unpleasant, developers can still sell software through a competing app store, their website, or by mailing you a CD-ROM if all else fails. I think this is a good thing - the "escape hatch" means they'll actually have to put effort into pleasing the vendors who use their channel.
You'll never see a "why we decided to abandon the iPhone app store" - the only choice in that world is to abandon the platform altogether.
I like the idea of a sandbox. Apple promotes the sandbox as a security feature but shouldn't Apple try to improve much more important things (security wise) first which are much less invasive?
Example: The Keychain application from Apple (used to store certificates, private keys and passwords) is using a encryption algorithm that is too weak for what it is used - namely: DES. You can break it with a reasonable amount of money.
Wouldn't it make more sense to improve these kind of things first? We would gain so much more security with a minimal effort.
Example: The Keychain application from Apple (used to store certificates, private keys and passwords) is using a encryption algorithm that is too weak for what it is used - namely: DES. You can break it with a reasonable amount of money.
Wouldn't it make more sense to improve these kind of things first? We would gain so much more security with a minimal effort.
I could not believe they would use single DES (I would have expected AES), so I googled around. Apparently (http://stackoverflow.com/questions/6312871/what-encryption-a...; it is (or at some time was) 3DES; the PDF linked from there states:
"All the password data in the keychain is protected using the
Triple Digital Encryption Standard (3DES)."
"NIST considers keying option 1 to be appropriate through 2030."
> "The Keychain application ... using a encryption algorithm that is too weak for what it is used - namely: DES"
Source? This is relevant to my interests. Namely, I'm trying to figure out if using something like 1password or other services would be worth it. Thanks!
Source? This is relevant to my interests. Namely, I'm trying to figure out if using something like 1password or other services would be worth it. Thanks!
The problem is that allowing the holes he wants in sandboxing would defeat the security benefits. And that security is the whole point of the ordeal.
I don't know what the best solution is. Possibly allowing non-sandboxed apps in the app store, which go under extra review (possibly with a premium charge to defray the cost of extra review), or requiring the user to select a 'do not sandbox this' option when installing the app.
However, Apple can't give this app what it wants while keeping the integrity of their sandbox.
I don't know what the best solution is. Possibly allowing non-sandboxed apps in the app store, which go under extra review (possibly with a premium charge to defray the cost of extra review), or requiring the user to select a 'do not sandbox this' option when installing the app.
However, Apple can't give this app what it wants while keeping the integrity of their sandbox.
It is clear that Apple's current sandboxing is not perfect, but what could be done?
The goal is to create the most secure running environment that is possible. Allowing random apps to access/modify different files on the system (without user explicitly allowing that) kinda defeats the purpose of sandboxing (from user's point of view - from developers POV, sandboxing makes his app more secure and stable).
All I see is people ranting about sandboxing's limitations, without coming up with actual plans to improve it.
The goal is to create the most secure running environment that is possible. Allowing random apps to access/modify different files on the system (without user explicitly allowing that) kinda defeats the purpose of sandboxing (from user's point of view - from developers POV, sandboxing makes his app more secure and stable).
All I see is people ranting about sandboxing's limitations, without coming up with actual plans to improve it.
They're trying to take take take everything away from the user. Soon there will be no filesystem.
>Soon there will be no filesystem.
Is that a bad thing? I'm not saying it will happen soon, or that those of us long in the tooth will go easily, but I honestly think it's the future.
Think about young teenagers who will soon be "in charge". They snap a pic on their phone and send it to someone else. Nobody cares where it is in the filesystem, or even what the filename is. I used to meticulously name, tag and organize my mp3 collection into folders and sub-folders. Now I don't even know where they are on my hard drive - because I just don't care.
Those are old concepts we used to rely on to find and use information stored inside the computer, but I honestly don't see the need for the in the future. We can stop focusing on the "how" of the computer, and focus on the doing.
I will add that "power" users like developers will require these kind of concepts for a lot longer than your average Joe, but I still see it becoming less and less important.
Is that a bad thing? I'm not saying it will happen soon, or that those of us long in the tooth will go easily, but I honestly think it's the future.
Think about young teenagers who will soon be "in charge". They snap a pic on their phone and send it to someone else. Nobody cares where it is in the filesystem, or even what the filename is. I used to meticulously name, tag and organize my mp3 collection into folders and sub-folders. Now I don't even know where they are on my hard drive - because I just don't care.
Those are old concepts we used to rely on to find and use information stored inside the computer, but I honestly don't see the need for the in the future. We can stop focusing on the "how" of the computer, and focus on the doing.
I will add that "power" users like developers will require these kind of concepts for a lot longer than your average Joe, but I still see it becoming less and less important.
Reminds me of the GDrive story[1]. Basically, Google killed a Dropbox competitor project 4 years ago because "files are so 1990". Fast forward from where they thought the death of files was imminent and they're now preparing to launch Google Drive[2] again.
Files are more popular and profitable than ever. You have companies like Dropbox and Box.net making serious money. Yes, I can see that we may one day not need to expose the concept of filesystems to an end user but I think it will be a very very long time (like generations) unless there is some revolutionary new computing concept besides the ones we have today.
[1] http://googlesystem.blogspot.com.au/2011/05/how-google-docs-... [2] http://www.telegraph.co.uk/technology/google/9071936/Google-...
Files are more popular and profitable than ever. You have companies like Dropbox and Box.net making serious money. Yes, I can see that we may one day not need to expose the concept of filesystems to an end user but I think it will be a very very long time (like generations) unless there is some revolutionary new computing concept besides the ones we have today.
[1] http://googlesystem.blogspot.com.au/2011/05/how-google-docs-... [2] http://www.telegraph.co.uk/technology/google/9071936/Google-...
Once you are dealing with more than, say, two hundred pieces of information, you kind of start needing to classify that information and have definite ways to find it.
If tags are a way that you can definitely find and specify a given file, then tags will form part of a new, distributed file system. If tags wind-up just being half-assed, uncertain hints to where files might be, then they will form part of a new, disfunctional distributed file system. And the later case seems to be where things are going. This "hints but no certainty" approach to file location indeed works great most of the time and fails frustratingly significant percent of the time.
But even here, this is a file system even when it is often dysfunctional.
If tags are a way that you can definitely find and specify a given file, then tags will form part of a new, distributed file system. If tags wind-up just being half-assed, uncertain hints to where files might be, then they will form part of a new, disfunctional distributed file system. And the later case seems to be where things are going. This "hints but no certainty" approach to file location indeed works great most of the time and fails frustratingly significant percent of the time.
But even here, this is a file system even when it is often dysfunctional.
I think you missed my point.
I have thousands of photos "in" iPhoto, and I have no idea of any of the file names or their location on the file system.
I don't care what they are called or where they are, I just want to have my photos.
Sure, there might be a filesystem under there, but I have no interest in interacting with it directly.
I have thousands of photos "in" iPhoto, and I have no idea of any of the file names or their location on the file system.
I don't care what they are called or where they are, I just want to have my photos.
Sure, there might be a filesystem under there, but I have no interest in interacting with it directly.
"No you don't understand, these amplifiers go up to eleven..."
Even a flickin' unix whiz doesn't care about, say, which disk sector a file is located on. In fact, if they are using a distributed file system, they also can mostly ignore the physical location of the data.
Your spiffy net of tags is a way-to-find data. A officially "file system" is a way to find data. Each has some flexibility, some lack-of-ambiguity and some persistence over time. You may not care about the uniqueness, ambiguity and decay over time of your tag based way-to-find data. But that just means you've got a convenient but half-assed file system. Moreover,
Even a flickin' unix whiz doesn't care about, say, which disk sector a file is located on. In fact, if they are using a distributed file system, they also can mostly ignore the physical location of the data.
Your spiffy net of tags is a way-to-find data. A officially "file system" is a way to find data. Each has some flexibility, some lack-of-ambiguity and some persistence over time. You may not care about the uniqueness, ambiguity and decay over time of your tag based way-to-find data. But that just means you've got a convenient but half-assed file system. Moreover,
So... what about my scripts? Should I have to load some specific manager - iScript - in order to access my creations? Just because 'the filesystem is dying'? What about my store of .iso files? Do I need iIso?
Quit trying to get everyone off your lawn and accept that you are a (presumably) some kind of developer. Computers are not made just for your needs. The needs of the many outweigh the needs of the few or the one. In this case, you'll eventually have to be running some kind of developer tool to have this kind of access. This is probably appropriate. The average computer user (of any mainstream OS) has as much use for the ability to manage "scripts" and "ISOs" outside of a purpose-built application for using them, as he does for a C compiler.
File manager as a developer tool... The very idea makes me want to chase somebody off my lawn, but it does sound plausible. Every time I work with an application that insists on managing things on its own, I can't help but ask "but where _are_ the files??". I guess there is this notion that files are what's "real" in an otherwise ephemeral system. They are what you run, they are what you store your pictures in, they are what you recover from a busted harddrive.
Normal users seem to be very comfortable with the idea of unspecified magic though.
Normal users seem to be very comfortable with the idea of unspecified magic though.
Quit telling me what to do. Quit sucking down the Apple "There is only one way" philosophy. That there is constant complaints at Apple's UI decisions shows that even in UI, there is not 'only one way'. I much prefer the Linux way - "choose how you want to be" - give a reasonable default, which can be tailored.
To try and paint computer users as being in two camps 'normal' and 'developer' does everyone a disservice - there's much more variety in users than that. Here's an example - there's a lot of gamers that like side-editing save games, yet they're not developers. Where to they fit into your dichotomous view?
To try and paint computer users as being in two camps 'normal' and 'developer' does everyone a disservice - there's much more variety in users than that. Here's an example - there's a lot of gamers that like side-editing save games, yet they're not developers. Where to they fit into your dichotomous view?
I think people who need to manage files outside of a particular application will become the exception, not the rule. As long as you can access the underlying file system when you need to, I see no problem with most people not having to care about it.
How do you move photos from Alice's computer to Bob's computer? "Check out these"? With the concept of files, you can move photos/music/whatever in a number of ways - thumb drive, network shares, cloud. If you only work through 'photo manager' applications, how do you do it? What if the creators of the photo manager didn't want to support thumb drives? What if the way the photo managers on the different devices use different ways of referring to the photos?
I think 'regular' users have plenty of use for understanding the filesystem. I also think that it's okay to have some degree of expectation for the user - dumbing it down for the lowest common denominator is harmful (look at politics!). What do you really gain by alienating the power users?
I think 'regular' users have plenty of use for understanding the filesystem. I also think that it's okay to have some degree of expectation for the user - dumbing it down for the lowest common denominator is harmful (look at politics!). What do you really gain by alienating the power users?
You're still thinking of exceptional cases. Photo managing applications have, and will improve, native ways of sharing the photos, even if it's as simple as sending an email.
I see no reason why making the common case simple (not "dumb") means you have to eliminate, or even alienate, the power users. Frankly, since I started using a Mac, iTunes and an iPhone, I stopped managing music files. And I think that's great. Files are an implementation detail. What I want is music or radio programs, not files.
I see no reason why making the common case simple (not "dumb") means you have to eliminate, or even alienate, the power users. Frankly, since I started using a Mac, iTunes and an iPhone, I stopped managing music files. And I think that's great. Files are an implementation detail. What I want is music or radio programs, not files.
It's an error to simply transfer "it works for music" to "it works for everything". That it works for music is largely because sharing media files is verboten in our Brave New World - sharing is not a problem that needs to be solved there. But sharing non-media files between users is not an exceptional case, not even remotely - it's common as muck in business.
The idea that the 'normal' user is only a home-based casual web-browser/photo-taker/music listener is misleading from the outset.
The idea that the 'normal' user is only a home-based casual web-browser/photo-taker/music listener is misleading from the outset.
A hierarchy (i.e. a file system) is for many people the most natural way of classifying documents. There are other ways including tagging and search, and maybe those will become powerful and second nature, but right now classification like Linnaeus makes sense when you are dealing with lots of files.
I saw that iCloud file storage will support folders like the iPhone home screen, but I have no idea if they will support nested folders. This isn't only the case with nerds and geeks. My mother, about as computer phobic as they come, is a minister, and she saves all her sermons for future reuse. They are categorized by specific topic using folders. Also related documents from different applications can use folders to be organized together.
There are a lot of features of filesystems that we take for granted, abstracting it away without providing a usable alternative is problematic.
I saw that iCloud file storage will support folders like the iPhone home screen, but I have no idea if they will support nested folders. This isn't only the case with nerds and geeks. My mother, about as computer phobic as they come, is a minister, and she saves all her sermons for future reuse. They are categorized by specific topic using folders. Also related documents from different applications can use folders to be organized together.
There are a lot of features of filesystems that we take for granted, abstracting it away without providing a usable alternative is problematic.
Teenagers aren't going to go on making careers out of tagging photos and checking into places.
> Teenagers aren't going to go on making careers out of tagging photos and checking into places.
Do they currently go on to careers managing folder hierarchies?
Do they currently go on to careers managing folder hierarchies?
>Teenagers aren't going to go on making careers out of tagging photos and checking into places.
Some of those teenagers will go on to be CEO's and Execs at huge fortune 500 companies like Apple, Oracle, Microsoft, etc.
Some of those teenagers will go on to be CEO's and Execs at huge fortune 500 companies like Apple, Oracle, Microsoft, etc.
"Teenagers aren't going to go on making careers out of tagging photos and checking into places."
Exactly. No human will do this, computers will do for us in an automatic way, using search and programming.
We will ask the computer:
"Show me my 2004 photos in chronological order, and the computer will do."
What is the problem?
Exactly. No human will do this, computers will do for us in an automatic way, using search and programming.
We will ask the computer:
"Show me my 2004 photos in chronological order, and the computer will do."
What is the problem?
Your point? I don't get it.
> Is that a bad thing?
It is a very bad thing. I agree that it looks like this is where the industry is going, and I really, really, really dislike this direction.
Files are an incredibly useful abstraction. Sure, there are programs that work with photos and songs, but thee's a whole class of applications that works with "data" no matter what this data is. Think of stuff like backups, synchronization, compression, encryption, etc. If somebody comes up with a new encryption algorithm, filesystem lets me instantly use it for all my data regardless of which application I used to create it. But we're heading towards the world where we need one program to backup photos and another one to backup songs, and only OS manufacturers are allowed to create utilities that work with all my data in general. This is not good for innovation.
It is a very bad thing. I agree that it looks like this is where the industry is going, and I really, really, really dislike this direction.
Files are an incredibly useful abstraction. Sure, there are programs that work with photos and songs, but thee's a whole class of applications that works with "data" no matter what this data is. Think of stuff like backups, synchronization, compression, encryption, etc. If somebody comes up with a new encryption algorithm, filesystem lets me instantly use it for all my data regardless of which application I used to create it. But we're heading towards the world where we need one program to backup photos and another one to backup songs, and only OS manufacturers are allowed to create utilities that work with all my data in general. This is not good for innovation.
>Files are an incredibly useful abstraction
I agree with you. The "Files" abstraction has served us very well for more than 30 years. That's not justification to not attempt to find a better way.
I agree with you. The "Files" abstraction has served us very well for more than 30 years. That's not justification to not attempt to find a better way.
Next thing you know, there will be no keyboard, just a featureless ball. It would roll down from slippery slopes real well.
The MacBook Wheel: http://www.theonion.com/video/apple-introduces-revolutionary...
Hopefully it'll eventually become a computer with no screen or keyboard, just a big red button which turns the thing off. I'd buy that.
And version two would remove the button. Why would you want to turn it off?
Yes, and never mind that just about everything you take for granted about personal computers was "given" by Apple, too. I find this notion that users are entitled to complete device freedom really annoying.
If you find it so objectionable, go build your own hardware and OS platform. This isn't a matter of human rights because no one is telling you that you can't make your own.
If you find it so objectionable, go build your own hardware and OS platform. This isn't a matter of human rights because no one is telling you that you can't make your own.
Yes, and never mind that just about everything you take for granted about personal computers was "given" by Apple, too.
The RDF is on full effect there, I see. You might want to look at systems like the Xerox Alto & Star, both released before the Lisa. The implementation was certainly excellent - and I have a lot of respect for the Lisa and Macintosh engineers - but many of the concepts were invented elsewhere.
The RDF is on full effect there, I see. You might want to look at systems like the Xerox Alto & Star, both released before the Lisa. The implementation was certainly excellent - and I have a lot of respect for the Lisa and Macintosh engineers - but many of the concepts were invented elsewhere.
@cooldeal: Nope, I'm dead serious. There's no fundamental human right that entitles you to tell Apple (or any other device maker) what it can and can't sell you.
Of course there is, it's called Free Speech. There's no right that entitles you to force Apple to do what you want, but then again, nobody's arguing for it.
... you really object to users stating what they want to have?
So... Apple generally gets kudos for 'giving users what they want', but users are not allowed to say what they want?
Nice work.
So... Apple generally gets kudos for 'giving users what they want', but users are not allowed to say what they want?
Nice work.
@recoiledsnake: (for whatever reason, I'm not allowed to reply directly to you)
You're comparing Apple's ecosystem to Earth's.
Apple is a private company that makes products that are sold on the commercial markets. The Earth is something entirely different. If Apple made planets, then yes – they could decide how to manage the atmosphere. That's how business works.
You're comparing Apple's ecosystem to Earth's.
Apple is a private company that makes products that are sold on the commercial markets. The Earth is something entirely different. If Apple made planets, then yes – they could decide how to manage the atmosphere. That's how business works.
(for whatever reason, I'm not allowed to reply directly to you)
It's a cool-off period.
It's a cool-off period.
To keep me from advocating an unpopular, but entirely rational, position – all while other people freely misrepresent the First Amendment in response to my comments.
It's an algorithm, I'm pretty sure it has nothing against you.
And if you don't like pollution and global warming, stop complaining and trying to make things better, instead colonize your own planet and make them pollution-free.
Great sarcasm. :-)
I honestly can't get if that's sarcasm or the poster really believes such things. I think Poe's law applies here.
http://rationalwiki.org/wiki/Poes_Law
http://rationalwiki.org/wiki/Poes_Law
It's silly to pretend that Apple didn't pick and choose which capabilities they would support in the sandbox.
It's very similar to their support for "multitasking" on iOS. Handle the common cases well, most others will find some way to make it work, and the rest are out of luck.
It's very similar to their support for "multitasking" on iOS. Handle the common cases well, most others will find some way to make it work, and the rest are out of luck.
Typically the tradeoff with secureity is usability/features vs. security.
It's also important to note that the point of black hat hackers is to get around limitations. Without putting serious teeth into the sandboxing, it's largely pointless and security theater.
It's also important to note that the point of black hat hackers is to get around limitations. Without putting serious teeth into the sandboxing, it's largely pointless and security theater.
I hope Apple relaxes it's policy in regards to the sandbox. I do think it's great to have a sandbox provided by the OS, but IMO the default rule should be: "no access", then the developer could tick all legitimate uses for the application, if this happens to be unrestricted access, so be it. I think this is especially true with the new upcoming code signing feature in Mountain Lion.
I always got the feeling that once OSX became popular enough it would become an attractive attack target. Apple would have to start caring more about security. And the 'it just works' aspect of a lot of things they do would be reduced or eliminated.
I got a wrong certificate warning and a 403. Does anyone have a mirror?
Disable the HTTPS-Everywhere ruleset.
Oh, I don't even remember that I have that installed. Yeah, that was it.
I'm grateful for the iTunes App Store, but I have a bad feeling about the Mac App Store.
I think now might be the time for a rival App Store to set up shop before Apple locks developers into only releasing through their approval process.
Maybe I'm over reacting, but an ounce of prevention is worth a pound of cure.
I think now might be the time for a rival App Store to set up shop before Apple locks developers into only releasing through their approval process.
Maybe I'm over reacting, but an ounce of prevention is worth a pound of cure.
This is the first iteration of something I'm sure Apple will refine over the coming years. It's not surprising they haven't addressed the concerns of some applications, particularly power user and developer applications. Instituting a sandbox with user controlled permissions seems a solid step for usability and safety. For sure every feature will probably not ever be possible in a sandbox - for that we have regular installations which are not going away any time soon if ever. Apple is smartly trying to establish a trusted installation pattern for desktop applications resembling the experience on iOS, recent snafus notwithstanding.
So basically, it's notable that some applications are having difficulty with the first iteration of these new restrictions, but it's not surprising and I'm confident the issues will be resolved in time. Meanwhile, we've all survived without the App Store for a long time. I think these applications can survive. This is not the time for outrage.
So basically, it's notable that some applications are having difficulty with the first iteration of these new restrictions, but it's not surprising and I'm confident the issues will be resolved in time. Meanwhile, we've all survived without the App Store for a long time. I think these applications can survive. This is not the time for outrage.
Good points. I am concerned about this coming sandboxing. I don't use the Mac app store, but the sandboxing seems to be too restrictive, and I'd hate to see apps giving up functionality just to stay in the store. I think long-term Apple will get this sorted out, but it would be a shame for app functionality to regress in the meantime.
If Apple is not going to be distributing software updates because of their asinine policies, Apple should refund their 30% cut to their customers.
One thing to be wary of: abandoning the Mac App Store is going to make life much harder for you and your users in the near future. As of OS X 10.8, by default applications cannot be installed outside of the App Store (though a setting exists to change this):
http://techcrunch.com/2012/02/16/os-x-mountain-lion/ (scroll down to Gatekeeper)
Here's hoping that 10.9 doesn't disallow such installations at all (or void your warranty instead?).
http://techcrunch.com/2012/02/16/os-x-mountain-lion/ (scroll down to Gatekeeper)
Here's hoping that 10.9 doesn't disallow such installations at all (or void your warranty instead?).
Actually that's incorrect. You can't install completely unsigned applications from the web in 10.8 without changing a setting, but the default isn't the "Only MAS" option, it's the "MAS + identified developers" option.
So while you can abandon the App Store without penalty, you shouldn't stop paying Apple the $99 a year you need to do so to get the app signed, even if you aren't going to sandbox it or distribute it through the MAS. They just want the option of pulling a cert for a dev found to be distributing malware, not to personally review and reject every application that runs in OS X.
So while you can abandon the App Store without penalty, you shouldn't stop paying Apple the $99 a year you need to do so to get the app signed, even if you aren't going to sandbox it or distribute it through the MAS. They just want the option of pulling a cert for a dev found to be distributing malware, not to personally review and reject every application that runs in OS X.
That's not quite true - as shown in your link, gatekeeper's default (at least for now :) is to allow App Store as well as Signed Applications. If a developer is willing to get their application signed, then end users will still be able to install the application outside of the app store.
Now, say a game or web browser that runs potentially malicious content, sure, sandbox it. But other things like code interpreters, low level Unix tools, or inter process tools like AppleScript, they're still open to (mis)use by anyone.
I'm going to guess that most malware for OS X will soon become non-compiled scripts. Sure, the interpreter would be signed, but what it runs is totally arbitrary.