Sorry, I mentioned DynDNS but I was thinking in a more generic way (a dynamic DNS service).
My NAS has the ability to download updates automatically. It pops up a notification when it’s ready to be installed, and one click and 5 minutes later, your NAS is restarted and up-to-date.
But yes, ultimately I agree with you: it will always be too complicated for people compared to in-the-cloud services. In the end, it’s an equation where you have to balance the money, time and/or privacy you will lose when choosing a service.
Cool. Did you get an SSL update for the heartbleed bug?
We agree, though, I think. You may feel that people should make a different trade-off of privacy vs. convenience than they actually do, but I think we’re in agreement that there is that tradeoff. The way to fix this problem is to make the we-care-about-privacy-above-everything stuff actually be easier to do than the put-everything-in-the-cloud stuff. Until that happens, I think that hassling people to make a tradeoff just annoys them.
I’ve been using copy.com these days and I think it is the best alternative to Ubuntu One so far. The only problem is that you have to manually create symlinks in order to get files synchronized directly in your own file system. But the amount of free space they offer is amazing.
If you sign in by using this referral link you’ll get 20GB free and by referring you’ll get (unlimited?) bonus space: https://copy.com?r=RS9B4K
I’we been very happy with OwnCloud now. Latest version seems to work both on desktop and mobile side. I tried earlier versions some time ago and had some major problems, but now mostly all seems work fine for me. Only the website interface is quite slow, but I’m not sure if that’s due to the server I’m running it on.
Also I’m missing Ubuntu Touch app to sync my Nexus 7 ;). At least there is always sftp and terminal…
How would that work? An app on Ubuntu Touch can only read and write its own files, and then share them with other apps through the content hub. So “syncing” doesn’t really apply; there is little point in syncing a whole folder to your Ubuntu phone when the contents of that folder are then only available to the app doing the syncing. They can be shared with other apps, but at that point you might as well download them at share time rather than beforehand.
I’m not certain about this, but isn’t that just for click packages that want to get out faster with out manual authorization?
If not, I’m sure there’s other formats you’d be able to install on Ubuntu Touch that just aren’t recommended or in that app store?
It’s your phone – you can run whatever software you want on it. But if you want to make anything for actual users, then it’ll need to go into the app store, which means it’ll be running confined.
I miss the Maemo model. Aka, “It’s just freaking Debian. Do whatever you want. All the time.” This “restricted access to portions of the file system” business irritates the little Bryan inside me.
OK, let’s run with that as a thought experiment for a bit. With Bryan’s Desire For Apps Without Confinement, how do you protect against malicious apps? More importantly, how do you protect my dad against malicious apps? Let’s say that I want to write an app for BryanPhones which steals the user’s address book, website cookies, and credit card numbers, and sends them off to my server. There are, I think, these approaches:
apps gets reviewed by a real person before they’re let loose on the public. Apps are sandboxed and ask for outside-the-sandbox permissions (read photos, addressbook, etc) when they need it at runtime. Pros: it catches our malicious app. Cons: takes ages for reviews, costs an earth-shattering amount of money to run, gatekeepers are fallible. This is the Apple approach.
apps are sandboxed and declare outside-the-sandbox permissions that they will need in a manifest. All requested permissions are shown at install time; apps cannot be installed without agreeing to all permissions; once installed, an app can do everything it asked for whenever it wants. Pros: no runtime popups, no human review required. Cons: nobody understands the permissions install dialog, everyone just clicks “yes” anyway; malicious apps are thus de facto not prevented, but at least we can blame the user and say “well, you were told; you shouldn’t have installed it! lol!” This is the Android approach.
apps are sandboxed and declare outside-the-sandbox permissions that they will need in a manifest. All requested permissions are shown at install time; however, you can install an app while not granting it a permission that it wants. It will then run and (if well coded to deal with the possibility) cope with not having a permission it asked for and do something else. Pros: works around the all-or-nothing nature of the Android model. Cons: almost no apps expect to get PERMISSION_DENIED back from a web request, and so they don’t cope with it well. Usefully changing the sandbox around an app requires you to understand what the permissions actually mean, which most people do not. I don’t think anyone actually implements this approach out of the box, but it’s possible to set it up yourself on (rooted?) Android if you like it as an approach.
Apps are very tightly sandboxed and ask for outside-the-sandbox permissions (read photos, addressbook, etc) when they need it at runtime. Pros: it catches our malicious app. Cons: requires an ocean of privileged helpers which can do unsandboxed things and APIs and documentation for all these helpers, makes Bryan sad. This is the Ubuntu phone approach.
No sandboxing. Apps can do anything. Users are encouraged to only use the official archive for apps; upload access to the official archive is only granted to trusted people. Pros: a malicious app does not become available to users. Cons: doesn’t scale very well to a million apps; most app developers are not interested in becoming trusted. This is the Debian approach.
No sandboxing. Apps can do anything. There are a million apps. This is the Bryan Approach. How do you stop me writing my malicious app? Perhaps you just blame the user for running it.
Now, of course you as a user ought to have the ability to step outside the protections if you want to. And indeed you do – Android can install downloaded apks, and as noted your Ubuntu phone is yours and you can ssh into it and install Debian packages and do whatever you want. But that’s not a mass-market thing to do. If you want to solve the problem of malicious apps in some way other than caveat emptor and you want any app to be able to do whatever it wants at any time, I’d like to hear how you plan to do it. Without such a proposal, whining “but freeeeeeedom! why are you restricting meeeeee!” just makes you sound like an Gnu/Idiot, which you normally aren’t.
