Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upPWLBOS #1 => Christopher Meiklejohn on "A Note on Distributed Computing" #166
Comments
zeeshanlakhani
added
boston
labels
Aug 26, 2014
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tel
commented
Aug 28, 2014
|
Hi everyone! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tel
Aug 29, 2014
Off the cuff thoughts
I wanted to write these down and throw them out for commentary. I make no claim that this writing respects the opinions of my employer or even myself, but they did come to mind as I was listening and I'd love to hear what anyone else has to say. But also feel free to just ignore me /disclaimer
Mashalling v. Serialization
I did a poor job trying to talk about this w.r.t. JSON and I'd like to suggest that "marshalling", i.e. sending objects (really, codata) is essentially impossible.
Partial failure
Does any partial failure mentioned in the paper not depend upon distributed state? I'd sort of like to believe that without distributed state there is no notion of partial failure—or rather any partial failure can be transparently considered a total failure without any "loss". The proof sketch is just that you need distributed state in order for anyone else to know a request happened, so if the requestor just pretends like a partial failure was actually a total failure then, at the end of the day, nobody can dispute it.
Writing code that the "object should have had"
One thing Chris mentioned sort of offhandedly is that using IDs in your queue is essentially replicating entity/identity management that your "object should have had". This is, in some sense, an enormous abstracting leaking that happens in the OO mindset that entity/identity is universally manageable. Obviously light cones quickly disprove that such an abstraction could ever work as the idea simply doesn't respect causality.
So, I'm not sure I believe that "objects should have had" anything at all like entity or identity as it depends upon an acausal model of global ambient state. You just have to throw out this fundamental (well, for some models) notion of OOness entirely. Objects are still useful—but entity/identity is not as obvious as it sort of feels like it ought to be.
What is easy to map between? (Int and Char are, but other things aren't)
Chris mentioned that Int/Char are easy to map between... but more complex types are not! This is completely identical to the data/codata divide that I mentioned originally. I don't think "more complex" is the problem, but instead corecursive.
tel
commented
Aug 29, 2014
Off the cuff thoughtsI wanted to write these down and throw them out for commentary. I make no claim that this writing respects the opinions of my employer or even myself, but they did come to mind as I was listening and I'd love to hear what anyone else has to say. But also feel free to just ignore me /disclaimer Mashalling v. Serialization I did a poor job trying to talk about this w.r.t. JSON and I'd like to suggest that "marshalling", i.e. sending objects (really, codata) is essentially impossible. Partial failure Does any partial failure mentioned in the paper not depend upon distributed state? I'd sort of like to believe that without distributed state there is no notion of partial failure—or rather any partial failure can be transparently considered a total failure without any "loss". The proof sketch is just that you need distributed state in order for anyone else to know a request happened, so if the requestor just pretends like a partial failure was actually a total failure then, at the end of the day, nobody can dispute it. Writing code that the "object should have had" One thing Chris mentioned sort of offhandedly is that using IDs in your queue is essentially replicating entity/identity management that your "object should have had". This is, in some sense, an enormous abstracting leaking that happens in the OO mindset that entity/identity is universally manageable. Obviously light cones quickly disprove that such an abstraction could ever work as the idea simply doesn't respect causality. So, I'm not sure I believe that "objects should have had" anything at all like entity or identity as it depends upon an acausal model of global ambient state. You just have to throw out this fundamental (well, for some models) notion of OOness entirely. Objects are still useful—but entity/identity is not as obvious as it sort of feels like it ought to be. What is easy to map between? (Int and Char are, but other things aren't) Chris mentioned that Int/Char are easy to map between... but more complex types are not! This is completely identical to the data/codata divide that I mentioned originally. I don't think "more complex" is the problem, but instead corecursive. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tel
Aug 29, 2014
Has anyone by any chance used both Bloom and Haskell's lvish library? I'm very curious to see how they differ (in "practice")
tel
commented
Aug 29, 2014
|
Has anyone by any chance used both Bloom and Haskell's |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cmeiklejohn
Aug 29, 2014
The slides are available here:
https://speakerdeck.com/cmeiklejohn/a-note-on-distributed-computing
The video is available here:
https://www.youtube.com/watch?v=z79mjsLdkpY&feature=youtu.be
cmeiklejohn
commented
Aug 29, 2014
|
The slides are available here: The video is available here: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
vinoski
Aug 29, 2014
If you're interested, the IEEE Internet Computing articles of mine that @cmeiklejohn mentioned in his talk are here:
http://steve.vinoski.net/pdf/IEEE-Just_A_Mapping_Problem.pdf
http://steve.vinoski.net/pdf/IEEE-Convenience_Over_Correctness.pdf
There are other related ones under http://steve.vinoski.net/blog/internet-computing-columns/ as well.
vinoski
commented
Aug 29, 2014
|
If you're interested, the IEEE Internet Computing articles of mine that @cmeiklejohn mentioned in his talk are here: http://steve.vinoski.net/pdf/IEEE-Just_A_Mapping_Problem.pdf There are other related ones under http://steve.vinoski.net/blog/internet-computing-columns/ as well. |
ashleygwilliams commentedAug 26, 2014
This is a forum for questions/comments/resources related to the PWLBOS meetup.
-/-
DESCRIPTION:
We will look at A Note on Distributed Computing, a technical report published at Sun Microsystems in November of 1994. This paper specifically focuses on the idea that attempting to provide a unified view of objects, whether they are local or remote, is mistaken. We will briefly discuss the history of this model, starting with the remote procedure call (RPC) mechanism, discuss the differences between non-distributed and distributed objects, and finally provide an example of lessons learned given the problems in Sun’s Network File System (NFS).
BIO:
Christopher Meiklejohn is a Senior Software Engineer with Basho Technologies, Inc. and a graduate student in the College of Computing at Georgia Tech.