Pages

07 February 2015

Ubuntu phone?


Ubuntu phone

It looks like an Ubuntu phone is going to see the light of day. While I really want to see this launch be a success, the description of the phone by BBC News has me less than blisteringly hopeful. And not because the offering is a low-end device. Rather, it's because the phone won't have the most valuable distinctive feature promised by the platform--conversion to desktop mode when hooked up to external devices--and it will place front and center a largely app-less Scopes UI--which seems to try to be different mostly for the sake of creating some kind of distinction.

I think history has shown that different for different sake doesn't work out well in crowded, high-tech consumer markets. Different in and of itself doesn't offer the user value. In fact, different in and of itself represents friction for the user, a friction that something of greater value must overcome--be it improved performance, better usability, increased visceral appeal (with longevity), or useful new features. In addition, the problems of being different are amplified when when it comes from an upstart that lacks the marketing muscle to boom-crash-firework users into thinking it's not what it really is.

Yes, you need product distinction to succeed in a crowded market. But it has to be a distinction that represents value, not novelty. Inaugurating the platform with  a product that's crippled in the way this one is may forever give the platform a bad reputation--which would suck.

Then again, maybe Scopes solves a problem I didn't realize I had. Which would be pretty cool.

21 January 2015

Samba and mtp automatic mountpoints with gvfs


Apparently, if you browse to a Samba share using gvfs (e.g., from Gnome's file manager, Thunar, etc.), it has a good chance of appearing as a mounted volume in /run/user/{your-user-number}/gvfs/.

It seems to work for mtp devices as well. I hooked up my Android phone, and I got a /run/user/1000/mtp:host... directory. I tried a couple command line operations in there, and while it was slow as snails, it worked. Now I can write scripts that operate on data stored on my phone!

17 December 2014

On the need for an open source smartphone


 
Threatpost is reporting on Palo Alto Networks' discovery of a backdoor on an Android phone sold primarily in the Chinese and Taiwan markets that allows the vendor (and ostensibly anyone approved by or who impersonates the vendor) to take over your phone.

Whether there is any hyperbole in this or not, it's clear that what they describe could very easily be done. And it thus underscores why we need a fully open source smartphone platform that puts the user in control. A solution that's effectively open only for vendors or leaves the last mile closed (i.e., drivers) just isn't good enough.

Once we have the software solved, we can move on to building hardware that's open in the critical areas. But let's start with the easier to solve software problem. With just the smallest help from manufacturers, we could have this problem solved yesterday.

Threatpost (via Slashdot)

10 December 2014

Here to stay?


As part of my effort to diversify my online data siloing, I've been looking for an alternative to Google Maps/Navigation on my phone. I've slogged through a lot of FOSS and proprietary offerings, but all have had various inadequacies that left me lusting for the latest from Google.

Then today I learned that the part of Nokia that wasn't sold to Microsoft released a beta of their Here mapnav app for Android. So far it has been quite good. All the features I want, some that I didn't know I wanted but am happy to have, and a reasonably usable if less than stunningly attractive UI. I only hope their monetization plans don't gut the app after it comes out of beta.

Helpful links:

14 November 2014

WebDAV

I tried a number of things to get a speedy and easy-to-use WebDAV setup and finally settled on using the setup described in Kasun's Tech Blog's Mounting a WebDAV directory in Linux (Ubuntu).

I deviated from the above by leaving /etc/davfs2/davfs2.conf as it is and instead edited the conf file at ~/.davfs2 that magically showed up. I also found a secrets file there where I added credentials. I suspect these were added after the first access I performed, that is, after I did a $ mount . in the mount directory.