Google Releases Open Source File Sharing Project 'Upspin' On GitHub (betanews.com) 58
BrianFagioli quotes a report from BetaNews: Today, Google unveiled yet another way to share files. Called "Upspin," the open source project aims to make sharing easier for home users. With that said, the project does not seem particularly easy to set up or maintain. For example, it uses Unix-like directories and email addresses for permissions. While it may make sense to Google engineers, I am dubious that it will ever be widely used. "Upspin looks a bit like a global file system, but its real contribution is a set of interfaces, protocols, and components from which an information management system can be built, with properties such as security and access control suited to a modern, networked world. Upspin is not an "app" or a web service, but rather a suite of software components, intended to run in the network and on devices connected to it, that together provide a secure, modern information storage and sharing network," says Google. The search giant adds: "Upsin is a layer of infrastructure that other software and services can build on to facilitate secure access and sharing. This is an open source contribution, not a Google product. We have not yet integrated with the Key Transparency server, though we expect to eventually, and for now use a similar technique of securely publishing all key updates. File storage is inherently an archival medium without forward secrecy; loss of the user's encryption keys implies loss of content, though we do provide for key rotation."
That example (Score:1)
>With that said, the project does not seem particularly easy to set up or maintain. For example, it uses Unix-like directories and email addresses for permissions. While it may make sense to Google engineers, I am dubious that it will ever be widely used.
I, for one, am unable to find an example that is less to the point.
Re: (Score:3)
Re: (Score:2)
Before OSX, Macs did have one root per file filesystem, but users referred to them by name (roughly equivalent to volume labels), and internally the OS dynamically assigned them positive 16-bit IDs as they were mounted.
Re:Unix-like directories? (Score:4, Insightful)
Drive letters are by and large a hangover from CP/M and DOS, and could have been eliminated, or at least deprecated as early as Windows NT 3.5. Frankly, driver letter are completely ludicrous, to the point of being outright annoying. I've had local storage devices knock out drive shares, as an example of how utterly stupid the system is. We're literally dealing with a 40+ year old file device paradigm that only exists because MS seems completely unwilling to accept that Unix does it better.
Re: (Score:2)
No, just mountpoints.
Re: (Score:2)
Drive letters are by and large a hangover from CP/M and DOS, and could have been eliminated, or at least deprecated as early as Windows NT 3.5. Frankly, driver letter are completely ludicrous, to the point of being outright annoying. I've had local storage devices knock out drive shares, as an example of how utterly stupid the system is. We're literally dealing with a 40+ year old file device paradigm that only exists because MS seems completely unwilling to accept that Unix does it better.
I suspect it would break a lot of shit built in to Windows, including Microsoft's failed mobile version. The problem is, a ton of developers (including Microsoft) doesn't use relative paths in many cases, so I suspect these things would never change just like how Microsoft skipped version 9 of Windows for compatibility reasons. That, and path separators should be a front slash instead of a back slash (though Powershell seems to interpret either one just fine) and CRLF should go away, both of which are CP/M
Re: (Score:2)
Historically the A: drive was the floppy drive (not really floppy, but don't get me started on that).
When the "A:" terminology was invented, the disks and their containers really were floppy.
Re: (Score:2)
even WebTV users could manage a directory structure.
Re: (Score:2)
As all good people know, any technology that allows files to be transferred over the internet can enable piracy and thus is evil. Any company that makes a technology which ends up being used for piracy must be shut down for the good of the global economy. Or terrorism. Or think of the children.
Re: (Score:2)
Re: (Score:2)
Considering the enterprise use of GMail, no, it's not going anywhere. But way to exaggerate. Welcome to the Newest Epoch of Humanity, where, if you can't make an argument well, you can at least make it hyperbolically, which is the same thing, right?
infrastructure (Score:1)
>While it may make sense to Google engineers, I am dubious that it will ever be widely used
Idiot. It's infrastructure, also known as engineer land. I'm sure it will make sense to plenty of non-google engineers.
Re: (Score:2)
Unless those non-Google engineers have already heard of ftp, scp, rsync, etc.
The only real problem with sharing on home connections involves NAT, ISP ToS, etc: being findable and connectable. Rent a VPS and install OpenVPN on it, have your home fileserver connect to it, and it's solved.
Re: (Score:2)
Re: (Score:2)
That does explain why it intended as a way to glue services together as data sources, instead of being a "file sharing project." Files could certainly be at both ends though.
written in Go (Score:3)
It seems interesting but admittedly I stopped looking into it when I learned that it is written in Go. The problem is less with the language and more about the fact that it will radically reduce the number of people that will work on it, especially long term. I don't know what the future is but I think Go will go the way of Ruby: a language du jour.
Re: (Score:3)
Re: (Score:2)
You grossly underestimate the ability of decent programmers to switch from language to language.
I don't question the ability of programmers to pick up a languages, I question their will to do so. Unless they are paid to do so or interested in the language, they will have little reason to bother with a new project that's not written in their language of choice. I'm a programmer myself which is why I mentioned it.
Re: (Score:2)
Re: (Score:2)
It can matter depending on the use case. If a person wants better end user file sharing for IoT devices, then they might not be happy with anything other than C. Or, they might be happy to use python or Lua or Go or whatever. But probably not all at once, and they're probably not choosing based on the file interface.
For use on a general purpose desktop computer, it seems pretty boring because there are so many existing solutions.
Re: (Score:2)
Re: (Score:2)
Ruby may not be the hot thing anymore, but it's still a usable language, and there are still people using it.
The same can be said about COBOL and Fortran.
Re: (Score:2)
These days I can easily use Ruby in my COBOL. (true story)
Re: (Score:3)
Ruby is a beautifully designed language, a pleasure to code in. Even if I cannot stand the Rails Culture and its general attitude, learning Ruby changed me as a programmer. As long as I'm not the only one, Ruby will continue to be used.
Re: (Score:2)
The great thing about Ruby is that you can do all the work in C if you want, easily.
If you want to make sure your library works well in Ruby, just write it in C. Problem solved.
Comment removed (Score:3)
Re: (Score:2)
Well Brian, to wrap your head around things you can relate to, better toss that MacBook you authored your article on (BSD-variant and Unix-like directory structure), stop watching Netflix (hosted on Linux and some distributed POSIX-friendly Unix-like filesystem), don't put anything on Dropbox anymore (hosted on Linux and some distributed POSIX-friendly Unix-like filesystem). Get my point? Stop whining. Just because it's over your head, doesn't mean it's not over anyone elses.
Also, try using the web with URLs like http:\\backslashdot.org\ to avoid the Unixy feel.
no one asked for this (Score:2)
Now, if you want a business product, sure, you could probably fit this in somewhere, the somewhere where people don't use network s
Re: (Score:3)
I guess one could possibly integrate into some sort of home filesharing appliance, although my limited experience with this kind of hardware suggests they already have their own variations on this. Perhaps not quite the same level of security, but I fail to see why that would matter that much in a home setting. I guess someone could build an cloud app with it, but then again, there are already lots of those around.
Calling developers (Score:1)
This looks like a set of services which others can build on to provide consumer friendly applications, hiding the scary Unixy stuff. Maybe Google won't do it themselves because they're afraid of the copyright monsters.
vanity (Score:2)
Plan9? (Score:5, Informative)
A quick look at contributors confirms Rob Pike and Dave Presotto among them, who was among the key personalities at Bell Labs working on Plan9, all but confirming the lineage. As I recall, some of the same folks are behind Go.
What are the odds this has a different future than Plan9?