IOS 5's "Cleaning" Behavior(marco.org)
marco.org
IOS 5's "Cleaning" Behavior
http://www.marco.org/2011/10/13/ios5-caches-cleaning
206 comments
I entirely agree. Apple forgot an important use case? I hate it when software is built to think in place of the user. There are two culprits here:
* the lack of persistent, non backable offline storage * the addition of a auto-cleaning procedure
The auto-cleanup without a storage alternative is a blunder. iOS 5 decides for the user what should be deleted to free up space. An alternative would be to prompt what application data you would like to remove instead of a blind decision. Otherwise, that's the kind of programming that will one day lead robots to cleanup the human race! ;)
Of course, having permanent local storage that's not backed up would be a more user-friendly solution. However, it would probably lead people to run out of space when developers begin abusing it like some did with temp or cache storage.
It seems like a trend at Apple these days. With Lion, the OS now decides when an application should quit when unused.
* the lack of persistent, non backable offline storage * the addition of a auto-cleaning procedure
The auto-cleanup without a storage alternative is a blunder. iOS 5 decides for the user what should be deleted to free up space. An alternative would be to prompt what application data you would like to remove instead of a blind decision. Otherwise, that's the kind of programming that will one day lead robots to cleanup the human race! ;)
Of course, having permanent local storage that's not backed up would be a more user-friendly solution. However, it would probably lead people to run out of space when developers begin abusing it like some did with temp or cache storage.
It seems like a trend at Apple these days. With Lion, the OS now decides when an application should quit when unused.
I write several offline mapping apps, and this is totally throwing us for a loop. We're recommending our power users not upgrade to iOS 5. Users download gigabytes of maps to their cache directory, they don't want to eat their iCloud allotment with that, or their slow their iTunes sync. But they also don't want to have to download those maps again, or find themselves in the middle of the woods without the maps they downloaded.
Instead of just saying "don't install iOS5", can't you continue to store files in their Documents, but tell them to flip off the sync switch for your app? http://i.imgur.com/acOje.png
We could, but it would involve pushing an update to the app. The 'don't install' is a stopgap for people who may be counting on using their maps this weekend. Additionally, people collect geo information with our app, tracks and waypoints that they like to backup.
> Additionally, people collect geo information with our app, tracks and waypoints that they like to backup.
That could still be persisted separately if you stuff all that into iCloud's KV store instead of relying on file backup. (Just trying to brainstorm technical solutions; not suggesting they're at all optimal.)
That could still be persisted separately if you stuff all that into iCloud's KV store instead of relying on file backup. (Just trying to brainstorm technical solutions; not suggesting they're at all optimal.)
The cleaning issue isn't something that just popped up with the GM build. It existed before then in some of the later betas. As a developer it's verging on the lazy to wait for the GM before you update an app for an issue that you've known about for month(s). As a developer, it's your responsibility to update your app to work with as little inconvenience to your users.
That's what I thought, but see marchdown's comment later on this page -- he says: "Apple prohibits developers to store stuff that can be regenerated or re-downloaded. So, arguably, you can't just switch to using Documents for downloadable data." If that's true, it would prevent such a simple solution.
Good to know there is a per-app toggle switch for this.
Some of us make multi-MB files in the documents folder that weren't designed to be granular for backing up or syncing.
I guess I will have to write a blog post for us too.
I wonder if there is any chance that Apple will change how this works - it seems like this should be doomsday for a large swath of apps.
(married to Smokey and partner on all these apps!)
I wonder if there is any chance that Apple will change how this works - it seems like this should be doomsday for a large swath of apps.
(married to Smokey and partner on all these apps!)
The bigger question is why wasn't this considered DURING the iOS5 beta? If it got brought to Apple's attention during the beta cycles and they decided to not fix it then they'll most likely won't fix it now either (although it seems like they really don't have much choice here but to provide a solution one way or another)
All the developers in the beta are under NDA, so they can't write attention-getting blog posts that might actually influence Apple to do something.
Fair point, but attention-grabbing blog posts are not the only way to get your voice heard as a developer. There's a difference between 'feedback' and 'creating public pressure'.
But I hear ya...
Put it in Library/ (but not Library/Caches/). That's exactly the behavior you're looking for, I believe.
See Marco's post. Apple has made it clear that anything outside of Library/Caches/, tmp/, or the app bundle will be backed up to iCloud. I have personally witnessed this with Documents/ (as expected) and even Library/Application Support/ (which I hoped would be safe, but is not).
There is no current safe place to save local data that should not be backed up to iCloud.
There is no current safe place to save local data that should not be backed up to iCloud.
If there were both "on the phone and backed up in iCloud" and of "stored only on the phone" kinds of data, either your app would decide for you whether your data is worth backing up, or it would let you decide. Apple finds both options unacceptable.
The mental model for iOS is that it stores only two kinds of data: discardable because it can be reproduced, and backed up because it cannot.
That ensures that all your data always is safe. You do not have to worry about losing data when your phone breaks down, or about forgetting to move some data when you upgrade.
I think this also is the reason iOS devices do not have memory card slots. It complicates data management; Apple does not think that is worth the extra complexity.
The mental model for iOS is that it stores only two kinds of data: discardable because it can be reproduced, and backed up because it cannot.
That ensures that all your data always is safe. You do not have to worry about losing data when your phone breaks down, or about forgetting to move some data when you upgrade.
I think this also is the reason iOS devices do not have memory card slots. It complicates data management; Apple does not think that is worth the extra complexity.
Unfortunately, that doesn't work:
https://twitter.com/marcoarment/status/124583089417617408
https://twitter.com/marcoarment/status/124583089417617408
According to Marco's post (what this is a thread in response to), that is also backed up to iCloud and iTunes. Only Library/Caches/ and tmp/ are not.
My app is heavily effected as well. I have a Picasa client that auto-caches photos for users. The app manages the cache and clears it when needed, but certain albums can be manually set to cache by users so they're never deleted. I wouldn't want all these photos backed up and I don't think apple would allow it. Them going through and deleting the data themselves basically breaks the app for our users though.
The app: webalbumsapp.com
The app: webalbumsapp.com
Is this correct: http://news.ycombinator.com/item?id=3111234 ? Add .nosync to the file/foldername in Documents and it's not synced?
It doesn't seem to work for me. I moved our large data files from the library cache directory to a data.nosync directory in the documents directory. The data in the nosync folder is being backed up to iCloud.
Isn't this what innovation is about? Finding ways of solving problems? Is forcing apps to make more efficient of their use of space such a bad thing?
From what I see, your users have 3 choices: They can use your app and use up their iCloud allotment, they can use your app and not upgrade, or they can upgrade and find a mapping app that is more efficient in its use of space.
From what I see, your users have 3 choices: They can use your app and use up their iCloud allotment, they can use your app and not upgrade, or they can upgrade and find a mapping app that is more efficient in its use of space.
Or Apple can provide a persistent store that isn't uploaded into the iCloud.
I think this crosses the line regarding how much control Apple has over the device for which I paid!!!
This argument is way over used. It is 'your' choice to upgrade to iOS5.
It isn't like Chrome where there are rolling updates that just get applied. You actually have to sit at your computer for a while, download the software and than install it. Many chances to turn back.
It isn't like Chrome where there are rolling updates that just get applied. You actually have to sit at your computer for a while, download the software and than install it. Many chances to turn back.
Lame argument. Microsoft offers you a "choice" of installing updates as well. What if they started deleting files put by other legitimate apps because it is slowing your computer or changing your wallpaper because its too ugly... where is the line???
Apple - iCloud - Your content. On all your devices.
That is the title of Apple's main iCloud page at http://www.apple.com/icloud/.
iCloud is seamlessly integrated into your apps, so you can access your content on all your devices.
This is Apple's definition for the iCloud service. It doesn't matter what the data is, it's your data and Apple is promising to sync it between your devices, to preserve your experience.
In the case of Instapaper, the solution is obvious: Put the files in Documents. That is Instapaper's content and part of the experience that users want synced between devices.
If Apple penalizes developers and undermines the promise it is making to users because it decides to be miserly about bandwidth, then it has to admit it launched iCloud before it was ready.
That is the title of Apple's main iCloud page at http://www.apple.com/icloud/.
iCloud is seamlessly integrated into your apps, so you can access your content on all your devices.
This is Apple's definition for the iCloud service. It doesn't matter what the data is, it's your data and Apple is promising to sync it between your devices, to preserve your experience.
In the case of Instapaper, the solution is obvious: Put the files in Documents. That is Instapaper's content and part of the experience that users want synced between devices.
If Apple penalizes developers and undermines the promise it is making to users because it decides to be miserly about bandwidth, then it has to admit it launched iCloud before it was ready.
But it's not clear that Instapaper is allowed to put the files in Documents. According to the Data Storage Guidelines cited in the article:
1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the <Application_Home>/Documents directory and will be automatically backed up by iCloud.
2. Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
I don't know if this is something enforced in the approval process, but it seems like Apple's intention is for redownloadable content to all be stored in temporary, wipeable locations.
1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the <Application_Home>/Documents directory and will be automatically backed up by iCloud.
2. Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
I don't know if this is something enforced in the approval process, but it seems like Apple's intention is for redownloadable content to all be stored in temporary, wipeable locations.
Still, when user saves a webpage to Instapaper he/she probably wants to see it as it was when it was saved, and not magically updating itself afterwards. So I think that 'exactly this article at exactly this point in time' should qualify as 'content that cannot be recreated'.
[deleted]
"If Apple penalizes developers and undermines the promise it is making to users because it decides to be miserly about bandwidth, then it has to admit it launched iCloud before it was ready."
That's the key right there. The size of the Instapaper database is determined by the user. It will only fill up a user's iCloud space if they decide to save a lot of documents. Plus, they always have the option to buy additional space!
Aside from making sure the documents are reasonably compressed, the size of the Instapaper database should not be Marco's concern.
That's the key right there. The size of the Instapaper database is determined by the user. It will only fill up a user's iCloud space if they decide to save a lot of documents. Plus, they always have the option to buy additional space!
Aside from making sure the documents are reasonably compressed, the size of the Instapaper database should not be Marco's concern.
Their marketing is definitely hyperbolic. Even in terms of Apple's own services. The supposed data syncing in iWork actually doesn't work on the Mac versions. It only works between iOS devices. So if I edit a paper on my Mac, and I want to use it on my iPad, I still have to go through an annoying uploading/downloading phase. There's nothing seamless about it.
If you go to the bottom of http://www.apple.com/icloud/features/documents.html you can see the web interface you have to use.
I know this is a tangent to the OP but I was very annoyed to discover this last night, I feel like Apple was pretty misleading here. There are clearly technical difficulties that still need to be surmounted.
If you go to the bottom of http://www.apple.com/icloud/features/documents.html you can see the web interface you have to use.
I know this is a tangent to the OP but I was very annoyed to discover this last night, I feel like Apple was pretty misleading here. There are clearly technical difficulties that still need to be surmounted.
Add .nosync to the file/folder name path and keep it in the home or documents directory. Problem solved.
edit: I'm shocked this thread is so long and no body mentioned this. It's been on the apple developer forums for months as a solution.
edit: I'm shocked this thread is so long and no body mentioned this. It's been on the apple developer forums for months as a solution.
I haven't had a chance to verify this myself, but according to Marco, this does not actually avoid the iCloud sync:
https://twitter.com/#!/marcoarment/status/124587437799374848
https://twitter.com/#!/marcoarment/status/124587437799374848
It actually does. I know because I've been testing with our app. It works perfectly. We build up a fairly large 25MB sqlite db and it doesn't show in iCloud anywhere.
In fact, if you use UIManagedDocument, it creates a .nosync directory in the document bundle to prevent it from syncing in the framework itself.
In fact, if you use UIManagedDocument, it creates a .nosync directory in the document bundle to prevent it from syncing in the framework itself.
The docs specifically say directory, not file. Maybe that is the problem?
Well that could use better publicity. Do you have a citation?
Has anyone used this successfully?
Has anyone used this successfully?
Do you have any documentation about this? I see a few scant references in the developer forum and nothing in the docs.
I moved our large data files from the library cache directory to a data.nosync directory in the documents directory. The data in the nosync folder is being backed up to iCloud.
From what I can tell the use case for .nosync there is to store a large dataset in a SQLite store in such a way that individual transactions are replicated to iCloud but the entire SQLite store itself is not transferred each time something changes.
The documentation seems to imply that .nosync will prevent the whole store from being uploaded, but (1) that does not seem consistent with what others are reporting, and (2) I cannot find any other supporting information on .nosync in either Apple documentation or dev forums - that doc and this thread are literally the only places I've seen it referenced.
The other underlying issue is whether Apple would be cool with storing persistent application data in Documents provided that it is not synced to iCloud. The use case that Marco and others have described does not really match what's described in that document.
edit: Marcos -> Marco
The documentation seems to imply that .nosync will prevent the whole store from being uploaded, but (1) that does not seem consistent with what others are reporting, and (2) I cannot find any other supporting information on .nosync in either Apple documentation or dev forums - that doc and this thread are literally the only places I've seen it referenced.
The other underlying issue is whether Apple would be cool with storing persistent application data in Documents provided that it is not synced to iCloud. The use case that Marco and others have described does not really match what's described in that document.
edit: Marcos -> Marco
Can also store in the apps home directory (which is right above the apps Documents directory).
They spoke about .nosync at this year's WWDC a few times. Dev forums are a little nuts since they opened the iOS Beta 5 forums to all the non NDA members.
They spoke about .nosync at this year's WWDC a few times. Dev forums are a little nuts since they opened the iOS Beta 5 forums to all the non NDA members.
Watch the WWDC videos on Core Data.
There are a number of possible scenarios for file storage, the problem is a lack of clarity or documentation about the properties of the various locations as they stand now. As a developer, I could imagine desiring the following choices:
1. Temp: No backup, cleared regularly
2. Cache: No backup, cleared when space is tight
3. Local: Local backup only, never cleared
4. Documents: Local/cloud backup, never cleared
5. Cloud: Cloud backup, cleared when space is tight
The problem seems to be that #3 doesn't exist. Yet you'd think it would be a common requirement for stuff like in-app purchases of large and essential content packs, for example, turn-by-turn navigation maps.
I'd hate to be on holiday and have a 10 megabyte podcast download automatically trigger the erasure of 1000 megabytes of navigation data.
1. Temp: No backup, cleared regularly
2. Cache: No backup, cleared when space is tight
3. Local: Local backup only, never cleared
4. Documents: Local/cloud backup, never cleared
5. Cloud: Cloud backup, cleared when space is tight
The problem seems to be that #3 doesn't exist. Yet you'd think it would be a common requirement for stuff like in-app purchases of large and essential content packs, for example, turn-by-turn navigation maps.
I'd hate to be on holiday and have a 10 megabyte podcast download automatically trigger the erasure of 1000 megabytes of navigation data.
You are missing "No backup, never cleared" which is what the old "2. Cache" scenario used to be.
I disagree. If it's not worth backing up (locally), it doesn't deserve protected status on the phone.
Or to put it another way, if it's important enough to retain when storage space is low, it's important enough to retain for when you have to recover from a backup.
Or to put it another way, if it's important enough to retain when storage space is low, it's important enough to retain for when you have to recover from a backup.
Interesting, I appear to have been voted down for a calm and considered opinion.
You left out the case of storing data for offline use, which is one of the key use of Instapaper, offline maps, cached notebooks, etc.
If I stored something specifically for offline use, I want it to be available as long as my device is with me, even when I'm offline. (1) Some of it is important as you say, and they should be backed-up, but (2) some are important, but is capable of being downloaded again and shouldn't be backed up and shouldn't'. The latter is the one that is now automatically cleaned up.
If I stored something specifically for offline use, I want it to be available as long as my device is with me, even when I'm offline. (1) Some of it is important as you say, and they should be backed-up, but (2) some are important, but is capable of being downloaded again and shouldn't be backed up and shouldn't'. The latter is the one that is now automatically cleaned up.
I think that is a decision best left to the developer or user. Take an app that syncs your photos from a site you may already use, like Picasa, Flickr or SmugMug. You want to have these available on your iPad or iPhone instantly, even when you are without internet service. But you don't need them backed up to your computer every time you sync, causing the backup times to skyrocket, and if you lose them on a restore, it's a minor inconvenience, but not a huge deal. Losing them unexpectedly when you don't have the time or ability to re-downlaod them is a much more major problem for some people.
The first time that one of my several hundred megabyte foreign language dictionary files isn't available and needs to be re-downloaded when I need it in say, a meeting will trigger a severe re-evaluation of my use of the phone.
I just emailed the company that makes the dictionary app in question (pleco chinese dictionary, if anyone cares) and they confirmed this issue will affect them.
The ball is in Apple's court.
The ball is in Apple's court.
I'm definitely at risk of running into this predicament as a user. I'm more worried about the hundreds of megabytes of podcasts I download when WiFi is available for use throughout the day when WiFi isn't available.
To avoid this issue and enjoy the benefits of iOS 5, I'm going to have to clear out a bunch of apps, music, and photos and ensure that I always have a sufficient amount of "buffer" space so the cleaning is never triggered. I cannot be alone in this, and the fact that Apple is making this kind of thinking necessary for end users is kind of ridiculous. I really can't see this behavior lasting for very long, and I'm sure Apple will address it soon; this is the antithesis to the traditional iPhone experience. The only scenario where I could see this being purposeful is if Apple is really trying to hurt offline apps to increase data usage and appease carriers (maybe for pissing them off with iMessage?).
To avoid this issue and enjoy the benefits of iOS 5, I'm going to have to clear out a bunch of apps, music, and photos and ensure that I always have a sufficient amount of "buffer" space so the cleaning is never triggered. I cannot be alone in this, and the fact that Apple is making this kind of thinking necessary for end users is kind of ridiculous. I really can't see this behavior lasting for very long, and I'm sure Apple will address it soon; this is the antithesis to the traditional iPhone experience. The only scenario where I could see this being purposeful is if Apple is really trying to hurt offline apps to increase data usage and appease carriers (maybe for pissing them off with iMessage?).
I would wait until more reports come in.
Alternatively, just turn off iCloud back ups.
Alternatively, just turn off iCloud back ups.
Yeah, glad I read this before upgrading. My large collection of podcasts stored in Instacast will probably be lost straight away.
It seems fair to say that Instapaper's version of an article can't be "redownloaded" for various reasons (offline, paywall, article removed, etc.) so it would be OK to put it in the Documents folder.
The argument against that is that you're now syncing that article with iCloud in addition to Instapaper.
But I wonder whether the correct answer is instead to eliminate Instapaper's sync feature, and just let iCloud do it. Once you have system-level cloud sync, don't you want to let Apple do the work? Sync is hard, and it isn't really the core value of Instapaper.
Edit: I was wondering about iCloud only for iOS 5/MacOS 10.7.2 devices with iCloud accounts. But that story does fall apart for people with mixed devices. So never mind.
The argument against that is that you're now syncing that article with iCloud in addition to Instapaper.
But I wonder whether the correct answer is instead to eliminate Instapaper's sync feature, and just let iCloud do it. Once you have system-level cloud sync, don't you want to let Apple do the work? Sync is hard, and it isn't really the core value of Instapaper.
Edit: I was wondering about iCloud only for iOS 5/MacOS 10.7.2 devices with iCloud accounts. But that story does fall apart for people with mixed devices. So never mind.
I see it being a long while before everyone has iCloud up and running. We installed it last night on a relatively new MBP, to learn it doesn't work without Lion, so now we are upgrading to Lion. It will only work on certain phones, I believe 3GS and above.
Maybe Apple will release iCloud for Snow Leopard, but as it is now, instapaper works all the way down to the terrible version 2 iPhone I have had to resort to using in order to not sign into a new contract waiting on the release of the 4s.
Instapaper would hurt too many current users who are just fine with how things work without the cloud.
Maybe Apple will release iCloud for Snow Leopard, but as it is now, instapaper works all the way down to the terrible version 2 iPhone I have had to resort to using in order to not sign into a new contract waiting on the release of the 4s.
Instapaper would hurt too many current users who are just fine with how things work without the cloud.
Instapaper is more than just an iOS application, so no, iCloud is not the answer for syncing.
Isn't NSApplicationSupportDirectory for stuff that isn't "Documents" and yet needs to be managed as app state (not in 'Caches')? Why not just use that instead? That's what my app does and it seems to be OK with iOS 5.
I do the same thing. Apple is unclear about this, however. ApplicationSupport is at /Library/Application Support, and /Library definitely does get backed up to iTunes.
http://developer.apple.com/library/ios/#DOCUMENTATION/FileMa...
That said, I think we're in the clear with respect to iCloud backups:
"Devices with an active iCloud account have their app data backed up to iCloud at appropriate times. And for devices that are plugged into a computer, iTunes performs an incremental backup of the app’s data files."
It's ambiguous. But "app data" sounds like documents, whereas "app's data files" sounds like big data files in /Library to me.
http://developer.apple.com/library/ios/#DOCUMENTATION/FileMa...
That said, I think we're in the clear with respect to iCloud backups:
"Devices with an active iCloud account have their app data backed up to iCloud at appropriate times. And for devices that are plugged into a computer, iTunes performs an incremental backup of the app’s data files."
It's ambiguous. But "app data" sounds like documents, whereas "app's data files" sounds like big data files in /Library to me.
Well, according to the documentation that folder is backed up to iTunes as well. Actually, it seems, the only folder that skips backups to iTunes in the Library folder is the Caches folder.
The relevant part of the documentation is here: http://developer.apple.com/library/mac/#documentation/FileMa...
The relevant part of the documentation is here: http://developer.apple.com/library/mac/#documentation/FileMa...
I develop Definition (http://definitionapp.com) and I store the database in the Caches directory as well, after receiving the email from Apple to move. This is bad news for me, the entire offline dictionary could be wiped out.
Maybe the solution is to make it a choice for the user? An option to "clean up documents when space is low on the device" in the instapaper options. If checked, stuff gets stored in cache. If not, in documents.
That way, the default behavior is that "download something = want to keep it on device", but users can do the other one too if they want. I don't think the option is particularly useful, but it might make the app reviewer happy?
That way, the default behavior is that "download something = want to keep it on device", but users can do the other one too if they want. I don't think the option is particularly useful, but it might make the app reviewer happy?
I would bet Apple's never going to make this sort of a choice obvious to the user -- it goes against the "just working" (whether or not it works the way you want) they're currently pushing. It sure does worry me to read all these comments though; it seems like you'll never be able to count on an app having the data it needs to run, without re-downloading. As somebody who spends half his day in an airplane or a subway, plus plenty of time in expensive places (like overseas), that's terrifying.
Actually a couple video players right now do make this choice available to the user - OPlayer and AVPlayer. They both say something to the effect of "Backup media" in their settings. This simply toggles which location the media is stored in (AVPlayer even seems to move the media on the fly).
This is literally exactly how I would implement the choice if I were Marco.
This is literally exactly how I would implement the choice if I were Marco.
The problem is if the user chooses not to backup the data, it'll get wiped if she runs out of storage space. What would be nice would be to not sync to iCloud AND not get cleaned out.
This is what needs to happen. Either there needs to be a user confirmation before information can be "cleaned" from an app, or there needs to be a setting in the Settings/Appname for disallowing cleaning of that app's data.
[Edit] Upon further examination of the new Settings/iCloud in iOS 5, what will need to happen is that the user should be able to disable iCloud syncing for individual 3rd party apps. That's the most consistent solution for the current interface. [/Edit]
[Edit] Upon further examination of the new Settings/iCloud in iOS 5, what will need to happen is that the user should be able to disable iCloud syncing for individual 3rd party apps. That's the most consistent solution for the current interface. [/Edit]
I think the problem is that Marco sees Instapaper users as his customers. I sympathize with this, but I think iOS is an assertion by Apple that App Store customers are Apple customers. App Store Developers are providing a service to Apple's customers. But everything that happens must point back to Apple's servers, not their own.
In the same way Apple doesn't want every developer operating their own independent payment system, they also don't want developers operating their own cloud storage services. If Apple holds the data they can guarantee its security. They likely see these problems as temporary, until developers and customers learn to adjust to the fact that iOS data is controlled by the iCloud service.
In the same way Apple doesn't want every developer operating their own independent payment system, they also don't want developers operating their own cloud storage services. If Apple holds the data they can guarantee its security. They likely see these problems as temporary, until developers and customers learn to adjust to the fact that iOS data is controlled by the iCloud service.
It sounds like what Marco is looking for is something equivalent to Windows's AppData\Local, machine local, doesn't get nuked, but doesn't sync over roaming profiles either
manage it yourself: put things that need to be persistent in Documents. put the rest in Cache. move 'em as needed. do it automatically by download and access dates and/or provide an interface for people to manage it.
your app absolutely needs tons and tons of data to function? doesn't seem like your day. it's their device, their cloud, their decision. Apple doesn't give a shit about your day; they're going cloud. they may be wrong, but i'd guess they're going to have to find that out for themselves.
i'd assume they acknowledge this may kill some apps. i don't think they ever promised anyone a business; on the contrary, they seem to remind developers that they are there at their good grace all the time. as someone that built Facebook apps since '07, trust me, i know what this is like. start coding and start calling. best of luck.
your app absolutely needs tons and tons of data to function? doesn't seem like your day. it's their device, their cloud, their decision. Apple doesn't give a shit about your day; they're going cloud. they may be wrong, but i'd guess they're going to have to find that out for themselves.
i'd assume they acknowledge this may kill some apps. i don't think they ever promised anyone a business; on the contrary, they seem to remind developers that they are there at their good grace all the time. as someone that built Facebook apps since '07, trust me, i know what this is like. start coding and start calling. best of luck.
DHH declared the solution in 2007 [1] - apparently nobody needs offline applications!
[1] http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl...
[1] http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl...
I'm very rarely on a plane. However I take the subway every day, and I'm extremely thankful that Tweetbot, Reeder and Newsstand cache everything so that I have something to read. I also don't consider the subway a niche or isolated pocket.
I just don't buy the lame justification about not always being connected. If you don't want to be connected, turn off your damn phone. Don't insist that everyone else shouldn't be able to enjoy their time the way they want to because you associate your mobile device with stress.
I just don't buy the lame justification about not always being connected. If you don't want to be connected, turn off your damn phone. Don't insist that everyone else shouldn't be able to enjoy their time the way they want to because you associate your mobile device with stress.
I must be missing something. What is the problem with backing up pages stored in InstaPaper to iCloud? That's exactly the behavior I would want if I were using InstaPaper.
1. The user can re-download from Instapaper's servers.
2. It goes against the spirit of Apple's policy here, which is not to backup to iCloud what ca be re-downloaded (see 1)
3. The user might have lots of content stored and again due to 1, those don't need to be backed up to iCloud. And really Instapaper actually has a small version of the problem. What is critical is applications that has huge amounts of data like offline maps and wikipedia. Those can be re-downloaded from their servers yet most definitely should not be backed up to iCloud due to time and cost.
2. It goes against the spirit of Apple's policy here, which is not to backup to iCloud what ca be re-downloaded (see 1)
3. The user might have lots of content stored and again due to 1, those don't need to be backed up to iCloud. And really Instapaper actually has a small version of the problem. What is critical is applications that has huge amounts of data like offline maps and wikipedia. Those can be re-downloaded from their servers yet most definitely should not be backed up to iCloud due to time and cost.
That's pretty interesting. So, the three non-backed locations are tmp, Caches and the Application Bundle. tmp and Caches are now swept. So, if you store your real cache stuff in the Application Bundle, it won't be backed up or auto-deleted. But maybe it gets trashed when you update the app.
I wonder if OS X, in line with its trend to be more like iOS, is going to start automatically clearing the ~/Library/Caches directory as well.
I wonder if OS X, in line with its trend to be more like iOS, is going to start automatically clearing the ~/Library/Caches directory as well.
Unfortunately you can't write data to your application bundle. That folder is read-only.
The application bundle is signed. Writing to that location should be blocked by the sandbox.
There needs to be a file storage location that behaves the way Caches did before iOS 5
I'm confused. If the goal is for documents to be available in the near future in offline form, why not keep documents in /Documents until the user has read them (or some sane amount of time has passed), and then move them to /Caches or some temporary storage?
I've never used Instapaper, so perhaps documents are only stored until read anyway?
I'm confused. If the goal is for documents to be available in the near future in offline form, why not keep documents in /Documents until the user has read them (or some sane amount of time has passed), and then move them to /Caches or some temporary storage?
I've never used Instapaper, so perhaps documents are only stored until read anyway?
This is also particularly problematic for my own apps, which are offline photo browsers that sync your collection of photos. Keeping GBs of data in the Caches folder was the only way to have iPhone backups occur reasonably fast. Sure, they can be re-synced, but that will be a very time-consuming process for thousands of photos.
So, people (developers) are going to have to put their stuff in Documents, and instruct users to disable the iCloud sync for their particular app, unless the user really wants to have it eat into their iCloud storage.
Would that work?
Would that work?
What about offline web apps which are saved onto the home screen? Are they also "cleaned"? If we can't depend upon an offline web app to be there when offline then that would fundamentally defeat the purpose.
Of course, one could argue that the cleaning behaviour fundamentally defeats the purpose of a lot of apps, as already covered above (Instapaper, Offline Maps, etc.).
My iMac is packed up for building work, so I can't upgrade my iPad and check this out for myself. Sorry.
Of course, one could argue that the cleaning behaviour fundamentally defeats the purpose of a lot of apps, as already covered above (Instapaper, Offline Maps, etc.).
My iMac is packed up for building work, so I can't upgrade my iPad and check this out for myself. Sorry.
"Prior to iOS 5, the system never deleted the contents of Caches and tmp, so they were safe places for apps to put data that should always be available"
Not exactly.
Not exactly.
He says he knew about this behavior, and he also explicitly said (on Twitter, can't be bothered looking for it) that he was not going to report bugs to Apple during the beta.
I guess Marco just prefers venting after the fact.
I guess Marco just prefers venting after the fact.
Maybe if you are going to slag someone off you should be bothered looking for the tweet you base your slander on...
Fair enough. I tried now but that was months ago and Twitter search is unhelpful.
However, he's being asked by multiple people right now for the radar# and he's ignoring the questions. He just said he's known it for two weeks, which might have been too late for Apple to fix it anyway.
However, he's being asked by multiple people right now for the radar# and he's ignoring the questions. He just said he's known it for two weeks, which might have been too late for Apple to fix it anyway.
Yeah, one thing I don't understand is Marco had access to dev builds of iOS for months and iCloud dev access I presume. Why he only found about it now instead of doing something about it all this time?
Probably because, like most developers, he has separate development devices that he only uses for development. So he probably never ran into storage constraint limits while just testing Instapaper.
As an example, I have a 32GB iPod Touch that I've been using for all of the iOS5 testing for my applications and I'm only using around 600MB total. I'd never run into this issue either unless I loaded this up with tons of other apps and movies and music.
As an example, I have a 32GB iPod Touch that I've been using for all of the iOS5 testing for my applications and I'm only using around 600MB total. I'd never run into this issue either unless I loaded this up with tons of other apps and movies and music.
That's incorrect, he stated on his podcast that he's used iOS5 on his main device since WWDC.
Whether he hits the limit regularly or not is another question...
Whether he hits the limit regularly or not is another question...
I dont get it.. he get furios because he saves files he needs in a folder called /cache , and /cache gets purged when the system runs low on space.... What did you think cache meant?
Why dont you just update your app?
Why dont you just update your app?
I wouldn't say that the articles' metadata (URL, title, date of download, maybe thumbnail of the 1st page) is downloaded content. It's clearly user-generated, and should be in the "home" of the app IMHO.
The articles themselves, yes, send them to the cache. If the user needs to reclaim the storage used up by the articles, let the OS delete them. Then, when the user needs to read the article again, it will take some time to download. But don't get into an "all articles gone" situation. Just my 2 cents.
The articles themselves, yes, send them to the cache. If the user needs to reclaim the storage used up by the articles, let the OS delete them. Then, when the user needs to read the article again, it will take some time to download. But don't get into an "all articles gone" situation. Just my 2 cents.
I'd submit that this is, in some ways, worse: instead of all articles being gone they're now all grayed out, so the user knows they were here, can still see there, but if he's offline he can not access them because only the metadata is left, the data itself is gone.
What problem are you trying to fix? If I'm offline, what good is being able to see my article list if I can't read the articles? If I'm online, why do I feel any less irritated when I try to go back to an article I was just reading only to find that I need to wait for it to download again?
The problem fixed is that the user has an indication as to what happened to all of their saved articles. That's a very big difference. It's not a full solution, as the parent noted, but the UX is far superior.
I thought Instapaper scraped the page and stored that, to accommodate sites that require login for access. So not trivial to just re-download the articles. Plus the whole point is to have them available when you're offline.
I'd say in this case, the content is user-generated and should be backed up.
I'd say in this case, the content is user-generated and should be backed up.
That's a tough line to argue: the scraped page is actually stored by Instapaper (otherwise you could not access it from the website), so you re-download it from there, and technically it's not user-generated it's at best user-curated.
But this does indeed defeat the point of having it offline, which is a significant part of IP's purpose.
But this does indeed defeat the point of having it offline, which is a significant part of IP's purpose.
[deleted]
Has anyone figured out where the high water mark is? When will the cleaning behavior kick in?
This is an interesting twist especially with the 16GB devices which tend to actually be above 50%.
This is an interesting twist especially with the 16GB devices which tend to actually be above 50%.
[deleted]
Clearly, apps that cache data need to be modified to show the difference between having no data and having no data cached. IMAP clients have dealt with this, for example; they show a message like "the contents of this folder are not available offline".
Perhaps Apple could have made cache cleaning opt-in on a per-app basis until iOS 6, though.
Perhaps Apple could have made cache cleaning opt-in on a per-app basis until iOS 6, though.
The main issue is that iOS is deciding that you don't need something offline without asking you. I don't want my cached email to turn out to have been deleted because I downloaded something else entirely.
Many people would prefer the old method, where it would say you were out of space, and you would have to go free up some space.
Many people would prefer the old method, where it would say you were out of space, and you would have to go free up some space.
That's right; the solution is to make it easier to see which apps are using how much space and then provide a "clear" button.
My Nintendo Wii uses a "blocks" concept for this. It works fine, Apple should just copy it.
My Nintendo Wii uses a "blocks" concept for this. It works fine, Apple should just copy it.
Is it possible that a user could use Instapaper to save a document that they wouldn't be able to download later, even if they had access to an internet connection? If that's possible, I think Instapaper would have every right to store things in the Documents folder, since you're asking it to create something more akin to an archive than a temporary cache of data.
That seems to be the only way for Instapaper to give their users a reasonable experience, but it's still a bad solution. It doesn't make much sense for the Instapaper app to backup its users' cached articles to iCloud, when the whole point of the app is to backup the articles on the iPhone. If you have access to iCloud, you have access to the original article, so it's a waste of bandwidth. Not to mention that Instapaper risks getting hounded by Apple for the iCloud usage.
I honestly don't think there is an issue with allowing Instapaper content to get backed up to iCloud here. The analogy of a user created archive is a good one.
If people don't want the benefit of having their Instapaper content transfers across their devices automatically (and I do think this is a good feature) then they are free to disable iCloud backup for Instapaper in Settings.
If people don't want the benefit of having their Instapaper content transfers across their devices automatically (and I do think this is a good feature) then they are free to disable iCloud backup for Instapaper in Settings.
That's not entirely true. You can disable iCloud syncing for individual Apple apps, but 3rd party apps are all-or-nothing. You can't disable iCloud syncing for a single 3rd party app.
You can't? What's this screenshot showing, then?
http://i.imgur.com/acOje.png
(That's a serious question, BTW. I would check it myself but I can't upgrade to iOS5 until I figure out how to get Windows DEP to stop killing iTunes 10.5 every time I launch it.)
http://i.imgur.com/acOje.png
(That's a serious question, BTW. I would check it myself but I can't upgrade to iOS5 until I figure out how to get Windows DEP to stop killing iTunes 10.5 every time I launch it.)
I didn't find that setting screen. Definitely didn't see that in Settings/iCloud. I wonder how you get to that... I only had a chance to briefly look at my roommate's 3GS on iOS 5; won't be on iOS 5 myself until my 4S arrives later today.
Yes, you can disable iCloud backup on a per app basis.
Weird. On my roommate's 3GS upgraded to iOS 5.0 (I've not upgraded mine yet as my 4S is arriving today), I did not see the screen shown in the screenshot linked in the post above in the Settings/iCloud section. There were toggles for all the Apple apps, but 3rd party apps seemed to only be able to be toggled all at once, with a toggle called "Applications and Documents" or something of the sort. How do you do it?
It is admittedly, on double-checking, a bit convoluted.
Settings > iCloud > Storage and Backup > Manage Storage > [DEVICE] > Backup Options.
Settings > iCloud > Storage and Backup > Manage Storage > [DEVICE] > Backup Options.
Indeed; it's strange they bury it that deeply. Thanks for rooting that out.
I could be wrong, but I think all the articles are on Instapaper's servers, so you can re-download them.
But only if you are online, which defeats the object of "offline access".
The whole idea of an app like Instapaper (or any of the other examples presented) is that the "stuff" that is saved for later is all user-generated content. Some articles may even vanish (different location, move behind a paywall, deleted, etc...). In this case those articles would become inaccessible when the OS deletes the cache.
It seems that the argument that only the list of metadata is user-generated can apply to any type of media (music, movies, etc...). Technically speaking all of the music on my phone could be downloaded on demand. Of course this requires an always connected, fat, and cheap network connection. Which is pretty much the opposite of what most folks have.
This also breaks the user's expectations. I was annoyed/surprised when I upgraded to iOS 5 and Instapaper had to re-download everything.
It seems that the argument that only the list of metadata is user-generated can apply to any type of media (music, movies, etc...). Technically speaking all of the music on my phone could be downloaded on demand. Of course this requires an always connected, fat, and cheap network connection. Which is pretty much the opposite of what most folks have.
This also breaks the user's expectations. I was annoyed/surprised when I upgraded to iOS 5 and Instapaper had to re-download everything.
> Some articles may even vanish (different location, move behind a paywall, deleted, etc...). In this case those articles would become inaccessible when the OS deletes the cache.
As far as I know, all scraped articles are stored in Instapaper's server and downloaded from there, you don't get them directly from the source page.
As far as I know, all scraped articles are stored in Instapaper's server and downloaded from there, you don't get them directly from the source page.
I have had articles in my list that have become unavailable. No amount of trying to re-download them works. What you say makes sense but I am unfamiliar with the exact way that it works.
Apple's in a tight spot here - either they leave things as they are and piss off developers (and, by fiat, piss off users), or they have to start forcing users to more proactively manage their remaining space.
One can probably easily imagine an interface for showing the user how much data a particular app is using and allow them to nuke the temporary stuff. It might even look beautiful. It might even be fun to use. But it's going to introduce a lot of hand-wringing and micro-managing and lots of mental overhead that Apple really, really wants to avoid.
One can probably easily imagine an interface for showing the user how much data a particular app is using and allow them to nuke the temporary stuff. It might even look beautiful. It might even be fun to use. But it's going to introduce a lot of hand-wringing and micro-managing and lots of mental overhead that Apple really, really wants to avoid.
This general problem is a symptom of a major issue regarding the use of software that does not respect the freedom of its users. Every non-apple developer and user is required to bend to the will of the programmers who develop the proprietary iOS. Any negative choices or limitations imposed by Apple Inc. are virtually uncircumventable.
On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.
If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.
On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.
If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.
> defective by design, free (as in speech), respect the freedom of its users
Is it just me, or has the free software community gotten so disciplined and precise with their talking points that it would make Karl Rove blush?
It comes down to this: different people want different things. Some people want Kramer's vision of building your own pizza, both for fun and to get exactly the pizza you want. Most people would rather have pizza driven to their house after a 1 minute phone call, and if they lose some freedom over the exact topping placement and the kind of crust used, they're quite fine with that.
Yeah, this was a really boneheaded platform decision, and I'll be very frustrated if Apple doesn't fix it. But you can't seriously tell me that open-source software doesn't sometimes make blunders or suffer from flawed usability. And the idea that I can theoretically crack open the source to my app (the Venn intersection of those with the time, ability, and willingness to do so are a speck, by the way) doesn't help me after the cache is already cleared while I'm sitting on the plane.
I don't care whether something is defective by design, or defective by lack of design: I care that it's defective, period.
The day that technology vendors start engaging in things like free speech suppression or non-consensual privacy invasion is the day I'm willing to think of computing as being a political issue. What we have here is nothing more than tech which you think sucks, and in this instance, you're very right. If it sucks enough, people will stop buying it, and/or the vendor will make it suck it less. But for god's sake, get off the the soapbox and go back to making things; everybody has exactly as much freedom as they want.
tl;dr: FOSS needs to get better at delivering pizzas instead of bitching about Domino's.
Is it just me, or has the free software community gotten so disciplined and precise with their talking points that it would make Karl Rove blush?
It comes down to this: different people want different things. Some people want Kramer's vision of building your own pizza, both for fun and to get exactly the pizza you want. Most people would rather have pizza driven to their house after a 1 minute phone call, and if they lose some freedom over the exact topping placement and the kind of crust used, they're quite fine with that.
Yeah, this was a really boneheaded platform decision, and I'll be very frustrated if Apple doesn't fix it. But you can't seriously tell me that open-source software doesn't sometimes make blunders or suffer from flawed usability. And the idea that I can theoretically crack open the source to my app (the Venn intersection of those with the time, ability, and willingness to do so are a speck, by the way) doesn't help me after the cache is already cleared while I'm sitting on the plane.
I don't care whether something is defective by design, or defective by lack of design: I care that it's defective, period.
The day that technology vendors start engaging in things like free speech suppression or non-consensual privacy invasion is the day I'm willing to think of computing as being a political issue. What we have here is nothing more than tech which you think sucks, and in this instance, you're very right. If it sucks enough, people will stop buying it, and/or the vendor will make it suck it less. But for god's sake, get off the the soapbox and go back to making things; everybody has exactly as much freedom as they want.
tl;dr: FOSS needs to get better at delivering pizzas instead of bitching about Domino's.
> I don't care whether something is defective by design, or defective by lack of design: I care that it's defective, period.
Interesting. As an engineer, I very much care about causes. Especially systematic ones. They allow me to better reason about the kinds of problems my system is likely to have, and to proactively mitigate them.
I believe that sudoman's tl;dr is something like "If Domino's executives ate at Domino's, the pizza would taste better", which is to say that (as for most iOS APIs), Apple's own software almost certainly uses different APIs than what they force developer apps to use.
Even if you don't find comments like that interesting, I do. Your comment however (and the other replies to sudoman) miss the point entirely, and instead of discussing why the Domino's executives don't eat Domino's pizza, you spend your time arguing the importance of executives.
Interesting. As an engineer, I very much care about causes. Especially systematic ones. They allow me to better reason about the kinds of problems my system is likely to have, and to proactively mitigate them.
I believe that sudoman's tl;dr is something like "If Domino's executives ate at Domino's, the pizza would taste better", which is to say that (as for most iOS APIs), Apple's own software almost certainly uses different APIs than what they force developer apps to use.
Even if you don't find comments like that interesting, I do. Your comment however (and the other replies to sudoman) miss the point entirely, and instead of discussing why the Domino's executives don't eat Domino's pizza, you spend your time arguing the importance of executives.
> Apple's own software almost certainly uses different APIs than what they force developer apps to use.
I think it's foolish to think that Apple uses private frameworks for their apps exclusively, when they could be using the public frameworks that other 3rd party apps use.
It's more likely to be: Apple uses the public frameworks for the majority of their apps but use the private frameworks for controlling the underlying hardware and subsystems of the OS [stuff like communications which could cost the user money, SMS, phone calls].
I think it's foolish to think that Apple uses private frameworks for their apps exclusively, when they could be using the public frameworks that other 3rd party apps use.
It's more likely to be: Apple uses the public frameworks for the majority of their apps but use the private frameworks for controlling the underlying hardware and subsystems of the OS [stuff like communications which could cost the user money, SMS, phone calls].
I don't understand why you didn't google before your comment. For the search "iPhone private api" we get:
http://fajkowski.com/blog/2009/05/21/clicker-app-rejected-fo...
https://github.com/kennytm/iphone-private-frameworks
http://arstechnica.com/apple/news/2008/12/private-iphone-api...
http://www.tipb.com/2010/04/06/ibooks-private-apis/
http://www.tuaw.com/2009/12/15/apple-relents-and-is-now-allo...
http://gigaom.com/apple/cut-the-drama-people-private-apis-th...
http://fajkowski.com/blog/2009/05/21/clicker-app-rejected-fo...
https://github.com/kennytm/iphone-private-frameworks
http://arstechnica.com/apple/news/2008/12/private-iphone-api...
http://www.tipb.com/2010/04/06/ibooks-private-apis/
http://www.tuaw.com/2009/12/15/apple-relents-and-is-now-allo...
http://gigaom.com/apple/cut-the-drama-people-private-apis-th...
And I don't understand why you post random links about issues you are not familiar with, which is what you would need to digest them.
Some APIs are not ready for developer use, end of story. Apple does right to forbid their use to avoid crashes on the next iOS upgrade. It's not some plot to gain advantage. CoverFlow clones were always welcome, page curl is already published (clones were welcome before that, I coded one btw), JSON parser already published, some other APIs have no place on developer space.
Your complain should be: Apple doesn't open source their system.
Some APIs are not ready for developer use, end of story. Apple does right to forbid their use to avoid crashes on the next iOS upgrade. It's not some plot to gain advantage. CoverFlow clones were always welcome, page curl is already published (clones were welcome before that, I coded one btw), JSON parser already published, some other APIs have no place on developer space.
Your complain should be: Apple doesn't open source their system.
> Some APIs are not ready for developer use
If they aren't ready, why does apple use them?
> Apple does right to forbid their use to avoid crashes on the next iOS upgrade
Why doesn't this argument apply to apple? Are there any other methods of preventing crashing?
> Your complain should be: Apple doesn't open source their system.
No. My complaint is that apple doesn't treat developers as fellow programmers, but more like "end developers" or something. Apple gets to do it differently. Case in point being OP's post.
> And I don't understand why you post random links about issues you are not familiar with
You're projecting :-/
If they aren't ready, why does apple use them?
> Apple does right to forbid their use to avoid crashes on the next iOS upgrade
Why doesn't this argument apply to apple? Are there any other methods of preventing crashing?
> Your complain should be: Apple doesn't open source their system.
No. My complaint is that apple doesn't treat developers as fellow programmers, but more like "end developers" or something. Apple gets to do it differently. Case in point being OP's post.
> And I don't understand why you post random links about issues you are not familiar with
You're projecting :-/
Yep. This I don't care the reasons th ing feels a bit obscurantist to me.
> If we were talking about free software, users would have control of their data; not some distant programmers
Example Gnome3, which is free software, even a officially sanctioned GNU project. Overnight, a few key people decide to abandon the traditional desktop metaphor, against the will of a majority of their users and to the detriment of the whole linux desktop. The users hated it and are still hating it, but nobody has the ressources to modify it. Nobody has even the ressources to keep Gnome2 alive, let alone fork Gnome3.
Yes, in theory users could make only those changes they want, but only in theory. In practice, if a significantly influential player says that Gnome2 is gone, Gnome2 is gone. Even if iOS was free software, if Apple decided to make a change, they would be still big enough to force a majority of users to accept their way.
Example Gnome3, which is free software, even a officially sanctioned GNU project. Overnight, a few key people decide to abandon the traditional desktop metaphor, against the will of a majority of their users and to the detriment of the whole linux desktop. The users hated it and are still hating it, but nobody has the ressources to modify it. Nobody has even the ressources to keep Gnome2 alive, let alone fork Gnome3.
Yes, in theory users could make only those changes they want, but only in theory. In practice, if a significantly influential player says that Gnome2 is gone, Gnome2 is gone. Even if iOS was free software, if Apple decided to make a change, they would be still big enough to force a majority of users to accept their way.
Wonderful comment. This is one reason I always laughed at the argument "yea, but... we have all the source code!". Great, so the solution is we pay to maintain it? How is this free again?
The unsaid thing about freedoms is you cannot exercise them unless you have the means to do so. If you don't have that, the only value freedoms afford you is aspirational.
Given that the potential to do something is worth a whole lot less than the activity itself, it's easy to see why FOSS is in is current state and will remain that way for a long time.
Given that the potential to do something is worth a whole lot less than the activity itself, it's easy to see why FOSS is in is current state and will remain that way for a long time.
Then you would drop freedom of speech just because it is useless unless you own CNN?
Nobody is suggesting that. In any case it's a false comparison, since anybody has the ability to fully exercise their freedom of speech. To exercise your open-source freedoms fully require skills, time, and/or money (to pay others to do it for you).
If the overall noise level is too high and you don't own a microphone, your freedom of speech can't be used effectively, you talk any nobody hears you. It is not a reason to drop freedom of speech, right? It's just the same with free software, the mere fact that you are allowed to read, change and distribute source code IS the key. Doing so is hard but not a reason to dismiss this freedom as irrelevant.
This is an example of the difference between "free as in beer" and "free as in speech".
Ubuntu has put hard money into an alternative to Gnome3, yet they chose not to put effort into Gnome2 either. Which suggests that perhaps Gnome2 has been abandoned for good reasons, even if you don't agree with them.
If you're not paying for their time (or willing to put your own time in), you don't get to chose how the people who are putting the effort in spend their programming time.
With free software, you have the option to do whatever you like to it, but no-one has the obligation to work on it on your behalf.
If you're not paying for their time (or willing to put your own time in), you don't get to chose how the people who are putting the effort in spend their programming time.
With free software, you have the option to do whatever you like to it, but no-one has the obligation to work on it on your behalf.
> With free software, you have the option to do whatever you like to it, but no-one has the obligation to work on it on your behalf.
Absolutely and that's the problem. Say my wife (not a programmer) doesn't like it, she isn't going to learn to program, understand the code, make the changes she wants and implement them.
While it's theoretically possible, it's so impractical as to effectively be impossible.
The number of people for whom free as in speech software is actually freer than close software is a very small percentage - for others, such as my wife, Android or Linux is no freer (as in speech) than iOS or Windows.
Absolutely and that's the problem. Say my wife (not a programmer) doesn't like it, she isn't going to learn to program, understand the code, make the changes she wants and implement them.
While it's theoretically possible, it's so impractical as to effectively be impossible.
The number of people for whom free as in speech software is actually freer than close software is a very small percentage - for others, such as my wife, Android or Linux is no freer (as in speech) than iOS or Windows.
But it is possible in the free software domain, for your new-Gnome hating wife to read a blog or article about other people who also hate new-Gnome and who have put together, or suggest, an alternative. That alternative can be as little work for her as installing something else from the package manager (which can be at the skill level of a search and point and click).
This doesn't take skill in programming, no more than (in the venerable tradition of car metaphors) it takes mechanical skil to know that the dealer can install the leather seat or roof-rack options for your car if you request that of them.
You drastically understate the percentage of people who have alternatives to choose from at their skill level.
This doesn't take skill in programming, no more than (in the venerable tradition of car metaphors) it takes mechanical skil to know that the dealer can install the leather seat or roof-rack options for your car if you request that of them.
You drastically understate the percentage of people who have alternatives to choose from at their skill level.
Yes and no.
I think you're over estimating how IT literate my wife and many others are. I bought her a MacBook because she used to shout at the PC too much.
And it's not just her. My mum wouldn't get a Mac as she didn't want to have to relearn Windows. My aunty had Linux installed by one of her sons on her PC (for security reasons) and couldn't do a thing (another one returned it to Windows so she could go back to reading her mail and looking at the funny things her friends sent her). And before anyone asks about how all these examples are about women, my father is so IT illiterate I can't even form a coherent example of his lack of knowledge because there's so little of it (though he still surfs the web and looks at his photos).
For these people the idea that you'd go and look for an alternative is a pretty big stretch and that's before you ask whether they actually have the skills to carry out a proper assessment of what is available, what meets their needs, what's robust, what's actively developed (a major consideration in the FOSS world) and so on to make a choice. And even if they do do all that suddenly a major part of their world changes and there is (for them) a major investment in relearning how things work.
If you've got the skills and genuinely worry about these things then I agree FOSS is great but for a massive, massive number of people they just want something basic that makes some sensible choices they can live with and get on with doing stuff. Right now that's a need FOSS is doing little to meet.
I think you're over estimating how IT literate my wife and many others are. I bought her a MacBook because she used to shout at the PC too much.
And it's not just her. My mum wouldn't get a Mac as she didn't want to have to relearn Windows. My aunty had Linux installed by one of her sons on her PC (for security reasons) and couldn't do a thing (another one returned it to Windows so she could go back to reading her mail and looking at the funny things her friends sent her). And before anyone asks about how all these examples are about women, my father is so IT illiterate I can't even form a coherent example of his lack of knowledge because there's so little of it (though he still surfs the web and looks at his photos).
For these people the idea that you'd go and look for an alternative is a pretty big stretch and that's before you ask whether they actually have the skills to carry out a proper assessment of what is available, what meets their needs, what's robust, what's actively developed (a major consideration in the FOSS world) and so on to make a choice. And even if they do do all that suddenly a major part of their world changes and there is (for them) a major investment in relearning how things work.
If you've got the skills and genuinely worry about these things then I agree FOSS is great but for a massive, massive number of people they just want something basic that makes some sensible choices they can live with and get on with doing stuff. Right now that's a need FOSS is doing little to meet.
for others, such as my wife, Android or Linux is no freer (as in speech) than iOS or Windows.
Not entirely true. Windows can run into licensing problems from time to time, which you don't get with the other major OSes. Buy a used macbook? OS is fine. Buy a used Windows PC? Well... the vendor said it was genuine. Turns out if you try to get the security updates, it starts complaining about not being genuine. I had to sort out exactly this problem for a nontechnical ex-colleague of mine who'd bought such a PC for her new small business.
Not entirely true. Windows can run into licensing problems from time to time, which you don't get with the other major OSes. Buy a used macbook? OS is fine. Buy a used Windows PC? Well... the vendor said it was genuine. Turns out if you try to get the security updates, it starts complaining about not being genuine. I had to sort out exactly this problem for a nontechnical ex-colleague of mine who'd bought such a PC for her new small business.
That's an argument for free as in beer, not free as in speech.
But I'd say that's a pretty niche scenario. In over 20 years of PC use I can't say that I've ever come across it, either personally or seeing a friend or colleague go through it.
But I'd say that's a pretty niche scenario. In over 20 years of PC use I can't say that I've ever come across it, either personally or seeing a friend or colleague go through it.
I think it's less niche than you say. Instead, there's been an entire culture built up around avoiding windows licensing. Non-technical users have frequently asked me for 'free' windows, and many folks know they have pirated stuff but avoid the security upates because they know it'll break their licensing. Others have Windows installer discs that are pirated but valid - 'free, working Windows'.
For the most part, it 'just works', but it's not doing so in a legal way.
For the most part, it 'just works', but it's not doing so in a legal way.
That's different though. The first example was someone who thought they'd bought a valid license but had been duped. This one seems to be about people who want Windows but don't want to pay for it.
Those people need to do a total cost of ownership assessment and work out whether they go with something FOSS or something closed. While FOSS is great in cash out the door terms if you value your time it may not be as good a choice.
But again both are scenarios around free as in beer, not free as in speech.
* Incidentally, I should note I'm not against FOSS. I'm typing this into Chrome and I work for a company who build their products using Java and JBoss and who run an extensive Linux infrastructure. For us those have been great decisions but for my family who are not IT literate, I think the FOSS assessment looks very different.
Those people need to do a total cost of ownership assessment and work out whether they go with something FOSS or something closed. While FOSS is great in cash out the door terms if you value your time it may not be as good a choice.
But again both are scenarios around free as in beer, not free as in speech.
* Incidentally, I should note I'm not against FOSS. I'm typing this into Chrome and I work for a company who build their products using Java and JBoss and who run an extensive Linux infrastructure. For us those have been great decisions but for my family who are not IT literate, I think the FOSS assessment looks very different.
Your wife and all non-programmers get a major benefit when they use free software. When your wife uses proprietary software, she can never have any level of confidence that the software does what it claims to do and nothing more. Microsoft or Apple can do anything they want behind her back, and the only chance she'll ever have of knowing about it is if some disgruntled employee decides to spill the beans and doesn't immediately get silenced by Microsoft or Apple's huge legal team.
But when she uses a program whose the source code can be examined by a worldwide community of programmers, her chances are greatly improved that if the code plays any dirty tricks someone will already have discovered the offending code, they will have screamed bloody murder, and the offending code will already have been removed. Even if she's unfortunate enough to have encountered the malicious code before it's been discovered, she can be confident that when it is discovered: 1) it will quickly be fixed, and 2) since it's in Microsoft's and Apple's interests to disparage F/OSS software, it will be prominently reported on the 11:00 news.
I'm certainly not claiming that there's any absolute guarantee that any software is safe. If you really want to be paranoid, read Ken Thompson's "Reflections on Trusting Trust" at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167....
But I am claiming that her chances of being harmed by having her data misused are far, far greater when she uses software that can only be examined by a very few programmers inside an organization that has a vested interest in hiding the misuse. She's much safer when she uses software that can be examined by a worldwide community of programmers whose vested interest is in achieving status within the programmer community by producing code they can be proud of.
But when she uses a program whose the source code can be examined by a worldwide community of programmers, her chances are greatly improved that if the code plays any dirty tricks someone will already have discovered the offending code, they will have screamed bloody murder, and the offending code will already have been removed. Even if she's unfortunate enough to have encountered the malicious code before it's been discovered, she can be confident that when it is discovered: 1) it will quickly be fixed, and 2) since it's in Microsoft's and Apple's interests to disparage F/OSS software, it will be prominently reported on the 11:00 news.
I'm certainly not claiming that there's any absolute guarantee that any software is safe. If you really want to be paranoid, read Ken Thompson's "Reflections on Trusting Trust" at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167....
But I am claiming that her chances of being harmed by having her data misused are far, far greater when she uses software that can only be examined by a very few programmers inside an organization that has a vested interest in hiding the misuse. She's much safer when she uses software that can be examined by a worldwide community of programmers whose vested interest is in achieving status within the programmer community by producing code they can be proud of.
I don't dispute that that's a benefit, I do dispute that it's a big enough benefit to counter all the downsides from the perspective of a regular user.
Part of this is that I think the whole "programmers eyes" benefit is over stated.
"Can be examined" and "is examined by people who know enough to do a useful assessment" are different things. The number of programmers who really understand security isn't that high and the number of those who are committing time to review this sort of code is a fraction of this.
Most exploits aren't down to subterfuge, they're down to incompetence and the people coding (and reviewing) Linux are no less prone to that than those working on Windows or OSX. Those programmers are still human and still make mistakes. Oh, and not everyone reviewing the code has my best interests at heart. I'm not saying that security through obfuscation is good (it's not) but nor is openness without some drawbacks - on balance it's good but it's two steps forward, one step back.
And even if there are exploits in there for the NSA and the like, that's not actually that big a deal for most people. Don't get me wrong, I don't subscribe to the "privacy is only for those with something to hide" line, but security is about trade offs, and I can't see that the potentially greater security that comes from the code being open isn't worth the trade offs that come with it for non-technical users.
For me the positive thing about OSS is that to a large degree it keeps the competition honest. OSS keeps a focus on security and openness that I don't think existed in the same way before it was so prominent. I think this is a massive benefit, just one that I don't have to use OSS to take advantage of.
Because of this I love that OSS exists, and benefits from the fact it does, I just don't want to use it.
Part of this is that I think the whole "programmers eyes" benefit is over stated.
"Can be examined" and "is examined by people who know enough to do a useful assessment" are different things. The number of programmers who really understand security isn't that high and the number of those who are committing time to review this sort of code is a fraction of this.
Most exploits aren't down to subterfuge, they're down to incompetence and the people coding (and reviewing) Linux are no less prone to that than those working on Windows or OSX. Those programmers are still human and still make mistakes. Oh, and not everyone reviewing the code has my best interests at heart. I'm not saying that security through obfuscation is good (it's not) but nor is openness without some drawbacks - on balance it's good but it's two steps forward, one step back.
And even if there are exploits in there for the NSA and the like, that's not actually that big a deal for most people. Don't get me wrong, I don't subscribe to the "privacy is only for those with something to hide" line, but security is about trade offs, and I can't see that the potentially greater security that comes from the code being open isn't worth the trade offs that come with it for non-technical users.
For me the positive thing about OSS is that to a large degree it keeps the competition honest. OSS keeps a focus on security and openness that I don't think existed in the same way before it was so prominent. I think this is a massive benefit, just one that I don't have to use OSS to take advantage of.
Because of this I love that OSS exists, and benefits from the fact it does, I just don't want to use it.
"Overnight, a few key people decide to abandon the traditional desktop metaphor,
against the will of a majority of their users and to the detriment of the whole
linux desktop. The users hated it and are still hating it..."
- "overnight" - Versus an open discussion among everyone interested, with lots of early prototypes available to discuss the changes.
- "against the majority of their users" - Got numbers? Reasonable surveys? Or are we just trusting that the loud crowd that curses about this change is not a vocal minority, but really 'the userbase'?
- "the detriment of the whole linux desktop" - Puh - lease.. That's not even funny. This part is just sad..
- "Users hated it and are still hating it" - Generalization, care to provide numbers, surveys - ah, right. It's just a repetition of the second point, right? To really make it stick?
Really, that was uncalled for and totally useless. You could've made your point about not being able to 'use the source' without adding unqualified attacks.
Yes, there is the inconvenience of people having different ideas of what makes an optimal program. However, in the case of Gnome3, the Gnome team has been developing fallback mode, which will be used in some GNU/Linux distros in their next releases. So there is still a good deal of original functionality still in place. (And yes there are still variants like XFCE, and other alternatives.)
However, the main point isn't whether we can get as much eye-candy as humanly possible. Free software operating systems may always be lacking some set of features that are present in proprietary systems. But the real issue is how many _anti-features_ there are. We know about Apple's decision on storage policies because it is blatant and they were up-front about it. But there is so much in a proprietary program that we can't easily monitor. It may sound paranoid, but there are likely backdoors, etc. in many of our cell phones, allowing paying governments to listen to converstaions, even when it's sitting in your pocket, or it looks like it's off but still has the battery in. http://www.neatorama.com/2011/05/29/gmail-hackers-used-us-go... Gmail and others are _known_ to have backdoors to user data for governments, for example. How comfortable are you with that?
And it's not limited to backdoors and spying. Apple once installed a hardware chip in one of their computers to remove certain features and sell it at a cheaper price. Removing the chip allowed users to use those features. While we usually don't have much control at the hardware level, I personally don't want to use an operating system that is defective by design http://www.defectivebydesign.org/ , with forced obsolescence just being one example of a dirty tactic that is often used. (Get the latest phone, the previous one isn't cool anymore and the new OS works like crap on your "old" hardware!)
If it weren't for Firefox, there would hardly be any web standards to speak of, and the internet would basically cater to Microsoft Windows' Internet Explorer. Microsoft resisted the development of the internet in its current form because it allows users of virtually any operating system to use the web to its fullest potential. I don't think Apple is very much above that kind of thinking. When there weren't many apps for the iPhone, Apple touted the idea of web-based apps, because it was an easy entry point, and there weren't many binary alternatives in the "ecosystem". Once there were lots of programs in Apple's (censored) store, they began discouraging the use of web-based applications and encouraged everyone to make programs compiled for the iPhone, largely because a user of any device can use a web-based app, but you have to buy an iPhone to use the any of the programs that have been written by programmers for that device. (No cross-compiling allowed by Apple, btw.)
So whether or not we like where development is heading with a given free software project, there is a sanity to the development process in that there are no anti-features that I can really think of. If any get made, then all it takes is _one_ programmer to say, "I don't like that idea, I'll just delete that code and share the change with others, because it suits me, and because I can."
edit: spelling
However, the main point isn't whether we can get as much eye-candy as humanly possible. Free software operating systems may always be lacking some set of features that are present in proprietary systems. But the real issue is how many _anti-features_ there are. We know about Apple's decision on storage policies because it is blatant and they were up-front about it. But there is so much in a proprietary program that we can't easily monitor. It may sound paranoid, but there are likely backdoors, etc. in many of our cell phones, allowing paying governments to listen to converstaions, even when it's sitting in your pocket, or it looks like it's off but still has the battery in. http://www.neatorama.com/2011/05/29/gmail-hackers-used-us-go... Gmail and others are _known_ to have backdoors to user data for governments, for example. How comfortable are you with that?
And it's not limited to backdoors and spying. Apple once installed a hardware chip in one of their computers to remove certain features and sell it at a cheaper price. Removing the chip allowed users to use those features. While we usually don't have much control at the hardware level, I personally don't want to use an operating system that is defective by design http://www.defectivebydesign.org/ , with forced obsolescence just being one example of a dirty tactic that is often used. (Get the latest phone, the previous one isn't cool anymore and the new OS works like crap on your "old" hardware!)
If it weren't for Firefox, there would hardly be any web standards to speak of, and the internet would basically cater to Microsoft Windows' Internet Explorer. Microsoft resisted the development of the internet in its current form because it allows users of virtually any operating system to use the web to its fullest potential. I don't think Apple is very much above that kind of thinking. When there weren't many apps for the iPhone, Apple touted the idea of web-based apps, because it was an easy entry point, and there weren't many binary alternatives in the "ecosystem". Once there were lots of programs in Apple's (censored) store, they began discouraging the use of web-based applications and encouraged everyone to make programs compiled for the iPhone, largely because a user of any device can use a web-based app, but you have to buy an iPhone to use the any of the programs that have been written by programmers for that device. (No cross-compiling allowed by Apple, btw.)
So whether or not we like where development is heading with a given free software project, there is a sanity to the development process in that there are no anti-features that I can really think of. If any get made, then all it takes is _one_ programmer to say, "I don't like that idea, I'll just delete that code and share the change with others, because it suits me, and because I can."
edit: spelling
For the vast majority of developers of iOS apps the specifics of how their data is stored and backed up do not matter. If they were not forced by Apple to adopt this set of constraints they would make decisions on a whim, it would lead to less freedom for user, because where there is uniformity, there is a power to abstract, there is a freedom to not micromanage.
Circumventing design decicions is hard. Learning the specifics of particular design is hard practically in the same way. Hacking in an intentionally prohibitive environment is not much different from hacking in an overtly permissive environment — there's a pile of poorly undocumented design decisions which you have to grock before you get anywhere in this system.
So the actual difference it political. I won't argue that preventing little Joe to write the coolest Doom clone ever by requiring all software to be cryptographically signed before running it on a particular game console is somehow more evil than forcing him to spend years learning the ropes and working late hours in QA.
But I believe that imposing certain constrains on people willing to build on your platform is a good thing, because the resulting uniformity gives the platform more leverage. Whethere the constraints are technical or political /in origin/ is irrelevant.
Circumventing design decicions is hard. Learning the specifics of particular design is hard practically in the same way. Hacking in an intentionally prohibitive environment is not much different from hacking in an overtly permissive environment — there's a pile of poorly undocumented design decisions which you have to grock before you get anywhere in this system.
So the actual difference it political. I won't argue that preventing little Joe to write the coolest Doom clone ever by requiring all software to be cryptographically signed before running it on a particular game console is somehow more evil than forcing him to spend years learning the ropes and working late hours in QA.
But I believe that imposing certain constrains on people willing to build on your platform is a good thing, because the resulting uniformity gives the platform more leverage. Whethere the constraints are technical or political /in origin/ is irrelevant.
> there is a power to abstract, there is a freedom to not micromanage.
Oh, so is that like having freedom from porn now?
Oh, so is that like having freedom from porn now?
is that like having freedom from porn now?
Well, it is a lot like freedom from worry about what your 10-year-old is doing with the iPhone you bought them.
As long as someone offers devices that give you the abilities you want, why begrudge people who want something different?
Well, it is a lot like freedom from worry about what your 10-year-old is doing with the iPhone you bought them.
As long as someone offers devices that give you the abilities you want, why begrudge people who want something different?
So let's all wear the same clothes, eat the same foods, engage in the same pastimes, work the same hours, walk at the same speeds, drive the same car. Then the only abstraction will be in our dreams - the only place we will be free! Our dreams will then be the blessed relief that we will always look forward to as our own little free moment.
Point is, such didactic statements are stupid, as is the whole 'less choice is actually more freedom' mantra.
Put it this way. Say the government mandated one phone. One car. One style of house. One fashion outfit. You don't need any more than that. You're freed from having to micromanage your stuff. Sure, you can wear your outfit any way you want, and get your one car in whatever colour, but hey, uniformity breeds freedom from the enduser, right? Because 'micromanagement' is bad, right?
Point is, such didactic statements are stupid, as is the whole 'less choice is actually more freedom' mantra.
Put it this way. Say the government mandated one phone. One car. One style of house. One fashion outfit. You don't need any more than that. You're freed from having to micromanage your stuff. Sure, you can wear your outfit any way you want, and get your one car in whatever colour, but hey, uniformity breeds freedom from the enduser, right? Because 'micromanagement' is bad, right?
So let's all make our own clothes, grow our own foods, invent our own pastimes, work random hours, ignore road signs, and build our own cars.
There's a happy middle, and I think we're approaching it (given the mobile ecosystem, from both sides). I enjoy using iOS, and for most of my apps I don't care where they store it. I do agree that there appears to be a design flaw in iOS surrounding this, but allowing users complete control over their system only allows them (including me) a greater opportunity to shoot themselves in the foot.
There's a happy middle, and I think we're approaching it (given the mobile ecosystem, from both sides). I enjoy using iOS, and for most of my apps I don't care where they store it. I do agree that there appears to be a design flaw in iOS surrounding this, but allowing users complete control over their system only allows them (including me) a greater opportunity to shoot themselves in the foot.
But we're already at the happy middle. I don't design my phone hardware, I don't design my operating system, I don't grow my own food...
... but I am free to do all of those, plus free to modify all of those in the way I choose, should I want a better fit. Sure, I may have to be a dev, and have background knowledge in how to engage in some of those, but the capability is there. Granny Jones isn't going to shoot herself in the foot because of some downloaded maps.
... but I am free to do all of those, plus free to modify all of those in the way I choose, should I want a better fit. Sure, I may have to be a dev, and have background knowledge in how to engage in some of those, but the capability is there. Granny Jones isn't going to shoot herself in the foot because of some downloaded maps.
Yes, abstract freedom is great.
Now, how about some real freedom. Like the freedom to choose the mobile OS you want, be it "restricted" iOS or "open" Android, or whatever.
Now, how about some real freedom. Like the freedom to choose the mobile OS you want, be it "restricted" iOS or "open" Android, or whatever.
Why is 'choosing your OS' "real freedom", but 'modifying your OS' "abstract freedom"?
> So let's all wear the same clothes, eat the same foods, engage in the same pastimes, work the same hours, walk at the same speeds, drive the same car.
Yes, clearly restrictions for the space available to apps on a mobile phone is the same as political totalitarianism.
And user space apps not being able to address/change kernel space in Unix is also a major blow to our freedom.
Yes, clearly restrictions for the space available to apps on a mobile phone is the same as political totalitarianism.
And user space apps not being able to address/change kernel space in Unix is also a major blow to our freedom.
Wow, is that what all the downmodding is about? Way to miss the point, HN.
I'm trying to say that choice is not equivalatable to micromanagement - if it was, and the elimination of micromanagement is good, then the elimination of choice would be good - which it patently isn't. You have choice over a great many things in your life which are trivial, yet which people find important to have.
It was an analogy - "put it this way. say the X" kinda makes that clear.
I'm trying to say that choice is not equivalatable to micromanagement - if it was, and the elimination of micromanagement is good, then the elimination of choice would be good - which it patently isn't. You have choice over a great many things in your life which are trivial, yet which people find important to have.
It was an analogy - "put it this way. say the X" kinda makes that clear.
Every non-apple developer and user is required to bend to
the will of the programmers who develop the proprietary
iOS.
Every non-developer user is required to bend to the will
of the programmers who develop the OS.
Android is not a free operating system, but originally claimed to be one. http://yro.slashdot.org/story/11/09/19/1756241/RMS-Is-Androi...
The older I get the less tolerant I get of wild-eyed zealots like this. This sloganizing reminds me of the Mao days when lots of impressionable youths would wave the little red book and unthinkingly chant extracts, this is really no different.
Ooh! downvotes without explanation, herd mentality or hurd mentality?
> This general problem is a symptom of a major issue regarding the use of software that does not respect the freedom of its users.
Developers are not users. I don't particularly want my mobile phone to respect the "freedom of its developers". I do want to be sure that no app I install at a whim hogs the disk down, installs spyware or f*ks the phone when I'm in need to make an important call. If I wanted "developer freedom" I'd choose OpenMoko. Strangely, millions of us did not.
> Every non-apple developer and user is required to bend to the will of the programmers who develop the proprietary iOS.
He's only "required" so if he chooses to use iOS. And if he chooses to use iOS, it's because the platform attracted him, and one thing that attracts a lot of people to it it's the "it just works" and "you don't have to manage it".
> Any negative choices or limitations imposed by Apple Inc. are virtually uncircumventable.
Yeah. Except if you jailbreak.
> On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.
Yes. Then you get the mighty OpenMoko. Not defective by design. Yay!
> If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.
Yes, for a brief time in college I'd quote RMS too. You'll get over it.
Developers are not users. I don't particularly want my mobile phone to respect the "freedom of its developers". I do want to be sure that no app I install at a whim hogs the disk down, installs spyware or f*ks the phone when I'm in need to make an important call. If I wanted "developer freedom" I'd choose OpenMoko. Strangely, millions of us did not.
> Every non-apple developer and user is required to bend to the will of the programmers who develop the proprietary iOS.
He's only "required" so if he chooses to use iOS. And if he chooses to use iOS, it's because the platform attracted him, and one thing that attracts a lot of people to it it's the "it just works" and "you don't have to manage it".
> Any negative choices or limitations imposed by Apple Inc. are virtually uncircumventable.
Yeah. Except if you jailbreak.
> On the other hand, if users and developers in a community are free to view, modify and share the source code of the operating system and programs they are using, then that creates a dynamic where software cannot remain defective by design, something which cannot be said about Apple's hardware or software.
Yes. Then you get the mighty OpenMoko. Not defective by design. Yay!
> If we were talking about free (as in speech) software, users would have control of their data, and their choice of how to manage it; not some distant programmers working for a corporation's bottom line.
Yes, for a brief time in college I'd quote RMS too. You'll get over it.
> He's only "required" [to do] so if he chooses to use iOS. And if he chooses to use iOS, it's because the platform attracted him, and one thing that attracts a lot of people to it it's the "it just works" and "you don't have to manage it".
That is entirely true, and yes that is part of the problem. The polished nature of a proprietary operating system is like a polished jail. It may be nice and roomy now, but what about in 5 or 10 years when everyone has an iPhone and Apple has one or no competitors? Can we stop them from shrinking our room if there is no free alternative?
> Except if you jailbreak
Actually, no. You can access the filesystem, but you can't install your own free (or proprietary) operating system on the iPhone because there isn't one.
Free software isn't all about nice looking features (though they tend to get developed in time), it's largely about creating a dynamic that ensures the freedom of the user, and that protects them from anti-features, both blatant and subtle. It may not sound like much on the surface, but it's an important issue, especially if someday someone in power says that they don't approve of what you do with your computing devices.
The user of a program is controlled by the program and the program is controlled by the programmer. Do you wish to be controlled by someone who won't show you what the program does, and doesn't allow others to make improvements? There _are_ alternatives, and they are not perfect. I don't expect everyone to be an early adopter of every free technology, but there are many, especially at HN, who would be able to use them and to help them grow to the point where most people would be able to use them quite easily. Developing free software is an act of generosity, because it is much needed in our world, where we are becoming so dependent upon computing technology.
That is entirely true, and yes that is part of the problem. The polished nature of a proprietary operating system is like a polished jail. It may be nice and roomy now, but what about in 5 or 10 years when everyone has an iPhone and Apple has one or no competitors? Can we stop them from shrinking our room if there is no free alternative?
> Except if you jailbreak
Actually, no. You can access the filesystem, but you can't install your own free (or proprietary) operating system on the iPhone because there isn't one.
Free software isn't all about nice looking features (though they tend to get developed in time), it's largely about creating a dynamic that ensures the freedom of the user, and that protects them from anti-features, both blatant and subtle. It may not sound like much on the surface, but it's an important issue, especially if someday someone in power says that they don't approve of what you do with your computing devices.
The user of a program is controlled by the program and the program is controlled by the programmer. Do you wish to be controlled by someone who won't show you what the program does, and doesn't allow others to make improvements? There _are_ alternatives, and they are not perfect. I don't expect everyone to be an early adopter of every free technology, but there are many, especially at HN, who would be able to use them and to help them grow to the point where most people would be able to use them quite easily. Developing free software is an act of generosity, because it is much needed in our world, where we are becoming so dependent upon computing technology.
>That is entirely true, and yes that is part of the problem. The polished nature of a proprietary operating system is like a polished jail. It may be nice and roomy now, but what about in 5 or 10 years when everyone has an iPhone and Apple has one or no competitors? Can we stop them from shrinking our room if there is no free alternative?
Well, for one our room was fairly small itself before the iPhone. Actually, not small --inexistent. The only reason the touch-smartphone room exists is because Apple made the iPhone and then everybody copied it. So, if they have no competitor in 10 years, more power to them.
But I think that that can't happen. Even MS at the height of its power has had competitors... And today we have Android in several versions already.
> Actually, no. You can access the filesystem, but you can't install your own free (or proprietary) operating system on the iPhone because there isn't one.
Why that is? Because the OSF/GNU etc never cared about a mobile OS until Apple made one. Suddenly freedom in the mobile apps was important. Why wasn't it important when Nokia, Sony, Ericsson et al ruled? Because it took Apple (and Google after that) to show that a mobile OS can be a nice platform to use.
Well, for one our room was fairly small itself before the iPhone. Actually, not small --inexistent. The only reason the touch-smartphone room exists is because Apple made the iPhone and then everybody copied it. So, if they have no competitor in 10 years, more power to them.
But I think that that can't happen. Even MS at the height of its power has had competitors... And today we have Android in several versions already.
> Actually, no. You can access the filesystem, but you can't install your own free (or proprietary) operating system on the iPhone because there isn't one.
Why that is? Because the OSF/GNU etc never cared about a mobile OS until Apple made one. Suddenly freedom in the mobile apps was important. Why wasn't it important when Nokia, Sony, Ericsson et al ruled? Because it took Apple (and Google after that) to show that a mobile OS can be a nice platform to use.
> the OSF/GNU etc never cared about a mobile OS until Apple made one. Suddenly freedom in the mobile apps was important. Why wasn't it important when Nokia, Sony, Ericsson et al ruled?
Thank you. Nobody wants to remember that.
Thank you. Nobody wants to remember that.
Your comment is completely salient and relevant here, but it's received down-votes because it proposes sacrificing profits (i.e., hand-holding, generally cloud-hosted software) for freedom, and Hacker News is simply too sophisticated for such idealism.
I find your usage of the word "freedom" here highly suspect.
This "freedom" is reserved for a very, very small class of people. Conversely, as much as you might not like it, an experience that hand-holds offers a kind of freedom for people who wouldn't otherwise be able to take advantage of modern hardware and/or software.
In theory, there doesn't have to be such a dichotomy between freedom and superior polish/UX. In practice, I feel strongly that there is. The popularity of such hand-holding, "freedom"-restricting devices is also highly suggestive.
Depending on where you sit, Android seems to bridge the gap, but as an Android user for years, I'm not completely convinced it's a superior experience.
I'm not unsympathetic, but I think the above view is detached from the reality of modern computing as the majority of people experience it.
This "freedom" is reserved for a very, very small class of people. Conversely, as much as you might not like it, an experience that hand-holds offers a kind of freedom for people who wouldn't otherwise be able to take advantage of modern hardware and/or software.
In theory, there doesn't have to be such a dichotomy between freedom and superior polish/UX. In practice, I feel strongly that there is. The popularity of such hand-holding, "freedom"-restricting devices is also highly suggestive.
Depending on where you sit, Android seems to bridge the gap, but as an Android user for years, I'm not completely convinced it's a superior experience.
I'm not unsympathetic, but I think the above view is detached from the reality of modern computing as the majority of people experience it.
[deleted]
iOS 5 now lets you see per app space usage. (it's under Settings > General > Usage) I don't see anyway to delete that temp data, however, only the app itself (for non-apple apps).
That's only the data that will be backed up to iCloud though, so it probably doesn't include cache/tmp.
It does - my Downloads app is reported as using 10 GB.
It does
[deleted]
I'm sympathetic to Marco's blog post here, but I wonder if he's failing to interpret the two paragraphs from the documentation within the context of Instapaper's purpose.
With respect to point #1, and in the context of what Instapaper is for, the user is intending to read an article offline, and the local copy of the article was generated by the user's intent (and can, therefore, be considered user-generated even though the user is not the author of the article.)
With respect to point #2, the articles fail the "can be downloaded again" test in light of the app's purpose of making the articles available to the user when the network is not available. When the network is unavailable, the articles cannot be downloaded again. Edit: JeffDClark makes another excellent point here that the article may have originally been behind a paywall and therefore cannot be guaranteed to be re-downloadable. The same is true if the author removed the original article from their webserver.
Ergo, put them in the Documents folder. Whether this would satisfy the app reviewer is another question, but it's worth a shot to carefully explain to them how your app is not violating the letter of the law.
With respect to point #1, and in the context of what Instapaper is for, the user is intending to read an article offline, and the local copy of the article was generated by the user's intent (and can, therefore, be considered user-generated even though the user is not the author of the article.)
With respect to point #2, the articles fail the "can be downloaded again" test in light of the app's purpose of making the articles available to the user when the network is not available. When the network is unavailable, the articles cannot be downloaded again. Edit: JeffDClark makes another excellent point here that the article may have originally been behind a paywall and therefore cannot be guaranteed to be re-downloadable. The same is true if the author removed the original article from their webserver.
Ergo, put them in the Documents folder. Whether this would satisfy the app reviewer is another question, but it's worth a shot to carefully explain to them how your app is not violating the letter of the law.
But it doesn't make sense to back this data up to iCloud, which is what happens to the Documents folder.
Really? If I generate an offline copy of an article on my phone, wouldn't I want to have access to it on my iPad? Why wouldn't I want the truth to be in the cloud?
Because there's no point in burning your cloud storage, Apple bandwidth and prolong backup times when those articles can be easly re-downloaded from Instapapers servers on iPad.
Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.
Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.
Why there is no point in burning Apple's bandwidth, but there is a point in burning Instapaper servers' bandwidth?
I don't care how Apple (or Marco) solves the problem, but I sure do not want to lose Instapaper articles at random.
I don't care how Apple (or Marco) solves the problem, but I sure do not want to lose Instapaper articles at random.
It's not just Apple's bandwidth; it's users' iCloud storage, which costs users money.
The user can always choose not to sync Instapaper if he feels its costing him storage (though in reality, I have to wonder how much storage simple articles with occasional images could really take).
I think that has to be the best solution. It's far better to just have everything sync to iCloud and let the user choose to disable it rather than having Instapaper's primary core functionality - being able to read articles offline - not work properly.
I think that has to be the best solution. It's far better to just have everything sync to iCloud and let the user choose to disable it rather than having Instapaper's primary core functionality - being able to read articles offline - not work properly.
...when those articles can be easly re-downloaded from Instapapers servers...
My premise, in point #2, is that this actually isn't the case with respect to Instapaper's raison d'être. In fact, that's sort of the premise behind much of Marco's post too.
My premise, in point #2, is that this actually isn't the case with respect to Instapaper's raison d'être. In fact, that's sort of the premise behind much of Marco's post too.
So really what would make everyone is a type of Selective_Sync, i.e. there are three file types.
those that are ephemeral and can be deleted.
those that are ephemeral but should only deleted if given permission
And those that need to be backed up.
> when those articles can be easly re-downloaded from Instapapers servers on iPad.
That's kind-of the issue though, is it not? One of Instapaper's strength is that it provides for reading in a nicely formatted and offline way. You don't need a connection to go through your IP stack, unless iOS has decided to clean out everything.
That's kind-of the issue though, is it not? One of Instapaper's strength is that it provides for reading in a nicely formatted and offline way. You don't need a connection to go through your IP stack, unless iOS has decided to clean out everything.
You're quoting that out of context.
His point is, if you back it up to iCloud, to get any use out of the backup, you need to be online. Therefore it's a waste, because in that scenario, you can just download it from Instapaper anyways.
His point is, if you back it up to iCloud, to get any use out of the backup, you need to be online. Therefore it's a waste, because in that scenario, you can just download it from Instapaper anyways.
I took the original suggestion as a practical solution to make the best of the current situation. It doesn't make sense to potentially have a redundant backup, but it makes for a better user experience than disappearing articles.
Say I have a multimedia app that downloads assets. I don't want to see them randomly disappear or have them backup to iCloud. Where should they go?
What about apps like spotify and rdio? Where do they store music if those two directories are constantly cleaned?
For the record, I almost immediately filled up my allotted iCloud backup space because of rdio, because I have 4.6 gigs of music synced for offline use, and it wanted to back that up.
Solution: I disabled backups of rdio data.
Solution: I disabled backups of rdio data.
I don't understand Apple's logic here. You can't reconcile the idea of "cleaning because you can redownload" with "available offline". As soon as you clean up, you are going to break offline uses.
I would guess the idea is to help enable these 500 MB per issue magazine downloads. You download a new issue, you nuke some old issue, no one cares. As long as that wasn't an issue you cared about.
I would guess the idea is to help enable these 500 MB per issue magazine downloads. You download a new issue, you nuke some old issue, no one cares. As long as that wasn't an issue you cared about.
I had the exact same question and your idea as to the answer is interesting. Perhaps this new behavior is in response to Newsstand's ability to automatically download new issues--users may allow those to stack up without any thought and run out of space. The question then becomes: why not just enforce this behavior for Newsstand?
Somewhat of a conspiracy theory - but if the choice for developers is risk losing losing local data or back data up to the cloud unnecessarily, I think they'll choose to store it to the cloud, as they will be the ones blamed when their app "deletes data randomly".
The more storage space taken up by local files being backed up to iCloud, the more people will end up going over their 5GB capacity, and will have to upgrade to the higher capacity plans to cover it. I'm not sure I actually believe this right now, but if they refuse to fix the problem, then I might...
The more storage space taken up by local files being backed up to iCloud, the more people will end up going over their 5GB capacity, and will have to upgrade to the higher capacity plans to cover it. I'm not sure I actually believe this right now, but if they refuse to fix the problem, then I might...
Seem like the Dropbox app will have this quandary but on an even larger scale.
There is a category of data that is aimed at offline use. Streaming apps like Spotify, that let you download playlists for offline use. GPS apps that download hundreds of MB of map data. You get the idea.
On one hand, this data is a form of cache. The data is always available elsewhere (on the content provider servers) and it can be restored if necessary in a worst case scenario. But the key word here is "offline". This is the kind of data that, by definition depends on being around if the user is offline and therefore cannot be easily restored on demand, when the user needs it.
Obviously, having all of this stuff backed up to iCloud and using up GBs of people's capacity is not feasible or even logical. So this kind of data does not belong anywhere that iCloud will back up. But it must be stored somewhere that is safe from being purged.
Yes, a users GPS maps can be restored eventually but that doesn't help them when they are stranded in the middle of nowhere with nothing but a weak GPRS signal and all of their maps gone.
Apple have made an almighty cockup in overlooking the "offline data" use case.
In Marco's case, I'd agree that the articles represent user data that should be stored somewhere like Application Support, which will be backed by iCloud but I think that's probably fine in this case.