121–130 of 170 posts
The left hand doesn't seem to know what the right hand is doing it seems. Why not use another Google backed project, grpc, for their rpc stuff? I can understand not wanted extra dependencies, but then why depend on protobuf?
Seems to be very much in the space of kbfs and IPFS. For the folks who are building this: can you compare and contrast this to both kbfs and IPFS? Why have you chosen to start another project in an already crowded space instead of contributing to either of those projects? They are both open source and much further along in development . . .
We are aware of kbfs, ipfs, and several other systems. There are many trade-offs one can make in this space, and I think Upspin's set of tradeoffs is somewhat unique. One reason we started this project instead of contributing to others is that it's not clear that the trade-offs made by extant systems are really working for users, at a fundamental level. Maybe Upspin's will, maybe they won't. We'll see. We wrote a bit…
Is this an early sign of Google going back to its "not evil" roots or do I read too much into this?
Edit: for context, I used to be a google fanboy and I still to sone degree recommend some of their products. I just got a bit fed up with the butchering of xmpp and possibly a few things I can't remember right now.
Earlier quoted context omitted.
What problem does this solve for the end-user that isn't already or better solved by Google Drive, Dropbox, or sharing in chat apps like Hangouts or WhatApp? Or is it like, "Here is some cool technology!" without identifying a clear user need this solves, like Google Wave?
Dropbox uses one key for all content... Google drive means google can see all of your stuff... Sharing in hangouts is just like drive... WhatsApp isn't close to this robust... Wave was just really far ahead of its time but you see the modern incarnation in google docs and paper. This is like the infra to build spideroak on your own hardware. It's not the same as a service where you have to trust the operator.
Paper?
Does anyone have more context to compare this to Camlistore, which is made by another member of the Go team?
Hi, Camlistore author here. Andrew Gerrand worked with me on Camlistore too and is one of the Upspin authors. The main difference I see is that Camlistore can model POSIX filesystems for backup and FUSE, but that's not its preferred view of the world. It is perfectly happy modeling a tweet or a "like" on its own, without any name in the world. Upspin's data model is very much a traditional filesystem. Also, upspin ca…
You mean work is progressing on camlistore? That would make me a little bit happier : )
Earlier quoted context omitted.
Dropbox uses one key for all content... Google drive means google can see all of your stuff... Sharing in hangouts is just like drive... WhatsApp isn't close to this robust... Wave was just really far ahead of its time but you see the modern incarnation in google docs and paper. This is like the infra to build spideroak on your own hardware. It's not the same as a service where you have to trust the operator.
> google docs and paper Paper?
Cool to see in terms of Go style how they handle errors -- https://github.com/upspin/upspin/blob/master/errors/errors.g... It's a common pattern I've seen, but given that this comes from Rob Pike etc., glad to see that the pattern is considered a good one Edit: I sound like a total fangirl :/
It's such a good pattern, that other languages have even standardized it. Java's exceptions are basically the same thing: The stacktrace and the underlying exception come by default. Arguably, Go made a mistake here by not having featureful errors, since now each project has to reimplement them.
Plus, when I write Java I have to constantly specify new Exception types. I don't see anything wrong with having to do it for Go when I really want more or less data depending on circumstance.
Earlier quoted context omitted.
Does upspin have a known "set of tradeoffs [that are] somewhat unique" or does the community need to flesh them out? High-level bullets would be nice.
We haven't written the docs. That's what the issue I linked in the parent post is about.