Rusty's Blog

Thoughts and musings of someone who's not sure what 'normal' is…

Friday, May 15, 2009

Regarding UbuntuOne

As I noted in a identi.ca posting, the client is open, including the command structure for communicating with the server, so for people interested in a totally free/open solution, they are perfectly welcome to build a server that supports that command set, and provides the functionality desired. That may include encrypted storage, or a plug into Amazon C3, whatever.

To tell the truth, I’m not entirely happy with the idea, not because I’m concerned by the U1 licencing, or server implementation, or anything like that.

I have a colection of computers. This includes a couple of PVR systems hosting 4+ terabytes of storage for videos, music, pictures, etc that I wish to watch at my liesure. I have a server at home with about a terabyte of total storage, a couple of MiniITX based computers with 40-120 gig of storage, a primary workstation with 160 gig of internal storage, a couple of eeepcs each with 8 or 16 gig of sd storage for the home partition and differing amounts of ssd storage, one has a hard drive hanging off of it, the other has one available. I have a couple of PDAs, a G1, and a couple of Tablet formfactor computers, as well as a laptop with 128gig of storage as ssd.

In short I have a variety of systems, with differing storage capabilities, so it’s a given that I do not want to maintain a completely syncronized file system across the computers. Considering the current capabilities of te G1, I certainly don’t want to be storing MPEGs from my PVR onto it. I might be interested in transfering copies of videos to the 6670, but that’s a different matter.

The reality of the matter is that I have three different needs for syncronization. The first is to maintain availability of specific data for projects, presentations, etc. This should be temporary, and transient. Next is longer term availability of specific types of data. Music files, e-books, support tools, ISO Images, authentication credentials where appropriate, etc. Finally I would like to task a syncronization system with providing backup/recovery services. When the HD in a tablet dies, I would like to know that the data that I was working with on that tablet is on the server and can be quickly made available on a replacement tablet or notebook.

Let’s take my media library as an example. I would probably want to create a folder labeled ‘media’ (or ‘Media’) that I can create, or not create on various systems. Where the folder exists, all systems that have it, check with each other from hour to hour, or so, and syncronize changes. Do I suddenly disagree with the moral position of an artist and want to discard all that artists music? I get rid of it on one system, and the other systems discard it as well. Discover that the moral position I disagreed with was a fabrication of some creative writer’s imagination, I can pull back the media from my own archive server, and it gets re-synced to the various computers participating.

I shoot ‘raw’ images when I use my Pentax camera, and JPeG on my other camera’s. The original images all need to be archived somewhere, and since the Gimp doesn’t yet work directly with Raw images, I’m interested in maintaining a personal collection on systems that I work with there that is synced. I need the Raw image on both my archive server, and on the system that I manipulate images on. (If only to be able to re-convert from the original if I botch up an earlier converted image.) Once the images have been converted, and imported into a common image library program, I would like all systems that I am likely to present these images on to be able to sync up that image collection.

Project work. Somewhat similar to the photo manipulation process, whether I am working in writer, impress, writing batch scripts, or source code for executables, I generallly only need the original data on the system that I am working on it with. Sometimes that is more than one system, say an eeepc for writing an outline, and my desktop for doing layout, dry runs, revisions and the like. The revisions, and possibly the layout needs to be synced up with and from the eeepc, but for the most part I don’t need to maintain interim copies of object code between systems. What I’m aiming for is a presentable or usable output that I will then want to put on whatever system I need that output on.

With the exception of archiving the data, and to some degree even including that, I’m very likely not going to want to be using a client-server model for this. The single most obvious example of why I don’t want a client-server relationship for much of this is that as described, I need to buidl both a per folder, and a per file ACL at the server, so that I know which systems are going to get what data, at what granularity. The reality is that I would much rather have an rss type model where each system publishes a list of the files that are on the system, and gets told somehow what systems have authority to get data from it, and  each system that knows about the others, keeps track of what data and folders it needs to keep in sync.

Perhaps the most important reason not to have the authentication happening on a server some place is that if that server becomes compromised, it then becomes trivial for someone to gain access to all of the data for the user.  On the other hand if each system is able to identify for itself which systems are allowed access, and where appropriate which user, the security is significantly improved. Add in requiring ssl, or scp as a transfer mechanism, with updated and current security keys, and you could run all of this over open access points. But use WPA. Please.

The thing is, UbuntuOne does not appear to be looking to provide anywhere near this granularity of data management. It appears to be little more than an improved briefcase from Windows 4 Workgroups. I’m not saying that such a service isn’t important, and doesn’t have it’s uses, just that it’s not quite what I’m looking for as a multi-platform data synchronization solution.

The reality is that UbuntuOne could very well be a viable extension to a broader syncronization solution. As an example, I could use UbuntuOne as a bridge between my home systems and a work system. That way I don’t need to try to figure out what the remote feed information is between systems, and pick files as needed. I also wouldn’t be leaving ports open on my work computer, leading corporate security to suspect that my work system may be compromised in some way.

And as I say, from what I am seeing, that is basicly what the UbuntuOne system appears to me to be, along with a service that Canonical can run, and hopefully bring in more money from users who otherwise are not providing a lot of cash flow into Canonical.

I run Ubuntu wherever I can, and a few places that perhaps I should not. As noted above, I have various versions of Ubuntu on at least 12 different systems. I advocate and recommend Ubuntu in various ways, but I would not say that I’m personally making a huge contribution to Canonical’s war chest of funds. I’m afraid that I have to admit that I don’t think I’m really a significant part of the target market for UbuntuOne, but I may participate just because I can see it being useful to me, and I think it is worthwhile to support Canonical and Ubuntu overall.

Like I said to begin with, there’s nothing preventing you from writing your own server to provide a back end to the UbuntuOne client. It may turn out that your server provides better performance than whatever it is that Canonical is putting together. You may find hosting it on an Amazon cloud server is a workable solution, and if you are sharing the source code with others, perhaps you’ll find improvements and enhancements that you hadn’t thought of getting put into the server. If that happens, who knows, Canonical may start using your server software, unless you restrict the software in some way that Canonical may not be able to. I certainly won’t tell you how to handle that variety of moral and licencing question.

posted by Rusty at 1:21 am  

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress